en:users:drivers:ath10k:submittingpatches
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
en:users:drivers:ath10k:submittingpatches [2017/05/16 05:50] Kalle Valo Add go back link |
en:users:drivers:ath10k:submittingpatches [2018/04/13 04:34] Kalle Valo [Guidelines] Add Fixes tag |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| 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-by: tags. | + | * 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.txt · Last modified: 2020/08/26 14:40 by Kalle Valo
Page Tools
