Re: [PATCH net-next v9 2/3] net: ethtool: add KSZ87xx low-loss cable PHY tunables

[Fidelio LAWSON]

On 6/6/26 01:31, Jakub Kicinski wrote:
> On Fri, 5 Jun 2026 05:16:54 +0200 Marek Vasut wrote:
> > On 6/5/26 4:35 AM, Jakub Kicinski wrote:
> > > On Thu,  4 Jun 2026 13:41:19 +0200 Paolo Abeni wrote:
> > > > [Severity: High]
> > > > Is it intentional to enforce an 8-bit type constraint for bandwidth and DSP
> > > > equalizer tunables?
> > > >
> > > > This heavily couples the global API to the 8-bit register layout of the
> > > > KSZ87xx hardware without defining generic units like Hz for bandwidth.
> > >
> > > AFAIK this is the one comment from AI that survives scrutiny.
> > > Seems unlikely we'd need more bits, but then again - why not.
> > > u32 should be our default for integer values, u8 is more for
> > > booleans.
> >
> > Why waste memory space if we are already sure the space would not be used.
>
> Waste what memory? We are talking about a syscall argument effectively.
>
> My point is that this is adding the arguments as u8 in
> net/ethtool/ioctl.c, so as part of the global uAPI.
>
> The driver can still store these as u8, since any value outside of that
> range is invalid for ksz87xx, and the input is properly validated.
> But we shouldn't constrain the value "in transit", at the uAPI level.
> Another driver may need a larger range (however unlikely that is).

Thanks for the clarification.

I will update the series to use u32 for the PHY tunables in the next 
revision, while keeping the driver-side representation constrained to 
the supported range.

Thanks,
Fidelio