Re: [net-next: PATCH 00/12] ACPI support for DSA
From: Marcin Wojtas <hidden>
Date: 2022-06-21 10:03:05
Also in:
linux-acpi, lkml
pon., 20 cze 2022 o 19:21 Andy Shevchenko [off-list ref] napisał(a):
On Mon, Jun 20, 2022 at 05:02:13PM +0200, Marcin Wojtas wrote:quoted
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]....quoted
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