netdev - Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Jul 2020 17:30:26 -0500
From:   Jeremy Linton <jeremy.linton@....com>
To:     Dan Callaghan <dan.callaghan@...ngear.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Calvin Johnson <calvin.johnson@....nxp.com>,
        Russell King <linux@...linux.org.uk>, Jon <jon@...id-run.com>,
        Cristi Sovaiala <cristian.sovaiala@....com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Madalin Bucur <madalin.bucur@....nxp.com>,
        netdev <netdev@...r.kernel.org>, "linux.cj" <linux.cj@...il.com>,
        linux-acpi <linux-acpi@...r.kernel.org>
Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO
 PHY

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