On Tue, May 14, 2019 at 12:59 PM Yurii Pavlovskyi
<yurii.pavlovskyi@xxxxxxxxx> wrote:
>
> Add a new function to acpi.h / wmi.c that returns _UID of the ACPI WMI
> device. For example, it returns "ATK" for the following declaration in
> DSDT:
> Device (ATKD)
> {
> Name (_HID, "PNP0C14" /* Windows Management Instrumentation Device */)
> // _HID: Hardware ID
> Name (_UID, "ATK") // _UID: Unique ID
> ..
>
> Generally, it is possible that multiple PNP0C14 ACPI devices are present in
> the system as mentioned in the commit message of commit bff431e49ff5
> ("ACPI: WMI: Add ACPI-WMI mapping driver").
>
> Therefore the _UID is returned for a specific ACPI device that declares the
> given GUID, to which it is also mapped by other methods of wmi module.
>
> Signed-off-by: Yurii Pavlovskyi <yurii.pavlovskyi@xxxxxxxxx>
Some extra background may be useful when reviewing this.
As researched in
https://marc.info/?l=linux-kernel&m=155498017207933&w=2, we are
dealing with a tricky situation.
asus-wmi currently serves two different classes of device: eeepci-wmi
and asus-nb-wmi.
The eeepci devices have:
_WDG : includes a METHOD block with GUID ASUS_WMI_MGMT_GUID, and an
EVENT block with GUID EEEPC_WMI_EVENT_GUID
_UID : ASUSWMI
The asus-nb-wmi devices have:
_ WDG : includes a METHOD block with GUID ASUS_WMI_MGMT_GUID (same as
eeepc), and an EVENT block with GUID ASUS_NB_WMI_EVENT_GUID
_UID : ATK
To support new devices we now need to start concretely identifying
which of these we are working with. But complications include:
- The main MGMT_GUID used for matching at the moment is shared over
both device types
- Some Asus products have both of these (via two separate two
separate PNP0C14 WMI devices).
Currently eeepci-wmi and asus-nb-wmi register themselves with
asus-wmi, which registers a platform device for each one. The platform
dev probe then succeeds the platform device probe when it finds any
_WDG entry for the main MGMT_GUID and the _WDG entry for the
corresponding event GUID (not necessarily as part of the same
underlying ACPI Device). In the case of both devices being present
with duplicate MGMT, the first one that is parsed wins, and the other
is ignored (see guid_already_parsed()).
Sticking with the current approach, which is imperfect for devices
that have both devices, adding a method to detect the _UID seems
reasonable. Although actually I just realised you could probably also
detect the difference by using wmi_has_guid() on the EVENT UUID
without having to add a new function.
I'll keep thinking about how to improve the situation around two
devices present (but don't want to needlessly conflate this patch
series with that).
Daniel
