* [PATCH v1 0/1] input: touchscreen: atmel_mxt_ts: add support for generic touchscreen configurations
From: Svyatoslav Ryhel @ 2025-09-03 16:23 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov, Henrik Rydberg, Svyatoslav Ryhel
Cc: linux-input, linux-kernel
This provides support for generic touchscreen configuration options like
swapped-x-y, min-x, min-y, size-x, size-y, etc.
Svyatoslav Ryhel (1):
input: touchscreen: atmel_mxt_ts: add support for generic touchscreen
configurations
drivers/input/touchscreen/atmel_mxt_ts.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--
2.48.1
^ permalink raw reply
* [PATCH v1 2/2] ARM: tegra: p880: set correct touchscreen clipping
From: Svyatoslav Ryhel @ 2025-09-03 16:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Dmitry Torokhov, Svyatoslav Ryhel,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel, linux-input
In-Reply-To: <20250903161947.109328-1-clamor95@gmail.com>
From: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Existing touchscreen clipping is too small and causes problems with
touchscreen accuracy.
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
index 2f7754fd42a1..c6ef0a20c19f 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
@@ -108,8 +108,8 @@ sub-mic-ldo {
i2c@7000c400 {
touchscreen@20 {
rmi4-f11@11 {
- syna,clip-x-high = <1110>;
- syna,clip-y-high = <1973>;
+ syna,clip-x-high = <1440>;
+ syna,clip-y-high = <2560>;
touchscreen-inverted-y;
};
--
2.48.1
^ permalink raw reply related
* [PATCH v1 1/2] input: rmi4: fix RMI_2D clipping
From: Svyatoslav Ryhel @ 2025-09-03 16:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Dmitry Torokhov, Svyatoslav Ryhel,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel, linux-input
In-Reply-To: <20250903161947.109328-1-clamor95@gmail.com>
From: Jonas Schwöbel <jonasschwoebel@yahoo.de>
The physical max_y value was overridden with a clip_y_max value. This
caused problems when inverting/flipping the screen. Further it messed up
calculation of resolution.
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/input/rmi4/rmi_2d_sensor.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/input/rmi4/rmi_2d_sensor.c b/drivers/input/rmi4/rmi_2d_sensor.c
index b7fe6eb35a4e..b4762b3c8b24 100644
--- a/drivers/input/rmi4/rmi_2d_sensor.c
+++ b/drivers/input/rmi4/rmi_2d_sensor.c
@@ -56,7 +56,7 @@ void rmi_2d_sensor_abs_process(struct rmi_2d_sensor *sensor,
obj->x = min(sensor->max_x, obj->x);
if (axis_align->clip_y_high)
- obj->y = min(sensor->max_y, obj->y);
+ obj->y = min(axis_align->clip_y_high, obj->y);
sensor->tracking_pos[slot].x = obj->x;
sensor->tracking_pos[slot].y = obj->y;
@@ -149,13 +149,12 @@ static void rmi_2d_sensor_set_input_params(struct rmi_2d_sensor *sensor)
sensor->min_y = sensor->axis_align.clip_y_low;
if (sensor->axis_align.clip_y_high)
- sensor->max_y = min(sensor->max_y,
+ max_y = min(sensor->max_y,
sensor->axis_align.clip_y_high);
set_bit(EV_ABS, input->evbit);
max_x = sensor->max_x;
- max_y = sensor->max_y;
if (sensor->axis_align.swap_axes)
swap(max_x, max_y);
input_set_abs_params(input, ABS_MT_POSITION_X, 0, max_x, 0, 0);
--
2.48.1
^ permalink raw reply related
* [PATCH v1 0/2] input: rmi4: fix RMI_2D clipping
From: Svyatoslav Ryhel @ 2025-09-03 16:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Dmitry Torokhov, Svyatoslav Ryhel,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel, linux-input
The physical max_y value was overridden with a clip_y_max value. This
caused problems when inverting/flipping the screen. Further it messed up
calculation of resolution.
Jonas Schwöbel (2):
input: rmi4: fix RMI_2D clipping
ARM: tegra: p880: set correct touchscreen clipping
arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 4 ++--
drivers/input/rmi4/rmi_2d_sensor.c | 5 ++---
2 files changed, 4 insertions(+), 5 deletions(-)
--
2.48.1
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Mavroudis Chatzilazaridis @ 2025-09-03 15:56 UTC (permalink / raw)
To: Stuart; +Cc: jikos, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <CALTg27=fZ+_2b2AXmKk5UcZG_2-zm2XP3+xzbSUrWdahD7ShaA@mail.gmail.com>
Hi,
On 02/09/2025 23.03, Stuart wrote:
> Thanks for rebasing, testing with a Logitech G915 TKL:
> - All the keys work and the media controls work perfectly too.
> - The battery is detected and the sysfs attributes all look correct.
>
> However, caps lock correctly enables caps lock, but the caps lock
> light doesn't respond to it any more (the light works without the
> driver).
> My laptop's internal keyboard lights up correctly when caps lock is
> pressed on either keyboard, but the caps lock light on my G915 TKL
> never lights up.
Thanks for taking the time to test it.
Is your product id the same as the one in the patch or are you modifying
it before compiling?
> I'm happy to check anything you need for troubleshooting, I'm also
> happy to compile more kernels :)
Can you please dump the HID descriptors from your receiver
(sudo usbhid-dump -m 046d:c547) and share them?
> Thanks,
> Stuart
Thanks again
^ permalink raw reply
* Re: [PATCH v2] tsc2007: prevent overflow in pressure calculation
From: Dmitry Torokhov @ 2025-09-03 14:51 UTC (permalink / raw)
To: mailinglist1; +Cc: linux-input, Johannes Kirchmair
In-Reply-To: <20250129-fix_tsc_calculation_overflow-v2-1-9e51333496ad@skidata.com>
On Wed, Jan 29, 2025 at 02:51:20PM +0100, mailinglist1@johanneskirchmair.de wrote:
> From: Johannes Kirchmair <johannes.kirchmair@skidata.com>
>
> The touch resistance calculation in the tsc2007 driver is prone to overflow
> if (z2 - z1) is large and also x is reasonably big. As an result the
> driver sometimes emit input events even with very little touch pressure
> applied. For those events the x and y coordinates can be substantially
> off. We fix the overflow problematic by calculating in a bigger int
> type.
>
> Signed-off-by: Johannes Kirchmair <johannes.kirchmair@skidata.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 0/2 RESEND] input: touchcreen: tsc2007: make interrupt optional
From: Dmitry Torokhov @ 2025-09-03 14:41 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: Kevin Hilman, Andreas Kemnade, linux-input, linux-kernel
In-Reply-To: <20250824091927.105121-1-clamor95@gmail.com>
On Sun, Aug 24, 2025 at 12:19:25PM +0300, Svyatoslav Ryhel wrote:
> In case tsc2007 is used as an ADC sensor there will be no interrupt
> provided at all, so set up an interrupt only if one is present and
> remove associated warning.
Applied the lot, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: tsc2007: Document 'wakeup-source'
From: Dmitry Torokhov @ 2025-09-03 13:58 UTC (permalink / raw)
To: Fabio Estevam; +Cc: robh, krzk+dt, conor+dt, Frank.Li, linux-input, devicetree
In-Reply-To: <20250822213245.125901-1-festevam@gmail.com>
On Fri, Aug 22, 2025 at 06:32:45PM -0300, Fabio Estevam wrote:
> The 'wakeup-source' property is used by many devicetree files and is
> also supported by the tsc2007_core driver.
>
> Document it to avoid the following dt-schema warning:
>
> 'wakeup-source' does not match any of the regexes: '^pinctrl-[0-9]+$'
>
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: (subset) [PATCH v3 0/7] Fix, extend and support OF to mc13xxx pwrbutton
From: Lee Jones @ 2025-09-03 13:37 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Dzmitry Sankouski, Dr. David Alan Gilbert,
Heiko Stuebner, Uwe Kleine-König, devicetree, linux-input,
Alexander Kurz
Cc: linux-kernel
In-Reply-To: <20250829201517.15374-1-akurz@blala.de>
On Fri, 29 Aug 2025 20:15:10 +0000, Alexander Kurz wrote:
> Goal of this patch series is to make the mc13892 PWRON1 button usable,
> found e.g. on amazon kindle D01100/D01200/EY21 readers.
> A ten-year-old IRQ issue needed a fix, mc13783-pwrbutton had to be
> extended to the other to mc13xxx PMIC as well (keeping the mc13892
> PWRON3 key unsupported for simplicity) and adding OF support.
> The implementation has been tested on amazon kindle D01100 and D01200
> readers using PWRON1 of a mc13892.
>
> [...]
Applied, thanks!
[5/7] dt-bindings: mfd: fsl,mc13xxx: convert txt to DT schema
commit: 95ec82241a49c4dbd4f6db42d409b05a7a57920e
[6/7] dt-bindings: mfd: fsl,mc13xxx: add buttons node
commit: 4c880450f5ffc5b1f7fc94ae66d44457fbc352fa
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3 4/7] Input: mc13783-pwrbutton: enable other mc13xxx PMIC
From: Lee Jones @ 2025-09-03 13:35 UTC (permalink / raw)
To: Alexander Kurz
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Dzmitry Sankouski, Dr. David Alan Gilbert, Heiko Stuebner,
Uwe Kleine-König, devicetree, linux-input, linux-kernel
In-Reply-To: <20250829201517.15374-5-akurz@blala.de>
On Fri, 29 Aug 2025, Alexander Kurz wrote:
> All three mc13xxx types do feature two common power buttons referred as
> ONOFD[12] (mc13783) and PWRON[12] (mc13892/mc34708) in the SoC reference
> manuals. Add support for PWRON[12] (mc13892/mc34708) but skip support for
> button PWRON3 (mc13892) for sake of simplicity.
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> drivers/input/misc/Kconfig | 4 +--
> drivers/input/misc/mc13783-pwrbutton.c | 44 +++++++++++++++++++++++---
> include/linux/mfd/mc13783.h | 4 +--
> include/linux/mfd/mc13xxx.h | 2 ++
Acked-by: Lee Jones <lee@kernel.org>
> 4 files changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 0fb21c99a5e3..b66e920369f2 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -276,8 +276,8 @@ config INPUT_MC13783_PWRBUTTON
> tristate "MC13783 ON buttons"
> depends on MFD_MC13XXX
> help
> - Support the ON buttons of MC13783 PMIC as an input device
> - reporting power button status.
> + Support the ON buttons of MC13783/MC13892/MC34708 PMIC as an input
> + device reporting power button status.
>
> To compile this driver as a module, choose M here: the module
> will be called mc13783-pwrbutton.
> diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
> index ace9f286fd24..c9eea57ceedd 100644
> --- a/drivers/input/misc/mc13783-pwrbutton.c
> +++ b/drivers/input/misc/mc13783-pwrbutton.c
> @@ -30,16 +30,21 @@
> #include <linux/sched.h>
> #include <linux/slab.h>
>
> +struct mc13xxx_button_devtype {
> + int button_id_max;
> +};
> +
> struct mc13783_pwrb {
> struct input_dev *pwr;
> struct mc13xxx *mc13783;
> -#define MC13783_PWRB_B1_POL_INVERT (1 << 0)
> -#define MC13783_PWRB_B2_POL_INVERT (1 << 1)
> -#define MC13783_PWRB_B3_POL_INVERT (1 << 2)
> int flags;
> unsigned short keymap[3];
> };
>
> +#define MC13783_PWRB_B1_POL_INVERT (1 << 0)
> +#define MC13783_PWRB_B2_POL_INVERT (1 << 1)
> +#define MC13783_PWRB_B3_POL_INVERT (1 << 2)
> +
> #define MC13783_REG_INTERRUPT_SENSE_1 5
> #define MC13783_IRQSENSE1_ONOFD1S (1 << 3)
> #define MC13783_IRQSENSE1_ONOFD2S (1 << 4)
> @@ -108,6 +113,8 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> {
> const struct mc13xxx_buttons_platform_data *pdata;
> struct mc13xxx *mc13783 = dev_get_drvdata(pdev->dev.parent);
> + struct mc13xxx_button_devtype *devtype =
> + (struct mc13xxx_button_devtype *)pdev->id_entry->driver_data;
> struct input_dev *pwr;
> struct mc13783_pwrb *priv;
> int err = 0;
> @@ -127,6 +134,11 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> if (!priv)
> return -ENOMEM;
>
> + if (devtype->button_id_max < 2 && pdata->b_on_flags[2] & 0x3) {
> + dev_err(&pdev->dev, "button not supported\n");
> + return -ENODEV;
> + }
> +
> reg |= (pdata->b_on_flags[0] & 0x3) << MC13783_POWER_CONTROL_2_ON1BDBNC;
> reg |= (pdata->b_on_flags[1] & 0x3) << MC13783_POWER_CONTROL_2_ON2BDBNC;
> reg |= (pdata->b_on_flags[2] & 0x3) << MC13783_POWER_CONTROL_2_ON3BDBNC;
> @@ -239,12 +251,15 @@ static void mc13783_pwrbutton_remove(struct platform_device *pdev)
> {
> struct mc13783_pwrb *priv = platform_get_drvdata(pdev);
> const struct mc13xxx_buttons_platform_data *pdata;
> + struct mc13xxx_button_devtype *devtype =
> + (struct mc13xxx_button_devtype *)pdev->id_entry->driver_data;
>
> pdata = dev_get_platdata(&pdev->dev);
>
> mc13xxx_lock(priv->mc13783);
>
> - if (pdata->b_on_flags[2] & MC13783_BUTTON_ENABLE)
> + if (devtype->button_id_max >= 2 &&
> + pdata->b_on_flags[2] & MC13783_BUTTON_ENABLE)
> mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD3, priv);
> if (pdata->b_on_flags[1] & MC13783_BUTTON_ENABLE)
> mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD2, priv);
> @@ -254,7 +269,28 @@ static void mc13783_pwrbutton_remove(struct platform_device *pdev)
> mc13xxx_unlock(priv->mc13783);
> }
>
> +static const struct mc13xxx_button_devtype mc13783_button_devtype = {
> + .button_id_max = 2,
> +};
> +
> +static const struct mc13xxx_button_devtype mc13892_button_devtype = {
> + /* PWRON3 is not supported yet. */
> + .button_id_max = 1,
> +};
> +
> +static const struct mc13xxx_button_devtype mc34708_button_devtype = {
> + .button_id_max = 1,
> +};
> +
> +static const struct platform_device_id mc13xxx_pwrbutton_idtable[] = {
> + { "mc13783-pwrbutton", (kernel_ulong_t)&mc13783_button_devtype },
> + { "mc13892-pwrbutton", (kernel_ulong_t)&mc13892_button_devtype },
> + { "mc34708-pwrbutton", (kernel_ulong_t)&mc34708_button_devtype },
> + { /* sentinel */ }
> +};
> +
> static struct platform_driver mc13783_pwrbutton_driver = {
> + .id_table = mc13xxx_pwrbutton_idtable,
> .probe = mc13783_pwrbutton_probe,
> .remove = mc13783_pwrbutton_remove,
> .driver = {
> diff --git a/include/linux/mfd/mc13783.h b/include/linux/mfd/mc13783.h
> index c25b1676741b..ab6db774e1fa 100644
> --- a/include/linux/mfd/mc13783.h
> +++ b/include/linux/mfd/mc13783.h
> @@ -65,8 +65,8 @@
> #define MC13783_IRQ_UDM 23
> #define MC13783_IRQ_1HZ MC13XXX_IRQ_1HZ
> #define MC13783_IRQ_TODA MC13XXX_IRQ_TODA
> -#define MC13783_IRQ_ONOFD1 27
> -#define MC13783_IRQ_ONOFD2 28
> +#define MC13783_IRQ_ONOFD1 MC13XXX_IRQ_PWRON1
> +#define MC13783_IRQ_ONOFD2 MC13XXX_IRQ_PWRON2
> #define MC13783_IRQ_ONOFD3 29
> #define MC13783_IRQ_SYSRST MC13XXX_IRQ_SYSRST
> #define MC13783_IRQ_RTCRST MC13XXX_IRQ_RTCRST
> diff --git a/include/linux/mfd/mc13xxx.h b/include/linux/mfd/mc13xxx.h
> index 0393083af28a..36e5e7de7cb2 100644
> --- a/include/linux/mfd/mc13xxx.h
> +++ b/include/linux/mfd/mc13xxx.h
> @@ -67,6 +67,8 @@ int mc13xxx_irq_unmask(struct mc13xxx *mc13xxx, int irq);
> #define MC13XXX_IRQ_LOBATH 14
> #define MC13XXX_IRQ_1HZ 24
> #define MC13XXX_IRQ_TODA 25
> +#define MC13XXX_IRQ_PWRON1 27
> +#define MC13XXX_IRQ_PWRON2 28
> #define MC13XXX_IRQ_SYSRST 30
> #define MC13XXX_IRQ_RTCRST 31
> #define MC13XXX_IRQ_PC 32
> --
> 2.39.5
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3 3/7] Input: mc13783-pwrbutton: convert pdata members to array
From: Lee Jones @ 2025-09-03 13:35 UTC (permalink / raw)
To: Alexander Kurz
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Dzmitry Sankouski, Dr. David Alan Gilbert, Heiko Stuebner,
Uwe Kleine-König, devicetree, linux-input, linux-kernel
In-Reply-To: <20250829201517.15374-4-akurz@blala.de>
On Fri, 29 Aug 2025, Alexander Kurz wrote:
> As preparation for mc13783-pwrbutton OF support, convert the members of
> mc13xxx_buttons_platform_data to arrays to allow index access within
> the next commit.
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> drivers/input/misc/mc13783-pwrbutton.c | 54 +++++++++++++-------------
> include/linux/mfd/mc13xxx.h | 8 +---
Acked-by: Lee Jones <lee@kernel.org>
> 2 files changed, 29 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
> index 9fd84b8d163d..ace9f286fd24 100644
> --- a/drivers/input/misc/mc13783-pwrbutton.c
> +++ b/drivers/input/misc/mc13783-pwrbutton.c
> @@ -127,24 +127,24 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> if (!priv)
> return -ENOMEM;
>
> - reg |= (pdata->b1on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON1BDBNC;
> - reg |= (pdata->b2on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON2BDBNC;
> - reg |= (pdata->b3on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON3BDBNC;
> + reg |= (pdata->b_on_flags[0] & 0x3) << MC13783_POWER_CONTROL_2_ON1BDBNC;
> + reg |= (pdata->b_on_flags[1] & 0x3) << MC13783_POWER_CONTROL_2_ON2BDBNC;
> + reg |= (pdata->b_on_flags[2] & 0x3) << MC13783_POWER_CONTROL_2_ON3BDBNC;
>
> priv->pwr = pwr;
> priv->mc13783 = mc13783;
>
> mc13xxx_lock(mc13783);
>
> - if (pdata->b1on_flags & MC13783_BUTTON_ENABLE) {
> - priv->keymap[0] = pdata->b1on_key;
> - if (pdata->b1on_key != KEY_RESERVED)
> - __set_bit(pdata->b1on_key, pwr->keybit);
> + if (pdata->b_on_flags[0] & MC13783_BUTTON_ENABLE) {
> + priv->keymap[0] = pdata->b_on_key[0];
> + if (pdata->b_on_key[0] != KEY_RESERVED)
> + __set_bit(pdata->b_on_key[0], pwr->keybit);
>
> - if (pdata->b1on_flags & MC13783_BUTTON_POL_INVERT)
> + if (pdata->b_on_flags[0] & MC13783_BUTTON_POL_INVERT)
> priv->flags |= MC13783_PWRB_B1_POL_INVERT;
>
> - if (pdata->b1on_flags & MC13783_BUTTON_RESET_EN)
> + if (pdata->b_on_flags[0] & MC13783_BUTTON_RESET_EN)
> reg |= MC13783_POWER_CONTROL_2_ON1BRSTEN;
>
> err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD1,
> @@ -155,15 +155,15 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> }
> }
>
> - if (pdata->b2on_flags & MC13783_BUTTON_ENABLE) {
> - priv->keymap[1] = pdata->b2on_key;
> - if (pdata->b2on_key != KEY_RESERVED)
> - __set_bit(pdata->b2on_key, pwr->keybit);
> + if (pdata->b_on_flags[1] & MC13783_BUTTON_ENABLE) {
> + priv->keymap[1] = pdata->b_on_key[1];
> + if (pdata->b_on_key[1] != KEY_RESERVED)
> + __set_bit(pdata->b_on_key[1], pwr->keybit);
>
> - if (pdata->b2on_flags & MC13783_BUTTON_POL_INVERT)
> + if (pdata->b_on_flags[1] & MC13783_BUTTON_POL_INVERT)
> priv->flags |= MC13783_PWRB_B2_POL_INVERT;
>
> - if (pdata->b2on_flags & MC13783_BUTTON_RESET_EN)
> + if (pdata->b_on_flags[1] & MC13783_BUTTON_RESET_EN)
> reg |= MC13783_POWER_CONTROL_2_ON2BRSTEN;
>
> err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD2,
> @@ -174,15 +174,15 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> }
> }
>
> - if (pdata->b3on_flags & MC13783_BUTTON_ENABLE) {
> - priv->keymap[2] = pdata->b3on_key;
> - if (pdata->b3on_key != KEY_RESERVED)
> - __set_bit(pdata->b3on_key, pwr->keybit);
> + if (pdata->b_on_flags[2] & MC13783_BUTTON_ENABLE) {
> + priv->keymap[2] = pdata->b_on_key[2];
> + if (pdata->b_on_key[2] != KEY_RESERVED)
> + __set_bit(pdata->b_on_key[2], pwr->keybit);
>
> - if (pdata->b3on_flags & MC13783_BUTTON_POL_INVERT)
> + if (pdata->b_on_flags[2] & MC13783_BUTTON_POL_INVERT)
> priv->flags |= MC13783_PWRB_B3_POL_INVERT;
>
> - if (pdata->b3on_flags & MC13783_BUTTON_RESET_EN)
> + if (pdata->b_on_flags[2] & MC13783_BUTTON_RESET_EN)
> reg |= MC13783_POWER_CONTROL_2_ON3BRSTEN;
>
> err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD3,
> @@ -218,15 +218,15 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> free_irq:
> mc13xxx_lock(mc13783);
>
> - if (pdata->b3on_flags & MC13783_BUTTON_ENABLE)
> + if (pdata->b_on_flags[2] & MC13783_BUTTON_ENABLE)
> mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD3, priv);
>
> free_irq_b2:
> - if (pdata->b2on_flags & MC13783_BUTTON_ENABLE)
> + if (pdata->b_on_flags[1] & MC13783_BUTTON_ENABLE)
> mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD2, priv);
>
> free_irq_b1:
> - if (pdata->b1on_flags & MC13783_BUTTON_ENABLE)
> + if (pdata->b_on_flags[0] & MC13783_BUTTON_ENABLE)
> mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD1, priv);
>
> free_mc13xxx_lock:
> @@ -244,11 +244,11 @@ static void mc13783_pwrbutton_remove(struct platform_device *pdev)
>
> mc13xxx_lock(priv->mc13783);
>
> - if (pdata->b3on_flags & MC13783_BUTTON_ENABLE)
> + if (pdata->b_on_flags[2] & MC13783_BUTTON_ENABLE)
> mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD3, priv);
> - if (pdata->b2on_flags & MC13783_BUTTON_ENABLE)
> + if (pdata->b_on_flags[1] & MC13783_BUTTON_ENABLE)
> mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD2, priv);
> - if (pdata->b1on_flags & MC13783_BUTTON_ENABLE)
> + if (pdata->b_on_flags[0] & MC13783_BUTTON_ENABLE)
> mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD1, priv);
>
> mc13xxx_unlock(priv->mc13783);
> diff --git a/include/linux/mfd/mc13xxx.h b/include/linux/mfd/mc13xxx.h
> index f372926d5894..0393083af28a 100644
> --- a/include/linux/mfd/mc13xxx.h
> +++ b/include/linux/mfd/mc13xxx.h
> @@ -187,12 +187,8 @@ struct mc13xxx_leds_platform_data {
> #define MC13783_BUTTON_RESET_EN (1 << 4)
>
> struct mc13xxx_buttons_platform_data {
> - int b1on_flags;
> - unsigned short b1on_key;
> - int b2on_flags;
> - unsigned short b2on_key;
> - int b3on_flags;
> - unsigned short b3on_key;
> + int b_on_flags[3];
> + unsigned int b_on_key[3];
> };
>
> #define MC13783_TS_ATO_FIRST false
> --
> 2.39.5
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: tsc2007: use comma in filename
From: Dmitry Torokhov @ 2025-09-03 12:05 UTC (permalink / raw)
To: akemnade
Cc: robh, krzk+dt, conor+dt, Frank.Li, andreas, linux-input,
devicetree, linux-kernel
In-Reply-To: <20250830085326.36120-1-akemnade@kernel.org>
On Sat, Aug 30, 2025 at 10:53:26AM +0200, akemnade@kernel.org wrote:
> From: Andreas Kemnade <andreas@kemnade.info>
>
> Use comma between vendor-prefix and chip name as it is common.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 8/9] leds: mc13783: use fsl,led-control as node name
From: Lee Jones @ 2025-09-03 11:59 UTC (permalink / raw)
To: Alexander Kurz
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Dzmitry Sankouski, Dr. David Alan Gilbert, Heiko Stuebner,
Uwe Kleine-König, devicetree, linux-input, linux-kernel
In-Reply-To: <20250823144441.12654-9-akurz@blala.de>
Did you actually test this?
> According to fsl,mc13xxx.yaml, the node name for led-control is
> vendor prefixed. Change it accordingly.
According to what, now? I see:
% find . -name fsl,mc13xxx.yaml
<no results>
% git grep fsl,led-control
<no results>
% git grep led-control | grep -v led-controller
Documentation/devicetree/bindings/mfd/mc13xxx.txt: "led-control". Number of register depends of used IC, for MC13783 is 6,
Documentation/devicetree/bindings/mfd/mc13xxx.txt: led-control = <0x000 0x000 0x0e0 0x000>;
Documentation/netlink/specs/rt-link.yaml: name: coupled-control
arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi: led-control = <0x001 0x000 0x000 0x000 0x000 0x000>;
arch/arm/boot/dts/nxp/imx/imx51-zii-rdu1.dts: led-control = <0x0 0x0 0x3f83f8 0x0>;
arch/arm/boot/dts/nxp/imx/imx51-zii-scu2-mezz.dts: led-control = <0x0 0x0 0x3f83f8 0x0>;
arch/arm/boot/dts/nxp/imx/imx51-zii-scu3-esb.dts: led-control = <0x0 0x0 0x3f83f8 0x0>;
drivers/leds/leds-mc13783.c: ret = of_property_read_u32_array(parent, "led-control",
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> drivers/leds/leds-mc13783.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/leds/leds-mc13783.c b/drivers/leds/leds-mc13783.c
> index e22f09d13798..11add1fd24ce 100644
> --- a/drivers/leds/leds-mc13783.c
> +++ b/drivers/leds/leds-mc13783.c
> @@ -127,7 +127,7 @@ static struct mc13xxx_leds_platform_data __init *mc13xxx_led_probe_dt(
> if (!parent)
> return ERR_PTR(-ENODATA);
>
> - ret = of_property_read_u32_array(parent, "led-control",
> + ret = of_property_read_u32_array(parent, "fsl,led-control",
> pdata->led_control,
> leds->devtype->num_regs);
--
Lee Jones [李琼斯]
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD and Input due for the v6.18 merge window
From: Lee Jones @ 2025-09-03 11:32 UTC (permalink / raw)
To: Michael Walle
Cc: Dmitry Torokhov, jcormier, Job Sava, linux-kernel, linux-input
In-Reply-To: <20250826134631.1499936-1-mwalle@kernel.org>
Enjoy!
The following changes since commit 8f5ae30d69d7543eee0d70083daf4de8fe15d585:
Linux 6.17-rc1 (2025-08-10 19:41:16 +0300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-input-v6.18
for you to fetch changes up to 2215a87b02ad8d353cd3edebd1bed01db2458986:
mfd: tps6594: Add board power-off support (2025-09-03 11:28:36 +0100)
----------------------------------------------------------------
Immutable branch between MFD and Input due for the v6.18 merge window
----------------------------------------------------------------
Job Sava (1):
input: tps6594-pwrbutton: Add power button functionality
Michael Walle (2):
mfd: tps6594: Add power button functionality
mfd: tps6594: Add board power-off support
drivers/input/misc/Kconfig | 10 +++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/tps6594-pwrbutton.c | 126 +++++++++++++++++++++++++++++++++
drivers/mfd/tps6594-core.c | 58 ++++++++++++++-
4 files changed, 193 insertions(+), 2 deletions(-)
create mode 100644 drivers/input/misc/tps6594-pwrbutton.c
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 0/3] mfd: tps6594: add power button and power-off
From: Lee Jones @ 2025-09-03 10:46 UTC (permalink / raw)
To: Dmitry Torokhov, Michael Walle
Cc: jcormier, Job Sava, linux-kernel, linux-input
In-Reply-To: <175689630841.2597045.5125819314695096057.b4-ty@kernel.org>
On Wed, 03 Sep 2025, Lee Jones wrote:
> On Tue, 26 Aug 2025 15:46:28 +0200, Michael Walle wrote:
> > I took over the series from [1] since the original developer was an
> > intern and is no longer with their former company.
> >
> > Changelog is in the individual patches. But the most prominent
> > change is that the pin mux config is now read from the chip itself
> > instead of having a DT property.
> >
> > [...]
>
> Applied, thanks!
>
> [1/3] input: tps6594-pwrbutton: Add power button functionality
> commit: 170031ff27dd7a07fdedee7f3710a19dcdf889bd
> [2/3] mfd: tps6594: add power button functionality
> commit: d766ca01c208bdf0f36098607efe1e250ccf41c5
> [3/3] mfd: tps6594: Add board power-off support
> commit: 2215a87b02ad8d353cd3edebd1bed01db2458986
Submitted for build testing. Once complete, I'll send out a PR.
Note to self: ib-mfd-input-6.18
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 0/3] mfd: tps6594: add power button and power-off
From: Lee Jones @ 2025-09-03 10:45 UTC (permalink / raw)
To: Dmitry Torokhov, Lee Jones, Michael Walle
Cc: jcormier, Job Sava, linux-kernel, linux-input
In-Reply-To: <20250826134631.1499936-1-mwalle@kernel.org>
On Tue, 26 Aug 2025 15:46:28 +0200, Michael Walle wrote:
> I took over the series from [1] since the original developer was an
> intern and is no longer with their former company.
>
> Changelog is in the individual patches. But the most prominent
> change is that the pin mux config is now read from the chip itself
> instead of having a DT property.
>
> [...]
Applied, thanks!
[1/3] input: tps6594-pwrbutton: Add power button functionality
commit: 170031ff27dd7a07fdedee7f3710a19dcdf889bd
[2/3] mfd: tps6594: add power button functionality
commit: d766ca01c208bdf0f36098607efe1e250ccf41c5
[3/3] mfd: tps6594: Add board power-off support
commit: 2215a87b02ad8d353cd3edebd1bed01db2458986
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH v3] Input: bcm5974 - Driver cleanup by replacing dprintk with dev_dbg
From: Bhanu Seshu Kumar Valluri @ 2025-09-03 8:55 UTC (permalink / raw)
To: rydberg, dmitry.torokhov
Cc: linux-input, skhan, linux-kernel, linux-kernel-mentees,
bhanuseshukumar
Debug printk messages are converted to dev_dbg based logs
for better control over debug messages using dynamic logging.
Signed-off-by: Bhanu Seshu Kumar Valluri <bhanuseshukumar@gmail.com>
---
Changes in V3
1. Name in the from tag & signed-off tag are matched.
Note: This patch is tested for compilation.
v1 patch : https://lore.kernel.org/all/20250902164351.36828-1-bhanuseshukumar@gmail.com/
v2 patch : https://lore.kernel.org/all/20250903061908.41910-1-bhanuseshukumar@gmail.com/
drivers/input/mouse/bcm5974.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index dfdfb59cc8b5..03e112666c2e 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -156,13 +156,6 @@ MODULE_AUTHOR("Henrik Rydberg");
MODULE_DESCRIPTION("Apple USB BCM5974 multitouch driver");
MODULE_LICENSE("GPL");
-#define dprintk(level, format, a...)\
- { if (debug >= level) printk(KERN_DEBUG format, ##a); }
-
-static int debug = 1;
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, "Activate debugging output");
-
/* button data structure */
struct bt_data {
u8 unknown1; /* constant */
@@ -550,8 +543,7 @@ static int report_bt_state(struct bcm5974 *dev, int size)
if (size != sizeof(struct bt_data))
return -EIO;
- dprintk(7,
- "bcm5974: button data: %x %x %x %x\n",
+ dev_dbg(&dev->intf->dev, "button data: %x %x %x %x\n",
dev->bt_data->unknown1, dev->bt_data->button,
dev->bt_data->rel_x, dev->bt_data->rel_y);
@@ -688,7 +680,7 @@ static int bcm5974_wellspring_mode(struct bcm5974 *dev, bool on)
goto out;
}
- dprintk(2, "bcm5974: switched to %s mode.\n",
+ dev_dbg(&dev->intf->dev, "switched to %s mode.\n",
on ? "wellspring" : "normal");
out:
@@ -718,7 +710,7 @@ static void bcm5974_irq_button(struct urb *urb)
}
if (report_bt_state(dev, dev->bt_urb->actual_length))
- dprintk(1, "bcm5974: bad button package, length: %d\n",
+ dev_dbg(&intf->dev, "bad button package, length: %d\n",
dev->bt_urb->actual_length);
exit:
@@ -753,7 +745,7 @@ static void bcm5974_irq_trackpad(struct urb *urb)
goto exit;
if (report_tp_state(dev, dev->tp_urb->actual_length))
- dprintk(1, "bcm5974: bad trackpad package, length: %d\n",
+ dev_dbg(&intf->dev, "bad trackpad package, length: %d\n",
dev->tp_urb->actual_length);
exit:
@@ -786,7 +778,7 @@ static int bcm5974_start_traffic(struct bcm5974 *dev)
error = bcm5974_wellspring_mode(dev, true);
if (error) {
- dprintk(1, "bcm5974: mode switch failed\n");
+ dev_dbg(&dev->intf->dev, "mode switch failed\n");
goto err_out;
}
--
2.34.1
^ permalink raw reply related
* Possible regression in i2c_hid_acpi
From: Christian Schaubschläger @ 2025-09-03 8:36 UTC (permalink / raw)
To: linux-input; +Cc: linux-i2c
[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]
Good day,
I observe a possible regression on my HP ZBook Firefly 14 inch G9 Mobile Workstation PC/896D when I upgrade from linux-6.16-rc4 to linux-6.16-rc5: the notebook's touchpad doesn't work any more.
On 6.16-rc4 I see this:
[ 2.225387] input: SYNA30D9:00 06CB:CEA4 Mouse as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-SYNA30D9:00/0018:06CB:CEA4.0001/input/input7
[ 2.225451] input: SYNA30D9:00 06CB:CEA4 Touchpad as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-SYNA30D9:00/0018:06CB:CEA4.0001/input/input8
[ 2.225495] hid-generic 0018:06CB:CEA4.0001: input,hidraw0: I2C HID v1.00 Mouse [SYNA30D9:00 06CB:CEA4] on i2c-SYNA30D9:00
[ 2.360194] input: SYNA30D9:00 06CB:CEA4 Mouse as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-SYNA30D9:00/0018:06CB:CEA4.0001/input/input10
[ 2.360539] input: SYNA30D9:00 06CB:CEA4 Touchpad as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-SYNA30D9:00/0018:06CB:CEA4.0001/input/input11
[ 2.361078] hid-multitouch 0018:06CB:CEA4.0001: input,hidraw0: I2C HID v1.00 Mouse [SYNA30D9:00 06CB:CEA4] on i2c-SYNA30D9:00
Whereas on 6.16-rc5 I get:
[ 2.103592] i2c_hid_acpi i2c-SYNA30D9:00: HID over i2c has not been provided an Int IRQ
[ 2.103610] i2c_hid_acpi i2c-SYNA30D9:00: probe with driver i2c_hid_acpi failed with error -22
All newer kernels (up to 6.17-rc3) show the same behaviour.
Attached you find the full dmesg logs.
I'd be happy to provide more detailed logs or whatever is required to track this down.
Thanks and best regards,
Christian
[-- Attachment #2: dmesg-6.16-rc4.log.xz --]
[-- Type: application/x-xz, Size: 14780 bytes --]
[-- Attachment #3: dmesg-6.16-rc5.log.xz --]
[-- Type: application/x-xz, Size: 14744 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Input: bcm5974 - Driver cleanup by replacing dprintk with dev_dbg
From: Greg KH @ 2025-09-03 6:40 UTC (permalink / raw)
To: Bhanu Seshu Kumar Valluri
Cc: rydberg, dmitry.torokhov, linux-input, skhan, linux-kernel,
linux-kernel-mentees
In-Reply-To: <20250903061908.41910-1-bhanuseshukumar@gmail.com>
On Wed, Sep 03, 2025 at 11:49:08AM +0530, Bhanu Seshu Kumar Valluri wrote:
> From: bhanuseshukumar <bhanuseshukumar@gmail.com>
>
> Debug printk messages are converted to dev_dbg based logs
> for better control over debug messages using dynamic logging.
>
> Signed-off-by: Bhanu Seshu Kumar Valluri <bhanuseshukumar@gmail.com>
Does not match your "From:" line :(
^ permalink raw reply
* [PATCH v2] Input: bcm5974 - Driver cleanup by replacing dprintk with dev_dbg
From: Bhanu Seshu Kumar Valluri @ 2025-09-03 6:19 UTC (permalink / raw)
To: rydberg, dmitry.torokhov
Cc: linux-input, skhan, bhanuseshukumar, linux-kernel,
linux-kernel-mentees
From: bhanuseshukumar <bhanuseshukumar@gmail.com>
Debug printk messages are converted to dev_dbg based logs
for better control over debug messages using dynamic logging.
Signed-off-by: Bhanu Seshu Kumar Valluri <bhanuseshukumar@gmail.com>
---
Changes in V2
1. Removed unnecessary module name(bcm5974) prefix in each dev_dbg logs.
2. Removed unwanted variable declarations as pointed out in v1 review
3. Name is used in signed-off tag instead of email alias.
Note: This patch is tested for compilation.
v1 patch : https://lore.kernel.org/all/20250902164351.36828-1-bhanuseshukumar@gmail.com/
drivers/input/mouse/bcm5974.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index dfdfb59cc8b5..03e112666c2e 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -156,13 +156,6 @@ MODULE_AUTHOR("Henrik Rydberg");
MODULE_DESCRIPTION("Apple USB BCM5974 multitouch driver");
MODULE_LICENSE("GPL");
-#define dprintk(level, format, a...)\
- { if (debug >= level) printk(KERN_DEBUG format, ##a); }
-
-static int debug = 1;
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, "Activate debugging output");
-
/* button data structure */
struct bt_data {
u8 unknown1; /* constant */
@@ -550,8 +543,7 @@ static int report_bt_state(struct bcm5974 *dev, int size)
if (size != sizeof(struct bt_data))
return -EIO;
- dprintk(7,
- "bcm5974: button data: %x %x %x %x\n",
+ dev_dbg(&dev->intf->dev, "button data: %x %x %x %x\n",
dev->bt_data->unknown1, dev->bt_data->button,
dev->bt_data->rel_x, dev->bt_data->rel_y);
@@ -688,7 +680,7 @@ static int bcm5974_wellspring_mode(struct bcm5974 *dev, bool on)
goto out;
}
- dprintk(2, "bcm5974: switched to %s mode.\n",
+ dev_dbg(&dev->intf->dev, "switched to %s mode.\n",
on ? "wellspring" : "normal");
out:
@@ -718,7 +710,7 @@ static void bcm5974_irq_button(struct urb *urb)
}
if (report_bt_state(dev, dev->bt_urb->actual_length))
- dprintk(1, "bcm5974: bad button package, length: %d\n",
+ dev_dbg(&intf->dev, "bad button package, length: %d\n",
dev->bt_urb->actual_length);
exit:
@@ -753,7 +745,7 @@ static void bcm5974_irq_trackpad(struct urb *urb)
goto exit;
if (report_tp_state(dev, dev->tp_urb->actual_length))
- dprintk(1, "bcm5974: bad trackpad package, length: %d\n",
+ dev_dbg(&intf->dev, "bad trackpad package, length: %d\n",
dev->tp_urb->actual_length);
exit:
@@ -786,7 +778,7 @@ static int bcm5974_start_traffic(struct bcm5974 *dev)
error = bcm5974_wellspring_mode(dev, true);
if (error) {
- dprintk(1, "bcm5974: mode switch failed\n");
+ dev_dbg(&dev->intf->dev, "mode switch failed\n");
goto err_out;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] Input: bcm5974 - Driver cleanup by replacing dprintk with dev_dbg
From: Greg KH @ 2025-09-03 5:44 UTC (permalink / raw)
To: bhanuseshukumar
Cc: rydberg, dmitry.torokhov, linux-input, skhan, linux-kernel,
linux-kernel-mentees
In-Reply-To: <20250902164351.36828-1-bhanuseshukumar@gmail.com>
On Tue, Sep 02, 2025 at 10:13:51PM +0530, bhanuseshukumar wrote:
> Debug printk messages are converted to dev_dbg based logs
> for better control over debug messages using dynamic logging.
Why is this indented?
> Signed-off-by: bhanuseshukumar <bhanuseshukumar@gmail.com>
Please use your name, not your email alias.
> ---
> drivers/input/mouse/bcm5974.c | 21 ++++++++-------------
> 1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
> index dfdfb59cc8b5..2791fe0c1932 100644
> --- a/drivers/input/mouse/bcm5974.c
> +++ b/drivers/input/mouse/bcm5974.c
> @@ -156,13 +156,6 @@ MODULE_AUTHOR("Henrik Rydberg");
> MODULE_DESCRIPTION("Apple USB BCM5974 multitouch driver");
> MODULE_LICENSE("GPL");
>
> -#define dprintk(level, format, a...)\
> - { if (debug >= level) printk(KERN_DEBUG format, ##a); }
> -
> -static int debug = 1;
> -module_param(debug, int, 0644);
> -MODULE_PARM_DESC(debug, "Activate debugging output");
> -
> /* button data structure */
> struct bt_data {
> u8 unknown1; /* constant */
> @@ -547,11 +540,12 @@ static void setup_events_to_report(struct input_dev *input_dev,
> /* report button data as logical button state */
> static int report_bt_state(struct bcm5974 *dev, int size)
> {
> + struct usb_interface *intf = dev->intf;
No need for this variable.
> +
> if (size != sizeof(struct bt_data))
> return -EIO;
>
> - dprintk(7,
> - "bcm5974: button data: %x %x %x %x\n",
> + dev_dbg(&intf->dev, "bcm5974: button data: %x %x %x %x\n",
As you are using dev_dbg(), the prefix "bcm5974:" everywhere is not
needed at all. Just get rid of that.
As proof, look in the kernel log, now you have much more information
than before, right?
Same for the other changes in this patch, drop the prefix.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 00/11] HID: Implement haptic touchpad support
From: Jonathan Denose @ 2025-09-02 21:30 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov, Jonathan Corbet,
Henrik Rydberg
Cc: linux-input, linux-kernel, linux-doc, Angela Czubak,
Sean O'Brien
In-Reply-To: <20250818-support-forcepads-v3-0-e4f9ab0add84@google.com>
On Mon, Aug 18, 2025 at 6:10 PM Jonathan Denose <jdenose@google.com> wrote:
>
> Hello,
>
> This is an updated implementation of the interface for controlling haptic
> touchpads.
>
> Below is an updated design proposal for the userspace and HID interfaces,
> modified from what one of my colleagues submitted in 2019 [0].
>
> We would appreciate any feedback you might have.
>
> Thank you,
>
> Jonathan Denose
> Chromium OS Team
>
> Background
> ==========
>
> There are multiple independent projects to develop a touchpad with force sensors
> and haptic actuators, instead of a traditional button. These haptic touchpads
> have several advantages and potential uses; they allow clicking across the
> entire touchpad surface, adjusting the force requirement for clicks, haptic
> feedback initiated by UI, etc. Supporting these features will potentially
> require two new communication channels at the kernel level:
> * Control of haptic motor by the host
> * Force sensor data from device to host
>
> This document includes two related proposals:
> 1. HID design proposal, that hardware makers would need to implement
> 2. Kernel design proposal
>
> Objective
> ==========
>
> Develop a standard protocol to allow userspace applications to communicate with
> haptic touchpads, and minimize duplicated code and effort.
>
> Requirements:
> 1. Support UI-initiated haptic feedback.
> 2. Allow userspace to control when button press and button release haptic
> effects are triggered. (Useful when detecting a false click, changing force
> thresholds, or sending context-dependent effects).
> 3. Reveal force sensor readings to userspace applications.
> 4. Only allow OS-controlled haptic feedback for those systems which support it.
>
> Proposal
> ========
>
> In order to minimize duplicated effort, we propose standardized haptic touchpad
> support in the linux kernel.
>
> HID API
> -------
>
> Modes
> .....
>
> The haptic touchpad should be able to operate under two different modes.
>
> 1. Device-controlled mode
>
> The haptic touchpad should start up in "device-controlled mode"
> (HID_HAPTIC_MODE_DEVICE), meaning it acts as a normal touchpad. This means it
> should perform the press and release haptic feedback autonomously at predefined
> force thresholds, and send the appropriate BTN_* events.
>
> 2. Host-controlled mode
>
> Once the touchpad has been confirmed as supporting haptics (described in more
> detail in the the "Click and release control" section below), the device should
> enter "host-controlled mode" (HID_HAPTIC_MODE_HOST). In this mode userspace
> should take control. From here, userspace will take control over
> press/release haptic feedback, relying on the effects sent by the kernel.
>
> Multitouch
> ..........
>
> The HID API for multitouch reports should follow the Microsoft precision
> touchpad spec [1], with the following changes:
> * A tip pressure field [2] should be used to report the force. The physical unit
> Type (Newtons or grams), exponent, and limits should be reported in the
> report descriptor for the force field.
> * The device will always report the button state according to its predefined
> force thresholds, even when not in device-controlled mode.
> * The device must expose a "simple haptic controller" logical collection
> alongside the touchpad collection.
>
> Haptic control
> ..............
>
> The HID protocol described in HUTRR63[3] must be used.
>
> The following waveforms should be supported:
>
> | WAVEFORMNONE | Implicit waveforms required by protocol |
> | WAVEFORMSTOP | |
> | ------------------------ | ------------------------------------------------- |
> | WAVEFORMPRESS | To be used to simulate button press. In device- |
> | | controlled mode, it will also be used to simulate |
> | | button release. |
> | ------------------------ | ------------------------------------------------- |
> | WAVEFORMRELEASE | To be used to simulate button release. |
>
> All waveforms will have an associated duration; continuous waveforms will be
> ignored by the kernel.
>
> Triggers & Mode switching
> .........................
>
> The “auto trigger waveform” should be set to WAVEFORM_PRESS by default, and the
> button from the touchpad collection should be set as the “auto trigger
> associated control”.
>
> The kernel can trigger the different modes in the following ways:
> * Device-controlled mode can be enabled by setting the “auto trigger waveform” to
> WAVEFORM_PRESS.
> * Host-controlled mode can be enabled by setting the "auto trigger waveform" to
> WAVEFORM_STOP.
>
> The device must also support manual triggering. If intensity modification for
> waveforms is supported by the device, the intensity control should be included
> in the manual trigger output report. This allows modification of the intensity
> on a per-waveform basis. Retriggering does not need to be supported by the
> device.
>
> Userspace API
> -------------
>
> Multitouch protocol
> ...................
>
> ABS_MT_PRESSURE will be used to report force. The resolution of ABS_MT_PRESSURE
> should also be defined and reported in force units of grams or Newtons.
> ABS_PRESSURE should be reported as the total force applied to the touchpad.
> When the kernel is in host-controlled mode, it should always forward the button
> press and release events to userspace.
>
> Use Force Feedback protocol to request pre-defined effects
> ..........................................................
>
> The force feedback protocol [4] should be used to control predefined effects.
>
> Typical use of the force feedback protocol requires loading effects to the
> driver by describing the output waveform, and then requesting those effects
> using an ID provided by the driver. However, for haptic touchpads we do not want
> to describe the output waveform explicitly, but use a set of predefined effects,
> which are identified by HID usage.
>
> The force feedback protocol will need to be extended to allow requests for HID
> haptic effects. This requires a new feedback effect type:
>
> /**
> * struct ff_haptic_effect
> * @hid_usage: hid_usage according to Haptics page (WAVEFORM_CLICK, etc.)
> * @vendor_id: the waveform vendor ID if hid_usage is in the vendor-defined
> * range
> * @vendor_id: the vendor waveform page if hid_usage is in the vendor-defined
> * range
> * @intensity: strength of the effect
> * @repeat_count: number of times to retrigger effect
> * @retrigger_period: time before effect is retriggered (in ms)
> */
> struct ff_haptic_effect {
> __u16 hid_usage;
> __u16 vendor_id;
> __u8 vendor_waveform_page;
> __s16 intensity;
> __u16 repeat_count;
> __u16 retrigger_period;
> }
>
> Since the standard waveform id namespace does not overlap with the vendor
> waveform id namespace, the vendor id and page can be ignored for standard
> waveforms.
>
> Click and release control
> .........................
>
> Haptic functionality shall be gated behind the HID_MULTITOUCH_HAPTIC kernel
> configuration option, and this kernel configuration option should only be
> enabled if userspace will support haptic capabilities. Haptic functionality will
> only be initialized and used if HID_MULTITOUCH_HAPTIC is enabled, and if the
> following conditions have been met:
> * ABS_MT_PRESSURE is defined and reporting force units of Newtons or grams.
> * The device supports haptic effects according to the hid protocol defined in
> HUTRR63 [3].
> These checks will happen when the driver probes and initializes the multitouch
> device.
>
> In the case when the kernel configuration option has been set and the device
> reports pressure and haptic effects as defined above, the kernel will initialize
> the haptic device and configure the haptic driver to signal that the touchpad is
> haptic-compatible. To signal to userspace that the touchpad is haptic-compatible
> the kernel will mark INPUT_PROP_HAPTIC_TOUCHPAD.
>
> With userspace willing and able to take control, the kernel will signal to the
> device to exit device-controlled mode once a WAVEFORMPRESS or WAVEFORMRELEASE
> event is uploaded. From here, userspace will take control over press/release
> haptic feedback, relying on the effects sent by the kernel.
>
> In all other cases, the driver will take no action to enable haptic
> functionality.
>
> Summary of normal use-case
> 1. The kernel waits for userspace to upload WAVEFORMPRESS or
> WAVEFORMRELEASE.
> 2. Userspace determines when a click has been performed based on its own
> criteria and tells the touchpad to perform a haptic effect.
> 3. When userspace erases the WAVEFORMPRESS or WAVEFORMRELEASE effect, signal the
> device to return to device-controlled mode.
>
> [0]: https://www.spinics.net/lists/linux-input/msg60938.html
> [1]: https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-devices
> [2]: Usage ID 0x30 of HID usage table 0x0D. See chapter 16:
> https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
> [3]: https://www.usb.org/sites/default/files/hutrr63b_-_haptics_page_redline_0.pdf
> [4]: https://www.kernel.org/doc/html/v4.20/input/ff.html
>
> Signed-off-by: Jonathan Denose <jdenose@google.com>
> ---
> Changes in v3:
> - Change CONFIG_HID_HAPTIC from bool to tristate
> - Fix devm_kzalloc calls in hid-multitouch.c to use correct device
> - Minor comment cleanup + grammar fix
> - Link to v2: https://lore.kernel.org/r/20250818-support-forcepads-v2-0-ca2546e319d5@google.com
>
> Changes in v2:
> - Rename FF_HID and ff_hid_effect to FF_HAPTIC and ff_haptic_effect
> - Add more detail to CONFIG_HID_HAPTIC config option description
> - Remove CONFIG_MULTITOUCH_HAPTIC config option
> - Utilize devm api in hid-multitouch haptic functions
> - Link to v1: https://lore.kernel.org/all/20250714-support-forcepads-v1-0-71c7c05748c9@google.com
>
> ---
> Angela Czubak (11):
> HID: add haptics page defines
> Input: add FF_HAPTIC effect type
> Input: add INPUT_PROP_HAPTIC_TOUCHPAD
> HID: haptic: introduce hid_haptic_device
> HID: input: allow mapping of haptic output
> HID: haptic: initialize haptic device
> HID: input: calculate resolution for pressure
> HID: haptic: add functions handling events
> Input: MT - add INPUT_MT_TOTAL_FORCE flags
> HID: haptic: add hid_haptic_switch_mode
> HID: multitouch: add haptic multitouch support
>
> Documentation/input/event-codes.rst | 14 +
> drivers/hid/Kconfig | 11 +
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-haptic.c | 580 +++++++++++++++++++++++++++++++++
> drivers/hid/hid-haptic.h | 127 ++++++++
> drivers/hid/hid-input.c | 18 +-
> drivers/hid/hid-multitouch.c | 47 +++
> drivers/input/input-mt.c | 14 +-
> include/linux/hid.h | 29 ++
> include/linux/input/mt.h | 1 +
> include/uapi/linux/input-event-codes.h | 1 +
> include/uapi/linux/input.h | 22 +-
> 12 files changed, 858 insertions(+), 7 deletions(-)
> ---
> base-commit: 86731a2a651e58953fc949573895f2fa6d456841
> change-id: 20250625-support-forcepads-0b4f74fd3d0a
>
> Best regards,
> --
> Jonathan Denose <jdenose@google.com>
>
Hi all,
Please let me know if there is anything else needed from me.
Thanks!
--
Jonathan
^ permalink raw reply
* Re: [PATCH v3] HID: lg-g15 - Add support for Logitech G13.
From: Hans de Goede @ 2025-09-02 21:05 UTC (permalink / raw)
To: Leo L. Schwab
Cc: Kate Hsuan, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <aLdWZJwSrpvgXPFL@ewhac.org>
Hi,
On 2-Sep-25 22:41, Leo L. Schwab wrote:
> Didn't directly receive the intermediate reply:
>
> On Tue, Sep 02, 2025 at 11:14:09AM +0200, Hans de Goede wrote:
>> On 2-Sep-25 11:07 AM, Hans de Goede wrote:
>>> Ah I see. Yes if you do need to do a CONFIG check then using IS_ENABLED()
>>> is good.
>>>
>>> But I'm afraid that the underlying problem here is the use of
>>> cdev.brightness_hw_changed this is really only meant for led-class.c
>>> internal use.
>>>
> Then there should be a comment in the include file to that effect.
>
>>> The idea of cdev.brightness_hw_changed is that it stores the last
>>> value set by the hw.
>>>
>>> But in the mean time that value may have been overwritten by software.
>>>
>>> I think that you will fail to call led_classdev_notify_brightness_hw_changed()
>>> (you can add a debug print to check) if the following happens:
>>>
>>> 1. Brightness set to 255 (RGB 255,255,255) through sysfs
>>> 2. State toggled to off by backlight control button, brightness is now 0
>>> 3. Brightness set to 255 (RGB 255,255,255) through sysfs
>>> 4. State toggled to off by backlight control button, brightness is now 0
>>>
> This does not happen. The G13 accepts and remembers backlight color
> settings even when the LEDs have been toggled off locally.
>
> ```
> #### Initial state: Backlight on, full green:
> root:/sys/class/leds/g13:rgb:kbd_backlight# cat brightness brightness_hw_changed multi_intensity
> 255
> 255
> 0 255 0
> root:/sys/class/leds/g13:rgb:kbd_backlight# echo 255 0 0 > multi_intensity
> #### Backlight is on, full red.
> root:/sys/class/leds/g13:rgb:kbd_backlight# cat brightness brightness_hw_changed multi_intensity
> 255
> 255
> 255 0 0
> #### Backlight toggle button pressed; backlight is now off.
> root:/sys/class/leds/g13:rgb:kbd_backlight# cat brightness brightness_hw_changed multi_intensity
> 255
> 0
> 255 0 0
> root:/sys/class/leds/g13:rgb:kbd_backlight# echo 0 0 255 > multi_intensity
> #### Backlight color set to full blue, but is still off.
> root:/sys/class/leds/g13:rgb:kbd_backlight# cat brightness brightness_hw_changed multi_intensity
> 255
> 0
> 0 0 255
> #### Backlight toggle button pressed; backlight is now on, and blue.
> root:/sys/class/leds/g13:rgb:kbd_backlight# cat brightness brightness_hw_changed multi_intensity
> 255
> 255
> 0 0 255
> ```
>
> This also works if you alter `brightness` while the backlight is
> toggled off. IMHO, this is correct, principle-of-least-surprise behavior.
I see, interesting.
So what happens if you turn off the backlight with the toggle button on the G13
and then write 0 to brightness in sysfs and then press the toggle button again?
> Further (at least on my machine), `brightness_hw_changed` is
> read-only in sysfs, and therefore can't be altered by host software.
> Therefore, it would seem that using `cdev.brightness_hw_changed` as a cache
> value is valid.
Right it does seem that using cdev.brightness_hw_changed is valid in
this case.
But the LED API is supposed to have the brightness attribute present
the actual current brightness of the device.
I'm not sure how upower will react if the poll() on brightness_hw_changed
wakes upower up and then the reported brightness is unchanged...
I need to think about this a bit and check the upower code, let me
get back to you on this in a day or 2 ...
>>> I also see that you use TEST_BIT(rep->keybits, 23) ? LED_FULL : LED_OFF
>>> for the brightness value send to led_classdev_notify_brightness_hw_changed()
>>> but I would expect the hw to restore the previous brightness on a toggle
>>> from off -> on through the button? So then that should be send.
>>>
>>> And you also never update cdev.brightness and use the cached
>>> struct lg_g15_led.brightness in lg_g13_kbd_led_get(). This means that
>>> after a hw toggle of the backlight reading the brightness from sysfs
>>> will show the wrong (old) value.
>>>
> This prompts the question: What is the full intensity calculation
> formula intended to be? The docs appear to be rather quiet on this point.
> If we assume all intensity/brightness values (0-255) are essentially mapped
> to the range [0.0, 1.0], then it seems to me the calculation is:
>
> out = intensity * brightness * brightness_hw_changed
The way the API is intended to work is that after a hw-brightness-changes
event brightness == brightness_hw_changed in sysfs.
brightness_hw_changed only purpose is to cache the last hw set value so
that if userspace writing a new value to brightness races with
a brightness_hw_changed event a userspace process listening can still
read which value the hw actually send. TBH this is of little value to
userspace but the LED subsys maintainer insisted on this.
IOW the formula should always be:
out = intensity * brightness
The problem is that in the G13 case the real formula is:
out = intensity * brightness * internal-g13-toggle-bool
And there is no standard userspace API for how to deal with
the device having an internal-g13-toggle-bool
The G510 has something similar which is why I left out
brightness_hw_changed event generation in the G510 code.
As mentioned before I need to think a bit about how to handle
this. I have an idea howto handle this and I can try and
prototype this on the G510 which has more or less the same
problem, except that it simply throws away brightness writes
while toggled off with the button.
>
>>> I think that instead what you need to do is create a
>>> lg_g13_leds_changed_work() mirroring lg_g15_leds_changed_work()
>
> I dissent. But then it's entirely possible I'm still missing
> something...
>
> The only edge case I'm immediately aware of is:
>
> * Plug in G13.
> * Toggle backlight off.
> * Unload kernel module.
> * Reload kernel module.
>
> The backlight is now toggled off, but the newly loaded driver
> doesn't know this. Attempting to read `brightness_hw_changed` from sysfs at
> this point will result in ENODATA (essentially reporting, "I don't know").
> AFAIK, there is no way to probe the G13 for the current state of the
> backlight HW toggle. However, the moment the user generates any event on
> the G13, the correct state will be obtained, and `brightness_hw_changed`
> will be updated accordingly. Not ideal, but seemed the most honest
> approach.
Ack.
Regards,
Hans
^ permalink raw reply
* [PATCH 001/001] hid: Fix for Lenovo Yoga Book 9i top screen
From: Ross Martin @ 2025-09-02 20:54 UTC (permalink / raw)
To: linux-input; +Cc: rydberg
Issue: The current multitouch detection causes the Lenovo Yoga Book 9i
to be detected as type MT_CLS_WIN_8. This has
MT_QUIRK_CONTACT_CNT_ACCURATE set, which causes the touchscreen to
recognize only a single touch, not multitouch.
This patch creates a unique type MT_CLS_LENOVO_YOGA_BOOK_9I for this
laptop, with MT_QUIRK_CONTACT_CNT_ACCURATE removed. The result is that
multitouch works properly on the top screen. This laptop has two
screens, and the bottom one still doesn't work. Partial progress.
Note that this patch defines MT_CLS_LENOVO_YOGA_BOOK_9I as 0x0115,
making it the next in the sequence of IDs. There is a possible issue if
other patches have gone in and also use 0x0115. The number may need to
be adjusted.
Signed-off-by: Ross Martin <ross@bitbybitsp.com>
START OF PATCH
diff -rup linux-orig/drivers/hid/hid-ids.h linux/drivers/hid/hid-ids.h
--- linux-orig/drivers/hid/hid-ids.h 2025-09-02 12:56:48.870143225 -0700
+++ linux/drivers/hid/hid-ids.h 2025-09-02 13:17:55.987704096 -0700
@@ -837,6 +837,7 @@
#define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6093 0x6093
#define USB_DEVICE_ID_LENOVO_LEGION_GO_DUAL_DINPUT 0x6184
#define USB_DEVICE_ID_LENOVO_LEGION_GO2_DUAL_DINPUT 0x61ed
+#define USB_DEVICE_ID_LENOVO_YOGA_BOOK_9I 0x6161
#define USB_VENDOR_ID_LETSKETCH 0x6161
#define USB_DEVICE_ID_WP9620N 0x4d15
diff -rup linux-orig/drivers/hid/hid-multitouch.c
linux/drivers/hid/hid-multitouch.c
--- linux-orig/drivers/hid/hid-multitouch.c 2025-09-02
12:56:48.874143269 -0700
+++ linux/drivers/hid/hid-multitouch.c 2025-09-02 13:18:51.722450468
-0700
@@ -222,6 +222,8 @@ static void mt_post_parse(struct mt_devi
#define MT_CLS_RAZER_BLADE_STEALTH 0x0112
#define MT_CLS_SMART_TECH 0x0113
#define MT_CLS_APPLE_TOUCHBAR 0x0114
+#define MT_CLS_LENOVO_YOGA_BOOK_9I 0x0115
+
#define MT_CLS_SIS 0x0457
#define MT_DEFAULT_MAXCONTACT 10
@@ -413,6 +415,14 @@ static const struct mt_class mt_classes[
MT_QUIRK_APPLE_TOUCHBAR,
.maxcontacts = 11,
},
+ { .name = MT_CLS_LENOVO_YOGA_BOOK_9I,
+ .quirks = MT_QUIRK_ALWAYS_VALID |
+ MT_QUIRK_IGNORE_DUPLICATES |
+ MT_QUIRK_HOVERING |
+ MT_QUIRK_STICKY_FINGERS |
+ MT_QUIRK_WIN8_PTP_BUTTONS,
+ .export_all_inputs = true,
+ },
{ .name = MT_CLS_SIS,
.quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
MT_QUIRK_ALWAYS_VALID |
@@ -2388,6 +2398,11 @@ static const struct hid_device_id mt_dev
HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8,
USB_VENDOR_ID_GOOGLE,
USB_DEVICE_ID_GOOGLE_WHISKERS) },
+ /* Lenovo Yogo Book 9i (adds support for top screen of two screens) */
+ { .driver_data = MT_CLS_LENOVO_YOGA_BOOK_9I,
+ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_LENOVO,
+ USB_DEVICE_ID_LENOVO_YOGA_BOOK_9I) },
+
/* sis */
{ .driver_data = MT_CLS_SIS,
HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_SIS_TOUCH,
END OF PATCH
--
Ross Martin
Bit by Bit Signal Processing LLC
ross@bitbybitsp.com
+1-623-487-8011
^ permalink raw reply
* Re: [PATCH v3 6/7] dt-bindings: mfd: fsl,mc13xxx: add buttons node
From: Rob Herring (Arm) @ 2025-09-02 20:49 UTC (permalink / raw)
To: Alexander Kurz
Cc: Heiko Stuebner, Krzysztof Kozlowski, Dmitry Torokhov,
Conor Dooley, devicetree, Dzmitry Sankouski,
Uwe Kleine-König, linux-kernel, Dr. David Alan Gilbert,
linux-input, Lee Jones
In-Reply-To: <20250829201517.15374-7-akurz@blala.de>
On Fri, 29 Aug 2025 20:15:16 +0000, Alexander Kurz wrote:
> Add a buttons node and properties describing the "ONOFD" (MC13783) and
> "PWRON" (MC13892/MC34708) buttons available in the fsl,mc13xxx PMIC ICs.
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> .../devicetree/bindings/mfd/fsl,mc13xxx.yaml | 70 +++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@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