On 31/07/2020 16:14, Andrew Lunn wrote:
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?
As i said, path of least resistance. It is here today, heavily used,
well understood by lots of network developers, has a very active
maintainer in the form of Rob Herring, and avoids 'showflakes' as
Florian likes to call it, so we are all sharing the same code,
providing a lot of testing and maintenance.
Andrew
Hi Andrew,
I'm just coming into this thread now. With my alumni DT-maintainer had
on I think that trying to use ACPI & DT on the same system is the worst
of both worlds. Trying to do so makes the solution far more complicated
than either an ACPI-only or DT-only approach. There is no good way for
references between DT & ACPI nodes. I have serious doubts about the
reliability of the dynamic DT code in the kernel. Perhaps most
problematic is it excludes platform specific data from the ACPI
description provided by firmware, which means platform-specific data
needs to be shipped with the OS. Rather defeats the whole point of
firmware providing the platform description. An ACPI solution is
absolutely needed.
Regarding this specific series, I think it is approximately the right
approach. I have some specific concerns that I've talked with Calvin
about and I'm going to post as replies to the individual patches. My
most significant concern is the reference from the ACPI MAC node to the
MDIO node, which makes little sense. The MAC should have a reference to
the PHY node.
There have been other issues raised in this thread. I'm going to go back
and respond to a few of those points in separate emails, but as a larger
issue I think there is a fair bit of misunderstanding on what ACPI does
and does not do, and how much is expected to be standardized in ACPI
specs. In the ACPI world the typical model is the firmware/platform
vendor decides what data to put into the ACPI nodes that works for them,
and then the OS just has to deal with it. Linux typically never gets a
choice about what goes into ACPI nodes.
Already, threads like this one are setting the bar *far* higher on ACPI
schema than has ever been done before. I do think it is right to be
asking for a common data model for describing PHY connections. Lining
the model up with the DT PHY model is also valuable because we can use
common code. I also think as first through the door, what gets accepted
(after review) for the layerscape platforms here should become the
defacto standard that other vendors are expected to adopt, and I have
very high confidence that it will be acceptable because it follow the
pattern already used in devicetree.
Cheers,
g.
