lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 18 Sep 2014 19:59:53 -0400 From: Jon Masters <jcm@...hat.com> To: "Rafael J. Wysocki" <rjw@...ysocki.net>, Graeme Gregory <gg@...mlogic.co.uk> CC: Arnd Bergmann <arnd@...db.de>, Graeme Gregory <graeme.gregory@...aro.org>, Matthew Garrett <mjg59@...f.ucam.org>, Hanjun Guo <hanjun.guo@...aro.org>, Catalin Marinas <catalin.marinas@....com>, Mark Rutland <mark.rutland@....com>, Olof Johansson <olof@...om.net>, Grant Likely <grant.likely@...aro.org>, Will Deacon <will.deacon@....com>, linaro-acpi@...ts.linaro.org, Liviu Dudau <Liviu.Dudau@....com>, Lv Zheng <lv.zheng@...el.com>, Rob Herring <robh@...nel.org>, Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>, Daniel Lezcano <daniel.lezcano@...aro.org>, Robert Moore <robert.moore@...el.com>, linux-acpi@...r.kernel.org, Charles.Garcia-Tobin@....com, Robert Richter <rric@...nel.org>, Jason Cooper <jason@...edaemon.net>, Marc Zyngier <marc.zyngier@....com>, Mark Brown <broonie@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, linux-arm-kernel@...ts.infradead.org, Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org, Sudeep Holla <Sudeep.Holla@....com> Subject: Re: [PATCH v4 18/18] Documentation: ACPI for ARM64 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-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists