Linux Wireless

This is an old revision of the document!

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 ath11k patch review from patchwork:

More info about submitting patches:

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
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 ath11k-check as that will disable the useless warnings.

The ath11k patch flow is the same as ath10k patch flow