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?

Signed-off-by: Kyle Hendry <kylehendrydev@gmail.com>

Kyle Hendry (6):
  net: dsa: b53: Add phy_enable(), phy_disable() methods
  net: dsa: b53: mmap: Add reference to bcm63xx gpio controller
  dt-bindings: net: dsa: b53: Document brcm,gpio-ctrl property
  net: dsa: b53: mmap: Add register layout for bcm63268
  net: dsa: b53: mmap: Clear resets on bcm63xx EPHYs
  net: dsa: b53: mmap: Implement bcm63xx ephy power control

 .../devicetree/bindings/net/dsa/brcm,b53.yaml |  5 +
 drivers/net/dsa/b53/b53_common.c              |  6 ++
 drivers/net/dsa/b53/b53_mmap.c                | 99 ++++++++++++++++++-
 drivers/net/dsa/b53/b53_priv.h                |  2 +
 4 files changed, 111 insertions(+), 1 deletion(-)

-- 
2.43.0

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