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: <CAHp75VejnW23LEfyEO6Py8=e3_W0YMomk8jQ3JQeHqYcaeDitg@mail.gmail.com>
Date:   Wed, 29 Jul 2020 00:28:36 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Dan Callaghan <dan.callaghan@...ngear.com>,
        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>,
        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 11:56 PM Florian Fainelli <f.fainelli@...il.com> wrote:
> 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

Platform data in the modern kernel is definitely the wrong approach.
Software nodes of firmware nodes can be much more appreciated.

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

Why do you need DT on a system that runs without it and Linux has all
means to extend to cover a lot of stuff DT provides for other types of
firmware nodes?

-- 
With Best Regards,
Andy Shevchenko