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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aXkNqmiUoWZja4gg@makrotopia.org>
Date: Tue, 27 Jan 2026 19:10:34 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Paolo Abeni <pabeni@...hat.com>, Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Frank Wunderlich <frankwu@....de>, Chad Monroe <chad@...roe.io>,
	Cezary Wilmanski <cezary.wilmanski@...ran.com>,
	Avinash Jayaraman <ajayaraman@...linear.com>,
	Bing tao Xu <bxu@...linear.com>, Liang Xu <lxu@...linear.com>,
	Juraj Povazanec <jpovazanec@...linear.com>,
	"Fanni (Fang-Yi) Chan" <fchan@...linear.com>,
	"Benny (Ying-Tsan) Weng" <yweng@...linear.com>,
	"Livia M. Rosu" <lrosu@...linear.com>,
	John Crispin <john@...ozen.org>
Subject: Re: [PATCH net-next v8 4/4] net: dsa: add basic initial driver for
 MxL862xx switches

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.