Re: [PATCH 1/5] net: fec: properly support external PTP PHY for hardware time stamping

Vladimir Oltean [off-list ref] writes:

On Mon, Jul 06, 2020 at 09:33:30PM +0300, Sergey Organov wrote:

[...]

quoted

I'll then make these 2 changes separate in v2 indeed, though I'm not
aware about Fixes: tag and if I should do something about it. Any clues?

Add these 2 lines to your .gitconfig file:

[pretty]
	fixes = Fixes: %h (\"%s\")

Then use $(git blame) to find the commit which introduced the bad
behavior. I was able to go down back to this commit, which I then tagged
as follows:

git show 6605b730c061f67c44113391e5af5125d0672e99 --pretty=fixes

Then you copy the first line of the generated output to the patch, right
above your Signed-off-by: tag. Like this:

Fixes: 6605b730c061 ("FEC: Add time stamping code and a PTP hardware clock")

Note that the offending commit has been obscured, in the meantime, by
refactoring commit ff43da86c69d ("NET: FEC: dynamtic check DMA desc buff
type"). That doesn't mean that the Fixes: tag should point to the newest
commit touching the code though. In case where the refactoring is recent
though (not this case), Greg will send an email that backporting failed,
and you can send him a follow-up with a patch adjusted for each
individual stable tree where adjustments need to be made. You can also
ignore Greg's email, if you don't care about old stable trees.

In this particular case, the original offending commit and the one
obscuring it were included first in the following kernel tags:

$(git tag --contains 6605b730c061): v3.8
$(git tag --contains ff43da86c69d): v3.9

But, if you look at https://www.kernel.org/, the oldest stable tree
being actively maintained should be 3.16, so v3.8 vs v3.9 shouldn't make
any difference because nobody will try to apply your fix patch to a tree
older than 3.9 anyway.

When sending a bugfix patch, there are 2 options:

- You send the patch to the linux-stable mailing list directly. For
  networking fixes, however, David doesn't prefer this. See below.

- You send the patch to the netdev list (the same list where you sent
  this one), but with --subject-prefix "PATCH net" so that it gets
  applied to a different tree (this one:
  https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git as
  opposed to this one:
  https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git).
  The "net" tree is periodically merged into "net-next". Because your
  patch series will have to be split, there are 2 options: either you
  send your bugfix patches first, wait for them to be merged, and then
  for "net" to be merged into "net-next", or try somehow to make sure
  that the patches for "net" and for "net-next" can be applied in
  parallel without interfering and creating merge conflicts. I think you
  can do the latter.

Whatever you do, however, please be sure to copy Richard Cochran to
PTP-related patches, he tends to have a broader picture of the 1588 work
that is being done throughout the kernel, and can provide more
feedback.

Thanks a lot for thorough explanations and for finding the offensive
commit for me!

I'll then start with sending that separate patch as bug-fix with "PATCH net"
subject prefix, and then will re-send v2 of the series to net-next (with
just "PATCH v2") later, as soon as I collect all the feedback. I expect
no merge conflicts indeed.

Sounds like a plan!

Thanks again,
-- Sergey