* Re: [PATCH v6 0/8] Convert DA906{1,2} bindings to json-schema
From: Lee Jones @ 2023-12-21 14:15 UTC (permalink / raw)
To: Lee Jones, Wim Van Sebroeck, Guenter Roeck, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Biju Das
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input, devicetree, linux-pm,
linux-watchdog, Geert Uytterhoeven, Prabhakar Mahadev Lad,
Biju Das, linux-renesas-soc
In-Reply-To: <20231214080911.23359-1-biju.das.jz@bp.renesas.com>
On Thu, 14 Dec 2023 08:09:03 +0000, Biju Das wrote:
> Convert the below bindings to json-schema
> 1) DA906{1,2} mfd bindings
> 2) DA906{1,2,3} onkey bindings
> 3) DA906{1,2,3} thermal bindings
>
> Also add fallback for DA9061 watchdog device and document
> DA9063 watchdog device.
>
> [...]
Applied, thanks!
[1/8] dt-bindings: mfd: da9062: Update watchdog description
commit: 9e7b13b805bcbe5335c2936d4c7ea0323ac69a81
[2/8] dt-bindings: watchdog: dlg,da9062-watchdog: Add fallback for DA9061 watchdog
commit: 28d34db7772f18490b52328f04a3bf69ed5390d2
[3/8] dt-bindings: watchdog: dlg,da9062-watchdog: Document DA9063 watchdog
commit: d2a7dbb808870c17cffa2749ea877f61f298d098
[4/8] dt-bindings: mfd: dlg,da9063: Update watchdog child node
commit: d4018547a15a94c7e865b2cef82bff1cd43a32b3
[5/8] dt-bindings: input: Convert da906{1,2,3} onkey to json-schema
commit: db459d3da7bb9c37cb86897c7b321a49f8e40968
[6/8] dt-bindings: thermal: Convert da906{1,2} thermal to json-schema
commit: 998f499c843e360bcd9ee1fe9addc3b5d32f1234
[7/8] dt-bindings: mfd: dlg,da9063: Sort child devices
commit: 2bbf9d2a8e3bc933703dfda87cac953bed458496
[8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
commit: 522225161830f6a93f2aaabda99226c1ffddc8c4
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: element sizes in input_event struct on riscv32
From: Antonios Salios @ 2023-12-21 13:38 UTC (permalink / raw)
To: Arnd Bergmann, Dmitry Torokhov, Deepa Dinamani
Cc: rydberg, linux-input, linux-kernel, Jan Henrik Weinstock,
Lukas Jünger
In-Reply-To: <1a528414-f193-4ac0-a911-af426bb48d64@app.fastmail.com>
On Thu, 2023-12-21 at 12:28 +0000, Arnd Bergmann wrote:
> On Thu, Dec 21, 2023, at 08:56, Antonios Salios wrote:
> > On Tue, 2023-12-19 at 13:53 +0000, Arnd Bergmann wrote:
> > > On Tue, Dec 19, 2023, at 02:50, Dmitry Torokhov wrote:
> >
> > The problem seems to be, that __USE_TIME_BITS64 is not defined even
> > though riscv32 uses 64-bit time.
>
> That sounds like a libc bug. Which C library are you using?
Glibc 2.37.
> > __BITS_PER_LONG is set to 32 & __KERNEL__ is (of course) undefined
> > in
> > userspace.
> > The userspace therefore uses 64-bit values as opposed to the
> > kernel,
> > which uses 32-bit values.
> >
> > __USE_TIME_BITS64 is only set when __TIMESIZE is set to 32. [1]
> > Under riscv32, the default value of 64 is used. [2]
>
> I don't know what __TIMESIZE is, this is not part of the kernel ABI
> as far as I can tell. __USE_TIME_BITS64 should be set by any 32-bit
> architecture if the C library defines a 64-bit time_t, otherwise the
> kernel headers have no way of picking the correct definitions based
> on preprocessor logic.
Okay, I agree that this might be a libc problem then. I'll ask the
glibc maintainers.
Thanks for your kind help and happy holidays!
--
Antonios Salios
Software Engineer
MachineWare GmbH | www.machineware.de
Hühnermarkt 19, 52062 Aachen, Germany
Amtsgericht Aachen HRB25734
Geschäftsführung
Lukas Jünger
Dr.-Ing. Jan Henrik Weinstock
^ permalink raw reply
* Re: element sizes in input_event struct on riscv32
From: Arnd Bergmann @ 2023-12-21 12:28 UTC (permalink / raw)
To: Antonios Salios, Dmitry Torokhov, Deepa Dinamani
Cc: rydberg, linux-input, linux-kernel, Jan Henrik Weinstock,
Lukas Jünger
In-Reply-To: <491250ba57be2ab983048ffcf5ffd2aec2bedb9e.camel@mwa.re>
On Thu, Dec 21, 2023, at 08:56, Antonios Salios wrote:
> On Tue, 2023-12-19 at 13:53 +0000, Arnd Bergmann wrote:
>> On Tue, Dec 19, 2023, at 02:50, Dmitry Torokhov wrote:
>
> The header is included from the sysroot of the toolchain, using version
> 6.5.6.
> I'm using glibc 2.37 with a toolchain built from Buildroot.
>
> The problem seems to be, that __USE_TIME_BITS64 is not defined even
> though riscv32 uses 64-bit time.
That sounds like a libc bug. Which C library are you using?
> __BITS_PER_LONG is set to 32 & __KERNEL__ is (of course) undefined in
> userspace.
> The userspace therefore uses 64-bit values as opposed to the kernel,
> which uses 32-bit values.
>
> __USE_TIME_BITS64 is only set when __TIMESIZE is set to 32. [1]
> Under riscv32, the default value of 64 is used. [2]
I don't know what __TIMESIZE is, this is not part of the kernel ABI
as far as I can tell. __USE_TIME_BITS64 should be set by any 32-bit
architecture if the C library defines a 64-bit time_t, otherwise the
kernel headers have no way of picking the correct definitions based
on preprocessor logic.
Arnd
^ permalink raw reply
* Re: element sizes in input_event struct on riscv32
From: Antonios Salios @ 2023-12-21 8:56 UTC (permalink / raw)
To: Arnd Bergmann, Dmitry Torokhov, Deepa Dinamani
Cc: rydberg, linux-input, linux-kernel, Jan Henrik Weinstock,
Lukas Jünger
In-Reply-To: <9e97eb50-f9a6-4655-9422-fa1106fff97a@app.fastmail.com>
On Tue, 2023-12-19 at 13:53 +0000, Arnd Bergmann wrote:
> On Tue, Dec 19, 2023, at 02:50, Dmitry Torokhov wrote:
> > Hi Antonious,
> >
> > On Thu, Dec 14, 2023 at 11:11:18AM +0100, Antonios Salios wrote:
> > > Hi all.
> > >
> > > I'm having trouble getting evdev to run in a simulated Buildroot
> > > environment on riscv32. Evtest (and the x11 driver) seems to be
> > > receiving garbage data from input devices.
> > >
> > > Analyzing the input_event struct shows that the kernel uses 32-
> > > bit (aka
> > > __kernel_ulong_t) values for __sec & __usec.
> > > Evtest on the other hand interprets these variables as 64-bit
> > > time_t
> > > values in a timeval struct, resulting in a mismatch between the
> > > kernel
> > > and userspace.
> > >
> > > What would be the correct size for these values on a 32-bit
> > > architecture that uses 64-bit time_t values?
> >
> > I think there is misunderstanding - we do not have *2* 64-bit
> > values on
> > 32-but architectures. Here is what was done:
> >
> > Input: extend usable life of event timestamps to 2106 on 32 bit
> > systems
>
> Thanks for forwarding this to me. You are definitely right that
> the user-space structure is intended to use a pair of
> __kernel_ulong_t
> for the timestamp. Usually if an application gets this wrong, it is
> the
> result of having copied old kernel headers the source directory that
> need to be updated.
>
> For evtest in particular, I don't see how that is possible, the
> source
> code at [1] shows that it just includes the global linux/input.h,
> which on riscv32 would have to be at least from linux-5.6 anyway
> because older versions are too old to build a time64 glibc.
>
> Antonios, can you check which header was used to build your copy
> of evtest, and in case this came from /usr/include/linux, which
> version it corresponds to?
>
> Arnd
>
> [1]
> https://gitlab.freedesktop.org/libevdev/evtest/-/blob/master/evtest.c?ref_type=heads
The header is included from the sysroot of the toolchain, using version
6.5.6.
I'm using glibc 2.37 with a toolchain built from Buildroot.
The problem seems to be, that __USE_TIME_BITS64 is not defined even
though riscv32 uses 64-bit time.
__BITS_PER_LONG is set to 32 & __KERNEL__ is (of course) undefined in
userspace.
The userspace therefore uses 64-bit values as opposed to the kernel,
which uses 32-bit values.
__USE_TIME_BITS64 is only set when __TIMESIZE is set to 32. [1]
Under riscv32, the default value of 64 is used. [2]
[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/features-time64.h;h=af9d84daa7dfe4174e9f977b2c76c5c0df1ce47b;hb=refs/tags/glibc-2.37
[2]
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=bits/timesize.h;hb=refs/tags/glibc-2.37
--
Antonios Salios
Software Engineer
MachineWare GmbH | www.machineware.de
Hühnermarkt 19, 52062 Aachen, Germany
Amtsgericht Aachen HRB25734
Geschäftsführung
Lukas Jünger
Dr.-Ing. Jan Henrik Weinstock
^ permalink raw reply
* [PATCH] Input: da9063_onkey - avoid explicitly setting input's parent
From: Dmitry Torokhov @ 2023-12-21 3:09 UTC (permalink / raw)
To: Support Opensource, Biju Das; +Cc: linux-input, linux-kernel
devm_input_allocate_device() already sets parent of the new input
device, there's no need to set it up explicitly.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/misc/da9063_onkey.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/misc/da9063_onkey.c b/drivers/input/misc/da9063_onkey.c
index ce499c28a7b2..c338765e0ecd 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -211,7 +211,6 @@ static int da9063_onkey_probe(struct platform_device *pdev)
snprintf(onkey->phys, sizeof(onkey->phys), "%s/input0",
onkey->config->name);
onkey->input->phys = onkey->phys;
- onkey->input->dev.parent = &pdev->dev;
input_set_capability(onkey->input, EV_KEY, KEY_POWER);
--
2.43.0.195.gebba966016-goog
--
Dmitry
^ permalink raw reply related
* [PATCH] Input: da9063_onkey - avoid using OF-specific APIs
From: Dmitry Torokhov @ 2023-12-21 3:09 UTC (permalink / raw)
To: Support Opensource, Biju Das; +Cc: linux-input, linux-kernel
There is nothing OF-specific in the driver, so switch from OF properties
helpers to generic device helpers.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/misc/da9063_onkey.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/input/misc/da9063_onkey.c b/drivers/input/misc/da9063_onkey.c
index a8b7f1cd0ec2..ce499c28a7b2 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -9,11 +9,12 @@
#include <linux/errno.h>
#include <linux/input.h>
#include <linux/interrupt.h>
+#include <linux/mod_devicetable.h>
#include <linux/platform_device.h>
#include <linux/pm_wakeirq.h>
+#include <linux/property.h>
#include <linux/workqueue.h>
#include <linux/regmap.h>
-#include <linux/of.h>
#include <linux/mfd/da9063/core.h>
#include <linux/mfd/da9063/registers.h>
#include <linux/mfd/da9062/core.h>
@@ -199,8 +200,8 @@ static int da9063_onkey_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, -ENXIO,
"Parent regmap unavailable.\n");
- onkey->key_power = !of_property_read_bool(pdev->dev.of_node,
- "dlg,disable-key-power");
+ onkey->key_power = !device_property_read_bool(&pdev->dev,
+ "dlg,disable-key-power");
onkey->input = devm_input_allocate_device(&pdev->dev);
if (!onkey->input)
--
2.43.0.195.gebba966016-goog
--
Dmitry
^ permalink raw reply related
* Re: [RFC PATCH 4/5] input: add onkey driver for Marvell 88PM88X PMICs
From: Dmitry Torokhov @ 2023-12-20 23:33 UTC (permalink / raw)
To: Karel Balej
Cc: Karel Balej, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, linux-input, devicetree, linux-kernel,
Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <20231217131838.7569-5-karelb@gimli.ms.mff.cuni.cz>
Hi Karel,
On Sun, Dec 17, 2023 at 02:17:02PM +0100, Karel Balej wrote:
> From: Karel Balej <balejk@matfyz.cz>
>
> The Marvell 88PM88X PMICs provide onkey among other things. Add client
> driver to handle it. The driver currently only provides a basic support
> omitting additional functions found in the vendor version, such as long
> onkey and GPIO integration.
>
> Signed-off-by: Karel Balej <balejk@matfyz.cz>
> ---
> drivers/input/misc/88pm88x-onkey.c | 103 +++++++++++++++++++++++++++++
> drivers/input/misc/Kconfig | 10 +++
> drivers/input/misc/Makefile | 1 +
> 3 files changed, 114 insertions(+)
> create mode 100644 drivers/input/misc/88pm88x-onkey.c
>
> diff --git a/drivers/input/misc/88pm88x-onkey.c b/drivers/input/misc/88pm88x-onkey.c
> new file mode 100644
> index 000000000000..0d6056a3cab2
> --- /dev/null
> +++ b/drivers/input/misc/88pm88x-onkey.c
> @@ -0,0 +1,103 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <linux/kernel.h>
> +#include <linux/input.h>
> +#include <linux/regmap.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
Please sort alphabetically.
> +
> +#include <linux/mfd/88pm88x.h>
> +
> +struct pm88x_onkey {
> + struct input_dev *idev;
> + struct pm88x_chip *chip;
> + int irq;
Since you are using devm to request interrupt I do not think you need to
store it here.
> +};
> +
> +static irqreturn_t pm88x_onkey_irq_handler(int irq, void *data)
> +{
> + struct pm88x_onkey *onkey = data;
> + unsigned int val;
> + int ret = 0;
"error". Also no need to initialize it to 0.
> +
> + ret = regmap_read(onkey->chip->regmaps[PM88X_REGMAP_BASE], PM88X_REG_STATUS1, &val);
I still prefer to keep withing 80 columns, unless longer lines are a
clear win.
> + if (ret) {
> + dev_err(onkey->idev->dev.parent, "Failed to read status: %d\n", ret);
Maybe have "dev" in onkey instead of poking through input?
> + return IRQ_NONE;
> + }
> + val &= PM88X_ONKEY_STS1;
> +
> + input_report_key(onkey->idev, KEY_POWER, val);
> + input_sync(onkey->idev);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int pm88x_onkey_probe(struct platform_device *pdev)
> +{
> + struct pm88x_chip *chip = dev_get_drvdata(pdev->dev.parent);
> + struct pm88x_onkey *onkey;
> + int err;
> +
> + onkey = devm_kzalloc(&pdev->dev, sizeof(*onkey), GFP_KERNEL);
> + if (!onkey)
> + return -ENOMEM;
> +
> + onkey->chip = chip;
> +
> + onkey->irq = platform_get_irq(pdev, 0);
> + if (onkey->irq < 0) {
> + dev_err(&pdev->dev, "Failed to get IRQ\n");
> + return -EINVAL;
Do not clobber the return from platform_get_irq(). So "return
onkey->irq" (or simply irq if you drop it from onkey and use temporary).
> + }
> +
> + onkey->idev = devm_input_allocate_device(&pdev->dev);
> + if (!onkey->idev) {
> + dev_err(&pdev->dev, "Failed to allocate input device\n");
> + return -ENOMEM;
> + }
> +
> + onkey->idev->name = "88pm88x-onkey";
> + onkey->idev->phys = "88pm88x-onkey/input0";
> + onkey->idev->id.bustype = BUS_I2C;
> + onkey->idev->dev.parent = &pdev->dev;
No need to do this since you are using devm_input_allocate_device().
> + onkey->idev->evbit[0] = BIT_MASK(EV_KEY);
> + onkey->idev->keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
Please use
input_set_capability(onkey->idev, EV_KEY, KEY_POWER);
> +
> + err = devm_request_threaded_irq(&pdev->dev, onkey->irq, NULL, pm88x_onkey_irq_handler,
> + IRQF_ONESHOT | IRQF_NO_SUSPEND, "onkey", onkey);
Please align arguments.
> + if (err) {
> + dev_err(&pdev->dev, "Failed to request IRQ: %d\n", err);
I was persuaded to stop my crusade against dev_err_probe() so you may
use it here.
> + return err;
> + }
> +
> + err = input_register_device(onkey->idev);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to register input device: %d\n", err);
> + return err;
> + }
> +
> + device_init_wakeup(&pdev->dev, 1);
Are there cases where we woudl not want wakeup? Maybe use standard
"wakeup-source" property?
> +
> + return 0;
> +}
> +
> +static const struct of_device_id pm88x_onkey_of_match[] = {
> + { .compatible = "marvell,88pm88x-onkey", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, pm88x_onkey_of_match);
> +
> +static struct platform_driver pm88x_onkey_driver = {
> + .driver = {
> + .name = "88pm88x-onkey",
> + .of_match_table = of_match_ptr(pm88x_onkey_of_match),
Given that you are not guarding pm88x_onkey_of_match definition with
#ifdef CONFIG_OF you shoudl not use of_match_ptr().
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: SoC button array: add mapping for airplane mode button
From: Werner Sembach @ 2023-12-20 15:45 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <20231215171718.80229-1-wse@tuxedocomputers.com>
Am 15.12.23 um 18:17 schrieb Werner Sembach:
> From: Christoffer Sandberg <cs@tuxedo.de>
>
> This add a mapping for the airplane mode button on the TUXEDO Pulse Gen3.
>
> While it is physically a key it behaves more like a switch, sending a key
> down on first press and a key up on 2nd press. Therefor the switch event is
> used here. Besides this behaviour it uses the HID usage-id 0xc6 (Wireless
> Radio Button) and not 0xc8 (Wireless Radio Slider Switch), but since
> neither 0xc6 nor 0xc8 are currently implemented at all in soc_button_array
> this not to standard behaviour is not put behind a quirk for the moment.
>
> Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
For reference: https://bugzilla.kernel.org/show_bug.cgi?id=214259
> ---
> drivers/input/misc/soc_button_array.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
> index 08bcee3d6bcca..f6d060377d189 100644
> --- a/drivers/input/misc/soc_button_array.c
> +++ b/drivers/input/misc/soc_button_array.c
> @@ -299,6 +299,11 @@ static int soc_button_parse_btn_desc(struct device *dev,
> info->name = "power";
> info->event_code = KEY_POWER;
> info->wakeup = true;
> + } else if (upage == 0x01 && usage == 0xc6) {
> + info->name = "airplane mode switch";
> + info->event_type = EV_SW;
> + info->event_code = SW_RFKILL_ALL;
> + info->active_low = false;
> } else if (upage == 0x01 && usage == 0xca) {
> info->name = "rotation lock switch";
> info->event_type = EV_SW;
^ permalink raw reply
* Re: [PATCH] Input: SoC button array: add mapping for airplane mode button
From: Werner Sembach @ 2023-12-20 15:38 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <20231215171718.80229-1-wse@tuxedocomputers.com>
Am 15.12.23 um 18:17 schrieb Werner Sembach:
> From: Christoffer Sandberg <cs@tuxedo.de>
>
> This add a mapping for the airplane mode button on the TUXEDO Pulse Gen3.
>
> While it is physically a key it behaves more like a switch, sending a key
> down on first press and a key up on 2nd press. Therefor the switch event is
> used here. Besides this behaviour it uses the HID usage-id 0xc6 (Wireless
> Radio Button) and not 0xc8 (Wireless Radio Slider Switch), but since
> neither 0xc6 nor 0xc8 are currently implemented at all in soc_button_array
> this not to standard behaviour is not put behind a quirk for the moment.
>
> Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: stable@vger.kernel.org
> ---
> drivers/input/misc/soc_button_array.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
> index 08bcee3d6bcca..f6d060377d189 100644
> --- a/drivers/input/misc/soc_button_array.c
> +++ b/drivers/input/misc/soc_button_array.c
> @@ -299,6 +299,11 @@ static int soc_button_parse_btn_desc(struct device *dev,
> info->name = "power";
> info->event_code = KEY_POWER;
> info->wakeup = true;
> + } else if (upage == 0x01 && usage == 0xc6) {
> + info->name = "airplane mode switch";
> + info->event_type = EV_SW;
> + info->event_code = SW_RFKILL_ALL;
> + info->active_low = false;
> } else if (upage == 0x01 && usage == 0xca) {
> info->name = "rotation lock switch";
> info->event_type = EV_SW;
^ permalink raw reply
* Re: [PATCH v2 3/3] iio: hid-sensor-als: Add light chromaticity support
From: Jonathan Cameron @ 2023-12-20 15:29 UTC (permalink / raw)
To: Srinivas Pandruvada
Cc: jikos, lars, Basavaraj.Natikar, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20231218203026.1156375-4-srinivas.pandruvada@linux.intel.com>
On Mon, 18 Dec 2023 12:30:26 -0800
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> From: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
>
> In most cases, ambient color sensors also support the x and y light
> colors, which represent the coordinates on the CIE 1931 chromaticity
> diagram. Thus, add light chromaticity x and y.
>
> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Is it not possible to unify the support to be a single pass over the
channels array that just checks each one for availability and copies
the channel in if is found? Tweaked slightly to deal with
the pair of chromaticity channels.
Jonathan
> ---
> v2:
> Original patch from Basavaraj Natikar <Basavaraj.Natikar@amd.com> is
> modified to prevent failure when the new usage id is not found in the
> descriptor.
>
> drivers/iio/light/hid-sensor-als.c | 68 +++++++++++++++++++++++++++++-
> include/linux/hid-sensor-ids.h | 3 ++
> 2 files changed, 70 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index 8d6beacc338a..6e2793fa515c 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
> @@ -17,6 +17,8 @@ enum {
> CHANNEL_SCAN_INDEX_INTENSITY,
> CHANNEL_SCAN_INDEX_ILLUM,
> CHANNEL_SCAN_INDEX_COLOR_TEMP,
> + CHANNEL_SCAN_INDEX_CHROMATICITY_X,
> + CHANNEL_SCAN_INDEX_CHROMATICITY_Y,
> CHANNEL_SCAN_INDEX_MAX
> };
>
> @@ -76,6 +78,30 @@ static const struct iio_chan_spec als_channels[] = {
> BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
> .scan_index = CHANNEL_SCAN_INDEX_COLOR_TEMP,
> },
> + {
> + .type = IIO_CHROMATICITY,
> + .modified = 1,
> + .channel2 = IIO_MOD_X,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> + BIT(IIO_CHAN_INFO_HYSTERESIS) |
> + BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
> + .scan_index = CHANNEL_SCAN_INDEX_CHROMATICITY_X,
> + },
> + {
> + .type = IIO_CHROMATICITY,
> + .modified = 1,
> + .channel2 = IIO_MOD_Y,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> + BIT(IIO_CHAN_INFO_HYSTERESIS) |
> + BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
> + .scan_index = CHANNEL_SCAN_INDEX_CHROMATICITY_Y,
> + },
> IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
> };
>
> @@ -119,6 +145,16 @@ static int als_read_raw(struct iio_dev *indio_dev,
> min = als_state->als[chan->scan_index].logical_minimum;
> address = HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE;
> break;
> + case CHANNEL_SCAN_INDEX_CHROMATICITY_X:
> + report_id = als_state->als[chan->scan_index].report_id;
> + min = als_state->als[chan->scan_index].logical_minimum;
> + address = HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X;
> + break;
> + case CHANNEL_SCAN_INDEX_CHROMATICITY_Y:
> + report_id = als_state->als[chan->scan_index].report_id;
> + min = als_state->als[chan->scan_index].logical_minimum;
> + address = HID_USAGE_SENSOR_LIGHT_CHROMATICITY_Y;
> + break;
> default:
> report_id = -1;
> break;
> @@ -243,6 +279,14 @@ static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
> als_state->scan.illum[CHANNEL_SCAN_INDEX_COLOR_TEMP] = sample_data;
> ret = 0;
> break;
> + case HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X:
> + als_state->scan.illum[CHANNEL_SCAN_INDEX_CHROMATICITY_X] = sample_data;
> + ret = 0;
> + break;
> + case HID_USAGE_SENSOR_LIGHT_CHROMATICITY_Y:
> + als_state->scan.illum[CHANNEL_SCAN_INDEX_CHROMATICITY_Y] = sample_data;
> + ret = 0;
> + break;
> case HID_USAGE_SENSOR_TIME_TIMESTAMP:
> als_state->timestamp = hid_sensor_convert_timestamp(&als_state->common_attributes,
> *(s64 *)raw_data);
> @@ -303,11 +347,33 @@ static int als_parse_report(struct platform_device *pdev,
> st->als[CHANNEL_SCAN_INDEX_COLOR_TEMP].index,
> st->als[CHANNEL_SCAN_INDEX_COLOR_TEMP].report_id);
>
> +skip_temp_channel:
> + for (i = 0; i < 2; i++) {
> + int next_scan_index = CHANNEL_SCAN_INDEX_CHROMATICITY_X + i;
> +
> + ret = sensor_hub_input_get_attribute_info(hsdev,
> + HID_INPUT_REPORT, usage_id,
> + HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X + i,
> + &st->als[next_scan_index]);
> + if (ret < 0)
> + goto skip_chromaticity_channel;
> +
> + channels[index++] = als_channels[CHANNEL_SCAN_INDEX_CHROMATICITY_X + i];
> +
> + als_adjust_channel_bit_mask(channels,
> + CHANNEL_SCAN_INDEX_CHROMATICITY_X + i,
> + st->als[next_scan_index].size);
> +
> + dev_dbg(&pdev->dev, "als %x:%x\n",
> + st->als[next_scan_index].index,
> + st->als[next_scan_index].report_id);
> + }
> +
> st->scale_precision = hid_sensor_format_scale(usage_id,
> &st->als[CHANNEL_SCAN_INDEX_INTENSITY],
> &st->scale_pre_decml, &st->scale_post_decml);
>
> -skip_temp_channel:
> +skip_chromaticity_channel:
> *channels_out = channels;
> *size_channels_out = index;
>
> diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
> index 8af4fb3e0254..6730ee900ee1 100644
> --- a/include/linux/hid-sensor-ids.h
> +++ b/include/linux/hid-sensor-ids.h
> @@ -22,6 +22,9 @@
> #define HID_USAGE_SENSOR_DATA_LIGHT 0x2004d0
> #define HID_USAGE_SENSOR_LIGHT_ILLUM 0x2004d1
> #define HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE 0x2004d2
> +#define HID_USAGE_SENSOR_LIGHT_CHROMATICITY 0x2004d3
> +#define HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X 0x2004d4
> +#define HID_USAGE_SENSOR_LIGHT_CHROMATICITY_Y 0x2004d5
>
> /* PROX (200011) */
> #define HID_USAGE_SENSOR_PROX 0x200011
^ permalink raw reply
* Re: [PATCH v2 1/3] iio: hid-sensor-als: Allocate channels dynamically
From: Jonathan Cameron @ 2023-12-20 15:24 UTC (permalink / raw)
To: Srinivas Pandruvada
Cc: jikos, lars, Basavaraj.Natikar, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20231218203026.1156375-2-srinivas.pandruvada@linux.intel.com>
On Mon, 18 Dec 2023 12:30:24 -0800
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> Instead of assuming that every channel defined statically by
> als_channels[] is present, allocate dynamically based on presence of the
> respective usage id in the descriptor. This will allow to register ALS
> with limited channel support. Append the timestamp as the last channel.
>
> There is no intentional function changes done.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Hi Srinivas,
No huge rush on this as I'll not have the revert in my upstream now
until after the merge window + may not have a chance for a second pull
request anyway.
A few comments inline,
Jonathan
> ---
> v2:
> New change
>
> drivers/iio/light/hid-sensor-als.c | 57 ++++++++++++++++++------------
> 1 file changed, 35 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index 5cd27f04b45e..e57ad1946b56 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
> @@ -236,14 +236,21 @@ static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
>
> /* Parse report which is specific to an usage id*/
> static int als_parse_report(struct platform_device *pdev,
> - struct hid_sensor_hub_device *hsdev,
> - struct iio_chan_spec *channels,
> - unsigned usage_id,
> - struct als_state *st)
> + struct hid_sensor_hub_device *hsdev,
> + struct iio_chan_spec **channels_out,
> + int *size_channels_out,
> + unsigned int usage_id,
> + struct als_state *st)
Align with opening bracket. Also, try in general to avoid white space changes
when changing anything else. It would be easier to see what actually changed
here without that.
> {
> - int ret;
> + struct iio_chan_spec *channels;
> + int ret, index = 0;
> int i;
>
> + channels = devm_kcalloc(&pdev->dev, ARRAY_SIZE(als_channels),
> + sizeof(als_channels), GFP_KERNEL);
Given it's a fixed size (which is fine even though you might not use it
all), can you just make it part of the iio_priv() structure
and avoid need for handling the allocation here?
> + if (!channels)
> + return -ENOMEM;
> +
> for (i = 0; i <= CHANNEL_SCAN_INDEX_ILLUM; ++i) {
> ret = sensor_hub_input_get_attribute_info(hsdev,
> HID_INPUT_REPORT,
> @@ -251,9 +258,11 @@ static int als_parse_report(struct platform_device *pdev,
> HID_USAGE_SENSOR_LIGHT_ILLUM,
> &st->als[i]);
> if (ret < 0)
> - return ret;
> - als_adjust_channel_bit_mask(channels, i, st->als[i].size);
> + break;
>
> + channels[i] = als_channels[i];
channels[index] = als_channels[i]? Might be gaps. What you currently have
only works if the 'present channels' are all at the start.
> + als_adjust_channel_bit_mask(channels, i, st->als[i].size);
Would use index not i.
> + ++index;
> dev_dbg(&pdev->dev, "als %x:%x\n", st->als[i].index,
> st->als[i].report_id);
> }
> @@ -262,17 +271,24 @@ static int als_parse_report(struct platform_device *pdev,
> &st->als[CHANNEL_SCAN_INDEX_INTENSITY],
> &st->scale_pre_decml, &st->scale_post_decml);
>
> - return ret;
> + *channels_out = channels;
> + *size_channels_out = index;
> +
> + if (!index)
> + ret = -ENODEV;
> +
> + return 0;
> }
>
> /* Function to initialize the processing for usage id */
> static int hid_als_probe(struct platform_device *pdev)
> {
> - int ret = 0;
> + int ret = 0, max_channel_index;
> static const char *name = "als";
> struct iio_dev *indio_dev;
> struct als_state *als_state;
> struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> + struct iio_chan_spec *channels;
>
> indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(struct als_state));
> if (!indio_dev)
> @@ -293,24 +309,21 @@ static int hid_als_probe(struct platform_device *pdev)
> return ret;
> }
>
> - indio_dev->channels = devm_kmemdup(&pdev->dev, als_channels,
> - sizeof(als_channels), GFP_KERNEL);
> - if (!indio_dev->channels) {
> - dev_err(&pdev->dev, "failed to duplicate channels\n");
> - return -ENOMEM;
> - }
> -
> - ret = als_parse_report(pdev, hsdev,
> - (struct iio_chan_spec *)indio_dev->channels,
> - hsdev->usage,
> - als_state);
> + ret = als_parse_report(pdev, hsdev, &channels, &max_channel_index,
> + hsdev->usage, als_state);
> if (ret) {
> dev_err(&pdev->dev, "failed to setup attributes\n");
> return ret;
> }
>
> - indio_dev->num_channels =
> - ARRAY_SIZE(als_channels);
> + /* Add timestamp channel */
> + channels[max_channel_index] = als_channels[CHANNEL_SCAN_INDEX_TIMESTAMP];
> + channels[max_channel_index].scan_index = max_channel_index;
> +
> + /* +1 for adding timestamp channel */
> + indio_dev->num_channels = max_channel_index + 1;
> +
> + indio_dev->channels = channels;
> indio_dev->info = &als_info;
> indio_dev->name = name;
> indio_dev->modes = INDIO_DIRECT_MODE;
^ permalink raw reply
* Re: [PATCH] HID: sensor-hub: Enable hid core report processing for all devices
From: Yauhen Kharuzhy @ 2023-12-20 15:04 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-input, linux-iio, Daniel Thompson, linux-kernel,
Jiri Kosina, Srinivas Pandruvada, Benjamin Tissoires
In-Reply-To: <20231220145229.020abe62@jic23-huawei>
ср, 20 дек. 2023 г. в 16:52, Jonathan Cameron <jic23@kernel.org>:
>
> On Wed, 20 Dec 2023 01:15:03 +0200
> Yauhen Kharuzhy <jekhor@gmail.com> wrote:
>
> > After the commit 666cf30a589a ("HID: sensor-hub: Allow multi-function
> > sensor devices") hub devices are claimed by hidraw driver in hid_connect().
> > This causes stoppping of processing HID reports by hid core due to
> > optimization.
> >
> > In such case, the hid-sensor-custom driver cannot match a known custom
> > sensor in hid_sensor_custom_get_known() because it try to check custom
> > properties which weren't filled from the report because hid core didn't
> > parsed it.
> >
> > As result, custom sensors like hinge angle sensor and LISS sensors
> > don't work.
> >
> > Mark the sensor hub devices claimed by some driver to avoid hidraw-related
> > optimizations.
> >
> > Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> Fixes tag?
Fixes: 666cf30a589a ("HID: sensor-hub: Allow multi-function sensor devices")
>
> > ---
> > drivers/hid/hid-sensor-hub.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> > index 2eba152e8b90..26e93a331a51 100644
> > --- a/drivers/hid/hid-sensor-hub.c
> > +++ b/drivers/hid/hid-sensor-hub.c
> > @@ -632,7 +632,7 @@ static int sensor_hub_probe(struct hid_device *hdev,
> > }
> > INIT_LIST_HEAD(&hdev->inputs);
> >
> > - ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> > + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT | HID_CONNECT_DRIVER);
> > if (ret) {
> > hid_err(hdev, "hw start failed\n");
> > return ret;
>
--
Yauhen Kharuzhy
^ permalink raw reply
* Re: [PATCH] HID: sensor-hub: Enable hid core report processing for all devices
From: Jonathan Cameron @ 2023-12-20 14:52 UTC (permalink / raw)
To: Yauhen Kharuzhy
Cc: linux-input, linux-iio, Daniel Thompson, linux-kernel,
Jiri Kosina, Srinivas Pandruvada, Benjamin Tissoires
In-Reply-To: <20231219231503.1506801-1-jekhor@gmail.com>
On Wed, 20 Dec 2023 01:15:03 +0200
Yauhen Kharuzhy <jekhor@gmail.com> wrote:
> After the commit 666cf30a589a ("HID: sensor-hub: Allow multi-function
> sensor devices") hub devices are claimed by hidraw driver in hid_connect().
> This causes stoppping of processing HID reports by hid core due to
> optimization.
>
> In such case, the hid-sensor-custom driver cannot match a known custom
> sensor in hid_sensor_custom_get_known() because it try to check custom
> properties which weren't filled from the report because hid core didn't
> parsed it.
>
> As result, custom sensors like hinge angle sensor and LISS sensors
> don't work.
>
> Mark the sensor hub devices claimed by some driver to avoid hidraw-related
> optimizations.
>
> Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
Fixes tag?
> ---
> drivers/hid/hid-sensor-hub.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index 2eba152e8b90..26e93a331a51 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -632,7 +632,7 @@ static int sensor_hub_probe(struct hid_device *hdev,
> }
> INIT_LIST_HEAD(&hdev->inputs);
>
> - ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT | HID_CONNECT_DRIVER);
> if (ret) {
> hid_err(hdev, "hw start failed\n");
> return ret;
^ permalink raw reply
* Re: [PATCH] input: uinput: Drop checks for abs_min > abs_max
From: Paul Cercueil @ 2023-12-20 13:39 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Peter Hutterer, Chris Morgan, linux-input, svv, biswarupp,
contact, Chris Morgan
In-Reply-To: <ZYJJC-ID4SyHhuuA@google.com>
Hi Dmitry,
Le mardi 19 décembre 2023 à 17:53 -0800, Dmitry Torokhov a écrit :
> Hi Paul,
>
> On Wed, Dec 20, 2023 at 01:38:39AM +0100, Paul Cercueil wrote:
> > Hi Peter,
> >
> > Le mercredi 20 décembre 2023 à 09:51 +1000, Peter Hutterer a
> > écrit :
> > > On Mon, Dec 18, 2023 at 11:16:53AM -0600, Chris Morgan wrote:
> > > > From: Chris Morgan <macromorgan@hotmail.com>
> > > >
> > > > Stop checking if the minimum abs value is greater than the
> > > > maximum
> > > > abs
> > > > value. When the axis is inverted this condition is allowed.
> > > > Without
> > > > relaxing this check, it is not possible to use uinput on
> > > > devices in
> > > > userspace with an inverted axis, such as the adc-joystick found
> > > > on
> > > > many handheld gaming devices.
> > >
> > > As mentioned in the other thread [1] a fair bit of userspace
> > > relies
> > > on
> > > that general assumption so removing it will likely cause all
> > > sorts of
> > > issues.
> >
> > There is some userspace that works with it though, so why restrict
> > it
> > artificially?
> >
> > The fact that some other userspace code wouldn't work with it
> > sounds a
> > bit irrelevant. They just never encountered that min>max usage
> > before.
> >
> > And removing this check won't cause all sort of issues, why would
> > it?
> > It's not like the current software actively probes min>max and
> > crash
> > badly if it doesn't return -EINVAL...
>
> It will cause weird movements because calculations expect min be the
> minimum, and max the maximum, and not encode left/right or up/down.
> Putting this into adc joystick binding was a mistake.
I don't see why it was a mistake, it's only one of the ways to specify
that the axis is inverted. This information is between the firmware
(DT) and the kernel, that doesn't mean the information has to be
relayed as-is to the userspace.
Unlike what you wrote in your other answer, when talking about input
the kernel doesn't really normalize anything - it gives you the min/max
values, and the raw samples, not normalized samples (they don't get
translated to a pre-specified range, or even clamped).
I don't really like the idea of having the driver tamper with the
samples, but if the specification really is that max>min, then it would
be up to evdev/joydev (if the individual drivers are allowed min>max)
or adc-joystick (if they are not) to process the samples.
Cheers,
-Paul
> This is the definition of absinfo:
>
> /**
> * struct input_absinfo - used by EVIOCGABS/EVIOCSABS ioctls
> * @value: latest reported value for the axis.
> * @minimum: specifies minimum value for the axis.
> * @maximum: specifies maximum value for the axis.
> * @fuzz: specifies fuzz value that is used to filter noise from
> * the event stream.
> * @flat: values that are within this value will be discarded by
> * joydev interface and reported as 0 instead.
> * @resolution: specifies resolution for the values reported for
> * the axis.
> *
> * Note that input core does not clamp reported values to the
> * [minimum, maximum] limits, such task is left to userspace.
> ...
> */
>
> (We should change wording of the last sentence to "... does not
> always
> clamp ..." since when we do inversion/swap we do clamp values.)
>
> And note that the userspace that can handle swapped min and max will
> work fine if the kernel provides normalized data, but other software
> will/may not work.
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH v3 6/6] x86/vmware: Add TDX hypercall support
From: kernel test robot @ 2023-12-20 13:09 UTC (permalink / raw)
To: Alexey Makhalov, linux-kernel, virtualization, bp, hpa,
dave.hansen, mingo, tglx
Cc: llvm, oe-kbuild-all, dmitry.torokhov, tzimmermann, pv-drivers,
netdev, richardcochran, x86, dri-devel, horms, akaher, timothym,
linux-graphics-maintainer, mripard, jsipek, linux-input, namit,
kirill.shutemov, airlied, zackr
In-Reply-To: <20231219215751.9445-7-alexey.makhalov@broadcom.com>
Hi Alexey,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on dtor-input/next dtor-input/for-linus linus/master v6.7-rc6 next-20231220]
[cannot apply to tip/x86/vmware]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Alexey-Makhalov/x86-vmware-Move-common-macros-to-vmware-h/20231220-060028
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/r/20231219215751.9445-7-alexey.makhalov%40broadcom.com
patch subject: [PATCH v3 6/6] x86/vmware: Add TDX hypercall support
config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20231220/202312202020.5O1T2aSk-lkp@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231220/202312202020.5O1T2aSk-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312202020.5O1T2aSk-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> arch/x86/kernel/cpu/vmware.c:439:40: warning: format specifies type 'unsigned int' but the argument has type 'unsigned long' [-Wformat]
pr_warn("Out of range command %x\n", cmd);
~~ ^~~
%lx
include/linux/printk.h:508:37: note: expanded from macro 'pr_warn'
printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~~~~~~~~~
include/linux/printk.h:455:60: note: expanded from macro 'printk'
#define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
~~~ ^~~~~~~~~~~
include/linux/printk.h:427:19: note: expanded from macro 'printk_index_wrap'
_p_func(_fmt, ##__VA_ARGS__); \
~~~~ ^~~~~~~~~~~
1 warning generated.
vim +439 arch/x86/kernel/cpu/vmware.c
430
431 #ifdef CONFIG_INTEL_TDX_GUEST
432 unsigned long vmware_tdx_hypercall(unsigned long cmd,
433 struct tdx_module_args *args)
434 {
435 if (!hypervisor_is_type(X86_HYPER_VMWARE))
436 return 0;
437
438 if (cmd & ~VMWARE_CMD_MASK) {
> 439 pr_warn("Out of range command %x\n", cmd);
440 return 0;
441 }
442
443 args->r10 = VMWARE_TDX_VENDOR_LEAF;
444 args->r11 = VMWARE_TDX_HCALL_FUNC;
445 args->r12 = VMWARE_HYPERVISOR_MAGIC;
446 args->r13 = cmd;
447
448 __tdx_hypercall(args);
449
450 return args->r12;
451 }
452 EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
453 #endif
454
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/3] HID: make ishtp_cl_bus_type const
From: srinivas pandruvada @ 2023-12-20 12:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, jikos, benjamin.tissoires; +Cc: linux-kernel, linux-input
In-Reply-To: <2023122048-tribute-quote-1b4d@gregkh>
On Wed, 2023-12-20 at 08:38 +0100, Greg Kroah-Hartman wrote:
> Now that the driver core can properly handle constant struct
> bus_type,
> move the ishtp_cl_bus_type variable to be a constant structure as
> well,
> placing it into read-only memory which can not be modified at
> runtime.
>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: linux-input@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c
> b/drivers/hid/intel-ish-hid/ishtp/bus.c
> index 7fc738a22375..aa6cb033bb06 100644
> --- a/drivers/hid/intel-ish-hid/ishtp/bus.c
> +++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
> @@ -378,7 +378,7 @@ static const struct dev_pm_ops
> ishtp_cl_bus_dev_pm_ops = {
> .restore = ishtp_cl_device_resume,
> };
>
> -static struct bus_type ishtp_cl_bus_type = {
> +static const struct bus_type ishtp_cl_bus_type = {
> .name = "ishtp",
> .dev_groups = ishtp_cl_dev_groups,
> .probe = ishtp_cl_device_probe,
^ permalink raw reply
* [PATCH v6 3/4] dt-bindings: input: touchscreen: st1232: add touch-overlay example
From: Javier Carrasco @ 2023-12-20 8:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
In-Reply-To: <20230510-feature-ts_virtobj_patch-v6-0-d8a605975153@wolfvision.net>
The touch-overaly feature adds support for segments (touch areas) on the
touchscreen surface that represent overlays with clipped touchscreen
areas and printed buttons.
Add nodes for a clipped touchscreen and overlay buttons to the existing
example.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
.../input/touchscreen/sitronix,st1232.yaml | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
index 1d8ca19fd37a..e7ee7a0d74c4 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
@@ -37,6 +37,7 @@ unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/input/linux-event-codes.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -46,5 +47,33 @@ examples:
reg = <0x55>;
interrupts = <2 0>;
gpios = <&gpio1 166 0>;
+
+ touch-overlay {
+ segment-0 {
+ label = "Touchscreen";
+ x-origin = <0>;
+ x-size = <240>;
+ y-origin = <40>;
+ y-size = <280>;
+ };
+
+ segment-1a {
+ label = "Camera light";
+ linux,code = <KEY_LIGHTS_TOGGLE>;
+ x-origin = <40>;
+ x-size = <40>;
+ y-origin = <0>;
+ y-size = <40>;
+ };
+
+ segment-2a {
+ label = "Power";
+ linux,code = <KEY_POWER>;
+ x-origin = <160>;
+ x-size = <40>;
+ y-origin = <0>;
+ y-size = <40>;
+ };
+ };
};
};
--
2.39.2
^ permalink raw reply related
* [PATCH v6 4/4] Input: st1232 - add touch overlays handling
From: Javier Carrasco @ 2023-12-20 8:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
In-Reply-To: <20230510-feature-ts_virtobj_patch-v6-0-d8a605975153@wolfvision.net>
Use touch-overlay to support overlay objects such as buttons and a resized
frame defined in the device tree.
If buttons are provided, register an additional device to report key
events separately. A key event will be generated if the coordinates
of a touch event are within the area defined by the button properties.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
drivers/input/touchscreen/st1232.c | 71 ++++++++++++++++++++++++++++++--------
1 file changed, 57 insertions(+), 14 deletions(-)
diff --git a/drivers/input/touchscreen/st1232.c b/drivers/input/touchscreen/st1232.c
index 6475084aee1b..5684cf04bfa1 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -22,6 +22,7 @@
#include <linux/pm_qos.h>
#include <linux/slab.h>
#include <linux/types.h>
+#include <linux/input/touch-overlay.h>
#define ST1232_TS_NAME "st1232-ts"
#define ST1633_TS_NAME "st1633-ts"
@@ -56,7 +57,9 @@ struct st1232_ts_data {
struct touchscreen_properties prop;
struct dev_pm_qos_request low_latency_req;
struct gpio_desc *reset_gpio;
+ struct input_dev *overlay_keypad;
const struct st_chip_info *chip_info;
+ struct list_head touch_overlay_list;
int read_buf_len;
u8 *read_buf;
};
@@ -130,6 +133,7 @@ static int st1232_ts_read_resolution(struct st1232_ts_data *ts, u16 *max_x,
static int st1232_ts_parse_and_report(struct st1232_ts_data *ts)
{
struct input_dev *input = ts->input_dev;
+ struct input_dev *keypad = ts->overlay_keypad;
struct input_mt_pos pos[ST_TS_MAX_FINGERS];
u8 z[ST_TS_MAX_FINGERS];
int slots[ST_TS_MAX_FINGERS];
@@ -138,14 +142,20 @@ static int st1232_ts_parse_and_report(struct st1232_ts_data *ts)
for (i = 0; i < ts->chip_info->max_fingers; i++) {
u8 *buf = &ts->read_buf[i * 4];
+ bool contact = buf[0] & BIT(7);
+ unsigned int x, y;
- if (buf[0] & BIT(7)) {
- unsigned int x = ((buf[0] & 0x70) << 4) | buf[1];
- unsigned int y = ((buf[0] & 0x07) << 8) | buf[2];
-
- touchscreen_set_mt_pos(&pos[n_contacts],
- &ts->prop, x, y);
+ if (contact) {
+ x = ((buf[0] & 0x70) << 4) | buf[1];
+ y = ((buf[0] & 0x07) << 8) | buf[2];
+ }
+ if (touch_overlay_process_event(&ts->touch_overlay_list, keypad,
+ contact ? &x : NULL,
+ contact ? &y : NULL, i))
+ continue;
+ if (contact) {
+ touchscreen_set_mt_pos(&pos[n_contacts], &ts->prop, x, y);
/* st1232 includes a z-axis / touch strength */
if (ts->chip_info->have_z)
z[n_contacts] = ts->read_buf[i + 6];
@@ -226,6 +236,7 @@ static int st1232_ts_probe(struct i2c_client *client)
const struct st_chip_info *match;
struct st1232_ts_data *ts;
struct input_dev *input_dev;
+ struct input_dev *overlay_keypad;
u16 max_x, max_y;
int error;
@@ -263,8 +274,13 @@ static int st1232_ts_probe(struct i2c_client *client)
if (!input_dev)
return -ENOMEM;
+ overlay_keypad = devm_input_allocate_device(&client->dev);
+ if (!overlay_keypad)
+ return -ENOMEM;
+
ts->client = client;
ts->input_dev = input_dev;
+ ts->overlay_keypad = overlay_keypad;
ts->reset_gpio = devm_gpiod_get_optional(&client->dev, NULL,
GPIOD_OUT_HIGH);
@@ -286,24 +302,38 @@ static int st1232_ts_probe(struct i2c_client *client)
input_dev->name = "st1232-touchscreen";
input_dev->id.bustype = BUS_I2C;
+ overlay_keypad->name = "st1232-keypad";
+ overlay_keypad->id.bustype = BUS_I2C;
/* Wait until device is ready */
error = st1232_ts_wait_ready(ts);
if (error)
return error;
- /* Read resolution from the chip */
- error = st1232_ts_read_resolution(ts, &max_x, &max_y);
- if (error) {
- dev_err(&client->dev,
- "Failed to read resolution: %d\n", error);
- return error;
- }
-
if (ts->chip_info->have_z)
input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0,
ts->chip_info->max_area, 0, 0);
+ /* map overlay objects if defined in the device tree */
+ INIT_LIST_HEAD(&ts->touch_overlay_list);
+ error = touch_overlay_map(&ts->touch_overlay_list, ts->overlay_keypad);
+ if (error)
+ return error;
+
+ if (touch_overlay_mapped_touchscreen(&ts->touch_overlay_list)) {
+ /* Read resolution from the overlay touchscreen if defined */
+ touch_overlay_get_touchscreen_abs(&ts->touch_overlay_list,
+ &max_x, &max_y);
+ } else {
+ /* Read resolution from the chip */
+ error = st1232_ts_read_resolution(ts, &max_x, &max_y);
+ if (error) {
+ dev_err(&client->dev,
+ "Failed to read resolution: %d\n", error);
+ return error;
+ }
+ }
+
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
0, max_x, 0, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
@@ -335,6 +365,19 @@ static int st1232_ts_probe(struct i2c_client *client)
return error;
}
+ /* Register keypad input device if overlay buttons were defined */
+ if (touch_overlay_mapped_buttons(&ts->touch_overlay_list)) {
+ error = input_register_device(ts->overlay_keypad);
+ if (error) {
+ dev_err(&client->dev,
+ "Unable to register %s input device\n",
+ overlay_keypad->name);
+ return error;
+ }
+ } else {
+ input_free_device(ts->overlay_keypad);
+ }
+
i2c_set_clientdata(client, ts);
return 0;
--
2.39.2
^ permalink raw reply related
* [PATCH v6 2/4] Input: touch-overlay - Add touchscreen overlay handling
From: Javier Carrasco @ 2023-12-20 8:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
In-Reply-To: <20230510-feature-ts_virtobj_patch-v6-0-d8a605975153@wolfvision.net>
Some touch devices provide mechanical overlays with different objects
like buttons or clipped touchscreen surfaces.
In order to support these objects, add a series of helper functions
to the input subsystem to transform them into overlay objects via
device tree nodes.
These overlay objects consume the raw touch events and report the
expected input events depending on the object properties.
Note that the current implementation allows for multiple definitions
of touchscreen areas (regions that report touch events), but only the
first one will be used for the touchscreen device that the consumers
typically provide.
Should the need for multiple touchscreen areas arise, additional
touchscreen devices would be required at the consumer side.
There is no limitation in the number of touch areas defined as buttons.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
MAINTAINERS | 7 +
drivers/input/Makefile | 2 +-
drivers/input/touch-overlay.c | 283 ++++++++++++++++++++++++++++++++++++
include/linux/input/touch-overlay.h | 24 +++
4 files changed, 315 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 97f51d5ec1cf..3218d8694735 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22031,6 +22031,13 @@ L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/platform/x86/toshiba-wmi.c
+TOUCH OVERLAY
+M: Javier Carrasco <javier.carrasco@wolfvision.net>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: drivers/input/touch-overlay.c
+F: include/linux/input/touch-overlay.h
+
TPM DEVICE DRIVER
M: Peter Huewe <peterhuewe@gmx.de>
M: Jarkko Sakkinen <jarkko@kernel.org>
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index c78753274921..393e9f4d00dc 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -7,7 +7,7 @@
obj-$(CONFIG_INPUT) += input-core.o
input-core-y := input.o input-compat.o input-mt.o input-poller.o ff-core.o
-input-core-y += touchscreen.o
+input-core-y += touchscreen.o touch-overlay.o
obj-$(CONFIG_INPUT_FF_MEMLESS) += ff-memless.o
obj-$(CONFIG_INPUT_SPARSEKMAP) += sparse-keymap.o
diff --git a/drivers/input/touch-overlay.c b/drivers/input/touch-overlay.c
new file mode 100644
index 000000000000..0a0646ceb755
--- /dev/null
+++ b/drivers/input/touch-overlay.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Helper functions for overlay objects on touchscreens
+ *
+ * Copyright (c) 2023 Javier Carrasco <javier.carrasco@wolfvision.net>
+ */
+
+#include <linux/input.h>
+#include <linux/input/mt.h>
+#include <linux/input/touch-overlay.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/property.h>
+
+struct button {
+ u32 key;
+ bool pressed;
+ int slot;
+};
+
+struct touch_overlay_segment {
+ struct list_head list;
+ u32 x_origin;
+ u32 y_origin;
+ u32 x_size;
+ u32 y_size;
+ struct button *btn;
+};
+
+static int touch_overlay_get_segment(struct fwnode_handle *segment_node,
+ struct touch_overlay_segment *segment,
+ struct input_dev *keypad,
+ struct device *dev)
+{
+ int error;
+
+ error = fwnode_property_read_u32(segment_node, "x-origin",
+ &segment->x_origin);
+ if (error)
+ return error;
+
+ error = fwnode_property_read_u32(segment_node, "y-origin",
+ &segment->y_origin);
+ if (error)
+ return error;
+
+ error = fwnode_property_read_u32(segment_node, "x-size",
+ &segment->x_size);
+ if (error)
+ return error;
+
+ error = fwnode_property_read_u32(segment_node, "y-size",
+ &segment->y_size);
+ if (error)
+ return error;
+
+ if (fwnode_property_present(segment_node, "linux,code")) {
+ segment->btn = devm_kzalloc(dev, sizeof(*segment->btn),
+ GFP_KERNEL);
+ if (!segment->btn)
+ return -ENOMEM;
+
+ error = fwnode_property_read_u32(segment_node, "linux,code",
+ &segment->btn->key);
+ if (error)
+ return error;
+
+ input_set_capability(keypad, EV_KEY, segment->btn->key);
+ }
+
+ return 0;
+}
+
+/**
+ * touch_overlay_map - map overlay objects from the device tree and set
+ * key capabilities if buttons are defined.
+ * @list: pointer to the list that will hold the segments
+ * @keypad: pointer to the already allocated input_dev
+ *
+ * Returns 0 on success and error number otherwise.
+ *
+ * If a keypad input device is provided and overlay buttons are defined,
+ * its button capabilities are set accordingly.
+ */
+int touch_overlay_map(struct list_head *list, struct input_dev *keypad)
+{
+ struct fwnode_handle *overlay, *fw_segment;
+ struct device *dev = keypad->dev.parent;
+ struct touch_overlay_segment *segment;
+ int error;
+
+ overlay = device_get_named_child_node(dev, "touch-overlay");
+ if (!overlay)
+ return 0;
+
+ fwnode_for_each_child_node(overlay, fw_segment) {
+ segment = devm_kzalloc(dev, sizeof(*segment), GFP_KERNEL);
+ if (!segment) {
+ error = -ENOMEM;
+ goto put_overlay;
+ }
+ error = touch_overlay_get_segment(fw_segment, segment, keypad,
+ dev);
+ if (error)
+ goto put_overlay;
+
+ list_add_tail(&segment->list, list);
+ }
+
+put_overlay:
+ fwnode_handle_put(overlay);
+ return error;
+}
+EXPORT_SYMBOL(touch_overlay_map);
+
+/**
+ * touch_overlay_get_touchscreen_abs - get abs size from the touchscreen area.
+ * @list: pointer to the list that holds the segments
+ * @x: horizontal abs
+ * @y: vertical abs
+ */
+void touch_overlay_get_touchscreen_abs(struct list_head *list, u16 *x, u16 *y)
+{
+ struct touch_overlay_segment *segment;
+ struct list_head *ptr;
+
+ list_for_each(ptr, list) {
+ segment = list_entry(ptr, struct touch_overlay_segment, list);
+ if (!segment->btn) {
+ *x = segment->x_size - 1;
+ *y = segment->y_size - 1;
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(touch_overlay_get_touchscreen_abs);
+
+static bool touch_overlay_segment_event(struct touch_overlay_segment *seg,
+ u32 x, u32 y)
+{
+ if (!seg)
+ return false;
+
+ if (x >= seg->x_origin && x < (seg->x_origin + seg->x_size) &&
+ y >= seg->y_origin && y < (seg->y_origin + seg->y_size))
+ return true;
+
+ return false;
+}
+
+/**
+ * touch_overlay_mapped_touchscreen - check if a touchscreen area is mapped
+ * @list: pointer to the list that holds the segments
+ *
+ * Returns true if a touchscreen area is mapped or false otherwise.
+ */
+bool touch_overlay_mapped_touchscreen(struct list_head *list)
+{
+ struct touch_overlay_segment *segment;
+ struct list_head *ptr;
+
+ list_for_each(ptr, list) {
+ segment = list_entry(ptr, struct touch_overlay_segment, list);
+ if (!segment->btn)
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(touch_overlay_mapped_touchscreen);
+
+/**
+ * touch_overlay_mapped_buttons - check if overlay buttons are mapped
+ * @list: pointer to the list that holds the segments
+ *
+ * Returns true if overlay buttons mapped or false otherwise.
+ */
+bool touch_overlay_mapped_buttons(struct list_head *list)
+{
+ struct touch_overlay_segment *segment;
+ struct list_head *ptr;
+
+ list_for_each(ptr, list) {
+ segment = list_entry(ptr, struct touch_overlay_segment, list);
+ if (segment->btn)
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(touch_overlay_mapped_buttons);
+
+static bool touch_overlay_mt_on_touchscreen(struct list_head *list,
+ u32 *x, u32 *y)
+{
+ struct touch_overlay_segment *segment;
+ bool contact = x && y;
+ struct list_head *ptr;
+
+ /* Let the caller handle events with no coordinates (release) */
+ if (!contact)
+ return false;
+
+ list_for_each(ptr, list) {
+ segment = list_entry(ptr, struct touch_overlay_segment, list);
+ if (!segment->btn &&
+ touch_overlay_segment_event(segment, *x, *y)) {
+ *x -= segment->x_origin;
+ *y -= segment->y_origin;
+ return true;
+ }
+ }
+
+ return false;
+}
+
+static bool touch_overlay_button_event(struct input_dev *input,
+ struct touch_overlay_segment *segment,
+ const u32 *x, const u32 *y, u32 slot)
+{
+ bool contact = x && y;
+
+ if (!contact && segment->btn->pressed && segment->btn->slot == slot) {
+ segment->btn->pressed = false;
+ input_report_key(input, segment->btn->key, false);
+ input_sync(input);
+ return true;
+ } else if (contact && touch_overlay_segment_event(segment, *x, *y)) {
+ segment->btn->pressed = true;
+ segment->btn->slot = slot;
+ input_report_key(input, segment->btn->key, true);
+ input_sync(input);
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * touch_overlay_process_event - process input events according to the overlay
+ * mapping. This function acts as a filter to release the calling driver from
+ * the events that are either related to overlay buttons or out of the overlay
+ * touchscreen area if defined.
+ * @list: pointer to the list that holds the segments
+ * @input: pointer to the input device associated to the event
+ * @x: pointer to the x coordinate (NULL if not available - no contact)
+ * @y: pointer to the y coordinate (NULL if not available - no contact)
+ * @slot: slot associated to the event
+ *
+ * Returns true if the event was processed (reported for valid key events
+ * and dropped for events outside the overlay touchscreen area) or false
+ * if the event must be processed by the caller. In that case this function
+ * shifts the (x,y) coordinates to the overlay touchscreen axis if required.
+ */
+bool touch_overlay_process_event(struct list_head *list,
+ struct input_dev *input,
+ u32 *x, u32 *y, u32 slot)
+{
+ struct touch_overlay_segment *segment;
+ struct list_head *ptr;
+
+ /*
+ * buttons must be prioritized over overlay touchscreens to account for
+ * overlappings e.g. a button inside the touchscreen area.
+ */
+ list_for_each(ptr, list) {
+ segment = list_entry(ptr, struct touch_overlay_segment, list);
+ if (segment->btn &&
+ touch_overlay_button_event(input, segment, x, y, slot)) {
+ return true;
+ }
+ }
+
+ /*
+ * valid touch events on the overlay touchscreen are left for the client
+ * to be processed/reported according to its (possibly) unique features.
+ */
+ return !touch_overlay_mt_on_touchscreen(list, x, y);
+}
+EXPORT_SYMBOL(touch_overlay_process_event);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Helper functions for overlay objects on touch devices");
diff --git a/include/linux/input/touch-overlay.h b/include/linux/input/touch-overlay.h
new file mode 100644
index 000000000000..df974eb46dd4
--- /dev/null
+++ b/include/linux/input/touch-overlay.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Javier Carrasco <javier.carrasco@wolfvision.net>
+ */
+
+#ifndef _TOUCH_OVERLAY
+#define _TOUCH_OVERLAY
+
+#include <linux/types.h>
+
+struct input_dev;
+
+int touch_overlay_map(struct list_head *list, struct input_dev *keypad);
+
+void touch_overlay_get_touchscreen_abs(struct list_head *list, u16 *x, u16 *y);
+
+bool touch_overlay_mapped_touchscreen(struct list_head *list);
+
+bool touch_overlay_mapped_buttons(struct list_head *list);
+
+bool touch_overlay_process_event(struct list_head *list, struct input_dev *input,
+ u32 *x, u32 *y, u32 slot);
+
+#endif
--
2.39.2
^ permalink raw reply related
* [PATCH v6 1/4] dt-bindings: touchscreen: add touch-overlay property
From: Javier Carrasco @ 2023-12-20 8:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
In-Reply-To: <20230510-feature-ts_virtobj_patch-v6-0-d8a605975153@wolfvision.net>
The touch-overlay encompasses a number of touch areas that define a
clipped touchscreen area and/or buttons with a specific functionality.
A clipped touchscreen area avoids getting events from regions that are
physically hidden by overlay frames.
For touchscreens with printed overlay buttons, sub-nodes with a suitable
key code can be defined to report key events instead of the original
touch events.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
.../bindings/input/touchscreen/touchscreen.yaml | 119 +++++++++++++++++++++
1 file changed, 119 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
index 431c13335c40..d5ac90667bef 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
@@ -87,6 +87,125 @@ properties:
touchscreen-y-plate-ohms:
description: Resistance of the Y-plate in Ohms
+ touch-overlay:
+ description: list of nodes defining segments (touch areas) on the
+ touchscreen.
+
+ This object can be used to describe a series of segments to
+ restrict the region within touch events are reported or buttons
+ with a specific functionality.
+
+ This is of special interest if the touchscreen is shipped with a physical
+ overlay on top of it with a frame that hides some part of the original
+ touchscreen area. Printed buttons on that overlay are also a typical
+ use case.
+
+ A new touchscreen area is defined as a sub-node without a key code. If a
+ key code is defined in the sub-node, it will be interpreted as a button.
+
+ The x-origin and y-origin properties of a touchscreen area define the
+ offset of a new origin from where the touchscreen events are referenced.
+ This offset is applied to the events accordingly. The x-size and y-size
+ properties define the size of the touchscreen effective area.
+
+ The following example shows a new touchscreen area with the new origin
+ (0',0') for the touch events generated by the device.
+
+ Touchscreen (full area)
+ ┌────────────────────────────────────────┐
+ │ ┌───────────────────────────────┐ │
+ │ │ │ │
+ │ ├ y-size │ │
+ │ │ │ │
+ │ │ touchscreen area │ │
+ │ │ (no key code) │ │
+ │ │ │ │
+ │ │ x-size │ │
+ │ ┌└──────────────┴────────────────┘ │
+ │(0',0') │
+ ┌└────────────────────────────────────────┘
+ (0,0)
+
+ where (0',0') = (0+x-origin,0+y-origin)
+
+ Sub-nodes with key codes report the touch events on their surface as key
+ events instead.
+
+ The following example shows a touchscreen with a single button on it.
+
+ Touchscreen (full area)
+ ┌───────────────────────────────────┐
+ │ │
+ │ │
+ │ ┌─────────┐ │
+ │ │button 0 │ │
+ │ │KEY_POWER│ │
+ │ └─────────┘ │
+ │ │
+ │ │
+ ┌└───────────────────────────────────┘
+ (0,0)
+
+ Segments defining buttons and clipped toushcreen areas can be combined
+ as shown in the following example.
+ In that case only the events within the touchscreen area are reported
+ as touch events. Events within the button areas report their associated
+ key code. Any events outside the defined areas are ignored.
+
+ Touchscreen (full area)
+ ┌─────────┬──────────────────────────────┐
+ │ │ │
+ │ │ ┌───────────────────────┐ │
+ │ button 0│ │ │ │
+ │KEY_POWER│ │ │ │
+ │ │ │ │ │
+ ├─────────┤ │ touchscreen area │ │
+ │ │ │ (no key code) │ │
+ │ │ │ │ │
+ │ button 1│ │ │ │
+ │ KEY_INFO│ ┌└───────────────────────┘ │
+ │ │(0',0') │
+ ┌└─────────┴──────────────────────────────┘
+ (0,0)
+
+ type: object
+
+ patternProperties:
+ '^segment-':
+ type: object
+ description:
+ Each segment is represented as a sub-node.
+ properties:
+ x-origin:
+ description: horizontal origin of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-origin:
+ description: vertical origin of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ x-size:
+ description: horizontal resolution of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-size:
+ description: vertical resolution of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ label:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: descriptive name of the button
+
+ linux,code: true
+
+ required:
+ - x-origin
+ - y-origin
+ - x-size
+ - y-size
+
+ unevaluatedProperties: false
+
dependencies:
touchscreen-size-x: [ touchscreen-size-y ]
touchscreen-size-y: [ touchscreen-size-x ]
--
2.39.2
^ permalink raw reply related
* [PATCH v6 0/4] Input: support overlay objects on touchscreens
From: Javier Carrasco @ 2023-12-20 8:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
Some touchscreens are shipped with a physical layer on top of them where
a number of buttons and a resized touchscreen surface might be available.
In order to generate proper key events by overlay buttons and adjust the
touch events to a clipped surface, this series offers a documented,
device-tree-based solution by means of helper functions.
An implementation for a specific touchscreen driver is also included.
The functions in touch-overlay provide a simple workflow to acquire
physical objects from the device tree, map them into a list and generate
events according to the object descriptions.
This feature has been tested with a JT240MHQS-E3 display, which consists
of an st1624 as the base touchscreen and an overlay with two buttons and
a frame that clips its effective surface mounted on it.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
Changes in v6:
- General: use a single list to manage a single type of object.
- General: swap patches to have bindings preceding the code.
- touch-overlay.c: minor code-sytle fixes.
- Link to v5: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v5-0-ff6b5c4db693@wolfvision.net
Changes in v5:
- touchscreen bindings: move overlay common properties to a $def entry (Rob Herring)
- st1232 bindings: move overlays to the existing example instead of
making a new one (Rob Herring)
- Link to v4: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v4-0-5c6c0fc1eed6@wolfvision.net
Changes in v4:
- General: rename "touchscreen" to "touch" to include other consumers.
- PATCH 1/4: move touch-overlay feature to input core.
- PATCH 1/4, 3/4: set key caps and report key events without consumer's
intervention.
- PATCH 2/4: add missing 'required' field with the required properties.
- Link to v3: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v3-0-b4fb7fc4bab7@wolfvision.net
Changes in v3:
- General: rename "virtobj" and "virtual" to "overlay"
- PATCH 1/4: Make feature bool instead of tristate (selected by
supported touchscreens)
- Link to v2: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v2-0-f68a6bfe7a0f@wolfvision.net
Changes in v2:
- PATCH 1/4: remove preprocessor directives (the module is selected by
the drivers that support the feature). Typo in the commit message.
- PATCH 2/4: more detailed documentation. Images and examples were added.
- PATCH 3/4: select ts-virtobj automatically.
- Link to v1: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v1-0-5ae5e81bc264@wolfvision.net
---
Javier Carrasco (4):
dt-bindings: touchscreen: add touch-overlay property
Input: touch-overlay - Add touchscreen overlay handling
dt-bindings: input: touchscreen: st1232: add touch-overlay example
Input: st1232 - add touch overlays handling
.../input/touchscreen/sitronix,st1232.yaml | 29 +++
.../bindings/input/touchscreen/touchscreen.yaml | 119 +++++++++
MAINTAINERS | 7 +
drivers/input/Makefile | 2 +-
drivers/input/touch-overlay.c | 283 +++++++++++++++++++++
drivers/input/touchscreen/st1232.c | 71 +++++-
include/linux/input/touch-overlay.h | 24 ++
7 files changed, 520 insertions(+), 15 deletions(-)
---
base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86
change-id: 20230510-feature-ts_virtobj_patch-e267540aae74
Best regards,
--
Javier Carrasco <javier.carrasco@wolfvision.net>
^ permalink raw reply
* [PATCH 3/3] HID: bpf: make bus_type const in struct hid_bpf_ops
From: Greg Kroah-Hartman @ 2023-12-20 7:38 UTC (permalink / raw)
To: jikos, benjamin.tissoires; +Cc: linux-kernel, Greg Kroah-Hartman, linux-input
In-Reply-To: <2023122045-pellet-eggbeater-8d2f@gregkh>
The struct bus_type pointer in hid_bpf_ops just passes the pointer to
the driver core, and the driver core can handle, and expects, a constant
pointer, so also make the pointer constant in hid_bpf_ops.
Part of the process of moving all usages of struct bus_type to be
constant to move them all to read-only memory.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/hid_bpf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/hid_bpf.h b/include/linux/hid_bpf.h
index e9afb61e6ee0..840cd254172d 100644
--- a/include/linux/hid_bpf.h
+++ b/include/linux/hid_bpf.h
@@ -115,7 +115,7 @@ struct hid_bpf_ops {
size_t len, enum hid_report_type rtype,
enum hid_class_request reqtype);
struct module *owner;
- struct bus_type *bus_type;
+ const struct bus_type *bus_type;
};
extern struct hid_bpf_ops *hid_bpf_ops;
--
2.43.0
^ permalink raw reply related
* [PATCH 1/3] HID: make hid_bus_type const
From: Greg Kroah-Hartman @ 2023-12-20 7:38 UTC (permalink / raw)
To: jikos, benjamin.tissoires; +Cc: linux-kernel, Greg Kroah-Hartman, linux-input
Now that the driver core can properly handle constant struct bus_type,
move the hid_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 2 +-
include/linux/hid.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e0181218ad85..de7a477d6665 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2749,7 +2749,7 @@ static int hid_uevent(const struct device *dev, struct kobj_uevent_env *env)
return 0;
}
-struct bus_type hid_bus_type = {
+const struct bus_type hid_bus_type = {
.name = "hid",
.dev_groups = hid_dev_groups,
.drv_groups = hid_drv_groups,
diff --git a/include/linux/hid.h b/include/linux/hid.h
index bf43f3ff6664..7c26db874ff0 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -912,7 +912,7 @@ extern bool hid_ignore(struct hid_device *);
extern int hid_add_device(struct hid_device *);
extern void hid_destroy_device(struct hid_device *);
-extern struct bus_type hid_bus_type;
+extern const struct bus_type hid_bus_type;
extern int __must_check __hid_register_driver(struct hid_driver *,
struct module *, const char *mod_name);
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] HID: make ishtp_cl_bus_type const
From: Greg Kroah-Hartman @ 2023-12-20 7:38 UTC (permalink / raw)
To: jikos, benjamin.tissoires
Cc: linux-kernel, Greg Kroah-Hartman, Srinivas Pandruvada,
linux-input
In-Reply-To: <2023122045-pellet-eggbeater-8d2f@gregkh>
Now that the driver core can properly handle constant struct bus_type,
move the ishtp_cl_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c b/drivers/hid/intel-ish-hid/ishtp/bus.c
index 7fc738a22375..aa6cb033bb06 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -378,7 +378,7 @@ static const struct dev_pm_ops ishtp_cl_bus_dev_pm_ops = {
.restore = ishtp_cl_device_resume,
};
-static struct bus_type ishtp_cl_bus_type = {
+static const struct bus_type ishtp_cl_bus_type = {
.name = "ishtp",
.dev_groups = ishtp_cl_dev_groups,
.probe = ishtp_cl_device_probe,
--
2.43.0
^ permalink raw reply related
* [PATCH 3/3] HID: amd_sfh: Add a new interface for exporting ALS data
From: Basavaraj Natikar @ 2023-12-20 7:00 UTC (permalink / raw)
To: jikos, benjamin.tissoires, hdegoede, ilpo.jarvinen,
mario.limonciello, Shyam-sundar.S-k, linux-input
Cc: Basavaraj Natikar
In-Reply-To: <20231220070042.610455-1-Basavaraj.Natikar@amd.com>
AMDSFH has information about the Ambient light via the Ambient
Light Sensor (ALS) which is part of the AMD sensor fusion hub.
Add a new interface to export this information, where other drivers like
PMF can use this information to enhance user experiences.
Link: https://lore.kernel.org/all/ad064333-48a4-4cfa-9428-69e8a7c44667@redhat.com/
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Co-developed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
---
drivers/hid/amd-sfh-hid/amd_sfh_common.h | 1 +
drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 6 +++++
.../amd-sfh-hid/sfh1_1/amd_sfh_interface.c | 22 +++++++++++++++++++
include/linux/amd-pmf-io.h | 4 ++++
4 files changed, 33 insertions(+)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_common.h b/drivers/hid/amd-sfh-hid/amd_sfh_common.h
index cd57037bf217..a1950bc6e6ce 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_common.h
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_common.h
@@ -39,6 +39,7 @@ struct amd_mp2_sensor_info {
struct sfh_dev_status {
bool is_hpd_present;
+ bool is_als_present;
};
struct amd_mp2_dev {
diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c
index 0351b0fd394a..9dbe6f4cb294 100644
--- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c
+++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c
@@ -77,6 +77,9 @@ static int amd_sfh_hid_client_deinit(struct amd_mp2_dev *privdata)
case HPD_IDX:
privdata->dev_en.is_hpd_present = false;
break;
+ case ALS_IDX:
+ privdata->dev_en.is_als_present = false;
+ break;
}
if (cl_data->sensor_sts[i] == SENSOR_ENABLED) {
@@ -188,6 +191,9 @@ static int amd_sfh1_1_hid_client_init(struct amd_mp2_dev *privdata)
case HPD_IDX:
privdata->dev_en.is_hpd_present = true;
break;
+ case ALS_IDX:
+ privdata->dev_en.is_als_present = true;
+ break;
}
}
dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.c
index 197b828fc6a0..ae36312bc236 100644
--- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.c
+++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.c
@@ -103,12 +103,34 @@ static int amd_sfh_hpd_info(u8 *user_present)
return 0;
}
+static int amd_sfh_als_info(u32 *ambient_light)
+{
+ struct sfh_als_data als_data;
+ void __iomem *sensoraddr;
+
+ if (!ambient_light)
+ return -EINVAL;
+
+ if (!emp2 || !emp2->dev_en.is_als_present)
+ return -ENODEV;
+
+ sensoraddr = emp2->vsbase +
+ (ALS_IDX * SENSOR_DATA_MEM_SIZE_DEFAULT) +
+ OFFSET_SENSOR_DATA_DEFAULT;
+ memcpy_fromio(&als_data, sensoraddr, sizeof(struct sfh_als_data));
+ *ambient_light = amd_sfh_float_to_int(als_data.lux);
+
+ return 0;
+}
+
int amd_get_sfh_info(struct amd_sfh_info *sfh_info, enum sfh_message_type op)
{
if (sfh_info) {
switch (op) {
case MT_HPD:
return amd_sfh_hpd_info(&sfh_info->user_present);
+ case MT_ALS:
+ return amd_sfh_als_info(&sfh_info->ambient_light);
}
}
return -EINVAL;
diff --git a/include/linux/amd-pmf-io.h b/include/linux/amd-pmf-io.h
index 5b6d29d36922..b4f818205216 100644
--- a/include/linux/amd-pmf-io.h
+++ b/include/linux/amd-pmf-io.h
@@ -17,9 +17,11 @@
/**
* enum sfh_message_type - Query the SFH message type
* @MT_HPD: Message ID to know the Human presence info from MP2 FW
+ * @MT_ALS: Message ID to know the Ambient light info from MP2 FW
*/
enum sfh_message_type {
MT_HPD,
+ MT_ALS,
};
/**
@@ -36,9 +38,11 @@ enum sfh_hpd_info {
/**
* struct amd_sfh_info - get HPD sensor info from MP2 FW
+ * @ambient_light: Populates the ambient light information
* @user_present: Populates the user presence information
*/
struct amd_sfh_info {
+ u32 ambient_light;
u8 user_present;
};
--
2.25.1
^ 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