Lines Matching refs:patches
3 Submitting patches: the essential guide to getting your code into the kernel
18 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
38 patches prepared against those trees. See the **T:** entry for the subsystem
48 If you must generate your patches by hand, use ``diff -up`` or ``diff -uprN``
49 to create patches. Git generates patches in this form by default; if
52 All changes to the Linux kernel occur in the form of patches, as
92 individual patches which modify things in logical stages; see
116 vendor/product-specific trees that cherry-pick only specific patches
206 or more patches. If your changes include an API update, and a new
207 driver which uses that new API, separate those into two patches.
221 When dividing your change into a series of patches, take special care to
227 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
308 conclusions on which patches should go to the stable trees. The networking
310 adding lines like the above to their patches.
318 For small patches you may want to CC the Trivial Patch Monkey
319 trivial@kernel.org which collects "trivial" patches. Have a look
322 Trivial patches must qualify for one of the following rules:
346 For this reason, all patches should be submitted by e-mail "inline".
359 Exception: If your mailer is mangling patches then someone may ask
363 for hints about configuring your e-mail client so that it sends your patches
398 Once upon a time, patches used to disappear into the void without comment,
401 that you have sent your patches to the right place. Wait for a minimum of
411 and other kernel developers more easily distinguish patches from other
419 To improve tracking of who did what, especially with patches that can
422 patches that are being emailed around.
467 modify patches you receive in order to merge them, because the code is not
563 future patches, and ensures credit for the testers.
620 that, if you have your patches stored in a ``git`` repository, proper patch
659 series`` is an ordered sequence of multiple, related patches).
668 thousands of patches using tools such as ``gitk`` or ``git log
683 comments. If there are four patches in a patch series the individual
684 patches may be numbered like this: 1/4, 2/4, 3/4, 4/4. This assures
685 that developers understand the order in which the patches should be
686 applied and that they have reviewed or applied all of the patches in
722 on bigger patches. Other comments relevant only to the moment or the
756 If you have a series of patches, it may be most convenient to have the
758 ``git pull`` operation. Note, however, that pulling patches from a developer
759 requires a higher degree of trust than taking patches from a mailing list.
776 included in the request, a ``git shortlog`` listing of the patches
839 Andi Kleen, "On submitting kernel patches"
842 http://halobates.de/on-submitting-patches.pdf