linux-kernel - Re: [PATCH net-next v2 2/3] net: phy: air

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aff7a69c-e72f-4cb9-8fc5-6d8d1626ab4e@lunn.ch>
Date: Sat, 24 Jan 2026 19:33:31 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Bjørn Mork <bjorn@...k.no>
Cc: netdev@...r.kernel.org, "Lucien.Jheng" <lucienzx159@...il.com>,
	Daniel Golle <daniel@...rotopia.org>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/3] net: phy: air_en8811h: add Airoha
 AN8811HB support

On Sat, Jan 24, 2026 at 05:53:03PM +0100, Bjørn Mork wrote:
> Andrew Lunn <andrew@...n.ch> writes:
> 
> >> +#define AN8811HB_GPIO_OUTPUT		0x5cf8b8
> >> +#define   AN8811HB_GPIO_OUTPUT_345		(BIT(3) | BIT(4) | BIT(5))
> >
> >> +	/* Configure led gpio pins as output */
> >> +	ret = air_buckpbus_reg_modify(phydev, AN8811HB_GPIO_OUTPUT,
> >> +				      AN8811HB_GPIO_OUTPUT_345,
> >> +				      AN8811HB_GPIO_OUTPUT_345);
> >
> > The code/comment probably does not describe what is actually happening
> > here. My _guess_ is you are setting a pinmux, disconnecting the pins
> > from the GPIO controller and connecting them to the LED controller.
> 
> Possibly.  This code is copied from the out-of-tree vendor driver.  We
> already have similar code and comment in the en8811h probe:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/drivers/net/phy/air_en8811h.c#n959
> 
> The register addresses and layouts are suspiciously similar:
> 
> #define EN8811H_GPIO_OUTPUT		0xcf8b8
> #define   EN8811H_GPIO_OUTPUT_345		(BIT(3) | BIT(4) | BIT(5))
> 
> Without any docs, or a way to test this particular feature, I
> believe the safest option is to assume that the vendor driver is
> correct.  Can't start guessing no matter how tempting it is :-)

The writing of the value to the register is likely correct. I just
think all the names and comments are wrong.

Maybe using magic numbers in this case is actually better?

And describe the intent of the code in more general terms, allow the
pins to be used to driver LEDs.

> I have no other docs either.  The code is based solely on the vendor
> driver.  But trying to reuse as much as possible of the existing en8811h
> driver instead of duplicating it like the vendor did.

That is typical of vendors, and i agree with your strategy,.

> I have two almost identical boards with this phy connected to a Mediatek
> MT7988D SoC.  I can test, and have tested, the features exposed by those
> boards.  But this is obviously a limited test environment.  There are
> for example no port LEDs on any of the boards.

So you have no idea if the LEDs actualy blink with traffic, show link
state etc?

	Andrew