Message-ID: <20141129115209.GD7712@sirena.org.uk>
Date:	Sat, 29 Nov 2014 11:52:09 +0000
From:	Mark Brown <broonie@...nel.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Darren Hart <dvhart@...ux.intel.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Ben Zhang <benzh@...omium.org>,
	alsa-devel <alsa-devel@...a-project.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Bard Liao <bardliao@...ltek.com>,
	Oder Chiou <oder_chiou@...ltek.com>,
	Anatol Pomozov <anatol@...gle.com>,
	Dylan Reid <dgreid@...omium.org>, flove@...ltek.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] ASoC: rt5677: Add ACPI device probing

On Sat, Nov 29, 2014 at 12:51:59AM +0100, Rafael J. Wysocki wrote:
> On Friday, November 28, 2014 04:00:36 PM Mark Brown wrote:

> > OK, we probably should have one to aid discoverability since as far as I
> > can tell what's happening is that people (hi Intel!) are allocating
> > their own identifiers for devices produced by other vendors that turn up
> > on their boards.  If people can find the set of IDs in use there's more
> > chance they'll use the same ones as other people.

> There's the PRP0001 ID that can be use to in combination with the
> "compatible" property which then works the same way as for DT.

> That should be sufficient if the properties are going to be the
> same for ACPI (_DSD) and DT.

We've got people making BIOSs right now for systems you can actually buy 
that are intended to run Windows which we need to support; right now the
pressing problem I'm seeing is that we've got BIOS vendors not using
properties at all and we're going to be ending up with configuration
coming from big DMI tables instead which is miserable, Windows is
perfectly happy to have custom drivers installed per machine.  Do we
know if Windows supports PRP0001 as it currently stands?

> > If those are device IDs then what you're saying is what I'd expect to
> > happen and it's part of the reason I'd expect us to be registering IDs
> > along with registering properties - if people are defining device
> > specific properties they really ought to be tied to the IDs that are in
> > use especially if (as seems likely to be the case with the current state
> > of the world) people are doing things without attempting to coordinate
> > and we're ending up trying to document the deployed reality.

> The rule of thumb (in my view) should be that if the device object's _DSD is
> going to return the same set of properties as for DT and no other special
> handling determined by the ID is required (ie. nothing along the lines of
> "if the device ID is X, the _ABC method works like that" which has to be known
> by the driver), "PRP0001" should be returned by _HID and then the value of the
> "compatible" property should be the same as for DT.

This is a reasonable idea but we do need it to be compatible with
Windows and we still need to make sure we have a process in place that
BIOS authors and driver authors focused on Windows can reasonably be
expected to work with.  That's not something we have right now for DT
(our DT process involves contributing to Linux) so the problem remains
effectively the same.

We also need a way of getting the word out to people that they should be
doing this (also a problem no matter if we use PRP0001 or something UEFI
specific).

> Otherwise, a new device ID needs to be allocated for the device and _HID
> should return that ID.  Also, if the device is compatible with another
> device with an already allocated ID (for _HID), _CID may return the device ID
> of the compatible device.  [Of course, it's better if _HID is the same for
> identical devices.]

I honestly don't see BIOS authors as being likely to care about adding
things to the CID if their systems are working (I'm assuming that HID is
the primary device ID and CID are further backup compatible IDs).

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)

Powered by blists - more mailing lists