On 09/18/2014 07:20 PM, Rafael J. Wysocki wrote:
On Wednesday, September 17, 2014 04:40:36 PM Graeme Gregory wrote:
On Thu, Sep 18, 2014 at 01:22:10AM +0200, Arnd Bergmann wrote:
On Wednesday 17 September 2014, Graeme Gregory wrote:
It sounds like from the discussions in other threads that ARM64 should be following x86 and re-using DT bindings here. In which case there is not need to submit things to UEFI organisation.
What I got a little lost in has there been a formal decision about DT bindings in _DSD?
I think this is a discussion that still needs to happen: either we should recommend everyone to use _DSD in favor of the alternatives, or we should prohibit the use of _DSD. I have heard arguments both ways, but hopefully we can find an easy answer.
This discussion is just not going to happen until people at @redhat.com and people who have currently announced/released hardware are actually willing to start talking about it.
Id love to be able to put my foot down and ban the use of _DSD for servers but I suspect that will not happen.
I'll probably should stay away from this discussion, but I can't resist. :-)
Please imagine the situation in which the same IP block is included in an ARM64 SoC and in an x86 SoC that ships with ACPI tables and a _DSD for that device in them. What benefit would be there from disallowing systems based on the ARM64 SoC in question to ship the same _DSD in their ACPI tables?
"Disallowing" is a strong word in any case, because vendors own the platform and will ship _DSD properties to describe those devices. So the only "disallowing" Linux can do is to ignore entities present in ACPI tables that have already been shipped by vendors.
Anyway. I think we all don't want a runaway frenzy with _DSD key/values (generally there ought to be as few as possible, and additions should only happen carefully). Broadly, there are three levels I see here:
0). Devices that are part of the core ACPI specification. None today need key/value pairs, and I want to avoid this from growing. 1). Devices containing _DSD key/value pairs for a specific device but of a common industry type, such as a network device. In this case, the 4-6 properties that might need to be specified (MAC address, PHY address, PHY type, etc.) should be as minimal as possible and then standardized into a common binding that vendors agree to support, and which is owned and controlled by a neutral group such as ASWG. 2). Devices containining a specific ACPI ID that is unique to a given vendor where that device implements value-add/offload/something non core that can be owned entirely within a driver for one device. In that case, maybe a vendor would define a minimal set of _DSD key/values and be on the hook to maintain compatibility themselves.
I've chatted with a few people, and there will be a nice proposal presented to ASWG/UEFI on how to provide an official process for defining key/value pairs that are shared between common device types and managed by such a forum, as in the cases 0 and 1 above. In the meanwhile, there is only one _DSD use case in the early ACPI patches for ARM servers (in the network MAC, to pass in the mac address and a couple of PHY address/ID bits) and I've connected the vendors together asking them to come up with the initial first example covering that.
None of this is core to ACPI enablement. It's specific to a few drivers where also on x86 there will be _DSD properties.
Jon.