Re: [PATCH net-next v8 4/4] net: dsa: add basic initial driver for MxL862xx switches

[Daniel Golle <daniel@makrotopia.org>]

On Tue, Jan 27, 2026 at 07:34:41PM +0100, Andrew Lunn wrote:
> On Tue, Jan 27, 2026 at 04:07:10PM +0000, Daniel Golle wrote:
> > On Tue, Jan 27, 2026 at 04:04:10PM +0100, Andrew Lunn wrote:
> > > > > int mxl862xx_to_zephyr_errno(u16 reg)
> > > > so that would then just be
> > > > 	return (s16)reg;
> > > > right?
> > > 
> > > Yes.
> > 
> > +1
> > 
> > Maybe better to check if bit 16~31 is actually zero as well, so
> > int mxl862xx_to_zephyr_errno(int reg)
> > {
> > 	if (reg >= 0 && reg <= U16_MAX)
> > 		return (s16)reg;
> > 
> > 	return 0;
> 
> If bits 16~31 are not zero, i would say the MDIO driver is broken, and
> we should fix it. Returning 0 is going to hide such issues. If you are
> worried about it, at least add a WARN_ON() or something.

The MDIO bus driver can very well return things like -ETIMEDOUT or
-ENODEV as a result of its .read_c45() operation (both values got
all bits 16~31 set, on every architecture I've checked)

This hints towards broken hardware, but not a broken driver. And I'd
rather catch that case (int reg < 0) separately and outside of the
mxl862xx_to_zephyr_errno() helper.

The broken-driver case would be values between U16_MAX and S32_MAX which
really don't make any sense.

Making sure mxl862xx_to_zephyr_errno() isn't called if any of the bits
16~31 are set would still be good to not end up blaming the firmware for
something which in reality is the MDIO bus driver or faulty hardware.
In that sense my idea of return 0 was just to say "it isn't a value
returned by the Zephyr firmware". If you prefer a WARN_ON() and return
-EINVAL instead of the return 0 that would be fine as well, of course.