Thread (84 messages) 84 messages, 9 authors, 2022-06-25

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help