linux-kernel - Re: [PATCH 1/2] ASoC: rt5677: Add ACPI device probing

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2127240.rWRTDu6LHQ@vostro.rjw.lan>
Date:	Sat, 29 Nov 2014 00:51:59 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Mark Brown <broonie@...nel.org>
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 Friday, November 28, 2014 04:00:36 PM Mark Brown wrote:
> 
> --k9ssVBY1NpawPNl1
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> On Thu, Nov 27, 2014 at 12:09:55AM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 26, 2014 11:17:16 AM Mark Brown wrote:
> 
> > > > As to registering ACPI IDs, I believe this is the right link:
> > > > http://www.uefi.org/PNP_ACPI_Registry
> 
> > > No, those are vendors as far as I can tell.  I mean identifiers for
> > > specific devices - it appears to be common for for example Intel to
> > > allocate identifiers for devices they don't produce, I'd expect there to
> > > be some effort to keep track of that especially given that _DSD
> > > properties may well end up being specific to the identifier used to
> > > register in cases of parallel evolution.
> 
> > The vendor (or more precisely the owner of the initial 3 or 4 letter code)
> > is supposed to do that.  I'm not aware of any common registry of those IDs
> > for all vendors.
> 
> 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.

> > > > Or did you mean a HID/CID<->DSD mapping?
> 
> > > I don't really know what that is, sorry.
> 
> > The device ID is supposed to determine the way all of the ACPI objects for that
> > device will work, including what is returned by _DSD.  Pretty much in analogy
> > with PCI device IDs.
> 
> So the HID and CID are device IDs then?  Please bear in mind that we're
> not all familiar with the acronym soup that tends to go along with ACPI!

Yes, they are supposed to be treated this way.

> 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.

In other words, "PRP0001" means "a generic device with properties as returned
by _DSD".

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 speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/