linux-kernel - Re: [RFC PATCH net-next 0/6] net: dsa: b53: mmap: Add bcm63xx EPHY power and reset control

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: <a4ee184b-f2f8-4c0b-97c3-c853ac375f63@broadcom.com>
Date: Fri, 27 Jun 2025 16:08:06 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Kyle Hendry <kylehendrydev@...il.com>,
 Florian Fainelli <florian.fainelli@...adcom.com>,
 Andrew Lunn <andrew@...n.ch>, 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>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Russell King <linux@...linux.org.uk>
Cc: noltari@...il.com, jonas.gorski@...il.com, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH net-next 0/6] net: dsa: b53: mmap: Add bcm63xx EPHY
 power and reset control

On 6/20/25 06:41, Kyle Hendry wrote:
> Some bcm63268 bootloaders hold the fast ethernet phys in reset
> causing an error when they're probed. The resets are controlled
> by a register in the gpio controller, and would need a minimal
> driver to set. However, that register also controls the
> power states of the EPHYs. I'm trying to implement both
> functionalities at the same time to make sure that they don't
> interfere with eachother. These patches allow control of the
> ephy register from the b53 switch driver.
> 
> Is this the right place for this code, or should it be in a
> power domain? Should the resets be handled by a separate reset
> controller?

Good question, it seems like a reset controller might work with one 
reset per port being defined? Unfortunately the register in the GPIO 
controller is not logically part of a GPIO interface, it's just where it 
landed because that was convenient for the designer.
-- 
Florian