Message-ID: <87ilb7qxzu.fsf@nvidia.com>
Date:   Wed, 28 Jun 2023 10:48:21 -0700
From:   Rahul Rameshbabu <rrameshbabu@...dia.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, Richard Cochran <richardcochran@...il.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Saeed Mahameed <saeed@...nel.org>,
        Gal Pressman <gal@...dia.com>,
        "David S. Miller" <davem@...emloft.net>,
        lkft-triage@...ts.linaro.org, LTP List <ltp@...ts.linux.it>,
        Nathan Chancellor <nathan@...nel.org>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        Linux Kernel Functional Testing <lkft@...aro.org>
Subject: Re: [PATCH net v1] ptp: Make max_phase_adjustment sysfs device
 attribute invisible when not supported

On Wed, 28 Jun, 2023 16:35:41 +0200 Andrew Lunn <andrew@...n.ch> wrote:
>> > I also wounder if this really is something for net. How do you think
>> > this patch matches against the stable rules?
>> 
>> Apologize in advance but not sure I am following along. The commit for
>> the patch the introduces the problematic logic has made its way to net
>> and this patch is a fix. Therefore, isn't net the right tree to target?
>
> Humm. So c3b60ab7a4df is in net-next, and the tag net-next-6.5. So it
> was passed to Linus yesterday for merging. You would like this fix
> merged either before -rc1, or just after -rc1.

It can be after -rc1. I understand your point now from this elaboration.
Since the change is not heading towards a final release yet but a
release candidate, it's not an "urgent" patch to be applied before -rc1.

>
> We are in the grey area where it is less clear which tree it should be
> against. So it is good to explain after the --- what your intention
> is, so the Maintainers get a heads up and understand what you are
> trying to achieve.

Agreed, I could have used git notes for that in my patch generation.
Noted for the future. Just to be clear, my intention is for this fix to
make its way before the final 6.5 release (before the changes make their
way to an end user since the NULL pointer dereference when reading that
sysfs node from a PHC not supporting phase adjustment is problematic). I
think the issue being present in a release candidate is a minor problem.
Would I still keep the Fixes tag however if targeting net-next? I
remember this email from Jakub where if a Fixes tag is used, the patch
should end up in net rather than net-next. However, I fear that without
a Fixes tag, targeting net-next would cause me to miss applying this
fix before the 6.5 release.

Link: https://lore.kernel.org/netdev/20230607091909.321fc5d7@kernel.org/

----- BEGIN QUOTE -----
  We'll obviously apply our own judgment but submitter should send all
  fixes against net.
------ END QUOTE ------

I personally think this fix is "worthy" of targeting net based on the
discussion Jakub previously provided, given the impact of reading the
sysfs node on a system without this patch on PHCs that do not support
phase adjustment.

>
> I actually thought you were trying to fix an older issue, something in
> 6.4 or older, which is what net is mostly used for. Under those
> conditions, the stable rules apply. Things like, is this fixing an
> issue which really effects users....

Right, this was caught before it made its way to general users. I was
basing targeting net still from the previous conversation about Fixes
tags.

>
>        Andrew

Thanks,

Rahul Rameshbabu

Powered by blists - more mailing lists