Re: [PATCH net-next v3 0/2] net: dsa: mxl-gsw1xx: reset the switch through reset-gpios

[Daniel Golle <daniel@makrotopia.org>]

On Fri, Nov 13, 2026 at 03:08:10PM +0100, Andrew Lunn wrote:
> > This is separate from commit 82e2c7db0830 ("net: dsa: mxl-gsw1xx: force
> > internal PHYs into a known reset state"), which only programs the PHY
> > bits of RST_REQ. On this board that commit is applied, and the PHYs still
> > sit at the shifted addresses; only a hardware reset of the switch moves
> > them back.
> 
> I don't think 82e2c7db0830 is relevant here. The commit message says
> nothing about the address of the PHY.
> 
> How does the bootloader change the address? I assume there is a
> register it writes?

Yes.

PHY_ADDR_{0,1,2,3,4,5} at offsets 0xF415, 0xF414, 0xF413, 0xF412,
0xF411, 0xF410 (ie. reverse order). Bits 4:0 are the address of the
respective built-in PHY.

> 
> Is there a comment about why it changes the address?

I *guess* that in this case the vendor wants to avoid using PHY
address 0 which is widely misunderstood as being the "broadcast
address" (which it is, but only in scope of AUI attachments and SFP
modules). I know many people who get upset about using PHY address 0
for an actual PHY rather than reserving it as a broadcast address all
PHYs on the bus are listening on...

The switch also has it's own MDIO master interface exposed on external
pins which is shared with the internal PHYs. Hence programming the
addresses of the built-in PHYs can be done in order to accomodate
external PHYs on the same bus which may not be free to use arbitrary
addresses.

> 
> Does the driver have an implicit assumption about the addresses of the
> PHYs? Should the driver actually be writing this register to put the
> PHYs at the expected address?

The driver does what is described in the device tree. Ie. boot firmware
applying a non-default PHY addresses should just say so in the DT passed
to Linux imho.

See also Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml