Re: [[RFC PATCH v4 net-next] 0/2] net: dsa: hsr: Enable HSR HW offloading for KSZ9477

[Vladimir Oltean <olteanv@gmail.com>]

On Thu, Sep 14, 2023 at 11:18:31PM +0200, Lukasz Majewski wrote:
> As fair as I understood from the commit message - some part of this
> patch needs to be applied before HSR offloading v4.
> 
> Hence I will wait for it to be posted and upstreamed.
> 
> Only then some of this patch code would be squashed to v5 of hsr
> support.

No, this isn't how this is going to work. I can't post my patches and
then you post yours, because that would mean some functionality is
introduced without a user (ds->ops->port_set_mac_address), and we don't
accept that, because you may or may not resubmit your HSR patches as a
first user of the new infra.

So, what needs to happen is you need to post all the patches as an
all-or-nothing series. Somewhere in Documentation/process/ it is
probably explained in more detail what to pay attention to, when reposting
what is partly others' work. But the basic idea is that you need to keep
the Author: and Signed-off-by: fields if you aren't making major changes,
but you must also add your own Signed-off-by: at the end. You also have
responsibility for the patches that you post, and have to respond to
review feedback, even if they aren't authored for you. You are obviously
free to make changes to patches until they pass your own criteria.

The most that I can do to help you is to split that squashed patch and
put the result on a branch:
https://github.com/vladimiroltean/linux/commits/lukma-ksz-hsr-rfc-v4

But it's up to you to take it from there, rebase it on net-next, review
the result, test it, make sure that the changes are something that you
can justify when submitting, etc. You won't be alone if you need help,
of course, but the point is that you're not 100% passive to this activity.