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

[Sergey Organov]

Vladimir Oltean <olteanv@xxxxxxxxx> writes:

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

[...]

>
>> 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