Messages in this thread | | | From | Jon Nettleton <> | Date | Fri, 31 Jan 2020 16:14:55 +0100 | Subject | Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc |
| |
On Fri, Jan 31, 2020 at 4:09 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > Devicetree to the rescue! > > Yes, exactly. We have good, standardised descriptions for most of this > in device tree. And phylink can handle SFP and SFP+. Nobody has worked > on QSFP yet, since phylink has mostly been pushed by the embedded > world and 40G is not yet popular in the embedded world. > > > Entertaining the use of ACPI without any firmware abstraction for this > > hardware really feels like a square peg / round hole situation, so I'm > > assuming somebody's telling you that you need it "FOAR ENTAPRYZE". Who > > is it and can you tell them to bog off? > > The issues here is that SFPs are appearing in more and more server > systems, replacing plain old copper Ethernet. If the boxes use off the > shelf Mellanox or Intel PCIe cards, it is not an issue. But silicon > vendors are integrating this into the SoC in the ARM way of doing > things, memory mapped, spread over a number of controllers, not a > single PCIe device. > > Maybe we need hybrid systems. Plain, old, simple, boring things like > CPUs, serial ports, SATA, PCIe busses are described in ACPI. Complex > interesting things are in DT. The hard thing is the interface between > the two. DT having a phandle to an ACPI object, e.g a GPIO, interrupt > or an i2c bus. > > Andrew
Just as a review reference, I have found an old attempted implementation documented here. https://github.com/CumulusNetworks/apd-tools/wiki
-Jon
| |