Hi,
On 7/28/20 3:06 AM, Dan Callaghan wrote:
Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
Now i could be wrong, but are Ethernet switches something you expect
to see on ACPI/SBSA platforms? Or is this a legitimate use of the
escape hatch?
As an extra data point: right now I am working on an x86 embedded
appliance (ACPI not Device Tree) with 3x integrated Marvell switches.
I have been watching this patch series with great interest, because
right now there is no way for me to configure a complex switch topology
in DSA without Device Tree.
DSA though, the switch is hung off a normal MAC/MDIO, right? (ignoring
whether that NIC/MAC is actually hug off PCIe for the moment).
It just has a bunch of phy devices strung out on that single MAC/MDIO.
So in ACPI land it would still have a relationship similar to the one
Andrew pointed out with his DT example where the eth0->mdio->phy are all
contained in their physical parent. The phy in that case associated with
the parent adapter would be the first direct decedent of the mdio, the
switch itself could then be represented with another device, with a
further string of device/phys representing the devices. (I dislike
drawing acsii art, but if this isn't clear I will, its also worthwhile
to look at the dpaa2 docs for how the mac/phys work on this device for
contrast.).
If so, then its probably possible to represent with a fairly regular
looking set of ACPI objects and avoids part of the core discussion here
about whether we need a standardized way to pick phy's out of arbitrary
parts of the hierarchy using a part of the spec intended for one off
problems.
Am I missing something?
For the device I am working on, we will have units shipping before these
questions about how to represent Ethernet switches in ACPI can be
resolved. So realistically, we will have to actually configure the
switches using software_node structures supplied by an out-of-tree
platform driver, or some hackery like that, rather than configuring them
through ACPI.
An approach I have been toying with is to port all of DSA to use the
fwnode_handle abstraction instead of Device Tree nodes, but that is
obviously a large task, and frankly I was not sure whether such a patch
series would be welcomed.
