Lines Matching refs:patches

3 Submitting patches: the essential guide to getting your code into the kernel
16 For device tree binding patches, read
17 Documentation/devicetree/bindings/submitting-patches.rst.
19 This documentation assumes that you're using ``git`` to prepare your patches.
39 patches prepared against those trees.  See the **T:** entry for the subsystem
59 vendor/product-specific trees that cherry-pick only specific patches
175 or more patches.  If your changes include an API update, and a new
176 driver which uses that new API, separate those into two patches.
190 When dividing your change into a series of patches, take special care to
196 If you cannot condense your patch set into a smaller set of patches,
217 Check your patches with the patch style checker prior to submission
238 patches as arguments to scripts/get_maintainer.pl).  If you cannot find a
242 linux-kernel@vger.kernel.org should be used by default for all patches, but the
252 He gets a lot of e-mail, and, at this point, very few patches go through
286 For this reason, all patches should be submitted by e-mail "inline". The
304 Exception:  If your mailer is mangling patches then someone may ask
308 your e-mail client so that it sends your patches untouched.
325 version, add a ``patch changelog`` to the cover letter or to individual patches
329 the patches CC list.
367 Once upon a time, patches used to disappear into the void without comment,
370 happen, make sure that you have sent your patches to the right place.
390 and other kernel developers more easily distinguish patches from other
399 To improve tracking of who did what, especially with patches that can
402 patches that are being emailed around.
540 future patches, and ensures credit for the testers.
578 or reviewer, should be added by author to the applicable patches when sending
609 that, if you have your patches stored in a ``git`` repository, proper patch
648 series`` is an ordered sequence of multiple, related patches).
657 thousands of patches using tools such as ``gitk`` or ``git log
674 If there are four patches in a patch series the individual patches may
676 understand the order in which the patches should be applied and that
677 they have reviewed or applied all of the patches in the patch series.
717 on bigger patches. If you are going to include a ``diffstat`` after the
790 When other developers receive your patches and start the review process,
800 If you are using ``git format-patch`` to generate your patches, you can
823     $ git am patches.mbox
834 If you are not using git to format your patches, you can still include
880 Andi Kleen, "On submitting kernel patches"
883   http://halobates.de/on-submitting-patches.pdf