> From an architecture perspicuity, PHY vendor specific registers should be in the PHY register address space. MAC vendor specific registers should be in the MAC register address space. I agree 100%. The registers I'm talking about are not PHY or MAC specific. They are related to other functions. For example, configuring pins to output a clock, an SFD indication, a LED, or other. Some devices also can configure events driven by the PTP timer to toggle GPIOs, capture the timer on rising/falling edge of a GPIO or similar. > It seems like the Microchip device has some PHY vendor specific registers in the MAC address space. That is bad. I was not aware of that. I can tell you this is not my case. > Both your and Microchip device is a single piece of silicon. But i doubt there is anything in the standard which actually requires this. The PHY could be discrete, on the end of an MDIO bus and an MII bus. That is the typical design for the last 30 years, and what linux is built around. The MAC should not assume anything about the PHY, the PHY should not assume anything about the MAC, because they are interchangeable. Yes, to me the MAC and PHY must be separate entities even for the OPEN Alliance TC14/6 protocol. Besides, you can stuff whatever PHY within your MACPHY chip (e.g. 10BASE-T1L). In "my" driver you need to specify in the DTS the kind of net device and the PHY as a handle. > The framework does allow you to poke any register anywhere. But i would strongly avoid breaking the layering, it is going to cause you long term maintenance problems, and is ugly. On that we agree. Maybe I was just misunderstanding the earlier conversation where I thought you would not allow specific drivers to access MMS other than 0,1,4 and the ones that map to MMDs. If this is not the case, then I think I'm good. Thanks! --Pier
