Differences

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

--- en:users:drivers:ath10k:submittingpatches [2017/06/14 08:06]
Kalle Valo [Patch flow] Mention about ath-current, add the example from sources page, fix outdated link
+++ en:users:drivers:ath10k:submittingpatches [2020/06/09 12:22]
Kalle Valo Add a section about answering to why
@@ Line 8: / Line 8: @@
       * Cc: [[linux-wireless@vger.kernel.org]]
 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.
+It's important that linux-wireless is CCed on the patches, otherwise it won't be in patchwork and the maintainer won't see it. 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:
         * [[en/developers/Documentation/SubmittingPatches|linux-wireless submitting patches instructions]]
         * [[en/developers/Documentation/git-guide|linux-wireless git guide]]
+        * [[https://www.kernel.org/doc/html/latest/process/submitting-patches.html|Linux kernel submitting patches]]
+        * [[https://medium.com/@steveamaza/how-to-write-a-proper-git-commit-message-e028865e5791|How to write proper git commit messages]]
+        * [[https://lkml.kernel.org/r/20150314075357.GA8319@gmail.com|Ingo Molnar's points about commit logs]]
 ==== Guidelines ====
@@ Line 18: / Line 25: @@
 Guidelines for patches are:
-          * MUST follow [[https://www.kernel.org/doc/html/latest/process/submitting-patches.html|Documentation/SubmittingPatches]]
+  * MUST follow [[https://www.kernel.org/doc/html/latest/process/submitting-patches.html|Documentation/SubmittingPatches]]
-          * MUST be compiler warning free.
+  * MUST follow [[en/users/Drivers/ath10k/CodingStyle|ath10k coding style]]
-          * MUST be sparse warning free.
+  * MUST be compiler and sparse warning free.
-          * Commit log MUST not be empty.
+  * [[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.
-          * The commit log MUST answer the question "Why?":
+  * Patchsets SHOULD contain no more than 12 patches and include a cover letter.
-             * Describe the motivation behind the bug.
+  * Commit log MUST [[#answer_to_why|answer the question "Why?"]].
-             * How does it change the functionality from user's point of view?
+  * The commit log MUST not be empty.
-             * 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.
+  * Commit log MUST document the affected hardware versions, bus type and firmware version(s) tested, examples:
-             * If a problem has been found during code review and doesn't fix a known issues, mention that in the commit log.
+    * QCA988X PCI 10.2.4-1.0-00037
-             * 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.
+    * QCA99X0/QCA9984/QCA4019 PCI/AHB 10.4-3.5.3-00053
-          *   If others have reported the issue commit log SHOULD use Reported-by: and Tested-by: tags.
+    * QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00102-QCARMSWP-1
-          * SHOULD be //mostly// checkpatch clean (though not all patchworks warnings make sense):
+    * QCA9377 SDIO WLAN.TF.1.1.1-00061-QCATFSWPZ-1
-            * Patches SHOULD be sent with git send-email tool.
+  * 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.
-            * Patchsets SHOULD contain no more than 12 patches.
+  * 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.
-            * Patches SHOULD follow [[en/users/Drivers/ath10k/CodingStyle|ath10k coding style]]
+  * 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.
-            * 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]]
+==== Answer to "Why?" ====
+The commit log needs to describe the motivation behind the bug, in other words provide the background information why the patch is needed and why is it needed the way it is.
+  * 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.
+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, read that to understand more about commit logs.
 ==== Patch flow ====

Linux Wireless

User Tools

Site Tools

Differences

Page Tools