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

[Andy Shevchenko <andy.shevchenko@gmail.com>]

On Tue, Jul 28, 2020 at 11:56 PM Florian Fainelli <f.fainelli@gmail.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