* Re: [PATCH 1/2] Input: Create input notifier chain in input.c
From: Dmitry Torokhov @ 2025-11-05 22:59 UTC (permalink / raw)
To: Jonathan Denose
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <CAMCVhVP+LW27iLXttyFegRj_HMHheYrZtj4uuERLN0uqUjkR6Q@mail.gmail.com>
On Wed, Nov 05, 2025 at 04:40:29PM -0600, Jonathan Denose wrote:
> Hi Dmitry,
>
> Thanks for your feedback.
>
> On Wed, Nov 5, 2025 at 3:55 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Hi Jonathan,
> >
> > On Thu, Oct 30, 2025 at 02:10:40PM +0000, Jonathan Denose wrote:
> > > To expose input events to other kernel modules, add a blocking notifier
> > > chain. Publish LID_SWITCH_OPEN/LID_SWITCH_CLOSE events through this
> > > notifier chain when input_handle_event detects events signaling the lid
> > > switch has opened or closed.
> > >
> > > Additionally, export a function which allows other kernel modules to
> > > register notifier_block structs against this notifier chain.
> > >
> > > Signed-off-by: Jonathan Denose <jdenose@google.com>
> > > ---
> > > drivers/input/input.c | 13 +++++++++++++
> > > include/linux/input.h | 7 +++++++
> > > 2 files changed, 20 insertions(+)
> > >
> > > diff --git a/drivers/input/input.c b/drivers/input/input.c
> > > index a500e1e276c211d1146dbfea421a3402084007f8..b342b1ff138ccc58d4623edcf1152bd85d7054bf 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/notifier.h>
> > > #include "input-compat.h"
> > > #include "input-core-private.h"
> > > #include "input-poller.h"
> > > @@ -62,6 +63,8 @@ static const unsigned int input_max_code[EV_CNT] = {
> > > [EV_FF] = FF_MAX,
> > > };
> > >
> > > +static struct blocking_notifier_head input_notifier_head;
> > > +
> > > static inline int is_event_supported(unsigned int code,
> > > unsigned long *bm, unsigned int max)
> > > {
> > > @@ -367,10 +370,20 @@ void input_handle_event(struct input_dev *dev,
> > > if (type != EV_SYN)
> > > add_input_randomness(type, code, value);
> > >
> > > + if (type == EV_SW && code == SW_LID && !value)
> > > + blocking_notifier_call_chain(&input_notifier_head, value ?
> > > + LID_SWITCH_CLOSE : LID_SWITCH_OPEN, dev);
> >
> > I would prefer not having this directly in the input core but rather
> > have a lid handler that can then use notifier chain to forward the
> > events further.
>
> Ok, that makes sense to me. In that case, do you have a recommendation
> for where the lid handler should go?
>
> It looks like drivers/acpi/button.c initializes and handles the lid switch, so
> would it make sense for it to go there?
drivers/acpi/button.c is not the only source of SW_LID events (we also
have cros-ec-keyb.c and others), so I'd recommend putting it into
drivers/input, maybe as lid-notifier.c
>
> > Also, here you are running in atomic context, so you need atomic
> > notifier, not blocking (or you need to involve a workqueue).
>
> I'll use an atomic notifier in the next version.
Another option would be to schedule work and then use blocking notifier.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v4 0/3] mfd: twl603x: add power button
From: akemnade @ 2025-11-06 9:00 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andreas Kemnade, Dmitry Torokhov, Tony Lindgren, Kevin Hilman
Cc: devicetree, linux-kernel, linux-input, linux-omap,
Andreas Kemnade
Like the TWL4030, the TWL603x also has a power button feature,
so extend the TWL4030 power button driver to support TWL603x.
Signed-off-by: Andreas Kemnade <akemnade@kernel.org>
---
Changes in v4:
- reorder includes
- use register numbers in struct initializers directly
- Link to v3: https://patch.msgid.link/20251105-twl6030-button-v3-0-9b37eb2b0989@kernel.org
Changes in v3:
- static definition of chipdata
- stricter rules in common part of binding
- Link to v2: https://lore.kernel.org/r/20251030-twl6030-button-v2-0-09653d05a2b1@kernel.org
Changes in v2:
- integrate driver into existing TWL4030 driver
- improve commit messages
- Link to v1: https://lore.kernel.org/r/20251020-twl6030-button-v1-0-93e4644ac974@kernel.org
---
Andreas Kemnade (3):
dt-bindings: mfd: twl: enable power button also for twl603x
Input: twl4030 - add TWL603x power button
ARM: dts: ti/omap: omap4-epson-embt2ws: add powerbutton
Documentation/devicetree/bindings/mfd/ti,twl.yaml | 40 +++++++++++++---
arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts | 5 ++
drivers/input/misc/twl4030-pwrbutton.c | 58 +++++++++++++++++++++--
3 files changed, 93 insertions(+), 10 deletions(-)
---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20251020-twl6030-button-83d759b060e6
Best regards,
--
Andreas Kemnade <akemnade@kernel.org>
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: mfd: twl: enable power button also for twl603x
From: akemnade @ 2025-11-06 9:00 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andreas Kemnade, Dmitry Torokhov, Tony Lindgren, Kevin Hilman
Cc: devicetree, linux-kernel, linux-input, linux-omap,
Andreas Kemnade
In-Reply-To: <20251106-twl6030-button-v4-0-fdf1aa6e1e9a@kernel.org>
From: Andreas Kemnade <andreas@kemnade.info>
TWL603x has also a power button function, so add the corresponding subnode.
As not in all cases there is a power button connected to the corresponding
pad of the TWL603x, the functionality can be disabled by
status = "disabled" or simply not adding the subnode.
To keep things simple, follow the established design pattern of using const
interrupts as used also by the other subdevices.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
Documentation/devicetree/bindings/mfd/ti,twl.yaml | 40 +++++++++++++++++++----
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/ti,twl.yaml b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
index 776b04e182cb..045fd07f476e 100644
--- a/Documentation/devicetree/bindings/mfd/ti,twl.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
@@ -55,6 +55,15 @@ allOf:
gpadc: false
+ pwrbutton:
+ properties:
+ compatible:
+ const: ti,twl4030-pwrbutton
+ interrupts:
+ items:
+ - items:
+ const: 8
+
usb-comparator: false
- if:
@@ -95,7 +104,14 @@ allOf:
compatible:
const: ti,twl6030-gpadc
- pwrbutton: false
+ pwrbutton:
+ properties:
+ compatible:
+ const: ti,twl6030-pwrbutton
+ interrupts:
+ items:
+ - items:
+ const: 0
madc: false
@@ -146,7 +162,14 @@ allOf:
compatible:
const: ti,twl6032-gpadc
- pwrbutton: false
+ pwrbutton:
+ properties:
+ compatible:
+ const: ti,twl6030-pwrbutton
+ interrupts:
+ items:
+ - items:
+ const: 0
madc: false
@@ -226,11 +249,11 @@ properties:
properties:
compatible:
- const: ti,twl4030-pwrbutton
+ enum:
+ - ti,twl4030-pwrbutton
+ - ti,twl6030-pwrbutton
interrupts:
- items:
- - items:
- const: 8
+ maxItems: 1
watchdog:
type: object
@@ -459,6 +482,11 @@ examples:
#io-channel-cells = <1>;
};
+ pwrbutton {
+ compatible = "ti,twl6030-pwrbutton";
+ interrupts = <0>;
+ };
+
rtc {
compatible = "ti,twl4030-rtc";
interrupts = <8>;
--
2.47.3
^ permalink raw reply related
* [PATCH v4 2/3] Input: twl4030 - add TWL603x power button
From: akemnade @ 2025-11-06 9:00 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andreas Kemnade, Dmitry Torokhov, Tony Lindgren, Kevin Hilman
Cc: devicetree, linux-kernel, linux-input, linux-omap,
Andreas Kemnade
In-Reply-To: <20251106-twl6030-button-v4-0-fdf1aa6e1e9a@kernel.org>
From: Andreas Kemnade <andreas@kemnade.info>
Like the TWL4030, these PMICs also have a power button feature, so extend
the TWL4030 power button driver. As the irqchip of the TWL6030 mfd driver
does not provide mask, unmask finctions, do it manually.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
drivers/input/misc/twl4030-pwrbutton.c | 58 +++++++++++++++++++++++++++++++---
1 file changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/input/misc/twl4030-pwrbutton.c b/drivers/input/misc/twl4030-pwrbutton.c
index f85cc289c053..8673b1b441bf 100644
--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -20,6 +20,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#include <linux/bits.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
@@ -30,17 +31,31 @@
#include <linux/platform_device.h>
#include <linux/mfd/twl.h>
-#define PWR_PWRON_IRQ (1 << 0)
+#define PWR_PWRON_IRQ BIT(0)
-#define STS_HW_CONDITIONS 0xf
+struct twl_pwrbutton_chipdata {
+ u8 status_reg;
+ bool need_manual_irq;
+};
+
+static const struct twl_pwrbutton_chipdata twl4030_chipdata = {
+ .status_reg = 0xf,
+ .need_manual_irq = false,
+};
+
+static const struct twl_pwrbutton_chipdata twl6030_chipdata = {
+ .status_reg = 0x2,
+ .need_manual_irq = true,
+};
static irqreturn_t powerbutton_irq(int irq, void *_pwr)
{
struct input_dev *pwr = _pwr;
+ const struct twl_pwrbutton_chipdata *pdata = dev_get_drvdata(pwr->dev.parent);
int err;
u8 value;
- err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, &value, STS_HW_CONDITIONS);
+ err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, &value, pdata->status_reg);
if (!err) {
pm_wakeup_event(pwr->dev.parent, 0);
input_report_key(pwr, KEY_POWER, value & PWR_PWRON_IRQ);
@@ -55,10 +70,17 @@ static irqreturn_t powerbutton_irq(int irq, void *_pwr)
static int twl4030_pwrbutton_probe(struct platform_device *pdev)
{
+ const struct twl_pwrbutton_chipdata *pdata;
struct input_dev *pwr;
int irq = platform_get_irq(pdev, 0);
int err;
+ pdata = device_get_match_data(&pdev->dev);
+ if (!pdata)
+ return -EINVAL;
+
+ platform_set_drvdata(pdev, (void *)pdata);
+
pwr = devm_input_allocate_device(&pdev->dev);
if (!pwr) {
dev_err(&pdev->dev, "Can't allocate power button\n");
@@ -85,14 +107,41 @@ static int twl4030_pwrbutton_probe(struct platform_device *pdev)
return err;
}
+ if (pdata->need_manual_irq) {
+ err = twl6030_interrupt_unmask(0x01, REG_INT_MSK_LINE_A);
+ if (err < 0)
+ return err;
+
+ err = twl6030_interrupt_unmask(0x01, REG_INT_MSK_STS_A);
+ if (err < 0)
+ return err;
+ }
+
device_init_wakeup(&pdev->dev, true);
return 0;
}
+static void twl4030_pwrbutton_remove(struct platform_device *pdev)
+{
+ const struct twl_pwrbutton_chipdata *pdata = platform_get_drvdata(pdev);
+
+ if (pdata->need_manual_irq) {
+ twl6030_interrupt_mask(0x01, REG_INT_MSK_LINE_A);
+ twl6030_interrupt_mask(0x01, REG_INT_MSK_STS_A);
+ }
+}
+
#ifdef CONFIG_OF
static const struct of_device_id twl4030_pwrbutton_dt_match_table[] = {
- { .compatible = "ti,twl4030-pwrbutton" },
+ {
+ .compatible = "ti,twl4030-pwrbutton",
+ .data = &twl4030_chipdata,
+ },
+ {
+ .compatible = "ti,twl6030-pwrbutton",
+ .data = &twl6030_chipdata,
+ },
{},
};
MODULE_DEVICE_TABLE(of, twl4030_pwrbutton_dt_match_table);
@@ -100,6 +149,7 @@ MODULE_DEVICE_TABLE(of, twl4030_pwrbutton_dt_match_table);
static struct platform_driver twl4030_pwrbutton_driver = {
.probe = twl4030_pwrbutton_probe,
+ .remove = twl4030_pwrbutton_remove,
.driver = {
.name = "twl4030_pwrbutton",
.of_match_table = of_match_ptr(twl4030_pwrbutton_dt_match_table),
--
2.47.3
^ permalink raw reply related
* [PATCH v4 3/3] ARM: dts: ti/omap: omap4-epson-embt2ws: add powerbutton
From: akemnade @ 2025-11-06 9:00 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andreas Kemnade, Dmitry Torokhov, Tony Lindgren, Kevin Hilman
Cc: devicetree, linux-kernel, linux-input, linux-omap,
Andreas Kemnade
In-Reply-To: <20251106-twl6030-button-v4-0-fdf1aa6e1e9a@kernel.org>
From: Andreas Kemnade <andreas@kemnade.info>
There is a power button connected to the PMIC, so describe it to be able
to power off the device in a convenient manner.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
index c90f43cc2fae..673df1b693f2 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
+++ b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
@@ -229,6 +229,11 @@ rtc {
interrupts = <11>;
};
+ pwrbutton {
+ compatible = "ti,twl6030-pwrbutton";
+ interrupts = <0>;
+ };
+
ldo2: regulator-ldo2 {
compatible = "ti,twl6032-ldo2";
regulator-min-microvolt = <1000000>;
--
2.47.3
^ permalink raw reply related
* [dtor-input:for-linus] BUILD SUCCESS e08969c4d65ac31297fcb4d31d4808c789152f68
From: kernel test robot @ 2025-11-06 9:49 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: e08969c4d65ac31297fcb4d31d4808c789152f68 Input: cros_ec_keyb - fix an invalid memory access
elapsed time: 1679m
configs tested: 105
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.1.0
alpha allyesconfig clang-19
arc allmodconfig clang-19
arc allnoconfig gcc-15.1.0
arc allyesconfig clang-19
arc randconfig-001-20251106 gcc-12.5.0
arc randconfig-002-20251106 gcc-8.5.0
arm allmodconfig clang-19
arm allnoconfig clang-22
arm allyesconfig clang-19
arm randconfig-001-20251106 gcc-11.5.0
arm randconfig-002-20251106 clang-22
arm randconfig-003-20251106 gcc-10.5.0
arm randconfig-004-20251106 gcc-8.5.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.1.0
csky allnoconfig gcc-15.1.0
hexagon allmodconfig clang-19
hexagon allnoconfig clang-22
hexagon allyesconfig clang-19
hexagon randconfig-001-20251105 clang-22
hexagon randconfig-002-20251105 clang-20
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allyesconfig clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch randconfig-001-20251105 clang-18
loongarch randconfig-002-20251105 clang-20
m68k allmodconfig clang-19
m68k allnoconfig gcc-15.1.0
m68k allyesconfig clang-19
microblaze allmodconfig clang-19
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig clang-19
mips allnoconfig gcc-15.1.0
nios2 allmodconfig clang-22
nios2 allnoconfig gcc-11.5.0
nios2 allyesconfig clang-22
nios2 randconfig-001-20251105 gcc-9.5.0
nios2 randconfig-002-20251105 gcc-8.5.0
openrisc allmodconfig clang-22
openrisc allnoconfig gcc-15.1.0
parisc allnoconfig gcc-15.1.0
parisc randconfig-001-20251105 gcc-12.5.0
parisc randconfig-002-20251105 gcc-10.5.0
powerpc allnoconfig gcc-15.1.0
powerpc randconfig-001-20251105 gcc-14.3.0
powerpc randconfig-002-20251105 gcc-12.5.0
powerpc64 randconfig-001-20251105 clang-22
powerpc64 randconfig-002-20251105 clang-22
riscv allnoconfig gcc-15.1.0
riscv randconfig-001-20251105 gcc-8.5.0
riscv randconfig-002-20251105 clang-18
s390 allmodconfig clang-18
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 randconfig-001-20251105 gcc-8.5.0
s390 randconfig-002-20251105 gcc-14.3.0
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh defconfig gcc-15.1.0
sh randconfig-001-20251105 gcc-10.5.0
sh randconfig-002-20251105 gcc-11.5.0
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc allyesconfig clang-22
sparc randconfig-001-20251106 gcc-15.1.0
sparc randconfig-002-20251106 gcc-15.1.0
sparc64 allmodconfig clang-22
sparc64 allyesconfig clang-22
sparc64 defconfig clang-20
sparc64 randconfig-001-20251106 gcc-13.4.0
sparc64 randconfig-002-20251106 clang-20
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig clang-19
um defconfig clang-22
um i386_defconfig gcc-14
um randconfig-001-20251106 gcc-14
um randconfig-002-20251106 clang-22
um x86_64_defconfig clang-22
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20251105 clang-20
x86_64 buildonly-randconfig-002-20251105 gcc-13
x86_64 buildonly-randconfig-003-20251105 gcc-14
x86_64 buildonly-randconfig-004-20251105 gcc-13
x86_64 buildonly-randconfig-005-20251105 gcc-14
x86_64 buildonly-randconfig-006-20251105 gcc-13
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa allyesconfig clang-22
xtensa randconfig-001-20251106 gcc-9.5.0
xtensa randconfig-002-20251106 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3] Input: rename INPUT_PROP_HAPTIC_TOUCHPAD to INPUT_PROP_PRESSUREPAD
From: Peter Hutterer @ 2025-11-06 11:45 UTC (permalink / raw)
To: Jonathan Denose, Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov,
Jonathan Corbet, Henrik Rydberg
Cc: linux-input, linux-kernel, linux-doc, Angela Czubak,
Sean O'Brien, Randy Dunlap
In-Reply-To: <20251030011735.GA969565@quokka>
And expand it to encompass all pressure pads.
Definition: "pressure pad" as used here as includes all touchpads that
use physical pressure to convert to click, without physical hinges. Also
called haptic touchpads in general parlance, Synaptics calls them
ForcePads.
Most (all?) pressure pads are currently advertised as
INPUT_PROP_BUTTONPAD. The suggestion to identify them as pressure pads
by defining the resolution on ABS_MT_PRESSURE has been in the docs since
commit 20ccc8dd38a3 ("Documentation: input: define
ABS_PRESSURE/ABS_MT_PRESSURE resolution as grams") but few devices
provide this information.
In userspace it's thus impossible to determine whether a device is a
true pressure pad (pressure equals pressure) or a normal clickpad with
(pressure equals finger size).
Commit 7075ae4ac9db ("Input: add INPUT_PROP_HAPTIC_TOUCHPAD") introduces
INPUT_PROP_HAPTIC_TOUCHPAD but restricted it to those touchpads that
have support for userspace-controlled effects. Let's expand and rename
that definition to include all pressure pad touchpads since those that
do support FF effects can be identified by the presence of the
FF_HAPTIC bit.
This means:
- clickpad: INPUT_PROP_BUTTONPAD
- pressurepad: INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD
- pressurepad with configurable haptics:
INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD + FF_HAPTIC
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
ftr, I picked PRESSUREPAD over Dmitry's PRESSURE_TOUCHPAD suggestion
because it matches better with the existing BUTTONPAD.
Changes to v1: extra empty lines to render the lists as lists
Changes to v2: rename to PRESSUREPAD and rename it in the instances
where it's used in the code
v1: https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#u
v2: https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#m9504de27b02d00a55d540fd9fec9aed3edd0133c
Documentation/input/event-codes.rst | 25 ++++++++++++++++++-------
drivers/hid/hid-haptic.c | 2 +-
include/uapi/linux/input-event-codes.h | 2 +-
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
index 1ead9bb8d9c6..4424cbff251f 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -400,19 +400,30 @@ can report through the rotational axes (absolute and/or relative rx, ry, rz).
All other axes retain their meaning. A device must not mix
regular directional axes and accelerometer axes on the same event node.
-INPUT_PROP_HAPTIC_TOUCHPAD
---------------------------
+INPUT_PROP_PRESSUREPAD
+----------------------
+
+The INPUT_PROP_PRESSUREPAD property indicates that the device provides
+simulated haptic feedback (e.g. a vibrator motor situated below the surface)
+instead of physical haptic feedback (e.g. a hinge). This property is only set
+if the device:
-The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that device:
-- supports simple haptic auto and manual triggering
- can differentiate between at least 5 fingers
- uses correct resolution for the X/Y (units and value)
-- reports correct force per touch, and correct units for them (newtons or grams)
- follows the MT protocol type B
+If the simulated haptic feedback is controllable by userspace the device must:
+
+- support simple haptic auto and manual triggering, and
+- report correct force per touch, and correct units for them (newtons or grams), and
+- provide the EV_FF FF_HAPTIC force feedback effect.
+
Summing up, such devices follow the MS spec for input devices in
-Win8 and Win8.1, and in addition support the Simple haptic controller HID table,
-and report correct units for the pressure.
+Win8 and Win8.1, and in addition may support the Simple haptic controller HID
+table, and report correct units for the pressure.
+
+Where applicable, this property is set in addition to INPUT_PROP_BUTTONPAD, it
+does not replace that property.
Guidelines
==========
diff --git a/drivers/hid/hid-haptic.c b/drivers/hid/hid-haptic.c
index aa090684c1f2..fc8a9997f815 100644
--- a/drivers/hid/hid-haptic.c
+++ b/drivers/hid/hid-haptic.c
@@ -86,7 +86,7 @@ int hid_haptic_input_configured(struct hid_device *hdev,
if (hi->application == HID_DG_TOUCHPAD) {
if (haptic->auto_trigger_report &&
haptic->manual_trigger_report) {
- __set_bit(INPUT_PROP_HAPTIC_TOUCHPAD, hi->input->propbit);
+ __set_bit(INPUT_PROP_PRESSUREPAD, hi->input->propbit);
return 1;
}
return 0;
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index 8ba48590bd2c..d21172c6a266 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -27,7 +27,7 @@
#define INPUT_PROP_TOPBUTTONPAD 0x04 /* softbuttons at top of pad */
#define INPUT_PROP_POINTING_STICK 0x05 /* is a pointing stick */
#define INPUT_PROP_ACCELEROMETER 0x06 /* has accelerometer */
-#define INPUT_PROP_HAPTIC_TOUCHPAD 0x07 /* is a haptic touchpad */
+#define INPUT_PROP_PRESSUREPAD 0x07 /* pressure triggers clicks */
#define INPUT_PROP_MAX 0x1f
#define INPUT_PROP_CNT (INPUT_PROP_MAX + 1)
--
2.51.1
^ permalink raw reply related
* Re: [PATCH v4 08/11] input: macsmc-input: New driver to handle the Apple Mac SMC buttons/lid
From: Lee Jones @ 2025-11-06 13:53 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Hector Martin
In-Reply-To: <20251025-macsmc-subdevs-v4-8-374d5c9eba0e@gmail.com>
On Sat, 25 Oct 2025, James Calligeros wrote:
> From: Hector Martin <marcan@marcan.st>
>
> This driver implements power button and lid switch support for Apple Mac
> devices using SMC controllers driven by the macsmc driver.
>
> In addition to basic input support, this also responds to the final
> shutdown warning (when the power button is held down long enough) by
> doing an emergency kernel poweroff. This allows the NVMe controller to
> be cleanly shut down, which prevents data loss for in-cache data.
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> Co-developed-by: Sven Peter <sven@kernel.org>
> Signed-off-by: Sven Peter <sven@kernel.org>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/input/misc/Kconfig | 11 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/macsmc-input.c | 208 +++++++++++++++++++++++++
> 4 files changed, 221 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 79b9f40224a9..e8283f127f11 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2451,6 +2451,7 @@ F: drivers/hwmon/macsmc-hwmon.c
> F: drivers/pmdomain/apple/
> F: drivers/i2c/busses/i2c-pasemi-core.c
> F: drivers/i2c/busses/i2c-pasemi-platform.c
> +F: drivers/input/misc/macsmc-input.c
> F: drivers/input/touchscreen/apple_z2.c
> F: drivers/iommu/apple-dart.c
> F: drivers/iommu/io-pgtable-dart.c
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 0e6b49fb54bc..109660a1a5d2 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -981,4 +981,15 @@ config INPUT_STPMIC1_ONKEY
> To compile this driver as a module, choose M here: the
> module will be called stpmic1_onkey.
>
> +config INPUT_MACSMC
> + tristate "Apple Mac SMC lid/buttons"
> + depends on MFD_MACSMC
> + help
> + Say Y here if you want to use the input events delivered via the
> + SMC controller on Apple Mac machines using the macsmc driver.
> + This includes lid open/close and the power button.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called macsmc-input.
> +
> endif
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index ae857c24f48e..480a0d08d4ae 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_INPUT_IQS7222) += iqs7222.o
> obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
> obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
> obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
> +obj-$(CONFIG_INPUT_MACSMC_INPUT) += macsmc-input.o
> obj-$(CONFIG_INPUT_MAX7360_ROTARY) += max7360-rotary.o
> obj-$(CONFIG_INPUT_MAX77650_ONKEY) += max77650-onkey.o
> obj-$(CONFIG_INPUT_MAX77693_HAPTIC) += max77693-haptic.o
> diff --git a/drivers/input/misc/macsmc-input.c b/drivers/input/misc/macsmc-input.c
> new file mode 100644
> index 000000000000..d35322856526
> --- /dev/null
> +++ b/drivers/input/misc/macsmc-input.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple SMC input event driver
> + * Copyright The Asahi Linux Contributors
> + *
> + * This driver exposes certain events from the SMC as an input device.
> + * This includes the lid open/close and power button notifications.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/mfd/core.h>
This looks like it shouldn't be there.
> +#include <linux/mfd/macsmc.h>
> +#include <linux/module.h>
> +#include <linux/reboot.h>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 03/11] rtc: Add new rtc-macsmc driver for Apple Silicon Macs
From: Lee Jones @ 2025-11-06 13:54 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Hector Martin
In-Reply-To: <20251025-macsmc-subdevs-v4-3-374d5c9eba0e@gmail.com>
On Sat, 25 Oct 2025, James Calligeros wrote:
> From: Hector Martin <marcan@marcan.st>
>
> Apple Silicon Macs (M1, etc.) have an RTC that is part of the PMU IC,
> but most of the PMU functionality is abstracted out by the SMC.
> On T600x machines, the RTC counter must be accessed via the SMC to
> get full functionality, and it seems likely that future machines
> will move towards making SMC handle all RTC functionality.
>
> The SMC RTC counter access is implemented on all current machines
> as of the time of this writing, on firmware 12.x. However, the RTC
> offset (needed to set the time) is still only accessible via direct
> PMU access. To handle this, we expose the RTC offset as an NVMEM
> cell from the SPMI PMU device node, and this driver consumes that
> cell and uses it to compute/set the current time.
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> Signed-off-by: Sven Peter <sven@kernel.org>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/rtc/Kconfig | 11 ++
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-macsmc.c | 141 +++++++++++++++++++++++++
> 4 files changed, 154 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 10f4c0034b5e..3c6322872dd1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2460,6 +2460,7 @@ F: drivers/nvmem/apple-spmi-nvmem.c
> F: drivers/pinctrl/pinctrl-apple-gpio.c
> F: drivers/power/reset/macsmc-reboot.c
> F: drivers/pwm/pwm-apple.c
> +F: drivers/rtc/rtc-macsmc.c
> F: drivers/soc/apple/*
> F: drivers/spi/spi-apple.c
> F: drivers/spmi/spmi-apple-controller.c
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 4a8dc8d0a4b7..e165301d4abb 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -2078,6 +2078,17 @@ config RTC_DRV_WILCO_EC
> This can also be built as a module. If so, the module will
> be named "rtc_wilco_ec".
>
> +config RTC_DRV_MACSMC
> + tristate "Apple Mac System Management Controller RTC"
> + depends on MFD_MACSMC
> + help
> + If you say yes here you get support for RTC functions
> + inside Apple SPMI PMUs accessed through the SoC's
> + System Management Controller
> +
> + To compile this driver as a module, choose M here: the
> + module will be called rtc-macsmc.
> +
> config RTC_DRV_MSC313
> tristate "MStar MSC313 RTC"
> depends on ARCH_MSTARV7 || COMPILE_TEST
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 610a9ee5fd33..32083bd5bb81 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_RTC_DRV_M48T35) += rtc-m48t35.o
> obj-$(CONFIG_RTC_DRV_M48T59) += rtc-m48t59.o
> obj-$(CONFIG_RTC_DRV_M48T86) += rtc-m48t86.o
> obj-$(CONFIG_RTC_DRV_MA35D1) += rtc-ma35d1.o
> +obj-$(CONFIG_RTC_DRV_MACSMC) += rtc-macsmc.o
> obj-$(CONFIG_RTC_DRV_MAX31335) += rtc-max31335.o
> obj-$(CONFIG_RTC_DRV_MAX6900) += rtc-max6900.o
> obj-$(CONFIG_RTC_DRV_MAX6902) += rtc-max6902.o
> diff --git a/drivers/rtc/rtc-macsmc.c b/drivers/rtc/rtc-macsmc.c
> new file mode 100644
> index 000000000000..05e360277f63
> --- /dev/null
> +++ b/drivers/rtc/rtc-macsmc.c
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple SMC RTC driver
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/mfd/core.h>
Why is this here?
> +#include <linux/mfd/macsmc.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/rtc.h>
> +#include <linux/slab.h>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 00/11] mfd: macsmc: add rtc, hwmon and hid subdevices
From: Lee Jones @ 2025-11-06 13:55 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Mark Kettenis, Hector Martin
In-Reply-To: <20251025-macsmc-subdevs-v4-0-374d5c9eba0e@gmail.com>
On Sat, 25 Oct 2025, James Calligeros wrote:
> Hi all,
>
> This series adds support for the remaining SMC subdevices. These are the
> RTC, hwmon, and HID devices. They are being submitted together as the RTC
> and hwmon drivers both require changes to the SMC DT schema.
>
> The RTC driver is responsible for getting and setting the system clock,
> and requires an NVMEM cell. This series replaces Sven's original RTC driver
> submission [1].
>
> The hwmon function is an interesting one. While each Apple Silicon device
> exposes pretty similar sets of sensors, these all seem to be paired to
> different SMC keys in the firmware interface. This is true even when the
> sensors are on the SoC. For example, an M1 MacBook Pro will use different
> keys to access the LITTLE core temperature sensors to an M1 Mac mini. This
> necessitates describing which keys correspond to which sensors for each
> device individually, and populating the hwmon structs at runtime. We do
> this with a node in the device tree. This series includes only the keys
> for sensors which we know to be common to all devices. The SMC is also
> responsible for monitoring and controlling fan speeds on systems with fans,
> which we expose via the hwmon driver.
>
> The SMC also handles the hardware power button and lid switch. Power
> button presses and lid opening/closing are emitted as HID events, so we
> add an input subdevice to handle them.
>
> Since there are no real dependencies between the components of this series,
> it should be fine for each subsystem to take the relevant patches through
> their trees. The mfd one-liners should be taken in order to avoid trivial
> conflicts.
The MFD parts look okay. Let me know when the other drivers have been
accepted and I'll apply them all.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH v4 05/11] mfd: macsmc: Add new __SMC_KEY macro
From: Lee Jones @ 2025-11-06 13:56 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Jonathan Corbet, James Calligeros
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251025-macsmc-subdevs-v4-5-374d5c9eba0e@gmail.com>
On Sat, 25 Oct 2025 10:24:36 +1000, James Calligeros wrote:
> When using the _SMC_KEY macro in switch/case statements, GCC 15.2.1 errors
> out with 'case label does not reduce to an integer constant'. Introduce
> a new __SMC_KEY macro that can be used instead.
>
>
Applied, thanks!
[05/11] mfd: macsmc: Add new __SMC_KEY macro
commit: 8c3290b4c975e35a01aecfb51e0e004b6f7c0480
--
Lee Jones [李琼斯]
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD and HWMON due for the v6.19 merge window
From: Lee Jones @ 2025-11-06 14:00 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251025-macsmc-subdevs-v4-6-374d5c9eba0e@gmail.com>
Whoever takes this driver will need to pull the following:
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-hwmon-v6.19
for you to fetch changes up to b340412a3b22b60b5e19cce8726940c7b5b14439:
mfd: macsmc: Add new __SMC_KEY macro (2025-11-06 13:58:42 +0000)
----------------------------------------------------------------
Immutable branch between MFD and HWMON due for the v6.19 merge window
----------------------------------------------------------------
James Calligeros (1):
mfd: macsmc: Add new __SMC_KEY macro
include/linux/mfd/macsmc.h | 1 +
1 file changed, 1 insertion(+)
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3] Input: rename INPUT_PROP_HAPTIC_TOUCHPAD to INPUT_PROP_PRESSUREPAD
From: Benjamin Tissoires @ 2025-11-06 14:32 UTC (permalink / raw)
To: Peter Hutterer
Cc: Jonathan Denose, Jiri Kosina, Dmitry Torokhov, Jonathan Corbet,
Henrik Rydberg, linux-input, linux-kernel, linux-doc,
Angela Czubak, Sean O'Brien, Randy Dunlap
In-Reply-To: <20251106114534.GA405512@tassie>
On Nov 06 2025, Peter Hutterer wrote:
> And expand it to encompass all pressure pads.
>
> Definition: "pressure pad" as used here as includes all touchpads that
> use physical pressure to convert to click, without physical hinges. Also
> called haptic touchpads in general parlance, Synaptics calls them
> ForcePads.
>
> Most (all?) pressure pads are currently advertised as
> INPUT_PROP_BUTTONPAD. The suggestion to identify them as pressure pads
> by defining the resolution on ABS_MT_PRESSURE has been in the docs since
> commit 20ccc8dd38a3 ("Documentation: input: define
> ABS_PRESSURE/ABS_MT_PRESSURE resolution as grams") but few devices
> provide this information.
>
> In userspace it's thus impossible to determine whether a device is a
> true pressure pad (pressure equals pressure) or a normal clickpad with
> (pressure equals finger size).
>
> Commit 7075ae4ac9db ("Input: add INPUT_PROP_HAPTIC_TOUCHPAD") introduces
> INPUT_PROP_HAPTIC_TOUCHPAD but restricted it to those touchpads that
> have support for userspace-controlled effects. Let's expand and rename
> that definition to include all pressure pad touchpads since those that
> do support FF effects can be identified by the presence of the
> FF_HAPTIC bit.
>
> This means:
> - clickpad: INPUT_PROP_BUTTONPAD
> - pressurepad: INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD
> - pressurepad with configurable haptics:
> INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD + FF_HAPTIC
>
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Unless Jiri has any problem with it, I guess this would be fine going
through your tree Dmitry.
Cheers,
Benjamin
> ---
> ftr, I picked PRESSUREPAD over Dmitry's PRESSURE_TOUCHPAD suggestion
> because it matches better with the existing BUTTONPAD.
>
> Changes to v1: extra empty lines to render the lists as lists
> Changes to v2: rename to PRESSUREPAD and rename it in the instances
> where it's used in the code
>
> v1: https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#u
> v2: https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#m9504de27b02d00a55d540fd9fec9aed3edd0133c
>
> Documentation/input/event-codes.rst | 25 ++++++++++++++++++-------
> drivers/hid/hid-haptic.c | 2 +-
> include/uapi/linux/input-event-codes.h | 2 +-
> 3 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
> index 1ead9bb8d9c6..4424cbff251f 100644
> --- a/Documentation/input/event-codes.rst
> +++ b/Documentation/input/event-codes.rst
> @@ -400,19 +400,30 @@ can report through the rotational axes (absolute and/or relative rx, ry, rz).
> All other axes retain their meaning. A device must not mix
> regular directional axes and accelerometer axes on the same event node.
>
> -INPUT_PROP_HAPTIC_TOUCHPAD
> ---------------------------
> +INPUT_PROP_PRESSUREPAD
> +----------------------
> +
> +The INPUT_PROP_PRESSUREPAD property indicates that the device provides
> +simulated haptic feedback (e.g. a vibrator motor situated below the surface)
> +instead of physical haptic feedback (e.g. a hinge). This property is only set
> +if the device:
>
> -The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that device:
> -- supports simple haptic auto and manual triggering
> - can differentiate between at least 5 fingers
> - uses correct resolution for the X/Y (units and value)
> -- reports correct force per touch, and correct units for them (newtons or grams)
> - follows the MT protocol type B
>
> +If the simulated haptic feedback is controllable by userspace the device must:
> +
> +- support simple haptic auto and manual triggering, and
> +- report correct force per touch, and correct units for them (newtons or grams), and
> +- provide the EV_FF FF_HAPTIC force feedback effect.
> +
> Summing up, such devices follow the MS spec for input devices in
> -Win8 and Win8.1, and in addition support the Simple haptic controller HID table,
> -and report correct units for the pressure.
> +Win8 and Win8.1, and in addition may support the Simple haptic controller HID
> +table, and report correct units for the pressure.
> +
> +Where applicable, this property is set in addition to INPUT_PROP_BUTTONPAD, it
> +does not replace that property.
>
> Guidelines
> ==========
> diff --git a/drivers/hid/hid-haptic.c b/drivers/hid/hid-haptic.c
> index aa090684c1f2..fc8a9997f815 100644
> --- a/drivers/hid/hid-haptic.c
> +++ b/drivers/hid/hid-haptic.c
> @@ -86,7 +86,7 @@ int hid_haptic_input_configured(struct hid_device *hdev,
> if (hi->application == HID_DG_TOUCHPAD) {
> if (haptic->auto_trigger_report &&
> haptic->manual_trigger_report) {
> - __set_bit(INPUT_PROP_HAPTIC_TOUCHPAD, hi->input->propbit);
> + __set_bit(INPUT_PROP_PRESSUREPAD, hi->input->propbit);
> return 1;
> }
> return 0;
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 8ba48590bd2c..d21172c6a266 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -27,7 +27,7 @@
> #define INPUT_PROP_TOPBUTTONPAD 0x04 /* softbuttons at top of pad */
> #define INPUT_PROP_POINTING_STICK 0x05 /* is a pointing stick */
> #define INPUT_PROP_ACCELEROMETER 0x06 /* has accelerometer */
> -#define INPUT_PROP_HAPTIC_TOUCHPAD 0x07 /* is a haptic touchpad */
> +#define INPUT_PROP_PRESSUREPAD 0x07 /* pressure triggers clicks */
>
> #define INPUT_PROP_MAX 0x1f
> #define INPUT_PROP_CNT (INPUT_PROP_MAX + 1)
> --
> 2.51.1
>
^ permalink raw reply
* [PATCH] hid/hid-multitouch: Keep latency normal on deactivate for reactivation gesture
From: Werner Sembach @ 2025-11-06 15:45 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: Werner Sembach, linux-input, linux-kernel
Uniwill devices have a built in gesture in the touchpad to de- and
reactivate it by double taping the upper left corner. This gesture stops
working when latency is set to high, so this patch keeps the latency on
normal.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
Or should I better implement this as a quirk?
drivers/hid/hid-multitouch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 179dc316b4b51..df64cb6c41699 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1998,7 +1998,7 @@ static void mt_on_hid_hw_open(struct hid_device *hdev)
static void mt_on_hid_hw_close(struct hid_device *hdev)
{
- mt_set_modes(hdev, HID_LATENCY_HIGH, TOUCHPAD_REPORT_NONE);
+ mt_set_modes(hdev, HID_LATENCY_NORMAL, TOUCHPAD_REPORT_NONE);
}
/*
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] hid/hid-multitouch: Keep latency normal on deactivate for reactivation gesture
From: Werner Sembach @ 2025-11-06 15:48 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel
In-Reply-To: <20251106154636.985427-1-wse@tuxedocomputers.com>
Am 06.11.25 um 16:45 schrieb Werner Sembach:
> Uniwill devices have a built in gesture in the touchpad to de- and
> reactivate it by double taping the upper left corner. This gesture stops
> working when latency is set to high, so this patch keeps the latency on
> normal.
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Forgot again to add cc stable, please add it if the patch gets accepted.
> ---
> Or should I better implement this as a quirk?
>
> drivers/hid/hid-multitouch.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 179dc316b4b51..df64cb6c41699 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -1998,7 +1998,7 @@ static void mt_on_hid_hw_open(struct hid_device *hdev)
>
> static void mt_on_hid_hw_close(struct hid_device *hdev)
> {
> - mt_set_modes(hdev, HID_LATENCY_HIGH, TOUCHPAD_REPORT_NONE);
> + mt_set_modes(hdev, HID_LATENCY_NORMAL, TOUCHPAD_REPORT_NONE);
> }
>
> /*
^ permalink raw reply
* Re: [PATCH] hid/hid-multitouch: Keep latency normal on deactivate for reactivation gesture
From: Benjamin Tissoires @ 2025-11-06 16:50 UTC (permalink / raw)
To: Werner Sembach; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <20251106154636.985427-1-wse@tuxedocomputers.com>
On Nov 06 2025, Werner Sembach wrote:
> Uniwill devices have a built in gesture in the touchpad to de- and
> reactivate it by double taping the upper left corner. This gesture stops
> working when latency is set to high, so this patch keeps the latency on
> normal.
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
> Or should I better implement this as a quirk?
Yeah, I guess a quirk would be appreciated. The high latency on close
was introduced on purpose for saving energy purpose. So this patch is
rather not nice for those systems where it matters.
Cheers,
Benjamin
>
> drivers/hid/hid-multitouch.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 179dc316b4b51..df64cb6c41699 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -1998,7 +1998,7 @@ static void mt_on_hid_hw_open(struct hid_device *hdev)
>
> static void mt_on_hid_hw_close(struct hid_device *hdev)
> {
> - mt_set_modes(hdev, HID_LATENCY_HIGH, TOUCHPAD_REPORT_NONE);
> + mt_set_modes(hdev, HID_LATENCY_NORMAL, TOUCHPAD_REPORT_NONE);
> }
>
> /*
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: mfd: twl: enable power button also for twl603x
From: Conor Dooley @ 2025-11-06 17:25 UTC (permalink / raw)
To: akemnade
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andreas Kemnade, Dmitry Torokhov, Tony Lindgren, Kevin Hilman,
devicetree, linux-kernel, linux-input, linux-omap
In-Reply-To: <20251106-twl6030-button-v4-1-fdf1aa6e1e9a@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] hid/hid-multitouch: Keep latency normal on deactivate for reactivation gesture
From: Werner Sembach @ 2025-11-06 18:19 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <s2pc7whgvrwaldkgkle4ydkyc26q75senkmtesv57du6x7bxoa@mq3ght3dksdr>
Am 06.11.25 um 17:50 schrieb Benjamin Tissoires:
> On Nov 06 2025, Werner Sembach wrote:
>> Uniwill devices have a built in gesture in the touchpad to de- and
>> reactivate it by double taping the upper left corner. This gesture stops
>> working when latency is set to high, so this patch keeps the latency on
>> normal.
>>
>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>> ---
>> Or should I better implement this as a quirk?
> Yeah, I guess a quirk would be appreciated. The high latency on close
> was introduced on purpose for saving energy purpose. So this patch is
> rather not nice for those systems where it matters.
ack
v2 incoming
>
> Cheers,
> Benjamin
>
>> drivers/hid/hid-multitouch.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>> index 179dc316b4b51..df64cb6c41699 100644
>> --- a/drivers/hid/hid-multitouch.c
>> +++ b/drivers/hid/hid-multitouch.c
>> @@ -1998,7 +1998,7 @@ static void mt_on_hid_hw_open(struct hid_device *hdev)
>>
>> static void mt_on_hid_hw_close(struct hid_device *hdev)
>> {
>> - mt_set_modes(hdev, HID_LATENCY_HIGH, TOUCHPAD_REPORT_NONE);
>> + mt_set_modes(hdev, HID_LATENCY_NORMAL, TOUCHPAD_REPORT_NONE);
>> }
>>
>> /*
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH] HID: hid-input: Extend Elan ignore battery quirk to USB
From: Dmitry Torokhov @ 2025-11-06 19:10 UTC (permalink / raw)
To: Hans de Goede
Cc: Jiri Kosina, Mario Limonciello (AMD), mario.limonciello, bentiss,
André Barata, linux-input, Kenneth Albanowski
In-Reply-To: <CAE_wzQ_YvCh8a83mm3QG7LwMWo2CKEAMvRS7+CpJcq1r7MEBZA@mail.gmail.com>
On Fri, Oct 31, 2025 at 7:47 AM Dmitry Torokhov <dtor@google.com> wrote:
>
> Hi Hans,
>
> On Fri, Oct 31, 2025 at 2:13 AM Hans de Goede <hansg@kernel.org> wrote:
> >
> > Hi Jiri,
> >
> > On 31-Oct-25 10:07 AM, Jiri Kosina wrote:
> > > On Thu, 30 Oct 2025, Mario Limonciello (AMD) wrote:
> > >
> > >> USB Elan devices have the same problem as the I2C ones with a fake
> > >> battery device showing up.
> > >>
> > >> Reviewed-by: Hans de Goede <hansg@kernel.org>
> > >> Reported-by: André Barata <andretiagob@protonmail.com>
> > >> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220722
> > >> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
> > >
> > > Now applied.
> > >
> > > We'll have to come up with something more sophisticated once/if Elan ever
> > > starts producing devices with real battery ...
> >
> > Actually the provided HID battery is intended to be for
> > when a stylus is used and to report the stylus battery
> > values then.
> >
> > There is an email thread somewhere with some of the ChromeOS folks
> > talking about dropping the ELAN quirk for I2C touchscreens and
> > indeed replacing it with something more sophisticated. IIRC
> > the ChromeOS folks mentioned they would work on / provide patches.
> >
> > +To: Dmitry, Dmitry do you have any input on the ChromeOs issue ?
>
> +Kenneth Albanowski has been wrangling with support of Elan and other
> vendor styli, I'll let him comment.
Kenneth is currently busy with some internal projects and asked me to
pass the following:
We recommend that userspace components do not generate alerts for
power supplies that report "status" as "unknown". For a lot of styli
we start with "unknown" and 0 level until after we get a first real
report and update the state to "discharging" or "full" and only hen we
may start showing the indicator.
On ChromeOS we also have tech for clarifying "1%" and other bad
reports, currently specific to USI styluses using a S/N filter.
Kenneth will try to share more details next week hopefully.
Thanks,
Dmitry
^ permalink raw reply
* [PATCH v2] hid/hid-multitouch: Keep latency normal on deactivate for reactivation gesture
From: Werner Sembach @ 2025-11-06 19:59 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: Werner Sembach, linux-input, linux-kernel
Uniwill devices have a built in gesture in the touchpad to de- and
reactivate it by double taping the upper left corner. This gesture stops
working when latency is set to high, so this patch keeps the latency on
normal.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: stable@vger.kernel.org
---
V1->V2: Use a quirk to narrow down the devices this is applied to.
I have three Uniwill devices at hand right now that have at least two
physically different touchpads, but same Vendor + Product ID combination.
Maybe the vendor uses this product ID for all i2c connected touchpads, or
it is used as some kind of subvendor ID to indicate Uniwill?
To be able to really narrow it down to Uniwill only devices I would need to
check DMI strings, but then I will probably narrow it down to much as I
only know what we at TUXEDO use there.
drivers/hid/hid-multitouch.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 179dc316b4b51..470f199148057 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -76,6 +76,7 @@ MODULE_LICENSE("GPL");
#define MT_QUIRK_DISABLE_WAKEUP BIT(21)
#define MT_QUIRK_ORIENTATION_INVERT BIT(22)
#define MT_QUIRK_APPLE_TOUCHBAR BIT(23)
+#define MT_QUIRK_KEEP_LATENCY_ON_CLOSE BIT(24)
#define MT_INPUTMODE_TOUCHSCREEN 0x02
#define MT_INPUTMODE_TOUCHPAD 0x03
@@ -229,6 +230,7 @@ static void mt_post_parse(struct mt_device *td, struct mt_application *app);
#define MT_CLS_RAZER_BLADE_STEALTH 0x0112
#define MT_CLS_SMART_TECH 0x0113
#define MT_CLS_APPLE_TOUCHBAR 0x0114
+#define MT_CLS_UNIWILL_TOUCHPAD 0x0115
#define MT_CLS_SIS 0x0457
#define MT_DEFAULT_MAXCONTACT 10
@@ -420,6 +422,9 @@ static const struct mt_class mt_classes[] = {
MT_QUIRK_APPLE_TOUCHBAR,
.maxcontacts = 11,
},
+ { .name = MT_CLS_UNIWILL_TOUCHPAD,
+ .quirks = MT_QUIRK_KEEP_LATENCY_ON_CLOSE,
+ },
{ .name = MT_CLS_SIS,
.quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
MT_QUIRK_ALWAYS_VALID |
@@ -1998,7 +2003,12 @@ static void mt_on_hid_hw_open(struct hid_device *hdev)
static void mt_on_hid_hw_close(struct hid_device *hdev)
{
- mt_set_modes(hdev, HID_LATENCY_HIGH, TOUCHPAD_REPORT_NONE);
+ struct mt_device *td = hid_get_drvdata(hdev);
+
+ if (td->mtclass.quirks & MT_QUIRK_KEEP_LATENCY_ON_CLOSE)
+ mt_set_modes(hdev, HID_LATENCY_NORMAL, TOUCHPAD_REPORT_NONE);
+ else
+ mt_set_modes(hdev, HID_LATENCY_HIGH, TOUCHPAD_REPORT_NONE);
}
/*
@@ -2375,6 +2385,11 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_UNITEC,
USB_DEVICE_ID_UNITEC_USB_TOUCH_0A19) },
+ /* Uniwill touchpads */
+ { .driver_data = MT_CLS_UNIWILL_TOUCHPAD,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_PIXART, 0x0255) },
+
/* VTL panels */
{ .driver_data = MT_CLS_VTL,
MT_USB_DEVICE(USB_VENDOR_ID_VTL,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 01/11] dt-bindings: arm: fsl: Add various solidrun i.mx8m boards
From: Josua Mayer @ 2025-11-07 11:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Lad Prabhakar, Thierry Reding
Cc: Jon Nettleton, Mikhail Anikin, Yazan Shhady, devicetree,
linux-kernel, dri-devel, linux-input, imx, linux-arm-kernel,
Josua Mayer, Krzysztof Kozlowski
In-Reply-To: <20251107-imx8mp-hb-iiot-v2-0-d8233ded999e@solid-run.com>
Add bindings for various SolidRun boards:
- i.MX8MP HummingBoard IIoT - based on the SolidRun i.MX8M Plus SoM
- SolidSense N8 - single-board design with i.MX8M Nano
- i.MX8M Mini System on Module
- i.MX8M Mini HummingBoard Ripple
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 00cdf490b0620..f70b933ce3746 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1041,6 +1041,13 @@ properties:
- const: phytec,imx8mm-phycore-som # phyCORE-i.MX8MM SoM
- const: fsl,imx8mm
+ - description: SolidRun i.MX8MM SoM based boards
+ items:
+ - enum:
+ - solidrun,imx8mm-hummingboard-ripple # SolidRun i.MX8MM SoM on HummingBoard Ripple
+ - const: solidrun,imx8mm-sr-som
+ - const: fsl,imx8mm
+
- description: Variscite VAR-SOM-MX8MM based boards
items:
- const: variscite,var-som-mx8mm-symphony
@@ -1069,6 +1076,7 @@ properties:
- fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board
- fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board
- gw,imx8mn-gw7902 # i.MX8MM Gateworks Board
+ - solidrun,solidsense-n8-compact # SolidRun SolidSense N8 Compact
- const: fsl,imx8mn
- description: Variscite VAR-SOM-MX8MN based boards
@@ -1205,6 +1213,7 @@ properties:
items:
- enum:
- solidrun,imx8mp-cubox-m # SolidRun i.MX8MP SoM on CuBox-M
+ - solidrun,imx8mp-hummingboard-iiot # SolidRun i.MX8MP SoM on HummingBoard IIoT
- solidrun,imx8mp-hummingboard-mate # SolidRun i.MX8MP SoM on HummingBoard Mate
- solidrun,imx8mp-hummingboard-pro # SolidRun i.MX8MP SoM on HummingBoard Pro
- solidrun,imx8mp-hummingboard-pulse # SolidRun i.MX8MP SoM on HummingBoard Pulse
--
2.51.0
^ permalink raw reply related
* [PATCH v2 02/11] dt-bindings: display: panel: ronbo,rb070d30: panel-common ref
From: Josua Mayer @ 2025-11-07 11:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Lad Prabhakar, Thierry Reding
Cc: Jon Nettleton, Mikhail Anikin, Yazan Shhady, devicetree,
linux-kernel, dri-devel, linux-input, imx, linux-arm-kernel,
Josua Mayer
In-Reply-To: <20251107-imx8mp-hb-iiot-v2-0-d8233ded999e@solid-run.com>
Add missing ref on panel-common.yaml for this dsi panel so that common
properties can be shared.
Drop reset-gpios and backlight as they are already in panel-common.
Switch from additionalProperties to unevaluatedProperties so that common
panel properties are available without repeating them in this binding.
Notably panel-common defines the "port" property for linking panels to a
source - which was missing from this panel. Mark it as required.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
.../devicetree/bindings/display/panel/ronbo,rb070d30.yaml | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
index 04f86e0cbac91..6940373015833 100644
--- a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
@@ -9,6 +9,9 @@ title: Ronbo RB070D30 DSI Display Panel
maintainers:
- Maxime Ripard <mripard@kernel.org>
+allOf:
+ - $ref: panel-common.yaml#
+
properties:
compatible:
const: ronbo,rb070d30
@@ -20,10 +23,6 @@ properties:
description: GPIO used for the power pin
maxItems: 1
- reset-gpios:
- description: GPIO used for the reset pin
- maxItems: 1
-
shlr-gpios:
description: GPIO used for the shlr pin (horizontal flip)
maxItems: 1
@@ -35,10 +34,6 @@ properties:
vcc-lcd-supply:
description: Power regulator
- backlight:
- description: Backlight used by the panel
- $ref: /schemas/types.yaml#/definitions/phandle
-
required:
- compatible
- power-gpios
@@ -47,5 +42,6 @@ required:
- shlr-gpios
- updn-gpios
- vcc-lcd-supply
+ - port
-additionalProperties: false
+unevaluatedProperties: false
--
2.51.0
^ permalink raw reply related
* [PATCH v2 00/11] arm64: dts: add description for solidrun imx8mp hummingboard-iiot
From: Josua Mayer @ 2025-11-07 11:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Lad Prabhakar, Thierry Reding
Cc: Jon Nettleton, Mikhail Anikin, Yazan Shhady, devicetree,
linux-kernel, dri-devel, linux-input, imx, linux-arm-kernel,
Josua Mayer, Krzysztof Kozlowski
This patchset mainl adds description for 3 SolidRun boards:
- i.MX8MP Hummingboard IIoT
- SolidSense N8 Compact
- i.MX8MM Hummingboard Ripple
This includes dt bindings and a range of bug-fixes:
- dt bindings for the boards
- fix to dsi panel bindings referncing panel-common and adding port
property
- cosmetic fix to some solidrun imx8mp boards for regulator gpio
polarity
- fix dsi hdmi bridge on hummingboard pulse
- compile dtbs with symbols to support overlays
- gpiod_set_value _can_sleep conversion for panel and touchscreen
drivers
Open Questions:
- How to describe HX3 USB-2.0/3.0 Hub placed on a USB-2.0-only Bus
(affects imx8mm-hummingboard-ripple.dts)
- Is "description for" implied not only on dt-bindings patches, but also
dts? E.g. is this commit subject acceptable?:
"arm64: dts: add solidrun solidsense-n8 board"
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Changes in v2:
- fix spelling mistakes in commit descriptions.
- remove redundant "binding for" from subject:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst
(Reported-by: Krzysztof Kozlowski <krzk@kernel.org>)
- remove one useless comment from imx8mm-sr-som.dtsi to fix long line
warning.
- change ronbo panel binding to inherit panel-common and switch
additionalProperties to unevaluatedProperties.
(Reported-by: Krzysztof Kozlowski <krzk@kernel.org>)
- add dt binding for winstar lvds panel
- fix dtbs_check for dsi & lvds panel addons
- change n8 board dts comment-style in header
- collected ack on solidrun boards bindings patch (patch 1 in the series)
(Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>)
- added standard led label property to hb-iiot multi-purpose leds
ensuring consistent names in case lp5562 driver starts using it.
- Link to v1: https://lore.kernel.org/r/20251027-imx8mp-hb-iiot-v1-0-683f86357818@solid-run.com
---
Josua Mayer (11):
dt-bindings: arm: fsl: Add various solidrun i.mx8m boards
dt-bindings: display: panel: ronbo,rb070d30: panel-common ref
dt-bindings: panel: lvds: add Winstar WF70A8SYJHLNGA
Input: ilitek_ts_i2c: fix warning with gpio controllers that sleep
drm/panel: ronbo-rb070d30: fix warning with gpio controllers that sleep
arm64: dts: imx8mp-hummingboard-pulse/cubox-m: fix vmmc gpio polarity
arm64: dts: imx8mp-hummingboard-pulse: fix mini-hdmi dsi port reference
arm64: dts: imx8mp-sr-som: build dtbs with symbols for overlay support
arm64: dts: add description for solidrun imx8mp hummingboard-iiot
arm64: dts: add description for solidrun solidsense-n8 board
arm64: dts: add description for solidrun i.mx8mm som and evb
Documentation/devicetree/bindings/arm/fsl.yaml | 9 +
.../bindings/display/panel/panel-lvds.yaml | 2 +
.../bindings/display/panel/ronbo,rb070d30.yaml | 14 +-
arch/arm64/boot/dts/freescale/Makefile | 15 +
.../dts/freescale/imx8mm-hummingboard-ripple.dts | 335 ++++++++
arch/arm64/boot/dts/freescale/imx8mm-sr-som.dtsi | 395 ++++++++++
.../dts/freescale/imx8mn-solidsense-n8-compact.dts | 853 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mp-cubox-m.dts | 2 +-
...hummingboard-iiot-panel-dsi-WJ70N3TYJHMNG0.dtso | 69 ++
...ummingboard-iiot-panel-lvds-WF70A8SYJHLNGA.dtso | 105 +++
.../imx8mp-hummingboard-iiot-rs485-a.dtso | 18 +
.../imx8mp-hummingboard-iiot-rs485-b.dtso | 18 +
.../dts/freescale/imx8mp-hummingboard-iiot.dts | 712 +++++++++++++++++
.../imx8mp-hummingboard-pulse-common.dtsi | 2 +-
.../imx8mp-hummingboard-pulse-mini-hdmi.dtsi | 11 +-
drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 8 +-
drivers/input/touchscreen/ilitek_ts_i2c.c | 4 +-
17 files changed, 2548 insertions(+), 24 deletions(-)
---
base-commit: 607bcb1e539a7f2b2ba6832ba96fe3ad73b7401c
change-id: 20251026-imx8mp-hb-iiot-525b03beea62
Best regards,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply
* [PATCH v2 04/11] Input: ilitek_ts_i2c: fix warning with gpio controllers that sleep
From: Josua Mayer @ 2025-11-07 11:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Lad Prabhakar, Thierry Reding
Cc: Jon Nettleton, Mikhail Anikin, Yazan Shhady, devicetree,
linux-kernel, dri-devel, linux-input, imx, linux-arm-kernel,
Josua Mayer
In-Reply-To: <20251107-imx8mp-hb-iiot-v2-0-d8233ded999e@solid-run.com>
The ilitek touchscreen driver uses the non-sleeping gpiod_set_value
function for reset.
When the connected gpio controller needs to sleep as is common for i2c
based expanders, this causes noisy complaints in kernel log.
Reset is not time-critical, switch to the gpiod_set_value_cansleep
variant.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
drivers/input/touchscreen/ilitek_ts_i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/ilitek_ts_i2c.c b/drivers/input/touchscreen/ilitek_ts_i2c.c
index 0dd632724a003..8c5a54b336816 100644
--- a/drivers/input/touchscreen/ilitek_ts_i2c.c
+++ b/drivers/input/touchscreen/ilitek_ts_i2c.c
@@ -396,9 +396,9 @@ static const struct ilitek_protocol_map ptl_func_map[] = {
static void ilitek_reset(struct ilitek_ts_data *ts, int delay)
{
if (ts->reset_gpio) {
- gpiod_set_value(ts->reset_gpio, 1);
+ gpiod_set_value_cansleep(ts->reset_gpio, 1);
mdelay(10);
- gpiod_set_value(ts->reset_gpio, 0);
+ gpiod_set_value_cansleep(ts->reset_gpio, 0);
mdelay(delay);
}
}
--
2.51.0
^ permalink raw reply related
* [PATCH v2 07/11] arm64: dts: imx8mp-hummingboard-pulse: fix mini-hdmi dsi port reference
From: Josua Mayer @ 2025-11-07 11:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Lad Prabhakar, Thierry Reding
Cc: Jon Nettleton, Mikhail Anikin, Yazan Shhady, devicetree,
linux-kernel, dri-devel, linux-input, imx, linux-arm-kernel,
Josua Mayer
In-Reply-To: <20251107-imx8mp-hb-iiot-v2-0-d8233ded999e@solid-run.com>
imx8mp.dtsi includes a default port@1 node with an empty placeholder
endpoint intended for linking to a dsi bridge or panel.
HummingBoard Pulse mini-hdmi dtsi added and linked hdmi brodge to yet
another endpoint.
This duplicate endpoint can cause dsi_attach to fail.
Remove the duplicate node and link to the one defined in soc dtsi.
Further remove the unnecessary attach-bridge property.
Fixes: 2a222aa2bee9 ("arm64: dts: add description for solidrun imx8mp hummingboard variants")
Signed-off-by Josua Mayer <josua@solid-run.com>
---
.../dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi
index 46916ddc05335..0e5f4607c7c1b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-pulse-mini-hdmi.dtsi
@@ -41,7 +41,7 @@ port@0 {
reg = <0>;
adv7535_from_dsim: endpoint {
- remote-endpoint = <&dsim_to_adv7535>;
+ remote-endpoint = <&mipi_dsi_out>;
};
};
@@ -71,11 +71,8 @@ &lcdif1 {
&mipi_dsi {
samsung,esc-clock-frequency = <10000000>;
status = "okay";
+};
- port@1 {
- dsim_to_adv7535: endpoint {
- remote-endpoint = <&adv7535_from_dsim>;
- attach-bridge;
- };
- };
+&mipi_dsi_out {
+ remote-endpoint = <&adv7535_from_dsim>;
};
--
2.51.0
^ permalink raw reply related
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