* Re: [PATCH v2 13/16] leds: Use fwnode_for_each_child_node() instead
From: Jonathan Cameron @ 2025-09-29 9:51 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Laurent Pinchart, Paul Elder,
Mauro Carvalho Chehab, Horatiu Vultur, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Mark Brown, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-14-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:59 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> fwnode_for_each_child_node() is now the same as
> fwnode_for_each_available_child_node() on all backends (OF, ACPI and
> swnode). In order to remove the available variants, switch the uses to
> non-available variants.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 12/16] media: thp7312: Use fwnode_for_each_child_node() instead
From: Jonathan Cameron @ 2025-09-29 9:50 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Laurent Pinchart, Paul Elder,
Mauro Carvalho Chehab, Horatiu Vultur, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Mark Brown, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-13-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:58 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> fwnode_for_each_child_node() is now the same as
> fwnode_for_each_available_child_node() on all backends (OF, ACPI and
> swnode). In order to remove the available variants, switch the uses to
> non-available variants.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 11/16] Input: touch-overlay - Use fwnode_for_each_child_node() instead
From: Jonathan Cameron @ 2025-09-29 9:49 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Laurent Pinchart, Paul Elder,
Mauro Carvalho Chehab, Horatiu Vultur, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Mark Brown, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-12-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:57 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> fwnode_for_each_child_node() is now the same as
> fwnode_for_each_available_child_node() on all backends (OF, ACPI and
> swnode). In order to remove the available variants, switch the uses to
> non-available variants.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Another mechanical change.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> drivers/input/touch-overlay.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touch-overlay.c b/drivers/input/touch-overlay.c
> index b9fd82c4829d..7eaaaef1bd82 100644
> --- a/drivers/input/touch-overlay.c
> +++ b/drivers/input/touch-overlay.c
> @@ -82,7 +82,7 @@ int touch_overlay_map(struct list_head *list, struct input_dev *input)
> if (!overlay)
> return 0;
>
> - fwnode_for_each_available_child_node(overlay, fw_segment) {
> + fwnode_for_each_child_node(overlay, fw_segment) {
> segment = devm_kzalloc(dev, sizeof(*segment), GFP_KERNEL);
> if (!segment) {
> fwnode_handle_put(fw_segment);
^ permalink raw reply
* Re: [PATCH v2 10/16] net: lan966x: Use fwnode_for_each_child_node() instead
From: Jonathan Cameron @ 2025-09-29 9:48 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Laurent Pinchart, Paul Elder,
Mauro Carvalho Chehab, Horatiu Vultur, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Mark Brown, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-11-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:56 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> fwnode_for_each_child_node() is now the same as
> fwnode_for_each_available_child_node() on all backends (OF, ACPI and
> swnode). In order to remove the available variants, switch the uses to
> non-available variants.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
FWIW given mechanical change
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 09/16] driver core: Use fwnode_for_each_child_node() instead
From: Jonathan Cameron @ 2025-09-29 9:47 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Laurent Pinchart, Paul Elder,
Mauro Carvalho Chehab, Horatiu Vultur, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Mark Brown, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-10-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:55 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> fwnode_for_each_child_node() is now the same as
> fwnode_for_each_available_child_node() on all backends (OF, ACPI and
> swnode). In order to remove the available variants, switch the uses to
> non-available variants.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 08/16] property: Document that fwnode API returns available nodes
From: Jonathan Cameron @ 2025-09-29 9:44 UTC (permalink / raw)
To: Sakari Ailus, Krzysztof Kozlowski
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Laurent Pinchart, Paul Elder, Mauro Carvalho Chehab,
Horatiu Vultur, UNGLinuxDriver, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Mark Brown,
Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-9-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:54 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> The fwnode API has historically provided two functions to iterate over a
> fwnode's child nodes, fwnode_get_next_child_node() and
> fwnode_get_next_available_child_node() whereas all of the fwnode API has
> always worked on available nodes, apart unavailable ACPI child device
> nodes could have been returned by fwnode_get_next_child_node().
>
> Now that the availability check has been added to ACPI side as well,
> document that the functions in the fwnode API return available nodes.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 07/16] property: Drop DEVICE_DISABLED flag in fwnode_graph_get_endpoint_count()
From: Jonathan Cameron @ 2025-09-29 9:40 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sakari Ailus, linux-acpi, linux-kernel, linux-input, linux-leds,
linux-media, netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Paul Elder, Mauro Carvalho Chehab,
Horatiu Vultur, UNGLinuxDriver, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Mark Brown,
Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924100040.GA9827@pendragon.ideasonboard.com>
On Wed, 24 Sep 2025 13:00:40 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> On Wed, Sep 24, 2025 at 10:45:53AM +0300, Sakari Ailus wrote:
> > FWNODE_GRAPH_DEVICE_DISABLED flag isn't used anywhere, drop the flag and
> > support for it in fwnode_graph_get_endpoint_count().
> >
> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> With 06/16 squashed into this,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>
Agreed, doing them together makes the flag disappear so we don't have
to check manually that there are indeed no uses of it with the functions you
modify in patch 6.
With that,LGTM
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 05/16] property: Move Return: section of fwnode_graph_get_endpoint_by_id() down
From: Jonathan Cameron @ 2025-09-29 9:37 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Laurent Pinchart, Paul Elder,
Mauro Carvalho Chehab, Horatiu Vultur, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Mark Brown, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-6-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:51 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> Move Return: section of fwnode_graph_get_endpoint_by_id() down where it
> habitually is located.
I was rather expecting the kernel-doc documentation to specify this but
it only seems to do so by example. Hence reasonable to describe it as
you have.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 04/16] ACPI: property: Return present device nodes only on fwnode interface
From: Jonathan Cameron @ 2025-09-29 9:35 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Laurent Pinchart, Paul Elder,
Mauro Carvalho Chehab, Horatiu Vultur, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Mark Brown, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-5-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:50 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> fwnode_graph_get_next_subnode() may return fwnode backed by ACPI device
> nodes and there has been no check these devices are present in the system,
> unlike there has been on fwnode OF backend. In order to provide consistent
> behaviour towards callers, add a check for device presence by introducing
> a new function acpi_get_next_present_subnode(), used as the
> get_next_child_node() fwnode operation that also checks device node
> presence.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
I think this is fine because of the bit in the ACPI spec that says all
bits are set if _STA is missing. It seems much less likely we'll see
problems with hardware disappearing because _STA is there but says
the device isn't present.
Always a regression risk though :(
With the formatting changes Laurent asked for
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 02/16] ACPI: property: Use ACPI functions in acpi_graph_get_next_endpoint() only
From: Jonathan Cameron @ 2025-09-29 9:11 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Laurent Pinchart, Paul Elder,
Mauro Carvalho Chehab, Horatiu Vultur, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Mark Brown, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-3-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:48 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> Calling fwnode_get_next_child_node() in ACPI implementation of the fwnode
> property API is somewhat problematic as the latter is used in the
> impelementation of the former. Instead of using
> fwnode_get_next_child_node() in acpi_graph_get_next_endpoint(), call
> acpi_get_next_subnode() directly instead.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Makes sense to me on simply basis of making reasoning about it a little simpler.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 01/16] ACPI: property: Make acpi_get_next_subnode() static
From: Jonathan Cameron @ 2025-09-29 9:10 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, linux-input, linux-leds, linux-media,
netdev, linux-spi, Rafael J. Wysocki, Len Brown,
Greg Kroah-Hartman, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Javier Carrasco, Dmitry Torokhov,
Lee Jones, Pavel Machek, Matthias Fend, Chanwoo Choi,
Krzysztof Kozlowski, Laurent Pinchart, Paul Elder,
Mauro Carvalho Chehab, Horatiu Vultur, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Mark Brown, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20250924074602.266292-2-sakari.ailus@linux.intel.com>
On Wed, 24 Sep 2025 10:45:47 +0300
Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> acpi_get_next_subnode() is only used in drivers/acpi/property.c. Remove
> its prototype from include/linux/acpi.h and make it static.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH] Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak
From: Dmitry Torokhov @ 2025-09-29 4:29 UTC (permalink / raw)
To: Zhen Ni; +Cc: linux-input, stable
In-Reply-To: <20250928063737.74590-1-zhen.ni@easystack.cn>
On Sun, Sep 28, 2025 at 02:37:37PM +0800, Zhen Ni wrote:
> Struct ff_effect_compat is embedded twice inside
> uinput_ff_upload_compat, contains internal padding. In particular, there
> is a hole after struct ff_replay to satisfy alignment requirements for
> the following union member. Without clearing the structure,
> copy_to_user() may leak stack data to userspace.
>
> Initialize ff_up_compat to zero before filling valid fields.
Nicely spotted, thank you, applied.
--
Dmitry
^ permalink raw reply
* Re: [regression] 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") causes issue with ID 4c4a:4155 Jieli Technology USB Composite Device
From: Linux Hid @ 2025-09-29 0:39 UTC (permalink / raw)
To: Staffan Melin, zhangheng
Cc: Salvatore Bonaccorso, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel, regressions, stable, 1114557
In-Reply-To: <11f1363dcdec98f4275e4df3145e4f24@oscillator.se>
All,
It's good a working solution has been found. I'll comment separately on
the patch submission.
I did some digging to find out why there were multiple devices in the
wild with the same VID:PID.
It seems that Jieli does have a valid USB VID.
Zhuhai Jieli Technology Co., LTD owns VID 13908 (0x3654)
However, in one of their public SDKs they populate the default device
descriptor with:
'J', 'L', // idVendor: 0x4a4c - JL (actually 0x4c4a)
0x55, 0x41, // idProduct: chip id ('U', 'A' 0x4155)
So anyone developing a device using that chip's SDK who doesn't change
the default VID:PID will create a device with 4c4a:4155 VID:PID.
In other SDKs I see a different PID but the same 0x4c4a VID
'5', '4', // idProduct: chip id (0x3435)
So there are probably multiple devices in the wild with 4c4a:3435
VID:PIDs as well.
Here's a link to the 4c4a:4155 SDK if you'd like to take a look.
https://github.com/Jieli-Tech/AW30N/blob/main/sdk/apps/app/bsp/common/usb/device/descriptor.c#L31
Regards,
Terry
On 9/22/2025 11:33 AM, Staffan Melin wrote:
> Thank you,
>
> I can confirm that this patch fixes the touchscreen issue on my GPD DUO.
>
> Tested-by: staffan.melin@oscillator.se
>
> Thank you for your work!
>
> Staffan
>
> On 2025-09-22 11:21, zhangheng wrote:
>> Please help test this patch, I will push it to the kernel community.
>> Currently, the microphone device is functioning normally
^ permalink raw reply
* Re: [PATCH v2] HID: quirks: Add device descriptor for 4c4a:4155
From: Linux Hid @ 2025-09-29 0:42 UTC (permalink / raw)
To: Zhang Heng, jikos, bentiss, staffan.melin; +Cc: linux-input, linux-kernel
In-Reply-To: <20250923022445.3276026-1-zhangheng@kylinos.cn>
Hi Zhang,
The subject doesn't reflect what the patch is doing. You are not adding
a device descriptor, you are fixing a regression.
On 9/22/2025 7:24 PM, Zhang Heng wrote:
> Multiple USB devices have the same ID;
> add device descriptors to distinguish them.
>
> Fixes: 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY")
Should have a Fixes: tag referencing the regression bug.
Also a CC: tag for 1114557@bugs.debian.org
Possibly a CC: tag for stable@vger.kernel.org as well?
> Tested-by: staffan.melin@oscillator.se
> Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
> ---
> drivers/hid/hid-quirks.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> index ffd034566e2e..d28b180abd72 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -913,7 +913,6 @@ static const struct hid_device_id hid_ignore_list[] = {
> #endif
> { HID_USB_DEVICE(USB_VENDOR_ID_YEALINK, USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },
> { HID_USB_DEVICE(USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_HP_5MP_CAMERA_5473) },
> - { HID_USB_DEVICE(USB_VENDOR_ID_SMARTLINKTECHNOLOGY, USB_DEVICE_ID_SMARTLINKTECHNOLOGY_4155) },
> { }
> };
Smartlink Technology does not own the 0x4c4a VID or the 0x4155 PID. They
are an artifact of the Jieli SDK they used in development so the
#defines should not imply ownership by Smartlink. VID 0x4c4a is
currently unassigned by the USBIF and is therefore 'reserved'.
Maybe change
USB_VENDOR_ID_SMARTLINKTECHNOLOGY to USB_VENDOR_ID_JIELI_SDK_DEFAULT
and
USB_DEVICE_ID_SMARTLINKTRCHNOLOGY_4155 to USB_DEVICE_ID_JIELI_SDK_4155?
>
> @@ -1062,6 +1061,17 @@ bool hid_ignore(struct hid_device *hdev)
> strlen(elan_acpi_id[i].id)))
> return true;
> break;
> + case USB_VENDOR_ID_SMARTLINKTECHNOLOGY:
> + /* Multiple USB devices with identical IDs (mic & touchscreen).
> + * The touch screen requires hid core processing, but the
> + * microphone does not. They can be distinguished by manufacturer
> + * and serial number.
> + */
> + if (hdev->product == USB_DEVICE_ID_SMARTLINKTECHNOLOGY_4155 &&
> + strncmp(hdev->name, "SmartlinkTechnology", 19) == 0 &&
> + strncmp(hdev->uniq, "20201111000001", 14) == 0)
Using the serial number as a device identifier is somewhat risky. The
serial number is optional for a USB device but if it is used then it's
supposed to be unique for each device. Given how horrible the
configuration and HID descriptors are for this device it's unlikely that
they went to the trouble to give each unit a unique serial number. But
you should check a few of the devices (if you have more than one) to
verify they all have the same 20201111000001 serial number.
It's too bad the bcdHID version test for 0x0201 didn't work. The
hid->version field is filled by usbhid_probe with bcdDevice before both
hid_lookup_quirk and hid_ignore are called and then updated with bcdHID
by usbhid_parse after they have been called.
> + return true;
> + break;
> }
>
> if (hdev->type == HID_TYPE_USBMOUSE &&
Thanks
Terry
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 52e06d564ce6a5f03177922b2fa5667781d5ff83
From: kernel test robot @ 2025-09-28 22:56 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 52e06d564ce6a5f03177922b2fa5667781d5ff83 Input: aw86927 - add driver for Awinic AW86927
elapsed time: 1025m
configs tested: 144
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.1.0
alpha allyesconfig gcc-15.1.0
alpha defconfig gcc-15.1.0
arc allmodconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc allyesconfig gcc-15.1.0
arc defconfig gcc-15.1.0
arc randconfig-001-20250928 gcc-8.5.0
arc randconfig-002-20250928 gcc-8.5.0
arm allmodconfig gcc-15.1.0
arm allnoconfig clang-22
arm allyesconfig gcc-15.1.0
arm defconfig clang-22
arm nhk8815_defconfig clang-22
arm omap1_defconfig gcc-15.1.0
arm randconfig-001-20250928 clang-22
arm randconfig-002-20250928 clang-22
arm randconfig-003-20250928 clang-22
arm randconfig-004-20250928 clang-22
arm stm32_defconfig gcc-15.1.0
arm vt8500_v6_v7_defconfig gcc-15.1.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.1.0
arm64 defconfig gcc-15.1.0
arm64 randconfig-001-20250928 gcc-15.1.0
arm64 randconfig-002-20250928 gcc-9.5.0
arm64 randconfig-003-20250928 clang-17
arm64 randconfig-004-20250928 clang-22
csky allnoconfig gcc-15.1.0
csky defconfig gcc-15.1.0
csky randconfig-001-20250928 gcc-14.3.0
csky randconfig-002-20250928 gcc-15.1.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-22
hexagon allyesconfig clang-22
hexagon defconfig clang-22
hexagon randconfig-001-20250928 clang-22
hexagon randconfig-002-20250928 clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20250928 clang-20
i386 buildonly-randconfig-002-20250928 clang-20
i386 buildonly-randconfig-003-20250928 gcc-14
i386 buildonly-randconfig-004-20250928 clang-20
i386 buildonly-randconfig-005-20250928 clang-20
i386 buildonly-randconfig-006-20250928 clang-20
i386 defconfig clang-20
loongarch alldefconfig clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch defconfig clang-19
loongarch loongson3_defconfig clang-22
loongarch randconfig-001-20250928 gcc-15.1.0
loongarch randconfig-002-20250928 gcc-15.1.0
m68k allmodconfig gcc-15.1.0
m68k allnoconfig gcc-15.1.0
m68k allyesconfig gcc-15.1.0
m68k defconfig gcc-15.1.0
microblaze allmodconfig gcc-15.1.0
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig gcc-15.1.0
microblaze defconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
mips eyeq5_defconfig gcc-15.1.0
mips ip30_defconfig gcc-15.1.0
mips rb532_defconfig clang-18
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20250928 gcc-11.5.0
nios2 randconfig-002-20250928 gcc-8.5.0
openrisc allnoconfig gcc-15.1.0
openrisc allyesconfig gcc-15.1.0
openrisc defconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig gcc-15.1.0
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20250928 gcc-14.3.0
parisc randconfig-002-20250928 gcc-15.1.0
parisc64 defconfig gcc-15.1.0
powerpc adder875_defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig gcc-15.1.0
powerpc allyesconfig clang-22
powerpc bamboo_defconfig clang-22
powerpc randconfig-001-20250928 gcc-8.5.0
powerpc randconfig-002-20250928 clang-22
powerpc randconfig-003-20250928 gcc-8.5.0
powerpc socrates_defconfig gcc-15.1.0
powerpc tqm8555_defconfig gcc-15.1.0
powerpc64 randconfig-001-20250928 gcc-10.5.0
powerpc64 randconfig-002-20250928 clang-20
powerpc64 randconfig-003-20250928 clang-22
riscv allmodconfig clang-22
riscv allnoconfig gcc-15.1.0
riscv allyesconfig clang-16
riscv defconfig clang-22
riscv randconfig-001-20250928 gcc-11.5.0
riscv randconfig-002-20250928 gcc-13.4.0
s390 allmodconfig clang-18
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 defconfig clang-22
s390 randconfig-001-20250928 gcc-8.5.0
s390 randconfig-002-20250928 clang-18
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh ap325rxa_defconfig gcc-15.1.0
sh defconfig gcc-15.1.0
sh randconfig-001-20250928 gcc-15.1.0
sh randconfig-002-20250928 gcc-11.5.0
sh sh7710voipgw_defconfig gcc-15.1.0
sh sh7770_generic_defconfig gcc-15.1.0
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20250928 gcc-15.1.0
sparc randconfig-002-20250928 gcc-15.1.0
sparc64 defconfig clang-20
sparc64 randconfig-001-20250928 gcc-8.5.0
sparc64 randconfig-002-20250928 clang-22
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-14
um defconfig clang-22
um i386_defconfig gcc-14
um randconfig-001-20250928 gcc-14
um randconfig-002-20250928 clang-19
um x86_64_defconfig clang-22
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20250928 gcc-14
x86_64 buildonly-randconfig-002-20250928 gcc-14
x86_64 buildonly-randconfig-003-20250928 gcc-14
x86_64 buildonly-randconfig-004-20250928 gcc-14
x86_64 buildonly-randconfig-005-20250928 clang-20
x86_64 buildonly-randconfig-006-20250928 clang-20
x86_64 defconfig gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20250928 gcc-8.5.0
xtensa randconfig-002-20250928 gcc-10.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH][next] HID: hid-debug: Fix spelling mistake "Rechargable" -> "Rechargeable"
From: Colin Ian King @ 2025-09-28 21:01 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
Cc: kernel-janitors, linux-kernel
There is a spelling mistake in HID description. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
---
drivers/hid/hid-debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index 7107071c7c51..438a12046e86 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -2523,7 +2523,7 @@ static const struct hid_usage_entry hid_usage_table[] = {
{ 0x85, 0x0088, "iDeviceName" },
{ 0x85, 0x0089, "iDeviceChemistry" },
{ 0x85, 0x008a, "ManufacturerData" },
- { 0x85, 0x008b, "Rechargable" },
+ { 0x85, 0x008b, "Rechargeable" },
{ 0x85, 0x008c, "WarningCapacityLimit" },
{ 0x85, 0x008d, "CapacityGranularity1" },
{ 0x85, 0x008e, "CapacityGranularity2" },
--
2.51.0
^ permalink raw reply related
* [PATCH] HID: quirks: avoid Cooler Master MM712 dongle wakeup bug
From: Tristan Lobb @ 2025-09-28 16:25 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input, linux-kernel, Tristan Lobb
The Cooler Master Mice Dongle includes a vendor defined HID interface
alongside its mouse interface. Not polling it will cause the mouse to
stop responding to polls on any interface once woken up again after
going into power saving mode.
Add the HID_QUIRK_ALWAYS_POLL quirk alongside the Cooler Master VID and
the Dongle's PID.
Signed-off-by: Tristan Lobb <tristan.lobb@it-lobb.de>
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-quirks.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 149798754570..47a7f295764b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -342,6 +342,9 @@
#define USB_DEVICE_ID_CODEMERCS_IOW_FIRST 0x1500
#define USB_DEVICE_ID_CODEMERCS_IOW_LAST 0x15ff
+#define USB_VENDOR_ID_COOLER_MASTER 0x2516
+#define USB_DEVICE_ID_COOLER_MASTER_MICE_DONGLE 0x01b7
+
#define USB_VENDOR_ID_CORSAIR 0x1b1c
#define USB_DEVICE_ID_CORSAIR_K90 0x1b02
#define USB_DEVICE_ID_CORSAIR_K70R 0x1b09
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index f619ed10535d..95acc3f76d4b 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -57,6 +57,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FLIGHT_SIM_YOKE), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_PEDALS), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_THROTTLE), HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_COOLER_MASTER, USB_DEVICE_ID_COOLER_MASTER_MICE_DONGLE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE), HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70RGB), HID_QUIRK_NO_INIT_REPORTS },
--
2.51.0
^ permalink raw reply related
* [PATCH] Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak
From: Zhen Ni @ 2025-09-28 6:37 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, Zhen Ni, stable
Struct ff_effect_compat is embedded twice inside
uinput_ff_upload_compat, contains internal padding. In particular, there
is a hole after struct ff_replay to satisfy alignment requirements for
the following union member. Without clearing the structure,
copy_to_user() may leak stack data to userspace.
Initialize ff_up_compat to zero before filling valid fields.
Fixes: 2d56f3a32c0e ("Input: refactor evdev 32bit compat to be shareable with uinput")
Cc: stable@vger.kernel.org
Signed-off-by: Zhen Ni <zhen.ni@easystack.cn>
---
drivers/input/misc/uinput.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 2c51ea9d01d7..13336a2fd49c 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -775,6 +775,7 @@ static int uinput_ff_upload_to_user(char __user *buffer,
if (in_compat_syscall()) {
struct uinput_ff_upload_compat ff_up_compat;
+ memset(&ff_up_compat, 0, sizeof(ff_up_compat));
ff_up_compat.request_id = ff_up->request_id;
ff_up_compat.retval = ff_up->retval;
/*
--
2.20.1
^ permalink raw reply related
* Re: [PATCH RESEND v3 2/3] Input: aw86927 - add driver for Awinic AW86927
From: Dmitry Torokhov @ 2025-09-28 5:03 UTC (permalink / raw)
To: Griffin Kroah-Hartman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Luca Weiss, linux-input, devicetree, linux-kernel,
linux-arm-msm
In-Reply-To: <20250925-aw86927-v3-2-1fc6265b42de@fairphone.com>
On Thu, Sep 25, 2025 at 12:07:29PM +0200, Griffin Kroah-Hartman wrote:
> Add support for the I2C-connected Awinic AW86927 LRA haptic driver.
>
> This driver includes a hardcoded sine waveform to be uploaded to the
> AW86927's SRAM for haptic playback.
> This driver does not currently support all the capabilities of the
> AW86927, such as F0 calibration, RTP mode, and CONT mode.
>
> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
Added missing header, changed uint8_t to u8, changed some formatting and
applied, thank you.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND v3 1/3] dt-bindings: input: Add Awinic AW86927
From: Dmitry Torokhov @ 2025-09-28 5:01 UTC (permalink / raw)
To: Griffin Kroah-Hartman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Luca Weiss, linux-input, devicetree, linux-kernel,
linux-arm-msm, Krzysztof Kozlowski
In-Reply-To: <20250925-aw86927-v3-1-1fc6265b42de@fairphone.com>
On Thu, Sep 25, 2025 at 12:07:28PM +0200, Griffin Kroah-Hartman wrote:
> Add bindings for the Awinic AW86927 haptic chip which can be found in
> smartphones.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND v3 2/3] Input: aw86927 - add driver for Awinic AW86927
From: Dmitry Torokhov @ 2025-09-28 4:10 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Griffin Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Luca Weiss,
linux-input, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <81822df8-1978-4f22-93e7-87b79e1fc9f3@oss.qualcomm.com>
On Thu, Sep 25, 2025 at 02:15:42PM +0200, Konrad Dybcio wrote:
> On 9/25/25 12:07 PM, Griffin Kroah-Hartman wrote:
> > +static int aw86927_wait_enter_standby(struct aw86927_data *haptics)
> > +{
> > + unsigned int reg_val;
> > + int err;
>
> "ret" is more common (for "return value")
I requested this, "error" or "err" is my preference for temporaries that
hold either a negative error code or 0.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
From: Guenter Roeck @ 2025-09-28 2:09 UTC (permalink / raw)
To: James Calligeros, Janne Grunau, Rob Herring
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Dmitry Torokhov, asahi, linux-arm-kernel,
devicetree, linux-kernel, linux-rtc, linux-hwmon, linux-input
In-Reply-To: <2537878.PYKUYFuaPT@setsuna>
On 9/27/25 17:36, James Calligeros wrote:
> Hi Rob,
>
> On Friday, 26 September 2025 7:43:23 am Australian Eastern Standard Time Rob
> Herring wrote:
>> On Thu, Sep 25, 2025 at 3:49 PM Janne Grunau <j@jannau.net> wrote:
>>> On Fri, Aug 29, 2025 at 11:40:57AM -0500, Rob Herring wrote:
>>>>
>>>> This should be something like this:
>>>>
>>>> "^current-[A-Za-z0-9]{4}$":
>>>> $ref: "#/$defs/sensor"
>>>> unevaluatedProperties: false
>>>>
>>>> With the $defs/sensor being:
>>>>
>>>> $defs:
>>>> sensor:
>>>> type: object
>>>>
>>>> properties:
>>>> apple,key-id:
>>>> $ref: /schemas/types.yaml#/definitions/string
>>>> pattern: "^[A-Za-z0-9]{4}$"
>>>>
>>>> description:
>>>> The SMC FourCC key of the desired sensor. Must match the
>>>> node's suffix.
>>>>
>>>> label:
>>>> description: Human-readable name for the sensor
>>>>
>>>> required:
>>>> - apple,key-id
>>>> - label
>>>>
>>>> Though in general, 'label' should never be required being just for human
>>>> convenience.
>>>
>>> That does not sound as it would be compatible with skipping nodes in the
>>> driver if the node misses label. The driver could of course fall back
>>> to create a hwmon sensors without labels.
>>
>> The driver absolutely should.
>
> The original submission (and our downstream version) do this, but I changed
> it for v2 per Sven's feedback [1]. Outside of development/experimentation,
> we will (should) never have a sensor in the Devicetree of uknown utility.
> If we know what a sensor is for, then we should have a label for it.
>
Label attributes are optional in hwmon drivers. Period.
Guenter
^ permalink raw reply
* Re: [PATCH v5] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Stuart @ 2025-09-28 1:54 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis
Cc: jikos, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <20250927234834.2635483-1-mavchatz@protonmail.com>
Still working :)
Tested-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Thanks,
Stuart
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Mavroudis Chatzilazaridis @ 2025-09-28 0:50 UTC (permalink / raw)
To: Stuart; +Cc: jikos, linux-input, hadess, lains, benjamin.tissoires
In-Reply-To: <CALTg27nCi-cyY-C=Vsi3zXqHsk+M3uMyJ8U35vmxp8YNiqU9-w@mail.gmail.com>
On 2025-09-27 19:58, Stuart wrote:
> Hey, I've been keeping an eye out for the v5, did I miss it?
>
> Thanks,
> Stuart
Sorry for the delay. Things were busier than expected and I wanted to
investigate the protocol error that was printed in the kernel log.
I have now sent out the v5. You can find it here:
https://lore.kernel.org/linux-input/20250927234834.2635483-1-mavchatz@protonmail.com/T/
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
From: James Calligeros @ 2025-09-28 0:36 UTC (permalink / raw)
To: Janne Grunau, Rob Herring
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input
In-Reply-To: <CAL_JsqK-9n3_H6vS80bZuZiSPi9UNuMzHEPFL_EzYTeyNS1cYg@mail.gmail.com>
Hi Rob,
On Friday, 26 September 2025 7:43:23 am Australian Eastern Standard Time Rob
Herring wrote:
> On Thu, Sep 25, 2025 at 3:49 PM Janne Grunau <j@jannau.net> wrote:
> > On Fri, Aug 29, 2025 at 11:40:57AM -0500, Rob Herring wrote:
> > >
> > > This should be something like this:
> > >
> > > "^current-[A-Za-z0-9]{4}$":
> > > $ref: "#/$defs/sensor"
> > > unevaluatedProperties: false
> > >
> > > With the $defs/sensor being:
> > >
> > > $defs:
> > > sensor:
> > > type: object
> > >
> > > properties:
> > > apple,key-id:
> > > $ref: /schemas/types.yaml#/definitions/string
> > > pattern: "^[A-Za-z0-9]{4}$"
> > >
> > > description:
> > > The SMC FourCC key of the desired sensor. Must match the
> > > node's suffix.
> > >
> > > label:
> > > description: Human-readable name for the sensor
> > >
> > > required:
> > > - apple,key-id
> > > - label
> > >
> > > Though in general, 'label' should never be required being just for human
> > > convenience.
> >
> > That does not sound as it would be compatible with skipping nodes in the
> > driver if the node misses label. The driver could of course fall back
> > to create a hwmon sensors without labels.
>
> The driver absolutely should.
The original submission (and our downstream version) do this, but I changed
it for v2 per Sven's feedback [1]. Outside of development/experimentation,
we will (should) never have a sensor in the Devicetree of uknown utility.
If we know what a sensor is for, then we should have a label for it.
> > I looks to me it would be a
> > stretch to call the presence of the labels human convenience.
>
> Then it is an abuse of 'label". "label" is supposed to be literally
> that. Matching a sticker on a port of a device.
>
> If you need to associate a sensor with some other piece of h/w, then
> that should be via a phandle or something.
I don't think doing so is particularly useful for this platform. Few of
the sensors that we know about are directly related to any one piece of
hardware.
It's pretty much just the CPU cores and Broadcom module. The rest are things
like fans, palm rest area temperature sensors, ammeters and voltmeters for
entire
rails, etc.
Even where we can reliably associate a sensor to a piece of hardware,
(e.g. the WiFi/BT board), doing so does not by itself do anything useful. We
still need to write a human-readable label for the sensor.
I was trying to avoid yet another vendor property, but would something like
'apple,sensor-label' work here?
> Rob
James
[1]: https://lore.kernel.org/asahi/4a95cbf3-b3ae-4b26-8db2-dd5cf14a4c0c@kernel.org/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox