netdev - Re: [PATCH 0/4] net: dsa: b53: Enable internal GPHY on BCM63268

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: <aa8fefa0-c5ba-4bb0-9e45-6b0ac4cfbacc@lunn.ch>
Date: Mon, 10 Feb 2025 00:30:36 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Kyle Hendry <kylehendrydev@...il.com>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] net: dsa: b53: Enable internal GPHY on BCM63268

On Fri, Feb 07, 2025 at 08:44:31AM -0800, Florian Fainelli wrote:
> On 2/6/25 17:41, Kyle Hendry wrote:
> > 
> > On 2025-02-06 12:17, Andrew Lunn wrote:
> > > On Thu, Feb 06, 2025 at 10:15:50AM -0800, Florian Fainelli wrote:
> > > > Hi Kyle,
> > > > 
> > > > On 2/5/25 20:30, Kyle Hendry wrote:
> > > > > Some BCM63268 bootloaders do not enable the internal PHYs by default.
> > > > > This patch series adds functionality for the switch driver to
> > > > > configure the gigabit ethernet PHY.
> > > > > 
> > > > > Signed-off-by: Kyle Hendry <kylehendrydev@...il.com>
> > > > So the register address you are manipulating logically belongs
> > > > in the GPIO
> > > > block (GPIO_GPHY_CTRL) which has become quite a bit of a sundry here. I
> > > > don't have a strong objection about the approach picked up here
> > > > but we will
> > > > need a Device Tree binding update describing the second (and optional)
> > > > register range.
> > > Despite this being internal, is this actually a GPIO? Should it be
> > > modelled as a GPIO line connected to a reset input on the PHY? It
> > > would then nicely fit in the existing phylib handling of a PHY with a
> > > GPIO reset line?
> > > 
> > >     Andrew
> > The main reason I took this approach is because a SF2 register has
> > similar bits and I wanted to be consistent with that driver. If it
> > makes more sense to treat these bits as GPIOs/clocks/resets then it
> > would make the implementation simpler.
> 
> I don't think there is a need to go that far, and I don't think any of those
> abstractions work really well in the sense that they are neither clocks, nor
> resets, nor GPIOs, they are just enable bits for the power gating logic of
> the PHY, power domains would be the closest to what this is, but this is a
> very heavy handed approach with little benefit IMHO.

O.K. The naming is not particularly helpful. It is in the GPIO block,
and named GPIO_GPHY_CTRL so it kind of sounds like a GPIO. If the
existing GPIO driver could expose it as a GPIO it would of been a lot
simpler.

If the SF2 has similar bits, could the SF2 code be shared?

	Andrew