* Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi
From: Dmitry Torokhov @ 2025-10-22 17:54 UTC (permalink / raw)
To: Hans de Goede
Cc: Ilpo Järvinen, Andy Shevchenko, linux-input,
platform-driver-x86
In-Reply-To: <20251020152331.52870-1-hansg@kernel.org>
Hi Hans,
On Mon, Oct 20, 2025 at 05:23:29PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is a patch series for adding support for the electronic privacy screen
> on/off events send on e.g. Dell Latitude 7300 models.
>
> On these laptops the firmware does not allow querying the presence nor
> the status of the eprivacy screen at boot. This makes it impossible to
> implement the drm connector eprivacy properties API (1) since drm objects
> do not allow adding new properties after creation and the presence of
> the eprivacy cannot be detected at boot.
>
> So instead this series adds 2 evdev keycodes for eprivacy screen on + off
> and modifies the dell-wmi driver to use these, so that we can still
> propagate these events to userspace for e.g. a DE to show an OSD.
>
> Dmitry, can we get your ack for the addition of the 2 new keycodes?
> I think it will be easiest if Ilpo merges the entire series through
> the pdx86 tree with your ack for the keycodes.
Yes, that should be fine, although I wonder if this is best modeled as a
pair of keys or a single switch? I know we have touchpad on/off but I
wonder if it was the best option... Probably more convenient at some
point if it was done through the atkbd.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list
From: April Grimoire @ 2025-10-22 16:37 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, jikos, April Grimoire
SONiX AK870 PRO keyboard pretends to be an apple keyboard by VID:PID,
rendering function keys not treated properly. Despite being a
SONiX USB DEVICE, it uses a different name, so adding it to the list.
Signed-off-by: April Grimoire <april@aprilg.moe>
---
drivers/hid/hid-apple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 61404d7a4..57da4f86a 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -355,6 +355,7 @@ static const struct apple_key_translation swapped_fn_leftctrl_keys[] = {
static const struct apple_non_apple_keyboard non_apple_keyboards[] = {
{ "SONiX USB DEVICE" },
+ { "SONiX AK870 PRO" },
{ "Keychron" },
{ "AONE" },
{ "GANSS" },
--
2.51.0
^ permalink raw reply related
* Re: [RFC 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress
From: Mario Limonciello @ 2025-10-22 16:40 UTC (permalink / raw)
To: Muhammad Usama Anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Greg Kroah-Hartman, Danilo Krummrich, Dmitry Torokhov,
Thomas Gleixner, Peter Zijlstra, linux-acpi, linux-kernel,
linux-pm, linux-input
Cc: kernel
In-Reply-To: <bd186145-c85c-41e3-bdc6-c2aaba4e874f@collabora.com>
On 10/22/25 11:33 AM, Muhammad Usama Anjum wrote:
> On 10/22/25 2:14 AM, Mario Limonciello (AMD) (kernel.org) wrote:
>>
>>
>> On 10/18/2025 9:21 AM, Muhammad Usama Anjum wrote:
>>> Serio drivers call input_handle_event(). Although the serio drivers have
>>> duplicate events, they have separate code path and call
>>> input_handle_event(). Ignore the KEY_POWER such that this event isn't
>>> sent to the userspace if hibernation is in progress.
>>>
>>> Abort the hibernation by calling pm awake API as well.
>>
>> So do you observe events both from ACPI and from input? Or was this patch based upon an earlier version of the ACPI patch?
> Yes, I observe events from both ACPI and input driver when power button is pressed.
> AFAIU this happens because of historic reasons of button wired through keyboard
> controller.
>
> The call to pm_wakeup_dev_event() can be removed. But I've added it for non-ACPI
> devices. Maybe those devices handle only input events through this path. Do you
> think this can be the case?
Well my point was if both are coming through - it's probably better to
just have pm_wakeup_dev_event() in input and pass the input event from ACPI.
> >
>> Because it feels like to me perhaps another way to solve this would be for patch 2 to to send the input event and just keep pm_wakeup_dev_event() here instead of both places.
> I was sending input event in patch 2 earlier. I was having difficulty in managing
> so many dependencies in acpi_button_notify(). It suspends the button events. I'll
> reiterate and see if I can achieve this in next series because this would be most
> clean solution.
OK!
>
>>
>>>
>>> Without this, the event is sent to the userspace and it suspends the
>>> device after hibernation cancellation.
>>>
>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
>>> ---
>>> drivers/input/input.c | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>>> index a500e1e276c21..0979f18aae6a2 100644
>>> --- a/drivers/input/input.c
>>> +++ b/drivers/input/input.c
>>> @@ -26,6 +26,7 @@
>>> #include <linux/kstrtox.h>
>>> #include <linux/mutex.h>
>>> #include <linux/rcupdate.h>
>>> +#include <linux/suspend.h>
>>> #include "input-compat.h"
>>> #include "input-core-private.h"
>>> #include "input-poller.h"
>>> @@ -362,6 +363,11 @@ void input_handle_event(struct input_dev *dev,
>>> lockdep_assert_held(&dev->event_lock);
>>> + if (code == KEY_POWER && hibernation_in_progress()) {
>>> + pm_wakeup_dev_event(&dev->dev, 0, true);
>>> + return;
>>> + }
>>> +
>>> disposition = input_get_disposition(dev, type, code, &value);
>>> if (disposition != INPUT_IGNORE_EVENT) {
>>> if (type != EV_SYN)
>>
>
>
^ permalink raw reply
* Re: [RFC 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress
From: Muhammad Usama Anjum @ 2025-10-22 16:33 UTC (permalink / raw)
To: Mario Limonciello (AMD) (kernel.org), Rafael J. Wysocki,
Len Brown, Pavel Machek, Greg Kroah-Hartman, Danilo Krummrich,
Dmitry Torokhov, Thomas Gleixner, Peter Zijlstra, linux-acpi,
linux-kernel, linux-pm, linux-input
Cc: usama.anjum, kernel
In-Reply-To: <7308c2c0-3881-445d-9771-fad5c3259518@kernel.org>
On 10/22/25 2:14 AM, Mario Limonciello (AMD) (kernel.org) wrote:
>
>
> On 10/18/2025 9:21 AM, Muhammad Usama Anjum wrote:
>> Serio drivers call input_handle_event(). Although the serio drivers have
>> duplicate events, they have separate code path and call
>> input_handle_event(). Ignore the KEY_POWER such that this event isn't
>> sent to the userspace if hibernation is in progress.
>>
>> Abort the hibernation by calling pm awake API as well.
>
> So do you observe events both from ACPI and from input? Or was this patch based upon an earlier version of the ACPI patch?
Yes, I observe events from both ACPI and input driver when power button is pressed.
AFAIU this happens because of historic reasons of button wired through keyboard
controller.
The call to pm_wakeup_dev_event() can be removed. But I've added it for non-ACPI
devices. Maybe those devices handle only input events through this path. Do you
think this can be the case?
>
> Because it feels like to me perhaps another way to solve this would be for patch 2 to to send the input event and just keep pm_wakeup_dev_event() here instead of both places.
I was sending input event in patch 2 earlier. I was having difficulty in managing
so many dependencies in acpi_button_notify(). It suspends the button events. I'll
reiterate and see if I can achieve this in next series because this would be most
clean solution.
>
>>
>> Without this, the event is sent to the userspace and it suspends the
>> device after hibernation cancellation.
>>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
>> ---
>> drivers/input/input.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>> index a500e1e276c21..0979f18aae6a2 100644
>> --- a/drivers/input/input.c
>> +++ b/drivers/input/input.c
>> @@ -26,6 +26,7 @@
>> #include <linux/kstrtox.h>
>> #include <linux/mutex.h>
>> #include <linux/rcupdate.h>
>> +#include <linux/suspend.h>
>> #include "input-compat.h"
>> #include "input-core-private.h"
>> #include "input-poller.h"
>> @@ -362,6 +363,11 @@ void input_handle_event(struct input_dev *dev,
>> lockdep_assert_held(&dev->event_lock);
>> + if (code == KEY_POWER && hibernation_in_progress()) {
>> + pm_wakeup_dev_event(&dev->dev, 0, true);
>> + return;
>> + }
>> +
>> disposition = input_get_disposition(dev, type, code, &value);
>> if (disposition != INPUT_IGNORE_EVENT) {
>> if (type != EV_SYN)
>
--
---
Thanks,
Usama
^ permalink raw reply
* Re: [RFC 1/4] PM: hibernate: export hibernation_in_progress()
From: Muhammad Usama Anjum @ 2025-10-22 16:27 UTC (permalink / raw)
To: Rafael J. Wysocki, Mario Limonciello (AMD) (kernel.org)
Cc: usama.anjum, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel
In-Reply-To: <CAJZ5v0hCxpWXdnoQeW79kaDFmHcfE0A4k7JuA9T+RR1OyCw29w@mail.gmail.com>
On 10/22/25 2:53 PM, Rafael J. Wysocki wrote:
> On Tue, Oct 21, 2025 at 11:07 PM Mario Limonciello (AMD) (kernel.org)
> <superm1@kernel.org> wrote:
>>
>>
>>
>> On 10/18/2025 9:21 AM, Muhammad Usama Anjum wrote:
>>> Export hibernation_in_progress() to be used by other modules. Add its
>>> signature when hibernation config isn't enabled as well.
>>
>> I wonder if you actually want to have pm_sleep_transition_in_progress()
>> exported instead. "Logically" I would expect cancelling a hibernate and
>> cancelling a suspend should work similarly.
>
> Well, it does AFAICS, except that only the "freeze" and "poweroff"
> transitions can be aborted during hibernation. This is analogous to
> aborting a suspend transition.
I'll switch up with pm_sleep_transition_in_progress().
>
> The missing part is a mechanism to cancel hibernation between image
> creation and the "poweroff" transition.
I'll add wakeup checking there and see if it works.
--
---
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH v7 5/9] platform/x86: asus-wmi: Add support for multiple kbd led handlers
From: kernel test robot @ 2025-10-22 13:38 UTC (permalink / raw)
To: Antheas Kapenekakis, platform-driver-x86, linux-input
Cc: oe-kbuild-all, linux-kernel, Jiri Kosina, Benjamin Tissoires,
Corentin Chary, Luke D . Jones, Hans de Goede, Ilpo Järvinen,
Denis Benato, Antheas Kapenekakis
In-Reply-To: <20251018101759.4089-6-lkml@antheas.dev>
Hi Antheas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 3a8660878839faadb4f1a6dd72c3179c1df56787]
url: https://github.com/intel-lab-lkp/linux/commits/Antheas-Kapenekakis/HID-asus-simplify-RGB-init-sequence/20251018-182410
base: 3a8660878839faadb4f1a6dd72c3179c1df56787
patch link: https://lore.kernel.org/r/20251018101759.4089-6-lkml%40antheas.dev
patch subject: [PATCH v7 5/9] platform/x86: asus-wmi: Add support for multiple kbd led handlers
config: i386-randconfig-141-20251020 (https://download.01.org/0day-ci/archive/20251022/202510222013.EBLC609m-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510222013.EBLC609m-lkp@intel.com/
New smatch warnings:
drivers/platform/x86/asus-wmi.c:1623 kbd_led_update_all() warn: always true condition '(value >= 0) => (0-u32max >= 0)'
Old smatch warnings:
drivers/platform/x86/asus-wmi.c:2288 asus_new_rfkill() warn: '*rfkill' is an error pointer or valid
vim +1623 drivers/platform/x86/asus-wmi.c
1589
1590 static void kbd_led_update_all(struct work_struct *work)
1591 {
1592 enum led_brightness value;
1593 struct asus_wmi *asus;
1594 bool registered, notify;
1595 int ret;
1596
1597 asus = container_of(work, struct asus_wmi, kbd_led_work);
1598
1599 scoped_guard(spinlock_irqsave, &asus_ref.lock) {
1600 registered = asus->kbd_led_registered;
1601 value = asus->kbd_led_wk;
1602 notify = asus->kbd_led_notify;
1603 }
1604
1605 if (!registered) {
1606 /*
1607 * This workqueue runs under asus-wmi, which means probe has
1608 * completed and asus-wmi will keep running until it finishes.
1609 * Therefore, we can safely register the LED without holding
1610 * a spinlock.
1611 */
1612 ret = devm_led_classdev_register(&asus->platform_device->dev,
1613 &asus->kbd_led);
1614 if (!ret) {
1615 scoped_guard(spinlock_irqsave, &asus_ref.lock)
1616 asus->kbd_led_registered = true;
1617 } else {
1618 pr_warn("Failed to register keyboard backlight LED: %d\n", ret);
1619 return;
1620 }
1621 }
1622
> 1623 if (value >= 0)
1624 do_kbd_led_set(&asus->kbd_led, value);
1625 if (notify) {
1626 scoped_guard(spinlock_irqsave, &asus_ref.lock)
1627 asus->kbd_led_notify = false;
1628 led_classdev_notify_brightness_hw_changed(&asus->kbd_led, value);
1629 }
1630 }
1631
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/3] Input: add TWL603x power button
From: Andreas Kemnade @ 2025-10-22 12:44 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: akemnade, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren, Kevin Hilman, devicetree,
linux-kernel, linux-input, linux-omap
In-Reply-To: <aalnnbzeajxgnq33go5b2gi72yjzeeun5f2pkbdulu2hwuz663@b65xssnkse7l>
On Tue, 21 Oct 2025 10:58:35 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Mon, Oct 20, 2025 at 02:31:59PM +0200, akemnade@kernel.org wrote:
> > From: Andreas Kemnade <andreas@kemnade.info>
> >
> > Like the TWL4030, these PMICs also have a power button feature, so add
> > a driver for it.
>
> Could it be integrated into twl4030-pwrbutton.c? I think the differences
> can be accounted for via a "chip" structure attached to a compatible...
>
So what is different:
- different register (but same bit)
- some custom irq stuff for 603x (so if (is_603x) needed)
- different name for the button (can be neglected I think)
Besides of adding a chip structure we can do it the same way
as rtc-twl.c is doing: using twl_class_is_xxxx() which derives
its return from the parents compatible. It is simplier, but
I think the chip structure does not hurt much either.
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH] Input: atkbd - skip deactivate for HONOR FMB-P's internal keyboard
From: Hans de Goede @ 2025-10-22 11:20 UTC (permalink / raw)
To: Cryolitia PukNgae, Dmitry Torokhov
Cc: linux-input, linux-kernel, stable, zhanjun, niecheng1, cryolitia,
Mingcong Bai, Kexy Biscuit, Mikura Kyouka, foad.elkhattabi
In-Reply-To: <20251022-honor-v1-1-ff894ed271a9@linux.dev>
Hi,
On 22-Oct-25 12:40 PM, Cryolitia PukNgae wrote:
> After commit 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd -
> do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID"), HONOR
> FMB-P, aka HONOR MagicBook Pro 14 2025's internal keyboard stops
> working. Adding the atkbd_deactivate_fixup quirk fixes it.
>
> DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025
>
> Fixes: 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID")
> Reported-by: Mikura Kyouka <mikurakyouka@aosc.io>
> Link: https://www.xiaohongshu.com/explore/68738d0a0000000012015a79
> Link: https://club.honor.com/cn/thread-29463529-1-1.html
> Link: https://club.honor.com/cn/thread-29490444-1-1.html
> Reported-by: foad.elkhattabi <foad.elkhattabi@gmail.com>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=220384
> Signed-off-by: Cryolitia PukNgae <cryolitia.pukngae@linux.dev>
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede <hansg@kernel.org>
Regards,
Hans
> ---
> drivers/input/keyboard/atkbd.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 6c999d89ee4b..422e28ad1e8e 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -1937,6 +1937,13 @@ static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
> },
> .callback = atkbd_deactivate_fixup,
> },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "HONOR"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "FMB-P"),
> + },
> + .callback = atkbd_deactivate_fixup,
> + },
> { }
> };
>
>
> ---
> base-commit: 552c50713f273b494ac6c77052032a49bc9255e2
> change-id: 20251022-honor-8bc9bef8eba7
>
> Best regards,
^ permalink raw reply
* [PATCH] Input: atkbd - skip deactivate for HONOR FMB-P's internal keyboard
From: Cryolitia PukNgae @ 2025-10-22 10:40 UTC (permalink / raw)
To: Dmitry Torokhov, Hans de Goede
Cc: linux-input, linux-kernel, stable, zhanjun, niecheng1, cryolitia,
Mingcong Bai, Kexy Biscuit, Hans de Goede, Mikura Kyouka,
foad.elkhattabi, Cryolitia PukNgae
After commit 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd -
do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID"), HONOR
FMB-P, aka HONOR MagicBook Pro 14 2025's internal keyboard stops
working. Adding the atkbd_deactivate_fixup quirk fixes it.
DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025
Fixes: 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID")
Reported-by: Mikura Kyouka <mikurakyouka@aosc.io>
Link: https://www.xiaohongshu.com/explore/68738d0a0000000012015a79
Link: https://club.honor.com/cn/thread-29463529-1-1.html
Link: https://club.honor.com/cn/thread-29490444-1-1.html
Reported-by: foad.elkhattabi <foad.elkhattabi@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=220384
Signed-off-by: Cryolitia PukNgae <cryolitia.pukngae@linux.dev>
---
drivers/input/keyboard/atkbd.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 6c999d89ee4b..422e28ad1e8e 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -1937,6 +1937,13 @@ static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
},
.callback = atkbd_deactivate_fixup,
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HONOR"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "FMB-P"),
+ },
+ .callback = atkbd_deactivate_fixup,
+ },
{ }
};
---
base-commit: 552c50713f273b494ac6c77052032a49bc9255e2
change-id: 20251022-honor-8bc9bef8eba7
Best regards,
--
Cryolitia PukNgae <cryolitia.pukngae@linux.dev>
^ permalink raw reply related
* Re: [RFC 1/4] PM: hibernate: export hibernation_in_progress()
From: Rafael J. Wysocki @ 2025-10-22 9:53 UTC (permalink / raw)
To: Mario Limonciello (AMD) (kernel.org)
Cc: Muhammad Usama Anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Greg Kroah-Hartman, Danilo Krummrich, Dmitry Torokhov,
Thomas Gleixner, Peter Zijlstra, linux-acpi, linux-kernel,
linux-pm, linux-input, kernel
In-Reply-To: <68a8c1ba-275c-4908-a4c8-2e8b83367703@kernel.org>
On Tue, Oct 21, 2025 at 11:07 PM Mario Limonciello (AMD) (kernel.org)
<superm1@kernel.org> wrote:
>
>
>
> On 10/18/2025 9:21 AM, Muhammad Usama Anjum wrote:
> > Export hibernation_in_progress() to be used by other modules. Add its
> > signature when hibernation config isn't enabled as well.
>
> I wonder if you actually want to have pm_sleep_transition_in_progress()
> exported instead. "Logically" I would expect cancelling a hibernate and
> cancelling a suspend should work similarly.
Well, it does AFAICS, except that only the "freeze" and "poweroff"
transitions can be aborted during hibernation. This is analogous to
aborting a suspend transition.
The missing part is a mechanism to cancel hibernation between image
creation and the "poweroff" transition.
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mfd: twl: enable power button also for twl603x
From: Andreas Kemnade @ 2025-10-22 8:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Tony Lindgren, Kevin Hilman, devicetree,
linux-kernel, linux-input, linux-omap
In-Reply-To: <7702e4f6-4913-4d9e-bbc4-1fb849507e4c@kernel.org>
On Tue, 21 Oct 2025 19:18:25 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 21/10/2025 18:36, Andreas Kemnade wrote:
> > On Tue, 21 Oct 2025 11:58:49 +0200
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> >> On 21/10/2025 10:45, Andreas Kemnade wrote:
> >>> On Tue, 21 Oct 2025 09:10:28 +0200
> >>> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>
> >>>> On 20/10/2025 14:31, akemnade@kernel.org wrote:
> >>>>> From: Andreas Kemnade <andreas@kemnade.info>
> >>>>>
> >>>>> TWL603x has also a power button, so add the corresponding subnode.
> >>>>
> >>>> No, we don't add subnodes just because there is a power button. This
> >>>> needs broader explanation, see also my further comment.
> >>>>
> >>> Hmm, what is the general pattern to follow if a mfd device has some
> >>> functionality which depends on some optional external components?
> >>
> >> Please describe it better - how these nodes depend on external
> >> component? The power button logic/IC is in this device always. It is not
> >> optional.
> >>
> > The power button logic is always there, yes, but it depends on an optional
> > actual mechanical button connected to a pad of this device, which is
> > not always there. The logic will not work if I just put my finger on the PMIC,
> > but it will work if there is a mechanical button which I can press connected to
> > the PMIC.
>
>
> Hm... how do you represent this logic now? By adding status=disabled to
> the pwrbutton node?
>
Yes, or by simply not adding tho pwrbutton node at all. Well, if we break
the legacy pattern here, we can probably add a property for this.
Regards,
Andreas
^ permalink raw reply
* Re: Bug#1114557: [PATCH v2] HID: quirks: Add device descriptor for 4c4a:4155
From: Salvatore Bonaccorso @ 2025-10-22 6:04 UTC (permalink / raw)
To: zhangheng, 1114557
Cc: Linux Hid, jikos, bentiss, staffan.melin, linux-input,
linux-kernel
In-Reply-To: <e605f642-c967-4d41-8145-a10e8f48fb1b@kylinos.cn>
Hi,
On Mon, Oct 13, 2025 at 04:32:39PM +0800, zhangheng wrote:
> It happened to be the holiday, so communication was a bit troublesome.
>
> However, after a brief discussion with the microphone manufacturer,
>
> it was found that the serial number was still 20201111000001 on another
>
> microphone device. So, should we add it?
As this issue still affects one of our users in Debian, is there
anything which can be done to unblock the situation? Does that mean
that the proposed patch is not good for the microphone device?
My understanding is that it fixes at least Staffan's case which
regressed from 1a8953f4f774 ("HID: Add IGNORE quirk for
SMARTLINKTECHNOLOGY").
Regards,
Salvatore
^ permalink raw reply
* RE: [PATCH] HID: intel-ish-hid: Fix -Wcast-function-type-strict in devm_ishtp_alloc_workqueue()
From: Zhang, Lixu @ 2025-10-22 0:57 UTC (permalink / raw)
To: srinivas pandruvada, Nathan Chancellor, Jiri Kosina,
Benjamin Tissoires
Cc: Kees Cook, linux-input@vger.kernel.org, llvm@lists.linux.dev,
patches@lists.linux.dev
In-Reply-To: <939f507b8e8d6768d42ed1d380500f3cd22aee88.camel@linux.intel.com>
>-----Original Message-----
>From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
>Sent: Wednesday, October 22, 2025 7:35 AM
>To: Nathan Chancellor <nathan@kernel.org>; Jiri Kosina <jikos@kernel.org>;
>Benjamin Tissoires <bentiss@kernel.org>; Zhang, Lixu <lixu.zhang@intel.com>
>Cc: Kees Cook <kees@kernel.org>; linux-input@vger.kernel.org;
>llvm@lists.linux.dev; patches@lists.linux.dev
>Subject: Re: [PATCH] HID: intel-ish-hid: Fix -Wcast-function-type-strict in
>devm_ishtp_alloc_workqueue()
>
>On Wed, 2025-10-22 at 00:49 +0200, Nathan Chancellor wrote:
>> Clang warns (or errors with CONFIG_WERROR=y / W=e):
>>
>> drivers/hid/intel-ish-hid/ipc/ipc.c:935:36: error: cast from 'void
>> (*)(struct workqueue_struct *)' to 'void (*)(void *)' converts to
>> incompatible function type [-Werror,-Wcast-function-type-strict]
>> 935 | if (devm_add_action_or_reset(dev, (void (*)(void
>> *))destroy_workqueue,
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> include/linux/device/devres.h:168:34: note: expanded from macro
>> 'devm_add_action_or_reset'
>> 168 | __devm_add_action_or_ireset(dev, action, data,
>> #action)
>> | ^~~~~~
>>
>> This warning is pointing out a kernel control flow integrity (kCFI /
>> CONFIG_CFI=y) violation will occur due to this function cast when the
>> destroy_workqueue() is indirectly called via devm_action_release()
>> because the prototype of destroy_workqueue() does not match the
>> prototype of (*action)().
>>
>> Use a local function with the correct prototype to wrap
>> destroy_workqueue() to resolve the warning and CFI violation.
>>
>> Closes: https://github.com/ClangBuiltLinux/linux/issues/2139
>> Fixes: 0d30dae38fe0 ("HID: intel-ish-hid: Use dedicated unbound
>> workqueues to prevent resume blocking")
>> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
>
>Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>
Reviewed-by: Zhang Lixu <lixu.zhang@intel.com>
>> ---
>> drivers/hid/intel-ish-hid/ipc/ipc.c | 8 ++++++--
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: Fix -Wcast-function-type-strict in devm_ishtp_alloc_workqueue()
From: srinivas pandruvada @ 2025-10-21 23:35 UTC (permalink / raw)
To: Nathan Chancellor, Jiri Kosina, Benjamin Tissoires, Zhang Lixu
Cc: Kees Cook, linux-input, llvm, patches
In-Reply-To: <20251022-ishtp-fix-function-cast-warn-v1-1-bfb06464f8ca@kernel.org>
On Wed, 2025-10-22 at 00:49 +0200, Nathan Chancellor wrote:
> Clang warns (or errors with CONFIG_WERROR=y / W=e):
>
> drivers/hid/intel-ish-hid/ipc/ipc.c:935:36: error: cast from 'void
> (*)(struct workqueue_struct *)' to 'void (*)(void *)' converts to
> incompatible function type [-Werror,-Wcast-function-type-strict]
> 935 | if (devm_add_action_or_reset(dev, (void (*)(void
> *))destroy_workqueue,
> |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/device/devres.h:168:34: note: expanded from macro
> 'devm_add_action_or_reset'
> 168 | __devm_add_action_or_ireset(dev, action, data,
> #action)
> | ^~~~~~
>
> This warning is pointing out a kernel control flow integrity (kCFI /
> CONFIG_CFI=y) violation will occur due to this function cast when the
> destroy_workqueue() is indirectly called via devm_action_release()
> because the prototype of destroy_workqueue() does not match the
> prototype of (*action)().
>
> Use a local function with the correct prototype to wrap
> destroy_workqueue() to resolve the warning and CFI violation.
>
> Closes: https://github.com/ClangBuiltLinux/linux/issues/2139
> Fixes: 0d30dae38fe0 ("HID: intel-ish-hid: Use dedicated unbound
> workqueues to prevent resume blocking")
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> drivers/hid/intel-ish-hid/ipc/ipc.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-
> ish-hid/ipc/ipc.c
> index 59355e4a61f8..abf9c9a31c39 100644
> --- a/drivers/hid/intel-ish-hid/ipc/ipc.c
> +++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
> @@ -924,6 +924,11 @@ static const struct ishtp_hw_ops ish_hw_ops = {
> .dma_no_cache_snooping = _dma_no_cache_snooping
> };
>
> +static void ishtp_free_workqueue(void *wq)
> +{
> + destroy_workqueue(wq);
> +}
> +
> static struct workqueue_struct *devm_ishtp_alloc_workqueue(struct
> device *dev)
> {
> struct workqueue_struct *wq;
> @@ -932,8 +937,7 @@ static struct workqueue_struct
> *devm_ishtp_alloc_workqueue(struct device *dev)
> if (!wq)
> return NULL;
>
> - if (devm_add_action_or_reset(dev, (void (*)(void
> *))destroy_workqueue,
> - wq))
> + if (devm_add_action_or_reset(dev, ishtp_free_workqueue, wq))
> return NULL;
>
> return wq;
>
> ---
> base-commit: 828aeac92901c1f31b51ae0b9d792b9af5bd3e27
> change-id: 20251021-ishtp-fix-function-cast-warn-660d3dae8af4
>
> Best regards,
> --
> Nathan Chancellor <nathan@kernel.org>
>
^ permalink raw reply
* [PATCH] HID: intel-ish-hid: Fix -Wcast-function-type-strict in devm_ishtp_alloc_workqueue()
From: Nathan Chancellor @ 2025-10-21 22:49 UTC (permalink / raw)
To: Srinivas Pandruvada, Jiri Kosina, Benjamin Tissoires, Zhang Lixu
Cc: Kees Cook, linux-input, llvm, patches, Nathan Chancellor
Clang warns (or errors with CONFIG_WERROR=y / W=e):
drivers/hid/intel-ish-hid/ipc/ipc.c:935:36: error: cast from 'void (*)(struct workqueue_struct *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
935 | if (devm_add_action_or_reset(dev, (void (*)(void *))destroy_workqueue,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/device/devres.h:168:34: note: expanded from macro 'devm_add_action_or_reset'
168 | __devm_add_action_or_ireset(dev, action, data, #action)
| ^~~~~~
This warning is pointing out a kernel control flow integrity (kCFI /
CONFIG_CFI=y) violation will occur due to this function cast when the
destroy_workqueue() is indirectly called via devm_action_release()
because the prototype of destroy_workqueue() does not match the
prototype of (*action)().
Use a local function with the correct prototype to wrap
destroy_workqueue() to resolve the warning and CFI violation.
Closes: https://github.com/ClangBuiltLinux/linux/issues/2139
Fixes: 0d30dae38fe0 ("HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blocking")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
drivers/hid/intel-ish-hid/ipc/ipc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c
index 59355e4a61f8..abf9c9a31c39 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -924,6 +924,11 @@ static const struct ishtp_hw_ops ish_hw_ops = {
.dma_no_cache_snooping = _dma_no_cache_snooping
};
+static void ishtp_free_workqueue(void *wq)
+{
+ destroy_workqueue(wq);
+}
+
static struct workqueue_struct *devm_ishtp_alloc_workqueue(struct device *dev)
{
struct workqueue_struct *wq;
@@ -932,8 +937,7 @@ static struct workqueue_struct *devm_ishtp_alloc_workqueue(struct device *dev)
if (!wq)
return NULL;
- if (devm_add_action_or_reset(dev, (void (*)(void *))destroy_workqueue,
- wq))
+ if (devm_add_action_or_reset(dev, ishtp_free_workqueue, wq))
return NULL;
return wq;
---
base-commit: 828aeac92901c1f31b51ae0b9d792b9af5bd3e27
change-id: 20251021-ishtp-fix-function-cast-warn-660d3dae8af4
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2 07/11] input: macsmc-hid: New driver to handle the Apple Mac SMC buttons/lid
From: Janne Grunau @ 2025-10-21 21:35 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: James Calligeros, Sven Peter, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Jean Delvare, Guenter Roeck, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, Hector Martin
In-Reply-To: <qffp7kadq3xojla5k6f5pr37irgytqfsqvabr6ydvulxnkcgnn@bv5mrraxrhhe>
On Fri, Aug 29, 2025 at 11:11:22AM +0000, Dmitry Torokhov wrote:
> Hi James,
>
> On Wed, Aug 27, 2025 at 09:22:41PM +1000, James Calligeros wrote:
> > +static void macsmc_hid_event_button(struct macsmc_hid *smchid, unsigned long event)
> > +{
> > + u8 button = (event >> 8) & 0xff;
> > + u8 state = !!(event & 0xff);
> > +
> > + switch (button) {
> > + case BTN_POWER:
> > + case BTN_TOUCHID:
> > + if (smchid->wakeup_mode) {
> > + if (state)
> > + pm_wakeup_hard_event(smchid->dev);
> > + } else {
> > + input_report_key(smchid->input, KEY_POWER, state);
> > + input_sync(smchid->input);
> > + }
>
> I believe you should be using pm_wakeup_event() in all cases so that
> pressing power would interrupt suspend even if resume() handler has not
> been run yet.
pm_wakeup_event() does not wake from s2idle. pm_wakeup_dev_event()'s
`hard` parameter is explicitily documented to wake from s2idle. So using
pm_wakeup_dev_event and use `smchid->wakeup_mode && state` as hard
parameter seems the correct thing to do.
> Also I do not think suppressing KEY_POWER is needed.
> Userspace should be smart and decide whether to shutdown the system or
> not when receiving KEY_POWER depending on the overall system state.
Not all user space. Using the power button to wake from s2idle while
showing agetty's login prompt on a tty results in an immediate shutdown.
Janne
^ permalink raw reply
* Re: [RFC 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress
From: Mario Limonciello (AMD) (kernel.org) @ 2025-10-21 21:14 UTC (permalink / raw)
To: Muhammad Usama Anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Greg Kroah-Hartman, Danilo Krummrich, Dmitry Torokhov,
Thomas Gleixner, Peter Zijlstra, linux-acpi, linux-kernel,
linux-pm, linux-input
Cc: kernel
In-Reply-To: <20251018142114.897445-4-usama.anjum@collabora.com>
On 10/18/2025 9:21 AM, Muhammad Usama Anjum wrote:
> Serio drivers call input_handle_event(). Although the serio drivers have
> duplicate events, they have separate code path and call
> input_handle_event(). Ignore the KEY_POWER such that this event isn't
> sent to the userspace if hibernation is in progress.
>
> Abort the hibernation by calling pm awake API as well.
So do you observe events both from ACPI and from input? Or was this
patch based upon an earlier version of the ACPI patch?
Because it feels like to me perhaps another way to solve this would be
for patch 2 to to send the input event and just keep
pm_wakeup_dev_event() here instead of both places.
>
> Without this, the event is sent to the userspace and it suspends the
> device after hibernation cancellation.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> ---
> drivers/input/input.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index a500e1e276c21..0979f18aae6a2 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -26,6 +26,7 @@
> #include <linux/kstrtox.h>
> #include <linux/mutex.h>
> #include <linux/rcupdate.h>
> +#include <linux/suspend.h>
> #include "input-compat.h"
> #include "input-core-private.h"
> #include "input-poller.h"
> @@ -362,6 +363,11 @@ void input_handle_event(struct input_dev *dev,
>
> lockdep_assert_held(&dev->event_lock);
>
> + if (code == KEY_POWER && hibernation_in_progress()) {
> + pm_wakeup_dev_event(&dev->dev, 0, true);
> + return;
> + }
> +
> disposition = input_get_disposition(dev, type, code, &value);
> if (disposition != INPUT_IGNORE_EVENT) {
> if (type != EV_SYN)
^ permalink raw reply
* Re: [RFC 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Mario Limonciello (AMD) (kernel.org) @ 2025-10-21 21:12 UTC (permalink / raw)
To: Muhammad Usama Anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Greg Kroah-Hartman, Danilo Krummrich, Dmitry Torokhov,
Thomas Gleixner, Peter Zijlstra, linux-acpi, linux-kernel,
linux-pm, linux-input
Cc: kernel
In-Reply-To: <20251018142114.897445-3-usama.anjum@collabora.com>
On 10/18/2025 9:21 AM, Muhammad Usama Anjum wrote:
> acpi_pm_wakeup_event() is called from acpi_button_notify() which is
> called when power button is pressed. But system doesn't wake up as
> pm_wakeup_dev_event() isn't called with hard parameter set in case of
> hibernation. It gets set only for s2idle cases.
>
> Call acpi_pm_wakeup_event() if power button is pressed and hibernation
> is in progress. Set the hard parameter such that pm_system_wakeup()
> gets called which increments pm_abort_suspend counter. Hence hibernation
> would be cancelled as in hibernation path, this counter is checked if it
> should be aborted.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> ---
> drivers/acpi/button.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index 0a70260401882..4a2575c0c44e3 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -20,6 +20,7 @@
> #include <linux/acpi.h>
> #include <linux/dmi.h>
> #include <acpi/button.h>
> +#include <linux/suspend.h>
>
> #define ACPI_BUTTON_CLASS "button"
> #define ACPI_BUTTON_FILE_STATE "state"
> @@ -458,11 +459,16 @@ static void acpi_button_notify(acpi_handle handle, u32 event, void *data)
> acpi_pm_wakeup_event(&device->dev);
>
> button = acpi_driver_data(device);
> - if (button->suspended || event == ACPI_BUTTON_NOTIFY_WAKE)
> - return;
> -
> input = button->input;
> keycode = test_bit(KEY_SLEEP, input->keybit) ? KEY_SLEEP : KEY_POWER;
> + if (event == ACPI_BUTTON_NOTIFY_STATUS && keycode == KEY_POWER &&
> + hibernation_in_progress()) {
> + pm_wakeup_dev_event(&device->dev, 0, true);
The comments for pm_wakeup_dev_event() say that hard is used
specifically for suspend to idle, but now you're overloading it.
So I think the comment in pm_wakeup_dev_event() needs to be updated if
this is the way forward.
> + return;
> + }
> +
> + if (button->suspended || event == ACPI_BUTTON_NOTIFY_WAKE)
> + return;
>
> input_report_key(input, keycode, 1);
> input_sync(input);
^ permalink raw reply
* Re: [RFC 1/4] PM: hibernate: export hibernation_in_progress()
From: Mario Limonciello (AMD) (kernel.org) @ 2025-10-21 21:07 UTC (permalink / raw)
To: Muhammad Usama Anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Greg Kroah-Hartman, Danilo Krummrich, Dmitry Torokhov,
Thomas Gleixner, Peter Zijlstra, linux-acpi, linux-kernel,
linux-pm, linux-input
Cc: kernel
In-Reply-To: <20251018142114.897445-2-usama.anjum@collabora.com>
On 10/18/2025 9:21 AM, Muhammad Usama Anjum wrote:
> Export hibernation_in_progress() to be used by other modules. Add its
> signature when hibernation config isn't enabled as well.
I wonder if you actually want to have pm_sleep_transition_in_progress()
exported instead. "Logically" I would expect cancelling a hibernate and
cancelling a suspend should work similarly.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> ---
> include/linux/suspend.h | 2 ++
> kernel/power/hibernate.c | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index b02876f1ae38a..348831cdb60e4 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -393,6 +393,7 @@ extern void hibernation_set_ops(const struct platform_hibernation_ops *ops);
> extern int hibernate(void);
> extern bool system_entering_hibernation(void);
> extern bool hibernation_available(void);
> +extern bool hibernation_in_progress(void);
> asmlinkage int swsusp_save(void);
> extern struct pbe *restore_pblist;
> int pfn_is_nosave(unsigned long pfn);
> @@ -412,6 +413,7 @@ static inline void hibernation_set_ops(const struct platform_hibernation_ops *op
> static inline int hibernate(void) { return -ENOSYS; }
> static inline bool system_entering_hibernation(void) { return false; }
> static inline bool hibernation_available(void) { return false; }
> +static inline bool hibernation_in_progress(void) { return false; }
>
> static inline int hibernate_quiet_exec(int (*func)(void *data), void *data) {
> return -ENOTSUPP;
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index 14e85ff235512..aadf82f57e868 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -105,6 +105,7 @@ bool hibernation_in_progress(void)
> {
> return !atomic_read(&hibernate_atomic);
> }
> +EXPORT_SYMBOL_GPL(hibernation_in_progress);
>
> bool hibernation_available(void)
> {
^ permalink raw reply
* [PATCH v4 2/2] dt-bindings: touchscreen: consolidate simple touch controller to trivial-touch.yaml
From: Frank Li @ 2025-10-21 20:19 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Job Noorman,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
In-Reply-To: <20251021201924.2881098-1-Frank.Li@nxp.com>
Move azoteq,iqs5xx.yaml, himax,hx83112b.yaml, hynitron,cstxxx.yaml,
ilitek_ts_i2c.yaml, semtech,sx8654.yaml, ar1021.txt to trivial-touch.yaml
to consolidate simple touch yaml binding to one file.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v4
- add Reviewed-by: Rob Herring review tags
- rebase to next since v2 already pickup.
change in v3
move more files into trivial-touch.yaml
don't add rob's review by because big change
prevous discussion at
https://lore.kernel.org/imx/175937443731.2982292.3723741722041625819.robh@kernel.org/T/#m35cfaaee8239b7a9aad3354b80de5f44d267c2e9
change in v2
move to trivial-touch.yaml
previous discussion
https://lore.kernel.org/imx/20250925-swimming-overspend-ddf7ab4a252c@spud/T/#t
---
.../input/touchscreen/azoteq,iqs5xx.yaml | 75 ------------------
.../input/touchscreen/himax,hx83112b.yaml | 64 ----------------
.../input/touchscreen/hynitron,cstxxx.yaml | 65 ----------------
.../input/touchscreen/ilitek_ts_i2c.yaml | 76 -------------------
.../input/touchscreen/semtech,sx8654.yaml | 52 -------------
.../input/touchscreen/trivial-touch.yaml | 29 +++++++
6 files changed, 29 insertions(+), 332 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs5xx.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/himax,hx83112b.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/hynitron,cstxxx.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/ilitek_ts_i2c.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs5xx.yaml b/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs5xx.yaml
deleted file mode 100644
index b5f377215c098..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs5xx.yaml
+++ /dev/null
@@ -1,75 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/input/touchscreen/azoteq,iqs5xx.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Azoteq IQS550/572/525 Trackpad/Touchscreen Controller
-
-maintainers:
- - Jeff LaBundy <jeff@labundy.com>
-
-description: |
- The Azoteq IQS550, IQS572 and IQS525 trackpad and touchscreen controllers
- employ projected-capacitance sensing and can track up to five independent
- contacts.
-
- Link to datasheet: https://www.azoteq.com/
-
-allOf:
- - $ref: touchscreen.yaml#
-
-properties:
- compatible:
- enum:
- - azoteq,iqs550
- - azoteq,iqs572
- - azoteq,iqs525
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- reset-gpios:
- maxItems: 1
-
- wakeup-source: true
-
- touchscreen-size-x: true
- touchscreen-size-y: true
- touchscreen-inverted-x: true
- touchscreen-inverted-y: true
- touchscreen-swapped-x-y: true
-
-required:
- - compatible
- - reg
- - interrupts
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
-
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- touchscreen@74 {
- compatible = "azoteq,iqs550";
- reg = <0x74>;
- interrupt-parent = <&gpio>;
- interrupts = <27 IRQ_TYPE_LEVEL_HIGH>;
- reset-gpios = <&gpio 22 (GPIO_ACTIVE_LOW |
- GPIO_PUSH_PULL)>;
-
- touchscreen-size-x = <800>;
- touchscreen-size-y = <480>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/himax,hx83112b.yaml b/Documentation/devicetree/bindings/input/touchscreen/himax,hx83112b.yaml
deleted file mode 100644
index f5cfacb5e966d..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/himax,hx83112b.yaml
+++ /dev/null
@@ -1,64 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/input/touchscreen/himax,hx83112b.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Himax hx83112b touchscreen controller
-
-maintainers:
- - Job Noorman <job@noorman.info>
-
-allOf:
- - $ref: touchscreen.yaml#
-
-properties:
- compatible:
- enum:
- - himax,hx83100a
- - himax,hx83112b
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- reset-gpios:
- maxItems: 1
-
- touchscreen-inverted-x: true
- touchscreen-inverted-y: true
- touchscreen-size-x: true
- touchscreen-size-y: true
- touchscreen-swapped-x-y: true
-
-additionalProperties: false
-
-required:
- - compatible
- - reg
- - interrupts
- - reset-gpios
- - touchscreen-size-x
- - touchscreen-size-y
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/gpio/gpio.h>
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
- touchscreen@48 {
- compatible = "himax,hx83112b";
- reg = <0x48>;
- interrupt-parent = <&tlmm>;
- interrupts = <65 IRQ_TYPE_LEVEL_LOW>;
- touchscreen-size-x = <1080>;
- touchscreen-size-y = <2160>;
- reset-gpios = <&tlmm 64 GPIO_ACTIVE_LOW>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/hynitron,cstxxx.yaml b/Documentation/devicetree/bindings/input/touchscreen/hynitron,cstxxx.yaml
deleted file mode 100644
index 9cb5d4af00f75..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/hynitron,cstxxx.yaml
+++ /dev/null
@@ -1,65 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/input/touchscreen/hynitron,cstxxx.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Hynitron cstxxx series touchscreen controller
-
-description: |
- Bindings for Hynitron cstxxx series multi-touch touchscreen
- controllers.
-
-maintainers:
- - Chris Morgan <macromorgan@hotmail.com>
-
-allOf:
- - $ref: touchscreen.yaml#
-
-properties:
- compatible:
- enum:
- - hynitron,cst340
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- reset-gpios:
- maxItems: 1
-
- touchscreen-size-x: true
- touchscreen-size-y: true
- touchscreen-inverted-x: true
- touchscreen-inverted-y: true
- touchscreen-swapped-x-y: true
-
-additionalProperties: false
-
-required:
- - compatible
- - reg
- - interrupts
- - reset-gpios
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
- touchscreen@1a {
- compatible = "hynitron,cst340";
- reg = <0x1a>;
- interrupt-parent = <&gpio4>;
- interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>;
- touchscreen-size-x = <640>;
- touchscreen-size-y = <480>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ilitek_ts_i2c.yaml b/Documentation/devicetree/bindings/input/touchscreen/ilitek_ts_i2c.yaml
deleted file mode 100644
index 9f73289997568..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/ilitek_ts_i2c.yaml
+++ /dev/null
@@ -1,76 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/input/touchscreen/ilitek_ts_i2c.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Ilitek I2C Touchscreen Controller
-
-maintainers:
- - Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
-allOf:
- - $ref: touchscreen.yaml#
-
-properties:
- compatible:
- enum:
- - ilitek,ili210x
- - ilitek,ili2117
- - ilitek,ili2120
- - ilitek,ili2130
- - ilitek,ili2131
- - ilitek,ili2132
- - ilitek,ili2316
- - ilitek,ili2322
- - ilitek,ili2323
- - ilitek,ili2326
- - ilitek,ili251x
- - ilitek,ili2520
- - ilitek,ili2521
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- reset-gpios:
- maxItems: 1
-
- wakeup-source:
- type: boolean
- description: touchscreen can be used as a wakeup source.
-
- touchscreen-size-x: true
- touchscreen-size-y: true
- touchscreen-inverted-x: true
- touchscreen-inverted-y: true
- touchscreen-swapped-x-y: true
-
-additionalProperties: false
-
-required:
- - compatible
- - reg
- - interrupts
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/gpio/gpio.h>
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- touchscreen@41 {
- compatible = "ilitek,ili2520";
- reg = <0x41>;
-
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
- reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
- touchscreen-inverted-y;
- wakeup-source;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml b/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
deleted file mode 100644
index b2554064b6888..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
+++ /dev/null
@@ -1,52 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/input/touchscreen/semtech,sx8654.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Semtech SX8654 I2C Touchscreen Controller
-
-maintainers:
- - Frank Li <Frank.Li@nxp.com>
-
-properties:
- compatible:
- enum:
- - semtech,sx8650
- - semtech,sx8654
- - semtech,sx8655
- - semtech,sx8656
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- reset-gpios:
- maxItems: 1
-
-required:
- - compatible
- - reg
- - interrupts
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
-
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- touchscreen@48 {
- compatible = "semtech,sx8654";
- reg = <0x48>;
- interrupt-parent = <&gpio6>;
- interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
index 46cf833344b11..fa27c6754ca4e 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
@@ -12,10 +12,39 @@ maintainers:
properties:
compatible:
enum:
+ # The Azoteq IQS550, IQS572 and IQS525 trackpad and touchscreen controllers
+ - azoteq,iqs550
+ - azoteq,iqs572
+ - azoteq,iqs525
+ # Himax hx83100a touchscreen controller
+ - himax,hx83100a
+ # Himax hx83112b touchscreen controller
+ - himax,hx83112b
+ # Hynitron cstxxx series touchscreen controller
+ - hynitron,cst340
+ # Ilitek I2C Touchscreen Controller
+ - ilitek,ili210x
+ - ilitek,ili2117
+ - ilitek,ili2120
+ - ilitek,ili2130
+ - ilitek,ili2131
+ - ilitek,ili2132
+ - ilitek,ili2316
+ - ilitek,ili2322
+ - ilitek,ili2323
+ - ilitek,ili2326
+ - ilitek,ili251x
+ - ilitek,ili2520
+ - ilitek,ili2521
# MAXI MAX11801 Resistive touch screen controller with i2c interface
- maxim,max11801
# Microchip AR1020 and AR1021 touchscreen interface (I2C)
- microchip,ar1021-i2c
+ # Trivial touch screen controller with i2c interface
+ - semtech,sx8650
+ - semtech,sx8654
+ - semtech,sx8655
+ - semtech,sx8656
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: touchscreen: trivial-touch: add reset-gpios and wakeup-source
From: Frank Li @ 2025-10-21 20:19 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Add optional reset-gpios and wakeup-source properties.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v4
- rebase to next since v2 already pick up
- pick rob review tags
change in v3
- add wakeup-source and reset-gpios optional properties
change in v2
new patch
previous discussion
https://lore.kernel.org/imx/20250925-swimming-overspend-ddf7ab4a252c@spud/T/#t
---
.../devicetree/bindings/input/touchscreen/trivial-touch.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
index d6aed3afd4acb..46cf833344b11 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
@@ -23,6 +23,11 @@ properties:
interrupts:
maxItems: 1
+ reset-gpios:
+ maxItems: 1
+
+ wakeup-source: true
+
allOf:
- $ref: touchscreen.yaml
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: touchscreen: rename maxim,max11801.yaml to trivial-touch.yaml
From: Dmitry Torokhov @ 2025-10-21 18:04 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, imx
In-Reply-To: <20251002164413.1112136-1-Frank.Li@nxp.com>
Hi Frank,
On Thu, Oct 02, 2025 at 12:44:04PM -0400, Frank Li wrote:
> Rename maxim,max11801.yaml to trivial-touch.yaml for simple i2c touch
> controller with one interrupt and common touch properties.
>
> Add optional reset-gpios and wakeup-source properties.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> change in v3
> - add wakeup-source and reset-gpios optional properties
Sorry I already applied v2. Could you please rebase on top of the
linux-next (or my next branch)?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/3] Input: add TWL603x power button
From: Dmitry Torokhov @ 2025-10-21 17:58 UTC (permalink / raw)
To: akemnade
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andreas Kemnade, Tony Lindgren, Kevin Hilman, devicetree,
linux-kernel, linux-input, linux-omap
In-Reply-To: <20251020-twl6030-button-v1-2-93e4644ac974@kernel.org>
On Mon, Oct 20, 2025 at 02:31:59PM +0200, akemnade@kernel.org wrote:
> From: Andreas Kemnade <andreas@kemnade.info>
>
> Like the TWL4030, these PMICs also have a power button feature, so add
> a driver for it.
Could it be integrated into twl4030-pwrbutton.c? I think the differences
can be accounted for via a "chip" structure attached to a compatible...
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Off-by-one error in CP2112 HID driver affecting SMBus block read output
From: Luis Yanes @ 2025-10-21 17:18 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Kosina, Benjamin Tissoires
In-Reply-To: <68F7C063.5049.ref@yahoo.es>
Affected file: drivers/hid/hid-cp2112.c
Kernel version: v5.15.195 (verified) - master (suspected)
Tool used: i2cget -y 8 0xb 0x78 s <-- reading a battery gauge chip
Observed behavior:
Incorrect trailing last byte in 32 bytes SMBus block read response.
Expected output:
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xaa
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x55
Actual SMBus block data read output:
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xaa
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x00
I2C block data read output (from i2cget -y 8 0xb 0x78 i):
0x20 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xaa 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Description:
When performing an SMBus block read using the CP2112 HID USB-to-SMBus
bridge with the i2cget utility, the last byte of the response for a
32 bytes block read is, in this case, always 0x00 instead of the actual
value. In this sample case shown above the actual last byte is 0x55 but
the driver returns 0x00 (uninitialized value).
This happens consistently for any 32 bytes block read on any register.
Shorter than 32 bytes block transfers are unaffected.
Suspected cause:
For what I could understand checking the source code this seems an
off-by-one error in the read request and buffer handling, limited by the
I2C_SMBUS_BLOCK_MAX 32 bytes read value and the response parsing logic
within the CP2112 driver since that with a custom hacked module
(see patch below) I could read that last byte.
Steps to reproduce:
1. Connect a CP2112 device and a proper slave device to read from.
2. Use i2cget to perform a known 32 bytes block read with this device:
i.e: i2cget -y 8 0xb 0x78 s
3. Compare the output against the expected data from the target
SMBus device. The last byte probably could appear as any other
uninitialized buffer value, I guess.
From 'i2cget -y 8 0xb 0x78 i' the initial 0x20 is the block
length and the last 32th byte is completely missing.
Impact:
This bug produces incorrect output and will lead to data corruption
or data misinterpretation when reading from SMBus devices using this
driver.
Suggested fix:
Review the buffer handling and read length in the CP2112 driver SMBus
and I2C block read and write implementations.
I have not checked if write operations are affected, but probably would
be a good idea to verify that the 32 bytes block transfers are handled
properly.
Additional info:
The issue is reproducible with different CP2112 devices (silicon rev F04)
and v5.15.x stock kernel builds. Probably also affects newer versions
since for what I could understand, despite the additional checking
changes added to the driver the logic seems basically the same.
Patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/drivers/hid/hid-cp2112.c?h=v5.15.195
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -703,7 +703,7 @@
case I2C_SMBUS_BLOCK_DATA:
if (I2C_SMBUS_READ == read_write) {
count = cp2112_write_read_req(buf, addr,
- I2C_SMBUS_BLOCK_MAX,
+ I2C_SMBUS_BLOCK_MAX + 1,
command, NULL, 0);
} else {
count = cp2112_write_req(buf, addr, command,
@@ -796,7 +796,7 @@
memcpy(data->block + 1, buf, read_length);
break;
case I2C_SMBUS_BLOCK_DATA:
- if (read_length > I2C_SMBUS_BLOCK_MAX) {
+ if (read_length > I2C_SMBUS_BLOCK_MAX + 1) {
ret = -EPROTO;
goto power_normal;
}
--
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD, Input, Power and Regulator due for the v6.19 merge window
From: Lee Jones @ 2025-10-21 17:25 UTC (permalink / raw)
To: samuel.kayode
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Liam Girdwood,
Mark Brown, Dmitry Torokhov, Sebastian Reichel, Frank Li, imx,
devicetree, linux-kernel, linux-input, linux-pm, Abel Vesa,
Abel Vesa, Robin Gong, Robin Gong, Enric Balletbo i Serra,
Sean Nyekjaer, Christophe JAILLET, Krzysztof Kozlowski,
Sebastian Reichel
In-Reply-To: <20251001-pf1550-v12-0-a3302aa41687@savoirfairelinux.com>
Enjoy!
The following changes since commit 3a8660878839faadb4f1a6dd72c3179c1df56787:
Linux 6.18-rc1 (2025-10-12 13:42:36 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-input-power-regulator-v6.19
for you to fetch changes up to a7d6255a0bf302c028ac680564633a6aac5f611d:
MAINTAINERS: Add an entry for PF1550 MFD driver (2025-10-21 16:59:07 +0100)
----------------------------------------------------------------
Immutable branch between MFD, Input, Power and Regulator due for the v6.19 merge window
----------------------------------------------------------------
Samuel Kayode (6):
dt-bindings: mfd: Add binding for the PF1550 PMIC
mfd: pf1550: Add core driver for the PF1550 PMIC
regulator: pf1550: Add support for regulator
Input: pf1550 - add onkey support
power: supply: pf1550: add battery charger support
MAINTAINERS: Add an entry for PF1550 MFD driver
.../devicetree/bindings/mfd/nxp,pf1550.yaml | 161 ++++++
MAINTAINERS | 11 +
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/pf1550-onkey.c | 197 +++++++
drivers/mfd/Kconfig | 16 +
drivers/mfd/Makefile | 2 +
drivers/mfd/pf1550.c | 367 ++++++++++++
drivers/power/supply/Kconfig | 11 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/pf1550-charger.c | 641 +++++++++++++++++++++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/pf1550-regulator.c | 429 ++++++++++++++
include/linux/mfd/pf1550.h | 273 +++++++++
15 files changed, 2131 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/nxp,pf1550.yaml
create mode 100644 drivers/input/misc/pf1550-onkey.c
create mode 100644 drivers/mfd/pf1550.c
create mode 100644 drivers/power/supply/pf1550-charger.c
create mode 100644 drivers/regulator/pf1550-regulator.c
create mode 100644 include/linux/mfd/pf1550.h
--
Lee Jones [李琼斯]
^ 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