User Tools

Site Tools


en:users:drivers:ath10k:sources

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:users:drivers:ath10k:sources [2017/02/19 13:56]
Kalle Valo [Submitting patches] Add link to a page about ath10k-check
en:users:drivers:ath10k:sources [2017/06/13 15:59]
Kalle Valo [Git branches] Try to clarify more about the differences between -current and -next
Line 1: Line 1:
-o 
 Go back --> [[en/​users/​Drivers/​ath10k|ath10k]] ​ Go back --> [[en/​users/​Drivers/​ath10k|ath10k]] ​
  
    
-===== ath10k sources ​location ​=====+===== ath10k sources =====
  
 //ath10k// development happens in Kalle Valo's ath.git tree on kernel.org: ​ //ath10k// development happens in Kalle Valo's ath.git tree on kernel.org: ​
Line 19: Line 18:
 https://​git.kernel.org/​cgit/​linux/​kernel/​git/​kvalo/​ath.git/​tree/​drivers/​net/​wireless/​ath/​ath10k https://​git.kernel.org/​cgit/​linux/​kernel/​git/​kvalo/​ath.git/​tree/​drivers/​net/​wireless/​ath/​ath10k
  
-Periodically Kalle Valo pulls the ath tree into wireless-drivers-next tree. Then David Miller ​pulls it to net-next which is eventually ​pulled ​by Linus Torvalds to official kernel releases. As a rough estimate it takes 2-4 months for a patch to propage from ath.git to an official Linux release.+Periodically Kalle Valo merges ​ath-next and ath-current branches from ath.git ​into wireless-drivers-next ​and wireless-drivers ​tree, respectively. Then David Miller ​merges them to net-next ​and net trees, respectively, ​which are eventually ​merged ​by Linus Torvalds to the official kernel releases. ​
  
 +As a rough estimate it takes patches in ath-next 2-4 months to propagate from ath.git to the next official Linux release and patches from ath-current 1-3 weeks to propagate to the next -rc release.
  
-===== Submitting patches ===== +See also [[en/users/drivers/ath10k/submittingpatches|submitting ​ath10k 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.  +
-      * To: [[mailto:​ath10k@lists.infradead.org|ath10k@lists.infradead.org]]  +
-      * Cc: [[mailto:​linux-wireless@vger.kernel.org|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.  +
- +
-More info about submitting patches:  +
-        * [[en/​developers/​Documentation/​SubmittingPatches|en/​developers/​Documentation/​SubmittingPatches]]  +
-        * [[en/​developers/​Documentation/​git-guide|en/​developers/​Documentation/​git-guide]]  +
- +
-Guidelines for patches:  +
-          * MUST follow [[https://​www.kernel.org/​doc/​Documentation/​SubmittingPatches|Documentation/​SubmittingPatches]] +
-          * MUST be compiler warning free.  +
-          * MUST be sparse warning free.  +
-          * Commit log MUST not be empty.  +
-          * The commit log MUST answer the question "​Why?":​  +
-             * Describe the motivation behind the bug.  +
-             * How does it change the functionality from user's point of view?  +
-             * 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.  +
-             * If a problem has been found during code review and doesn'​t fix a known issues, mention that in the commit log. +
-             * 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.  +
-          *   If others have reported the issue commit log SHOULD use Reported-by:​ and Tested-by: tags.  +
-          *   ​SHOULD be checkpatch clean:  +
-          *     ​Patches SHOULD be sent with git send-email tool.  +
-          *     ​Patchsets SHOULD contain no more than 12 patches.  +
-          *     ​Patches SHOULD follow ​[[en/users/Drivers/ath10k/CodingStyle|ath10k ​coding style]]  +
-          *     ​It'​s RECOMMENDED to test patches ​with [[en/​users/​Drivers/​ath10k/​CodingStyle#​checking_code|ath10k-check]]  +
- +
-The terminology is from [[http://​www.ietf.org/​rfc/​rfc2119.txt|http://​www.ietf.org/​rfc/​rfc2119.txt]]  +
- +
-The ath10k patch flow is this:  +
-          * Patch gets posted to the mailing lists.  +
-          * Kalle immediately applies the patch to pending branch for build testing.  +
-          * Kalle waits 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.  +
-          * Kalle merges ath-next to master branch immeadiately after the patch is applies.  +
-          * Kalle merges ath-next into wireless-drivers-next roughly every 2-3 weeks  +
-          * David Miller merges wireless-drivers-next into net-next 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]]  +
  
 ===== Git branches ===== ===== Git branches =====
Line 69: Line 28:
 ath.git contains multiple branches: ​ ath.git contains multiple branches: ​
  
-  * master ​ : The default branch selected when cloning the tree. Everyone working on ath10k ​(or ath6kl) should use this branch. Follows ​John Linville's wireless-testing tree and contains the latest -rc release from Linus Torvalds + latest wireless ​code from John + latest ​ath10k/​ath6kl code from ath-next ​branchUsually the branch is rebased ​after a merge window (after -rc1 is released). Due to unclean history bisect ​might not work, better to use ath-next for bisecting.  +  ​* **master:** The default branch selected when cloning the tree. Everyone working on any ath drivers ​(ath10k, ath9k, ​ath6kl ​etc) should use this branch ​as the baseline for patches. Follows ​Bob Copeland's wireless-testing tree and contains the latest -rc release from Linus Torvalds + latest wireless + latest ​ath patches  ​from ath-next ​and ath-current branchesThe branch is rebased ​every time it's updated. Due to unclean history bisect ​will not work, better to use ath-next ​(or ath-current) ​for bisecting.  
-  * ath-next ​ : Based on John's wireless-next tree and John will pull from this branchath6kl/​ath10k ​patches are commited to this branch first and then merged to the master branch. For bisect runs it's better to use this branch instead of the master branch.  +  ​* **ath-next:** Based on Kalle's wireless-drivers-next tree and will be periodically merged to wireless-drivers-next and scheduled for the next release under works (not for the current -rc releases)ath patches are commited to this branch first and then merged to the master branch. For bisect runs it's better to use this branch instead of the master ​branch. All patches adding new features or low priority fixes go to this branch. 
-  * pending ​ : Used for building and runtime testing patches under review. Is rebased almost daily and hence commit ids are NOT stable. Use this only if you know what you are doing.  +  * **ath-current:​** Based on Kalle'​s wireless-drivers tree and will be periodically merged to wireless-drivers and scheduled for the current release under works (for the upcoming -rc release). Only critical fixes. 
-  * master-pending ​ : The pending branch merged on top of the master, for easier testing of the pending patches. Same rules apply as with the pending branch.+  * **pending:** Used for building and runtime testing patches under review. Is rebased almost daily and hence commit ids are NOT stable. Use this only if you know what you are doing.  
 +  ​* **master-pending:​** The pending branch merged on top of the master, for easier testing of the pending patches. Same rules apply as with the pending branch
 + 
 +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 it will be in v4.10-rc1.
en/users/drivers/ath10k/sources.txt · Last modified: 2021/03/06 06:06 by Kalle Valo