On Tue, Apr 15, 2025 at 04:06:31PM +0530, Siddharth Vadapalli wrote: > On Tue, Apr 15, 2025 at 12:18:01PM +0200, Matthias Schiffer wrote: > > As discussed [1], the comments for the different rgmii(-*id) modes do not > > accurately describe what these values mean. > > > > As the Device Tree is primarily supposed to describe the hardware and not > > its configuration, the different modes need to distinguish board designs > > If the Ethernet-Controller (MAC) is integrated in an SoC (as is the case > with CPSW Ethernet Switch), and, given that "phy-mode" is a property > added within the device-tree node of the MAC, I fail to understand how > the device-tree can continue "describing" hardware for different board > designs using the same SoC (unchanged MAC HW). phy-mode describes the link between the MAC and the PHY. So it either needs to be in the MAC node, or the PHY node when describing the board. I don't know the history of why it ended up in the MAC node, but it did. > Since all of the above is documented in "ethernet-controller.yaml" and > not "ethernet-phy.yaml", describing what the "MAC" should or shouldn't > do seems accurate, and modifying it to describe what the "PHY" should or > shouldn't do seems wrong. What we are really saying here is, does the PCB have extra long clock lines in order to add the delays? If yes, the MAC/PHY pair does nothing. If no, the MAC/PHY pair needs to add the delay. DT however says nothing about how the MAC/PHY pair should add the delay. That would be configuration, and DT should try to not describe configuration. Hence the binding description needs to be neutral to MAC and PHY. Linux has a preference, that the PHY does the delay. However, other operating systems might have other preferences. And since the binding should be generic across a range of operating systems, we don't mention Linux's preference. Andrew
