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 22:45:48 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Dan Callaghan <dan.callaghan@...ngear.com>
Cc:     Jeremy Linton <jeremy.linton@....com>,
        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

On Tue, Jul 28, 2020 at 06:06:26PM +1000, 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.
> 
> 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.

Hi Dan

I also have an x86 platform, but with a single switch. For that, i
have a platform driver, which instantiates a bit banging MDIO bus, and
sets up the switch using platform data. This works, but it is limited
to internal Copper only PHYs.

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

I would actually suggest you look at using DT. We are struggling to
get ACPI maintainers involved with really simple things, like the ACPI
equivalent of a phandle from the MAC to the PHY. A full DSA binding
for Marvell switches is pretty complex, especially if you need SFP
support. I expect the ACPI maintainers will actively run away
screaming when you make your proposal.

DT can be used on x86, and i suspect it is a much easier path of least
resistance.

	Andrew