Sidebar
This is an old revision of the document!
Table of Contents
Go back –> ath10k
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.
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.
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:
Guidelines
Guidelines for patches are:
- MUST follow Documentation/SubmittingPatches
- MUST follow ath10k coding style
- MUST be compiler and sparse warning free.
- git send-email SHOULD be used to submit the patch to avoid any formatting issues.
- Patchsets SHOULD contain no more than 12 patches and include a cover letter.
- 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 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.
- 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.
- This also implies that the commit log MUST not be empty.
- Ingo Molnar has written a nice description about what maintainers are looking from a commit log.
- 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 Reported-by: and Tested-by: tags if others have reported the issue.
- SHOULD use 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 ath10k-check as that will disable the useless warnings.
The terminology is from http://www.ietf.org/rfc/rfc2119.txt
Patch flow
The ath10k patch flow is this:
- Patch gets posted to the mailing lists.
- Kalle applies ASAP (usually can take 1-3 business days) the patch to pending and master-pending branches for build testing.
- 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 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 and ath-current to master branch immeadiately after the patch is applied.
- 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 tree and wireless-drivers to net tree every two weeks or so.
- Linus Torvalds merges net every week and net-next during 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 ath10k sources and branches.
