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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
