Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220620150225.1307946-1-mw@semihalf.com> <YrCsgIxOmXQcjy+B@smile.fi.intel.com>
In-Reply-To: <YrCsgIxOmXQcjy+B@smile.fi.intel.com>
From:   Marcin Wojtas <mw@semihalf.com>
Date:   Tue, 21 Jun 2022 12:02:46 +0200
Message-ID: <CAPv3WKdJ_zoraG=gpOOSWHJcoMTKkkH8=N21aXX2RrusjWWD9g@mail.gmail.com>
Subject: Re: [net-next: PATCH 00/12] ACPI support for DSA
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Len Brown <lenb@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
        vivien.didelot@gmail.com, Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>, pabeni@redhat.com,
        Russell King - ARM Linux <linux@armlinux.org.uk>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Grzegorz Bernacki <gjb@semihalf.com>,
        Grzegorz Jaszczyk <jaz@semihalf.com>,
        Tomasz Nowicki <tn@semihalf.com>,
        Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>,
        upstream@semihalf.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

pon., 20 cze 2022 o 19:21 Andy Shevchenko
<andriy.shevchenko@linux.intel.com> napisa=C5=82(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 t=
he
> > 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 tric=
ks
> > and workarounds have to be applied. Addition of switch description to
> > DSDT/SSDT tables would help to solve many similar cases and use unmodif=
ied
> > kernel modules. It also enables this feature for ARM64 ACPI users.
> >
> > The key enablements allowing for adding ACPI support for DSA in Linux w=
ere
> > NIC drivers, MDIO, PHY, and phylink modifications =E2=80=93 the latter =
three merged
> > in 2021. I thought it would be worth to experiment with DSA, which seem=
ed
> > 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 feasi=
ble,
> > 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