On Thu, Nov 10, 2022 at 05:01:34PM +0100, Andrew Lunn wrote: > On Thu, Nov 10, 2022 at 03:29:26PM +0000, Vladimir Oltean wrote: > > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote: > > > On 11/9/22 17:41, Vladimir Oltean wrote: > > > > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote: > > > >> Several (later) patches in this series cannot be applied until a stable > > > >> release has occured containing the dts updates. > > > > > > > > New kernels must remain compatible with old device trees. > > > > > > Well, this binding is not present in older device trees, so it needs to > > > be added before these patches can be applied. It also could be possible > > > to manually bind the driver using e.g. a helper function (like what is > > > done with lynx_pcs_create_on_bus). Of course this would be tricky, > > > because we would need to unbind any generic phy driver attached, but > > > avoid unbinding an existing Lynx PCS driver. > > > > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for > > these PCS devices, would it be possible to probe them in a generic way > > as MDIO devices, if they lack a compatible string? > > That is not how it currently works. If a device on an MDIO bus has a > compatible, it is assumed to be an mdio device, and it is probed in a > generic way as an sort of mdio device. It could be an Ethernet switch, > or Broadcom has some generic PHYs which are mdio devices, etc. > > If there is no compatible, the ID registers are read and it is assumed > to be a PHY. It will be probed as a PHY. The probe() function will be > given a phydev etc. > > It will need some core changes to allow an mdio device to be probed > via the ID registers. Yes, it would require extending struct mdio_driver with something like what struct phy_driver has (u32 phy_id, u32 phy_id_mask), or with a more generic phy_id_match_table (similar to maybe of_match_table). I don't see a conceptually simpler way though.
