[LTP] [PATCH net v1] ptp: Make max_phase_adjustment sysfs device attribute invisible when not supported
Andrew Lunn
andrew@lunn.ch
Wed Jun 28 16:35:41 CEST 2023
> >> diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c
> >> index 77219cdcd683..6e4d5456a885 100644
> >> --- a/drivers/ptp/ptp_sysfs.c
> >> +++ b/drivers/ptp/ptp_sysfs.c
> >> @@ -358,6 +358,9 @@ static umode_t ptp_is_attribute_visible(struct kobject *kobj,
> >> attr == &dev_attr_max_vclocks.attr) {
> >> if (ptp->is_virtual_clock)
> >> mode = 0;
> >> + } else if (attr == &dev_attr_max_phase_adjustment.attr) {
> >> + if (!info->adjphase || !info->getmaxphase)
> >> + mode = 0;
> >
> > Maybe it is time to turn this into a switch statement?
>
> I agree. However, I do not want to conflate two separate things being a
> bugfix and a cleanup. I think we can do one of two options.
>
> 1. We can take this patch as is, but I submit a subsequent cleanup patch for
> this.
Fine by me.
> > 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.
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.
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....
Andrew
More information about the ltp
mailing list