[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YrCsgIxOmXQcjy+B@smile.fi.intel.com>
Date: Mon, 20 Jun 2022 20:21:04 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Marcin Wojtas <mw@...ihalf.com>
Cc: linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
netdev@...r.kernel.org, rafael@...nel.org, lenb@...nel.org,
andrew@...n.ch, vivien.didelot@...il.com, f.fainelli@...il.com,
olteanv@...il.com, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, linux@...linux.org.uk,
hkallweit1@...il.com, gjb@...ihalf.com, jaz@...ihalf.com,
tn@...ihalf.com, Samer.El-Haj-Mahmoud@....com,
upstream@...ihalf.com
Subject: Re: [net-next: PATCH 00/12] ACPI support for DSA
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.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists