Lines Matching refs:patches
18 Documentation/SubmittingDrivers; for device tree binding patches, read
19 Documentation/devicetree/bindings/submitting-patches.txt.
22 control system; if you use git to prepare your patches, you'll find much
24 and document a sensible set of patches. In general, use of git will make
43 patches prepared against those trees. See the "T:" entry for the subsystem
53 If you must generate your patches by hand, use "diff -up" or "diff -uprN"
54 to create patches. Git generates patches in this form by default; if
57 All changes to the Linux kernel occur in the form of patches, as
96 individual patches which modify things in logical stages; see section
120 vendor/product-specific trees that cherry-pick only specific patches
208 or more patches. If your changes include an API update, and a new
209 driver which uses that new API, separate those into two patches.
223 When dividing your change into a series of patches, take special care to
229 If you cannot condense your patch set into a smaller set of patches,
249 Check your patches with the patch style checker prior to submission
284 Do not send more than 15 patches at once to the vger mailing lists!!!
288 He gets a lot of e-mail, and, at this point, very few patches go through
305 conclusions on which patches should go to the stable trees. The networking
307 adding lines like the above to their patches.
315 For small patches you may want to CC the Trivial Patch Monkey
316 trivial@kernel.org which collects "trivial" patches. Have a look
318 Trivial patches must qualify for one of the following rules:
341 For this reason, all patches should be submitting e-mail "inline".
351 Exception: If your mailer is mangling patches then someone may ask
355 your e-mail client so that it sends your patches untouched.
389 Once upon a time, patches used to disappear into the void without comment,
392 that you have sent your patches to the right place. Wait for a minimum of
402 and other kernel developers more easily distinguish patches from other
410 To improve tracking of who did what, especially with patches that can
413 patches that are being emailed around.
457 modify patches you receive in order to merge them, because the code is not
548 future patches, and ensures credit for the testers.
602 that, if you have your patches stored in a git repository, proper patch
641 series" is an ordered sequence of multiple, related patches).
650 thousands of patches using tools such as "gitk" or "git log
665 comments. If there are four patches in a patch series the individual
666 patches may be numbered like this: 1/4, 2/4, 3/4, 4/4. This assures
667 that developers understand the order in which the patches should be
668 applied and that they have reviewed or applied all of the patches in
704 on bigger patches. Other comments relevant only to the moment or the
723 If you have a series of patches, it may be most convenient to have the
725 "git pull" operation. Note, however, that pulling patches from a developer
726 requires a higher degree of trust than taking patches from a mailing list.
743 included in the request, a "git shortlog" listing of the patches
802 Andi Kleen, "On submitting kernel patches"
804 http://halobates.de/on-submitting-patches.pdf