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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7d42152a-2df1-a26c-b619-b804001e0eac@gmail.com>
Date:   Tue, 28 Jul 2020 13:56:15 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>,
        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>,
        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 7/28/2020 1:45 PM, Andrew Lunn wrote:
> 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.

At some point I had a dsa2_platform_data implementation which was
intended to describe more complex switch set-ups and trees, the old code
is still there for your entertainment:

https://github.com/ffainelli/linux/commits/dsa-pdata

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

And you can easily overlay Device Tree to an existing system by using
either a full Device Tree overlay (dtbo) or using CONFIG_OF_DYNAMIC and
creating nodes on the fly.
-- 
Florian