On 7/28/2020 7:53 PM, Jeremy Linton wrote: > Hi, > > On 7/28/20 7:39 PM, Florian Fainelli wrote: >> On 7/28/2020 3:30 PM, Jeremy Linton wrote: >>> Hi, >>> >>> On 7/28/20 3:06 AM, Dan Callaghan wrote: >>>> Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00: >>>>> Now i could be wrong, but are Ethernet switches something you expect >>>>> to see on ACPI/SBSA platforms? Or is this a legitimate use of the >>>>> escape hatch? >>>> >>>> As an extra data point: right now I am working on an x86 embedded >>>> appliance (ACPI not Device Tree) with 3x integrated Marvell switches. >>>> I have been watching this patch series with great interest, because >>>> right now there is no way for me to configure a complex switch topology >>>> in DSA without Device Tree. >>> >>> DSA though, the switch is hung off a normal MAC/MDIO, right? (ignoring >>> whether that NIC/MAC is actually hug off PCIe for the moment). >> >> There is no specific bus, we have memory mapped, MDIO, SPI, I2C swiches >> all supported within the driver framework right now. >> >>> >>> It just has a bunch of phy devices strung out on that single MAC/MDIO. >> >> It has a number of built-in PHYs that typically appear on a MDIO bus, >> whether that bus is the switch's internal MDIO bus, or another MDIO bus >> (which could be provided with just two GPIOs) depends on how the switch >> is connected to its management host. >> >> When the switch is interfaced via MDIO the switch also typically has a >> MDIO interface called the pseudo-PHY which is how you can actually tap >> into the control interface of the switch, as opposed to reading its >> internal PHYs from the MDIO bus. >> >>> So in ACPI land it would still have a relationship similar to the one >>> Andrew pointed out with his DT example where the eth0->mdio->phy are all >>> contained in their physical parent. The phy in that case associated with >>> the parent adapter would be the first direct decedent of the mdio, the >>> switch itself could then be represented with another device, with a >>> further string of device/phys representing the devices. (I dislike >>> drawing acsii art, but if this isn't clear I will, its also worthwhile >>> to look at the dpaa2 docs for how the mac/phys work on this device for >>> contrast.). >> >> The eth0->mdio->phy relationship you describe is the simple case that >> you are well aware of which is say what we have on the Raspberry Pi 4 >> with GENET and the external Broadcom PHY. >> >> For an Ethernet switch connected to an Ethernet MAC, we have 4 different >> types of objects: >> >> - the Ethernet MAC which sits on its specific bus >> >> - the Ethernet switch which also sits on its specific bus >> >> - the built-in PHYs of the Ethernet switch which sit on whatever >> bus/interface the switch provides to make them accessible >> >> - the specific bus controller that provides access to the Ethernet switch >> >> and this is a simplification that does not take into account Physical >> Coding Sublayer devices, pure MDIO devices (with no foot in the Ethernet >> land such as PCIe, USB3 or SATA PHYs), SFP, SFF and other pluggable >> modules. > > Which is why I've stayed away from much of the switch discussion. There > are a lot of edge cases to fall into, because for whatever reason > networking seems to be unique in all this non-enumerable customization > vs many other areas of the system. Storage, being an example i'm more > familiar with which has very similar problems yet, somehow has managed > to avoid much of this, despite having run on fabrics significantly more > complex than basic ethernet (including running on a wide range of hot > pluggable GBIC/SFP/QSFP/etc media layers). > > ACPI's "problem" here is that its strongly influenced by the "Plug and > Play" revolution of the 1990's where the industry went from having > humans describing hardware using machine readable languages, to hardware > which was enumerable using standard protocols. ACPI's device > descriptions are there as a crutch for the remaining non plug an play > hardware in the system. > > So at a basic level, if your describing hardware in ACPI rather than > abstracting it, that is a problem. I suppose that is a good summary, my impression from this patch series is that we want the description part, not the abstraction, whether it is on purpose or because there is a misunderstanding of what ACPI is intended for, or higher powers have decided this must be done otherwise nothing gets sold, who knows? -- Florian
