pon., 20 cze 2022 o 19:56 Andrew Lunn [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.

Not true. There are deployed x86 systems which do this, and they are
fully up to date, not legacy. There are however limitations in what
you can do. So please drop this wording.

Ok, thanks for clarification, agree for rewording. Afair pdata was a
legacy derived from the Orion/Dove times, but indeed it can be used in
the new systems that lack other switch description.

quoted

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.

It would be good to describe the limitations. As i said, there are x86
systems running with marvell 6390 switches.

I'm aware of that and even saw some x86_64 + Marvell switch
contemporary examples of how lack of DT in system was worked around:
- out of tree updates to the module code
- keep small DT blob on the system storage, from where the mv88e6xxx
Those could be poor-coding / anecdotic showcases. I'd be happy to
learn if there is a proper and recommended way, how to do it properly.

quoted

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].

No surprises there. That is how the DT binding works. And the current
ACPI concept is basically DT in different words. Maybe the more
important question is, is rewording DT in ACPI the correct approach,
or should you bo doing a more native ACPI implementation? I cannot
answer that, you need to ask the ACPI maintainers.

This is why I added linux-acpi list and the ACPI Maintainers to discuss

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.

We really do need to ensure this is possible. You are setting an ABI
here, which everybody else in the ACPI world needs to follow. Cascaded
switches is fundamental to DSA, it is the D in DSA. So i would prefer
that you at least define and document the binding for D in DSA and get
it sanity checked by the ACPI people.

I'm aware of the "D" importance, just kept it aside for now due to
lack of access to relevant HW and willing to discuss the overall
approach first.

WRT the technical side: multiple-phandle property is for sure
supported in _DSD, so the most straightforward would be to follow that
and simply migrate to fwnode_. The thing is in arm64 it's not widely
used and (testing that with ACPI is making it even harder).  There is
also an alternative brought by Andy - definitely a thing to discuss
further. I think we seem to have a quorum for that among recipents of
this thread.

Thanks,
Marcin