linux-kernel - Re: [PATCH v1 2/3] net: stmmac: dwmac-sun8i: Allow runtime AC200/AC300 phy selection

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: <CADvTj4pt48o0wm-69WfkOtp0c-aP64DSwPFo=znY2Hk_N2ft1w@mail.gmail.com>
Date: Mon, 26 May 2025 15:45:45 -0600
From: James Hilliard <james.hilliard1@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, linux-sunxi@...ts.linux.dev, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Chen-Yu Tsai <wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>, 
	Samuel Holland <samuel@...lland.org>, Maxime Coquelin <mcoquelin.stm32@...il.com>, 
	Alexandre Torgue <alexandre.torgue@...s.st.com>, Serge Semin <fancer.lancer@...il.com>, 
	Feiyang Chen <chenfeiyang@...ngson.cn>, Yanteng Si <si.yanteng@...ux.dev>, 
	Uwe Kleine-König <u.kleine-koenig@...libre.com>, 
	Jinjie Ruan <ruanjinjie@...wei.com>, Paul Kocialkowski <paulk@...-base.io>, 
	"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>, linux-arm-kernel@...ts.infradead.org, 
	linux-stm32@...md-mailman.stormreply.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/3] net: stmmac: dwmac-sun8i: Allow runtime
 AC200/AC300 phy selection

On Mon, May 26, 2025 at 3:22 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > > The normal way to do this is phy_find_first().
> >
> > Sure, but there are problems with that approach here.
> >
> > The initialization sequences are rather different and the devices
> > won't be visible on the mdio bus until after they are initialized.
> >
> > The resets will be specific to either the AC200 or AC300 so we
> > need to choose the correct PHY based on the efuse value rather
> > than a mdio bus scan to avoid a circular dependency essentially.
> >
> > AC200: i2c based reset/init sequence
> > AC300: mdio based reset/init sequence
>
> O.K. so you need to post more, so we get to see the complete
> problem/solution. It seems to me, AC200 and AC300 are not compatible,
> so should have different compatible strings. That might be part of the
> solution. But it is too early to say.

They will need to use different reset drivers but the mac part is
largely the same AFAIU. The mdio part is similar after initialization
as well I think.

These are the vendor docs(I only found chinese version so far) that
have some more details on the AC200 and AC300 EPHY's:
http://file.whycan.com/files/202304/V85x/Linux_EMAC_%e5%bc%80%e5%8f%91%e6%8c%87%e5%8d%97.pdf

Translated important sections:

For AC200:
ARM communicates with AC200 through TWI, initializes EPHY, and then
MAC accesses the MDIO bus.
EPHY, PWM module provides an internal 25M clock to EPHY.

For AC300:
ARM communicates with AC300 through MDIO bus, initializes EPHY, and
then MAC accesses EPHY through MDIO bus. PWM module provides an
internal
25M clock to EPHY.

So the MAC to EPHY connection is more or less the same AFAIU,
but the initialization is quite different.

>
>         Andrew
>