Re: [RFC v3 4/4] net: dsa: initial support for MT7628 embedded switch

[Joris Vaisvila <joey@tinyisr.com>]

Hi Daniel, thanks for the feedback and suggestions.

On Sat, Mar 21, 2026 at 09:05:35PM +0000, Daniel Golle wrote:
> As mentioned in the binding comment:
> - The MDIO bus is exclusively used to speak with the built-in PHYs.
> - The PHY addresses match the port IDs.
> - Only Clause-22 read/write operations are supported.
> - There is no way to connect an external PHY (no MII interface
>   exposed on external pins)
> 
> Imho it would hence be much easier to just use DSA's simple .phy_read
> and .phy_write operations instead of registering a bus manually in the
> driver, and even requiring a description of the MDIO bus in device
> tree.
> 
> If you want to reserve the option of adding PHY-specific DT properties
> in future (eg. for PHY-controlled LEDs? but afair the LEDs are
> controlled by the switch itself and SoC-level pinctrl), at least set
> `ds->user_mii_bus = bus;` to make the device tree description
> optional. Completely omitting the whole bus definition and changing
> mt7628_mii_read and mt7628_mii_write to be useful as .phy_read and
> .phy_write ops in struct dsa_switch is the better option for simple
> legacy hardware like that imho. See b53 driver, for example.

The LEDs are indeed controlled by the switch, so there doesn't appear to
be anything to configure now or in the future. Using `ds->user_mii_bus`
sounds like a reasonable option to simplify configuration and works fine
on this switch, I was not aware of it earlier. 

> @DSA maintainers: correct me if I'm wrong and, for which ever reason,
> using the .phy_read/.phy_write ops is discouraged in new drivers, even
> for dead-simple hardware like that one.

Regarding .phy_read/.phy_write, I was advised against using them in new
drivers in v1 of this RFC. I'm happy to rework this, but would
appreciate clarification from the DSA maintainers on the preferred
direction for hardware like this.