User Tools

Site Tools


en:developers:documentation:submittingpatches

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
en:developers:documentation:submittingpatches [2018/04/13 13:24]
Kalle Valo Add section for top posting
en:developers:documentation:submittingpatches [2020/10/08 08:36]
Kalle Valo Add a section for new drivers
Line 33: Line 33:
  
   * [[en/​users/​drivers/​ath10k/​submittingpatches|ath10k]]   * [[en/​users/​drivers/​ath10k/​submittingpatches|ath10k]]
 +  * [[en/​users/​drivers/​ath11k/​submittingpatches|ath11k]]
 ===== Checking state of patches from patchwork ===== ===== Checking state of patches from patchwork =====
  
Line 93: Line 94:
  
 If a patch in a bigger patchset changes resubmit the whole patchset, even the patches which have not changes. The maintainers look at patchsets as a complete unit, usually they do not want to take patches individually from a patchset. If a patch in a bigger patchset changes resubmit the whole patchset, even the patches which have not changes. The maintainers look at patchsets as a complete unit, usually they do not want to take patches individually from a patchset.
 +
 +===== Tree labels =====
 +
 +Labeling patches with what tree the patch should go to helps maintainers to prioritise and sort patches and avoids unnecessary emails, which saves everyone time and speeds up patch review. Here are some tips how to label wireless patches.
 +
 +If you want to target your patch to a specific release (for example that the patch should go -rc release not -next) you can inform the maintainer by adding the release number inside the PATCH brackets:
 + 
 +<​code>​[PATCH 4.20] subsystem: fix foo</​code>​
 +
 +If you want to make it clear to the maintainer that the patch should NOT go to -rc release but to -next instead you can add "​-next"​ to PATCH brackets:
 +
 +<​code>​[PATCH -next] subsystem: fix foo</​code>​
 +
 +Alternatively you can specify the exact tree you are targetting by adding the name of the git tree inside PATCH brackets:
 +
 +<​code>​[PATCH mac80211] mac80211: fix foo
 +[PATCH mac80211-next] mac80211: implement very-cool-feature
 +[PATCH wireless-drivers] ath10k: fix foo
 +[PATCH wireless-drivers-next] ath10k: implement awesome-feature
 +</​code>​
 +
  
 ===== Sending large patches or multiple patches ===== ===== Sending large patches or multiple patches =====
Line 133: Line 155:
 Please also read the [[https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html|official Linux SubmittingPatches]] documentation,​ especially the **[[https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html#​sign-your-work-the-developer-s-certificate-of-origin|Developer'​s Certificate of Origin]]**. Do not submit patches unless you have read, understood and agreed to the certificate. ​ Please also read the [[https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html|official Linux SubmittingPatches]] documentation,​ especially the **[[https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html#​sign-your-work-the-developer-s-certificate-of-origin|Developer'​s Certificate of Origin]]**. Do not submit patches unless you have read, understood and agreed to the certificate. ​
  
 +
 +===== New driver =====
 +
 +For submitting a new wireless driver the recommendations are:
 +
 +  * follow [[https://​www.kernel.org/​doc/​html/​latest/​process/​coding-style.html|Linux kernel coding style]]
 +  * use one of [[https://​git.kernel.org/​pub/​scm/​linux/​kernel/​git/​torvalds/​linux.git/​tree/​LICENSES/​preferred|preferred licenses]] ​
 +  * use [[https://​www.kernel.org/​doc/​html/​latest/​process/​license-rules.html|SPDX tags]]
 +  * use either cfg80211 or mac80211, depending on the firmware architecture (no custom 802.11 stack in the driver)
 +  * have firmware images available with an acceptable license in [[https://​git.kernel.org/​pub/​scm/​linux/​kernel/​git/​firmware/​linux-firmware.git/​|linux-firmware]]
 +  * for review submit the driver as one file per patch, for easier review
 +    * example: https://​lore.kernel.org/​linux-wireless/​20200623110000.31559-1-ajay.kathat@microchip.com/​
 +  * final commit (after the review) will be one big patch
 +    * for staging drivers the final patch will be just a small moving the driver, example: https://​git.kernel.org/​linus/​5625f965d764
  
 ===== Examples of a patches ===== ===== Examples of a patches =====
Line 242: Line 278:
 ==== Signed-off-by missing ==== ==== Signed-off-by missing ====
  
-Read [[https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html#​sign-your-work-the-developer-s-certificate-of-origin|Developer'​s Certificate of Origin]] and add Signed-off-by ​to the commit log.+Read [[https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html#​sign-your-work-the-developer-s-certificate-of-origin|Developer'​s Certificate of Origin]]. Do not submit patches unless you have read, understood ​and agreed ​to the certificate. 
  
 ==== Format issues ==== ==== Format issues ====
Line 256: Line 293:
 commit log message header line text enclosed in parentheses and commit log message header line text enclosed in parentheses and
 double quotes with no line breaks whatsoever. double quotes with no line breaks whatsoever.
 +The fixes lines must be placed just above the signed-off-by lines.
  
 Example: Example:
Line 336: Line 374:
 More info: http://​www.idallen.com/​topposting.html More info: http://​www.idallen.com/​topposting.html
  
 +==== Do not send HTML mail ====
 +
 +linux-wireless mailing list drops all mail using HTML, so don't use it.
 +
 +==== Use RFC or RFT for patches not ready ====
 +
 +If the patches are not yet ready to be applied by the maintainer, mark them as RFC (Request For Comments) or RFT (Request For Test). This way the maintainer can easily see that the patch should not be applied yet. This saves a lot of maintainer'​s time.
 +
 +==== Use Co-developed-by when multiple authors ​ ====
 +
 +When a patch has multiple authors you should use Co-developed-by tag:
 +
 +https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html#​when-to-use-acked-by-cc-and-co-developed-by
 +
 +==== Maximum of 7-12 patches per patchset ​ ====
 +
 +If you want your patches reviewed smoothly submit maximum of 7-12 patches per patchset. If the patches are bigger don't send more than 7 patches. But if they smaller, or trivial patches, 12 patches is ok. But anything more than 12 patches and you will get reviewers grumpy (read: it takes longer to get your patches reviewed and applied).
 +
 +But you can submit multiple patchsets, just try to throttle it down to avoid bufferbloat in patchwork, for example you can send a new patchset every other day. And don't forget to document the dependencies in the cover letter ("this patchset depends on patchset B").
  
-===== More patch work references =====+===== More references =====
  
 Here is a list of links to help you write better patches ​ Here is a list of links to help you write better patches ​
Line 345: Line 402:
   * [[http://​linux.yyz.us/​patch-format.html|http://​linux.yyz.us/​patch-format.html]] ​   * [[http://​linux.yyz.us/​patch-format.html|http://​linux.yyz.us/​patch-format.html]] ​
   * [[https://​www.ozlabs.org/​~akpm/​stuff/​tpp.txt|Andrew Morton'​s ''​The perfect patch''​]] ​   * [[https://​www.ozlabs.org/​~akpm/​stuff/​tpp.txt|Andrew Morton'​s ''​The perfect patch''​]] ​
 +  * [[http://​lkml.kernel.org/​r/​20171026223701.GA25649@bhelgaas-glaptop.roam.corp.google.com|Make Bjorn'​s life easier (and grease the path of your patch)]]
en/developers/documentation/submittingpatches.txt · Last modified: 2024/02/01 20:12 by Jeff Johnson