pon., 20 cze 2022 o 19:21 Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> napisał(a): > > On Mon, Jun 20, 2022 at 05:02:13PM +0200, Marcin Wojtas wrote: > > Hi! > > > > This patchset introduces the support for DSA in ACPI world. A couple of > > words about the background and motivation behind those changes: > > > > The DSA code is strictly dependent on the Device Tree and Open Firmware > > (of_*) interface, both in the drivers and the common high-level net/dsa API. > > The only alternative is to pass the information about the topology via > > platform data - a legacy approach used by older systems that compiled the > > board description into the kernel. > > > > The above constraint is problematic for the embedded devices based e.g. on > > x86_64 SoCs, which are described by ACPI tables - to use DSA, some tricks > > and workarounds have to be applied. Addition of switch description to > > DSDT/SSDT tables would help to solve many similar cases and use unmodified > > kernel modules. It also enables this feature for ARM64 ACPI users. > > > > The key enablements allowing for adding ACPI support for DSA in Linux were > > NIC drivers, MDIO, PHY, and phylink modifications – the latter three merged > > in 2021. I thought it would be worth to experiment with DSA, which seemed > > to be a natural follow-up challenge. > > > > It turned out that without much hassle it is possible to describe > > DSA-compliant switches as child devices of the MDIO busses, which are > > responsible for their enumeration based on the standard _ADR fields and > > description in _DSD objects under 'device properties' UUID [1]. > > The vast majority of required changes were simple of_* to fwnode_* > > transition, as the DT and ACPI topolgies are analogous, except for > > 'ports' and 'mdio' subnodes naming, as they don't conform ACPI > > namespace constraints [2]. > > ... > > > Note that for now cascade topology remains unsupported in ACPI world > > (based on "dsa" label and "link" property values). It seems to be feasible, > > but would extend this patchset due to necessity of of_phandle_iterator > > migration to fwnode_. Leave it as a possible future step. > > Wondering if this can be done using fwnode graph. > Probably yes. It's a general question whether to follow iterating over phandles pointed by properties, like DT with a minimal code change or do something completely different. Best regards, Marcin
