Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   2) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   3) .. _netdev-FAQ:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   4) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   5) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   6) netdev FAQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   7) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   8) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   9) Q: What is netdev?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  10) ------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  11) A: It is a mailing list for all network-related Linux stuff.  This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  12) includes anything found under net/ (i.e. core code like IPv6) and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  13) drivers/net (i.e. hardware specific drivers) in the Linux source tree.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  14) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  15) Note that some subsystems (e.g. wireless drivers) which have a high
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  16) volume of traffic have their own specific mailing lists.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  17) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  18) The netdev list is managed (like many other Linux mailing lists) through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  19) VGER (http://vger.kernel.org/) and archives can be found below:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  20) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  21) -  http://marc.info/?l=linux-netdev
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  22) -  http://www.spinics.net/lists/netdev/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  23) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  24) Aside from subsystems like that mentioned above, all network-related
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  25) Linux development (i.e. RFC, review, comments, etc.) takes place on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  26) netdev.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  27) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  28) Q: How do the changes posted to netdev make their way into Linux?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  29) -----------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  30) A: There are always two trees (git repositories) in play.  Both are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  31) driven by David Miller, the main network maintainer.  There is the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  32) ``net`` tree, and the ``net-next`` tree.  As you can probably guess from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  33) the names, the ``net`` tree is for fixes to existing code already in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  34) mainline tree from Linus, and ``net-next`` is where the new code goes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  35) for the future release.  You can find the trees here:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  36) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  37) - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  38) - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  39) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  40) Q: How often do changes from these trees make it to the mainline Linus tree?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  41) ----------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  42) A: To understand this, you need to know a bit of background information on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  43) the cadence of Linux development.  Each new release starts off with a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  44) two week "merge window" where the main maintainers feed their new stuff
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  45) to Linus for merging into the mainline tree.  After the two weeks, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  46) merge window is closed, and it is called/tagged ``-rc1``.  No new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  47) features get mainlined after this -- only fixes to the rc1 content are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  48) expected.  After roughly a week of collecting fixes to the rc1 content,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  49) rc2 is released.  This repeats on a roughly weekly basis until rc7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  50) (typically; sometimes rc6 if things are quiet, or rc8 if things are in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  51) state of churn), and a week after the last vX.Y-rcN was done, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  52) official vX.Y is released.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  53) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  54) Relating that to netdev: At the beginning of the 2-week merge window,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  55) the ``net-next`` tree will be closed - no new changes/features.  The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  56) accumulated new content of the past ~10 weeks will be passed onto
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  57) mainline/Linus via a pull request for vX.Y -- at the same time, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  58) ``net`` tree will start accumulating fixes for this pulled content
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  59) relating to vX.Y
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  60) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  61) An announcement indicating when ``net-next`` has been closed is usually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  62) sent to netdev, but knowing the above, you can predict that in advance.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  63) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  64) IMPORTANT: Do not send new ``net-next`` content to netdev during the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  65) period during which ``net-next`` tree is closed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  66) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  67) Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  68) tree for ``net-next`` reopens to collect content for the next (vX.Y+1)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  69) release.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  70) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  71) If you aren't subscribed to netdev and/or are simply unsure if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  72) ``net-next`` has re-opened yet, simply check the ``net-next`` git
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  73) repository link above for any new networking-related commits.  You may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  74) also check the following website for the current status:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  75) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  76)   http://vger.kernel.org/~davem/net-next.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  77) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  78) The ``net`` tree continues to collect fixes for the vX.Y content, and is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  79) fed back to Linus at regular (~weekly) intervals.  Meaning that the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  80) focus for ``net`` is on stabilization and bug fixes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  81) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  82) Finally, the vX.Y gets released, and the whole cycle starts over.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  83) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  84) Q: So where are we now in this cycle?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  85) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  86) Load the mainline (Linus) page here:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  87) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  88)   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  89) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  90) and note the top of the "tags" section.  If it is rc1, it is early in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  91) the dev cycle.  If it was tagged rc7 a week ago, then a release is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  92) probably imminent.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  93) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  94) Q: How do I indicate which tree (net vs. net-next) my patch should be in?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  95) -------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  96) A: Firstly, think whether you have a bug fix or new "next-like" content.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  97) Then once decided, assuming that you use git, use the prefix flag, i.e.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  98) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  99) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)   git format-patch --subject-prefix='PATCH net-next' start..finish
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) Use ``net`` instead of ``net-next`` (always lower case) in the above for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) bug-fix ``net`` content.  If you don't use git, then note the only magic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) in the above is just the subject text of the outgoing e-mail, and you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) can manually change it yourself with whatever MUA you are comfortable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) with.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) Q: I sent a patch and I'm wondering what happened to it?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) --------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) Q: How can I tell whether it got merged?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) A: Start by looking at the main patchworks queue for netdev:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)   https://patchwork.kernel.org/project/netdevbpf/list/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) The "State" field will tell you exactly where things are at with your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) patch.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) Q: The above only says "Under Review".  How can I find out more?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) ----------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) A: Generally speaking, the patches get triaged quickly (in less than
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) 48h).  So be patient.  Asking the maintainer for status updates on your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) patch is a good way to ensure your patch is ignored or pushed to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) bottom of the priority list.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) Q: I submitted multiple versions of the patch series
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) ----------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) Q: should I directly update patchwork for the previous versions of these
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) patch series?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) A: No, please don't interfere with the patch status on patchwork, leave
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) it to the maintainer to figure out what is the most recent and current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) version that should be applied. If there is any doubt, the maintainer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) will reply and ask what should be done.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) Q: I made changes to only a few patches in a patch series should I resend only those changed?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) ---------------------------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) A: No, please resend the entire patch series and make sure you do number your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) patches such that it is clear this is the latest and greatest set of patches
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) that can be applied.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) Q: I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) -------------------------------------------------------------------------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) A: There is no revert possible, once it is pushed out, it stays like that.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) Please send incremental versions on top of what has been merged in order to fix
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) the patches the way they would look like if your latest patch series was to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) merged.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) Q: Are there special rules regarding stable submissions on netdev?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) ---------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) While it used to be the case that netdev submissions were not supposed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) to carry explicit ``CC: stable@vger.kernel.org`` tags that is no longer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) the case today. Please follow the standard stable rules in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) and make sure you include appropriate Fixes tags!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) Q: Is the comment style convention different for the networking content?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) ------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) A: Yes, in a largely trivial way.  Instead of this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159)   /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)    * foobar blah blah blah
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)    * another line of text
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)    */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) it is requested that you make it look like this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)   /* foobar blah blah blah
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)    * another line of text
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)    */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) Q: I am working in existing code that has the former comment style and not the latter.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) --------------------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) Q: Should I submit new code in the former style or the latter?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) A: Make it the latter style, so that eventually all code in the domain
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) of netdev is of this format.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) Q: I found a bug that might have possible security implications or similar.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) ---------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) Q: Should I mail the main netdev maintainer off-list?**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) A: No. The current netdev maintainer has consistently requested that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) people use the mailing lists and not reach out directly.  If you aren't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) OK with that, then perhaps consider mailing security@kernel.org or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) as possible alternative mechanisms.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) Q: What level of testing is expected before I submit my change?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) ---------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) A: If your changes are against ``net-next``, the expectation is that you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) have tested by layering your changes on top of ``net-next``.  Ideally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) you will have done run-time testing specific to your change, but at a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) minimum, your changes should survive an ``allyesconfig`` and an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) ``allmodconfig`` build without new warnings or failures.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) Q: How do I post corresponding changes to user space components?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) ----------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) A: User space code exercising kernel features should be posted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) alongside kernel patches. This gives reviewers a chance to see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) how any new interface is used and how well it works.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) When user space tools reside in the kernel repo itself all changes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) should generally come as one series. If series becomes too large
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) or the user space project is not reviewed on netdev include a link
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) to a public repo where user space patches can be seen.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) In case user space tooling lives in a separate repository but is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) reviewed on netdev  (e.g. patches to `iproute2` tools) kernel and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) user space patches should form separate series (threads) when posted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) to the mailing list, e.g.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)   [PATCH net-next 0/3] net: some feature cover letter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)    └─ [PATCH net-next 1/3] net: some feature prep
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)    └─ [PATCH net-next 2/3] net: some feature do it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)    └─ [PATCH net-next 3/3] selftest: net: some feature
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)   [PATCH iproute2-next] ip: add support for some feature
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) Posting as one thread is discouraged because it confuses patchwork
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) (as of patchwork 2.2.2).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) Q: Any other tips to help ensure my net/net-next patch gets OK'd?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) -----------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) A: Attention to detail.  Re-read your own work as if you were the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) reviewer.  You can start with using ``checkpatch.pl``, perhaps even with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) the ``--strict`` flag.  But do not be mindlessly robotic in doing so.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) If your change is a bug fix, make sure your commit log indicates the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) end-user visible symptom, the underlying reason as to why it happens,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) and then if necessary, explain why the fix proposed is the best way to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) get things done.  Don't mangle whitespace, and as is common, don't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) mis-indent function arguments that span multiple lines.  If it is your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) first patch, mail it to yourself so you can test apply it to an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) unpatched tree to confirm infrastructure didn't mangle it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) Finally, go back and read
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) to be sure you are not repeating some common mistake documented there.