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
307 conclusions on which patches should go to the stable trees. The networking
309 adding lines like the above to their patches.
317 For small patches you may want to CC the Trivial Patch Monkey
318 trivial@kernel.org which collects "trivial" patches. Have a look
320 Trivial patches must qualify for one of the following rules:
343 For this reason, all patches should be submitted by e-mail "inline".
353 Exception: If your mailer is mangling patches then someone may ask
357 your e-mail client so that it sends your patches untouched.
391 Once upon a time, patches used to disappear into the void without comment,
394 that you have sent your patches to the right place. Wait for a minimum of
404 and other kernel developers more easily distinguish patches from other
412 To improve tracking of who did what, especially with patches that can
415 patches that are being emailed around.
459 modify patches you receive in order to merge them, because the code is not
550 future patches, and ensures credit for the testers.
604 that, if you have your patches stored in a git repository, proper patch
643 series" is an ordered sequence of multiple, related patches).
652 thousands of patches using tools such as "gitk" or "git log
667 comments. If there are four patches in a patch series the individual
668 patches may be numbered like this: 1/4, 2/4, 3/4, 4/4. This assures
669 that developers understand the order in which the patches should be
670 applied and that they have reviewed or applied all of the patches in
706 on bigger patches. Other comments relevant only to the moment or the
738 If you have a series of patches, it may be most convenient to have the
740 "git pull" operation. Note, however, that pulling patches from a developer
741 requires a higher degree of trust than taking patches from a mailing list.
758 included in the request, a "git shortlog" listing of the patches
817 Andi Kleen, "On submitting kernel patches"
819 http://halobates.de/on-submitting-patches.pdf