From: Hans de Goede <hdegoede@redhat.com>
To: "Armin Wolf" <W_Armin@gmx.de>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Andy Shevchenko <andy@kernel.org>,
platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] platform/x86: wmi: Use ACPI device name in netlink event
Date: Wed, 24 Jan 2024 12:06:07 +0100 [thread overview]
Message-ID: <b057d7fe-aad1-4fc5-909d-6f45ff7969eb@redhat.com> (raw)
In-Reply-To: <f07b3156-2bc8-49bf-bc08-e40209b89cf1@gmx.de>
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@gmx.de>
>>>> ---
>>>> 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@redhat.com>
Regards,
Hans
next prev parent reply other threads:[~2024-01-24 11:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-21 20:08 [PATCH v2] platform/x86: wmi: Use ACPI device name in netlink event Armin Wolf
2024-01-22 11:29 ` Hans de Goede
2024-01-22 12:47 ` Ilpo Järvinen
2024-01-22 15:03 ` Armin Wolf
2024-01-24 11:06 ` Hans de Goede [this message]
2024-01-24 11:10 ` Ilpo Järvinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b057d7fe-aad1-4fc5-909d-6f45ff7969eb@redhat.com \
--to=hdegoede@redhat.com \
--cc=W_Armin@gmx.de \
--cc=andy@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox