[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aXtfVUb0eLwP4R28@shell.armlinux.org.uk>
Date: Thu, 29 Jan 2026 13:23:33 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Simon Horman <horms@...nel.org>, vkoul@...nel.org,
neil.armstrong@...aro.org, krzk+dt@...nel.org, conor+dt@...nel.org,
ciprianmarian.costea@....nxp.com, s32@....com,
p.zabel@...gutronix.de, ghennadi.procopciuc@....com,
bogdan-gabriel.roman@....com, Ionut.Vicovan@....com,
alexandru-catalin.ionita@....com, linux-phy@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, netdev@...r.kernel.org,
Frank.li@....com
Subject: Re: [PATCH 2/4] phy: s32g: Add serdes subsystem phy
On Thu, Jan 29, 2026 at 02:01:13PM +0100, Vincent Guittot wrote:
> yes, the usual pattern is :
> - phy_set_mode_ext()
> - then phy_power_on()
> but I can add an additional check
Please read Documentation/driver-api/phy/phy.rst section "Order of API
calls" which suggests phy_set_mode_ext() after phy_power_on().
Having different requirements for different SerDes PHYs quickly becomes
annoying for users of the SerDes PHYs.
E.g. I'm trying to add SerDes PHY support to stmmac, which is used
across different platforms. Having all SerDes PHY drivers behave the
same as far as their PHY API calls are concerned means that the whole
point of having an abstracted interface is maintained. Otherwise, it's
completely pointless.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists