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 [2022/05/18 05:13]
Kalle Valo [Commit title is wrong] should be informative and unique
en:developers:documentation:submittingpatches [2024/02/01 20:12] (current)
Jeff Johnson [Who to address] add ath12k
Line 32: Line 32:
 Where [[en/​developers/​maintainers|Maintainers]] contains the list of maintainers and mailing lists for the piece of code you are patching. //Other Developers//​ in this case can be a list of developers (or mailing lists) who you think may like to review this patch or who changed the code you are working on recently. ​ Where [[en/​developers/​maintainers|Maintainers]] contains the list of maintainers and mailing lists for the piece of code you are patching. //Other Developers//​ in this case can be a list of developers (or mailing lists) who you think may like to review this patch or who changed the code you are working on recently. ​
  
-Do note that drivers might have special requirements,​ the best is to check them from the corresponding wiki page. Here's a list for few of them:+Do note that drivers might have special requirements,​ the best is to check them from the corresponding wiki page. Here's a list for few of them:
  
   * [[en/​users/​drivers/​ath10k/​submittingpatches|ath10k]]   * [[en/​users/​drivers/​ath10k/​submittingpatches|ath10k]]
   * [[en/​users/​drivers/​ath11k/​submittingpatches|ath11k]]   * [[en/​users/​drivers/​ath11k/​submittingpatches|ath11k]]
 +  * [[en/​users/​drivers/​ath11k/​submittingpatches|ath12k]]
 ===== Checking state of patches from patchwork ===== ===== Checking state of patches from patchwork =====
  
Line 62: Line 63:
  
  
-<​code>​[PATCH] subsystem: fix foo and optimize bar</​code>​+<​code>​[PATCH] ​wifi: subsystem: fix foo and optimize bar</​code>​ 
 + 
 +Starting from 2022 we prefix all wireless patch titles with "wifi: ".
  
 In case of wireless patches the subsystem can for example be ''​mac80211'',​ ''​cfg80211''​ or the name of the driver, for example ''​ath9k''​. There'​s an easy way to check with git what prefix you should use: In case of wireless patches the subsystem can for example be ''​mac80211'',​ ''​cfg80211''​ or the name of the driver, for example ''​ath9k''​. There'​s an easy way to check with git what prefix you should use:
Line 83: Line 86:
 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: add a new way to do foo</​code>​+<​code>​[RFC] ​wifi: 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:
  
-<​code>​[PATCH v2] subsystem: fix foo and optimize bar +<​code>​[PATCH v2] wifi: subsystem: fix foo and optimize bar 
-[PATCH v3] subsystem: fix foo and optimize bar +[PATCH v3] wifi: subsystem: fix foo and optimize bar 
-[PATCH v4] subsystem: fix foo and optimize bar</​code>​+[PATCH v4] wifi: subsystem: fix foo and optimize bar</​code>​
  
 **Always** increase the version number, no matter how small the change is. The maintainers focus on the latest version and ignore the older versions. Make sure that the maintainers don't need to guess what version he should take, that just creates problems. **Always** increase the version number, no matter how small the change is. The maintainers focus on the latest version and ignore the older versions. Make sure that the maintainers don't need to guess what version he should take, that just creates problems.
Line 120: Line 123:
 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: 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>​+<​code>​[PATCH 4.20] wifi: 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: 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>​+<​code>​[PATCH -next] ​wifi: 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: Alternatively you can specify the exact tree you are targetting by adding the name of the git tree inside PATCH brackets:
  
-<​code>​[PATCH wireless] mac80211: fix foo +<​code>​[PATCH wireless] ​wifi: mac80211: fix foo 
-[PATCH wireless-next] mac80211: implement very-cool-feature +[PATCH wireless-next] ​wifi: mac80211: implement very-cool-feature 
-[PATCH wireless] ath10k: fix foo +[PATCH wireless] ​wifi: ath10k: fix foo 
-[PATCH wireless-next] ath10k: implement awesome-feature+[PATCH wireless-next] ​wifi: ath10k: implement awesome-feature
 </​code>​ </​code>​
  
Line 142: Line 145:
  
  
-<​code>​[PATCH 0/4] driver_name:​ introduce foo and bar +<​code>​[PATCH 0/4] wifi: driver_name:​ introduce foo and bar 
-[PATCH 1/4] driver_name:​ introduce get_foo_bars() +[PATCH 1/4] wifi: driver_name:​ introduce get_foo_bars() 
-[PATCH 2/4] driver_name:​ fix locking on bar_by_foo() +[PATCH 2/4] wifi: driver_name:​ fix locking on bar_by_foo() 
-[PATCH 3/4] driver_name:​ use foo when barring +[PATCH 3/4] wifi: driver_name:​ use foo when barring 
-[PATCH 4/4] driver_name:​ optimize bar at init time</​code>​ +[PATCH 4/4] wifi: driver_name:​ optimize bar at init time</​code>​ 
-On the e-mail with subject, "​[PATCH 0/4] driver_name:​ introduce foo and bar", you would give a brief overview of all the changes. No patch should be included in that e-mail, and as that e-mail will not end up in the change logs it should not contain anything that should be archived, only a rough overview over the purpose of the patch set, no in-depth description which should be in the changelog for each patch. ​+On the e-mail with subject, "​[PATCH 0/4] wifi: driver_name:​ introduce foo and bar", you would give a brief overview of all the changes. No patch should be included in that e-mail, and as that e-mail will not end up in the change logs it should not contain anything that should be archived, only a rough overview over the purpose of the patch set, no in-depth description which should be in the changelog for each patch. ​
  
  
Line 210: Line 213:
 To: John Linville To: John Linville
 Cc: linux-wireless,​ Bcm43xx-dev,​ Larry Finger Cc: linux-wireless,​ Bcm43xx-dev,​ Larry Finger
-Subject: [PATCH] b43: Remove the "radio hw enabled"​ message on startup.+Subject: [PATCH] ​wifi: b43: Remove the "radio hw enabled"​ message on startup.
  
 This message is useless. Only report state changes. This message is useless. Only report state changes.
Line 248: Line 251:
 To: John Linville To: John Linville
 Cc: linux-wireless,​ Michael Wu, Johannes Berg, Daniel Drake, Larry Finger Cc: linux-wireless,​ Michael Wu, Johannes Berg, Daniel Drake, Larry Finger
-Subject: [PATCH 3/5] Wireless: add IEEE-802.11 regualtory domain module+Subject: [PATCH 3/5] wifi: add IEEE-802.11 regualtory domain module
  
 This adds the regulatory domain module. It provides a way to This adds the regulatory domain module. It provides a way to
Line 289: Line 292:
 If you send a new version of the patch or patchset you should always add a version number. The first version does not need to be shown but starting from second version the version number must be available: If you send a new version of the patch or patchset you should always add a version number. The first version does not need to be shown but starting from second version the version number must be available:
  
-  [PATCH] ath10k: fix DMA allocation +  [PATCH] ​wifi: ath10k: fix DMA allocation 
-  [PATCH v2] ath10k: fix DMA allocation +  [PATCH v2] wifi: ath10k: fix DMA allocation 
-  [PATCH v3] ath10k: fix DMA allocation+  [PATCH v3] wifi: ath10k: fix DMA allocation
   ...   ...
-  [PATCH v11] ath10k: fix DMA allocation+  [PATCH v11] wifi: ath10k: fix DMA allocation
  
 You can add the version with switch ''​--subject-prefix'':​ You can add the version with switch ''​--subject-prefix'':​
Line 366: Line 369:
  
 The correct format for the commit title is name of driver, followed by a colon, followed by a space and then followed by the actual title. Also the title should be informative and unique, so something like "fix a bug" is not a good title. The correct format for the commit title is name of driver, followed by a colon, followed by a space and then followed by the actual title. Also the title should be informative and unique, so something like "fix a bug" is not a good title.
 +
 +In 2022 we started using "wifi: " in front of all wireless patches.
  
 For examples uou can use ''​git log''​ to check older commits and see what prefix was used: For examples uou can use ''​git log''​ to check older commits and see what prefix was used:
Line 426: Line 431:
 Examples: Examples:
  
-  [PATCH RFC] ath11k: enable power save mode always +  [PATCH RFC] wifi: ath11k: enable power save mode always 
-  [PATCH RFT] ath10k: sdio: always use DMA transfers+  [PATCH RFT] wifi: ath10k: sdio: always use DMA transfers
  
  
en/developers/documentation/submittingpatches.1652850800.txt.gz · Last modified: 2022/05/18 05:13 by Kalle Valo