* Re: [PATCH HID v1] HID: nvidia-shield: Pack inner/related declarations in HOSTCMD reports
From: Benjamin Tissoires @ 2023-07-10 8:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Rahul Rameshbabu
Cc: linux-input, linux-kernel, kernel test robot
In-Reply-To: <20230705060414.581468-1-rrameshbabu@nvidia.com>
On Tue, 04 Jul 2023 23:04:14 -0700, Rahul Rameshbabu wrote:
> Match alignment information in composite type declarations used by packed
> HOSTCMD report structures. Compiler packing attribute is not recursive for
> inner declarations. Mismatched alignment information can cause undefined
> behavior in code generated for accessing composite type members. struct
> pointers passed to thunderstrike_parse_board_info_payload and
> thunderstrike_parse_haptics_payload are an example of this being
> potentially problematic since alignment information from the packed HOSTCMD
> report is lost.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.5/upstream-fixes), thanks!
[1/1] HID: nvidia-shield: Pack inner/related declarations in HOSTCMD reports
https://git.kernel.org/hid/hid/c/8bcf314b92ed
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/2] Updates to amd_sfh
From: Benjamin Tissoires @ 2023-07-10 8:32 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input, akshata.mukundshetty,
Basavaraj Natikar
In-Reply-To: <20230707065722.9036-1-Basavaraj.Natikar@amd.com>
On Fri, 07 Jul 2023 12:27:20 +0530, Basavaraj Natikar wrote:
> This patch series include changes for renaming the float32 variable
> including the fix for shift-out-of-bounds issue.
>
> Basavaraj Natikar (2):
> HID: amd_sfh: Rename the float32 variable
> HID: amd_sfh: Fix for shift-out-of-bounds
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.5/upstream-fixes), thanks!
[1/2] HID: amd_sfh: Rename the float32 variable
https://git.kernel.org/hid/hid/c/c1685a862a4b
[2/2] HID: amd_sfh: Fix for shift-out-of-bounds
https://git.kernel.org/hid/hid/c/878543661764
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH] selftests: hid: fix vmtests.sh not running make headers
From: Benjamin Tissoires @ 2023-07-10 8:32 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan, Benjamin Tissoires
Cc: linux-input, linux-kselftest, linux-kernel
In-Reply-To: <20230709-fix-selftests-v1-1-57d0878114cc@kernel.org>
On Sun, 09 Jul 2023 12:06:56 +0200, Benjamin Tissoires wrote:
> According to commit 01d6c48a828b ("Documentation: kselftest:
> "make headers" is a prerequisite"), running the kselftests requires
> to run "make headers" first.
>
> Do that in "vmtest.sh" as well to fix the HID CI.
>
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.5/upstream-fixes), thanks!
[1/1] selftests: hid: fix vmtests.sh not running make headers
https://git.kernel.org/hid/hid/c/f9abdcc617da
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH] HID: hyperv: avoid struct memcpy overrun warning
From: Benjamin Tissoires @ 2023-07-10 8:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Arnd Bergmann
Cc: Arnd Bergmann, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Paulo Miguel Almeida, Michael Kelley, Dawei Li,
Yang Yingliang, Thomas Weißschuh, linux-hyperv, linux-input,
linux-kernel
In-Reply-To: <20230705140242.844167-1-arnd@kernel.org>
On Wed, 05 Jul 2023 16:02:24 +0200, Arnd Bergmann wrote:
> A previous patch addressed the fortified memcpy warning for most
> builds, but I still see this one with gcc-9:
>
> In file included from include/linux/string.h:254,
> from drivers/hid/hid-hyperv.c:8:
> In function 'fortify_memcpy_chk',
> inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:
> include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
> 583 | __write_overflow_field(p_size_field, size);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.5/upstream-fixes), thanks!
[1/1] HID: hyperv: avoid struct memcpy overrun warning
https://git.kernel.org/hid/hid/c/5f151364b1da
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH v3] HID: logitech-hidpp: Add wired USB id for Logitech G502 Lightspeed
From: Benjamin Tissoires @ 2023-07-10 8:32 UTC (permalink / raw)
To: Stuart Hayhurst
Cc: linux-kernel, linux-input, Benjamin Tissoires, Jiri Kosina,
Bastien Nocera, Filipe Laíns
In-Reply-To: <20230630113818.13005-1-stuart.a.hayhurst@gmail.com>
On Fri, 30 Jun 2023 12:38:20 +0100, Stuart Hayhurst wrote:
> Previously, support for the G502 had been attempted in commit
> '27fc32fd9417 ("HID: logitech-hidpp: add USB PID for a few more supported mice")'
>
> This caused some issues and was reverted by
> 'addf3382c47c ("Revert "HID: logitech-hidpp: add USB PID for a few more
> supported mice"")'.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.5/upstream-fixes), thanks!
[1/1] HID: logitech-hidpp: Add wired USB id for Logitech G502 Lightspeed
https://git.kernel.org/hid/hid/c/a343a7682acc
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH] HID: input: fix mapping for camera access keys
From: Benjamin Tissoires @ 2023-07-10 8:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov
Cc: Eray Orçunus, linux-input, linux-kernel
In-Reply-To: <ZJtd/fMXRUgq20TW@google.com>
On Tue, 27 Jun 2023 15:09:01 -0700, Dmitry Torokhov wrote:
> Commit 9f4211bf7f81 ("HID: add mapping for camera access keys") added
> mapping for the camera access keys, but unfortunately used wrong usage
> codes for them. HUTRR72[1] specifies that camera access controls use 0x76,
> 0x077 and 0x78 usages in the consumer control page. Previously mapped 0xd5,
> 0xd6 and 0xd7 usages are actually defined in HUTRR64[2] as game recording
> controls.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.5/upstream-fixes), thanks!
[1/1] HID: input: fix mapping for camera access keys
https://git.kernel.org/hid/hid/c/e3ea6467f623
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: input: iqs7222: Define units for slider properties
From: Krzysztof Kozlowski @ 2023-07-10 8:16 UTC (permalink / raw)
To: Jeff LaBundy, dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-input, devicetree
In-Reply-To: <ZKrpMekZBt95Gmnr@nixie71>
On 09/07/2023 19:06, Jeff LaBundy wrote:
> The units assumed by the 'azoteq,top-speed', 'azoteq,bottom-speed'
> and 'azoteq,gesture-dist' properties are unspecified; define them
> according to the device's datasheet.
>
> Signed-off-by: Jeff LaBundy <jeff@labundy.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] HID: amd_sfh: Increase bitwidth to avoid shift-out-of-bounds
From: Benjamin Tissoires @ 2023-07-10 7:55 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: Basavaraj Natikar, basavaraj.natikar, mario.limonciello,
Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <CAAd53p7-Cyqt-aGkzDNu2sqWejJQgbLcs8BBQvOZxj-FfHmo2g@mail.gmail.com>
On Jul 10 2023, Kai-Heng Feng wrote:
> Hi Basavaraj,
>
> On Fri, Jul 7, 2023 at 3:36 PM Basavaraj Natikar <bnatikar@amd.com> wrote:
> >
> >
> > On 7/4/2023 1:47 PM, Kai-Heng Feng wrote:
> > > UBSAN complains shift-out-of-bounds on amd_sfh:
> > > [ 7.593412] input: SYNA3105:00 06CB:CEA3 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA3105:00/0018:06CB:CEA3.0001/input/input11
> > > [ 7.593541] input: SYNA3105:00 06CB:CEA3 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA3105:00/0018:06CB:CEA3.0001/input/input12
> > > [ 7.593625] hid-multitouch 0018:06CB:CEA3.0001: input,hidraw0: I2C HID v1.00 Mouse [SYNA3105:00 06CB:CEA3] on i2c-SYNA3105:00
> > > [ 7.664537] ================================================================================
> > > [ 7.664540] UBSAN: shift-out-of-bounds in drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c:149:50
> > > [ 7.664544] shift exponent 103 is too large for 64-bit type 'long unsigned int'
> > > [ 7.664547] CPU: 5 PID: 124 Comm: kworker/5:1 Tainted: G W 6.4.0-next-20230703 #1
> > > [ 7.664549] Hardware name: HP HP EliteBook 835 13 inch G10 Notebook PC/8C10, BIOS V83 Ver. 01.01.09 06/05/2023
> > > [ 7.664551] Workqueue: events amd_sfh_work_buffer [amd_sfh]
> > > [ 7.664562] Call Trace:
> > > [ 7.664564] <TASK>
> > > [ 7.664567] dump_stack_lvl+0x48/0x70
> > > [ 7.664576] dump_stack+0x10/0x20
> > > [ 7.664578] __ubsan_handle_shift_out_of_bounds+0x156/0x310
> > > [ 7.664584] ? sched_clock_noinstr+0x9/0x10
> > > [ 7.664589] ? sched_clock_cpu+0x12/0x1d0
> > > [ 7.664594] ? raw_spin_rq_lock_nested+0x1e/0xa0
> > > [ 7.664597] ? psi_group_change+0x237/0x520
> > > [ 7.664600] float_to_int.cold+0x18/0xcf [amd_sfh]
> > > [ 7.664606] ? __pfx_get_input_rep+0x10/0x10 [amd_sfh]
> > > [ 7.664611] get_input_rep+0x241/0x340 [amd_sfh]
> > > [ 7.664617] amd_sfh_work_buffer+0x91/0x190 [amd_sfh]
> > > [ 7.664622] process_one_work+0x229/0x450
> > > [ 7.664627] worker_thread+0x50/0x3f0
> > > [ 7.664629] ? __pfx_worker_thread+0x10/0x10
> > > [ 7.664632] kthread+0xf4/0x130
> > > [ 7.664635] ? __pfx_kthread+0x10/0x10
> > > [ 7.664638] ret_from_fork+0x29/0x50
> > > [ 7.664644] </TASK>
> > > [ 7.664652] ================================================================================
> > >
> > > So increase the variable bitwidth to solve the issue.
> > >
> > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > > ---
> > > drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> > > index 6f0d332ccf51..550639ef8bfe 100644
> > > --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> > > +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> > > @@ -134,7 +134,8 @@ static void get_common_inputs(struct common_input_property *common, int report_i
> > >
> > > static int float_to_int(u32 float32)
> > > {
> > > - int fraction, shift, mantissa, sign, exp, zeropre;
> > > + int fraction, shift, sign, exp, zeropre;
> > > + s128 mantissa;
> > >
> > > mantissa = float32 & GENMASK(22, 0);
> > > sign = (float32 & BIT(31)) ? -1 : 1;
> >
> > Could you please check below patch which covers more scenario's and corner cases
> > for UBSAN: shift-out-of-bounds.
> > https://lore.kernel.org/all/20230707065722.9036-1-Basavaraj.Natikar@amd.com/T/#m67e0b7aa6a288ea074b3bfa61e7f085f7e036172
>
> Thanks for the patch. Please add my tag:
> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Thanks. I'll add the tags to Basavaraj's series and push it to Linus
ASAP.
Cheers,
Benjamin
>
> >
> > Thanks,
> > --
> > Basavaraj
> >
^ permalink raw reply
* Re: [PATCH] selftests: hid: fix vmtests.sh not running make headers
From: Benjamin Tissoires @ 2023-07-10 7:51 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Shuah Khan, linux-input, linux-kselftest,
linux-kernel
In-Reply-To: <20230709-fix-selftests-v1-1-57d0878114cc@kernel.org>
On Sun, Jul 9, 2023 at 12:07 PM Benjamin Tissoires <bentiss@kernel.org> wrote:
>
> According to commit 01d6c48a828b ("Documentation: kselftest:
> "make headers" is a prerequisite"), running the kselftests requires
> to run "make headers" first.
>
> Do that in "vmtest.sh" as well to fix the HID CI.
>
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> ---
> Looks like the new master branch (v6.5-rc1) broke my CI.
>
> And given that `make headers` is now a requisite to run the kselftests,
> also include that command in vmtests.sh.
>
> Broken CI job: https://gitlab.freedesktop.org/bentiss/hid/-/jobs/44704436
> Fixed CI job: https://gitlab.freedesktop.org/bentiss/hid/-/jobs/45151040
FWIW, I'm going to apply this one now given that otherwise all of the
CI is not working.
Cheers,
Benjamin
> ---
> tools/testing/selftests/hid/vmtest.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/hid/vmtest.sh b/tools/testing/selftests/hid/vmtest.sh
> index 681b906b4853..4da48bf6b328 100755
> --- a/tools/testing/selftests/hid/vmtest.sh
> +++ b/tools/testing/selftests/hid/vmtest.sh
> @@ -79,6 +79,7 @@ recompile_kernel()
> cd "${kernel_checkout}"
>
> ${make_command} olddefconfig
> + ${make_command} headers
> ${make_command}
> }
>
>
> ---
> base-commit: 0e382fa72bbf0610be40af9af9b03b0cd149df82
> change-id: 20230709-fix-selftests-c8b0bdff1d20
>
> Best regards,
> --
> Benjamin Tissoires <bentiss@kernel.org>
>
^ permalink raw reply
* Re: [PATCH] HID: amd_sfh: Increase bitwidth to avoid shift-out-of-bounds
From: Kai-Heng Feng @ 2023-07-10 5:15 UTC (permalink / raw)
To: Basavaraj Natikar
Cc: basavaraj.natikar, mario.limonciello, Jiri Kosina,
Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <29b68182-cb58-6a3f-0fdf-b919851e5524@amd.com>
Hi Basavaraj,
On Fri, Jul 7, 2023 at 3:36 PM Basavaraj Natikar <bnatikar@amd.com> wrote:
>
>
> On 7/4/2023 1:47 PM, Kai-Heng Feng wrote:
> > UBSAN complains shift-out-of-bounds on amd_sfh:
> > [ 7.593412] input: SYNA3105:00 06CB:CEA3 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA3105:00/0018:06CB:CEA3.0001/input/input11
> > [ 7.593541] input: SYNA3105:00 06CB:CEA3 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA3105:00/0018:06CB:CEA3.0001/input/input12
> > [ 7.593625] hid-multitouch 0018:06CB:CEA3.0001: input,hidraw0: I2C HID v1.00 Mouse [SYNA3105:00 06CB:CEA3] on i2c-SYNA3105:00
> > [ 7.664537] ================================================================================
> > [ 7.664540] UBSAN: shift-out-of-bounds in drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c:149:50
> > [ 7.664544] shift exponent 103 is too large for 64-bit type 'long unsigned int'
> > [ 7.664547] CPU: 5 PID: 124 Comm: kworker/5:1 Tainted: G W 6.4.0-next-20230703 #1
> > [ 7.664549] Hardware name: HP HP EliteBook 835 13 inch G10 Notebook PC/8C10, BIOS V83 Ver. 01.01.09 06/05/2023
> > [ 7.664551] Workqueue: events amd_sfh_work_buffer [amd_sfh]
> > [ 7.664562] Call Trace:
> > [ 7.664564] <TASK>
> > [ 7.664567] dump_stack_lvl+0x48/0x70
> > [ 7.664576] dump_stack+0x10/0x20
> > [ 7.664578] __ubsan_handle_shift_out_of_bounds+0x156/0x310
> > [ 7.664584] ? sched_clock_noinstr+0x9/0x10
> > [ 7.664589] ? sched_clock_cpu+0x12/0x1d0
> > [ 7.664594] ? raw_spin_rq_lock_nested+0x1e/0xa0
> > [ 7.664597] ? psi_group_change+0x237/0x520
> > [ 7.664600] float_to_int.cold+0x18/0xcf [amd_sfh]
> > [ 7.664606] ? __pfx_get_input_rep+0x10/0x10 [amd_sfh]
> > [ 7.664611] get_input_rep+0x241/0x340 [amd_sfh]
> > [ 7.664617] amd_sfh_work_buffer+0x91/0x190 [amd_sfh]
> > [ 7.664622] process_one_work+0x229/0x450
> > [ 7.664627] worker_thread+0x50/0x3f0
> > [ 7.664629] ? __pfx_worker_thread+0x10/0x10
> > [ 7.664632] kthread+0xf4/0x130
> > [ 7.664635] ? __pfx_kthread+0x10/0x10
> > [ 7.664638] ret_from_fork+0x29/0x50
> > [ 7.664644] </TASK>
> > [ 7.664652] ================================================================================
> >
> > So increase the variable bitwidth to solve the issue.
> >
> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > ---
> > drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> > index 6f0d332ccf51..550639ef8bfe 100644
> > --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> > +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> > @@ -134,7 +134,8 @@ static void get_common_inputs(struct common_input_property *common, int report_i
> >
> > static int float_to_int(u32 float32)
> > {
> > - int fraction, shift, mantissa, sign, exp, zeropre;
> > + int fraction, shift, sign, exp, zeropre;
> > + s128 mantissa;
> >
> > mantissa = float32 & GENMASK(22, 0);
> > sign = (float32 & BIT(31)) ? -1 : 1;
>
> Could you please check below patch which covers more scenario's and corner cases
> for UBSAN: shift-out-of-bounds.
> https://lore.kernel.org/all/20230707065722.9036-1-Basavaraj.Natikar@amd.com/T/#m67e0b7aa6a288ea074b3bfa61e7f085f7e036172
Thanks for the patch. Please add my tag:
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>
> Thanks,
> --
> Basavaraj
>
^ permalink raw reply
* Re: [PATCH v2] HID: Add introduction about HID for non-kernel programmers
From: Peter Hutterer @ 2023-07-10 2:10 UTC (permalink / raw)
To: Marco Morandini
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, Jonathan Corbet,
linux-doc
In-Reply-To: <dc79f50c-0539-0d7c-129a-d02d5bbee4d5@polimi.it>
On Wed, Jun 28, 2023 at 03:37:44PM +0200, Marco Morandini wrote:
> On 6/27/23 08:04, Peter Hutterer wrote:
> > On Thu, Jun 22, 2023 at 10:39:15PM +0200, Marco Morandini wrote:
> >> Add an introduction about HID
> >> meant for the casual programmers that is trying
> >> either to fix his device or to understand what
> >> is going wrong.
> >>
> >> Signed-off-by: Marco Morandini <marco.morandini@polimi.it>
> >> ---
> >> v1: https://lore.kernel.org/linux-input/3mbw67akm2xzd2kgzb6sdfh4dly6im5jrz5umuvczjvrgxtf46@q5ooib3zkmfq/T/#m00b625a4d2c605dd7f62a866df7bf97ef2921d63
> >
> > Thanks for all the fixes, much easier to read and follow already. A few
> > nitpicks like last time but this is coming together!
>
> :)
>
> Unfortunately while reading hidreport-parsing.rst I found it not very clear, at least for me.
> I tried to rearrange things there, but I fear we'll need v4 for that file :/
>
> It would be great if you could double-check it, especially the reference to the
> spec; for example, I think one should look into HID spec 6.2.2.2 (and not HID spec 6.2.2.7 as written in v2)
> for inferring the Type of the item (Global in this case). From there you jump to HID spec 6.2.2.7
> that defines the different Global items; without looking into HID spec 6.2.2.2 you
> all you can do is to browse the spec until you find the bit sequence "0000 01 nn" in HID spec 6.2.2.7.
> I've also finished "parsing" the fourth byte at the end of the document.
See my other email but this largely comes down to where you want the
cut-off to be. You can link to each individual section but anyone
actually attempting this would have to read the spec anyway.
So IMO it would be perfectly acceptable to just state "Report descriptor
parsing is detailed in the Hid spec section 6.2.2" and not linking each
item separately. For me personally it is generally more important to
know that "those bits are that" because that's where the early errors
are being made. I can usually find what "that" means myself :)
>
> I'm going to wait a few more days for Banjamin's comments, if any,
> then will send v3. At any rate, I'm attaching the current diff at the bottom of this email
> (what I would send, right now, as v3).
>
> On a side note: after sending v2 I've realized that _lot_ of sentences
> now come from you. Thus, for v3, I think it would be better to send something like
>
> Signed-off-by: Marco Morandini <marco.morandini@polimi.it>
> Co-developed-by: Peter Hutterer <peter.hutterer@who-t.net>
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
>
> Ok for you?
>
> If yes: I don't have clear whether I should send
>
> Signed-off-by: Marco Morandini <marco.morandini@polimi.it>
> Co-developed-by: Peter Hutterer <peter.hutterer@who-t.net>
>
> and you should reply with
>
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
>
> or I should simply write the Signed-off-by on your behalf.
that's the only bit you cannot do. But honestly, I don't care too much
in this case, it's just text so don't worry about the extra tags,
If you really want to (so the blame for bug splits between us :) feel
free to use Co-authored-by if you want though, I think that's both
common enough and appropriate.
> =================================
> From: Marco Morandini <marco.morandini@polimi.it>
>
> Add an introduction about HID
> meant for the casual programmers that is trying
> either to fix his device or to understand what
> is going wrong.
>
> Signed-off-by: Marco Morandini <marco.morandini@polimi.it>
> Co-developed-by: Peter Hutterer <peter.hutterer@who-t.net>
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> ---
> v2: https://lore.kernel.org/linux-input/20230627060437.GA726439@quokka/T/#t
>
> changes:
> - corrections suggested in https://lore.kernel.org/linux-input/20230627060437.GA726439@quokka/T/#m21b0a280e2ce2b21332ca31cfafaddf44a1b5fb1
> - corrections suggested in https://lore.kernel.org/linux-input/20230627060437.GA726439@quokka/T/#mafb91d69de2d56e6a1eeff5ba4ed88a764cf559e
> - some rewording of Documentation/hid/hidreport-parsing.rst
>
> --- /dev/null 2023-06-28 09:46:06.188159532 +0200
> +++ Documentation/hid/hidintro.rst 2023-06-28 15:26:31.543904010 +0200
> @@ -0,0 +1,510 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +======================================
> +Introduction to HID report descriptors
> +======================================
> +
> +This chapter is meant to give a broad overview of what HID report
> +descriptors are, and of how a casual (non-kernel) programmer can deal
> +with HID devices that are not working well with Linux.
> +
> +.. contents::
> + :local:
> + :depth: 2
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + hidreport-parsing
> +
> +
> +Introduction
> +============
> +
> +HID stands for Human Interface Device, and can be whatever device you
> +are using to interact with a computer, be it a mouse, a touchpad, a
> +tablet, a microphone.
> +
> +Many HID devices work out the box, even if their hardware is different.
> +For example, mice can have any number of buttons; they may have a
> +wheel; movement sensitivity differs between different models, and so
> +on. Nonetheless, most of the time everything just works, without the
> +need to have specialized code in the kernel for every mouse model
> +developed since 1970.
> +
> +This is because modern HID devices do advertise their capabilities
> +through the *HID report descriptor*, a fixed set of bytes describing
> +exactly what *HID reports* may be sent between the device and the host
> +and the meaning of each individual bit in those reports. For example,
> +a HID Report Descriptor may specify that "in a report with ID 3 the
> +bits from 8 to 15 is the delta x coordinate of a mouse".
> +
> +The HID report itself then merely carries the actual data values
> +without any extra meta information. Note that HID reports may be sent
> +from the device ("Input Reports", i.e. input events), to the device
> +("Output Reports" to e.g. change LEDs) or used for device configuration
> +("Feature reports"). A device may support one or more HID reports.
> +
> +The HID subsystem is in charge of parsing the HID report descriptors,
> +and converts HID events into normal input device interfaces (see
> +Documentation/hid/hid-transport.rst). Devices may misbehave because the
> +HID report descriptor provided by the device is wrong, or because it
> +needs to be dealt with in a special way, or because some special
> +device or interaction mode is not handled by the default code.
> +
> +The format of HID report descriptors is described by two documents,
> +available from the `USB Implementers Forum <https://www.usb.org/>`_
> +`HID web page <https://www.usb.org/hid>`_ address:
> +
> + * the `HID USB Device Class Definition
> + <https://www.usb.org/document-library/device-class-definition-hid-111>`_ (HID Spec from now on)
> + * the `HID Usage Tables <https://usb.org/document-library/hid-usage-tables-14>`_ (HUT from now on)
> +
> +The HID subsystem can deal with different transport drivers
> +(USB, I2C, Bluetooth, etc.). See Documentation/hid/hid-transport.rst.
> +
> +Parsing HID report descriptors
> +==============================
> +
> +The current list of HID devices can be found at ``/sys/bus/hid/devices/``.
> +For each device, say ``/sys/bus/hid/devices/0003\:093A\:2510.0002/``,
> +one can read the corresponding report descriptor::
> +
> + $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
> + 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).|
> + 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....|
> + 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...|
> + 00000030 81 06 c0 c0 |....|
> + 00000034
> +
> +Optional stuff: the HID report descriptor can be read also by
s/Optional stuff: //
unless you're talking about cooking poultry, "stuff" should
generally be avoided :)
> +directly accessing the hidraw driver [#hidraw]_.
> +
> +The basic structure of HID report descriptors is defined in the HID
> +spec, while HUT "defines constants that can be interpreted by an
> +application to identify the purpose and meaning of a data field in a
> +HID report". Each entry is defined by at least two bytes, where the
> +first one defines what type of value is following and is described in
> +the HID spec, while the second one carries the actual value and is
> +described in the HUT.
> +
> +HID report descriptors can, in principle, be painstakingly parsed by
> +hand, byte by byte.
> +
> +A short introduction on how to do this is sketched in
> +Documentation/hid/hidreport-parsing.rst; you only need to understand it
> +if you need to patch HID report descriptors.
> +
> +In practice you should not parse HID report descriptors by hand; rather,
> +you should use an existing parser. Among all the available ones
> +
> + * the online `USB Descriptor and Request Parser
> + <http://eleccelerator.com/usbdescreqparser/>`_;
> + * `hidrdd <https://github.com/abend0c1/hidrdd>`_,
> + that provides very detailed and somewhat verbose descriptions
> + (verbosity can be useful if you are not familiar with HID report
> + descriptors);
> + * `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_,
> + a complete utility set that allows, among other things,
> + to record and replay the raw HID reports and to debug
> + and replay HID devices.
> + It is being actively developed by the Linux HID subsystem maintainers.
> +
> +Parsing the mouse HID report descriptor with `hid-tools
> +<https://gitlab.freedesktop.org/libevdev/hid-tools>`_ leads to
> +(explanations interposed)::
> +
> + $ ./hid-decode /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
> + # device 0:0
> + # 0x05, 0x01, // Usage Page (Generic Desktop) 0
> + # 0x09, 0x02, // Usage (Mouse) 2
> + # 0xa1, 0x01, // Collection (Application) 4
> + # 0x09, 0x01, // Usage (Pointer) 6
> + # 0xa1, 0x00, // Collection (Physical) 8
> + # 0x05, 0x09, // Usage Page (Button) 10
> + what follows is a button
btw, did you check the proper rendering of this page? IIRC in RST
documents you need an empty line after a code block.
> +
> + # 0x19, 0x01, // Usage Minimum (1) 12
> + # 0x29, 0x03, // Usage Maximum (3) 14
> + first button is button number 1, last button is button number 3
> +
> + # 0x15, 0x00, // Logical Minimum (0) 16
> + # 0x25, 0x01, // Logical Maximum (1) 18
> + each button can send values from 0 up to including 1
> + (i.e. they are binary buttons)
> +
> + # 0x75, 0x01, // Report Size (1) 20
> + each button is sent as exactly one bit
> +
> + # 0x95, 0x03, // Report Count (3) 22
> + and there are three of those bits (matching the three buttons)
> +
> + # 0x81, 0x02, // Input (Data,Var,Abs) 24
> + it's actual Data (not constant padding), they represent
> + a single variable (Var) and their values are Absolute (not relative);
> + See HID spec Sec. 6.2.2.5 "Input, Output, and Feature Items
missing closing quotes
> +
> + # 0x75, 0x05, // Report Size (5) 26
> + five additional padding bits, needed to reach a byte
> +
> + # 0x95, 0x01, // Report Count (1) 28
> + those five bits are repeated only once
> +
> + # 0x81, 0x01, // Input (Cnst,Arr,Abs) 30
> + and take Constant (Cnst) values i.e. they can be ignored
full stop at the end, since you start a new sentence below.
> +
> + # 0x05, 0x01, // Usage Page (Generic Desktop) 32
> + # 0x09, 0x30, // Usage (X) 34
> + # 0x09, 0x31, // Usage (Y) 36
> + # 0x09, 0x38, // Usage (Wheel) 38
> + The mouse has also two physical positions (Usage (X), Usage (Y))
> + and a wheel (Usage (Wheel))
> +
> + # 0x15, 0x81, // Logical Minimum (-127) 40
> + # 0x25, 0x7f, // Logical Maximum (127) 42
> + each of them can send values ranging from -127 up to including 127
> +
> + # 0x75, 0x08, // Report Size (8) 44
> + is represented by eight bits
"which is..."
> +
> + # 0x95, 0x03, // Report Count (3) 46
> + and there are three of those eight bits, matching X, Y and Wheel
full stop at the end, since you start a new sentence below.
> +
> + # 0x81, 0x06, // Input (Data,Var,Rel) 48
> + This time the data values are Relative (Rel), i.e. they represent
> + the change from the previously sent report (event)
> +
> + # 0xc0, // End Collection 50
> + # 0xc0, // End Collection 51
> + #
> + R: 52 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 c0 c0
> + N: device 0:0
> + I: 3 0001 0001
> +
> +
> +This Report Descriptor tells us that the mouse input will be
> +transmitted using four bytes: the first one for the buttons (three
> +bits used, five for padding), the last three for the mouse X, Y and
> +wheel changes, respectively.
I wonder if here we should mention something like:
"This particular device only has one HID report so it may (and does)
omit the Report ID. Devices that can send multiple different HID reports
must send the Report ID as the first byte of each report."
> +
> +Indeed, for any event, the mouse will send a *report* of four bytes.
> +We can check the values sent by resorting e.g. to the `hid-recorder`
> +tool, from `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_:
> +The sequence of bytes sent by clicking and releasing button 1, then button 2, then button 3 is::
> +
> + $ sudo ./hid-recorder /dev/hidraw1
> +
> + ....
> + output of hid-decode
> + ....
> +
> + # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000000.000000 4 01 00 00 00
> + # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000000.183949 4 00 00 00 00
> + # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000001.959698 4 02 00 00 00
> + # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000002.103899 4 00 00 00 00
> + # Button: 0 0 1 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000004.855799 4 04 00 00 00
> + # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000005.103864 4 00 00 00 00
> +
> +This example shows that when button 2 is clicked,
> +the bytes ``02 00 00 00`` are sent, and the immediately subsequent
> +event (``00 00 00 00``) is the release of button 2 (no buttons are
> +pressed, remember that the data values are *absolute*).
> +
> +If instead one clicks and holds button 1, then clicks and holds button
> +2, releases button 1, and finally releases button 2, the reports are::
> +
> + # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000044.175830 4 01 00 00 00
> + # Button: 1 1 0 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000045.975997 4 03 00 00 00
> + # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000047.407930 4 02 00 00 00
> + # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
> + E: 000049.199919 4 00 00 00 00
> +
> +where with ``03 00 00 00`` both buttons are pressed, and with the
> +subsequent ``02 00 00 00`` button 1 is released while button 2 is still
> +active.
> +
> +Output, Input and Feature Reports
> +---------------------------------
> +
> +HID devices can have Input Reports, like in the mouse example, Output
> +Reports, and Feature Reports. "Output" means that the information is
> +sent to the device. For example, a joystick with force feedback will
> +have some output; the led of a keyboard would need an output as well.
> +"Input" means that data come from the device.
> +
> +"Feature"s are not meant to be consumed by the end user and define
> +configuration options for the device. They can be queried from the host;
> +when declared as *Volatile* they should be changed by the host.
> +
> +
> +Collections, Report IDs and Evdev events
> +========================================
> +
> +A single device can logically group data into different, independent
superfluous comma
> +sets, called a *Collection*. Collections can be nested, and there are
superfluous commas
> +different types of collections (see the HID spec 6.2.2.6
> +"Collection, End Collection Items" for details).
Going with what I mentioned above: you provide the exact location for
the collection spec here but I don't think it'll be very useful - anyone
needing to know that detail needs to read through most of 6.2.2 anyway
and the Collection subsection is easy enough to find.
This isn't to say you need to remove the reference, just that providing
that level of detail probably has little benefit to most readers.
> +
> +Different reports are identified by means of different *Report ID*
> +fields, i.e. a number identifying the structure of the immediately
> +following report.
> +Whenever a Report ID is needed it is transmitted as the first byte of
> +any report. A device with only one supported HID report (like the mouse
> +example above) may omit the report ID.
> +
> +Consider the following HID report descriptor::
> +
> + 05 01 09 02 A1 01 85 01 05 09 19 01 29 05 15 00
> + 25 01 95 05 75 01 81 02 95 01 75 03 81 01 05 01
> + 09 30 09 31 16 00 F8 26 FF 07 75 0C 95 02 81 06
> + 09 38 15 80 25 7F 75 08 95 01 81 06 05 0C 0A 38
> + 02 15 80 25 7F 75 08 95 01 81 06 C0 05 01 09 02
> + A1 01 85 02 05 09 19 01 29 05 15 00 25 01 95 05
> + 75 01 81 02 95 01 75 03 81 01 05 01 09 30 09 31
> + 16 00 F8 26 FF 07 75 0C 95 02 81 06 09 38 15 80
> + 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 80 25
> + 7F 75 08 95 01 81 06 C0 05 01 09 07 A1 01 85 05
> + 05 07 15 00 25 01 09 29 09 3E 09 4B 09 4E 09 E3
> + 09 E8 09 E8 09 E8 75 01 95 08 81 02 95 00 81 01
> + C0 05 0C 09 01 A1 01 85 06 15 00 25 01 75 01 95
> + 01 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
> + 06 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
> + 06 C0 05 0C 09 01 A1 01 85 03 09 05 15 00 26 FF
> + 00 75 08 95 02 B1 02 C0
> +
> +After parsing it (try to parse it on your own using the suggested
> +tools!) one can see that the device presents two ``Mouse`` Application
> +Collections (with reports identified by Reports IDs 1 and 2,
> +respectively), a ``Keypad`` Application Collection (whose report is
> +identified by the Report ID 5) and two ``Consumer Controls`` Application
> +Collections, (with Report IDs 6 and 3, respectively). Note, however,
> +that you can have different Report IDs for the same Application
s/you/a device/
> +Collection.
> +
> +The data sent will begin with the Report ID byte, and will be followed
> +by the corresponding information. For example, the data transmitted for
> +the last consumer control::
> +
> + 0x05, 0x0C, // Usage Page (Consumer)
> + 0x09, 0x01, // Usage (Consumer Control)
> + 0xA1, 0x01, // Collection (Application)
> + 0x85, 0x03, // Report ID (3)
> + 0x09, 0x05, // Usage (Headphone)
> + 0x15, 0x00, // Logical Minimum (0)
> + 0x26, 0xFF, 0x00, // Logical Maximum (255)
> + 0x75, 0x08, // Report Size (8)
> + 0x95, 0x02, // Report Count (2)
> + 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
> + 0xC0, // End Collection
> +
> +will be of three bytes: the first for the Report ID (3), the next two
> +for the headphone, with two (``Report Count (2)``) bytes
> +(``Report Size (8)``), each ranging from 0 (``Logical Minimum (0)``)
> +to 255 (``Logical Maximum (255)``).
> +
> +All the Input data sent by the device should be translated into
> +corresponding Evdev events, so that the remaining part of the stack can
> +know what is going on, e.g. the bit for the first button translates into
> +the ``EV_KEY/BTN_LEFT`` evdev event and relative X movement translates
> +into the ``EV_REL/REL_X`` evdev event".
> +
> +Events
> +======
> +
> +In Linux, one ``/dev/input/event*`` is created for each ``Application
> +Collection``. Going back to the mouse example, and repeating the
> +sequence where one clicks and holds button 1, then clicks and holds
> +button 2, releases button 1, and finally releases button 2, one gets::
> +
> + $ sudo libinput record /dev/input/event1
> + # libinput record
> + version: 1
> + ndevices: 1
> + libinput:
> + version: "1.23.0"
> + git: "unknown"
> + system:
> + os: "opensuse-tumbleweed:20230619"
> + kernel: "6.3.7-1-default"
> + dmi: "dmi:bvnHP:bvrU77Ver.01.05.00:bd03/24/2022:br5.0:efr20.29:svnHP:pnHPEliteBook64514inchG9NotebookPC:pvr:rvnHP:rn89D2:rvrKBCVersion14.1D.00:cvnHP:ct10:cvr:sku5Y3J1EA#ABZ:"
> + devices:
> + - node: /dev/input/event1
> + evdev:
> + # Name: PixArt HP USB Optical Mouse
> + # ID: bus 0x3 vendor 0x3f0 product 0x94a version 0x111
> + # Supported Events:
> + # Event type 0 (EV_SYN)
> + # Event type 1 (EV_KEY)
> + # Event code 272 (BTN_LEFT)
> + # Event code 273 (BTN_RIGHT)
> + # Event code 274 (BTN_MIDDLE)
> + # Event type 2 (EV_REL)
> + # Event code 0 (REL_X)
> + # Event code 1 (REL_Y)
> + # Event code 8 (REL_WHEEL)
> + # Event code 11 (REL_WHEEL_HI_RES)
> + # Event type 4 (EV_MSC)
> + # Event code 4 (MSC_SCAN)
> + # Properties:
> + name: "PixArt HP USB Optical Mouse"
> + id: [3, 1008, 2378, 273]
> + codes:
> + 0: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] # EV_SYN
> + 1: [272, 273, 274] # EV_KEY
> + 2: [0, 1, 8, 11] # EV_REL
> + 4: [4] # EV_MSC
> + properties: []
> + hid: [
> + 0x05, 0x01, 0x09, 0x02, 0xa1, 0x01, 0x09, 0x01, 0xa1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x03,
> + 0x15, 0x00, 0x25, 0x01, 0x95, 0x08, 0x75, 0x01, 0x81, 0x02, 0x05, 0x01, 0x09, 0x30, 0x09, 0x31,
> + 0x09, 0x38, 0x15, 0x81, 0x25, 0x7f, 0x75, 0x08, 0x95, 0x03, 0x81, 0x06, 0xc0, 0xc0
> + ]
> + udev:
> + properties:
> + - ID_INPUT=1
> + - ID_INPUT_MOUSE=1
> + - LIBINPUT_DEVICE_GROUP=3/3f0/94a:usb-0000:05:00.3-2
> + quirks:
> + events:
> + # Current time is 12:31:56
> + - evdev:
> + - [ 0, 0, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
> + - [ 0, 0, 1, 272, 1] # EV_KEY / BTN_LEFT 1
> + - [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
> + - evdev:
> + - [ 1, 207892, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
> + - [ 1, 207892, 1, 273, 1] # EV_KEY / BTN_RIGHT 1
> + - [ 1, 207892, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1207ms
> + - evdev:
> + - [ 2, 367823, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
> + - [ 2, 367823, 1, 272, 0] # EV_KEY / BTN_LEFT 0
> + - [ 2, 367823, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1160ms
> + # Current time is 12:32:00
> + - evdev:
> + - [ 3, 247617, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
> + - [ 3, 247617, 1, 273, 0] # EV_KEY / BTN_RIGHT 0
> + - [ 3, 247617, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +880ms
> +
> +Note: if ``libinput`` is not available on your system try using
> +``evemu-record``.
this should probably read "If ``libinput record`` is not avaiable..."
because it's often in a seprate package (libinput-utils on Fedora for
example).
Cheers,
Peter
> +
> +When something does not work
> +============================
> +
> +There can be a number of reasons why a device does not behave
> +correctly. For example
> +
> +* The HID report descriptor provided by the HID device may be wrong
> + because e.g.
> +
> + * it does not follow the standard, so that the kernel
> + will not able to make sense of the HID report descriptor;
> + * the HID report descriptor *does not match* what is actually
> + sent by the device (this can be verified by reading the raw HID
> + data);
> +* the HID report descriptor may need some "quirks" (see later on).
> +
> +As a consequence, a ``/dev/input/event*`` may not be created
> +for each Application Collection, and/or the events
> +there may not match what you would expect.
> +
> +
> +Quirks
> +------
> +
> +There are some known peculiarities of HID devices that the kernel
> +knows how to fix - these are called the HID quirks and a list of those
> +is available in `include/linux/hid.h`.
> +
> +Should this be the case, it should be enough to add the required quirk
> +in the kernel, for the HID device at hand. This can be done in the file
> +`drivers/hid/hid-quirks.c`. How to do it should be relatively
> +straightforward after looking into the file.
> +
> +The list of currently defined quirks, from `include/linux/hid.h`, is
> +
> +.. kernel-doc:: include/linux/hid.h
> + :doc: HID quirks
> +
> +Quirks for USB devices can be specified while loading the usbhid module,
> +see ``modinfo usbhid``, although the proper fix should go into
> +hid-quirks.c and **be submitted upstream**.
> +See Documentation/process/submitting-patches.rst for guidelines on how
> +to submit a patch. Quirks for other busses need to go into hid-quirks.c.
> +
> +Fixing HID report descriptors
> +-----------------------------
> +
> +Should you need to patch HID report descriptors the easiest way is to
> +resort to eBPF, as described in Documentation/hid/hid-bpf.rst.
> +
> +Basically, you can change any byte of the original HID report
> +descriptor. The examples in samples/hid should be a good starting point
> +for your code, see e.g. `samples/hid/hid_mouse.bpf.c`::
> +
> + SEC("fmod_ret/hid_bpf_rdesc_fixup")
> + int BPF_PROG(hid_rdesc_fixup, struct hid_bpf_ctx *hctx)
> + {
> + ....
> + data[39] = 0x31;
> + data[41] = 0x30;
> + return 0;
> + }
> +
> +Of course this can be also done within the kernel source code, see e.g.
> +`drivers/hid/hid-aureal.c` or `drivers/hid/hid-samsung.c` for a slightly
> +more complex file.
> +
> +Check Documentation/hid/hidreport-parsing.rst if you need any help
> +navigating the HID manuals and understanding the exact meaning of
> +the HID report descriptor hex numbers.
> +
> +Whatever solution you come up with, please remember to **submit the
> +fix to the HID maintainers**, so that it can be directly integrated in
> +the kernel and that particular HID device will start working for
> +everyone else. See Documentation/process/submitting-patches.rst for
> +guidelines on how to do this.
> +
> +
> +Modifying the transmitted data on the fly
> +-----------------------------------------
> +
> +Using eBPF it is also possible to modify the data exchanged with the
> +device. See again the examples in `samples/hid`.
> +
> +Again, **please post your fix**, so that it can be integrated in the
> +kernel!
> +
> +Writing a specialized driver
> +----------------------------
> +
> +This should really be your last resort.
> +
> +
> +.. rubric:: Footnotes
> +
> +.. [#hidraw] read hidraw: see Documentation/hid/hidraw.rst and
> + file `samples/hidraw/hid-example.c` for an example.
> + The output of ``hid-example`` would be, for the same mouse::
> +
> + $ sudo ./hid-example
> + Report Descriptor Size: 52
> + Report Descriptor:
> + 5 1 9 2 a1 1 9 1 a1 0 5 9 19 1 29 3 15 0 25 1 75 1 95 3 81 2 75 5 95 1 81 1 5 1 9 30 9 31 9 38 15 81 25 7f 75 8 95 3 81 6 c0 c0
> +
> + Raw Name: PixArt USB Optical Mouse
> + Raw Phys: usb-0000:05:00.4-2.3/input0
> + Raw Info:
> + bustype: 3 (USB)
> + vendor: 0x093a
> + product: 0x2510
> + ...
> --- /dev/null 2023-06-28 09:46:06.188159532 +0200
> +++ Documentation/hid/hidreport-parsing.rst 2023-06-27 22:56:18.886315875 +0200
> @@ -0,0 +1,49 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +========================================
> +Manual parsing of HID report descriptors
> +========================================
> +
> +Consider again the mouse HID report descriptor
> +introduced in Documentation/hid/hidintro.rst::
> +
> + $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
> + 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).|
> + 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....|
> + 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...|
> + 00000030 81 06 c0 c0 |....|
> + 00000034
> +
> +and try to parse it by hand.
> +
> +Start with the first number, 0x05: it carries 2 bits for the
> +length of the item, 2 bits for the type of the item and 4 bits for the
> +function::
> +
> + +----------+
> + | 00000101 |
> + +----------+
> + ^^
> + ---- Length of data (see HID spec 6.2.2.2)
> + ^^
> + ------ Type of the item (see HID spec 6.2.2.2, then jump to 6.2.2.7)
> + ^^^^
> + --------- Function of the item (see HID spec 6.2.2.7, then HUT Sec 3)
> +
> +In our case, the length is 1 byte, the type is ``Global`` and the
> +function is ``Usage Page``, thus for parsing the value 0x01 in the second byte
> +we need to refer to HUT Sec 3.
> +
> +The second number is the actual data, and its meaning can be found in
> +the HUT. We have a ``Usage Page``, thus we need to refer to HUT
> +Sec. 3, "Usage Pages"; from there, one sees that ``0x01`` stands for
> +``Generic Desktop Page``.
> +
> +Moving now to the second two bytes, and following the same scheme,
> +``0x09`` (i.e. ``00001001``) will be followed by one byte (``01``)
> +and is a ``Local`` item (``10``). Thus, the meaning of the remaining four bits
> +(``0000``) is given in the HID spec Sec. 6.2.2.8 "Local Items", so that
> +we have a ``Usage``. From HUT, Sec. 4, "Generic Desktop Page", we see that
> +0x02 stands for ``Mouse``.
> +
> +The following numbers can be parsed in the same way.
> diff --git a/Documentation/hid/index.rst b/Documentation/hid/index.rst
> index b2028f382f11..af02cf7cfa82 100644
> --- a/Documentation/hid/index.rst
> +++ b/Documentation/hid/index.rst
> @@ -7,6 +7,7 @@ Human Interface Devices (HID)
> .. toctree::
> :maxdepth: 1
>
> + hidintro
> hiddev
> hidraw
> hid-sensor
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 7f2e8ba7d783..8d1699f355ec 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -341,6 +341,29 @@ struct hid_item {
> */
> #define MAX_USBHID_BOOT_QUIRKS 4
>
> +/**
> + * DOC: HID quirks
> + * | @HID_QUIRK_NOTOUCH:
> + * | @HID_QUIRK_IGNORE: ignore this device
> + * | @HID_QUIRK_NOGET:
> + * | @HID_QUIRK_HIDDEV_FORCE:
> + * | @HID_QUIRK_BADPAD:
> + * | @HID_QUIRK_MULTI_INPUT:
> + * | @HID_QUIRK_HIDINPUT_FORCE:
> + * | @HID_QUIRK_ALWAYS_POLL:
> + * | @HID_QUIRK_INPUT_PER_APP:
> + * | @HID_QUIRK_X_INVERT:
> + * | @HID_QUIRK_Y_INVERT:
> + * | @HID_QUIRK_SKIP_OUTPUT_REPORTS:
> + * | @HID_QUIRK_SKIP_OUTPUT_REPORT_ID:
> + * | @HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP:
> + * | @HID_QUIRK_HAVE_SPECIAL_DRIVER:
> + * | @HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE:
> + * | @HID_QUIRK_FULLSPEED_INTERVAL:
> + * | @HID_QUIRK_NO_INIT_REPORTS:
> + * | @HID_QUIRK_NO_IGNORE:
> + * | @HID_QUIRK_NO_INPUT_SYNC:
> + */
> /* BIT(0) reserved for backward compatibility, was HID_QUIRK_INVERT */
> #define HID_QUIRK_NOTOUCH BIT(1)
> #define HID_QUIRK_IGNORE BIT(2)
^ permalink raw reply
* [PATCH v5] dt-bindings: MFD: Convert STMPE to YAML schema
From: Linus Walleij @ 2023-07-09 21:48 UTC (permalink / raw)
To: Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Maxime Coquelin, Alexandre Torgue, Dmitry Torokhov, Lee Jones,
Philippe Schenker, Stefan Agner, Marek Vasut, Steffen Trumtrar
Cc: linux-gpio, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, linux-input, Rob Herring, Linus Walleij
This converts the STMPE MFD device tree bindings to the YAML
schema.
Reference the existing schema for the ADC, just define the
other subnode schemas directly in the MFD schema.
Add two examples so we have examples covering both the simple
GPIO expander and the more complex with ADC and touchscreen.
Some in-tree users do not follow the naming conventions for nodes
so these DTS files need to be augmented to use proper node names
like "adc", "pwm", "gpio", "keyboard-controller" etc before the
bindings take effect on them.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
This adds the missing GPIO bindings for the STMPE port expander
and converts the existing MFD binding to YAML.
I suppose Lee can merge this when he's happy with it.
---
Changes in v5:
- Rebase on v6.5-rc1 meaning GPIO binding is merged
upstream and can be dropped.
- Link to v4: https://lore.kernel.org/r/20230426-stmpe-dt-bindings-v4-0-36fdd53d9919@linaro.org
Changes in v4:
- Make the GPIO bindings a conversion: there were some old
text bindings for the STMPE GPIO, we now delete them as
part of the patch.
- I expect Lee or the DT binding tree to pick both patches.
- Link to v3: https://lore.kernel.org/r/20230426-stmpe-dt-bindings-v3-0-eac1d736e488@linaro.org
Changes in v3:
- Update to review feedback
- Collected some ack/review tags
- Link to v2: https://lore.kernel.org/r/20230426-stmpe-dt-bindings-v2-0-2f85a1fffcda@linaro.org
Changes in v2:
- Split off a separate GPIO binding
- Updated the MFD binding according to feedback
---
ChangeLog v4->v5:
- Rebase on v6.5-rc1
ChangeLog v3->v4:
- No changes.
ChangeLog v2->v3:
- Drop the required pwm properties already required by the
template pwm schema.
- Add the number of PWM cells as const.
ChangeLog v1->v2:
- Split off the GPIO bindings to their own schema, as the old
bindings didn't even have any GPIO bindings. Put the GPIO
schema before this schema so we can use GPIO in the examples.
- Drop nodename and pattern as STMPE is not a generic name.
- Add maxItems to the resets.
- Make wakeup-source just :true, as it is a generic property.
- Move unevaluatedProperties for subnodes right before properties
as requested.
- Name devices "port-expander" in the examples.
- Use lowercase hex in line init.
---
.../devicetree/bindings/input/stmpe-keypad.txt | 41 ---
.../bindings/input/touchscreen/stmpe.txt | 108 --------
.../devicetree/bindings/mfd/st,stmpe.yaml | 297 +++++++++++++++++++++
Documentation/devicetree/bindings/mfd/stmpe.txt | 42 ---
4 files changed, 297 insertions(+), 191 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/stmpe-keypad.txt b/Documentation/devicetree/bindings/input/stmpe-keypad.txt
deleted file mode 100644
index 12bb771d66d4..000000000000
--- a/Documentation/devicetree/bindings/input/stmpe-keypad.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* STMPE Keypad
-
-Required properties:
- - compatible : "st,stmpe-keypad"
- - linux,keymap : See ./matrix-keymap.txt
-
-Optional properties:
- - debounce-interval : Debouncing interval time in milliseconds
- - st,scan-count : Scanning cycles elapsed before key data is updated
- - st,no-autorepeat : If specified device will not autorepeat
- - keypad,num-rows : See ./matrix-keymap.txt
- - keypad,num-columns : See ./matrix-keymap.txt
-
-Example:
-
- stmpe_keypad {
- compatible = "st,stmpe-keypad";
-
- debounce-interval = <64>;
- st,scan-count = <8>;
- st,no-autorepeat;
-
- linux,keymap = <0x205006b
- 0x4010074
- 0x3050072
- 0x1030004
- 0x502006a
- 0x500000a
- 0x5008b
- 0x706001c
- 0x405000b
- 0x6070003
- 0x3040067
- 0x303006c
- 0x60400e7
- 0x602009e
- 0x4020073
- 0x5050002
- 0x4030069
- 0x3020008>;
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
deleted file mode 100644
index 238b51555c04..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
+++ /dev/null
@@ -1,108 +0,0 @@
-STMPE Touchscreen
-----------------
-
-Required properties:
- - compatible: "st,stmpe-ts"
-
-Optional properties:
-- st,ave-ctrl : Sample average control
- 0 -> 1 sample
- 1 -> 2 samples
- 2 -> 4 samples
- 3 -> 8 samples
-- st,touch-det-delay : Touch detect interrupt delay (recommended is 3)
- 0 -> 10 us
- 1 -> 50 us
- 2 -> 100 us
- 3 -> 500 us
- 4 -> 1 ms
- 5 -> 5 ms
- 6 -> 10 ms
- 7 -> 50 ms
-- st,settling : Panel driver settling time (recommended is 2)
- 0 -> 10 us
- 1 -> 100 us
- 2 -> 500 us
- 3 -> 1 ms
- 4 -> 5 ms
- 5 -> 10 ms
- 6 -> 50 ms
- 7 -> 100 ms
-- st,fraction-z : Length of the fractional part in z (recommended is 7)
- (fraction-z ([0..7]) = Count of the fractional part)
-- st,i-drive : current limit value of the touchscreen drivers
- 0 -> 20 mA (typical 35mA max)
- 1 -> 50 mA (typical 80 mA max)
-
-Optional properties common with MFD (deprecated):
- - st,sample-time : ADC conversion time in number of clock.
- 0 -> 36 clocks
- 1 -> 44 clocks
- 2 -> 56 clocks
- 3 -> 64 clocks
- 4 -> 80 clocks (recommended)
- 5 -> 96 clocks
- 6 -> 124 clocks
- - st,mod-12b : ADC Bit mode
- 0 -> 10bit ADC
- 1 -> 12bit ADC
- - st,ref-sel : ADC reference source
- 0 -> internal
- 1 -> external
- - st,adc-freq : ADC Clock speed
- 0 -> 1.625 MHz
- 1 -> 3.25 MHz
- 2 || 3 -> 6.5 MHz
-
-Node should be child node of stmpe node to which it belongs.
-
-Note that common ADC settings of stmpe_touchscreen (child) will take precedence
-over the settings done in MFD.
-
-Example:
-
-stmpe811@41 {
- compatible = "st,stmpe811";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_touch_int>;
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x41>;
- interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
- interrupt-parent = <&gpio4>;
- interrupt-controller;
- id = <0>;
- blocks = <0x5>;
- irq-trigger = <0x1>;
- /* Common ADC settings */
- /* 3.25 MHz ADC clock speed */
- st,adc-freq = <1>;
- /* 12-bit ADC */
- st,mod-12b = <1>;
- /* internal ADC reference */
- st,ref-sel = <0>;
- /* ADC converstion time: 80 clocks */
- st,sample-time = <4>;
-
- stmpe_touchscreen {
- compatible = "st,stmpe-ts";
- reg = <0>;
- /* 8 sample average control */
- st,ave-ctrl = <3>;
- /* 5 ms touch detect interrupt delay */
- st,touch-det-delay = <5>;
- /* 1 ms panel driver settling time */
- st,settling = <3>;
- /* 7 length fractional part in z */
- st,fraction-z = <7>;
- /*
- * 50 mA typical 80 mA max touchscreen drivers
- * current limit value
- */
- st,i-drive = <1>;
- };
- stmpe_adc {
- compatible = "st,stmpe-adc";
- st,norequest-mask = <0x0F>;
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
new file mode 100644
index 000000000000..b77cc3f3075d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
@@ -0,0 +1,297 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/st,stmpe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectonics Port Expander (STMPE)
+
+description: STMicroelectronics Port Expander (STMPE) is a series of slow
+ bus controllers for various expanded peripherals such as GPIO, keypad,
+ touchscreen, ADC, PWM or rotator. It can contain one or several different
+ peripherals connected to SPI or I2C.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,stmpe601
+ - st,stmpe801
+ - st,stmpe811
+ - st,stmpe1600
+ - st,stmpe1601
+ - st,stmpe2401
+ - st,stmpe2403
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vcc-supply: true
+
+ vio-supply: true
+
+ reset-gpios:
+ maxItems: 1
+
+ wakeup-source: true
+
+ st,autosleep-timeout:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 4, 16, 32, 64, 128, 256, 512, 1024 ]
+ description: Time idle before going to automatic sleep to save power
+
+ st,sample-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6 ]
+ description: |
+ Sample time per iteration
+ 0 = 36 clock ticks
+ 1 = 44 clock ticks
+ 2 = 56 clock ticks
+ 3 = 64 clock ticks
+ 4 = 80 clock ticks - recommended
+ 5 = 96 clock ticks
+ 6 = 124 clock ticks
+
+ st,mod-12b:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: ADC bit mode 0 = 10bit ADC, 1 = 12bit ADC
+
+ st,ref-sel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: ADC reference source 0 = internal, 1 = external
+
+ st,adc-freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ ADC clock speed
+ 0 = 1.625 MHz
+ 1 = 3.25 MHz
+ 2, 3 = 6.5 MHz
+
+ adc:
+ type: object
+ $ref: /schemas/iio/adc/st,stmpe-adc.yaml#
+
+ gpio:
+ type: object
+ $ref: /schemas/gpio/st,stmpe-gpio.yaml#
+
+ keyboard-controller:
+ type: object
+ $ref: /schemas/input/matrix-keymap.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: st,stmpe-keypad
+
+ debounce-interval:
+ description: Debouncing interval in milliseconds
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ st,no-autorepeat:
+ description: If present, the keys will not autorepeat when pressed
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,scan-count:
+ description: Scanning cycles elapsed before key data is updated
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - compatible
+ - linux,keymap
+
+ pwm:
+ type: object
+ $ref: /schemas/pwm/pwm.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: st,stmpe-pwm
+
+ "#pwm-cells":
+ const: 2
+
+ touchscreen:
+ type: object
+ $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: st,stmpe-ts
+
+ st,ave-ctrl:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ Sample average control
+ 0 = 1 sample
+ 1 = 2 samples
+ 2 = 4 samples
+ 3 = 8 samples
+
+ st,touch-det-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ description: |
+ Touch detection delay
+ 0 = 10 us
+ 1 = 50 us
+ 2 = 100 us
+ 3 = 500 us - recommended
+ 4 = 1 ms
+ 5 = 5 ms
+ 6 = 10 ms
+ 7 = 50 ms
+
+ st,settling:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ description: |
+ Panel driver settling time
+ 0 = 10 us
+ 1 = 100 us
+ 2 = 500 us - recommended
+ 3 = 1 ms
+ 4 = 5 ms
+ 5 = 10 ms
+ 6 = 50 ms
+ 7 = 100 ms
+
+ st,fraction-z:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ description: Length of the fractional part in z, recommended is 7
+ (fraction-z ([0..7]) = Count of the fractional part)
+
+ st,i-drive:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: |
+ current limit value of the touchscreen drivers
+ 0 = 20 mA (typical 35 mA max)
+ 1 = 50 mA (typical 80 mA max)
+
+ required:
+ - compatible
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/input/input.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port-expander@43 {
+ compatible = "st,stmpe2401";
+ reg = <0x43>;
+ reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ vcc-supply = <&db8500_vsmps2_reg>;
+ vio-supply = <&db8500_vsmps2_reg>;
+ wakeup-source;
+ st,autosleep-timeout = <1024>;
+
+ gpio {
+ compatible = "st,stmpe-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ st,norequest-mask = <0xf0f002>;
+ };
+
+ keyboard-controller {
+ compatible = "st,stmpe-keypad";
+ debounce-interval = <64>;
+ st,scan-count = <8>;
+ st,no-autorepeat;
+ keypad,num-rows = <8>;
+ keypad,num-columns = <8>;
+ linux,keymap = <
+ MATRIX_KEY(0x00, 0x00, KEY_1)
+ MATRIX_KEY(0x00, 0x01, KEY_2)
+ MATRIX_KEY(0x00, 0x02, KEY_3)
+ MATRIX_KEY(0x00, 0x03, KEY_4)
+ MATRIX_KEY(0x00, 0x04, KEY_5)
+ MATRIX_KEY(0x00, 0x05, KEY_6)
+ MATRIX_KEY(0x00, 0x06, KEY_7)
+ MATRIX_KEY(0x00, 0x07, KEY_8)
+ MATRIX_KEY(0x00, 0x08, KEY_9)
+ MATRIX_KEY(0x00, 0x09, KEY_0)
+ >;
+ };
+
+ pwm {
+ compatible = "st,stmpe-pwm";
+ #pwm-cells = <2>;
+ };
+ };
+
+ port-expander@41 {
+ compatible = "st,stmpe811";
+ reg = <0x41>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ st,adc-freq = <1>;
+ st,mod-12b = <1>;
+ st,ref-sel = <0>;
+ st,sample-time = <4>;
+
+ adc {
+ compatible = "st,stmpe-adc";
+ st,norequest-mask = <0x0f>;
+ #io-channel-cells = <1>;
+ };
+
+ gpio {
+ compatible = "st,stmpe-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ pwm {
+ compatible = "st,stmpe-pwm";
+ #pwm-cells = <2>;
+ };
+
+ touchscreen {
+ compatible = "st,stmpe-ts";
+ st,ave-ctrl = <3>;
+ st,touch-det-delay = <5>;
+ st,settling = <3>;
+ st,fraction-z = <7>;
+ st,i-drive = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
deleted file mode 100644
index d4408a417193..000000000000
--- a/Documentation/devicetree/bindings/mfd/stmpe.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* ST Microelectronics STMPE Multi-Functional Device
-
-STMPE is an MFD device which may expose the following inbuilt devices: gpio,
-keypad, touchscreen, adc, pwm, rotator.
-
-Required properties:
- - compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]"
- - reg : I2C/SPI address of the device
-
-Optional properties:
- - interrupts : The interrupt outputs from the controller
- - interrupt-controller : Marks the device node as an interrupt controller
- - wakeup-source : Marks the input device as wakable
- - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
- - irq-gpio : If present, which GPIO to use for event IRQ
-
-Optional properties for devices with touch and ADC (STMPE811|STMPE610):
- - st,sample-time : ADC conversion time in number of clock.
- 0 -> 36 clocks 4 -> 80 clocks (recommended)
- 1 -> 44 clocks 5 -> 96 clocks
- 2 -> 56 clocks 6 -> 124 clocks
- 3 -> 64 clocks
- - st,mod-12b : ADC Bit mode
- 0 -> 10bit ADC 1 -> 12bit ADC
- - st,ref-sel : ADC reference source
- 0 -> internal 1 -> external
- - st,adc-freq : ADC Clock speed
- 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
- 1 -> 3.25 MHz
-
-Example:
-
- stmpe1601: stmpe1601@40 {
- compatible = "st,stmpe1601";
- reg = <0x40>;
- interrupts = <26 0x4>;
- interrupt-parent = <&gpio6>;
- interrupt-controller;
-
- wakeup-source;
- st,autosleep-timeout = <1024>;
- };
---
base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
change-id: 20230426-stmpe-dt-bindings-c3479dd71a28
Best regards,
--
Linus Walleij <linus.walleij@linaro.org>
^ permalink raw reply related
* [PATCH v3] HID: hid-google-stadiaff: add support for Stadia force feedback
From: Fabio Baltieri @ 2023-07-09 21:44 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Rahul Rameshbabu, linux-input, linux-kernel,
Fabio Baltieri
Add a hid-stadiaff module to support rumble based force feedback on the
Google Stadia controller. This works using the HID output endpoint
exposed on both the USB and BLE interface.
Signed-off-by: Fabio Baltieri <fabiobaltieri@chromium.org>
---
Hi, this adds rumble support to the stadia controller using the input
interface. Up to now this has only been implemented at application level
using hidraw:
https://source.chromium.org/chromium/chromium/src/+/main:device/gamepad/hid_haptic_gamepad.cc
Tested with fftest, works both over USB and BLE.
Changes from v2:
- check stadiaff_init value at probe time and fail the probe if init
fails
Changes from v1:
- renamed the module to hid-google-stadiaff.c
- added locking for passing the state to the worker code
- added a module removed check to prevent the work from rescheduling
drivers/hid/Kconfig | 7 ++
drivers/hid/Makefile | 1 +
drivers/hid/hid-google-stadiaff.c | 158 ++++++++++++++++++++++++++++++
drivers/hid/hid-ids.h | 1 +
4 files changed, 167 insertions(+)
create mode 100644 drivers/hid/hid-google-stadiaff.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 4ce012f83253..ea1646384b20 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -412,6 +412,13 @@ config HID_GOOGLE_HAMMER
help
Say Y here if you have a Google Hammer device.
+config HID_GOOGLE_STADIA_FF
+ tristate "Google Stadia force feedback"
+ select INPUT_FF_MEMLESS
+ help
+ Say Y here if you want to enable force feedback support for the Google
+ Stadia controller.
+
config HID_VIVALDI
tristate "Vivaldi Keyboard"
select HID_VIVALDI_COMMON
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 5d37cacbde33..18e9a3afecab 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
obj-$(CONFIG_HID_GLORIOUS) += hid-glorious.o
obj-$(CONFIG_HID_VIVALDI_COMMON) += hid-vivaldi-common.o
obj-$(CONFIG_HID_GOOGLE_HAMMER) += hid-google-hammer.o
+obj-$(CONFIG_HID_GOOGLE_STADIA_FF) += hid-google-stadiaff.o
obj-$(CONFIG_HID_VIVALDI) += hid-vivaldi.o
obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
diff --git a/drivers/hid/hid-google-stadiaff.c b/drivers/hid/hid-google-stadiaff.c
new file mode 100644
index 000000000000..f8ca7209917d
--- /dev/null
+++ b/drivers/hid/hid-google-stadiaff.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Stadia controller rumble support.
+ *
+ * Copyright 2023 Google LLC
+ */
+
+#include <linux/hid.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+
+#include "hid-ids.h"
+
+#define STADIA_FF_REPORT_ID 5
+
+struct stadiaff_device {
+ struct hid_device *hid;
+ struct hid_report *report;
+ spinlock_t lock;
+ bool removed;
+ uint16_t strong_magnitude;
+ uint16_t weak_magnitude;
+ struct work_struct work;
+};
+
+static void stadiaff_work(struct work_struct *work)
+{
+ struct stadiaff_device *stadiaff =
+ container_of(work, struct stadiaff_device, work);
+ struct hid_field *rumble_field = stadiaff->report->field[0];
+ unsigned long flags;
+
+ spin_lock_irqsave(&stadiaff->lock, flags);
+ rumble_field->value[0] = stadiaff->strong_magnitude;
+ rumble_field->value[1] = stadiaff->weak_magnitude;
+ spin_unlock_irqrestore(&stadiaff->lock, flags);
+
+ hid_hw_request(stadiaff->hid, stadiaff->report, HID_REQ_SET_REPORT);
+}
+
+static int stadiaff_play(struct input_dev *dev, void *data,
+ struct ff_effect *effect)
+{
+ struct hid_device *hid = input_get_drvdata(dev);
+ struct stadiaff_device *stadiaff = hid_get_drvdata(hid);
+ unsigned long flags;
+
+ spin_lock_irqsave(&stadiaff->lock, flags);
+ if (!stadiaff->removed) {
+ stadiaff->strong_magnitude = effect->u.rumble.strong_magnitude;
+ stadiaff->weak_magnitude = effect->u.rumble.weak_magnitude;
+ schedule_work(&stadiaff->work);
+ }
+ spin_unlock_irqrestore(&stadiaff->lock, flags);
+
+ return 0;
+}
+
+static int stadiaff_init(struct hid_device *hid)
+{
+ struct stadiaff_device *stadiaff;
+ struct hid_report *report;
+ struct hid_input *hidinput;
+ struct input_dev *dev;
+ int error;
+
+ if (list_empty(&hid->inputs)) {
+ hid_err(hid, "no inputs found\n");
+ return -ENODEV;
+ }
+ hidinput = list_entry(hid->inputs.next, struct hid_input, list);
+ dev = hidinput->input;
+
+ report = hid_validate_values(hid, HID_OUTPUT_REPORT,
+ STADIA_FF_REPORT_ID, 0, 2);
+ if (!report)
+ return -ENODEV;
+
+ stadiaff = devm_kzalloc(&hid->dev, sizeof(struct stadiaff_device),
+ GFP_KERNEL);
+ if (!stadiaff)
+ return -ENOMEM;
+
+ hid_set_drvdata(hid, stadiaff);
+
+ input_set_capability(dev, EV_FF, FF_RUMBLE);
+
+ error = input_ff_create_memless(dev, NULL, stadiaff_play);
+ if (error)
+ return error;
+
+ stadiaff->removed = false;
+ stadiaff->hid = hid;
+ stadiaff->report = report;
+ INIT_WORK(&stadiaff->work, stadiaff_work);
+ spin_lock_init(&stadiaff->lock);
+
+ hid_info(hid, "Force Feedback for Google Stadia controller\n");
+
+ return 0;
+}
+
+static int stadia_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+
+ ret = hid_parse(hdev);
+ if (ret) {
+ hid_err(hdev, "parse failed\n");
+ return ret;
+ }
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT & ~HID_CONNECT_FF);
+ if (ret) {
+ hid_err(hdev, "hw start failed\n");
+ return ret;
+ }
+
+ ret = stadiaff_init(hdev);
+ if (ret) {
+ dev_err(&hdev->dev, "force feedback init failed\n");
+ hid_hw_stop(hdev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void stadia_remove(struct hid_device *hid)
+{
+ struct stadiaff_device *stadiaff = hid_get_drvdata(hid);
+ unsigned long flags;
+
+ spin_lock_irqsave(&stadiaff->lock, flags);
+ stadiaff->removed = true;
+ spin_unlock_irqrestore(&stadiaff->lock, flags);
+
+ cancel_work_sync(&stadiaff->work);
+ hid_hw_stop(hid);
+}
+
+static const struct hid_device_id stadia_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STADIA) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STADIA) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, stadia_devices);
+
+static struct hid_driver stadia_driver = {
+ .name = "stadia",
+ .id_table = stadia_devices,
+ .probe = stadia_probe,
+ .remove = stadia_remove,
+};
+module_hid_driver(stadia_driver);
+
+MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index d79e946acdcb..366c95904e4f 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -529,6 +529,7 @@
#define USB_DEVICE_ID_GOOGLE_MOONBALL 0x5044
#define USB_DEVICE_ID_GOOGLE_DON 0x5050
#define USB_DEVICE_ID_GOOGLE_EEL 0x5057
+#define USB_DEVICE_ID_GOOGLE_STADIA 0x9400
#define USB_VENDOR_ID_GOTOP 0x08f2
#define USB_DEVICE_ID_SUPER_Q2 0x007f
--
2.41.0.255.g8b1d071c50-goog
^ permalink raw reply related
* [PATCH v2 4/4] Input: iqs7222 - add support for Azoteq IQS7222D
From: Jeff LaBundy @ 2023-07-09 17:07 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt
Cc: linux-input, devicetree, jeff
In-Reply-To: <ZKrotyhz7eueujys@nixie71>
The vendor has introduced a new variant of silicon which is highly
similar to the existing IQS7222A, but with its independent sliders
essentially replaced with a single-contact trackpad.
Update the common driver to support this new device's register map
and report trackpad events. As with the IQS7222A, the new IQS7222D
can report both raw coordinates as well as gestures.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
---
drivers/input/misc/Kconfig | 4 +-
drivers/input/misc/iqs7222.c | 468 ++++++++++++++++++++++++++++++++++-
2 files changed, 461 insertions(+), 11 deletions(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 81a54a59e13c..c47eecc6f83b 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -791,10 +791,10 @@ config INPUT_IQS626A
module will be called iqs626a.
config INPUT_IQS7222
- tristate "Azoteq IQS7222A/B/C capacitive touch controller"
+ tristate "Azoteq IQS7222A/B/C/D capacitive touch controller"
depends on I2C
help
- Say Y to enable support for the Azoteq IQS7222A/B/C family
+ Say Y to enable support for the Azoteq IQS7222A/B/C/D family
of capacitive touch controllers.
To compile this driver as a module, choose M here: the
diff --git a/drivers/input/misc/iqs7222.c b/drivers/input/misc/iqs7222.c
index acb95048e823..a9c1dba1e8c1 100644
--- a/drivers/input/misc/iqs7222.c
+++ b/drivers/input/misc/iqs7222.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * Azoteq IQS7222A/B/C Capacitive Touch Controller
+ * Azoteq IQS7222A/B/C/D Capacitive Touch Controller
*
* Copyright (C) 2022 Jeff LaBundy <jeff@labundy.com>
*/
@@ -12,6 +12,7 @@
#include <linux/gpio/consumer.h>
#include <linux/i2c.h>
#include <linux/input.h>
+#include <linux/input/touchscreen.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/ktime.h>
@@ -25,6 +26,7 @@
#define IQS7222_PROD_NUM_A 840
#define IQS7222_PROD_NUM_B 698
#define IQS7222_PROD_NUM_C 863
+#define IQS7222_PROD_NUM_D 1046
#define IQS7222_SYS_STATUS 0x10
#define IQS7222_SYS_STATUS_RESET BIT(3)
@@ -54,6 +56,7 @@
#define IQS7222_EVENT_MASK_ATI BIT(12)
#define IQS7222_EVENT_MASK_SLDR BIT(10)
+#define IQS7222_EVENT_MASK_TPAD IQS7222_EVENT_MASK_SLDR
#define IQS7222_EVENT_MASK_TOUCH BIT(1)
#define IQS7222_EVENT_MASK_PROX BIT(0)
@@ -71,6 +74,7 @@
#define IQS7222_MAX_COLS_CHAN 6
#define IQS7222_MAX_COLS_FILT 2
#define IQS7222_MAX_COLS_SLDR 11
+#define IQS7222_MAX_COLS_TPAD 24
#define IQS7222_MAX_COLS_GPIO 3
#define IQS7222_MAX_COLS_SYS 13
@@ -102,16 +106,18 @@ enum iqs7222_reg_grp_id {
IQS7222_REG_GRP_BTN,
IQS7222_REG_GRP_CHAN,
IQS7222_REG_GRP_SLDR,
+ IQS7222_REG_GRP_TPAD,
IQS7222_REG_GRP_GPIO,
IQS7222_REG_GRP_SYS,
IQS7222_NUM_REG_GRPS
};
static const char * const iqs7222_reg_grp_names[IQS7222_NUM_REG_GRPS] = {
- [IQS7222_REG_GRP_CYCLE] = "cycle",
- [IQS7222_REG_GRP_CHAN] = "channel",
- [IQS7222_REG_GRP_SLDR] = "slider",
- [IQS7222_REG_GRP_GPIO] = "gpio",
+ [IQS7222_REG_GRP_CYCLE] = "cycle-%d",
+ [IQS7222_REG_GRP_CHAN] = "channel-%d",
+ [IQS7222_REG_GRP_SLDR] = "slider-%d",
+ [IQS7222_REG_GRP_TPAD] = "trackpad",
+ [IQS7222_REG_GRP_GPIO] = "gpio-%d",
};
static const unsigned int iqs7222_max_cols[IQS7222_NUM_REG_GRPS] = {
@@ -122,6 +128,7 @@ static const unsigned int iqs7222_max_cols[IQS7222_NUM_REG_GRPS] = {
[IQS7222_REG_GRP_CHAN] = IQS7222_MAX_COLS_CHAN,
[IQS7222_REG_GRP_FILT] = IQS7222_MAX_COLS_FILT,
[IQS7222_REG_GRP_SLDR] = IQS7222_MAX_COLS_SLDR,
+ [IQS7222_REG_GRP_TPAD] = IQS7222_MAX_COLS_TPAD,
[IQS7222_REG_GRP_GPIO] = IQS7222_MAX_COLS_GPIO,
[IQS7222_REG_GRP_SYS] = IQS7222_MAX_COLS_SYS,
};
@@ -130,8 +137,10 @@ static const unsigned int iqs7222_gpio_links[] = { 2, 5, 6, };
struct iqs7222_event_desc {
const char *name;
+ u16 link;
u16 mask;
u16 val;
+ u16 strict;
u16 enable;
enum iqs7222_reg_key_id reg_key;
};
@@ -188,6 +197,93 @@ static const struct iqs7222_event_desc iqs7222_sl_events[] = {
},
};
+static const struct iqs7222_event_desc iqs7222_tp_events[] = {
+ {
+ .name = "event-press",
+ .link = BIT(7),
+ },
+ {
+ .name = "event-tap",
+ .link = BIT(0),
+ .mask = BIT(0),
+ .val = BIT(0),
+ .enable = BIT(0),
+ .reg_key = IQS7222_REG_KEY_TAP,
+ },
+ {
+ .name = "event-swipe-x-pos",
+ .link = BIT(2),
+ .mask = BIT(2) | BIT(1),
+ .val = BIT(2),
+ .strict = BIT(4),
+ .enable = BIT(1),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-swipe-y-pos",
+ .link = BIT(3),
+ .mask = BIT(3) | BIT(1),
+ .val = BIT(3),
+ .strict = BIT(3),
+ .enable = BIT(1),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-swipe-x-neg",
+ .link = BIT(4),
+ .mask = BIT(4) | BIT(1),
+ .val = BIT(4),
+ .strict = BIT(4),
+ .enable = BIT(1),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-swipe-y-neg",
+ .link = BIT(5),
+ .mask = BIT(5) | BIT(1),
+ .val = BIT(5),
+ .strict = BIT(3),
+ .enable = BIT(1),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-flick-x-pos",
+ .link = BIT(2),
+ .mask = BIT(2) | BIT(1),
+ .val = BIT(2) | BIT(1),
+ .strict = BIT(4),
+ .enable = BIT(2),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-flick-y-pos",
+ .link = BIT(3),
+ .mask = BIT(3) | BIT(1),
+ .val = BIT(3) | BIT(1),
+ .strict = BIT(3),
+ .enable = BIT(2),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-flick-x-neg",
+ .link = BIT(4),
+ .mask = BIT(4) | BIT(1),
+ .val = BIT(4) | BIT(1),
+ .strict = BIT(4),
+ .enable = BIT(2),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-flick-y-neg",
+ .link = BIT(5),
+ .mask = BIT(5) | BIT(1),
+ .val = BIT(5) | BIT(1),
+ .strict = BIT(3),
+ .enable = BIT(2),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+};
+
struct iqs7222_reg_grp_desc {
u16 base;
int num_row;
@@ -524,6 +620,62 @@ static const struct iqs7222_dev_desc iqs7222_devs[] = {
},
},
},
+ {
+ .prod_num = IQS7222_PROD_NUM_D,
+ .fw_major = 0,
+ .fw_minor = 37,
+ .touch_link = 1770,
+ .allow_offset = 9,
+ .event_offset = 10,
+ .comms_offset = 11,
+ .reg_grps = {
+ [IQS7222_REG_GRP_STAT] = {
+ .base = IQS7222_SYS_STATUS,
+ .num_row = 1,
+ .num_col = 7,
+ },
+ [IQS7222_REG_GRP_CYCLE] = {
+ .base = 0x8000,
+ .num_row = 7,
+ .num_col = 2,
+ },
+ [IQS7222_REG_GRP_GLBL] = {
+ .base = 0x8700,
+ .num_row = 1,
+ .num_col = 3,
+ },
+ [IQS7222_REG_GRP_BTN] = {
+ .base = 0x9000,
+ .num_row = 14,
+ .num_col = 3,
+ },
+ [IQS7222_REG_GRP_CHAN] = {
+ .base = 0xA000,
+ .num_row = 14,
+ .num_col = 4,
+ },
+ [IQS7222_REG_GRP_FILT] = {
+ .base = 0xAE00,
+ .num_row = 1,
+ .num_col = 2,
+ },
+ [IQS7222_REG_GRP_TPAD] = {
+ .base = 0xB000,
+ .num_row = 1,
+ .num_col = 24,
+ },
+ [IQS7222_REG_GRP_GPIO] = {
+ .base = 0xC000,
+ .num_row = 3,
+ .num_col = 3,
+ },
+ [IQS7222_REG_GRP_SYS] = {
+ .base = IQS7222_SYS_SETUP,
+ .num_row = 1,
+ .num_col = 12,
+ },
+ },
+ },
};
struct iqs7222_prop_desc {
@@ -1008,6 +1160,123 @@ static const struct iqs7222_prop_desc iqs7222_props[] = {
.val_pitch = 4,
.label = "maximum gesture time",
},
+ {
+ .name = "azoteq,num-rows",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 0,
+ .reg_shift = 4,
+ .reg_width = 4,
+ .val_min = 1,
+ .val_max = 12,
+ .label = "number of rows",
+ },
+ {
+ .name = "azoteq,num-cols",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 0,
+ .reg_shift = 0,
+ .reg_width = 4,
+ .val_min = 1,
+ .val_max = 12,
+ .label = "number of columns",
+ },
+ {
+ .name = "azoteq,lower-cal-y",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 1,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .label = "lower vertical calibration",
+ },
+ {
+ .name = "azoteq,lower-cal-x",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 1,
+ .reg_shift = 0,
+ .reg_width = 8,
+ .label = "lower horizontal calibration",
+ },
+ {
+ .name = "azoteq,upper-cal-y",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 2,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .label = "upper vertical calibration",
+ },
+ {
+ .name = "azoteq,upper-cal-x",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 2,
+ .reg_shift = 0,
+ .reg_width = 8,
+ .label = "upper horizontal calibration",
+ },
+ {
+ .name = "azoteq,top-speed",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 3,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .val_pitch = 4,
+ .label = "top speed",
+ },
+ {
+ .name = "azoteq,bottom-speed",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 3,
+ .reg_shift = 0,
+ .reg_width = 8,
+ .label = "bottom speed",
+ },
+ {
+ .name = "azoteq,gesture-min-ms",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_TAP,
+ .reg_offset = 20,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .val_pitch = 16,
+ .label = "minimum gesture time",
+ },
+ {
+ .name = "azoteq,gesture-max-ms",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ .reg_offset = 21,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .val_pitch = 16,
+ .label = "maximum gesture time",
+ },
+ {
+ .name = "azoteq,gesture-max-ms",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_TAP,
+ .reg_offset = 21,
+ .reg_shift = 0,
+ .reg_width = 8,
+ .val_pitch = 16,
+ .label = "maximum gesture time",
+ },
+ {
+ .name = "azoteq,gesture-dist",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_TAP,
+ .reg_offset = 22,
+ .reg_shift = 0,
+ .reg_width = 16,
+ .label = "gesture distance",
+ },
+ {
+ .name = "azoteq,gesture-dist",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ .reg_offset = 23,
+ .reg_shift = 0,
+ .reg_width = 16,
+ .label = "gesture distance",
+ },
{
.name = "drive-open-drain",
.reg_grp = IQS7222_REG_GRP_GPIO,
@@ -1091,16 +1360,19 @@ struct iqs7222_private {
struct gpio_desc *irq_gpio;
struct i2c_client *client;
struct input_dev *keypad;
+ struct touchscreen_properties prop;
unsigned int kp_type[IQS7222_MAX_CHAN][ARRAY_SIZE(iqs7222_kp_events)];
unsigned int kp_code[IQS7222_MAX_CHAN][ARRAY_SIZE(iqs7222_kp_events)];
unsigned int sl_code[IQS7222_MAX_SLDR][ARRAY_SIZE(iqs7222_sl_events)];
unsigned int sl_axis[IQS7222_MAX_SLDR];
+ unsigned int tp_code[ARRAY_SIZE(iqs7222_tp_events)];
u16 cycle_setup[IQS7222_MAX_CHAN / 2][IQS7222_MAX_COLS_CYCLE];
u16 glbl_setup[IQS7222_MAX_COLS_GLBL];
u16 btn_setup[IQS7222_MAX_CHAN][IQS7222_MAX_COLS_BTN];
u16 chan_setup[IQS7222_MAX_CHAN][IQS7222_MAX_COLS_CHAN];
u16 filt_setup[IQS7222_MAX_COLS_FILT];
u16 sldr_setup[IQS7222_MAX_SLDR][IQS7222_MAX_COLS_SLDR];
+ u16 tpad_setup[IQS7222_MAX_COLS_TPAD];
u16 gpio_setup[ARRAY_SIZE(iqs7222_gpio_links)][IQS7222_MAX_COLS_GPIO];
u16 sys_setup[IQS7222_MAX_COLS_SYS];
};
@@ -1127,6 +1399,9 @@ static u16 *iqs7222_setup(struct iqs7222_private *iqs7222,
case IQS7222_REG_GRP_SLDR:
return iqs7222->sldr_setup[row];
+ case IQS7222_REG_GRP_TPAD:
+ return iqs7222->tpad_setup;
+
case IQS7222_REG_GRP_GPIO:
return iqs7222->gpio_setup[row];
@@ -1936,6 +2211,14 @@ static int iqs7222_parse_chan(struct iqs7222_private *iqs7222,
ref_setup[4] = dev_desc->touch_link;
if (fwnode_property_present(chan_node, "azoteq,use-prox"))
ref_setup[4] -= 2;
+ } else if (dev_desc->reg_grps[IQS7222_REG_GRP_TPAD].num_row &&
+ fwnode_property_present(chan_node,
+ "azoteq,counts-filt-enable")) {
+ /*
+ * In the case of IQS7222D, however, the reference mode field
+ * is partially repurposed as a counts filter enable control.
+ */
+ chan_setup[0] |= IQS7222_CHAN_SETUP_0_REF_MODE_REF;
}
if (fwnode_property_present(chan_node, "azoteq,rx-enable")) {
@@ -2278,6 +2561,136 @@ static int iqs7222_parse_sldr(struct iqs7222_private *iqs7222,
IQS7222_REG_KEY_NO_WHEEL);
}
+static int iqs7222_parse_tpad(struct iqs7222_private *iqs7222,
+ struct fwnode_handle *tpad_node, int tpad_index)
+{
+ const struct iqs7222_dev_desc *dev_desc = iqs7222->dev_desc;
+ struct touchscreen_properties *prop = &iqs7222->prop;
+ struct i2c_client *client = iqs7222->client;
+ int num_chan = dev_desc->reg_grps[IQS7222_REG_GRP_CHAN].num_row;
+ int count, error, i;
+ u16 *event_mask = &iqs7222->sys_setup[dev_desc->event_offset];
+ u16 *tpad_setup = iqs7222->tpad_setup;
+ unsigned int chan_sel[12];
+
+ error = iqs7222_parse_props(iqs7222, tpad_node, tpad_index,
+ IQS7222_REG_GRP_TPAD,
+ IQS7222_REG_KEY_NONE);
+ if (error)
+ return error;
+
+ count = fwnode_property_count_u32(tpad_node, "azoteq,channel-select");
+ if (count < 0) {
+ dev_err(&client->dev, "Failed to count %s channels: %d\n",
+ fwnode_get_name(tpad_node), count);
+ return count;
+ } else if (!count || count > ARRAY_SIZE(chan_sel)) {
+ dev_err(&client->dev, "Invalid number of %s channels\n",
+ fwnode_get_name(tpad_node));
+ return -EINVAL;
+ }
+
+ error = fwnode_property_read_u32_array(tpad_node,
+ "azoteq,channel-select",
+ chan_sel, count);
+ if (error) {
+ dev_err(&client->dev, "Failed to read %s channels: %d\n",
+ fwnode_get_name(tpad_node), error);
+ return error;
+ }
+
+ tpad_setup[6] &= ~GENMASK(num_chan - 1, 0);
+
+ for (i = 0; i < ARRAY_SIZE(chan_sel); i++) {
+ tpad_setup[8 + i] = 0;
+ if (i >= count || chan_sel[i] == U8_MAX)
+ continue;
+
+ if (chan_sel[i] >= num_chan) {
+ dev_err(&client->dev, "Invalid %s channel: %u\n",
+ fwnode_get_name(tpad_node), chan_sel[i]);
+ return -EINVAL;
+ }
+
+ /*
+ * The following fields indicate which channels participate in
+ * the trackpad, as well as each channel's relative placement.
+ */
+ tpad_setup[6] |= BIT(chan_sel[i]);
+ tpad_setup[8 + i] = chan_sel[i] * 34 + 1072;
+ }
+
+ tpad_setup[7] = dev_desc->touch_link;
+ if (fwnode_property_present(tpad_node, "azoteq,use-prox"))
+ tpad_setup[7] -= 2;
+
+ for (i = 0; i < ARRAY_SIZE(iqs7222_tp_events); i++)
+ tpad_setup[20] &= ~(iqs7222_tp_events[i].strict |
+ iqs7222_tp_events[i].enable);
+
+ for (i = 0; i < ARRAY_SIZE(iqs7222_tp_events); i++) {
+ const char *event_name = iqs7222_tp_events[i].name;
+ struct fwnode_handle *event_node;
+
+ event_node = fwnode_get_named_child_node(tpad_node, event_name);
+ if (!event_node)
+ continue;
+
+ if (fwnode_property_present(event_node,
+ "azoteq,gesture-angle-tighten"))
+ tpad_setup[20] |= iqs7222_tp_events[i].strict;
+
+ tpad_setup[20] |= iqs7222_tp_events[i].enable;
+
+ error = iqs7222_parse_event(iqs7222, event_node, tpad_index,
+ IQS7222_REG_GRP_TPAD,
+ iqs7222_tp_events[i].reg_key,
+ iqs7222_tp_events[i].link, 1566,
+ NULL,
+ &iqs7222->tp_code[i]);
+ fwnode_handle_put(event_node);
+ if (error)
+ return error;
+
+ if (!dev_desc->event_offset)
+ continue;
+
+ /*
+ * The press/release event is determined based on whether the
+ * coordinate fields report 0xFFFF and solely relies on touch
+ * or proximity interrupts to be unmasked.
+ */
+ if (i)
+ *event_mask |= IQS7222_EVENT_MASK_TPAD;
+ else if (tpad_setup[7] == dev_desc->touch_link)
+ *event_mask |= IQS7222_EVENT_MASK_TOUCH;
+ else
+ *event_mask |= IQS7222_EVENT_MASK_PROX;
+ }
+
+ if (!iqs7222->tp_code[0])
+ return 0;
+
+ input_set_abs_params(iqs7222->keypad, ABS_X,
+ 0, (tpad_setup[4] ? : 1) - 1, 0, 0);
+
+ input_set_abs_params(iqs7222->keypad, ABS_Y,
+ 0, (tpad_setup[5] ? : 1) - 1, 0, 0);
+
+ touchscreen_parse_properties(iqs7222->keypad, false, prop);
+
+ if (prop->max_x >= U16_MAX || prop->max_y >= U16_MAX) {
+ dev_err(&client->dev, "Invalid trackpad size: %u*%u\n",
+ prop->max_x, prop->max_y);
+ return -EINVAL;
+ }
+
+ tpad_setup[4] = prop->max_x + 1;
+ tpad_setup[5] = prop->max_y + 1;
+
+ return 0;
+}
+
static int (*iqs7222_parse_extra[IQS7222_NUM_REG_GRPS])
(struct iqs7222_private *iqs7222,
struct fwnode_handle *reg_grp_node,
@@ -2285,6 +2698,7 @@ static int (*iqs7222_parse_extra[IQS7222_NUM_REG_GRPS])
[IQS7222_REG_GRP_CYCLE] = iqs7222_parse_cycle,
[IQS7222_REG_GRP_CHAN] = iqs7222_parse_chan,
[IQS7222_REG_GRP_SLDR] = iqs7222_parse_sldr,
+ [IQS7222_REG_GRP_TPAD] = iqs7222_parse_tpad,
};
static int iqs7222_parse_reg_grp(struct iqs7222_private *iqs7222,
@@ -2298,7 +2712,7 @@ static int iqs7222_parse_reg_grp(struct iqs7222_private *iqs7222,
if (iqs7222_reg_grp_names[reg_grp]) {
char reg_grp_name[16];
- snprintf(reg_grp_name, sizeof(reg_grp_name), "%s-%d",
+ snprintf(reg_grp_name, sizeof(reg_grp_name),
iqs7222_reg_grp_names[reg_grp], reg_grp_index);
reg_grp_node = device_get_named_child_node(&client->dev,
@@ -2346,8 +2760,8 @@ static int iqs7222_parse_all(struct iqs7222_private *iqs7222)
continue;
/*
- * The IQS7222C exposes multiple GPIO and must be informed
- * as to which GPIO this group represents.
+ * The IQS7222C and IQS7222D expose multiple GPIO and must be
+ * informed as to which GPIO this group represents.
*/
for (j = 0; j < ARRAY_SIZE(iqs7222_gpio_links); j++)
gpio_setup[0] &= ~BIT(iqs7222_gpio_links[j]);
@@ -2480,6 +2894,41 @@ static int iqs7222_report(struct iqs7222_private *iqs7222)
iqs7222->sl_code[i][j], 0);
}
+ for (i = 0; i < dev_desc->reg_grps[IQS7222_REG_GRP_TPAD].num_row; i++) {
+ u16 tpad_pos_x = le16_to_cpu(status[4]);
+ u16 tpad_pos_y = le16_to_cpu(status[5]);
+ u16 state = le16_to_cpu(status[6]);
+
+ input_report_key(iqs7222->keypad, iqs7222->tp_code[0],
+ tpad_pos_x < U16_MAX);
+
+ if (tpad_pos_x < U16_MAX)
+ touchscreen_report_pos(iqs7222->keypad, &iqs7222->prop,
+ tpad_pos_x, tpad_pos_y, false);
+
+ if (!(le16_to_cpu(status[1]) & IQS7222_EVENT_MASK_TPAD))
+ continue;
+
+ /*
+ * Skip the press/release event, as it does not have separate
+ * status fields and is handled separately.
+ */
+ for (j = 1; j < ARRAY_SIZE(iqs7222_tp_events); j++) {
+ u16 mask = iqs7222_tp_events[j].mask;
+ u16 val = iqs7222_tp_events[j].val;
+
+ input_report_key(iqs7222->keypad,
+ iqs7222->tp_code[j],
+ (state & mask) == val);
+ }
+
+ input_sync(iqs7222->keypad);
+
+ for (j = 1; j < ARRAY_SIZE(iqs7222_tp_events); j++)
+ input_report_key(iqs7222->keypad,
+ iqs7222->tp_code[j], 0);
+ }
+
input_sync(iqs7222->keypad);
return 0;
@@ -2584,6 +3033,7 @@ static const struct of_device_id iqs7222_of_match[] = {
{ .compatible = "azoteq,iqs7222a" },
{ .compatible = "azoteq,iqs7222b" },
{ .compatible = "azoteq,iqs7222c" },
+ { .compatible = "azoteq,iqs7222d" },
{ }
};
MODULE_DEVICE_TABLE(of, iqs7222_of_match);
@@ -2598,5 +3048,5 @@ static struct i2c_driver iqs7222_i2c_driver = {
module_i2c_driver(iqs7222_i2c_driver);
MODULE_AUTHOR("Jeff LaBundy <jeff@labundy.com>");
-MODULE_DESCRIPTION("Azoteq IQS7222A/B/C Capacitive Touch Controller");
+MODULE_DESCRIPTION("Azoteq IQS7222A/B/C/D Capacitive Touch Controller");
MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: input: iqs7222: Add properties for Azoteq IQS7222D
From: Jeff LaBundy @ 2023-07-09 17:07 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt
Cc: linux-input, devicetree, jeff
In-Reply-To: <ZKrotyhz7eueujys@nixie71>
Extend the common binding to include a new variant of the silicon,
which effectively replaces a pair of slider nodes with a trackpad
node comprising the same or similar properties.
As part of this change, the if/then/else schema have been updated
to identify properties that are not supported by the new device.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
---
.../bindings/input/azoteq,iqs7222.yaml | 232 ++++++++++++++++--
1 file changed, 215 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
index 4c8690b62ce0..5b1769c19b17 100644
--- a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
+++ b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/input/azoteq,iqs7222.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Azoteq IQS7222A/B/C Capacitive Touch Controller
+title: Azoteq IQS7222A/B/C/D Capacitive Touch Controller
maintainers:
- Jeff LaBundy <jeff@labundy.com>
description: |
- The Azoteq IQS7222A, IQS7222B and IQS7222C are multichannel capacitive touch
- controllers that feature additional sensing capabilities.
+ The Azoteq IQS7222A, IQS7222B, IQS7222C and IQS7222D are multichannel
+ capacitive touch controllers that feature additional sensing capabilities.
Link to datasheets: https://www.azoteq.com/
@@ -21,6 +21,7 @@ properties:
- azoteq,iqs7222a
- azoteq,iqs7222b
- azoteq,iqs7222c
+ - azoteq,iqs7222d
reg:
maxItems: 1
@@ -173,6 +174,152 @@ properties:
maximum: 3000
description: Specifies the report rate (in ms) during ultra-low-power mode.
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-swapped-x-y: true
+
+ trackpad:
+ type: object
+ description: Represents all channels associated with the trackpad.
+
+ properties:
+ azoteq,channel-select:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 12
+ items:
+ minimum: 0
+ maximum: 13
+ description:
+ Specifies the order of the channels that participate in the trackpad.
+ Specify 255 to omit a given channel for the purpose of mapping a non-
+ rectangular trackpad.
+
+ azoteq,num-rows:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 12
+ description: Specifies the number of rows that comprise the trackpad.
+
+ azoteq,num-cols:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 12
+ description: Specifies the number of columns that comprise the trackpad.
+
+ azoteq,top-speed:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ multipleOf: 4
+ minimum: 0
+ maximum: 1020
+ description:
+ Specifies the speed (in coordinates traveled per conversion) after
+ which coordinate filtering is no longer applied.
+
+ azoteq,bottom-speed:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description:
+ Specifies the speed (in coordinates traveled per conversion) after
+ which coordinate filtering is linearly reduced.
+
+ azoteq,use-prox:
+ type: boolean
+ description:
+ Directs the trackpad to respond to the proximity states of the
+ selected channels instead of their corresponding touch states.
+ Note the trackpad cannot report granular coordinates during a
+ state of proximity.
+
+ patternProperties:
+ "^azoteq,lower-cal-(x|y)$":
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's lower starting points.
+
+ "^azoteq,upper-cal-(x|y)$":
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's upper starting points.
+
+ "^event-(press|tap|(swipe|flick)-(x|y)-(pos|neg))$":
+ type: object
+ $ref: input.yaml#
+ description:
+ Represents a press or gesture event reported by the trackpad. Specify
+ 'linux,code' under the press event to report absolute coordinates.
+
+ properties:
+ linux,code: true
+
+ azoteq,gesture-angle-tighten:
+ type: boolean
+ description:
+ Limits the tangent of the gesture angle to 0.5 (axial gestures
+ only). If specified in one direction, the effect is applied in
+ either direction.
+
+ azoteq,gesture-max-ms:
+ multipleOf: 16
+ minimum: 0
+ maximum: 4080
+ description:
+ Specifies the length of time (in ms) within which a tap, swipe
+ or flick gesture must be completed in order to be acknowledged
+ by the device. The number specified for any one swipe or flick
+ gesture applies to all other swipe or flick gestures.
+
+ azoteq,gesture-min-ms:
+ multipleOf: 16
+ minimum: 0
+ maximum: 4080
+ description:
+ Specifies the length of time (in ms) for which a tap gesture must
+ be held in order to be acknowledged by the device.
+
+ azoteq,gesture-dist:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description:
+ Specifies the distance (in coordinates) across which a swipe or
+ flick gesture must travel in order to be acknowledged by the
+ device. The number specified for any one swipe or flick gesture
+ applies to all remaining swipe or flick gestures.
+
+ For tap gestures, this property specifies the distance from the
+ original point of contact across which the contact is permitted
+ to travel before the gesture is rejected by the device.
+
+ azoteq,gpio-select:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 3
+ items:
+ minimum: 0
+ maximum: 2
+ description: |
+ Specifies one or more GPIO mapped to the event as follows:
+ 0: GPIO0
+ 1: GPIO3
+ 2: GPIO4
+
+ Note that although multiple events can be mapped to a single
+ GPIO, they must all be of the same type (proximity, touch or
+ trackpad gesture).
+
+ additionalProperties: false
+
+ required:
+ - azoteq,channel-select
+
+ additionalProperties: false
+
patternProperties:
"^cycle-[0-9]$":
type: object
@@ -288,6 +435,10 @@ patternProperties:
Activates the reference channel in response to proximity events
instead of touch events.
+ azoteq,counts-filt-enable:
+ type: boolean
+ description: Applies counts filtering to the channel.
+
azoteq,ati-band:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
@@ -432,12 +583,12 @@ patternProperties:
description: |
Specifies one or more GPIO mapped to the event as follows:
0: GPIO0
- 1: GPIO3 (IQS7222C only)
- 2: GPIO4 (IQS7222C only)
+ 1: GPIO3
+ 2: GPIO4
Note that although multiple events can be mapped to a single
GPIO, they must all be of the same type (proximity, touch or
- slider gesture).
+ slider/trackpad gesture).
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -610,8 +761,8 @@ patternProperties:
description: |
Specifies one or more GPIO mapped to the event as follows:
0: GPIO0
- 1: GPIO3 (IQS7222C only)
- 2: GPIO4 (IQS7222C only)
+ 1: GPIO3
+ 2: GPIO4
Note that although multiple events can be mapped to a single
GPIO, they must all be of the same type (proximity, touch or
@@ -629,8 +780,8 @@ patternProperties:
description: |
Represents a GPIO mapped to one or more events as follows:
gpio-0: GPIO0
- gpio-1: GPIO3 (IQS7222C only)
- gpio-2: GPIO4 (IQS7222C only)
+ gpio-1: GPIO3
+ gpio-2: GPIO4
allOf:
- $ref: ../pinctrl/pincfg-node.yaml#
@@ -641,11 +792,53 @@ patternProperties:
additionalProperties: false
allOf:
+ - $ref: touchscreen/touchscreen.yaml#
+
- if:
properties:
compatible:
contains:
- const: azoteq,iqs7222b
+ enum:
+ - azoteq,iqs7222a
+ - azoteq,iqs7222b
+ - azoteq,iqs7222c
+
+ then:
+ properties:
+ touchscreen-size-x: false
+ touchscreen-size-y: false
+ touchscreen-inverted-x: false
+ touchscreen-inverted-y: false
+ touchscreen-swapped-x-y: false
+
+ trackpad: false
+
+ patternProperties:
+ "^channel-([0-9]|1[0-9])$":
+ properties:
+ azoteq,counts-filt-enable: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - azoteq,iqs7222b
+ - azoteq,iqs7222c
+
+ then:
+ patternProperties:
+ "^channel-([0-9]|1[0-9])$":
+ properties:
+ azoteq,ulp-allow: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - azoteq,iqs7222b
+ - azoteq,iqs7222d
then:
patternProperties:
@@ -657,13 +850,22 @@ allOf:
properties:
azoteq,ref-select: false
+ "^slider-[0-1]$": false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: azoteq,iqs7222b
+
+ then:
+ patternProperties:
+ "^channel-([0-9]|1[0-9])$":
patternProperties:
"^event-(prox|touch)$":
properties:
azoteq,gpio-select: false
- "^slider-[0-1]$": false
-
"^gpio-[0-2]$": false
- if:
@@ -704,10 +906,6 @@ allOf:
else:
patternProperties:
- "^channel-([0-9]|1[0-9])$":
- properties:
- azoteq,ulp-allow: false
-
"^slider-[0-1]$":
patternProperties:
"^event-(press|tap|(swipe|flick)-(pos|neg))$":
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: input: iqs7222: Define units for slider properties
From: Jeff LaBundy @ 2023-07-09 17:06 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt
Cc: linux-input, devicetree, jeff
In-Reply-To: <ZKrotyhz7eueujys@nixie71>
The units assumed by the 'azoteq,top-speed', 'azoteq,bottom-speed'
and 'azoteq,gesture-dist' properties are unspecified; define them
according to the device's datasheet.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
---
.../bindings/input/azoteq,iqs7222.yaml | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
index 9ddba7f2e7aa..4c8690b62ce0 100644
--- a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
+++ b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
@@ -521,16 +521,16 @@ patternProperties:
minimum: 0
maximum: 65535
description:
- Specifies the speed of movement after which coordinate filtering is
- no longer applied.
+ Specifies the speed (in coordinates traveled per conversion) after
+ which coordinate filtering is no longer applied.
azoteq,bottom-speed:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description:
- Specifies the speed of movement after which coordinate filtering is
- linearly reduced.
+ Specifies the speed (in coordinates traveled per conversion) after
+ which coordinate filtering is linearly reduced.
azoteq,bottom-beta:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -595,10 +595,10 @@ patternProperties:
minimum: 0
maximum: 4080
description:
- Specifies the distance across which a swipe or flick gesture must
- travel in order to be acknowledged by the device. The number spec-
- ified for any one swipe or flick gesture applies to all remaining
- swipe or flick gestures.
+ Specifies the distance (in coordinates) across which a swipe or
+ flick gesture must travel in order to be acknowledged by the
+ device. The number specified for any one swipe or flick gesture
+ applies to all remaining swipe or flick gestures.
azoteq,gpio-select:
$ref: /schemas/types.yaml#/definitions/uint32-array
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/4] Input: iqs7222 - configure power mode before triggering ATI
From: Jeff LaBundy @ 2023-07-09 17:06 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt
Cc: linux-input, devicetree, jeff
In-Reply-To: <ZKrotyhz7eueujys@nixie71>
If the device drops into ultra-low-power mode before being placed
into normal-power mode as part of ATI being triggered, the device
does not assert any interrupts until the ATI routine is restarted
two seconds later.
Solve this problem by adopting the vendor's recommendation, which
calls for the device to be placed into normal-power mode prior to
being configured and ATI being triggered.
The original implementation followed this sequence, but the order
was inadvertently changed as part of the resolution of a separate
erratum.
Fixes: 1e4189d8af27 ("Input: iqs7222 - protect volatile registers")
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
---
drivers/input/misc/iqs7222.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/misc/iqs7222.c b/drivers/input/misc/iqs7222.c
index 096b0925f41b..acb95048e823 100644
--- a/drivers/input/misc/iqs7222.c
+++ b/drivers/input/misc/iqs7222.c
@@ -1381,9 +1381,6 @@ static int iqs7222_ati_trigger(struct iqs7222_private *iqs7222)
if (error)
return error;
- sys_setup &= ~IQS7222_SYS_SETUP_INTF_MODE_MASK;
- sys_setup &= ~IQS7222_SYS_SETUP_PWR_MODE_MASK;
-
for (i = 0; i < IQS7222_NUM_RETRIES; i++) {
/*
* Trigger ATI from streaming and normal-power modes so that
@@ -1561,8 +1558,11 @@ static int iqs7222_dev_init(struct iqs7222_private *iqs7222, int dir)
return error;
}
- if (dir == READ)
+ if (dir == READ) {
+ iqs7222->sys_setup[0] &= ~IQS7222_SYS_SETUP_INTF_MODE_MASK;
+ iqs7222->sys_setup[0] &= ~IQS7222_SYS_SETUP_PWR_MODE_MASK;
return 0;
+ }
return iqs7222_ati_trigger(iqs7222);
}
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/4] Add support for Azoteq IQS7222D
From: Jeff LaBundy @ 2023-07-09 17:04 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt
Cc: linux-input, devicetree, jeff
This series adds support for the latest member of the Azoteq IQS7222x
family of devices; it also sneaks in a bug fix and a clarification to
the binding.
Changes in v2:
- Added patches [1/4] and [2/4]
- Updated patch [3/4] as follows:
- Wrapped words instead of splitting them
- Specified units for the 'azoteq,top-speed', 'azoteq,bottom-speed'
and 'azoteq,gesture-dist' properties as in patch [2/4]
- Corrected the 'azoteq,gesture-dist' property's role in the case of
tap gestures
- Updated the if/then/else schema to consolidate restrictions common
to both IQS7222B and IQS7222D, and to indicate that the latter can
support the 'azoteq,ulp-allow' property
- Added more details to the commit message
- Removed unused variable 'val' from patch [4/4]
Jeff LaBundy (4):
Input: iqs7222 - configure power mode before triggering ATI
dt-bindings: input: iqs7222: Define units for slider properties
dt-bindings: input: iqs7222: Add properties for Azoteq IQS7222D
Input: iqs7222 - add support for Azoteq IQS7222D
.../bindings/input/azoteq,iqs7222.yaml | 248 ++++++++-
drivers/input/misc/Kconfig | 4 +-
drivers/input/misc/iqs7222.c | 476 +++++++++++++++++-
3 files changed, 688 insertions(+), 40 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH] Input: tegra-kbc - use devm_platform_ioremap_resource
From: Martin Kaiser @ 2023-07-09 13:41 UTC (permalink / raw)
To: Laxman Dewangan, Dmitry Torokhov, Thierry Reding, Jonathan Hunter
Cc: Martin Kaiser, linux-input, linux-tegra, linux-kernel
devm_platform_get_and_ioremap_resource maps a resource and returns its
physical address. If we don't need the physical address, we should call
devm_platform_ioremap_resource instead.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
drivers/input/keyboard/tegra-kbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/tegra-kbc.c b/drivers/input/keyboard/tegra-kbc.c
index d5a6c7d8eb25..c9a823ea45d0 100644
--- a/drivers/input/keyboard/tegra-kbc.c
+++ b/drivers/input/keyboard/tegra-kbc.c
@@ -640,7 +640,7 @@ static int tegra_kbc_probe(struct platform_device *pdev)
timer_setup(&kbc->timer, tegra_kbc_keypress_timer, 0);
- kbc->mmio = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
+ kbc->mmio = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(kbc->mmio))
return PTR_ERR(kbc->mmio);
--
2.30.2
^ permalink raw reply related
* [PATCH] selftests: hid: fix vmtests.sh not running make headers
From: Benjamin Tissoires @ 2023-07-09 10:06 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan
Cc: linux-input, linux-kselftest, linux-kernel, Benjamin Tissoires
According to commit 01d6c48a828b ("Documentation: kselftest:
"make headers" is a prerequisite"), running the kselftests requires
to run "make headers" first.
Do that in "vmtest.sh" as well to fix the HID CI.
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
---
Looks like the new master branch (v6.5-rc1) broke my CI.
And given that `make headers` is now a requisite to run the kselftests,
also include that command in vmtests.sh.
Broken CI job: https://gitlab.freedesktop.org/bentiss/hid/-/jobs/44704436
Fixed CI job: https://gitlab.freedesktop.org/bentiss/hid/-/jobs/45151040
---
tools/testing/selftests/hid/vmtest.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/hid/vmtest.sh b/tools/testing/selftests/hid/vmtest.sh
index 681b906b4853..4da48bf6b328 100755
--- a/tools/testing/selftests/hid/vmtest.sh
+++ b/tools/testing/selftests/hid/vmtest.sh
@@ -79,6 +79,7 @@ recompile_kernel()
cd "${kernel_checkout}"
${make_command} olddefconfig
+ ${make_command} headers
${make_command}
}
---
base-commit: 0e382fa72bbf0610be40af9af9b03b0cd149df82
change-id: 20230709-fix-selftests-c8b0bdff1d20
Best regards,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply related
* [dtor-input:next] BUILD SUCCESS 685b37704ce68924fa823d1cc37e512555526e06
From: kernel test robot @ 2023-07-08 23:07 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 685b37704ce68924fa823d1cc37e512555526e06 dt-bindings: input: touchscreen: edt-ft5x06: Add 'threshold' property
elapsed time: 1306m
configs tested: 168
configs skipped: 6
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha alldefconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
alpha randconfig-r036-20230708 gcc
arc allyesconfig gcc
arc defconfig gcc
arc hsdk_defconfig gcc
arc randconfig-r021-20230708 gcc
arc randconfig-r043-20230708 gcc
arc tb10x_defconfig gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm footbridge_defconfig gcc
arm imxrt_defconfig gcc
arm lpc18xx_defconfig gcc
arm multi_v5_defconfig clang
arm mvebu_v7_defconfig gcc
arm omap2plus_defconfig gcc
arm pxa_defconfig gcc
arm randconfig-r021-20230708 clang
arm randconfig-r023-20230708 clang
arm randconfig-r034-20230708 gcc
arm randconfig-r035-20230708 gcc
arm randconfig-r046-20230708 clang
arm spear6xx_defconfig gcc
arm vexpress_defconfig clang
arm64 allyesconfig gcc
arm64 defconfig gcc
csky defconfig gcc
csky randconfig-r006-20230708 gcc
csky randconfig-r012-20230708 gcc
hexagon randconfig-r003-20230708 clang
hexagon randconfig-r022-20230708 clang
hexagon randconfig-r041-20230708 clang
hexagon randconfig-r045-20230708 clang
i386 allyesconfig gcc
i386 buildonly-randconfig-r004-20230708 clang
i386 buildonly-randconfig-r005-20230708 clang
i386 buildonly-randconfig-r006-20230708 clang
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-i001-20230708 clang
i386 randconfig-i002-20230708 clang
i386 randconfig-i003-20230708 clang
i386 randconfig-i004-20230708 clang
i386 randconfig-i005-20230708 clang
i386 randconfig-i006-20230708 clang
i386 randconfig-i011-20230708 gcc
i386 randconfig-i012-20230708 gcc
i386 randconfig-i013-20230708 gcc
i386 randconfig-i014-20230708 gcc
i386 randconfig-i015-20230708 gcc
i386 randconfig-i016-20230708 gcc
i386 randconfig-r016-20230708 gcc
i386 randconfig-r033-20230708 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-r015-20230708 gcc
m68k allmodconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k m5475evb_defconfig gcc
m68k randconfig-r001-20230708 gcc
m68k randconfig-r025-20230708 gcc
microblaze randconfig-r004-20230708 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips cobalt_defconfig gcc
mips gpr_defconfig gcc
mips maltaup_defconfig clang
nios2 10m50_defconfig gcc
nios2 defconfig gcc
nios2 randconfig-r011-20230708 gcc
nios2 randconfig-r014-20230708 gcc
openrisc randconfig-r012-20230708 gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc generic-32bit_defconfig gcc
parisc randconfig-r024-20230708 gcc
parisc randconfig-r031-20230708 gcc
parisc64 defconfig gcc
powerpc akebono_defconfig clang
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc cm5200_defconfig gcc
powerpc eiger_defconfig gcc
powerpc kmeter1_defconfig clang
powerpc microwatt_defconfig clang
powerpc mpc512x_defconfig clang
powerpc mpc5200_defconfig clang
powerpc mpc834x_itx_defconfig gcc
powerpc mpc834x_itxgp_defconfig clang
powerpc mvme5100_defconfig clang
powerpc obs600_defconfig clang
powerpc ppc64_defconfig gcc
powerpc rainier_defconfig gcc
powerpc randconfig-r011-20230708 gcc
powerpc randconfig-r025-20230708 gcc
powerpc sam440ep_defconfig gcc
powerpc tqm8540_defconfig clang
powerpc tqm8560_defconfig clang
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-r001-20230708 clang
riscv randconfig-r004-20230708 clang
riscv randconfig-r013-20230708 gcc
riscv randconfig-r026-20230708 gcc
riscv randconfig-r042-20230708 gcc
riscv rv32_defconfig clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r006-20230708 clang
s390 randconfig-r024-20230708 gcc
s390 randconfig-r032-20230708 clang
s390 randconfig-r044-20230708 gcc
sh allmodconfig gcc
sh hp6xx_defconfig gcc
sh j2_defconfig gcc
sh polaris_defconfig gcc
sh randconfig-r002-20230708 gcc
sh se7751_defconfig gcc
sparc allyesconfig gcc
sparc defconfig gcc
sparc randconfig-r015-20230708 gcc
sparc randconfig-r031-20230708 gcc
sparc64 randconfig-r026-20230708 gcc
sparc64 randconfig-r034-20230708 gcc
sparc64 randconfig-r035-20230708 gcc
sparc64 randconfig-r036-20230708 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allyesconfig gcc
x86_64 buildonly-randconfig-r001-20230708 clang
x86_64 buildonly-randconfig-r002-20230708 clang
x86_64 buildonly-randconfig-r003-20230708 clang
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-r002-20230708 clang
x86_64 randconfig-r014-20230708 gcc
x86_64 randconfig-x001-20230708 gcc
x86_64 randconfig-x002-20230708 gcc
x86_64 randconfig-x003-20230708 gcc
x86_64 randconfig-x004-20230708 gcc
x86_64 randconfig-x005-20230708 gcc
x86_64 randconfig-x006-20230708 gcc
x86_64 randconfig-x011-20230708 clang
x86_64 randconfig-x012-20230708 clang
x86_64 randconfig-x013-20230708 clang
x86_64 randconfig-x014-20230708 clang
x86_64 randconfig-x015-20230708 clang
x86_64 randconfig-x016-20230708 clang
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa iss_defconfig gcc
xtensa randconfig-r005-20230708 gcc
xtensa randconfig-r023-20230708 gcc
xtensa randconfig-r032-20230708 gcc
xtensa randconfig-r033-20230708 gcc
xtensa xip_kc705_defconfig gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* RE: [PATCH] HID: hyperv: avoid struct memcpy overrun warning
From: Michael Kelley (LINUX) @ 2023-07-08 14:37 UTC (permalink / raw)
To: Arnd Bergmann, Jiri Kosina, Benjamin Tissoires
Cc: Arnd Bergmann, KY Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Paulo Miguel Almeida, Dawei Li, Yang Yingliang,
Thomas Weißschuh, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20230705140242.844167-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@kernel.org> Sent: Wednesday, July 5, 2023 7:02 AM
>
> A previous patch addressed the fortified memcpy warning for most
> builds, but I still see this one with gcc-9:
>
> In file included from include/linux/string.h:254,
> from drivers/hid/hid-hyperv.c:8:
> In function 'fortify_memcpy_chk',
> inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:
> include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with
> attribute warning: detected write beyond size of field (1st parameter); maybe use
> struct_group()? [-Werror=attribute-warning]
> 583 | __write_overflow_field(p_size_field, size);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> My guess is that the WARN_ON() itself is what confuses gcc, so it no
> longer sees that there is a correct range check. Rework the code in a
> way that helps readability and avoids the warning.
>
> Fixes: 542f25a944715 ("HID: hyperv: Replace one-element array with flexible-array member")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/hid/hid-hyperv.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
> index 49d4a26895e76..f33485d83d24f 100644
> --- a/drivers/hid/hid-hyperv.c
> +++ b/drivers/hid/hid-hyperv.c
> @@ -258,19 +258,17 @@ static void mousevsc_on_receive(struct hv_device *device,
>
> switch (hid_msg_hdr->type) {
> case SYNTH_HID_PROTOCOL_RESPONSE:
> + len = struct_size(pipe_msg, data, pipe_msg->size);
> +
> /*
> * While it will be impossible for us to protect against
> * malicious/buggy hypervisor/host, add a check here to
> * ensure we don't corrupt memory.
> */
> - if (struct_size(pipe_msg, data, pipe_msg->size)
> - > sizeof(struct mousevsc_prt_msg)) {
> - WARN_ON(1);
> + if (WARN_ON(len > sizeof(struct mousevsc_prt_msg)))
> break;
> - }
>
> - memcpy(&input_dev->protocol_resp, pipe_msg,
> - struct_size(pipe_msg, data, pipe_msg->size));
> + memcpy(&input_dev->protocol_resp, pipe_msg, len);
> complete(&input_dev->wait_event);
> break;
>
> --
> 2.39.2
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
^ permalink raw reply
* Re: [PATCH v2 5/5] dt-bindings: input: touchscreen: edt-ft5x06: Add 'threshold' property
From: Dmitry Torokhov @ 2023-07-08 0:06 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Abel Vesa, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Herbert Xu, David S. Miller, Ulf Hansson, Rob Herring, kernel,
Peng Fan, Fabio Estevam, NXP Linux Team, Daniel Lezcano,
Thomas Gleixner, Michael Trimarchi, Mark Brown, Dario Binacchi,
Marek Vasut, linux-clk, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, linux-input, linux-mmc
In-Reply-To: <20230621093245.78130-6-o.rempel@pengutronix.de>
On Wed, Jun 21, 2023 at 11:32:45AM +0200, Oleksij Rempel wrote:
> Add a new property 'threshold' to the edt-ft5x06 touchscreen binding.
> This property allows setting the "click"-threshold in the range from 0
> to 255. This change addresses the following dtbs_check warning:
> imx6dl-lanmcu.dtb: touchscreen@38: 'threshold' does not match any of the regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Rob Herring <robh@kernel.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: adp5588-keys - Use devm_regulator_get_enable()
From: Dmitry Torokhov @ 2023-07-08 0:04 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Michael Hennerich, linux-kernel, kernel-janitors, linux-input
In-Reply-To: <af343b5b0d740cc9f8863264c30e3da4215721d7.1686985911.git.christophe.jaillet@wanadoo.fr>
On Sat, Jun 17, 2023 at 09:12:03AM +0200, Christophe JAILLET wrote:
> Use devm_regulator_get_enable() instead of hand writing it. It saves some
> line of code.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: pinephone-keyboard - Use devm_regulator_get_enable()
From: Dmitry Torokhov @ 2023-07-08 0:04 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Samuel Holland, linux-kernel, kernel-janitors, linux-input
In-Reply-To: <78d7a4719ed7c372a7aa62afb66d4f1561799b5f.1686985515.git.christophe.jaillet@wanadoo.fr>
On Sat, Jun 17, 2023 at 09:05:42AM +0200, Christophe JAILLET wrote:
> Use devm_regulator_get_enable() instead of hand writing it. It saves some
> line of code.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied, thank you.
--
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox