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