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
en:developers:documentation:submittingpatches [2020/02/13 16:32]
Kalle Valo Add Do not send HTML mail
en:developers:documentation:submittingpatches [2021/02/12 08:22] (current)
Johannes Berg
Line 57: Line 57:
 ===== Subject ===== ===== Subject =====
  
-If what you are sending is a patch you can use a subject as follows: ​+If what you are sending is a patch you should ​use a subject as follows: ​
  
  
Line 81: Line 81:
 If your patch is just a proposal you can mark the patch as RFC in the subject: ​ If your patch is just a proposal you can mark the patch as RFC in the subject: ​
  
-<​code>​[RFC] subsystem: a new way to do foo</​code>​+<​code>​[RFC] subsystem: ​add a new way to do foo</​code>​
  
 If you need to make changes to the patch add a version number inside the brackets: If you need to make changes to the patch add a version number inside the brackets:
Line 94: 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.
 +
 +Subject lines, like commit messages (see below) should be written in imperative voice ("fix foo and optimize bar"), not in any other way such as past tense ("​fixed foo and optimized bar").
 +
 +===== Commit Messages =====
 +
 +Please write commit messages, like mentioned for the subject above, in imperative voice.
 +
 +Commit messages should describe
 +  * why a change was made,
 +  * how it achieves its stated goal, and,
 +  * if applicable, other considerations such as
 +    * alternatives that were considered,
 +    * implications on other code,
 +    * possible security implications,​
 +    * etc.
 +
 +If you find yourself listing out a number of changes in the commit message as a bulleted list or similar, consider splitting up the patch into discrete changes that each do one thing. Similarly, if one of the additional considerations is refactoring,​ try to shift that into a separate patch.
  
 ===== Tree labels ===== ===== Tree labels =====
Line 155: Line 172:
 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 requirements are:
 +
 +  * follow [[https://​www.kernel.org/​doc/​html/​latest/​process/​coding-style.html|Linux kernel coding style]]
 +  * 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 submitted for [[https://​git.kernel.org/​pub/​scm/​linux/​kernel/​git/​firmware/​linux-firmware.git/​|linux-firmware]] with an acceptable license allowing redistribution
 +  * document Device Tree usage in [[https://​www.kernel.org/​doc/​html/​latest/​devicetree/​bindings/​submitting-patches.html|devicetree bindings]] and review them with DT maintainers
 +  * in the commit log/cover letter provide an overview of the driver
 +    * what hardware the driver supports
 +    * what features are supported (client, AP, mesh modes etc)
 +  * for review submit the driver as one file per patch, to make it easier for the reviewers
 +    * 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 patch moving the driver, example: https://​git.kernel.org/​linus/​5625f965d764
 +
 +There'​s also a list of [[https://​git.kernel.org/​pub/​scm/​linux/​kernel/​git/​torvalds/​linux.git/​tree/​LICENSES/​preferred|preferred licenses]] available.
  
 ===== Examples of a patches ===== ===== Examples of a patches =====
Line 264: Line 300:
 ==== 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 372: Line 409:
  
 https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html#​when-to-use-acked-by-cc-and-co-developed-by 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 references ===== ===== More references =====
en/developers/documentation/submittingpatches.1581611560.txt.gz · Last modified: 2020/02/13 16:32 by Kalle Valo