Message-ID: <541B71F9.70008@redhat.com>
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