Re: [PATCH v2] platform/x86: wmi: Use ACPI device name in netlink event
From: Hans de Goede
Date: Wed Jan 24 2024 - 06:06:24 EST
Hi,
On 1/22/24 16:03, Armin Wolf wrote:
> Am 22.01.24 um 13:47 schrieb Ilpo Järvinen:
>
>> On Mon, 22 Jan 2024, Hans de Goede wrote:
>>> On 1/21/24 21:08, Armin Wolf wrote:
>>>> The device name inside the ACPI netlink event is limited to
>>>> 15 characters, so the WMI device name will get truncated.
>>>>
>>>> This can be observed with kacpimon when receiving an event
>>>> from WMI device "9DBB5994-A997-11DA-B012-B622A1EF5492":
>>>>
>>>> netlink: 9DBB5994-A997- 000000d0 00000000
>>>>
>>>> Fix this by using the shorter device name from the ACPI
>>>> bus device instead. This still allows users to uniquely
>>>> identify the WMI device by using the notify id (0xd0).
>>>>
>>>> Signed-off-by: Armin Wolf <W_Armin@xxxxxx>
>>>> ---
>>>> Changes since v1:
>>>> - use acpi_dev_name() helper function
>>> I'm a bit divided on this patch. I agree the new way of doing
>>> things is better, but technically this is a bit of a userspace API
>>> break.
>>>
>>> I guess we could hope that nothing depends on the old netlink API
>>> format / name but I'm not sure we can rely on that ...
>>>
>>> Ilpo, Andy do you have any opinion on this ?
>> Hi Armin,
>>
>> Have you tried to conduct debian code search to find the code using this?
>>
> I did, but i found nothing.
>
> I am also preparing to properly initialize the device_class field in another patch,
> and this also has the potential of breaking userspace if some users created custom
> acpid configs to listen to those events.
>
> I think we can revert those changes anytime if someones turns out to be actually depending
> on them.
Based on the above I'm willing to go ahead with these changes, with
the note that we need to be prepared to revert this immediately if we
get any reports if this breaking userspace.
Given the (unlikely) potential breakage I think it would be good
to get this change into linux-next soon for maximum testing.
Reviewed-by: Hans de Goede <hdegoede@xxxxxxxxxx>
Regards,
Hans