On Fri, Nov 24, 2023 at 07:35:35PM +0100, Andrew Lunn wrote: > > I think you are hitting some of the same points I have hit with DSA. > > The PHY package could be considered an SoC with lots of peripherals on > > it, for which you'd want separate drivers. > > At least at the moment, this is not true. The package does just > contain PHYs. But it also has some properties which are shared across > those PHYs, e.g. reset. > > What you describe might become true in the future. e.g. The LED/GPIO > controller is currently part of the PHY, and each PHY has its own. I > could however imagine that becomes a block of its own, outside of the > PHY address space, and maybe it might want its own class LED > driver. Some PHYs have temperature sensors, which could be a package > sensor, so could in theory be an individual hwmon driver. However, > i've not yet seen such a package. > > Do we consider this now? At the moment i don't see an MFD style system > is required. We could crystal ball gaze and come up with some > requirements, but i would prefer to have some real devices and > datasheets. Without them, we will get the requirements wrong. > > I also think we are not that far away from it, in terms of DT, if you > consider the later comments. I suggested we need a phy package > specific compatible. At the moment, it will be ignored by the kernel, > the kernel does not need it, it probes the PHYs in the current way, > using the ID registers. But it could in future be used to probe a real > driver, which could be an MFD style driver. We need to see updated DT > binding examples, but i don't see why we cannot slot it in at a later > date. I'm not suggesting to go for MFD right away. Just with a structure that is extensible to possibly cover that. For now, a package node with a Qualcomm compatible, with the most minimal driver that forwards MDIO access to PHY children. I can't speak for the future of PHY drivers, since I don't know enough about PHYs. I'm just coming from the DSA background where I really wish we had this sort of infrastructure earlier. Now I have the SJA1110 which still lacks support for the interrupt controller for its integrated PHYs, and a bunch of other IP blocks in the package, because it's so incredibly hard to make the driver support the old-style and the new-style device trees.
