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

[Fidelio LAWSON <lawson.fidelio@gmail.com>]

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