> 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. Andrew
