* Re: [git pull] Input updates for v6.10-rc5
From: Dmitry Torokhov @ 2024-06-24 15:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
In-Reply-To: <CAHk-=wj730guvRzh4wo16Cq8tq1D1tyD8ub4CiBxV4Bk0Kq_-g@mail.gmail.com>
On Mon, Jun 24, 2024 at 10:28:09AM -0400, Linus Torvalds wrote:
> On Sun, 23 Jun 2024 at 19:05, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> > Please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.10-rc5
> >
> > to receive updates for the input subsystem. You will get:
>
> Nope. I get something entirely different. I think you tagged the wrong state.
Ugh, I was on a wrong branch ('next' for the next merge window) when I
created the tag. I'll fix my script, but in the meantime should I:
- blow away the bad tag and re-create under the same name as before
(input-for-v6.10-rc5) or
- blow away the bad tag and use new name for the correct one (somthing
like input-for-v6.10-rc5-fixed)?
I do not want to keep the bad tag to avoid confusion in the future.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [git pull] Input updates for v6.10-rc5
From: Linus Torvalds @ 2024-06-24 18:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-kernel, linux-input
In-Reply-To: <ZnmX1XeOzU1NfgrY@google.com>
On Mon, 24 Jun 2024 at 11:59, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> Ugh, I was on a wrong branch ('next' for the next merge window) when I
> created the tag. I'll fix my script, but in the meantime should I:
>
> - blow away the bad tag and re-create under the same name as before
> (input-for-v6.10-rc5) or
>
> - blow away the bad tag and use new name for the correct one (somthing
> like input-for-v6.10-rc5-fixed)?
Either works. Some people just re-use the same tag name, others will
always use new names. I don't personally worry about it, and whatever
you feel better about works for me.
Linus
^ permalink raw reply
* Re: [git pull] Input updates for v6.10-rc5
From: Dmitry Torokhov @ 2024-06-24 18:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
In-Reply-To: <CAHk-=wh3ZpDhHseFjYf96CcgTSRoZtjbf41hoBCyfQJ=N+oMng@mail.gmail.com>
On Mon, Jun 24, 2024 at 02:10:49PM -0400, Linus Torvalds wrote:
> On Mon, 24 Jun 2024 at 11:59, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> > Ugh, I was on a wrong branch ('next' for the next merge window) when I
> > created the tag. I'll fix my script, but in the meantime should I:
> >
> > - blow away the bad tag and re-create under the same name as before
> > (input-for-v6.10-rc5) or
> >
> > - blow away the bad tag and use new name for the correct one (somthing
> > like input-for-v6.10-rc5-fixed)?
>
> Either works. Some people just re-use the same tag name, others will
> always use new names. I don't personally worry about it, and whatever
> you feel better about works for me.
OK, great. I re-created the tag using the original name but tagging the
right commit.
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.10-rc5
It should resolve to 7c7b1be19b22 ("Input: ads7846 - use spi_device_id
table").
Thanks!
--
Dmitry
^ permalink raw reply
* Re: Re: [git pull] Input updates for v6.10-rc5
From: pr-tracker-bot @ 2024-06-24 18:41 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <Znm5EzNHCk_g4puh@google.com>
The pull request you sent on Mon, 24 Jun 2024 11:21:07 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.10-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/55027e689933ba2e64f3d245fb1ff185b3e7fc81
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [linux-next:master] BUILD REGRESSION f76698bd9a8ca01d3581236082d786e9a6b72bb7
From: Andrew Morton @ 2024-06-24 19:31 UTC (permalink / raw)
To: kernel test robot
Cc: Linux Memory Management List, amd-gfx, imx, intel-xe,
linux-arm-kernel, linux-arm-msm, linux-input, linux-mediatek,
linux-mtd, linux-trace-kernel, netdev, Mark Brown, Baolin Wang
In-Reply-To: <202406230716.DQbMBKh0-lkp@intel.com>
On Sun, 23 Jun 2024 07:11:24 +0800 kernel test robot <lkp@intel.com> wrote:
> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: f76698bd9a8ca01d3581236082d786e9a6b72bb7 Add linux-next specific files for 20240621
>
> Error/Warning reports:
>
> https://lore.kernel.org/oe-kbuild-all/202406220536.JnAncjqz-lkp@intel.com
> https://lore.kernel.org/oe-kbuild-all/202406220754.evK8Hrjw-lkp@intel.com
>
> Error/Warning: (recently discovered and may have been fixed)
>
> drivers/soc/qcom/smsm.c:(.text.qcom_smsm_remove+0x70): undefined reference to `mbox_free_channel'
>
> Unverified Error/Warning (likely false positive, please contact us if interested):
>
> include/linux/container_of.h:20:54: error: invalid use of undefined type 'struct thpsize'
> include/linux/list.h:645:25: error: invalid use of undefined type 'struct thpsize'
> include/linux/stddef.h:16:33: error: invalid use of undefined type 'struct thpsize'
> mm/huge_memory.c:455:21: error: implicit declaration of function 'to_thpsize'; did you mean 'thp_size'? [-Werror=implicit-function-declaration]
> mm/huge_memory.c:455:37: error: invalid type argument of '->' (have 'int')
> mm/huge_memory.c:558:35: error: 'MTHP_STAT_FILE_ALLOC' undeclared (first use in this function); did you mean 'THP_FILE_ALLOC'?
> mm/huge_memory.c:559:38: error: 'MTHP_STAT_FILE_FALLBACK' undeclared (first use in this function); did you mean 'THP_FILE_FALLBACK'?
> mm/huge_memory.c:560:45: error: 'MTHP_STAT_FILE_FALLBACK_CHARGE' undeclared (first use in this function); did you mean 'THP_FILE_FALLBACK_CHARGE'?
> mm/huge_memory.c:579:17: warning: assignment to 'struct thpsize *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
> mm/huge_memory.c:579:33: error: invalid application of 'sizeof' to incomplete type 'struct thpsize'
> mm/huge_memory.c:583:44: error: invalid use of undefined type 'struct thpsize'
> mm/huge_memory.c:608:15: warning: passing argument 1 of 'kfree' makes pointer from integer without a cast [-Wint-conversion]
>
>
> ...
>
>
> |-- x86_64-randconfig-014-20240202
> | |-- include-linux-container_of.h:error:invalid-use-of-undefined-type-struct-thpsize
> | |-- include-linux-list.h:error:invalid-use-of-undefined-type-struct-thpsize
> | |-- include-linux-stddef.h:error:invalid-use-of-undefined-type-struct-thpsize
> | |-- mm-huge_memory.c:error:MTHP_STAT_FILE_ALLOC-undeclared-(first-use-in-this-function)
> | |-- mm-huge_memory.c:error:MTHP_STAT_FILE_FALLBACK-undeclared-(first-use-in-this-function)
> | |-- mm-huge_memory.c:error:MTHP_STAT_FILE_FALLBACK_CHARGE-undeclared-(first-use-in-this-function)
> | |-- mm-huge_memory.c:error:implicit-declaration-of-function-to_thpsize
> | |-- mm-huge_memory.c:error:invalid-application-of-sizeof-to-incomplete-type-struct-thpsize
> | |-- mm-huge_memory.c:error:invalid-type-argument-of-(have-int-)
> | |-- mm-huge_memory.c:error:invalid-use-of-undefined-type-struct-thpsize
> | |-- mm-huge_memory.c:warning:assignment-to-struct-thpsize-from-int-makes-pointer-from-integer-without-a-cast
> | `-- mm-huge_memory.c:warning:passing-argument-of-kfree-makes-pointer-from-integer-without-a-cast
Is there a way for us to obtain that config file?
"mm: shmem: add multi-size THP sysfs interface for anonymous shmem"
moved things into mm_tytpes.h but didn't include it so perhaps this
will fix:
--- a/mm/huge_memory.c~mm-shmem-add-multi-size-thp-sysfs-interface-for-anonymous-shmem-fix-4
+++ a/mm/huge_memory.c
@@ -20,6 +20,7 @@
#include <linux/swapops.h>
#include <linux/backing-dev.h>
#include <linux/dax.h>
+#include <linux/mm_types.h>
#include <linux/khugepaged.h>
#include <linux/freezer.h>
#include <linux/pfn_t.h>
_
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: arm: qcom: add OnePlus 8 series
From: Rob Herring @ 2024-06-24 20:40 UTC (permalink / raw)
To: Caleb Connolly
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Daniel Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Bjorn Andersson, Konrad Dybcio, Henrik Rydberg, dri-devel,
devicetree, linux-input, linux-arm-msm, ~postmarketos/upstreaming
In-Reply-To: <20240624-oneplus8-v1-3-388eecf2dff7@postmarketos.org>
On Mon, Jun 24, 2024 at 03:30:27AM +0200, Caleb Connolly wrote:
> Add bindings for the OnePlus 8, 8 Pro, and 8T devices.
>
> Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index d839691a900c..a41eeb8c3fc5 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -986,8 +986,11 @@ properties:
> - enum:
> - qcom,qrb5165-rb5
> - qcom,sm8250-hdk
> - qcom,sm8250-mtp
> + - oneplus,kebab
> + - oneplus,instantnoodle
> + - oneplus,instantnoodlep
Which one is which device in the commit msg? I can only guess that 'p'
here corresponds to Pro. A comment after the compatibles would help.
> - sony,pdx203-generic
> - sony,pdx206-generic
> - xiaomi,elish
> - xiaomi,pipa
>
> --
> 2.45.0
>
^ permalink raw reply
* Re: linux-next: build failure after merge of the bpf-next tree
From: Thinker Li @ 2024-06-25 1:22 UTC (permalink / raw)
To: Mark Brown
Cc: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking, Benjamin Tissoires, Jiri Kosina, Martin KaFai Lau,
linux-input, Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <ZnB9X1Jj6c04ufC0@sirena.org.uk>
Hi Mark,
I'm sorry for not getting back to you sooner. I have been traveling
since my last message.
I guess this patch is for the HID tree. The changes in this patch are great.
However, I suggest you implement ".update" if you think it is
reasonable for HID,
although it is not a MUST-BE. ".update" provides a good feature that
user space programs
can update an implementation on the flight.
On Mon, Jun 17, 2024 at 11:16 AM Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
> 280 | .reg = hid_bpf_reg,
> | ^~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
> 281 | .unreg = hid_bpf_unreg,
> | ^~~~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
>
> Caused by commit
>
> 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
>
> interacting with commit
>
> ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
>
> from the HID tree.
>
> I've fixed it up as below:
>
> From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> From: Mark Brown <broonie@kernel.org>
> Date: Mon, 17 Jun 2024 19:02:27 +0100
> Subject: [PATCH] HID: bpf: Fix up build
>
> Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> index 5f200557ff12b..744318e7d936b 100644
> --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
> return 0;
> }
>
> -static int hid_bpf_reg(void *kdata)
> +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
> {
> struct hid_bpf_ops *ops = kdata;
> struct hid_device *hdev;
> @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
> return err;
> }
>
> -static void hid_bpf_unreg(void *kdata)
> +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
> {
> struct hid_bpf_ops *ops = kdata;
> struct hid_device *hdev;
> --
> 2.39.2
>
^ permalink raw reply
* Re: [PATCH] Input: qt1050 - handle CHIP_ID reading error
From: Marco Felsch @ 2024-06-25 8:32 UTC (permalink / raw)
To: Andrei Lalaev
Cc: dmitry.torokhov, robh, linux-input, linux-kernel, Andrei Lalaev
In-Reply-To: <20240617183018.916234-1-andrey.lalaev@gmail.com>
On 24-06-17, Andrei Lalaev wrote:
> From: Andrei Lalaev <andrei.lalaev@anton-paar.com>
>
> If the device is missing, we get the following error:
>
> qt1050 3-0041: ID -1340767592 not supported
>
> Let's handle this situation and print more informative error
> when reading of CHIP_ID fails:
>
> qt1050 3-0041: Failed to read chip ID: -6
>
> Fixes: cbebf5addec1 ("Input: qt1050 - add Microchip AT42QT1050 support")
> Signed-off-by: Andrei Lalaev <andrei.lalaev@anton-paar.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
^ permalink raw reply
* [PATCH RESEND] hid: bpf: Fix grammar
From: Luis Felipe Hernandez @ 2024-06-25 10:55 UTC (permalink / raw)
To: jikos, bentiss
Cc: Luis Felipe Hernandez, skhan, ricardo, linux-kernel-mentees,
linux-input, linux-kernel
* spelling fix: XBox -> Xbox, lowercase 'b' as per Microsoft branding
* rephrase: paddle -> paddles, the controller itself has more than one paddle
* rephrase: replace usage of "those" in favor of explicitly making reference
to the paddles
* grammatical fix: report -> reports, use present tense verb.
* spelling fix: interpret
* consistency: capitalize the first word in bullet points
Signed-off-by: Luis Felipe Hernandez <luis.hernandez093@gmail.com>
---
.../hid/bpf/progs/Microsoft__XBox-Elite-2.bpf.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/bpf/progs/Microsoft__XBox-Elite-2.bpf.c b/drivers/hid/bpf/progs/Microsoft__XBox-Elite-2.bpf.c
index c04abecab8ee..858cf20ebe2c 100644
--- a/drivers/hid/bpf/progs/Microsoft__XBox-Elite-2.bpf.c
+++ b/drivers/hid/bpf/progs/Microsoft__XBox-Elite-2.bpf.c
@@ -15,20 +15,19 @@ HID_BPF_CONFIG(
);
/*
- * When using the XBox Wireless Controller Elite 2 over Bluetooth,
- * the device exports the paddle on the back of the device as a single
+ * When using the Xbox Wireless Controller Elite 2 over Bluetooth,
+ * the device exports the paddles on the back of the device as a single
* bitfield value of usage "Assign Selection".
*
- * The kernel doesn't process those usages properly and report KEY_UNKNOWN
- * for it.
+ * The kernel doesn't process the paddles usage properly and reports KEY_UNKNOWN.
*
- * SDL doesn't know how to interprete that KEY_UNKNOWN and thus ignores the paddles.
+ * SDL doesn't know how to interpret KEY_UNKNOWN and thus ignores the paddles.
*
* Given that over USB the kernel uses BTN_TRIGGER_HAPPY[5-8], we
- * can tweak the report descriptor to make the kernel interprete it properly:
- * - we need an application collection of gamepad (so we have to close the current
+ * can tweak the report descriptor to make the kernel interpret it properly:
+ * - We need an application collection of gamepad (so we have to close the current
* Consumer Control one)
- * - we need to change the usage to be buttons from 0x15 to 0x18
+ * - We need to change the usage to be buttons from 0x15 to 0x18
*/
#define OFFSET_ASSIGN_SELECTION 211
--
2.45.1
^ permalink raw reply related
* Re: [linux-next:master] BUILD REGRESSION f76698bd9a8ca01d3581236082d786e9a6b72bb7
From: Philip Li @ 2024-06-25 12:55 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel test robot, Linux Memory Management List, amd-gfx, imx,
intel-xe, linux-arm-kernel, linux-arm-msm, linux-input,
linux-mediatek, linux-mtd, linux-trace-kernel, netdev, Mark Brown,
Baolin Wang
In-Reply-To: <20240624123154.4c3125c3093636de35b407dd@linux-foundation.org>
On Mon, Jun 24, 2024 at 12:31:54PM -0700, Andrew Morton wrote:
> On Sun, 23 Jun 2024 07:11:24 +0800 kernel test robot <lkp@intel.com> wrote:
>
> > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > branch HEAD: f76698bd9a8ca01d3581236082d786e9a6b72bb7 Add linux-next specific files for 20240621
> >
> > Error/Warning reports:
> >
> > https://lore.kernel.org/oe-kbuild-all/202406220536.JnAncjqz-lkp@intel.com
> > https://lore.kernel.org/oe-kbuild-all/202406220754.evK8Hrjw-lkp@intel.com
> >
> > Error/Warning: (recently discovered and may have been fixed)
> >
> > drivers/soc/qcom/smsm.c:(.text.qcom_smsm_remove+0x70): undefined reference to `mbox_free_channel'
> >
> > Unverified Error/Warning (likely false positive, please contact us if interested):
> >
> > include/linux/container_of.h:20:54: error: invalid use of undefined type 'struct thpsize'
> > include/linux/list.h:645:25: error: invalid use of undefined type 'struct thpsize'
> > include/linux/stddef.h:16:33: error: invalid use of undefined type 'struct thpsize'
> > mm/huge_memory.c:455:21: error: implicit declaration of function 'to_thpsize'; did you mean 'thp_size'? [-Werror=implicit-function-declaration]
> > mm/huge_memory.c:455:37: error: invalid type argument of '->' (have 'int')
> > mm/huge_memory.c:558:35: error: 'MTHP_STAT_FILE_ALLOC' undeclared (first use in this function); did you mean 'THP_FILE_ALLOC'?
> > mm/huge_memory.c:559:38: error: 'MTHP_STAT_FILE_FALLBACK' undeclared (first use in this function); did you mean 'THP_FILE_FALLBACK'?
> > mm/huge_memory.c:560:45: error: 'MTHP_STAT_FILE_FALLBACK_CHARGE' undeclared (first use in this function); did you mean 'THP_FILE_FALLBACK_CHARGE'?
> > mm/huge_memory.c:579:17: warning: assignment to 'struct thpsize *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
> > mm/huge_memory.c:579:33: error: invalid application of 'sizeof' to incomplete type 'struct thpsize'
> > mm/huge_memory.c:583:44: error: invalid use of undefined type 'struct thpsize'
> > mm/huge_memory.c:608:15: warning: passing argument 1 of 'kfree' makes pointer from integer without a cast [-Wint-conversion]
> >
> >
> > ...
> >
> >
> > |-- x86_64-randconfig-014-20240202
> > | |-- include-linux-container_of.h:error:invalid-use-of-undefined-type-struct-thpsize
> > | |-- include-linux-list.h:error:invalid-use-of-undefined-type-struct-thpsize
> > | |-- include-linux-stddef.h:error:invalid-use-of-undefined-type-struct-thpsize
> > | |-- mm-huge_memory.c:error:MTHP_STAT_FILE_ALLOC-undeclared-(first-use-in-this-function)
> > | |-- mm-huge_memory.c:error:MTHP_STAT_FILE_FALLBACK-undeclared-(first-use-in-this-function)
> > | |-- mm-huge_memory.c:error:MTHP_STAT_FILE_FALLBACK_CHARGE-undeclared-(first-use-in-this-function)
> > | |-- mm-huge_memory.c:error:implicit-declaration-of-function-to_thpsize
> > | |-- mm-huge_memory.c:error:invalid-application-of-sizeof-to-incomplete-type-struct-thpsize
> > | |-- mm-huge_memory.c:error:invalid-type-argument-of-(have-int-)
> > | |-- mm-huge_memory.c:error:invalid-use-of-undefined-type-struct-thpsize
> > | |-- mm-huge_memory.c:warning:assignment-to-struct-thpsize-from-int-makes-pointer-from-integer-without-a-cast
> > | `-- mm-huge_memory.c:warning:passing-argument-of-kfree-makes-pointer-from-integer-without-a-cast
>
> Is there a way for us to obtain that config file?
Sorry, kindly ignore the issues associated with x86_64-randconfig-014-20240202 kconfig.
The bisected reports for it are mostly wrong such as [1], [2] due to bot issue, thus these
wrong info was included in this summary report as well.
[1] https://lore.kernel.org/oe-kbuild-all/202406220112.qjyQbasK-lkp@intel.com/
[2] https://lore.kernel.org/oe-kbuild-all/202406211750.Ks4k82Gi-lkp@intel.com/
>
> "mm: shmem: add multi-size THP sysfs interface for anonymous shmem"
> moved things into mm_tytpes.h but didn't include it so perhaps this
> will fix:
>
> --- a/mm/huge_memory.c~mm-shmem-add-multi-size-thp-sysfs-interface-for-anonymous-shmem-fix-4
> +++ a/mm/huge_memory.c
> @@ -20,6 +20,7 @@
> #include <linux/swapops.h>
> #include <linux/backing-dev.h>
> #include <linux/dax.h>
> +#include <linux/mm_types.h>
> #include <linux/khugepaged.h>
> #include <linux/freezer.h>
> #include <linux/pfn_t.h>
> _
>
^ permalink raw reply
* [PATCH v14 0/3] Input: Add TouchNetix axiom touchscreen driver
From: Kamel Bouhara @ 2024-06-25 14:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy
Cc: catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo, Kamel Bouhara
Add a new driver for the TouchNetix's axiom family of touchscreen
controller. This driver only support i2c and can be later adapted for
SPI and USB support.
--
Changes in v14:
- Fix is_report/present as booleans
- Add a comment to describe the boolean variable insert
- Remove not needed packed attributed from struct axiom_cmd_header
- Remove duplicate target event checking
- Only emit ABS_MT_DISTANCE/ABS_MT_PRESSURE
- Remove input_report_key() as a mean to indicate firs reported contact
- Remove EV_REL only need for u46 aka debug data
- Report only MT_TOOL_FINGER instead of MT_TOOL_MAX
- Remove unused EV_REL
- Remove emit BTN_TOUCH as a way to indicate first target report
- Remove unjustified delay after read access
- Remove falling back to polling mode when no irq acquired in ACPI/DT
- Remove handle of u46 report as it's not used
- Remove touchscreen_report_pos() call as it generates extra dummy events
- Rebase on v6.10-rc5
Changes in v13:
- Fix CRC16 not selected reported in:https://lore.kernel.org/oe-kbuild-all/202405311035.5QZSREJv-lkp@intel.com/
- Rebase on v6.10-rc2
Changes in v12:
- Fix REGMAP_I2C not selected
- Rebase on v6.10-rc1
Changes in v11:
- Fix regulators name to match dt-binding
- Enable regulators before reset is asserted
Changes in v10:
- Set regulators as required
- Enable power supply before reset
- Fix ref count due to regulator requested twice
- Rebase on v6.9-rc4
Changes in v9:
- Fix issue reported in https://lore.kernel.org/oe-kbuild-all/202402201157.BKo97uWl-lkp@intel.com/
- Rebase on v6.8-rc2
Changes in v8:
- Fix missing call to input_report_slot_state()
- Fix issue reported in https://lore.kernel.org/oe-kbuild-all/202402020623.8T1Ah513-lkp@intel.com/
Changes in v7:
- Remove startup time from dt-binding
- Fix usage table not correctly populated
Changes in v6:
- Fix missing unevaluatedProperties.in dt-binding
- Use __le16 to correctly deal with device endianness
- Use standart kernel types s/char/u8/
- Use regmap api as driver might support spi later
- Use get_unaligned_le16() for the sake of clarity
- Use devm_regulator_enable_optional()
Changes in v5:
- Fix wrong message constructed in axiom_i2c_read
- Delay required between i2c reads is >= 250us
- Do not split report reading in two phases as we'll
have to wait 500us
- Use lower-case in properties names
- Make regulators properties are required in dt-binding
- Fix bug report: https://lore.kernel.org/lkml/202312051457.y3N1q3sZ-lkp@intel.com/
- Fix bug report: https://lore.kernel.org/lkml/6f8e3b64-5b21-4a50-8680-063ef7a93bdb@suswa.mountain/
Changes in v4:
- Cleanup unused headers and macros
- Use standard kernel type
- Namespace structures and functions
- Use packed struct when possible to avoid bitfield operators
- Fix missing break when address is found in axiom_populate_target_address()
- Split reads in two steps for the reports, first length then report
itself so we only read required bytes
- Get poll-interval from devicetree
- Add VDDI/VDDA regulators
- Add a startup delay of 110 ms required after VDDA/VDDI is applied
- Remove axiom_i2c_write() as it is no more used
Changes in v3:
- Remove irq-gpios property in dt-binding
- Use a generic node name
- Fix issues reported in https://lore.kernel.org/oe-kbuild-all/202310100300.oAC2M62R-lkp@intel.com/
Changes in v2:
- Add device tree binding documentation
- Move core functions in axiom_i2c as we only care about i2c support now
- Use static function when required
- Use syntax dev_err_probe()
- Add an hardware based reset
Kamel Bouhara (3):
dt-bindings: vendor-prefixes: Add TouchNetix AS
dt-bindings: input: Add TouchNetix axiom touchscreen
Input: Add TouchNetix axiom i2c touchscreen driver
.../input/touchscreen/touchnetix,ax54a.yaml | 62 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 8 +
drivers/input/touchscreen/Kconfig | 14 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/touchnetix_axiom.c | 616 ++++++++++++++++++
6 files changed, 703 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
create mode 100644 drivers/input/touchscreen/touchnetix_axiom.c
--
2.25.1
^ permalink raw reply
* [PATCH v14 1/3] dt-bindings: vendor-prefixes: Add TouchNetix AS
From: Kamel Bouhara @ 2024-06-25 14:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy
Cc: catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo, Kamel Bouhara,
Krzysztof Kozlowski
In-Reply-To: <20240625143948.54452-1-kamel.bouhara@bootlin.com>
Add vendor prefix for TouchNetix AS (https://www.touchnetix.com/products/).
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index fbf47f0bacf1..f102b3abf3fc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1489,6 +1489,8 @@ patternProperties:
description: Toradex AG
"^toshiba,.*":
description: Toshiba Corporation
+ "^touchnetix,.*":
+ description: TouchNetix AS
"^toumaz,.*":
description: Toumaz
"^tpk,.*":
--
2.25.1
^ permalink raw reply related
* [PATCH v14 2/3] dt-bindings: input: Add TouchNetix axiom touchscreen
From: Kamel Bouhara @ 2024-06-25 14:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy
Cc: catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo, Kamel Bouhara,
Krzysztof Kozlowski
In-Reply-To: <20240625143948.54452-1-kamel.bouhara@bootlin.com>
Add the TouchNetix axiom I2C touchscreen device tree bindings
documentation.
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../input/touchscreen/touchnetix,ax54a.yaml | 62 +++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
new file mode 100644
index 000000000000..66229a4d6f15
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/touchnetix,ax54a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TouchNetix Axiom series touchscreen controller
+
+maintainers:
+ - Kamel Bouhara <kamel.bouhara@bootlin.com>
+
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+ - $ref: /schemas/input/input.yaml#
+
+properties:
+ compatible:
+ const: touchnetix,ax54a
+
+ reg:
+ const: 0x66
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ vdda-supply:
+ description: Analog power supply regulator on VDDA pin
+
+ vddi-supply:
+ description: I/O power supply regulator on VDDI pin
+
+required:
+ - compatible
+ - reg
+ - vdda-supply
+ - vddi-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@66 {
+ compatible = "touchnetix,ax54a";
+ reg = <0x66>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+ vdda-supply = <&vdda_reg>;
+ vddi-supply = <&vddi_reg>;
+ poll-interval = <20>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 2ca8f35dfe03..6e418ee4c166 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22739,6 +22739,12 @@ L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/platform/x86/toshiba-wmi.c
+TOUCHNETIX AXIOM I2C TOUCHSCREEN DRIVER
+M: Kamel Bouhara <kamel.bouhara@bootlin.com>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
+
TPM DEVICE DRIVER
M: Peter Huewe <peterhuewe@gmx.de>
M: Jarkko Sakkinen <jarkko@kernel.org>
--
2.25.1
^ permalink raw reply related
* [PATCH v14 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: Kamel Bouhara @ 2024-06-25 14:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy
Cc: catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo, Kamel Bouhara
In-Reply-To: <20240625143948.54452-1-kamel.bouhara@bootlin.com>
Add a new driver for the TouchNetix's axiom family of
touchscreen controllers. This driver only supports i2c
and can be later adapted for SPI and USB support.
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
---
MAINTAINERS | 2 +
drivers/input/touchscreen/Kconfig | 14 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/touchnetix_axiom.c | 616 +++++++++++++++++++
4 files changed, 633 insertions(+)
create mode 100644 drivers/input/touchscreen/touchnetix_axiom.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 6e418ee4c166..f27b0b7bc2fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22741,9 +22741,11 @@ F: drivers/platform/x86/toshiba-wmi.c
TOUCHNETIX AXIOM I2C TOUCHSCREEN DRIVER
M: Kamel Bouhara <kamel.bouhara@bootlin.com>
+M: bsp-development.geo@leica-geosystems.com
L: linux-input@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
+F: drivers/input/touchscreen/touchnetix_axiom.c
TPM DEVICE DRIVER
M: Peter Huewe <peterhuewe@gmx.de>
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index c821fe3ee794..1ce8f1c25625 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -834,6 +834,20 @@ config TOUCHSCREEN_MIGOR
To compile this driver as a module, choose M here: the
module will be called migor_ts.
+config TOUCHSCREEN_TOUCHNETIX_AXIOM
+ tristate "TouchNetix AXIOM based touchscreen controllers"
+ depends on I2C
+ select CRC16
+ select REGMAP_I2C
+ help
+ Say Y here if you have a axiom touchscreen connected to
+ your system.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called axiom.
+
config TOUCHSCREEN_TOUCHRIGHT
tristate "Touchright serial touchscreen"
select SERIO
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index a81cb5aa21a5..6ce7b804adc7 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_TOUCHSCREEN_SUR40) += sur40.o
obj-$(CONFIG_TOUCHSCREEN_SURFACE3_SPI) += surface3_spi.o
obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC) += ti_am335x_tsc.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
+obj-$(CONFIG_TOUCHSCREEN_TOUCHNETIX_AXIOM) += touchnetix_axiom.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
obj-$(CONFIG_TOUCHSCREEN_TS4800) += ts4800-ts.o
diff --git a/drivers/input/touchscreen/touchnetix_axiom.c b/drivers/input/touchscreen/touchnetix_axiom.c
new file mode 100644
index 000000000000..04a896163fcf
--- /dev/null
+++ b/drivers/input/touchscreen/touchnetix_axiom.c
@@ -0,0 +1,616 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TouchNetix axiom Touchscreen Driver
+ *
+ * Copyright (C) 2020-2023 TouchNetix Ltd.
+ *
+ * Author(s): Bart Prescott <bartp@baasheep.co.uk>
+ * Pedro Torruella <pedro.torruella@touchnetix.com>
+ * Mark Satterthwaite <mark.satterthwaite@touchnetix.com>
+ * Hannah Rossiter <hannah.rossiter@touchnetix.com>
+ * Kamel Bouhara <kamel.bouhara@bootlin.com>
+ *
+ */
+#include <linux/bitfield.h>
+#include <linux/crc16.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/input/mt.h>
+#include <linux/input/touchscreen.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/regmap.h>
+
+#include <asm/unaligned.h>
+#define AXIOM_PROX_LEVEL -128
+#define AXIOM_STARTUP_TIME_MS 110
+/*
+ * Register group u31 has 2 pages for usage table entries.
+ */
+#define AXIOM_U31_MAX_USAGES 0xff
+#define AXIOM_U31_BYTES_PER_USAGE 6
+#define AXIOM_U31_PAGE0_LENGTH 0x0C
+#define AXIOM_U31_BOOTMODE_MASK BIT(7)
+#define AXIOM_U31_DEVID_MASK GENMASK(14, 0)
+
+#define AXIOM_MAX_REPORT_LEN 0x7f
+
+#define AXIOM_CMD_HEADER_READ_MASK BIT(15)
+#define AXIOM_U41_MAX_TARGETS 10
+
+#define AXIOM_U46_AUX_CHANNELS 4
+#define AXIOM_U46_AUX_MASK GENMASK(11, 0)
+
+#define AXIOM_COMMS_MAX_USAGE_PAGES 3
+#define AXIOM_COMMS_PAGE_SIZE 256
+#define AXIOM_COMMS_REPORT_LEN_MASK GENMASK(6, 0)
+
+#define AXIOM_REPORT_USAGE_ID 0x34
+#define AXIOM_DEVINFO_USAGE_ID 0x31
+#define AXIOM_USAGE_2HB_REPORT_ID 0x01
+#define AXIOM_USAGE_2AUX_REPORT_ID 0x46
+#define AXIOM_USAGE_2DCTS_REPORT_ID 0x41
+
+#define AXIOM_PAGE_OFFSET_MASK GENMASK(6, 0)
+
+struct axiom_devinfo {
+ __le16 device_id;
+ u8 fw_minor;
+ u8 fw_major;
+ u8 fw_info_extra;
+ u8 tcp_revision;
+ u8 bootloader_fw_minor;
+ u8 bootloader_fw_major;
+ __le16 jedec_id;
+ u8 num_usages;
+} __packed;
+
+/*
+ * Describes parameters of a specific usage, essentially a single element of
+ * the "Usage Table"
+ */
+struct axiom_usage_entry {
+ u8 id;
+ bool is_report;
+ u8 start_page;
+ u8 num_pages;
+};
+
+/*
+ * Represents state of a touch or target when detected prior to a touch (eg.
+ * hover or proximity events).
+ */
+enum axiom_target_state {
+ AXIOM_TARGET_STATE_NOT_PRESENT = 0,
+ AXIOM_TARGET_STATE_PROX = 1,
+ AXIOM_TARGET_STATE_HOVER = 2,
+ AXIOM_TARGET_STATE_TOUCHING = 3,
+};
+
+struct axiom_u41_target {
+ enum axiom_target_state state;
+ u16 x;
+ u16 y;
+ s8 z;
+ /* force target report processing */
+ bool insert;
+ bool touch;
+};
+
+struct axiom_target_report {
+ u8 index;
+ bool present;
+ u16 x;
+ u16 y;
+ s8 z;
+};
+
+union axiom_cmd_header {
+ __le32 preamble;
+ struct {
+ __le16 target_address;
+ __le16 length;
+ } head;
+};
+
+struct axiom_data {
+ struct axiom_devinfo devinfo;
+ struct device *dev;
+ struct gpio_desc *reset_gpio;
+ struct i2c_client *client;
+ struct input_dev *input_dev;
+ u32 max_report_len;
+ u8 rx_buf[AXIOM_COMMS_MAX_USAGE_PAGES * AXIOM_COMMS_PAGE_SIZE];
+ struct axiom_u41_target targets[AXIOM_U41_MAX_TARGETS];
+ struct axiom_usage_entry usage_table[AXIOM_U31_MAX_USAGES];
+ bool usage_table_populated;
+ struct regmap *regmap;
+ struct touchscreen_properties prop;
+};
+
+static const struct regmap_config axiom_i2c_regmap_config = {
+ .reg_bits = 32,
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+ .val_bits = 8,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+};
+
+/*
+ * axiom devices are typically configured to report touches at a rate
+ * of 100Hz (10ms) for systems that require polling for reports.
+ * When reports are polled, it will be expected to occasionally
+ * observe the overflow bit being set in the reports.
+ * This indicates that reports are not being read fast enough.
+ */
+#define POLL_INTERVAL_DEFAULT_MS 10
+
+/* Translate usage/page/offset triplet into physical address. */
+static u16 axiom_usage_to_target_address(struct axiom_data *ts, u8 usage, u8 page,
+ char offset)
+{
+ /* At the moment the convention is that u31 is always at physical address 0x0 */
+ if (!ts->usage_table_populated) {
+ if (usage == AXIOM_DEVINFO_USAGE_ID)
+ return ((page << 8) + offset);
+ else
+ return 0xffff;
+ }
+
+ if (page >= ts->usage_table[usage].num_pages) {
+ dev_err(ts->dev, "Invalid usage table! usage: u%02x, page: %02x, offset: %02x\n",
+ usage, page, offset);
+ return 0xffff;
+ }
+
+ return ((ts->usage_table[usage].start_page + page) << 8) + offset;
+}
+
+static int axiom_read(struct axiom_data *ts, u8 usage, u8 page, void *buf, u16 len)
+{
+ union axiom_cmd_header cmd_header;
+ int ret;
+
+ cmd_header.head.target_address =
+ cpu_to_le16(axiom_usage_to_target_address(ts, usage, page, 0));
+ cmd_header.head.length = cpu_to_le16(len | AXIOM_CMD_HEADER_READ_MASK);
+
+ ret = regmap_write(ts->regmap, cmd_header.preamble, 0);
+ if (ret) {
+ dev_err(ts->dev, "failed to write preamble, error %d\n", ret);
+ return ret;
+ }
+
+ ret = regmap_raw_read(ts->regmap, 0, buf, len);
+ if (ret) {
+ dev_err(ts->dev, "failed to read target address %04x, error %d\n",
+ cmd_header.head.target_address, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * One of the main purposes for reading the usage table is to identify
+ * which usages reside at which target address.
+ * When performing subsequent reads or writes to AXIOM, the target address
+ * is used to specify which usage is being accessed.
+ * Consider the following discovery code which will build up the usage table.
+ */
+static u32 axiom_populate_usage_table(struct axiom_data *ts)
+{
+ struct axiom_usage_entry *usage_table;
+ u8 *rx_data = ts->rx_buf;
+ u32 max_report_len = 0;
+ u32 usage_id;
+ int error;
+
+ usage_table = ts->usage_table;
+
+ /* Read the second page of usage u31 to get the usage table */
+ error = axiom_read(ts, AXIOM_DEVINFO_USAGE_ID, 1, rx_data,
+ (AXIOM_U31_BYTES_PER_USAGE * ts->devinfo.num_usages));
+
+ if (error)
+ return error;
+
+ for (usage_id = 0; usage_id < ts->devinfo.num_usages; usage_id++) {
+ u16 offset = (usage_id * AXIOM_U31_BYTES_PER_USAGE);
+ u8 id = rx_data[offset + 0];
+ u8 start_page = rx_data[offset + 1];
+ u8 num_pages = rx_data[offset + 2];
+ u32 max_offset = ((rx_data[offset + 3] & AXIOM_PAGE_OFFSET_MASK) + 1) * 2;
+
+ usage_table[id].is_report = !num_pages;
+
+ /* Store the entry into the usage table */
+ usage_table[id].id = id;
+ usage_table[id].start_page = start_page;
+ usage_table[id].num_pages = num_pages;
+
+ dev_dbg(ts->dev, "Usage u%02x Info: %*ph\n", id, AXIOM_U31_BYTES_PER_USAGE,
+ &rx_data[offset]);
+
+ /* Identify the max report length the module will receive */
+ if (usage_table[id].is_report && max_offset > max_report_len)
+ max_report_len = max_offset;
+ }
+
+ ts->usage_table_populated = true;
+
+ return max_report_len;
+}
+
+static int axiom_discover(struct axiom_data *ts)
+{
+ int error;
+
+ /*
+ * Fetch the first page of usage u31 to get the
+ * device information and the number of usages
+ */
+ error = axiom_read(ts, AXIOM_DEVINFO_USAGE_ID, 0, &ts->devinfo, AXIOM_U31_PAGE0_LENGTH);
+ if (error)
+ return error;
+
+ dev_dbg(ts->dev, " Boot Mode : %s\n",
+ FIELD_GET(AXIOM_U31_BOOTMODE_MASK,
+ le16_to_cpu(ts->devinfo.device_id)) ? "BLP" : "TCP");
+ dev_dbg(ts->dev, " Device ID : %04lx\n",
+ FIELD_GET(AXIOM_U31_DEVID_MASK, le16_to_cpu(ts->devinfo.device_id)));
+ dev_dbg(ts->dev, " Firmware Rev : %02x.%02x\n", ts->devinfo.fw_major,
+ ts->devinfo.fw_minor);
+ dev_dbg(ts->dev, " Bootloader Rev : %02x.%02x\n", ts->devinfo.bootloader_fw_major,
+ ts->devinfo.bootloader_fw_minor);
+ dev_dbg(ts->dev, " FW Extra Info : %04x\n", ts->devinfo.fw_info_extra);
+ dev_dbg(ts->dev, " Silicon : %04x\n", le16_to_cpu(ts->devinfo.jedec_id));
+ dev_dbg(ts->dev, " Number usages : %04x\n", ts->devinfo.num_usages);
+
+ ts->max_report_len = axiom_populate_usage_table(ts);
+ if (!ts->max_report_len || !ts->devinfo.num_usages ||
+ ts->max_report_len > AXIOM_MAX_REPORT_LEN) {
+ dev_err(ts->dev, "Invalid report length or usages number");
+ return -EINVAL;
+ }
+
+ dev_dbg(ts->dev, "Max Report Length: %u\n", ts->max_report_len);
+
+ return 0;
+}
+
+/*
+ * Support function to axiom_process_u41_report.
+ * Generates input-subsystem events for every target.
+ * After calling this function the caller shall issue
+ * a Sync to the input sub-system.
+ */
+static bool axiom_process_u41_report_target(struct axiom_data *ts,
+ struct axiom_target_report *target)
+{
+ struct input_dev *input_dev = ts->input_dev;
+ struct axiom_u41_target *target_prev_state;
+ enum axiom_target_state current_state;
+ int id;
+
+ /* Verify the target index */
+ if (target->index >= AXIOM_U41_MAX_TARGETS) {
+ dev_err(ts->dev, "Invalid target index! %u\n", target->index);
+ return false;
+ }
+
+ target_prev_state = &ts->targets[target->index];
+
+ current_state = AXIOM_TARGET_STATE_NOT_PRESENT;
+
+ if (target->present) {
+ if (target->z >= 0)
+ current_state = AXIOM_TARGET_STATE_TOUCHING;
+ else if (target->z > AXIOM_PROX_LEVEL && target->z < 0)
+ current_state = AXIOM_TARGET_STATE_HOVER;
+ else if (target->z == AXIOM_PROX_LEVEL)
+ current_state = AXIOM_TARGET_STATE_PROX;
+ }
+
+ id = target->index;
+
+ dev_dbg(ts->dev, "U41 Target T%u, present:%u, x:%u, y:%u, z:%d\n",
+ target->index, target->present,
+ target->x, target->y, target->z);
+
+ switch (current_state) {
+ case AXIOM_TARGET_STATE_NOT_PRESENT:
+ case AXIOM_TARGET_STATE_PROX:
+ if (!target_prev_state->insert)
+ break;
+ target_prev_state->insert = false;
+
+ input_mt_report_slot_inactive(input_dev);
+ /*
+ * make sure the previous coordinates are
+ * all off screen when the finger comes back
+ */
+ target->x = 65535;
+ target->y = 65535;
+ target->z = AXIOM_PROX_LEVEL;
+ break;
+ case AXIOM_TARGET_STATE_HOVER:
+ case AXIOM_TARGET_STATE_TOUCHING:
+ target_prev_state->insert = true;
+ input_report_abs(input_dev, ABS_MT_TRACKING_ID, id);
+ input_mt_slot(ts->input_dev, id);
+ input_mt_report_slot_state(ts->input_dev, MT_TOOL_FINGER, true);
+ input_report_abs(input_dev, ABS_MT_POSITION_X, target->x);
+ input_report_abs(input_dev, ABS_MT_POSITION_Y, target->y);
+
+ if (current_state == AXIOM_TARGET_STATE_TOUCHING) {
+ input_report_abs(input_dev, ABS_MT_DISTANCE, 0);
+ input_report_abs(input_dev, ABS_MT_PRESSURE, target->z);
+ } else {
+ input_report_abs(input_dev, ABS_MT_DISTANCE, -target->z);
+ input_report_abs(input_dev, ABS_MT_PRESSURE, 0);
+ }
+
+ break;
+ default:
+ break;
+ }
+
+ target_prev_state->state = current_state;
+ target_prev_state->x = target->x;
+ target_prev_state->y = target->y;
+ target_prev_state->z = target->z;
+
+ return true;
+}
+
+/*
+ * U41 is the output report of the 2D CTS and contains the status of targets
+ * (including contacts and pre-contacts) along with their X,Y,Z values.
+ * When a target has been removed (no longer detected),
+ * the corresponding X,Y,Z values will be zeroed.
+ */
+static bool axiom_process_u41_report(struct axiom_data *ts, u8 *rx_buf)
+{
+ struct axiom_target_report target;
+ bool update_done = false;
+ u16 target_status;
+ int i;
+
+ target_status = get_unaligned_le16(rx_buf + 1);
+
+ for (i = 0; i < AXIOM_U41_MAX_TARGETS; i++) {
+ u8 *target_step = &rx_buf[i * 4];
+
+ target.index = i;
+ target.present = ((target_status & (1 << i)) != 0) ? true : false;
+ target.x = get_unaligned_le16(target_step + 3);
+ target.y = get_unaligned_le16(target_step + 5);
+ target.z = (s8)(rx_buf[i + 43]);
+ update_done |= axiom_process_u41_report_target(ts, &target);
+ }
+
+ return update_done;
+}
+
+/*
+ * Validates the crc and demultiplexes the axiom reports to the appropriate
+ * report handler
+ */
+static int axiom_handle_events(struct axiom_data *ts)
+{
+ struct input_dev *input_dev = ts->input_dev;
+ u8 *report_data = ts->rx_buf;
+ struct device *dev = ts->dev;
+ u16 crc_report;
+ u8 *crc_bytes;
+ u16 crc_calc;
+ int error;
+ u8 len;
+
+ error = axiom_read(ts, AXIOM_REPORT_USAGE_ID, 0, report_data, ts->max_report_len);
+ if (error)
+ return error;
+
+ len = (report_data[0] & AXIOM_COMMS_REPORT_LEN_MASK) << 1;
+ if (len <= 2) {
+ dev_err(dev, "Zero length report discarded.\n");
+ return -ENODATA;
+ }
+
+ /* Validate the report CRC */
+ crc_bytes = &report_data[len];
+
+ crc_report = get_unaligned_le16(crc_bytes - 2);
+ /* Length is in 16 bit words and remove the size of the CRC16 itself */
+ crc_calc = crc16(0, report_data, (len - 2));
+
+ if (crc_calc != crc_report) {
+ dev_err(dev,
+ "CRC mismatch! Expected: %#x, Calculated CRC: %#x.\n",
+ crc_report, crc_calc);
+ return -EINVAL;
+ }
+
+ switch (report_data[1]) {
+ case AXIOM_USAGE_2DCTS_REPORT_ID:
+ if (axiom_process_u41_report(ts, &report_data[1])) {
+ input_mt_sync_frame(input_dev);
+ input_sync(input_dev);
+ }
+ break;
+
+ case AXIOM_USAGE_2AUX_REPORT_ID:
+ /* This is an aux report (force), not used currently */
+ break;
+
+ case AXIOM_USAGE_2HB_REPORT_ID:
+ /* This is a heartbeat report */
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void axiom_i2c_poll(struct input_dev *input_dev)
+{
+ struct axiom_data *ts = input_get_drvdata(input_dev);
+
+ axiom_handle_events(ts);
+}
+
+static irqreturn_t axiom_irq(int irq, void *dev_id)
+{
+ struct axiom_data *ts = dev_id;
+
+ axiom_handle_events(ts);
+
+ return IRQ_HANDLED;
+}
+
+static void axiom_reset(struct gpio_desc *reset_gpio)
+{
+ gpiod_set_value_cansleep(reset_gpio, 1);
+ usleep_range(1000, 2000);
+ gpiod_set_value_cansleep(reset_gpio, 0);
+ msleep(AXIOM_STARTUP_TIME_MS);
+}
+
+static int axiom_i2c_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct input_dev *input_dev;
+ struct axiom_data *ts;
+ u32 poll_interval;
+ int target;
+ int error;
+
+ ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
+ if (!ts)
+ return -ENOMEM;
+
+ i2c_set_clientdata(client, ts);
+ ts->client = client;
+ ts->dev = dev;
+
+ ts->regmap = devm_regmap_init_i2c(client, &axiom_i2c_regmap_config);
+ error = PTR_ERR_OR_ZERO(ts->regmap);
+ if (error) {
+ dev_err(dev, "Failed to initialize regmap: %d\n", error);
+ return error;
+ }
+
+ error = devm_regulator_get_enable(dev, "vddi");
+ if (error)
+ return dev_err_probe(&client->dev, error,
+ "Failed to enable VDDI regulator\n");
+
+ error = devm_regulator_get_enable(dev, "vdda");
+ if (error)
+ return dev_err_probe(&client->dev, error,
+ "Failed to enable VDDA regulator\n");
+
+ ts->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ts->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ts->reset_gpio), "failed to get reset GPIO\n");
+
+ /* Make sure the time after a power ON sequence is meet */
+ if (ts->reset_gpio)
+ axiom_reset(ts->reset_gpio);
+ else
+ msleep(AXIOM_STARTUP_TIME_MS);
+
+ error = axiom_discover(ts);
+ if (error)
+ return dev_err_probe(dev, error, "Failed touchscreen discover\n");
+
+ input_dev = devm_input_allocate_device(ts->dev);
+ if (!input_dev)
+ return -ENOMEM;
+
+ input_dev->name = "TouchNetix axiom Touchscreen";
+ input_dev->phys = "input/axiom_ts";
+
+ input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, 65535, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, 65535, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_TOOL_TYPE, 0, MT_TOOL_FINGER, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_DISTANCE, 0, 127, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 127, 0, 0);
+
+ touchscreen_parse_properties(input_dev, true, &ts->prop);
+
+ /* Registers the axiom device as a touchscreen instead of a mouse pointer */
+ error = input_mt_init_slots(input_dev, AXIOM_U41_MAX_TARGETS, INPUT_MT_DIRECT);
+ if (error)
+ return error;
+
+ /* Enables the raw data for up to 4 force channels to be sent to the input subsystem */
+ set_bit(EV_MSC, input_dev->evbit);
+ /* Declare that we support "RAW" Miscellaneous events */
+ set_bit(MSC_RAW, input_dev->mscbit);
+
+ ts->input_dev = input_dev;
+ input_set_drvdata(ts->input_dev, ts);
+
+ /* Ensure that all reports are initialised to not be present. */
+ for (target = 0; target < AXIOM_U41_MAX_TARGETS; target++)
+ ts->targets[target].state = AXIOM_TARGET_STATE_NOT_PRESENT;
+
+ if (client->irq) {
+ error = devm_request_threaded_irq(dev, client->irq, NULL,
+ axiom_irq, IRQF_ONESHOT, dev_name(dev), ts);
+ if (error)
+ dev_err_probe(dev, error, "failed to request irq");
+ } else {
+ error = input_setup_polling(input_dev, axiom_i2c_poll);
+ if (error)
+ return dev_err_probe(ts->dev, error, "Unable to set up polling mode\n");
+
+ if (!device_property_read_u32(ts->dev, "poll-interval", &poll_interval))
+ input_set_poll_interval(input_dev, poll_interval);
+ else
+ input_set_poll_interval(input_dev, POLL_INTERVAL_DEFAULT_MS);
+ }
+
+ error = input_register_device(input_dev);
+ if (error)
+ return dev_err_probe(ts->dev, error, "failed to register input device\n");
+
+ return 0;
+}
+
+static const struct i2c_device_id axiom_i2c_id_table[] = {
+ { "ax54a" },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, axiom_i2c_id_table);
+
+static const struct of_device_id axiom_i2c_of_match[] = {
+ { .compatible = "touchnetix,ax54a", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, axiom_i2c_of_match);
+
+static struct i2c_driver axiom_i2c_driver = {
+ .driver = {
+ .name = "axiom",
+ .of_match_table = axiom_i2c_of_match,
+ },
+ .id_table = axiom_i2c_id_table,
+ .probe = axiom_i2c_probe,
+};
+module_i2c_driver(axiom_i2c_driver);
+
+MODULE_AUTHOR("Bart Prescott <bartp@baasheep.co.uk>");
+MODULE_AUTHOR("Pedro Torruella <pedro.torruella@touchnetix.com>");
+MODULE_AUTHOR("Mark Satterthwaite <mark.satterthwaite@touchnetix.com>");
+MODULE_AUTHOR("Hannah Rossiter <hannah.rossiter@touchnetix.com>");
+MODULE_AUTHOR("Kamel Bouhara <kamel.bouhara@bootlin.com>");
+MODULE_DESCRIPTION("TouchNetix axiom touchscreen I2C bus driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] Fixes: bda38f9a41 ("HID: asus: use hid for brightness control on keyboard")
From: Benjamin Tissoires @ 2024-06-25 14:59 UTC (permalink / raw)
To: Luke D. Jones; +Cc: linux-input, linux-kernel, jikos
In-Reply-To: <20240624001450.969059-1-luke@ljones.dev>
Hi Luke,
On Jun 24 2024, Luke D. Jones wrote:
> - Fix missing braces around initializer
> - Remove unused function declaration from asus-wmi.h
>
> Signed-off-by: Luke D. Jones <luke@ljones.dev>
You are missing Reported-by: Mark Brown <broonie@kernel.org> to give
credits where it's due and also a link to the report:
Link: https://lore.kernel.org/all/ZnQ03jc-xEWam2cR@sirena.org.uk/
The subject formatting is also wrong.
> ---
> include/linux/platform_data/x86/asus-wmi.h | 11 +----------
That's weird. That file shouldn't be touched from us (on the HID side)
without the ack from Hans or the platform x86 people.
And bda38f9a41 ("HID: asus: use hid for brightness...) doesn't have such
an ack.
This got me realize that the initial patch was incorrectly taken through
the hid tree:
in [1] Hans explicitely asked to take the patch through his tree.
So I'm going to drop your patch from the HID tree and ask you to
resubmit the entire patch as a v3 to the platform guys.
Cheers,
Benjamin
[1] https://lore.kernel.org/all/b0d8eebc-5abb-4ec0-898c-af7eedc730d9@redhat.com/
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
> index 96c780efa0d7..74b32e1d6735 100644
> --- a/include/linux/platform_data/x86/asus-wmi.h
> +++ b/include/linux/platform_data/x86/asus-wmi.h
> @@ -162,15 +162,6 @@ static inline int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1,
> #endif
>
> /* To be used by both hid-asus and asus-wmi to determine which controls kbd_brightness */
> -#if IS_ENABLED(CONFIG_ASUS_WMI)
> -bool asus_use_hid_led(void);
> -#else
> -static inline bool asus_use_hid_led(void)
> -{
> - return true;
> -}
> -#endif
> -
> static const struct dmi_system_id asus_use_hid_led_dmi_ids[] = {
> {
> .matches = {
> @@ -202,7 +193,7 @@ static const struct dmi_system_id asus_use_hid_led_dmi_ids[] = {
> DMI_MATCH(DMI_BOARD_NAME, "RC71L"),
> },
> },
> - NULL,
> + { },
> };
>
> #endif /* __PLATFORM_DATA_X86_ASUS_WMI_H */
> --
> 2.45.2
>
^ permalink raw reply
* Re: [PATCH v2 1/1] hid-asus: use hid for brightness control on keyboard
From: Benjamin Tissoires @ 2024-06-25 15:02 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Luke Jones, linux-input, linux-kernel
In-Reply-To: <nycvar.YFH.7.76.2406191639360.24940@cbobk.fhfr.pm>
On Jun 19 2024, Jiri Kosina wrote:
> On Sun, 16 Jun 2024, Luke Jones wrote:
>
> > > I thought this was finalised but I'm still getting conflicting
> > > reports. Please don't merge until I confirm the fix.
> >
> > This is ready for merge now. I have more confirmation that the single
> > patch with no adjustment to report_id works well.
>
> Applied, thanks.
This patch should have been taken through the platform x86 tree [0].
I have now reverted it (and it was buggy, it failed to compile on
linux-next).
Cheers,
Benjamin
[0] https://lore.kernel.org/all/b0d8eebc-5abb-4ec0-898c-af7eedc730d9@redhat.com/
>
> --
> Jiri Kosina
> SUSE Labs
>
^ permalink raw reply
* Re: linux-next: build failure after merge of the bpf-next tree
From: Benjamin Tissoires @ 2024-06-25 15:54 UTC (permalink / raw)
To: Thinker Li
Cc: Mark Brown, Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
bpf, Networking, Jiri Kosina, Martin KaFai Lau, linux-input,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <CAFVMQ6R8ZZE+9jWM1vhEuz2PsLyCgKhpaVD377TKEu4AfGO_iA@mail.gmail.com>
On Jun 24 2024, Thinker Li wrote:
> Hi Mark,
>
> I'm sorry for not getting back to you sooner. I have been traveling
> since my last message.
> I guess this patch is for the HID tree. The changes in this patch are great.
Ok, thanks for the review. However, the need appears because there is a
conflicting update in the bpf tree.
May I ask the bpf maintainers (Daniel/Alexei/Andrii) for an immutable
tag I could merge to so I can take this patch from Mark?
>
> However, I suggest you implement ".update" if you think it is
> reasonable for HID,
> although it is not a MUST-BE. ".update" provides a good feature that
> user space programs
> can update an implementation on the flight.
FWIW, Mark handles linux-next, so not sure he has deep knowledge of
HID-BPF, and not sure he wants too :)
Regarding .update, I'm not sure it's worth the effort for hid-bpf. Right
now HID-BPF programs are just a one-shot: you load them, pin them and
forget. This might be different when systemd starts implementing a HID
firewall, but we can cross that bridge when we see fit.
Cheers,
Benjamin
>
> On Mon, Jun 17, 2024 at 11:16 AM Mark Brown <broonie@kernel.org> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
> > 280 | .reg = hid_bpf_reg,
> > | ^~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
> > 281 | .unreg = hid_bpf_unreg,
> > | ^~~~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
> >
> > Caused by commit
> >
> > 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> >
> > interacting with commit
> >
> > ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
> >
> > from the HID tree.
> >
> > I've fixed it up as below:
> >
> > From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> > From: Mark Brown <broonie@kernel.org>
> > Date: Mon, 17 Jun 2024 19:02:27 +0100
> > Subject: [PATCH] HID: bpf: Fix up build
> >
> > Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> >
> > Signed-off-by: Mark Brown <broonie@kernel.org>
> > ---
> > drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > index 5f200557ff12b..744318e7d936b 100644
> > --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> > +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
> > return 0;
> > }
> >
> > -static int hid_bpf_reg(void *kdata)
> > +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
> > {
> > struct hid_bpf_ops *ops = kdata;
> > struct hid_device *hdev;
> > @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
> > return err;
> > }
> >
> > -static void hid_bpf_unreg(void *kdata)
> > +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
> > {
> > struct hid_bpf_ops *ops = kdata;
> > struct hid_device *hdev;
> > --
> > 2.39.2
> >
^ permalink raw reply
* Re: linux-next: build failure after merge of the bpf-next tree
From: Mark Brown @ 2024-06-25 16:03 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Thinker Li, Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
bpf, Networking, Jiri Kosina, Martin KaFai Lau, linux-input,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <ud5j6hbozgg6em43volidpffykdtd2lpf32etmdiyksorl2cb4@whtseaibw2xw>
[-- Attachment #1: Type: text/plain, Size: 480 bytes --]
On Tue, Jun 25, 2024 at 05:54:47PM +0200, Benjamin Tissoires wrote:
> On Jun 24 2024, Thinker Li wrote:
> > However, I suggest you implement ".update" if you think it is
> > reasonable for HID,
> > although it is not a MUST-BE. ".update" provides a good feature that
> > user space programs
> > can update an implementation on the flight.
> FWIW, Mark handles linux-next, so not sure he has deep knowledge of
> HID-BPF, and not sure he wants too :)
Only holiday cover but yes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] Input: qt1050 - handle CHIP_ID reading error
From: Dmitry Torokhov @ 2024-06-25 16:14 UTC (permalink / raw)
To: Andrei Lalaev; +Cc: robh, m.felsch, linux-input, linux-kernel, Andrei Lalaev
In-Reply-To: <20240617183018.916234-1-andrey.lalaev@gmail.com>
On Mon, Jun 17, 2024 at 08:30:18PM +0200, Andrei Lalaev wrote:
> From: Andrei Lalaev <andrei.lalaev@anton-paar.com>
>
> If the device is missing, we get the following error:
>
> qt1050 3-0041: ID -1340767592 not supported
>
> Let's handle this situation and print more informative error
> when reading of CHIP_ID fails:
>
> qt1050 3-0041: Failed to read chip ID: -6
>
> Fixes: cbebf5addec1 ("Input: qt1050 - add Microchip AT42QT1050 support")
> Signed-off-by: Andrei Lalaev <andrei.lalaev@anton-paar.com>
Applied, thank you.
But how did we get into the situation with the chip being missing?
Incorrect DTB for the board?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: linux-next: build failure after merge of the bpf-next tree
From: Alexei Starovoitov @ 2024-06-25 17:14 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Thinker Li, Mark Brown, Daniel Borkmann, Alexei Starovoitov,
Andrii Nakryiko, bpf, Networking, Jiri Kosina, Martin KaFai Lau,
open list:HID CORE LAYER, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <ud5j6hbozgg6em43volidpffykdtd2lpf32etmdiyksorl2cb4@whtseaibw2xw>
On Tue, Jun 25, 2024 at 8:54 AM Benjamin Tissoires <bentiss@kernel.org> wrote:
>
> On Jun 24 2024, Thinker Li wrote:
> > Hi Mark,
> >
> > I'm sorry for not getting back to you sooner. I have been traveling
> > since my last message.
> > I guess this patch is for the HID tree. The changes in this patch are great.
>
> Ok, thanks for the review. However, the need appears because there is a
> conflicting update in the bpf tree.
>
> May I ask the bpf maintainers (Daniel/Alexei/Andrii) for an immutable
> tag I could merge to so I can take this patch from Mark?
I'm not sure how that would look like.
imo conflict is minor enough.
When net-next/bpf-next lands in the upcoming merge window
just provide Mark's patch as a conflict resolution suggestion
in the cover letter of hid PR ?
^ permalink raw reply
* Re: [PATCH] Input: qt1050 - handle CHIP_ID reading error
From: Andrei Lalaev @ 2024-06-25 19:30 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: andrey.lalaev, linux-input, linux-kernel, robh, m.felsch
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 319 bytes --]
> But how did we get into the situation with the chip being missing?
In my case, this chip is a part of an external board.
So, for example, I see this message in the case of a bad cable connection.
Also, I prefer to see messages with error codes instead of random values from a stack :)
Best regards,
Andrei Lalaev
^ permalink raw reply
* Re: [PATCH] Input: qt1050 - handle CHIP_ID reading error
From: Andrei Lalaev @ 2024-06-25 19:35 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: andrey.lalaev, linux-input, linux-kernel, robh, m.felsch
In-Reply-To: <Znrs5QVAuSjH5sCT@google.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 393 bytes --]
> But how did we get into the situation with the chip being missing?
In my case, this chip is a part of an external board.
So, for example, I see this message in the case of a bad cable connection.
Also, I prefer to see messages with error codes instead of random values from a stack :)
P.S. sorry for the previous email, I made a typo in git-send-email args.
Best regards,
Andrei Lalaev
^ permalink raw reply
* Re: [PATCH] Input: ads7846 - add dummy command register clearing cycle
From: Dmitry Torokhov @ 2024-06-25 20:50 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-input, Arnd Bergmann, Greg Kroah-Hartman, Linus Walleij,
kernel
In-Reply-To: <dfc1b846-24ea-42c4-adfe-2b762e2f8851@denx.de>
On Sun, Jun 23, 2024 at 08:21:00PM +0200, Marek Vasut wrote:
> On 3/20/24 8:23 AM, Marek Vasut wrote:
> > On STM32MP135F with XPT2046 touch controller attached to SPI bus, it has
> > been observed that the touch controller locks up after Linux kernel has
> > finished booting. Adding a dummy cycle on the SPI bus seems to mitigate
> > the lock up.
> >
> > The XPTEK XPT2046 controller seems to be an identical clone of TI TSC2046,
> > the datasheet seems to be a clone of the TI part as well, text seem to be
> > word to word identical, except all the pictures have been drawn again.
> >
> > This touch controller is present e.g. on WaveShare 3.2inch RPi LCD (B)
> > panel, the DTO provided by WaveShare uses 50 kHz SPI clock for this
> > touch controller, which is unusually low and possibly might have been
> > used as some sort of workaround for an issue. The SPI LCD on the same
> > bus uses 16 MHz clock.
> >
> > SPI bus DT properties spi-cs-setup-delay-ns, spi-cs-hold-delay-ns,
> > spi-cs-inactive-delay-ns, spi-rx-delay-us, spi-tx-delay-us set to
> > range of 500ns..5us seem to have no impact on the behavior of the
> > touch controller, the lock up always occurs. The STM32MP13xx SPI
> > controller users GPIO control for the nCS pins.
> >
> > Since the dummy cycle happens after the controller has been put into
> > power down mode and both ADC and REF regulators have been disabled,
> > the cycle should have no impact on the configuration of the controller,
> > i.e. it should be a NOP.
> >
> > It is unclear whether this problem is specific to this cloned XPT2046
> > controller, or whether this is also present on TSC2046. A test on
> > either TSC2046 or ADS7846 would be very welcome.
>
> Hi,
>
> Are there still any open topics with this patch ?
I am concerned that we are putting workaroud for a single controller
into common function. Can we quirk it based on compatible? If not then I
would like someone to run tests on other controllers. Unfortunately I do
not have such hardware.
Linus, do you have devices with ads7846 or tsc2046 by chance? Spitz?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: Add driver for PixArt PS/2 touchpad
From: Aseda Aboagye @ 2024-06-25 23:55 UTC (permalink / raw)
To: Binbin Zhou
Cc: Binbin Zhou, Huacai Chen, Jon Xie, Jay Lee, Dmitry Torokhov,
Huacai Chen, loongson-kernel, linux-input, Xiaotian Wu
In-Reply-To: <20240624065359.2985060-1-zhoubinbin@loongson.cn>
Hi Binbin,
On Mon, Jun 24, 2024 at 02:53:59PM +0800, Binbin Zhou wrote:
> +
> +static void pixart_reset(struct psmouse *psmouse)
> +{
> + ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);
> + msleep(100);
> + psmouse_reset(psmouse);
> +}
What is the reason for the 100ms delay here? Is it to prepare the
controller for the upcoming reset? If so, could it perhaps be
defined as a macro?
Thanks,
--
Aseda Aboagye
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: add OnePlus 8T (kebab)
From: Bjorn Andersson @ 2024-06-26 4:16 UTC (permalink / raw)
To: Caleb Connolly
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Daniel Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Konrad Dybcio,
Henrik Rydberg, dri-devel, devicetree, linux-input, linux-arm-msm,
~postmarketos/upstreaming, Frieder Hannenheim
In-Reply-To: <20240624-oneplus8-v1-7-388eecf2dff7@postmarketos.org>
On Mon, Jun 24, 2024 at 03:30:31AM GMT, Caleb Connolly wrote:
> Initial support for USB, UFS, touchscreen, panel, wifi, and bluetooth.
>
Nice.
> diff --git a/arch/arm64/boot/dts/qcom/sm8250-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-oneplus-common.dtsi
[..]
> + vph_pwr: vph-pwr-regulator {
Please keep nodes sorted by address, then node name, then label (as
applicable). Perhaps making the -regulator suffix a regulator- prefix
instead (to keep them grouped).
> + compatible = "regulator-fixed";
> + regulator-name = "vph_pwr";
> + regulator-min-microvolt = <3700000>;
> + regulator-max-microvolt = <3700000>;
> + regulator-always-on;
> + };
> +
> + vreg_s4a_1p8: vreg-s4a-1p8 {
> + compatible = "regulator-fixed";
> + regulator-name = "vreg_s4a_1p8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
[..]
> +&adsp {
> + status = "okay";
Per Documentation/devicetree/bindings/dts-coding-style.rst please keep
"status" as last property in your nodes.
> + firmware-name = "qcom/sm8250/OnePlus/adsp.mbn";
> +};
> +
[..]
> +&mdss_dsi0 {
> + status = "okay";
> + vdda-supply = <&vreg_l9a_1p2>;
> +
> + display_panel: panel@0 {
> + reg = <0>;
> + vddio-supply = <&vreg_l14a_1p8>;
> + vdd-supply = <&vreg_l11c_3p3>;
> + avdd-supply = <&panel_avdd_5p5>;
How do you know that the panel will have these properties, when you
don't give it a compatible here? Not a strong objection, but perhaps
this should be pushed out?
> + /* FIXME: There is a bug somewhere in the display stack and it isn't
> + * possible to get the panel to a working state after toggling reset.
> + * At best it just shows one or more vertical red lines. So for now
> + * let's skip the reset GPIO.
> + */
> + // reset-gpios = <&tlmm 75 GPIO_ACTIVE_LOW>;
> +
> + pinctrl-0 = <&panel_reset_pins &panel_vsync_pins &panel_vout_pins>;
> + pinctrl-names = "default";
> +
> + status = "disabled";
> +
> + port {
> + panel_in_0: endpoint {
> + remote-endpoint = <&mdss_dsi0_out>;
> + };
> + };
> + };
> +
> +};
[..]
> +&pm8150_gpios {
> + gpio-reserved-ranges = <2 1>, <4 1>, <8 1>;
How come?
> +};
> +
[..]
> +&tlmm {
> + gpio-reserved-ranges = <28 4>, <40 4>;
> +
> + bt_en_state: bt-default-state {
> + pins = "gpio21";
> + function = "gpio";
> + drive-strength = <16>;
> + output-low;
> + bias-pull-up;
> + };
> +
> + wlan_en_state: wlan-default-state {
> + wlan-en-pins {
Perhaps flatten this?
> + pins = "gpio20";
> + function = "gpio";
> +
> + drive-strength = <16>;
> + output-low;
> + bias-pull-up;
> + };
> + };
> +
[..]
> diff --git a/arch/arm64/boot/dts/qcom/sm8250-oneplus-kebab.dts b/arch/arm64/boot/dts/qcom/sm8250-oneplus-kebab.dts
[..]
> +&i2c13 {
[..]
> +};
> +
> +&display_panel {
'd' < 'i'
Regards,
Bjorn
> + compatible = "samsung,amb655x";
> + status = "okay";
> +};
>
> --
> 2.45.0
>
^ 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