User Tools

Site Tools


en:users:drivers:ath10k:submittingpatches

Differences

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

Link to this comparison view

Next revision
Previous revision
en:users:drivers:ath10k:submittingpatches [2017/05/16 05:29]
Kalle Valo refactor submitting patches section from sources page to it's own page
en:users:drivers:ath10k:submittingpatches [2018/04/13 04:34] (current)
Kalle Valo [Guidelines] Add Fixes tag
Line 1: Line 1:
 +Go back --> [[en/​users/​Drivers/​ath10k]] ​
 +
 +
 ===== Submitting patches ===== ===== Submitting patches =====
  
 Send patches to the mailing lists below. Kalle Valo reviews the patches within the next few days and, if they are ok, commits them to ath.git. ​ Send patches to the mailing lists below. Kalle Valo reviews the patches within the next few days and, if they are ok, commits them to ath.git. ​
-      * To: [[mailto:​ath10k@lists.infradead.org|ath10k@lists.infradead.org]]  +      * To: [[ath10k@lists.infradead.org]]  
-      * Cc: [[mailto:​linux-wireless@vger.kernel.org|linux-wireless@vger.kernel.org]] ​+      * Cc: [[linux-wireless@vger.kernel.org]] ​
  
-Preferably use ath.git master branch as the baseline for patches. Other trees can be used as well, but then the chances of conflicts are higher. ​+Preferably use [[en/​users/​drivers/​ath10k/​sources|ath.git master branch]] as the baseline for patches. Other trees can be used as well, but then the chances of conflicts are higher. 
 + 
 +You can follow the state of ath10k patch review from patchwork:​ 
 + 
 +[[https://​patchwork.kernel.org/​project/​linux-wireless/​list/?​state=*&​q=ath10k]]
  
 More info about submitting patches: ​ More info about submitting patches: ​
-        * [[en/​developers/​Documentation/​SubmittingPatches|en/​developers/​Documentation/​SubmittingPatches]]  +        * [[en/​developers/​Documentation/​SubmittingPatches|linux-wireless submitting patches instructions]]  
-        * [[en/​developers/​Documentation/​git-guide|en/​developers/​Documentation/​git-guide]] ​+        * [[en/​developers/​Documentation/​git-guide|linux-wireless ​git guide]] ​
  
-Guidelines for patches:  +==== Guidelines ==== 
-          * MUST follow [[https://​www.kernel.org/​doc/​Documentation/SubmittingPatches|Documentation/​SubmittingPatches]] + 
-          * MUST be compiler warning free.  +Guidelines for patches ​are
-          * MUST be sparse warning free.  +  
-          Commit log MUST not be empty.  +  ​* MUST follow [[https://​www.kernel.org/​doc/​html/latest/​process/​submitting-patches.html|Documentation/​SubmittingPatches]] 
-          The commit ​log MUST answer the question "​Why?":​  +  * MUST follow [[en/​users/​Drivers/​ath10k/​CodingStyle|ath10k coding style]] 
-             ​* Describe the motivation behind the bug.  +  * MUST be compiler and sparse warning free.  
-             ​* How does it change the functionality from user's point of view?  +  [[https://​www.kernel.org/​pub/​software/​scm/​git/​docs/​git-send-email.html|git send-email]] SHOULD ​be used to submit the patch to avoid any formatting issues
-             ​* Does it fix a bug? If it does, please describe the bug (doesn'​t need to be long). Also if there'​s a public bug report add a link to the bug report.  +  Patchsets SHOULD contain no more than 12 patches and include a cover letter.  
-             ​* If a problem has been found during code review and doesn'​t fix a known issues, mention that in the commit log. +  * Commit ​log MUST answer the question "​Why?":​  
-             ​* Ingo Molnar has written [[https://​lkml.kernel.org/​g/​20150314075357.GA8319@gmail.com|a nice description]] about what maintainers are looking from a commit log.  +    * Describe the motivation behind the bug.  
-            If others have reported ​the issue commit log SHOULD use Reported-by: ​and Tested-bytags.  +    * How does it change the functionality from user's point of view?  
-            SHOULD be checkpatch clean: ​ +    * Does it fix a bug? If it does, please describe the bug (doesn'​t ​necessarily ​need to be long). Also if there'​s a public bug report add a link to the bug report ​or email describing the issue.  
-              Patches SHOULD be sent with git send-email tool.  +    * If a problem has been found during code review and doesn'​t fix a known issue, mention that in the commit log this is a theoretical fix. 
-              Patchsets ​SHOULD ​contain no more than 12 patches.  +    * This also implies that the commit log MUST not be empty.  
-              Patches ​SHOULD ​follow ​[[en/users/Drivers/ath10k/CodingStyle|ath10k coding style]]  +    * Ingo Molnar has written [[https://​lkml.kernel.org/​r/​20150314075357.GA8319@gmail.com|a nice description]] about what maintainers are looking from a commit log. 
-              It's RECOMMENDED to test patches with [[en/​users/​Drivers/​ath10k/​CodingStyle#​checking_code|ath10k-check]] ​+  Commit log MUST document ​the affected hardware versions, bus type and firmware version(s) tested, examples: 
 +    * QCA988X PCI 10.2.4-1.0-00037 
 +    QCA99X0/​QCA9984/​QCA4019 PCI/AHB 10.4-3.5.3-00053 
 +    QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00102-QCARMSWP-1 
 +    * QCA9377 SDIO WLAN.TF.1.1.1-00061-QCATFSWPZ-1 
 +  * SHOULD ​use [[https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html#​using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes|Reported-by:​ and Tested-by: tags]] if others have reported the issue
 +  * SHOULD ​use [[https://www.kernel.org/doc/html/​latest/​process/​submitting-patches.html#​describe-changes|Fixes: tag]] if it fixes a regression caused by known commit. 
 +  SHOULD be //mostly// checkpatch clean (though not all patchworks warnings make sense), it's RECOMMENDED to test patches with [[en/​users/​Drivers/​ath10k/​CodingStyle#​checking_code|ath10k-check]] ​as that will disable the useless warnings.
  
 The terminology is from [[http://​www.ietf.org/​rfc/​rfc2119.txt|http://​www.ietf.org/​rfc/​rfc2119.txt]] ​ The terminology is from [[http://​www.ietf.org/​rfc/​rfc2119.txt|http://​www.ietf.org/​rfc/​rfc2119.txt]] ​
 +
 +==== Patch flow ====
  
 The ath10k patch flow is this:  The ath10k patch flow is this: 
           * Patch gets posted to the mailing lists. ​           * Patch gets posted to the mailing lists. ​
-          * Kalle immediately ​applies the patch to pending ​branch ​for build testing.  +          * Kalle applies ​ASAP (usually can take 1-3 business days) the patch to pending ​and master-pending branches ​for build testing.  
-          * Kalle waits two business days for patch being under review (unless the patch is urgent).  +          * Kalle waits minimum of two business days for patch being under review (unless the patch is urgent).  
-          * If no comments or warnings, Kalle applies the patch to ath-next branch and sends a "​Thanks,​ applied"​ reply.  +          * If no comments or warnings, Kalle applies the patch either to ath-current branch (for critical fixes) or to ath-next branch ​(new features, low priority fixes) ​and sends a "​Thanks,​ applied"​ reply.  
-          * Kalle merges ath-next to master branch immeadiately after the patch is applies.  +          * Kalle merges ath-next ​and ath-current ​to master branch immeadiately after the patch is applied.  
-          * Kalle merges ath-next into wireless-drivers-next roughly every 2-3 weeks  +          * Kalle merges ath-next into wireless-drivers-next ​tree and ath-current to wireless-drivers tree roughly every 2-3 weeks. 
-          * David Miller merges wireless-drivers-next into net-next every two weeks or so  +          * David Miller merges wireless-drivers-next into net-next ​tree and wireless-drivers to net tree every two weeks or so. 
-          * Linus Torvalds merges net-next ​into linux.git ​during [[https://​www.kernel.org/​doc/​Documentation/development-process/​2.Process|merge window]] ​+          * Linus Torvalds merges ​net every week and net-next during [[https://​www.kernel.org/​doc/​html/latest/​process/​2.Process.html|the merge window]] ​into linux.git .  
 + 
 +As a rough estimate it takes 2-4 months for a patch to propagate from ath-next to an official Linux release.
  
 +To clarify the meaning with ath-current and ath-next let's take a concrete example: let's say that the latest release from Linux is v4.9-rc2. If a patch is applied to ath-current it will most like be in v4.9-rc4 or v4.9-rc5 (usually it takes a minimum of one week to get to Linus' tree, sometimes more). But if the patch is applied to ath-next the first release it will be in is v4.10-rc1.
  
 +See also [[en/​users/​drivers/​ath10k/​sources|ath10k sources and branches]].
en/users/drivers/ath10k/submittingpatches.1494912547.txt.gz · Last modified: 2017/05/16 05:29 by Kalle Valo