* [PATCH AUTOSEL 6.7 11/14] Input: gpio_keys_polled - suppress deferred probe error for gpio
From: Sasha Levin @ 2024-03-11 18:36 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Uwe Kleine-König, Linus Walleij, Dmitry Torokhov,
Sasha Levin, linux-input
In-Reply-To: <20240311183618.327694-1-sashal@kernel.org>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[ Upstream commit 963465a33141d0d52338e77f80fe543d2c9dc053 ]
On a PC Engines APU our admins are faced with:
$ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517"
261
Such a message always appears when e.g. a new USB device is plugged in.
Suppress this message which considerably clutters the kernel log for
EPROBE_DEFER (i.e. -517).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240305101042.10953-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/keyboard/gpio_keys_polled.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index ba00ecfbd343b..b41fd1240f431 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -315,12 +315,10 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
error = devm_gpio_request_one(dev, button->gpio,
flags, button->desc ? : DRV_NAME);
- if (error) {
- dev_err(dev,
- "unable to claim gpio %u, err=%d\n",
- button->gpio, error);
- return error;
- }
+ if (error)
+ return dev_err_probe(dev, error,
+ "unable to claim gpio %u\n",
+ button->gpio);
bdata->gpiod = gpio_to_desc(button->gpio);
if (!bdata->gpiod) {
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 09/12] Input: gpio_keys_polled - suppress deferred probe error for gpio
From: Sasha Levin @ 2024-03-11 18:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Uwe Kleine-König, Linus Walleij, Dmitry Torokhov,
Sasha Levin, linux-input
In-Reply-To: <20240311183727.328187-1-sashal@kernel.org>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[ Upstream commit 963465a33141d0d52338e77f80fe543d2c9dc053 ]
On a PC Engines APU our admins are faced with:
$ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517"
261
Such a message always appears when e.g. a new USB device is plugged in.
Suppress this message which considerably clutters the kernel log for
EPROBE_DEFER (i.e. -517).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240305101042.10953-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/keyboard/gpio_keys_polled.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index ba00ecfbd343b..b41fd1240f431 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -315,12 +315,10 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
error = devm_gpio_request_one(dev, button->gpio,
flags, button->desc ? : DRV_NAME);
- if (error) {
- dev_err(dev,
- "unable to claim gpio %u, err=%d\n",
- button->gpio, error);
- return error;
- }
+ if (error)
+ return dev_err_probe(dev, error,
+ "unable to claim gpio %u\n",
+ button->gpio);
bdata->gpiod = gpio_to_desc(button->gpio);
if (!bdata->gpiod) {
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.1 4/7] Input: gpio_keys_polled - suppress deferred probe error for gpio
From: Sasha Levin @ 2024-03-11 18:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Uwe Kleine-König, Linus Walleij, Dmitry Torokhov,
Sasha Levin, linux-input
In-Reply-To: <20240311183826.328535-1-sashal@kernel.org>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[ Upstream commit 963465a33141d0d52338e77f80fe543d2c9dc053 ]
On a PC Engines APU our admins are faced with:
$ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517"
261
Such a message always appears when e.g. a new USB device is plugged in.
Suppress this message which considerably clutters the kernel log for
EPROBE_DEFER (i.e. -517).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240305101042.10953-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/keyboard/gpio_keys_polled.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index c3937d2fc7446..a0f9978c68f55 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -319,12 +319,10 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
error = devm_gpio_request_one(dev, button->gpio,
flags, button->desc ? : DRV_NAME);
- if (error) {
- dev_err(dev,
- "unable to claim gpio %u, err=%d\n",
- button->gpio, error);
- return error;
- }
+ if (error)
+ return dev_err_probe(dev, error,
+ "unable to claim gpio %u\n",
+ button->gpio);
bdata->gpiod = gpio_to_desc(button->gpio);
if (!bdata->gpiod) {
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.15 2/5] Input: gpio_keys_polled - suppress deferred probe error for gpio
From: Sasha Levin @ 2024-03-11 18:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Uwe Kleine-König, Linus Walleij, Dmitry Torokhov,
Sasha Levin, linux-input
In-Reply-To: <20240311183901.328749-1-sashal@kernel.org>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[ Upstream commit 963465a33141d0d52338e77f80fe543d2c9dc053 ]
On a PC Engines APU our admins are faced with:
$ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517"
261
Such a message always appears when e.g. a new USB device is plugged in.
Suppress this message which considerably clutters the kernel log for
EPROBE_DEFER (i.e. -517).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240305101042.10953-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/keyboard/gpio_keys_polled.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index c3937d2fc7446..a0f9978c68f55 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -319,12 +319,10 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
error = devm_gpio_request_one(dev, button->gpio,
flags, button->desc ? : DRV_NAME);
- if (error) {
- dev_err(dev,
- "unable to claim gpio %u, err=%d\n",
- button->gpio, error);
- return error;
- }
+ if (error)
+ return dev_err_probe(dev, error,
+ "unable to claim gpio %u\n",
+ button->gpio);
bdata->gpiod = gpio_to_desc(button->gpio);
if (!bdata->gpiod) {
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.10 2/5] Input: gpio_keys_polled - suppress deferred probe error for gpio
From: Sasha Levin @ 2024-03-11 18:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Uwe Kleine-König, Linus Walleij, Dmitry Torokhov,
Sasha Levin, linux-input
In-Reply-To: <20240311183923.328881-1-sashal@kernel.org>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[ Upstream commit 963465a33141d0d52338e77f80fe543d2c9dc053 ]
On a PC Engines APU our admins are faced with:
$ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517"
261
Such a message always appears when e.g. a new USB device is plugged in.
Suppress this message which considerably clutters the kernel log for
EPROBE_DEFER (i.e. -517).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240305101042.10953-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/keyboard/gpio_keys_polled.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index c3937d2fc7446..a0f9978c68f55 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -319,12 +319,10 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
error = devm_gpio_request_one(dev, button->gpio,
flags, button->desc ? : DRV_NAME);
- if (error) {
- dev_err(dev,
- "unable to claim gpio %u, err=%d\n",
- button->gpio, error);
- return error;
- }
+ if (error)
+ return dev_err_probe(dev, error,
+ "unable to claim gpio %u\n",
+ button->gpio);
bdata->gpiod = gpio_to_desc(button->gpio);
if (!bdata->gpiod) {
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 2/5] Input: gpio_keys_polled - suppress deferred probe error for gpio
From: Sasha Levin @ 2024-03-11 18:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Uwe Kleine-König, Linus Walleij, Dmitry Torokhov,
Sasha Levin, linux-input
In-Reply-To: <20240311183950.329120-1-sashal@kernel.org>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[ Upstream commit 963465a33141d0d52338e77f80fe543d2c9dc053 ]
On a PC Engines APU our admins are faced with:
$ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517"
261
Such a message always appears when e.g. a new USB device is plugged in.
Suppress this message which considerably clutters the kernel log for
EPROBE_DEFER (i.e. -517).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240305101042.10953-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/keyboard/gpio_keys_polled.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index 465eecfa6b3f0..825fff00e4f88 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -325,12 +325,10 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
error = devm_gpio_request_one(dev, button->gpio,
flags, button->desc ? : DRV_NAME);
- if (error) {
- dev_err(dev,
- "unable to claim gpio %u, err=%d\n",
- button->gpio, error);
- return error;
- }
+ if (error)
+ return dev_err_probe(dev, error,
+ "unable to claim gpio %u\n",
+ button->gpio);
bdata->gpiod = gpio_to_desc(button->gpio);
if (!bdata->gpiod) {
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 2/5] Input: gpio_keys_polled - suppress deferred probe error for gpio
From: Sasha Levin @ 2024-03-11 18:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Uwe Kleine-König, Linus Walleij, Dmitry Torokhov,
Sasha Levin, linux-input
In-Reply-To: <20240311184011.329314-1-sashal@kernel.org>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[ Upstream commit 963465a33141d0d52338e77f80fe543d2c9dc053 ]
On a PC Engines APU our admins are faced with:
$ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517"
261
Such a message always appears when e.g. a new USB device is plugged in.
Suppress this message which considerably clutters the kernel log for
EPROBE_DEFER (i.e. -517).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240305101042.10953-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/keyboard/gpio_keys_polled.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index edc7262103b9a..96e47b2401490 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -328,12 +328,10 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
error = devm_gpio_request_one(dev, button->gpio,
flags, button->desc ? : DRV_NAME);
- if (error) {
- dev_err(dev,
- "unable to claim gpio %u, err=%d\n",
- button->gpio, error);
- return error;
- }
+ if (error)
+ return dev_err_probe(dev, error,
+ "unable to claim gpio %u\n",
+ button->gpio);
bdata->gpiod = gpio_to_desc(button->gpio);
if (!bdata->gpiod) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/2] map Fn + R key on newer Yogas and Legions
From: Dmitry Torokhov @ 2024-03-11 18:45 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Ike Panhc, Hans de Goede, Philipp Jungkamp, Gergo Koteles,
platform-driver-x86, LKML, linux-input
In-Reply-To: <269b8adf-426a-b614-5450-383cde095c75@linux.intel.com>
On Mon, Mar 11, 2024 at 12:53:36PM +0200, Ilpo Järvinen wrote:
> On Sat, 9 Mar 2024, Dmitry Torokhov wrote:
>
> > On Mon, Feb 26, 2024 at 03:27:33PM +0200, Ilpo Järvinen wrote:
> > > On Tue, 20 Feb 2024 04:39:34 +0100, Gergo Koteles wrote:
> > >
> > > > This patch series adds a new KEY_FN_R input event code and map the
> > > > Fn + R key to it in the ideapad-laptop driver.
> > > >
> > > > It affects two WMI keycodes and I couldn't try the 0x0a, but I couldn't
> > > > find any indication that the refresh rate toggle should not be Fn + R.
> > > >
> > > > Regards,
> > > > Gergo
> > > >
> > > > [...]
> > >
> > >
> > > Thank you for your contribution, it has been applied to my local
> > > review-ilpo branch. Note it will show up in the public
> > > platform-drivers-x86/review-ilpo branch only once I've pushed my
> > > local branch there, which might take a while.
> > >
> > > The list of commits applied:
> > > [1/2] Input: allocate keycode for Fn + R
> > > commit: 4e45fa464aeef4e803412b5dcce73aad48c94b0e
> >
> > I am sorry for the delay, but instead of defining a generic name we should define
> > a proper keycode for concrete action even if nothing is printed on a
> > particular key on a particular device.
> >
> > Please drop this patch.
>
> Dropping them at this point would bit of a hassle due to backmerges of
> fixes branch.
You should really wait applying patches affecting other parts of the
kernel as well as UAPI until all maintainers responsible for them agree
with the changes.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Add xpad support for Snakebyte GAMEPADs
From: matt.git @ 2024-03-11 22:41 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input
Support for Snakebyte GAMEPAD BASE X
Support for Snakebyte GAMEPAD RGB X
Signed-off-by: Matt Scialabba <matt.git@fastmail.fm>
---
drivers/input/joystick/xpad.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 14c828adebf7..712f79ed3259 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -366,6 +366,8 @@ static const struct xpad_device {
{ 0x24c6, 0x5d04, "Razer Sabertooth", 0, XTYPE_XBOX360 },
{ 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x2563, 0x058d, "OneXPlayer Gamepad", 0, XTYPE_XBOX360 },
+ { 0x294b, 0x3303, "Snakebyte GAMEPAD BASE X", 0, XTYPE_XBOXONE },
+ { 0x294b, 0x3404, "Snakebyte GAMEPAD RGB X", 0, XTYPE_XBOXONE },
{ 0x2dc8, 0x2000, "8BitDo Pro 2 Wired Controller fox Xbox", 0, XTYPE_XBOXONE },
{ 0x2dc8, 0x3106, "8BitDo Pro 2 Wired Controller", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 },
@@ -507,6 +509,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA controllers */
XPAD_XBOX360_VENDOR(0x2563), /* OneXPlayer Gamepad */
XPAD_XBOX360_VENDOR(0x260d), /* Dareu H101 */
+ XPAD_XBOXONE_VENDOR(0x294b), /* Snakebyte */
XPAD_XBOX360_VENDOR(0x2c22), /* Qanba Controllers */
XPAD_XBOX360_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller */
XPAD_XBOXONE_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller for Xbox */
--
2.39.2
^ permalink raw reply related
* Re: [PATCH 0/2] map Fn + R key on newer Yogas and Legions
From: Ilpo Järvinen @ 2024-03-12 11:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Ike Panhc, Hans de Goede, Philipp Jungkamp, Gergo Koteles,
platform-driver-x86, LKML, linux-input
In-Reply-To: <Ze9RU8Mbnl-w8ZUL@google.com>
[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]
On Mon, 11 Mar 2024, Dmitry Torokhov wrote:
> On Mon, Mar 11, 2024 at 12:53:36PM +0200, Ilpo Järvinen wrote:
> > On Sat, 9 Mar 2024, Dmitry Torokhov wrote:
> >
> > > On Mon, Feb 26, 2024 at 03:27:33PM +0200, Ilpo Järvinen wrote:
> > > > On Tue, 20 Feb 2024 04:39:34 +0100, Gergo Koteles wrote:
> > > >
> > > > > This patch series adds a new KEY_FN_R input event code and map the
> > > > > Fn + R key to it in the ideapad-laptop driver.
> > > > >
> > > > > It affects two WMI keycodes and I couldn't try the 0x0a, but I couldn't
> > > > > find any indication that the refresh rate toggle should not be Fn + R.
> > > > >
> > > > > Regards,
> > > > > Gergo
> > > > >
> > > > > [...]
> > > >
> > > >
> > > > Thank you for your contribution, it has been applied to my local
> > > > review-ilpo branch. Note it will show up in the public
> > > > platform-drivers-x86/review-ilpo branch only once I've pushed my
> > > > local branch there, which might take a while.
> > > >
> > > > The list of commits applied:
> > > > [1/2] Input: allocate keycode for Fn + R
> > > > commit: 4e45fa464aeef4e803412b5dcce73aad48c94b0e
> > >
> > > I am sorry for the delay, but instead of defining a generic name we should define
> > > a proper keycode for concrete action even if nothing is printed on a
> > > particular key on a particular device.
> > >
> > > Please drop this patch.
> >
> > Dropping them at this point would bit of a hassle due to backmerges of
> > fixes branch.
>
> You should really wait applying patches affecting other parts of the
> kernel as well as UAPI until all maintainers responsible for them agree
> with the changes.
>
> Thanks.
I'm sorry about that. I'll try to be more careful in the future.
I've now replaced those patches in pdx86/for-next.
--
i.
^ permalink raw reply
* Re: [PATCH v2 0/2] map Fn + R key on newer Lenovo Yogas and Legions
From: Ilpo Järvinen @ 2024-03-12 11:01 UTC (permalink / raw)
To: Gergo Koteles
Cc: Ike Panhc, Hans de Goede, Dmitry Torokhov, platform-driver-x86,
LKML, linux-input
In-Reply-To: <f77afd46-a238-630e-e77f-2c2506097554@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
On Mon, 11 Mar 2024, Ilpo Järvinen wrote:
> On Sun, 10 Mar 2024, Gergo Koteles wrote:
>
> > This patch series adds a new KEY_REFRESH_RATE_TOGGLE input event code
> > and maps the Fn + R key to it in the ideapad-laptop driver.
> >
> > It affects two WMI keycodes. I couldn't try the 0x0a.
> >
> > Regards,
> > Gergo
> >
> > Changes in v2:
> > - use KEY_REFRESH_RATE_TOGGLE instead of KEY_FN_R
> >
> > [1]: https://lore.kernel.org/all/cover.1708399689.git.soyer@irl.hu/
> >
> > Gergo Koteles (2):
> > Input: allocate keycode for Display refresh rate toggle
> > platform/x86: ideapad-laptop: map Fn + R key to
> > KEY_REFRESH_RATE_TOGGLE
>
> As mentioned in the other thread, please redo this on top of
> pdx86/for-next.
Nevermind, I replaced the original patches with these two.
--
i.
^ permalink raw reply
* Re: Regression with Lenovo ThinkPad Compact USB Keyboard
From: Raphaël Halimi @ 2024-03-12 11:56 UTC (permalink / raw)
To: Mikhail Khvoinitsky
Cc: Linux regressions mailing list, Jiri Kosina,
Linux Input Mailing List, Dmitry Torokhov, Benjamin Tissoires,
Linux Stable Mailing List
In-Reply-To: <0d2b0c46-4d84-4279-8964-589d77435e6a@gmail.com>
Le 04/03/2024 à 17:09, Raphaël Halimi a écrit :
> Thanks, it's done. I'll test and report.
Nearly a week testing this patch (with kernels 6.6.15, 6.7.7 and 6.7.9,
following Debian unstable updates) and it's working well so far.
Not a single spurious middle-click, which is not surprising since, if I
understand correctly, this last patch just disables 46a0a2c and makes it
optional, allowing to enable it on demand with a setting in sysfs.
And I have vertical and horizontal scrolling with the middle button
working reliably (I'm not sure of what you mean by "hi-res scrolling",
is it about 4K displays ?).
So as far as I'm concerned, this patch should be included ASAP in the
next kernels releases (both latest and stable).
Regards,
--
Raphaël Halimi
^ permalink raw reply
* Re: Regression with Lenovo ThinkPad Compact USB Keyboard
From: Mikhail Khvoinitsky @ 2024-03-12 13:05 UTC (permalink / raw)
To: Raphaël Halimi
Cc: Linux regressions mailing list, Jiri Kosina,
Linux Input Mailing List, Dmitry Torokhov, Benjamin Tissoires,
Linux Stable Mailing List
In-Reply-To: <9a55659c-86a6-4d9a-ab4f-94fbfb72e7c4@gmail.com>
> Not a single spurious middle-click, which is not surprising since, if I
> understand correctly, this last patch just disables 46a0a2c and makes it
> optional, allowing to enable it on demand with a setting in sysfs.
That's correct.
> And I have vertical and horizontal scrolling with the middle button
> working reliably
If you mean my statement in the initial commit that the original
firmware doesn't support horizontal scrolling, I might be wrong, looks
like I've mixed it up with something. But the main reason for the
change was hi-res scrolling.
> (I'm not sure of what you mean by "hi-res scrolling",
> is it about 4K displays ?).
No, it's about scrolling not by a fixed amount of lines but by
individual pixels depending on how strongly you press the trackpoint.
More like modern touchpads work.
> So as far as I'm concerned, this patch should be included ASAP in the
> next kernels releases (both latest and stable).
Yes, as soon as it gets into master (given that 6.8 has just been
released it will be soon), I'll make sure it will be included in
stable (either automatically or manually).
On Tue, 12 Mar 2024 at 13:57, Raphaël Halimi <raphael.halimi@gmail.com> wrote:
>
> Le 04/03/2024 à 17:09, Raphaël Halimi a écrit :
> > Thanks, it's done. I'll test and report.
>
> Nearly a week testing this patch (with kernels 6.6.15, 6.7.7 and 6.7.9,
> following Debian unstable updates) and it's working well so far.
>
> Not a single spurious middle-click, which is not surprising since, if I
> understand correctly, this last patch just disables 46a0a2c and makes it
> optional, allowing to enable it on demand with a setting in sysfs.
>
> And I have vertical and horizontal scrolling with the middle button
> working reliably (I'm not sure of what you mean by "hi-res scrolling",
> is it about 4K displays ?).
>
> So as far as I'm concerned, this patch should be included ASAP in the
> next kernels releases (both latest and stable).
>
> Regards,
>
> --
> Raphaël Halimi
^ permalink raw reply
* Re: Regression with Lenovo ThinkPad Compact USB Keyboard
From: Raphaël Halimi @ 2024-03-12 13:12 UTC (permalink / raw)
To: Mikhail Khvoinitsky
Cc: Linux regressions mailing list, Jiri Kosina,
Linux Input Mailing List, Dmitry Torokhov, Benjamin Tissoires,
Linux Stable Mailing List
In-Reply-To: <CAMMabwMDvumbNOvFk3mdqXfprO_xy4gB5R0KangvzJatv8BhUw@mail.gmail.com>
Le 12/03/2024 à 14:05, Mikhail Khvoinitsky a écrit :
>> (I'm not sure of what you mean by "hi-res scrolling",
>> is it about 4K displays ?).
>
> No, it's about scrolling not by a fixed amount of lines but by
> individual pixels depending on how strongly you press the trackpoint.
> More like modern touchpads work.
I didn't even know that the TrackPoint was pressure-sensitive :) I
quickly tested this (not with scrolling, only cursor movement) and
indeed, if I apply stronger pressure, the cursor moves faster. I never
noticed that. We learn something everyday.
>> So as far as I'm concerned, this patch should be included ASAP in the
>> next kernels releases (both latest and stable).
>
> Yes, as soon as it gets into master (given that 6.8 has just been
> released it will be soon), I'll make sure it will be included in
> stable (either automatically or manually).
Perfect. Thank you for your work !
Regards,
--
Raphaël Halimi
^ permalink raw reply
* INVESTMENT PROPOSAL
From: Howard @ 2024-03-12 16:16 UTC (permalink / raw)
To: linux-input
Good day,
Our investors are exploring all possibilities to initiate change
on a massive scale of investment opportunities, We offer
personal, business, loans at a fixed interest rate of 2% per
annum.
Regards
Howard Ethan
Financial Advisor
^ permalink raw reply
* [PATCH] dt-bindings: input: samsung,s3c6410-keypad: convert to DT Schema
From: Krzysztof Kozlowski @ 2024-03-12 18:30 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Convert Samsung SoC Keypad bindings to DT schema with changes:
1. Rename "linux,keypad-no-autorepeat" property to
"linux,input-no-autorepeat", because the latter was implemented in
the Linux driver.
2. Add clocks and clock-names, already used by DTS and the Linux driver.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../input/samsung,s3c6410-keypad.yaml | 121 ++++++++++++++++++
.../bindings/input/samsung-keypad.txt | 77 -----------
.../bindings/power/wakeup-source.txt | 2 +-
3 files changed, 122 insertions(+), 78 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml
delete mode 100644 Documentation/devicetree/bindings/input/samsung-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml b/Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml
new file mode 100644
index 000000000000..a53569aa0ee7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/samsung,s3c6410-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SoC series Keypad Controller
+
+description:
+ Samsung SoC Keypad controller is used to interface a SoC with a matrix-type
+ keypad device. The keypad controller supports multiple row and column lines.
+ A key can be placed at each intersection of a unique row and a unique column.
+ The keypad controller can sense a key-press and key-release and report the
+ event using a interrupt to the cpu.
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - samsung,s3c6410-keypad
+ - samsung,s5pv210-keypad
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: keypad
+
+ interrupts:
+ maxItems: 1
+
+ wakeup-source: true
+
+ linux,input-no-autorepeat:
+ type: boolean
+ description:
+ Do no enable autorepeat feature.
+
+ linux,input-wakeup:
+ type: boolean
+ deprecated: true
+
+ samsung,keypad-num-columns:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of column lines connected to the keypad controller.
+
+ samsung,keypad-num-rows:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of row lines connected to the keypad controller.
+
+patternProperties:
+ '^key-[0-9a-z]+$':
+ type: object
+ $ref: input.yaml#
+ additionalProperties: false
+ description:
+ Each key connected to the keypad controller is represented as a child
+ node to the keypad controller device node.
+
+ properties:
+ keypad,column:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The column number to which the key is connected.
+
+ keypad,row:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The row number to which the key is connected.
+
+ linux,code: true
+
+ required:
+ - keypad,column
+ - keypad,row
+ - linux,code
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - samsung,keypad-num-columns
+ - samsung,keypad-num-rows
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos4.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ keypad@100a0000 {
+ compatible = "samsung,s5pv210-keypad";
+ reg = <0x100a0000 0x100>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock CLK_KEYIF>;
+ clock-names = "keypad";
+
+ samsung,keypad-num-rows = <2>;
+ samsung,keypad-num-columns = <8>;
+ linux,input-no-autorepeat;
+ wakeup-source;
+
+ key-1 {
+ keypad,row = <0>;
+ keypad,column = <3>;
+ linux,code = <2>;
+ };
+
+ key-2 {
+ keypad,row = <0>;
+ keypad,column = <4>;
+ linux,code = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt b/Documentation/devicetree/bindings/input/samsung-keypad.txt
deleted file mode 100644
index 4c5c0a82586d..000000000000
--- a/Documentation/devicetree/bindings/input/samsung-keypad.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-* Samsung's Keypad Controller device tree bindings
-
-Samsung's Keypad controller is used to interface a SoC with a matrix-type
-keypad device. The keypad controller supports multiple row and column lines.
-A key can be placed at each intersection of a unique row and a unique column.
-The keypad controller can sense a key-press and key-release and report the
-event using a interrupt to the cpu.
-
-Required SoC Specific Properties:
-- compatible: should be one of the following
- - "samsung,s3c6410-keypad": For controllers compatible with s3c6410 keypad
- controller.
- - "samsung,s5pv210-keypad": For controllers compatible with s5pv210 keypad
- controller.
-
-- reg: physical base address of the controller and length of memory mapped
- region.
-
-- interrupts: The interrupt number to the cpu.
-
-Required Board Specific Properties:
-- samsung,keypad-num-rows: Number of row lines connected to the keypad
- controller.
-
-- samsung,keypad-num-columns: Number of column lines connected to the
- keypad controller.
-
-- Keys represented as child nodes: Each key connected to the keypad
- controller is represented as a child node to the keypad controller
- device node and should include the following properties.
- - keypad,row: the row number to which the key is connected.
- - keypad,column: the column number to which the key is connected.
- - linux,code: the key-code to be reported when the key is pressed
- and released.
-
-- pinctrl-0: Should specify pin control groups used for this controller.
-- pinctrl-names: Should contain only one value - "default".
-
-Optional Properties:
-- wakeup-source: use any event on keypad as wakeup event.
- (Legacy property supported: "linux,input-wakeup")
-
-Optional Properties specific to linux:
-- linux,keypad-no-autorepeat: do no enable autorepeat feature.
-
-
-Example:
- keypad@100a0000 {
- compatible = "samsung,s5pv210-keypad";
- reg = <0x100A0000 0x100>;
- interrupts = <173>;
- samsung,keypad-num-rows = <2>;
- samsung,keypad-num-columns = <8>;
- linux,input-no-autorepeat;
- wakeup-source;
-
- pinctrl-names = "default";
- pinctrl-0 = <&keypad_rows &keypad_columns>;
-
- key_1 {
- keypad,row = <0>;
- keypad,column = <3>;
- linux,code = <2>;
- };
-
- key_2 {
- keypad,row = <0>;
- keypad,column = <4>;
- linux,code = <3>;
- };
-
- key_3 {
- keypad,row = <0>;
- keypad,column = <5>;
- linux,code = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/power/wakeup-source.txt b/Documentation/devicetree/bindings/power/wakeup-source.txt
index 75bc20b95688..a6c8978964aa 100644
--- a/Documentation/devicetree/bindings/power/wakeup-source.txt
+++ b/Documentation/devicetree/bindings/power/wakeup-source.txt
@@ -27,7 +27,7 @@ List of legacy properties and respective binding document
Documentation/devicetree/bindings/mfd/tc3589x.txt
Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
4. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
-5. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt
+5. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml
6. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
Examples
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 00/10] backlight: Replace struct fb_info in interfaces
From: Uwe Kleine-König @ 2024-03-13 6:48 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, andy, daniel.thompson, jingoohan1, deller, robin, javierm,
dri-devel, linux-fbdev, linux-input, linux-pwm
In-Reply-To: <20240305162425.23845-1-tzimmermann@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]
Hello Thomas,
On Tue, Mar 05, 2024 at 05:22:33PM +0100, Thomas Zimmermann wrote:
> Backlight drivers implement struct backlight_ops.check_fb, which
> uses struct fb_info in its interface. Replace the callback with one
> that does not use fb_info.
>
> In DRM, we have several drivers that implement backlight support. By
> including <linux/backlight.h> these drivers depend on <linux/fb.h>.
> At the same time, fbdev is deprecated for new drivers and likely to
> be replaced on many systems.
>
> This patchset is part of a larger effort to implement the backlight
> code without depending on fbdev.
>
> Patch 1 makes the backlight core match backlight and framebuffer
> devices via struct fb_info.bl_dev. Patches 2 to 9 then go through
> drivers and remove unnecessary implementations of check_fb. Finally,
> patch 10 replaces the check_fb hook with controls_device, which
> uses the framebuffer's Linux device instead of the framebuffer.
I assume the merge plan for this series is via drm-misc in one go?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 00/10] backlight: Replace struct fb_info in interfaces
From: Lee Jones @ 2024-03-13 8:03 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Thomas Zimmermann, andy, daniel.thompson, jingoohan1, deller,
robin, javierm, dri-devel, linux-fbdev, linux-input, linux-pwm
In-Reply-To: <heasef3pdfyj7xyngnvbg527pc5uyy2v6hatz4wr6q3sfkhw3h@f4lnresjcnmb>
On Wed, 13 Mar 2024, Uwe Kleine-König wrote:
> Hello Thomas,
>
> On Tue, Mar 05, 2024 at 05:22:33PM +0100, Thomas Zimmermann wrote:
> > Backlight drivers implement struct backlight_ops.check_fb, which
> > uses struct fb_info in its interface. Replace the callback with one
> > that does not use fb_info.
> >
> > In DRM, we have several drivers that implement backlight support. By
> > including <linux/backlight.h> these drivers depend on <linux/fb.h>.
> > At the same time, fbdev is deprecated for new drivers and likely to
> > be replaced on many systems.
> >
> > This patchset is part of a larger effort to implement the backlight
> > code without depending on fbdev.
> >
> > Patch 1 makes the backlight core match backlight and framebuffer
> > devices via struct fb_info.bl_dev. Patches 2 to 9 then go through
> > drivers and remove unnecessary implementations of check_fb. Finally,
> > patch 10 replaces the check_fb hook with controls_device, which
> > uses the framebuffer's Linux device instead of the framebuffer.
>
> I assume the merge plan for this series is via drm-misc in one go?
Backlight in one go. This will be the second attempt at applying it.
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH] input: ioc3kbd: add device table
From: Karel Balej @ 2024-03-13 11:53 UTC (permalink / raw)
To: Dmitry Torokhov, Thomas Bogendoerfer, linux-input, linux-kernel
Cc: stable, balejk
Without the device table the driver will not auto-load when compiled as
a module.
Fixes: 273db8f03509 ("Input: add IOC3 serio driver")
Cc: stable@vger.kernel.org
Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
I do not own any device using this driver, but I verified that modinfo
does not show the "platform:ioc3-kbd" alias when run on the module
compiled without this patch and it does with it.
drivers/input/serio/ioc3kbd.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/serio/ioc3kbd.c b/drivers/input/serio/ioc3kbd.c
index 50552dc7b4f5..676b0bda3d72 100644
--- a/drivers/input/serio/ioc3kbd.c
+++ b/drivers/input/serio/ioc3kbd.c
@@ -200,9 +200,16 @@ static void ioc3kbd_remove(struct platform_device *pdev)
serio_unregister_port(d->aux);
}
+static const struct platform_device_id ioc3kbd_id_table[] = {
+ { "ioc3-kbd", },
+ { }
+};
+MODULE_DEVICE_TABLE(platform, ioc3kbd_id_table);
+
static struct platform_driver ioc3kbd_driver = {
.probe = ioc3kbd_probe,
.remove_new = ioc3kbd_remove,
+ .id_table = ioc3kbd_id_table,
.driver = {
.name = "ioc3-kbd",
},
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v9 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: Marco Felsch @ 2024-03-13 20:21 UTC (permalink / raw)
To: Kamel Bouhara
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Jeff LaBundy, catalin.popescu, mark.satterthwaite,
Thomas Petazzoni, Gregory Clement, bsp-development.geo
In-Reply-To: <20240301103909.167923-4-kamel.bouhara@bootlin.com>
Hi Kamel,
please see below, be aware that this is just an rough review.
On 24-03-01, Kamel Bouhara wrote:
> Add a new driver for the TouchNetix's axiom family of
> touchscreen controllers. This driver only supports i2c
> and can be later adapted for SPI and USB support.
>
> Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
> ---
> MAINTAINERS | 1 +
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/touchnetix_axiom.c | 669 +++++++++++++++++++
> 4 files changed, 683 insertions(+)
> create mode 100644 drivers/input/touchscreen/touchnetix_axiom.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4b3ed2f22b89..de5fad8f317a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -22262,6 +22262,7 @@ M: Kamel Bouhara <kamel.bouhara@bootlin.com>
> L: linux-input@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
> +F: drivers/input/touchscreen/touchnetix_axiom.c
>
> TPM DEVICE DRIVER
> M: Peter Huewe <peterhuewe@gmx.de>
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index e3e2324547b9..f36bee8d8696 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -803,6 +803,18 @@ config TOUCHSCREEN_MIGOR
> To compile this driver as a module, choose M here: the
> module will be called migor_ts.
>
> +config TOUCHSCREEN_TOUCHNETIX_AXIOM
> + tristate "TouchNetix AXIOM based touchscreen controllers"
> + depends on I2C
> + help
> + Say Y here if you have a axiom touchscreen connected to
> + your system.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called axiom.
> +
> config TOUCHSCREEN_TOUCHRIGHT
> tristate "Touchright serial touchscreen"
> select SERIO
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index 62bd24f3ac8e..8e32a2df5e18 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -88,6 +88,7 @@ obj-$(CONFIG_TOUCHSCREEN_SUR40) += sur40.o
> obj-$(CONFIG_TOUCHSCREEN_SURFACE3_SPI) += surface3_spi.o
> obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC) += ti_am335x_tsc.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
> +obj-$(CONFIG_TOUCHSCREEN_TOUCHNETIX_AXIOM) += touchnetix_axiom.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
> obj-$(CONFIG_TOUCHSCREEN_TS4800) += ts4800-ts.o
> diff --git a/drivers/input/touchscreen/touchnetix_axiom.c b/drivers/input/touchscreen/touchnetix_axiom.c
> new file mode 100644
> index 000000000000..e7abba41eed0
> --- /dev/null
> +++ b/drivers/input/touchscreen/touchnetix_axiom.c
> @@ -0,0 +1,669 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * TouchNetix axiom Touchscreen Driver
> + *
> + * Copyright (C) 2020-2023 TouchNetix Ltd.
> + *
> + * Author(s): Bart Prescott <bartp@baasheep.co.uk>
> + * Pedro Torruella <pedro.torruella@touchnetix.com>
> + * Mark Satterthwaite <mark.satterthwaite@touchnetix.com>
> + * Hannah Rossiter <hannah.rossiter@touchnetix.com>
> + * Kamel Bouhara <kamel.bouhara@bootlin.com>
> + *
> + */
> +#include <linux/bitfield.h>
> +#include <linux/crc16.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/input.h>
> +#include <linux/input/mt.h>
> +#include <linux/input/touchscreen.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/regmap.h>
> +
> +#include <asm/unaligned.h>
> +#define AXIOM_PROX_LEVEL -128
> +#define AXIOM_DMA_OPS_DELAY_USEC 250
> +#define AXIOM_STARTUP_TIME_MS 110
> +/*
> + * Register group u31 has 2 pages for usage table entries.
> + */
> +#define AXIOM_U31_MAX_USAGES 0xff
> +#define AXIOM_U31_BYTES_PER_USAGE 6
> +#define AXIOM_U31_PAGE0_LENGTH 0x0C
> +#define AXIOM_U31_BOOTMODE_MASK BIT(7)
> +#define AXIOM_U31_DEVID_MASK GENMASK(14, 0)
> +
> +#define AXIOM_MAX_REPORT_LEN 0x7f
> +
> +#define AXIOM_CMD_HEADER_READ_MASK BIT(15)
> +#define AXIOM_U41_MAX_TARGETS 10
> +
> +#define AXIOM_U46_AUX_CHANNELS 4
> +#define AXIOM_U46_AUX_MASK GENMASK(11, 0)
> +
> +#define AXIOM_COMMS_MAX_USAGE_PAGES 3
> +#define AXIOM_COMMS_PAGE_SIZE 256
> +#define AXIOM_COMMS_REPORT_LEN_MASK GENMASK(6, 0)
> +
> +#define AXIOM_REPORT_USAGE_ID 0x34
> +#define AXIOM_DEVINFO_USAGE_ID 0x31
> +#define AXIOM_USAGE_2HB_REPORT_ID 0x01
> +#define AXIOM_USAGE_2AUX_REPORT_ID 0x46
> +#define AXIOM_USAGE_2DCTS_REPORT_ID 0x41
> +
> +#define AXIOM_PAGE_OFFSET_MASK GENMASK(6, 0)
> +
> +struct axiom_devinfo {
> + __le16 device_id;
> + u8 fw_minor;
> + u8 fw_major;
> + u8 fw_info_extra;
> + u8 tcp_revision;
> + u8 bootloader_fw_minor;
> + u8 bootloader_fw_major;
> + __le16 jedec_id;
> + u8 num_usages;
> +} __packed;
> +
> +/*
> + * Describes parameters of a specific usage, essentially a single element of
> + * the "Usage Table"
> + */
> +struct axiom_usage_entry {
> + u8 id;
> + u8 is_report;
> + u8 start_page;
> + u8 num_pages;
> +};
> +
> +/*
> + * Represents state of a touch or target when detected prior to a touch (eg.
> + * hover or proximity events).
> + */
> +enum axiom_target_state {
> + AXIOM_TARGET_STATE_NOT_PRESENT = 0,
> + AXIOM_TARGET_STATE_PROX = 1,
> + AXIOM_TARGET_STATE_HOVER = 2,
> + AXIOM_TARGET_STATE_TOUCHING = 3,
> +};
> +
> +struct axiom_u41_target {
> + enum axiom_target_state state;
> + u16 x;
> + u16 y;
> + s8 z;
> + bool insert;
> + bool touch;
> +};
> +
> +struct axiom_target_report {
> + u8 index;
> + u8 present;
> + u16 x;
> + u16 y;
> + s8 z;
> +};
> +
> +struct axiom_cmd_header {
> + __le16 target_address;
> + __le16 length;
> +} __packed;
> +
> +struct axiom_data {
> + struct axiom_devinfo devinfo;
> + struct device *dev;
> + struct gpio_desc *reset_gpio;
> + struct i2c_client *client;
> + struct input_dev *input_dev;
> + u32 max_report_len;
> + u8 rx_buf[AXIOM_COMMS_MAX_USAGE_PAGES * AXIOM_COMMS_PAGE_SIZE];
> + struct axiom_u41_target targets[AXIOM_U41_MAX_TARGETS];
> + struct axiom_usage_entry usage_table[AXIOM_U31_MAX_USAGES];
> + bool usage_table_populated;
> + struct regulator *vdda;
> + struct regulator *vddi;
> + struct regmap *regmap;
> + struct touchscreen_properties prop;
> +};
> +
> +static const struct regmap_config axiom_i2c_regmap_config = {
> + .reg_bits = 32,
> + .reg_format_endian = REGMAP_ENDIAN_LITTLE,
> + .val_bits = 8,
> + .val_format_endian = REGMAP_ENDIAN_LITTLE,
> +};
> +
> +/*
> + * axiom devices are typically configured to report touches at a rate
> + * of 100Hz (10ms) for systems that require polling for reports.
> + * When reports are polled, it will be expected to occasionally
> + * observe the overflow bit being set in the reports.
> + * This indicates that reports are not being read fast enough.
> + */
> +#define POLL_INTERVAL_DEFAULT_MS 10
> +
> +/* Translate usage/page/offset triplet into physical address. */
> +static u16 axiom_usage_to_target_address(struct axiom_data *ts, u8 usage, u8 page,
> + char offset)
> +{
> + /* At the moment the convention is that u31 is always at physical address 0x0 */
> + if (!ts->usage_table_populated) {
> + if (usage == AXIOM_DEVINFO_USAGE_ID)
> + return ((page << 8) + offset);
> + else
> + return 0xffff;
> + }
> +
> + if (page >= ts->usage_table[usage].num_pages) {
> + dev_err(ts->dev, "Invalid usage table! usage: u%02x, page: %02x, offset: %02x\n",
> + usage, page, offset);
> + return 0xffff;
> + }
> +
> + return ((ts->usage_table[usage].start_page + page) << 8) + offset;
> +}
> +
> +static int axiom_read(struct axiom_data *ts, u8 usage, u8 page, void *buf, u16 len)
> +{
> + struct axiom_cmd_header cmd_header;
> + u32 preamble;
> + int ret;
> +
> + cmd_header.target_address = cpu_to_le16(axiom_usage_to_target_address(ts, usage, page, 0));
> + cmd_header.length = cpu_to_le16(len | AXIOM_CMD_HEADER_READ_MASK);
> +
> + preamble = get_unaligned_le32(&cmd_header);
> +
> + ret = regmap_write(ts->regmap, preamble, 0);
> + if (ret) {
> + dev_err(ts->dev, "failed to write preamble, error %d\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_raw_read(ts->regmap, 0, buf, len);
> + if (ret) {
> + dev_err(ts->dev, "failed to read target address %04x, error %d\n",
> + cmd_header.target_address, ret);
> + return ret;
> + }
> +
> + /* Wait device's DMA operations */
> + usleep_range(AXIOM_DMA_OPS_DELAY_USEC, AXIOM_DMA_OPS_DELAY_USEC + 50);
> +
> + return 0;
> +}
> +
> +/*
> + * One of the main purposes for reading the usage table is to identify
> + * which usages reside at which target address.
> + * When performing subsequent reads or writes to AXIOM, the target address
> + * is used to specify which usage is being accessed.
> + * Consider the following discovery code which will build up the usage table.
> + */
> +static u32 axiom_populate_usage_table(struct axiom_data *ts)
> +{
> + struct axiom_usage_entry *usage_table;
> + u8 *rx_data = ts->rx_buf;
> + u32 max_report_len = 0;
> + u32 usage_id;
> + int error;
> +
> + usage_table = ts->usage_table;
> +
> + /* Read the second page of usage u31 to get the usage table */
> + error = axiom_read(ts, AXIOM_DEVINFO_USAGE_ID, 1, rx_data,
> + (AXIOM_U31_BYTES_PER_USAGE * ts->devinfo.num_usages));
> +
> + if (error)
> + return error;
> +
> + for (usage_id = 0; usage_id < ts->devinfo.num_usages; usage_id++) {
> + u16 offset = (usage_id * AXIOM_U31_BYTES_PER_USAGE);
> + u8 id = rx_data[offset + 0];
> + u8 start_page = rx_data[offset + 1];
> + u8 num_pages = rx_data[offset + 2];
> + u32 max_offset = ((rx_data[offset + 3] & AXIOM_PAGE_OFFSET_MASK) + 1) * 2;
> +
> + usage_table[id].is_report = !num_pages;
> +
> + /* Store the entry into the usage table */
> + usage_table[id].id = id;
> + usage_table[id].start_page = start_page;
> + usage_table[id].num_pages = num_pages;
> +
> + dev_dbg(ts->dev, "Usage u%02x Info: %*ph\n", id, AXIOM_U31_BYTES_PER_USAGE,
> + &rx_data[offset]);
> +
> + /* Identify the max report length the module will receive */
> + if (usage_table[id].is_report && max_offset > max_report_len)
> + max_report_len = max_offset;
> + }
> +
> + ts->usage_table_populated = true;
> +
> + return max_report_len;
> +}
> +
> +static int axiom_discover(struct axiom_data *ts)
> +{
> + int error;
> +
> + /*
> + * Fetch the first page of usage u31 to get the
> + * device information and the number of usages
> + */
> + error = axiom_read(ts, AXIOM_DEVINFO_USAGE_ID, 0, &ts->devinfo, AXIOM_U31_PAGE0_LENGTH);
> + if (error)
> + return error;
> +
> + dev_dbg(ts->dev, " Boot Mode : %s\n",
> + FIELD_GET(AXIOM_U31_BOOTMODE_MASK,
> + le16_to_cpu(ts->devinfo.device_id)) ? "BLP" : "TCP");
> + dev_dbg(ts->dev, " Device ID : %04lx\n",
> + FIELD_GET(AXIOM_U31_DEVID_MASK, le16_to_cpu(ts->devinfo.device_id)));
> + dev_dbg(ts->dev, " Firmware Rev : %02x.%02x\n", ts->devinfo.fw_major,
> + ts->devinfo.fw_minor);
> + dev_dbg(ts->dev, " Bootloader Rev : %02x.%02x\n", ts->devinfo.bootloader_fw_major,
> + ts->devinfo.bootloader_fw_minor);
> + dev_dbg(ts->dev, " FW Extra Info : %04x\n", ts->devinfo.fw_info_extra);
> + dev_dbg(ts->dev, " Silicon : %04x\n", le16_to_cpu(ts->devinfo.jedec_id));
> + dev_dbg(ts->dev, " Number usages : %04x\n", ts->devinfo.num_usages);
> +
> + ts->max_report_len = axiom_populate_usage_table(ts);
> + if (!ts->max_report_len || !ts->devinfo.num_usages ||
> + ts->max_report_len > AXIOM_MAX_REPORT_LEN) {
> + dev_err(ts->dev, "Invalid report length or usages number");
> + return -EINVAL;
> + }
> +
> + dev_dbg(ts->dev, "Max Report Length: %u\n", ts->max_report_len);
> +
> + return 0;
> +}
> +
> +/*
> + * Support function to axiom_process_u41_report.
> + * Generates input-subsystem events for every target.
> + * After calling this function the caller shall issue
> + * a Sync to the input sub-system.
> + */
> +static bool axiom_process_u41_report_target(struct axiom_data *ts,
> + struct axiom_target_report *target)
> +{
> + struct input_dev *input_dev = ts->input_dev;
> + struct axiom_u41_target *target_prev_state;
> + enum axiom_target_state current_state;
> + int id;
> +
> + /* Verify the target index */
> + if (target->index >= AXIOM_U41_MAX_TARGETS) {
> + dev_err(ts->dev, "Invalid target index! %u\n", target->index);
> + return false;
> + }
> +
> + target_prev_state = &ts->targets[target->index];
> +
> + current_state = AXIOM_TARGET_STATE_NOT_PRESENT;
> +
> + if (target->present) {
> + if (target->z >= 0)
> + current_state = AXIOM_TARGET_STATE_TOUCHING;
> + else if (target->z > AXIOM_PROX_LEVEL && target->z < 0)
> + current_state = AXIOM_TARGET_STATE_HOVER;
> + else if (target->z == AXIOM_PROX_LEVEL)
> + current_state = AXIOM_TARGET_STATE_PROX;
> + }
> +
> + if (target_prev_state->state == current_state &&
> + target_prev_state->x == target->x &&
> + target_prev_state->y == target->y &&
> + target_prev_state->z == target->z)
> + return false;
> +
> + id = target->index;
> +
> + dev_dbg(ts->dev, "U41 Target T%u, present:%u, x:%u, y:%u, z:%d\n",
> + target->index, target->present,
> + target->x, target->y, target->z);
> +
> + switch (current_state) {
> + case AXIOM_TARGET_STATE_NOT_PRESENT:
> + case AXIOM_TARGET_STATE_PROX:
> + if (!target_prev_state->insert)
> + break;
> + target_prev_state->insert = false;
> +
> + if (!id)
> + input_report_key(input_dev, BTN_TOUCH, 0);
> +
> + input_mt_report_slot_inactive(input_dev);
> + /*
> + * make sure the previous coordinates are
> + * all off screen when the finger comes back
> + */
> + target->x = 65535;
> + target->y = 65535;
> + target->z = AXIOM_PROX_LEVEL;
> + break;
> + case AXIOM_TARGET_STATE_HOVER:
> + case AXIOM_TARGET_STATE_TOUCHING:
> + target_prev_state->insert = true;
> + input_report_abs(input_dev, ABS_MT_TRACKING_ID, id);
> + input_report_abs(input_dev, ABS_MT_POSITION_X, target->x);
> + input_report_abs(input_dev, ABS_MT_POSITION_Y, target->y);
> +
> + if (current_state == AXIOM_TARGET_STATE_TOUCHING) {
> + input_report_abs(input_dev, ABS_MT_DISTANCE, 0);
> + input_report_abs(input_dev, ABS_DISTANCE, 0);
> + input_report_abs(input_dev, ABS_MT_PRESSURE, target->z);
> + input_report_abs(input_dev, ABS_PRESSURE, target->z);
> + } else {
> + input_report_abs(input_dev, ABS_MT_DISTANCE, -target->z);
> + input_report_abs(input_dev, ABS_DISTANCE, -target->z);
> + input_report_abs(input_dev, ABS_MT_PRESSURE, 0);
> + input_report_abs(input_dev, ABS_PRESSURE, 0);
> + }
> +
> + if (!id)
> + input_report_key(input_dev, BTN_TOUCH, (current_state ==
> + AXIOM_TARGET_STATE_TOUCHING));
> + break;
> + default:
> + break;
> + }
> +
> + target_prev_state->state = current_state;
> + target_prev_state->x = target->x;
> + target_prev_state->y = target->y;
> + target_prev_state->z = target->z;
> +
> + return true;
> +}
> +
> +/*
> + * U41 is the output report of the 2D CTS and contains the status of targets
> + * (including contacts and pre-contacts) along with their X,Y,Z values.
> + * When a target has been removed (no longer detected),
> + * the corresponding X,Y,Z values will be zeroed.
> + */
> +static bool axiom_process_u41_report(struct axiom_data *ts, u8 *rx_buf)
> +{
> + struct axiom_target_report target;
> + bool update_done = false;
> + u16 target_status;
> + int i;
> +
> + target_status = get_unaligned_le16(rx_buf + 1);
> +
> + for (i = 0; i < AXIOM_U41_MAX_TARGETS; i++) {
> + u8 *target_step = &rx_buf[i * 4];
> +
> + target.index = i;
> + input_mt_slot(ts->input_dev, i);
> + input_mt_report_slot_state(ts->input_dev, MT_TOOL_FINGER, true);
> + target.present = ((target_status & (1 << i)) != 0) ? 1 : 0;
> + target.x = get_unaligned_le16(target_step + 3);
> + target.y = get_unaligned_le16(target_step + 5);
> + target.z = (s8)(rx_buf[i + 43]);
> + touchscreen_report_pos(ts->input_dev, &ts->prop, target.x, target.y, true);
> + update_done |= axiom_process_u41_report_target(ts, &target);
> + }
> +
> + return update_done;
> +}
> +
> +/*
> + * U46 report contains a low level measurement data generated by the capacitive
> + * displacement sensor (CDS) algorithms from the auxiliary channels.
> + * This information is useful when tuning multi-press to assess mechanical
> + * consistency in the unit's construction.
> + */
> +static void axiom_process_u46_report(struct axiom_data *ts, u8 *rx_buf)
> +{
> + struct input_dev *input_dev = ts->input_dev;
> + u32 event_value;
> + u16 aux_value;
> + int i;
> +
> + for (i = 0; i < AXIOM_U46_AUX_CHANNELS; i++) {
> + u8 *target_step = &rx_buf[i * 2];
> +
> + input_mt_slot(input_dev, i);
> + input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, true);
> + aux_value = get_unaligned_le16(target_step + 1) & AXIOM_U46_AUX_MASK;
> + event_value = (i << 16) | (aux_value);
> + input_event(input_dev, EV_MSC, MSC_RAW, event_value);
> + }
> +}
> +
> +/*
> + * Validates the crc and demultiplexes the axiom reports to the appropriate
> + * report handler
> + */
> +static int axiom_handle_events(struct axiom_data *ts)
> +{
> + struct input_dev *input_dev = ts->input_dev;
> + u8 *report_data = ts->rx_buf;
> + struct device *dev = ts->dev;
> + u16 crc_report;
> + u8 *crc_bytes;
> + u16 crc_calc;
> + int error;
> + u8 len;
> +
> + error = axiom_read(ts, AXIOM_REPORT_USAGE_ID, 0, report_data, ts->max_report_len);
> + if (error)
> + return error;
> +
> + len = (report_data[0] & AXIOM_COMMS_REPORT_LEN_MASK) << 1;
> + if (len <= 2) {
> + dev_err(dev, "Zero length report discarded.\n");
> + return -ENODATA;
> + }
> +
> + /* Validate the report CRC */
> + crc_bytes = &report_data[len];
> +
> + crc_report = get_unaligned_le16(crc_bytes - 2);
> + /* Length is in 16 bit words and remove the size of the CRC16 itself */
> + crc_calc = crc16(0, report_data, (len - 2));
> +
> + if (crc_calc != crc_report) {
> + dev_err(dev,
> + "CRC mismatch! Expected: %#x, Calculated CRC: %#x.\n",
> + crc_report, crc_calc);
> + return -EINVAL;
> + }
> +
> + switch (report_data[1]) {
> + case AXIOM_USAGE_2DCTS_REPORT_ID:
> + if (axiom_process_u41_report(ts, &report_data[1])) {
> + input_mt_sync_frame(input_dev);
> + input_sync(input_dev);
> + }
> + break;
> +
> + case AXIOM_USAGE_2AUX_REPORT_ID:
> + /* This is an aux report (force) */
> + axiom_process_u46_report(ts, &report_data[1]);
> + input_mt_sync(input_dev);
> + input_sync(input_dev);
> + break;
> +
> + case AXIOM_USAGE_2HB_REPORT_ID:
> + /* This is a heartbeat report */
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static void axiom_i2c_poll(struct input_dev *input_dev)
> +{
> + struct axiom_data *ts = input_get_drvdata(input_dev);
> +
> + axiom_handle_events(ts);
> +}
> +
> +static irqreturn_t axiom_irq(int irq, void *dev_id)
> +{
> + struct axiom_data *ts = dev_id;
> +
> + axiom_handle_events(ts);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void axiom_reset(struct gpio_desc *reset_gpio)
> +{
> + gpiod_set_value_cansleep(reset_gpio, 1);
> + usleep_range(1000, 2000);
> + gpiod_set_value_cansleep(reset_gpio, 0);
> + msleep(AXIOM_STARTUP_TIME_MS);
> +}
> +
> +static int axiom_i2c_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct input_dev *input_dev;
> + struct axiom_data *ts;
> + u32 poll_interval;
> + int target;
> + int error;
> +
> + ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
> + if (!ts)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(client, ts);
> + ts->client = client;
> + ts->dev = dev;
> +
> + ts->regmap = devm_regmap_init_i2c(client, &axiom_i2c_regmap_config);
> + error = PTR_ERR_OR_ZERO(ts->regmap);
> + if (error) {
> + dev_err(dev, "Failed to initialize regmap: %d\n", error);
> + return error;
> + }
> +
> + ts->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ts->reset_gpio))
> + return dev_err_probe(dev, PTR_ERR(ts->reset_gpio), "failed to get reset GPIO\n");
> +
> + if (ts->reset_gpio)
> + axiom_reset(ts->reset_gpio);
This seems useless, since you doing an reset without enabling the power
supply (below). I know there are systems which do have the supply always
connected or for ACPI the supply is managed via firmware, but the driver
should implement the correct logic and for DT/OF case this is not
correct.
> +
> + ts->vddi = devm_regulator_get_optional(dev, "vddi");
> + if (!IS_ERR(ts->vddi)) {
> + error = devm_regulator_get_enable(dev, "vddi");
Regulators are ref counted and now you request the regulator twice. Also
the regulator is not optional, it is required for the device to work.
Same applies to the vdda below.
> + if (error)
> + return dev_err_probe(&client->dev, error,
> + "Failed to enable vddi regulator\n");
> + }
> +
> + ts->vdda = devm_regulator_get_optional(dev, "vdda");
> + if (!IS_ERR(ts->vdda)) {
> + error = devm_regulator_get_enable(dev, "vdda");
> + if (error)
> + return dev_err_probe(&client->dev, error,
> + "Failed to enable vdda regulator\n");
> + msleep(AXIOM_STARTUP_TIME_MS);
> + }
> +
> + error = axiom_discover(ts);
> + if (error)
> + return dev_err_probe(dev, error, "Failed touchscreen discover\n");
> +
> + input_dev = devm_input_allocate_device(ts->dev);
> + if (!input_dev)
> + return -ENOMEM;
> +
> + input_dev->name = "TouchNetix axiom Touchscreen";
> + input_dev->phys = "input/axiom_ts";
> +
> + input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, 65535, 0, 0);
> + input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, 65535, 0, 0);
> + input_set_abs_params(input_dev, ABS_MT_TOOL_TYPE, 0, MT_TOOL_MAX, 0, 0);
> + input_set_abs_params(input_dev, ABS_MT_DISTANCE, 0, 127, 0, 0);
> + input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 127, 0, 0);
> +
> + touchscreen_parse_properties(input_dev, true, &ts->prop);
> +
> + /* Registers the axiom device as a touchscreen instead of a mouse pointer */
> + error = input_mt_init_slots(input_dev, AXIOM_U41_MAX_TARGETS, INPUT_MT_DIRECT);
> + if (error)
> + return error;
> +
> + /* Enables the raw data for up to 4 force channels to be sent to the input subsystem */
> + set_bit(EV_REL, input_dev->evbit);
> + set_bit(EV_MSC, input_dev->evbit);
> + /* Declare that we support "RAW" Miscellaneous events */
> + set_bit(MSC_RAW, input_dev->mscbit);
> +
> + ts->input_dev = input_dev;
> + input_set_drvdata(ts->input_dev, ts);
> +
> + /* Ensure that all reports are initialised to not be present. */
> + for (target = 0; target < AXIOM_U41_MAX_TARGETS; target++)
> + ts->targets[target].state = AXIOM_TARGET_STATE_NOT_PRESENT;
> +
> + error = devm_request_threaded_irq(dev, client->irq, NULL,
> + axiom_irq, IRQF_ONESHOT, dev_name(dev), ts);
> + if (error) {
> + dev_info(dev, "Request irq failed, falling back to polling mode");
> +
> + error = input_setup_polling(input_dev, axiom_i2c_poll);
> + if (error)
> + return dev_err_probe(ts->dev, error, "Unable to set up polling mode\n");
> +
> + if (!device_property_read_u32(ts->dev, "poll-interval", &poll_interval))
This is not wrong but can we move the "poll-intervall" parsing into
touchscreen_parse_properties() since it seems pretty common to me.
> + input_set_poll_interval(input_dev, poll_interval);
> + else
> + input_set_poll_interval(input_dev, POLL_INTERVAL_DEFAULT_MS);
> + }
> +
> + error = input_register_device(input_dev);
> + if (error)
> + return dev_err_probe(ts->dev, error,
> + "Could not register with Input Sub-system.\n");
return input_register_device(input_dev);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id axiom_i2c_id_table[] = {
> + { "ax54a" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(i2c, axiom_i2c_id_table);
Do we really need an i2c-id table here? Most platforms do either use OF
or ACPI.
Regards,
Marco
> +static const struct of_device_id axiom_i2c_of_match[] = {
> + { .compatible = "touchnetix,ax54a", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, axiom_i2c_of_match);
> +
> +static struct i2c_driver axiom_i2c_driver = {
> + .driver = {
> + .name = "axiom",
> + .of_match_table = axiom_i2c_of_match,
> + },
> + .id_table = axiom_i2c_id_table,
> + .probe = axiom_i2c_probe,
> +};
> +module_i2c_driver(axiom_i2c_driver);
> +
> +MODULE_AUTHOR("Bart Prescott <bartp@baasheep.co.uk>");
> +MODULE_AUTHOR("Pedro Torruella <pedro.torruella@touchnetix.com>");
> +MODULE_AUTHOR("Mark Satterthwaite <mark.satterthwaite@touchnetix.com>");
> +MODULE_AUTHOR("Hannah Rossiter <hannah.rossiter@touchnetix.com>");
> +MODULE_AUTHOR("Kamel Bouhara <kamel.bouhara@bootlin.com>");
> +MODULE_DESCRIPTION("TouchNetix axiom touchscreen I2C bus driver");
> +MODULE_LICENSE("GPL");
> --
> 2.25.1
>
>
^ permalink raw reply
* Enquiry
From: Aminda Sebastian @ 2024-03-13 21:43 UTC (permalink / raw)
To: linux-input
Good day .
Please email us your company's most recent catalog. We would like
to make a purchase from you.
Looking forward to hearing from you.
Aminda Sebastian
Purchasing and Quality Manager
GSCOMMODITYTRADNG S.R.L
Parque Empresarial Vía Norte, C. Quintanavides,
21, Building 5, 28050 Madrid, Spain.
^ permalink raw reply
* Re: [PATCH v9 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: Kamel Bouhara @ 2024-03-14 8:28 UTC (permalink / raw)
To: Marco Felsch
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Jeff LaBundy, catalin.popescu, mark.satterthwaite,
Thomas Petazzoni, Gregory Clement, bsp-development.geo
In-Reply-To: <20240313202135.2lwgtu2z67ksh2tz@pengutronix.de>
Le Wed, Mar 13, 2024 at 09:21:35PM +0100, Marco Felsch a écrit :
> Hi Kamel,
>
Hi Marco,
> please see below, be aware that this is just an rough review.
>
[...]
> > +
> > +static int axiom_i2c_probe(struct i2c_client *client)
> > +{
> > + struct device *dev = &client->dev;
> > + struct input_dev *input_dev;
> > + struct axiom_data *ts;
> > + u32 poll_interval;
> > + int target;
> > + int error;
> > +
> > + ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
> > + if (!ts)
> > + return -ENOMEM;
> > +
> > + i2c_set_clientdata(client, ts);
> > + ts->client = client;
> > + ts->dev = dev;
> > +
> > + ts->regmap = devm_regmap_init_i2c(client, &axiom_i2c_regmap_config);
> > + error = PTR_ERR_OR_ZERO(ts->regmap);
> > + if (error) {
> > + dev_err(dev, "Failed to initialize regmap: %d\n", error);
> > + return error;
> > + }
> > +
> > + ts->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(ts->reset_gpio))
> > + return dev_err_probe(dev, PTR_ERR(ts->reset_gpio), "failed to get reset GPIO\n");
> > +
> > + if (ts->reset_gpio)
> > + axiom_reset(ts->reset_gpio);
>
> This seems useless, since you doing an reset without enabling the power
> supply (below). I know there are systems which do have the supply always
> connected or for ACPI the supply is managed via firmware, but the driver
> should implement the correct logic and for DT/OF case this is not
> correct.
>
Alright, this can be moved after enabling vdda regulator as this is
still required in the power sequence.
> > +
> > + ts->vddi = devm_regulator_get_optional(dev, "vddi");
> > + if (!IS_ERR(ts->vddi)) {
> > + error = devm_regulator_get_enable(dev, "vddi");
>
> Regulators are ref counted and now you request the regulator twice. Also
> the regulator is not optional, it is required for the device to work.
> Same applies to the vdda below.
>
Ack, I wrongly took my use case (ACPI + fixed regulators) but this isn't
a common use case.
> > + if (error)
> > + return dev_err_probe(&client->dev, error,
> > + "Failed to enable vddi regulator\n");
> > + }
> > +
> > + ts->vdda = devm_regulator_get_optional(dev, "vdda");
> > + if (!IS_ERR(ts->vdda)) {
> > + error = devm_regulator_get_enable(dev, "vdda");
> > + if (error)
> > + return dev_err_probe(&client->dev, error,
> > + "Failed to enable vdda regulator\n");
> > + msleep(AXIOM_STARTUP_TIME_MS);
> > + }
> > +
> > + error = axiom_discover(ts);
> > + if (error)
> > + return dev_err_probe(dev, error, "Failed touchscreen discover\n");
> > +
> > + input_dev = devm_input_allocate_device(ts->dev);
> > + if (!input_dev)
> > + return -ENOMEM;
> > +
> > + input_dev->name = "TouchNetix axiom Touchscreen";
> > + input_dev->phys = "input/axiom_ts";
> > +
> > + input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, 65535, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, 65535, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_TOOL_TYPE, 0, MT_TOOL_MAX, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_DISTANCE, 0, 127, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 127, 0, 0);
> > +
> > + touchscreen_parse_properties(input_dev, true, &ts->prop);
> > +
> > + /* Registers the axiom device as a touchscreen instead of a mouse pointer */
> > + error = input_mt_init_slots(input_dev, AXIOM_U41_MAX_TARGETS, INPUT_MT_DIRECT);
> > + if (error)
> > + return error;
> > +
> > + /* Enables the raw data for up to 4 force channels to be sent to the input subsystem */
> > + set_bit(EV_REL, input_dev->evbit);
> > + set_bit(EV_MSC, input_dev->evbit);
> > + /* Declare that we support "RAW" Miscellaneous events */
> > + set_bit(MSC_RAW, input_dev->mscbit);
> > +
> > + ts->input_dev = input_dev;
> > + input_set_drvdata(ts->input_dev, ts);
> > +
> > + /* Ensure that all reports are initialised to not be present. */
> > + for (target = 0; target < AXIOM_U41_MAX_TARGETS; target++)
> > + ts->targets[target].state = AXIOM_TARGET_STATE_NOT_PRESENT;
> > +
> > + error = devm_request_threaded_irq(dev, client->irq, NULL,
> > + axiom_irq, IRQF_ONESHOT, dev_name(dev), ts);
> > + if (error) {
> > + dev_info(dev, "Request irq failed, falling back to polling mode");
> > +
> > + error = input_setup_polling(input_dev, axiom_i2c_poll);
> > + if (error)
> > + return dev_err_probe(ts->dev, error, "Unable to set up polling mode\n");
> > +
> > + if (!device_property_read_u32(ts->dev, "poll-interval", &poll_interval))
>
> This is not wrong but can we move the "poll-intervall" parsing into
> touchscreen_parse_properties() since it seems pretty common to me.
Maybe too late to add it in this series :).
>
> > + input_set_poll_interval(input_dev, poll_interval);
> > + else
> > + input_set_poll_interval(input_dev, POLL_INTERVAL_DEFAULT_MS);
> > + }
> > +
> > + error = input_register_device(input_dev);
> > + if (error)
> > + return dev_err_probe(ts->dev, error,
> > + "Could not register with Input Sub-system.\n");
>
> return input_register_device(input_dev);
Ack, thanks.
>
> > +
> > + return 0;
> > +}
> > +
> > +static const struct i2c_device_id axiom_i2c_id_table[] = {
> > + { "ax54a" },
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(i2c, axiom_i2c_id_table);
>
> Do we really need an i2c-id table here? Most platforms do either use OF
> or ACPI.
If not wrong this is used to enumarate the device from userspace
and in my case it is required as there is no direct i2c controller
exposed from ACPI pov.
Thanks !
--
Kamel Bouhara, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 2/4] HID: hid-sensor-custom: Convert sprintf/snprintf to sysfs_emit
From: Li Zhijian @ 2024-03-14 8:47 UTC (permalink / raw)
To: linux-kernel
Cc: Li Zhijian, Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada,
Benjamin Tissoires, linux-input, linux-iio
In-Reply-To: <20240314084753.1322110-1-lizhijian@fujitsu.com>
Per filesystems/sysfs.rst, show() should only use sysfs_emit()
or sysfs_emit_at() when formatting the value to be returned to user space.
coccinelle complains that there are still a couple of functions that use
snprintf(). Convert them to sysfs_emit().
sprintf() will be converted as weel if they have.
Generally, this patch is generated by
make coccicheck M=<path/to/file> MODE=patch \
COCCI=scripts/coccinelle/api/device_attr_show.cocci
No functional change intended
CC: Jiri Kosina <jikos@kernel.org>
CC: Jonathan Cameron <jic23@kernel.org>
CC: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
CC: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: linux-input@vger.kernel.org
CC: linux-iio@vger.kernel.org
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
This is a part of the work "Fix coccicheck device_attr_show warnings"[1]
Split them per subsystem so that the maintainer can review it easily
[1] https://lore.kernel.org/lkml/20240116041129.3937800-1-lizhijian@fujitsu.com/
---
drivers/hid/hid-sensor-custom.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
index d85398721659..ee1a118834f0 100644
--- a/drivers/hid/hid-sensor-custom.c
+++ b/drivers/hid/hid-sensor-custom.c
@@ -155,7 +155,7 @@ static ssize_t enable_sensor_show(struct device *dev,
{
struct hid_sensor_custom *sensor_inst = dev_get_drvdata(dev);
- return sprintf(buf, "%d\n", sensor_inst->enable);
+ return sysfs_emit(buf, "%d\n", sensor_inst->enable);
}
static int set_power_report_state(struct hid_sensor_custom *sensor_inst,
@@ -372,14 +372,14 @@ static ssize_t show_value(struct device *dev, struct device_attribute *attr,
sizeof(struct hid_custom_usage_desc),
usage_id_cmp);
if (usage_desc)
- return snprintf(buf, PAGE_SIZE, "%s\n",
- usage_desc->desc);
+ return sysfs_emit(buf, "%s\n",
+ usage_desc->desc);
else
- return sprintf(buf, "not-specified\n");
+ return sysfs_emit(buf, "not-specified\n");
} else
return -EINVAL;
- return sprintf(buf, "%d\n", value);
+ return sysfs_emit(buf, "%d\n", value);
}
static ssize_t store_value(struct device *dev, struct device_attribute *attr,
--
2.29.2
^ permalink raw reply related
* [PATCH v2 4/4] HID: corsair/lenovo: Convert sprintf/snprintf to sysfs_emit
From: Li Zhijian @ 2024-03-14 8:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Li Zhijian, Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20240314084753.1322110-1-lizhijian@fujitsu.com>
Per filesystems/sysfs.rst, show() should only use sysfs_emit()
or sysfs_emit_at() when formatting the value to be returned to user space.
coccinelle complains that there are still a couple of functions that use
snprintf(). Convert them to sysfs_emit().
sprintf() will be converted as weel if they have.
Generally, this patch is generated by
make coccicheck M=<path/to/file> MODE=patch \
COCCI=scripts/coccinelle/api/device_attr_show.cocci
No functional change intended
CC: Jiri Kosina <jikos@kernel.org>
CC: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: linux-input@vger.kernel.org
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
This is a part of the work "Fix coccicheck device_attr_show warnings"[1]
Split them per subsystem so that the maintainer can review it easily
[1] https://lore.kernel.org/lkml/20240116041129.3937800-1-lizhijian@fujitsu.com/
---
drivers/hid/hid-corsair.c | 4 ++--
drivers/hid/hid-lenovo.c | 22 +++++++++++-----------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/hid/hid-corsair.c b/drivers/hid/hid-corsair.c
index 8c895c820b67..702f50e9841d 100644
--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -298,7 +298,7 @@ static ssize_t k90_show_macro_mode(struct device *dev,
goto out;
}
- ret = snprintf(buf, PAGE_SIZE, "%s\n", macro_mode);
+ ret = sysfs_emit(buf, "%s\n", macro_mode);
out:
kfree(data);
@@ -367,7 +367,7 @@ static ssize_t k90_show_current_profile(struct device *dev,
goto out;
}
- ret = snprintf(buf, PAGE_SIZE, "%d\n", current_profile);
+ ret = sysfs_emit(buf, "%d\n", current_profile);
out:
kfree(data);
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index 149a3c74346b..97f8d01cadcd 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -555,7 +555,7 @@ static ssize_t attr_fn_lock_show(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data->fn_lock);
+ return sysfs_emit(buf, "%u\n", data->fn_lock);
}
static ssize_t attr_fn_lock_store(struct device *dev,
@@ -599,8 +599,8 @@ static ssize_t attr_sensitivity_show_cptkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *cptkbd_data = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n",
- cptkbd_data->sensitivity);
+ return sysfs_emit(buf, "%u\n",
+ cptkbd_data->sensitivity);
}
static ssize_t attr_sensitivity_store_cptkbd(struct device *dev,
@@ -789,7 +789,7 @@ static ssize_t attr_press_to_select_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data_pointer->press_to_select);
+ return sysfs_emit(buf, "%u\n", data_pointer->press_to_select);
}
static ssize_t attr_press_to_select_store_tpkbd(struct device *dev,
@@ -819,7 +819,7 @@ static ssize_t attr_dragging_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data_pointer->dragging);
+ return sysfs_emit(buf, "%u\n", data_pointer->dragging);
}
static ssize_t attr_dragging_store_tpkbd(struct device *dev,
@@ -849,7 +849,7 @@ static ssize_t attr_release_to_select_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data_pointer->release_to_select);
+ return sysfs_emit(buf, "%u\n", data_pointer->release_to_select);
}
static ssize_t attr_release_to_select_store_tpkbd(struct device *dev,
@@ -879,7 +879,7 @@ static ssize_t attr_select_right_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data_pointer->select_right);
+ return sysfs_emit(buf, "%u\n", data_pointer->select_right);
}
static ssize_t attr_select_right_store_tpkbd(struct device *dev,
@@ -909,8 +909,8 @@ static ssize_t attr_sensitivity_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n",
- data_pointer->sensitivity);
+ return sysfs_emit(buf, "%u\n",
+ data_pointer->sensitivity);
}
static ssize_t attr_sensitivity_store_tpkbd(struct device *dev,
@@ -938,8 +938,8 @@ static ssize_t attr_press_speed_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n",
- data_pointer->press_speed);
+ return sysfs_emit(buf, "%u\n",
+ data_pointer->press_speed);
}
static ssize_t attr_press_speed_store_tpkbd(struct device *dev,
--
2.29.2
^ permalink raw reply related
* [PATCH v2 1/4] HID: hid-picolcd_core: Convert sprintf/snprintf to sysfs_emit
From: Li Zhijian @ 2024-03-14 8:47 UTC (permalink / raw)
To: linux-kernel
Cc: Li Zhijian, Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
linux-input
Per filesystems/sysfs.rst, show() should only use sysfs_emit()
or sysfs_emit_at() when formatting the value to be returned to user space.
coccinelle complains that there are still a couple of functions that use
snprintf(). Convert them to sysfs_emit().
sprintf() will be converted as weel if they have.
Generally, this patch is generated by
make coccicheck M=<path/to/file> MODE=patch \
COCCI=scripts/coccinelle/api/device_attr_show.cocci
No functional change intended
CC: "Bruno Prémont" <bonbons@linux-vserver.org>
CC: Jiri Kosina <jikos@kernel.org>
CC: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: linux-input@vger.kernel.org
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
This is a part of the work "Fix coccicheck device_attr_show warnings"[1]
Split them per subsystem so that the maintainer can review it easily
[1] https://lore.kernel.org/lkml/20240116041129.3937800-1-lizhijian@fujitsu.com/
---
drivers/hid/hid-picolcd_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
index bbda231a7ce3..fa46fb6eab3f 100644
--- a/drivers/hid/hid-picolcd_core.c
+++ b/drivers/hid/hid-picolcd_core.c
@@ -256,9 +256,9 @@ static ssize_t picolcd_operation_mode_show(struct device *dev,
struct picolcd_data *data = dev_get_drvdata(dev);
if (data->status & PICOLCD_BOOTLOADER)
- return snprintf(buf, PAGE_SIZE, "[bootloader] lcd\n");
+ return sysfs_emit(buf, "[bootloader] lcd\n");
else
- return snprintf(buf, PAGE_SIZE, "bootloader [lcd]\n");
+ return sysfs_emit(buf, "bootloader [lcd]\n");
}
static ssize_t picolcd_operation_mode_store(struct device *dev,
@@ -301,7 +301,7 @@ static ssize_t picolcd_operation_mode_delay_show(struct device *dev,
{
struct picolcd_data *data = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%hu\n", data->opmode_delay);
+ return sysfs_emit(buf, "%hu\n", data->opmode_delay);
}
static ssize_t picolcd_operation_mode_delay_store(struct device *dev,
--
2.29.2
^ 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