On 7/28/2020 2:28 PM, Andy Shevchenko wrote: > On Tue, Jul 28, 2020 at 11:56 PM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: >> On 7/28/2020 1:45 PM, Andrew Lunn wrote: >>> On Tue, Jul 28, 2020 at 06:06:26PM +1000, 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. >>>> >>>> For the device I am working on, we will have units shipping before these >>>> questions about how to represent Ethernet switches in ACPI can be >>>> resolved. So realistically, we will have to actually configure the >>>> switches using software_node structures supplied by an out-of-tree >>>> platform driver, or some hackery like that, rather than configuring them >>>> through ACPI. >>> >>> Hi Dan >>> >>> I also have an x86 platform, but with a single switch. For that, i >>> have a platform driver, which instantiates a bit banging MDIO bus, and >>> sets up the switch using platform data. This works, but it is limited >>> to internal Copper only PHYs. >> >> At some point I had a dsa2_platform_data implementation which was >> intended to describe more complex switch set-ups and trees, the old code >> is still there for your entertainment: >> >> https://github.com/ffainelli/linux/commits/dsa-pdata > > Platform data in the modern kernel is definitely the wrong approach. > Software nodes of firmware nodes can be much more appreciated. Yes, yes, thank you. As you can see this was back from 2016 and it was never submitted. The only viable alternative that I can think of, unless the ACPI community at large finally decided to get its act together and invest some serious efforts and time into understanding modern and complex network topologies is to overlay a Device Tree onto a live system. > >>>> An approach I have been toying with is to port all of DSA to use the >>>> fwnode_handle abstraction instead of Device Tree nodes, but that is >>>> obviously a large task, and frankly I was not sure whether such a patch >>>> series would be welcomed. >>> >>> I would actually suggest you look at using DT. We are struggling to >>> get ACPI maintainers involved with really simple things, like the ACPI >>> equivalent of a phandle from the MAC to the PHY. A full DSA binding >>> for Marvell switches is pretty complex, especially if you need SFP >>> support. I expect the ACPI maintainers will actively run away >>> screaming when you make your proposal. >>> >>> DT can be used on x86, and i suspect it is a much easier path of least >>> resistance. >> >> And you can easily overlay Device Tree to an existing system by using >> either a full Device Tree overlay (dtbo) or using CONFIG_OF_DYNAMIC and >> creating nodes on the fly. > > Why do you need DT on a system that runs without it and Linux has all > means to extend to cover a lot of stuff DT provides for other types of > firmware nodes? Because ACPI is beyond useless at providing nearly the same level of description as what DT can do today? I am not trying to wage a war of DT is better than ACPI, but when it is not even capable of describing a simple 1 to 1 mapping between an Ethernet MAC and a PHY device sitting on an integrated or separate MDIO bus, describing a full Ethernet switch fabric with 1 to 40 ports, each with a variety of connectivity options, and you have an pressing need to get your platform out to customers, then the choice is obvious. -- Florian
