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/10/08 08:36]
Kalle Valo Add a section for new drivers
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 158: Line 175:
 ===== New driver ===== ===== New driver =====
  
-For submitting a new wireless driver the recommendations ​are:+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]]   * 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 [[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)   * 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]] +  * 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 
-  * for review submit the driver as one file per patch, ​for easier ​review+  * 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/​     * example: https://​lore.kernel.org/​linux-wireless/​20200623110000.31559-1-ajay.kathat@microchip.com/​
   * final commit (after the review) will be one big patch   * 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+    * 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 =====
en/developers/documentation/submittingpatches.1602146202.txt.gz · Last modified: 2020/10/08 08:36 by Kalle Valo