Linux Input/HID development
 help / color / mirror / Atom feed
* Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS
From: Ihor Solodrai @ 2026-01-13 22:03 UTC (permalink / raw)
  To: Eduard Zingerman, Alexei Starovoitov, Andrii Nakryiko,
	Daniel Borkmann, Martin KaFai Lau
  Cc: Mykyta Yatsenko, Tejun Heo, Alan Maguire, Benjamin Tissoires,
	Jiri Kosina, bpf, linux-kernel, linux-input, sched-ext
In-Reply-To: <952853dd064d5303a7e7ec8e58028e9ee88f2fad.camel@gmail.com>

On 1/13/26 12:39 PM, Eduard Zingerman wrote:
> On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote:
>> A kernel function bpf_foo marked with KF_IMPLICIT_ARGS flag is
>> expected to have two associated types in BTF:
>>   * `bpf_foo` with a function prototype that omits implicit arguments
>>   * `bpf_foo_impl` with a function prototype that matches the kernel
>>      declaration of `bpf_foo`, but doesn't have a ksym associated with
>>      its name
>>
>> In order to support kfuncs with implicit arguments, the verifier has
>> to know how to resolve a call of `bpf_foo` to the correct BTF function
>> prototype and address.
>>
>> To implement this, in add_kfunc_call() kfunc flags are checked for
>> KF_IMPLICIT_ARGS. For such kfuncs a BTF func prototype is adjusted to
>> the one found for `bpf_foo_impl` (func_name + "_impl" suffix, by
>> convention) function in BTF.
>>
>> This effectively changes the signature of the `bpf_foo` kfunc in the
>> context of verification: from one without implicit args to the one
>> with full argument list.
>>
>> Whether a kfunc argument is implicit or not is determined by
>> is_kfunc_arg_implicit(). The values of implicit arguments by design
>> are provided by the verifier, and so they can only be of particular
>> types. In this patch the only allowed implicit arg type is a pointer
>> to struct bpf_prog_aux. The __prog args (usually void *) are also
>> considered implicit for backwards compatibility.
>>
>> In order to enable the verifier to correctly set an implicit
>> bpf_prog_aux arg value at runtime, is_kfunc_arg_prog() is extended to
>> check for the arg type. At a point when prog arg is determined in
>> check_kfunc_args() the kfunc with implicit args already has a
>> prototype with full argument list, so the existing value patch
>> mechanism just works.
>>
>> If a new kfunc with KF_IMPLICIT_ARG is declared for an existing kfunc
>> that uses a __prog argument (a legacy case), the prototype
>> substitution works in exactly the same way, assuming the kfunc follows
>> the _impl naming convention. The difference is only in how _impl
>> prototype is added to the BTF, which is not the verifier's
>> concern. See a subsequent resolve_btfids patch for details.
>>
>> In check_kfunc_call() reset the subreg_def of registers holding
>> implicit arguments to correctly track zero extensions.
>>
>> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
>> ---
> 
> Overall lgtm.
> 
> [...]
> 
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> 
> [...]
> 
>> @@ -14303,6 +14358,17 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>>  	for (i = 0; i < nargs; i++) {
>>  		u32 regno = i + 1;
>>  
>> +		/*
>> +		 * Implicit kfunc arguments are set after main verification pass.
>> +		 * For correct tracking of zero-extensions we have to reset subreg_def for such
>> +		 * args. Otherwise mark_btf_func_reg_size() will be inspecting subreg_def of regs
>> +		 * from an earlier (irrelevant) point in the program, which may lead to an error
>> +		 * in opt_subreg_zext_lo32_rnd_hi32().
>> +		 */
>> +		if (unlikely(KF_IMPLICIT_ARGS & meta.kfunc_flags
>> +				&& is_kfunc_arg_implicit(desc_btf, &args[i])))
>> +			regs[regno].subreg_def = DEF_NOT_SUBREG;
>> +
> 
> Did you try doing this in `mark_reg_not_init()`?
> This function is called for R1-R5 some time prior this hunk.

> Did you try doing this in `mark_reg_not_init()`?

Just tried, it doesn't work because REG0 is considered a caller saved
register, and so it breaks the zext tracking:

        #define CALLER_SAVED_REGS 6
        static const int caller_saved[CALLER_SAVED_REGS] = {
	     BPF_REG_0, BPF_REG_1, BPF_REG_2, BPF_REG_3, BPF_REG_4, BPF_REG_5
        };

        [...]

	for (i = 0; i < CALLER_SAVED_REGS; i++)
		mark_reg_not_init(env, regs, caller_saved[i]);

CI run for the diff below (on top of this series):
https://github.com/kernel-patches/bpf/actions/runs/20972520708


diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index b4e40b87e8fa..8bbcd1466815 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2784,6 +2784,8 @@ static void __reg_assign_32_into_64(struct bpf_reg_state *reg)
        }
 }
 
+#define DEF_NOT_SUBREG (0)
+
 /* Mark a register as having a completely unknown (scalar) value. */
 static void __mark_reg_unknown_imprecise(struct bpf_reg_state *reg)
 {
@@ -2798,6 +2800,7 @@ static void __mark_reg_unknown_imprecise(struct bpf_reg_state *reg)
        reg->var_off = tnum_unknown;
        reg->frameno = 0;
        reg->precise = false;
+       reg->subreg_def = DEF_NOT_SUBREG;
        __mark_reg_unbounded(reg);
 }
 
@@ -2892,7 +2895,6 @@ static int mark_btf_ld_reg(struct bpf_verifier_env *env,
        }
 }
 
-#define DEF_NOT_SUBREG (0)
 static void init_reg_state(struct bpf_verifier_env *env,
                           struct bpf_func_state *state)
 {
@@ -14363,17 +14365,6 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
        for (i = 0; i < nargs; i++) {
                u32 regno = i + 1;
 
-               /*
-                * Implicit kfunc arguments are set after main verification pass.
-                * For correct tracking of zero-extensions we have to reset subreg_def for such
-                * args. Otherwise mark_btf_func_reg_size() will be inspecting subreg_def of regs
-                * from an earlier (irrelevant) point in the program, which may lead to an error
-                * in opt_subreg_zext_lo32_rnd_hi32().
-                */
-               if (unlikely(KF_IMPLICIT_ARGS & meta.kfunc_flags
-                               && is_kfunc_arg_implicit(desc_btf, &args[i])))
-                       regs[regno].subreg_def = DEF_NOT_SUBREG;
-
                t = btf_type_skip_modifiers(desc_btf, args[i].type, NULL);
                if (btf_type_is_ptr(t))
                        mark_btf_func_reg_size(env, regno, sizeof(void *));

---

Resetting all reg args appears to be working however (see below).
CI: https://github.com/kernel-patches/bpf/actions/runs/20973490221

Should I send this as a separate patch?

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 8bbcd1466815..9dfcf3149841 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2800,7 +2800,6 @@ static void __mark_reg_unknown_imprecise(struct bpf_reg_state *reg)
        reg->var_off = tnum_unknown;
        reg->frameno = 0;
        reg->precise = false;
-       reg->subreg_def = DEF_NOT_SUBREG;
        __mark_reg_unbounded(reg);
 }
 
@@ -14241,6 +14240,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
        for (i = 0; i < CALLER_SAVED_REGS; i++)
                mark_reg_not_init(env, regs, caller_saved[i]);
 
+       for (i = 0; i < MAX_BPF_FUNC_REG_ARGS; i++) {
+               u32 regno = i + 1;
+               regs[regno].subreg_def = DEF_NOT_SUBREG;
+       }
+
        /* Check return type */
        t = btf_type_skip_modifiers(desc_btf, meta.func_proto->type, NULL);


> What I don't like from structural point of view is:
> - `is_kfunc_arg_implicit()` depends on KF_IMPLICIT_ARGS, but that
>   check is done externally. Hence, the naming is misleading or 'meta'
>   should be passed to `is_kfunc_arg_implicit()`.
> - doing DEF_NOT_SUBREG logically has not much to do with implicit args,
>   so it is a bit confusing that is pre-conditioned like that.
> 
>>  		t = btf_type_skip_modifiers(desc_btf, args[i].type, NULL);
>>  		if (btf_type_is_ptr(t))
>>  			mark_btf_func_reg_size(env, regno, sizeof(void *));


^ permalink raw reply related

* Re: [PATCH 2/3] drivers: input: touchscreen: edt-ft5x06: Add FocalTech FT3518
From: Szczurek @ 2026-01-13 22:21 UTC (permalink / raw)
  To: Dmitry Baryshkov
  Cc: yedaya.ka, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-input,
	devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <o4eu2db3y3wrxaxtxcbxupdc2tzemqvb4fupwfkjfjqmy5qudd@v4umeav2oib2>

On Tue, Jan 13, 2026 at 20:28:27 +0100 Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:

>On Tue, Jan 13, 2026 at 09:12:36PM +0200, Yedaya Katsman via B4 Relay wrote: 
> From: Yedaya Katsman <yedaya.ka@gmail.com> 
> 
> The driver also works with FT3518, which supports up to 10 touch points. 
>  Add compatible data for it. 
> 
> Co-developed-by: SzczurekYT <szczurek@szczurek.yt> 
> Signed-off-by: SzczurekYT <szczurek@szczurek.yt> 
 
>This doesn't look like a name.

Hello
Yes, it isn't a real name.
Yedaya Katsman is upstreaming those patches by me, under my permission,
and I forgot to tell him my name, so he took it from gitlab, which is just a nickname.
All of "SzczurekYT <szczurek@szczurek.yt>" should be replaced with "Kamil Gołda <kamil.golda@protonmail.com>",
this is my name and the e-mail I would like this to be under.
Excuse me for the chaos.
 
> Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com> 
> --- 
>  drivers/input/touchscreen/edt-ft5x06.c | 6 ++++++ 
>  1 file changed, 6 insertions(+) 
> 
 
>-- 
>With best wishes 
>Dmitry

Regards
Kamil Gołda



^ permalink raw reply

* Re: [PATCH 2/3] drivers: input: touchscreen: edt-ft5x06: Add FocalTech FT3518
From: Dmitry Baryshkov @ 2026-01-13 23:19 UTC (permalink / raw)
  To: Szczurek
  Cc: yedaya.ka, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-input,
	devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <19bb972b9d3.12a7d3da3105717.8521466650832407846@szczurek.yt>

On Tue, Jan 13, 2026 at 11:21:02PM +0100, Szczurek wrote:
> On Tue, Jan 13, 2026 at 20:28:27 +0100 Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> 
> >On Tue, Jan 13, 2026 at 09:12:36PM +0200, Yedaya Katsman via B4 Relay wrote: 
> > From: Yedaya Katsman <yedaya.ka@gmail.com> 
> > 
> > The driver also works with FT3518, which supports up to 10 touch points. 
> >  Add compatible data for it. 
> > 
> > Co-developed-by: SzczurekYT <szczurek@szczurek.yt> 
> > Signed-off-by: SzczurekYT <szczurek@szczurek.yt> 
>  
> >This doesn't look like a name.
> 
> Hello
> Yes, it isn't a real name.
> Yedaya Katsman is upstreaming those patches by me, under my permission,
> and I forgot to tell him my name, so he took it from gitlab, which is just a nickname.
> All of "SzczurekYT <szczurek@szczurek.yt>" should be replaced with "Kamil Gołda <kamil.golda@protonmail.com>",
> this is my name and the e-mail I would like this to be under.
> Excuse me for the chaos.

No worries, thank you for providing necessary information.

>  
> > Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com> 
> > --- 
> >  drivers/input/touchscreen/edt-ft5x06.c | 6 ++++++ 
> >  1 file changed, 6 insertions(+) 
> > 
>  
> >-- 
> >With best wishes 
> >Dmitry
> 
> Regards
> Kamil Gołda
> 
> 

-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS
From: Ihor Solodrai @ 2026-01-13 23:48 UTC (permalink / raw)
  To: Eduard Zingerman, Alexei Starovoitov, Andrii Nakryiko,
	Daniel Borkmann, Martin KaFai Lau
  Cc: Mykyta Yatsenko, Tejun Heo, Alan Maguire, Benjamin Tissoires,
	Jiri Kosina, bpf, linux-kernel, linux-input, sched-ext
In-Reply-To: <93ecdc25-aa5e-485b-8ff4-a9db3b585861@linux.dev>

On 1/13/26 2:03 PM, Ihor Solodrai wrote:
> On 1/13/26 12:39 PM, Eduard Zingerman wrote:
>> On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote:
>>> 
>>
>> [...]
>>
>>> @@ -14303,6 +14358,17 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>>>  	for (i = 0; i < nargs; i++) {
>>>  		u32 regno = i + 1;
>>>  
>>> +		/*
>>> +		 * Implicit kfunc arguments are set after main verification pass.
>>> +		 * For correct tracking of zero-extensions we have to reset subreg_def for such
>>> +		 * args. Otherwise mark_btf_func_reg_size() will be inspecting subreg_def of regs
>>> +		 * from an earlier (irrelevant) point in the program, which may lead to an error
>>> +		 * in opt_subreg_zext_lo32_rnd_hi32().
>>> +		 */
>>> +		if (unlikely(KF_IMPLICIT_ARGS & meta.kfunc_flags
>>> +				&& is_kfunc_arg_implicit(desc_btf, &args[i])))
>>> +			regs[regno].subreg_def = DEF_NOT_SUBREG;
>>> +
>>
>> Did you try doing this in `mark_reg_not_init()`?
>> This function is called for R1-R5 some time prior this hunk.
> 
>> Did you try doing this in `mark_reg_not_init()`?
> 
> Just tried, it doesn't work because REG0 is considered a caller saved
> register, and so it breaks the zext tracking:
> 
>         #define CALLER_SAVED_REGS 6
>         static const int caller_saved[CALLER_SAVED_REGS] = {
> 	     BPF_REG_0, BPF_REG_1, BPF_REG_2, BPF_REG_3, BPF_REG_4, BPF_REG_5
>         };
> 
>         [...]
> 
> 	for (i = 0; i < CALLER_SAVED_REGS; i++)
> 		mark_reg_not_init(env, regs, caller_saved[i]);
> 
> CI run for the diff below (on top of this series):
> https://github.com/kernel-patches/bpf/actions/runs/20972520708
> 
>
> [...]
> 
> ---
> 
> Resetting all reg args appears to be working however (see below).
> CI: https://github.com/kernel-patches/bpf/actions/runs/20973490221
> 

A follow up after a chat with Eduard.

This change in check_kfunc_call() appears to be working:

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 092003cc7841..ff743335111c 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -13958,8 +13958,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
                regs = branch->frame[branch->curframe]->regs;
 
                /* Clear r0-r5 registers in forked state */
-               for (i = 0; i < CALLER_SAVED_REGS; i++)
-                       mark_reg_not_init(env, regs, caller_saved[i]);
+               for (i = 0; i < CALLER_SAVED_REGS; i++) {
+                       u32 regno = caller_saved[i];
+                       mark_reg_not_init(env, regs, regno);
+                       regs[regno].subreg_def = DEF_NOT_SUBREG;
+               }
 
                mark_reg_unknown(env, regs, BPF_REG_0);
                err = __mark_reg_s32_range(env, regs, BPF_REG_0, -MAX_ERRNO, -1);

https://github.com/kernel-patches/bpf/actions/runs/20975419422

Apparently, doing .subreg_def = DEF_NOT_SUBREG in mark_reg_not_init()
breaks zero-extension tracking somewhere else.  But this is not
directly relevant to the series.

Eduard, Alexei, any concerns with this diff? Should I send a separate
patch?


>  [...]


^ permalink raw reply related

* Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS
From: Ihor Solodrai @ 2026-01-14  0:03 UTC (permalink / raw)
  To: Eduard Zingerman, Alexei Starovoitov, Andrii Nakryiko,
	Daniel Borkmann, Martin KaFai Lau
  Cc: Mykyta Yatsenko, Tejun Heo, Alan Maguire, Benjamin Tissoires,
	Jiri Kosina, bpf, linux-kernel, linux-input, sched-ext
In-Reply-To: <18d9b15319bf8d71a3cd5b08239529505714dc96.camel@gmail.com>

On 1/13/26 1:59 PM, Eduard Zingerman wrote:
> On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote:
> 
> [...]
> 
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -3271,6 +3271,38 @@ static struct btf *find_kfunc_desc_btf(struct bpf_verifier_env *env, s16 offset)
>>  	return btf_vmlinux ?: ERR_PTR(-ENOENT);
>>  }
>>  
>> +#define KF_IMPL_SUFFIX "_impl"
>> +
>> +static const struct btf_type *find_kfunc_impl_proto(struct bpf_verifier_env *env,
>> +						    struct btf *btf,
>> +						    const char *func_name)
>> +{
>> +	char impl_name[KSYM_SYMBOL_LEN];
> 
> Oh, as we discussed already, this should use env->tmp_str_buf.

The env->tmp_str_buf size is smaller:

	#define TMP_STR_BUF_LEN 320

*And* there is already a local char buffer of size KSYM_SYMBOL_LEN
already in use in verifier.c:

	int bpf_check_attach_target(...) {
		bool prog_extension = prog->type == BPF_PROG_TYPE_EXT;
		bool prog_tracing = prog->type == BPF_PROG_TYPE_TRACING;
		char trace_symbol[KSYM_SYMBOL_LEN];
	[...]

Since these are function names, the real limit is KSYM_SYMBOL_LEN,
right?

Sure >320 chars long kfunc name is unlikely, but technically possible.

> 
>> +	const struct btf_type *func;
>> +	s32 impl_id;
>> +	int len;
>> +
>> +	len = snprintf(impl_name, sizeof(impl_name), "%s%s", func_name, KF_IMPL_SUFFIX);
>> +	if (len < 0 || len >= sizeof(impl_name)) {
>> +		verbose(env, "function name %s%s is too long\n", func_name, KF_IMPL_SUFFIX);
>> +		return NULL;
>> +	}
> 
> [...]


^ permalink raw reply

* Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS
From: Alexei Starovoitov @ 2026-01-14  0:55 UTC (permalink / raw)
  To: Ihor Solodrai
  Cc: Eduard Zingerman, Alexei Starovoitov, Andrii Nakryiko,
	Daniel Borkmann, Martin KaFai Lau, Mykyta Yatsenko, Tejun Heo,
	Alan Maguire, Benjamin Tissoires, Jiri Kosina, bpf, LKML,
	open list:HID CORE LAYER, sched-ext
In-Reply-To: <c7e2a776-52f9-46ad-8422-3a9202bbd9f1@linux.dev>

On Tue, Jan 13, 2026 at 3:48 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> On 1/13/26 2:03 PM, Ihor Solodrai wrote:
> > On 1/13/26 12:39 PM, Eduard Zingerman wrote:
> >> On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote:
> >>>
> >>
> >> [...]
> >>
> >>> @@ -14303,6 +14358,17 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> >>>     for (i = 0; i < nargs; i++) {
> >>>             u32 regno = i + 1;
> >>>
> >>> +           /*
> >>> +            * Implicit kfunc arguments are set after main verification pass.
> >>> +            * For correct tracking of zero-extensions we have to reset subreg_def for such
> >>> +            * args. Otherwise mark_btf_func_reg_size() will be inspecting subreg_def of regs
> >>> +            * from an earlier (irrelevant) point in the program, which may lead to an error
> >>> +            * in opt_subreg_zext_lo32_rnd_hi32().
> >>> +            */
> >>> +           if (unlikely(KF_IMPLICIT_ARGS & meta.kfunc_flags
> >>> +                           && is_kfunc_arg_implicit(desc_btf, &args[i])))
> >>> +                   regs[regno].subreg_def = DEF_NOT_SUBREG;
> >>> +
> >>
> >> Did you try doing this in `mark_reg_not_init()`?
> >> This function is called for R1-R5 some time prior this hunk.
> >
> >> Did you try doing this in `mark_reg_not_init()`?
> >
> > Just tried, it doesn't work because REG0 is considered a caller saved
> > register, and so it breaks the zext tracking:
> >
> >         #define CALLER_SAVED_REGS 6
> >         static const int caller_saved[CALLER_SAVED_REGS] = {
> >            BPF_REG_0, BPF_REG_1, BPF_REG_2, BPF_REG_3, BPF_REG_4, BPF_REG_5
> >         };
> >
> >         [...]
> >
> >       for (i = 0; i < CALLER_SAVED_REGS; i++)
> >               mark_reg_not_init(env, regs, caller_saved[i]);
> >
> > CI run for the diff below (on top of this series):
> > https://github.com/kernel-patches/bpf/actions/runs/20972520708
> >
> >
> > [...]
> >
> > ---
> >
> > Resetting all reg args appears to be working however (see below).
> > CI: https://github.com/kernel-patches/bpf/actions/runs/20973490221
> >
>
> A follow up after a chat with Eduard.
>
> This change in check_kfunc_call() appears to be working:
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 092003cc7841..ff743335111c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -13958,8 +13958,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>                 regs = branch->frame[branch->curframe]->regs;
>
>                 /* Clear r0-r5 registers in forked state */
> -               for (i = 0; i < CALLER_SAVED_REGS; i++)
> -                       mark_reg_not_init(env, regs, caller_saved[i]);
> +               for (i = 0; i < CALLER_SAVED_REGS; i++) {
> +                       u32 regno = caller_saved[i];
> +                       mark_reg_not_init(env, regs, regno);
> +                       regs[regno].subreg_def = DEF_NOT_SUBREG;
> +               }
>
>                 mark_reg_unknown(env, regs, BPF_REG_0);
>                 err = __mark_reg_s32_range(env, regs, BPF_REG_0, -MAX_ERRNO, -1);
>
> https://github.com/kernel-patches/bpf/actions/runs/20975419422
>
> Apparently, doing .subreg_def = DEF_NOT_SUBREG in mark_reg_not_init()
> breaks zero-extension tracking somewhere else.  But this is not
> directly relevant to the series.
>
> Eduard, Alexei, any concerns with this diff? Should I send a separate
> patch?

This is odd. Clear it only for res_spin_lock() processing?!
Should be around lines 14149 instead?

First, need to investigate why clearing it in mark_reg_not_init()
breaks things.
That's what clear_caller_saved_regs() is doing already.
Maybe these two loops in check_kfunc_call() should be doing
clear_caller_saved_regs() instead...
Needs proper investigation.

^ permalink raw reply

* Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS
From: Eduard Zingerman @ 2026-01-14  1:06 UTC (permalink / raw)
  To: Ihor Solodrai, Alexei Starovoitov, Andrii Nakryiko,
	Daniel Borkmann, Martin KaFai Lau
  Cc: Mykyta Yatsenko, Tejun Heo, Alan Maguire, Benjamin Tissoires,
	Jiri Kosina, bpf, linux-kernel, linux-input, sched-ext
In-Reply-To: <aff8eeed-414c-49b3-b7f0-c8c328ed5199@linux.dev>

On Tue, 2026-01-13 at 16:03 -0800, Ihor Solodrai wrote:
> On 1/13/26 1:59 PM, Eduard Zingerman wrote:
> > On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote:
> > 
> > [...]
> > 
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -3271,6 +3271,38 @@ static struct btf *find_kfunc_desc_btf(struct bpf_verifier_env *env, s16 offset)
> > >  	return btf_vmlinux ?: ERR_PTR(-ENOENT);
> > >  }
> > >  
> > > +#define KF_IMPL_SUFFIX "_impl"
> > > +
> > > +static const struct btf_type *find_kfunc_impl_proto(struct bpf_verifier_env *env,
> > > +						    struct btf *btf,
> > > +						    const char *func_name)
> > > +{
> > > +	char impl_name[KSYM_SYMBOL_LEN];
> > 
> > Oh, as we discussed already, this should use env->tmp_str_buf.
> 
> The env->tmp_str_buf size is smaller:
> 
> 	#define TMP_STR_BUF_LEN 320
> 
> *And* there is already a local char buffer of size KSYM_SYMBOL_LEN
> already in use in verifier.c:
> 
> 	int bpf_check_attach_target(...) {
> 		bool prog_extension = prog->type == BPF_PROG_TYPE_EXT;
> 		bool prog_tracing = prog->type == BPF_PROG_TYPE_TRACING;
> 		char trace_symbol[KSYM_SYMBOL_LEN];
> 	[...]
> 
> Since these are function names, the real limit is KSYM_SYMBOL_LEN,
> right?
> 
> Sure >320 chars long kfunc name is unlikely, but technically possible.

320 is good enough, you'll be able to cover this:

kfunc_trace_long_descriptive_kernel_symbol_for_tracing_scheduler_memory_io_and_interrupt_paths_during_runtime_analysis_of_latency_throughput_and_resource_contention_on_large_scale_multiprocessor_linux_systems_using_bpf_and_kprobes_without_requiring_kernel_recompilation_or_system_restart_for_production_use_cases_v2x

But not this:

kfunc_trace_kernel_scheduler_and_memory_management_path_for_observing_task_lifecycle_events_context_switches_page_fault_handling_and_io_wait_states_while_debugging_performance_regressions_on_large_multiprocessor_systems_running_preemptible_linux_kernels_with_bpf_tracing_and_dynamic_instrumentation_enabled_for_deep_visibility_into_runtime_behavior_and_latency_sensitive_code_paths_without_recompilation.

Should suffice, I think.

^ permalink raw reply

* Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS
From: Eduard Zingerman @ 2026-01-14  1:35 UTC (permalink / raw)
  To: Ihor Solodrai, Alexei Starovoitov, Andrii Nakryiko,
	Daniel Borkmann, Martin KaFai Lau
  Cc: Mykyta Yatsenko, Tejun Heo, Alan Maguire, Benjamin Tissoires,
	Jiri Kosina, bpf, linux-kernel, linux-input, sched-ext
In-Reply-To: <c7e2a776-52f9-46ad-8422-3a9202bbd9f1@linux.dev>

On Tue, 2026-01-13 at 15:48 -0800, Ihor Solodrai wrote:

[...]

> A follow up after a chat with Eduard.
> 
> This change in check_kfunc_call() appears to be working:
> 
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 092003cc7841..ff743335111c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -13958,8 +13958,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>                 regs = branch->frame[branch->curframe]->regs;
>  
>                 /* Clear r0-r5 registers in forked state */
> -               for (i = 0; i < CALLER_SAVED_REGS; i++)
> -                       mark_reg_not_init(env, regs, caller_saved[i]);
> +               for (i = 0; i < CALLER_SAVED_REGS; i++) {
> +                       u32 regno = caller_saved[i];
> +                       mark_reg_not_init(env, regs, regno);
> +                       regs[regno].subreg_def = DEF_NOT_SUBREG;
> +               }
>  
>                 mark_reg_unknown(env, regs, BPF_REG_0);
>                 err = __mark_reg_s32_range(env, regs, BPF_REG_0, -MAX_ERRNO, -1);
> 
> https://github.com/kernel-patches/bpf/actions/runs/20975419422
> 
> Apparently, doing .subreg_def = DEF_NOT_SUBREG in mark_reg_not_init()
> breaks zero-extension tracking somewhere else.  But this is not
> directly relevant to the series.
> 
> Eduard, Alexei, any concerns with this diff? Should I send a separate
> patch?

Imo this is acceptable to land this series but follow up investigation
is definitely needed. Either there is a bug and mark_reg_not_init() is
called in a context where upper 32-bits are still significant, or zero
extension related code can be improved to avoid patching in some cases.

Additional context for other reviewers, Ihor did two experiments:
- added '.subreg_def = DEF_NOT_SUBREG' to mark_reg_not_init(),
  which resulted in selftests failure;
- added '.subreg_def = DEF_NOT_SUBREG' as above, which worked fine.

Meaning that code in check_kfunc_call() is not a culprit.

^ permalink raw reply

* Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS
From: Ihor Solodrai @ 2026-01-14  3:57 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Eduard Zingerman, Alexei Starovoitov, Andrii Nakryiko,
	Daniel Borkmann, Martin KaFai Lau, Mykyta Yatsenko, Tejun Heo,
	Alan Maguire, Benjamin Tissoires, Jiri Kosina, bpf, LKML,
	open list:HID CORE LAYER, sched-ext
In-Reply-To: <CAADnVQLizVA16Q-wVMd5-00YSPZtyuu7Exn9B8c_r1rn2cztkg@mail.gmail.com>



On 1/13/26 4:55 PM, Alexei Starovoitov wrote:
> On Tue, Jan 13, 2026 at 3:48 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> On 1/13/26 2:03 PM, Ihor Solodrai wrote:
>>> On 1/13/26 12:39 PM, Eduard Zingerman wrote:
>>>> On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote:
>>>>>
>>>>
>>>> [...]
>>>>
>>>>> @@ -14303,6 +14358,17 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>>>>>     for (i = 0; i < nargs; i++) {
>>>>>             u32 regno = i + 1;
>>>>>
>>>>> +           /*
>>>>> +            * Implicit kfunc arguments are set after main verification pass.
>>>>> +            * For correct tracking of zero-extensions we have to reset subreg_def for such
>>>>> +            * args. Otherwise mark_btf_func_reg_size() will be inspecting subreg_def of regs
>>>>> +            * from an earlier (irrelevant) point in the program, which may lead to an error
>>>>> +            * in opt_subreg_zext_lo32_rnd_hi32().
>>>>> +            */
>>>>> +           if (unlikely(KF_IMPLICIT_ARGS & meta.kfunc_flags
>>>>> +                           && is_kfunc_arg_implicit(desc_btf, &args[i])))
>>>>> +                   regs[regno].subreg_def = DEF_NOT_SUBREG;
>>>>> +
>>>>
>>>> Did you try doing this in `mark_reg_not_init()`?
>>>> This function is called for R1-R5 some time prior this hunk.
>>>
>>>> Did you try doing this in `mark_reg_not_init()`?
>>>
>>> Just tried, it doesn't work because REG0 is considered a caller saved
>>> register, and so it breaks the zext tracking:
>>>
>>>         #define CALLER_SAVED_REGS 6
>>>         static const int caller_saved[CALLER_SAVED_REGS] = {
>>>            BPF_REG_0, BPF_REG_1, BPF_REG_2, BPF_REG_3, BPF_REG_4, BPF_REG_5
>>>         };
>>>
>>>         [...]
>>>
>>>       for (i = 0; i < CALLER_SAVED_REGS; i++)
>>>               mark_reg_not_init(env, regs, caller_saved[i]);
>>>
>>> CI run for the diff below (on top of this series):
>>> https://github.com/kernel-patches/bpf/actions/runs/20972520708
>>>
>>>
>>> [...]
>>>
>>> ---
>>>
>>> Resetting all reg args appears to be working however (see below).
>>> CI: https://github.com/kernel-patches/bpf/actions/runs/20973490221
>>>
>>
>> A follow up after a chat with Eduard.
>>
>> This change in check_kfunc_call() appears to be working:
>>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 092003cc7841..ff743335111c 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -13958,8 +13958,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>>                 regs = branch->frame[branch->curframe]->regs;
>>
>>                 /* Clear r0-r5 registers in forked state */
>> -               for (i = 0; i < CALLER_SAVED_REGS; i++)
>> -                       mark_reg_not_init(env, regs, caller_saved[i]);
>> +               for (i = 0; i < CALLER_SAVED_REGS; i++) {
>> +                       u32 regno = caller_saved[i];
>> +                       mark_reg_not_init(env, regs, regno);
>> +                       regs[regno].subreg_def = DEF_NOT_SUBREG;
>> +               }
>>
>>                 mark_reg_unknown(env, regs, BPF_REG_0);
>>                 err = __mark_reg_s32_range(env, regs, BPF_REG_0, -MAX_ERRNO, -1);
>>
>> https://github.com/kernel-patches/bpf/actions/runs/20975419422
>>
>> Apparently, doing .subreg_def = DEF_NOT_SUBREG in mark_reg_not_init()
>> breaks zero-extension tracking somewhere else.  But this is not
>> directly relevant to the series.
>>
>> Eduard, Alexei, any concerns with this diff? Should I send a separate
>> patch?
> 
> This is odd. Clear it only for res_spin_lock() processing?!
> Should be around lines 14149 instead?

Yes. Sorry, this was a messed up local diff. The commits tested on CI
are correct though. I'll have this fix in v2, since it is necessary
for KF_IMPLICIT_ARGS to work.

I'll look into this problem more after implicit args land, unless
someone beats me to it.

> 
> First, need to investigate why clearing it in mark_reg_not_init()
> breaks things.
> That's what clear_caller_saved_regs() is doing already.
> Maybe these two loops in check_kfunc_call() should be doing
> clear_caller_saved_regs() instead...
> Needs proper investigation.


^ permalink raw reply

* Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS
From: Ihor Solodrai @ 2026-01-14  4:08 UTC (permalink / raw)
  To: Eduard Zingerman, Alexei Starovoitov, Andrii Nakryiko,
	Daniel Borkmann, Martin KaFai Lau
  Cc: Mykyta Yatsenko, Tejun Heo, Alan Maguire, Benjamin Tissoires,
	Jiri Kosina, bpf, linux-kernel, linux-input, sched-ext
In-Reply-To: <5027595d4eff50d423af8ebc5fecd6a0f7229d60.camel@gmail.com>



On 1/13/26 5:06 PM, Eduard Zingerman wrote:
> On Tue, 2026-01-13 at 16:03 -0800, Ihor Solodrai wrote:
>> On 1/13/26 1:59 PM, Eduard Zingerman wrote:
>>> On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote:
>>>
>>> [...]
>>>
>>>> --- a/kernel/bpf/verifier.c
>>>> +++ b/kernel/bpf/verifier.c
>>>> @@ -3271,6 +3271,38 @@ static struct btf *find_kfunc_desc_btf(struct bpf_verifier_env *env, s16 offset)
>>>>  	return btf_vmlinux ?: ERR_PTR(-ENOENT);
>>>>  }
>>>>  
>>>> +#define KF_IMPL_SUFFIX "_impl"
>>>> +
>>>> +static const struct btf_type *find_kfunc_impl_proto(struct bpf_verifier_env *env,
>>>> +						    struct btf *btf,
>>>> +						    const char *func_name)
>>>> +{
>>>> +	char impl_name[KSYM_SYMBOL_LEN];
>>>
>>> Oh, as we discussed already, this should use env->tmp_str_buf.
>>
>> The env->tmp_str_buf size is smaller:
>>
>> 	#define TMP_STR_BUF_LEN 320
>>
>> *And* there is already a local char buffer of size KSYM_SYMBOL_LEN
>> already in use in verifier.c:
>>
>> 	int bpf_check_attach_target(...) {
>> 		bool prog_extension = prog->type == BPF_PROG_TYPE_EXT;
>> 		bool prog_tracing = prog->type == BPF_PROG_TYPE_TRACING;
>> 		char trace_symbol[KSYM_SYMBOL_LEN];
>> 	[...]
>>
>> Since these are function names, the real limit is KSYM_SYMBOL_LEN,
>> right?
>>
>> Sure >320 chars long kfunc name is unlikely, but technically possible.
> 
> 320 is good enough, you'll be able to cover this:
> 
> kfunc_trace_long_descriptive_kernel_symbol_for_tracing_scheduler_memory_io_and_interrupt_paths_during_runtime_analysis_of_latency_throughput_and_resource_contention_on_large_scale_multiprocessor_linux_systems_using_bpf_and_kprobes_without_requiring_kernel_recompilation_or_system_restart_for_production_use_cases_v2x
> 
> But not this:
> 
> kfunc_trace_kernel_scheduler_and_memory_management_path_for_observing_task_lifecycle_events_context_switches_page_fault_handling_and_io_wait_states_while_debugging_performance_regressions_on_large_multiprocessor_systems_running_preemptible_linux_kernels_with_bpf_tracing_and_dynamic_instrumentation_enabled_for_deep_visibility_into_runtime_behavior_and_latency_sensitive_code_paths_without_recompilation.
> 
> Should suffice, I think.

I will laugh for at least 321 seconds when the size of this buffer
will have to be increased, and will make sure you hear it :)

They thought 640K of memory is enough, you know.


^ permalink raw reply

* Re: [PATCH] Input: adp5589: remove a leftover header file
From: Dmitry Torokhov @ 2026-01-14  6:43 UTC (permalink / raw)
  To: Vladimir Zapolskiy
  Cc: Nuno Sá, Laurent Pinchart, Signed-off-by : Lee Jones,
	linux-input
In-Reply-To: <20260113151140.3843753-1-vz@mleia.com>

On Tue, Jan 13, 2026 at 05:11:40PM +0200, Vladimir Zapolskiy wrote:
> In commit 3bdbd0858df6 ("Input: adp5589: remove the driver") the last user
> of include/linux/input/adp5589.h was removed along with the whole driver,
> thus the header file can be also removed.
> 
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>

Applied, thank you.

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH v4 3/6] dt-bindings: input: google,goldfish-events-keypad: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-14  7:31 UTC (permalink / raw)
  To: Kuan-Wei Chiu
  Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
	krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
	lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
	linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-4-visitorckw@gmail.com>

On Tue, Jan 13, 2026 at 09:25:59AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Events Keypad binding to DT schema format.
> Move the file to the input directory to match the subsystem.
> Update the example node name to 'keypad' to comply with generic node
> naming standards.
> 
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v4 4/6] dt-bindings: power: supply: google,goldfish-battery: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-14  7:31 UTC (permalink / raw)
  To: Kuan-Wei Chiu
  Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
	krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
	lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
	linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-5-visitorckw@gmail.com>

On Tue, Jan 13, 2026 at 09:26:00AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Battery binding to DT schema format.
> Move the file to the power/supply directory to match the subsystem.
> Update the example node name to 'battery' to comply with generic node
> naming standards.
> 
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v4 5/6] dt-bindings: sound: google,goldfish-audio: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-14  7:31 UTC (permalink / raw)
  To: Kuan-Wei Chiu
  Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
	krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
	lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
	linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-6-visitorckw@gmail.com>

On Tue, Jan 13, 2026 at 09:26:01AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Audio binding to DT schema format.
> Move the file to the sound directory to match the subsystem.
> Update the example node name to 'sound' to comply with generic node
> naming standards.
> 
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
>  .../devicetree/bindings/goldfish/audio.txt    | 17 ---------
>  .../bindings/sound/google,goldfish-audio.yaml | 38 +++++++++++++++++++
>  2 files changed, 38 insertions(+), 17 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/goldfish/audio.txt
>  create mode 100644 Documentation/devicetree/bindings/sound/google,goldfish-audio.yaml

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH] input: byd: use %*ph for Z packet dump
From: Andy Shevchenko @ 2026-01-14  7:37 UTC (permalink / raw)
  To: Vivek BalachandharTN
  Cc: Dmitry Torokhov, linux-input, linux-kernel, Thomas Gleixner,
	Ingo Molnar
In-Reply-To: <20251202033120.2264474-1-vivek.balachandhar@gmail.com>

On Tue, Dec 02, 2025 at 03:31:20AM +0000, Vivek BalachandharTN wrote:
> Replace the hand-rolled %02x formatting of the Z packet warning in the
> BYD driver with the %*ph format specifier. %*ph is the preferred helper
> for printing a buffer in hexadecimal and makes the logging clearer and
> more consistent.

You probably took one of the oldest examples of such a conversion done in
the input subsystem.

> +			     "Unrecognized Z: pkt = %*ph\n",
> +			     4, psmouse->packet);

The (not-so-critical) problem here is the stack consumption and additional work
for the printf() to parse '*'. To optimise that, static field widths may be
embedded in the format strings

			     "Unrecognized Z: pkt = %4ph\n",
			     psmouse->packet);

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply

* Re: [PATCH] input: byd: use %*ph for Z packet dump
From: Vivek BalachandharTN @ 2026-01-14  8:49 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Dmitry Torokhov, linux-input, linux-kernel, Thomas Gleixner,
	Ingo Molnar
In-Reply-To: <aWdHsalXcjFKmDDK@black.igk.intel.com>

Thanks Andy — good point. Packet length is fixed here, so |%4ph| is 
better. I’ll follow this pattern in future patches (and can send a small 
follow-up to adjust this one if desired).


Best, Vivek

On 2026-01-14 3:37 a.m., Andy Shevchenko wrote:
> On Tue, Dec 02, 2025 at 03:31:20AM +0000, Vivek BalachandharTN wrote:
>> Replace the hand-rolled %02x formatting of the Z packet warning in the
>> BYD driver with the %*ph format specifier. %*ph is the preferred helper
>> for printing a buffer in hexadecimal and makes the logging clearer and
>> more consistent.
> You probably took one of the oldest examples of such a conversion done in
> the input subsystem.
>
>> +			     "Unrecognized Z: pkt = %*ph\n",
>> +			     4, psmouse->packet);
> The (not-so-critical) problem here is the stack consumption and additional work
> for the printf() to parse '*'. To optimise that, static field widths may be
> embedded in the format strings
>
> 			     "Unrecognized Z: pkt = %4ph\n",
> 			     psmouse->packet);
>

^ permalink raw reply

* Re: [PATCH] input: byd: use %*ph for Z packet dump
From: Andy Shevchenko @ 2026-01-14  8:53 UTC (permalink / raw)
  To: Vivek BalachandharTN
  Cc: Dmitry Torokhov, linux-input, linux-kernel, Thomas Gleixner,
	Ingo Molnar
In-Reply-To: <f846343a-49ac-443f-bef3-04e3e08ee20c@gmail.com>

On Wed, Jan 14, 2026 at 04:49:32AM -0400, Vivek BalachandharTN wrote:
> Thanks Andy — good point. Packet length is fixed here, so |%4ph| is better.
> I’ll follow this pattern in future patches (and can send a small follow-up
> to adjust this one if desired).

You can find all such places in input subsystem and convert them all
(1 patch per subfolder probably, 1 for keyboard/*, 1 for mouse/*, ...).

P.S. And do not top-post!

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply

* Re: [PATCH 1/3] dt-bindings: input: touchscreen: edt-ft5x06: Add FocalTech FT3518
From: Krzysztof Kozlowski @ 2026-01-14  9:22 UTC (permalink / raw)
  To: Yedaya Katsman
  Cc: SzczurekYT, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-input,
	devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260113-touchscreen-patches-v1-1-a10957f32dd8@gmail.com>

On Tue, Jan 13, 2026 at 09:12:35PM +0200, Yedaya Katsman wrote:
> Document FocalTech FT3518 support by adding the compatible.
> 
> Co-developed-by: SzczurekYT <szczurek@szczurek.yt>
> Signed-off-by: SzczurekYT <szczurek@szczurek.yt>

You need to use real names or real known identity.

See submitting patches.

> Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>

Best regards,
Krzysztof


^ permalink raw reply

* [PATCH v2 3/3] arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Add Focaltech FT3518 touchscreen
From: Yedaya Katsman via B4 Relay @ 2026-01-14  9:31 UTC (permalink / raw)
  To: SzczurekYT, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Bjorn Andersson, Konrad Dybcio
  Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
	Yedaya Katsman, Kamil Gołda
In-Reply-To: <20260114-touchscreen-patches-v2-0-4215f94c8aba@gmail.com>

From: Yedaya Katsman <yedaya.ka@gmail.com>

Add device tree node for the Focaltech FT3518 touchscreen on
Xiaomi Mi A3 (laurel-sprout).

Enable qupv3_id_0 and i2c2 bus that the touchscreen is on.

Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
---
 .../boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts  | 34 ++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
index 994fb0412fcbdf5466f87a325c48b697a37b514b..97feed708d3b6483eab72cfb0ae39be6f5ae3a11 100644
--- a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
+++ b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
@@ -119,6 +119,18 @@ active-config0 {
 			};
 		};
 	};
+
+	ts_vdd_supply: ts-vdd-supply {
+		compatible = "regulator-fixed";
+		regulator-name = "ts_vdd_supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 83 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		startup-delay-us = <70000>;
+	};
 };
 
 &hsusb_phy1 {
@@ -411,3 +423,25 @@ &usb3 {
 &usb3_dwc3 {
 	extcon = <&extcon_usb>;
 };
+
+&qupv3_id_0 {
+	status = "okay";
+};
+
+&i2c2 {
+	status = "okay";
+
+	touchscreen@38 {
+		compatible = "focaltech,ft3518";
+		reg = <0x38>;
+		interrupt-parent = <&tlmm>;
+		interrupts = <88 IRQ_TYPE_EDGE_FALLING>;
+
+		vcc-supply = <&ts_vdd_supply>;
+
+		reset-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
+
+		touchscreen-size-x = <720>;
+		touchscreen-size-y = <1560>;
+	};
+};

-- 
2.52.0



^ permalink raw reply related

* [PATCH v2 1/3] dt-bindings: input: touchscreen: edt-ft5x06: Add FocalTech FT3518
From: Yedaya Katsman via B4 Relay @ 2026-01-14  9:31 UTC (permalink / raw)
  To: SzczurekYT, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Bjorn Andersson, Konrad Dybcio
  Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
	Yedaya Katsman, Kamil Gołda
In-Reply-To: <20260114-touchscreen-patches-v2-0-4215f94c8aba@gmail.com>

From: Yedaya Katsman <yedaya.ka@gmail.com>

Document FocalTech FT3518 support by adding the compatible.

Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
---
 Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
index 7d3edb58f72d84ed19fb87fdd136c97f855aba00..6f90522de8c0afbe2d9d1e04578316350f66ec58 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
@@ -39,6 +39,7 @@ properties:
       - edt,edt-ft5406
       - edt,edt-ft5506
       - evervision,ev-ft5726
+      - focaltech,ft3518
       - focaltech,ft5426
       - focaltech,ft5452
       - focaltech,ft6236

-- 
2.52.0



^ permalink raw reply related

* [PATCH v2 0/3] Support FT3518 touchscreen in xiaomi-laurel
From: Yedaya Katsman via B4 Relay @ 2026-01-14  9:31 UTC (permalink / raw)
  To: SzczurekYT, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Bjorn Andersson, Konrad Dybcio
  Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
	Yedaya Katsman, Kamil Gołda

Adds support for the touchscreen in the Xiaomi Mi A3 (xiaomi-laurel)
 smartphone, FocalTech FT3518

Original tree was here:
 Link: https://gitlab.postmarketos.org/SzczurekYT/linux/-/commits/laurel

Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
---
Changes in v2:
- Fixed name and email in signoffs
- Link to v1: https://lore.kernel.org/r/20260113-touchscreen-patches-v1-0-a10957f32dd8@gmail.com

---
Yedaya Katsman (3):
      dt-bindings: input: touchscreen: edt-ft5x06: Add FocalTech FT3518
      drivers: input: touchscreen: edt-ft5x06: Add FocalTech FT3518
      arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Add Focaltech FT3518 touchscreen

 .../bindings/input/touchscreen/edt-ft5x06.yaml     |  1 +
 .../boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts  | 34 ++++++++++++++++++++++
 drivers/input/touchscreen/edt-ft5x06.c             |  6 ++++
 3 files changed, 41 insertions(+)
---
base-commit: b71e635feefc852405b14620a7fc58c4c80c0f73
change-id: 20260113-touchscreen-patches-beb2526bd5fb

Best regards,
-- 
Yedaya Katsman <yedaya.ka@gmail.com>



^ permalink raw reply

* [PATCH v2 2/3] drivers: input: touchscreen: edt-ft5x06: Add FocalTech FT3518
From: Yedaya Katsman via B4 Relay @ 2026-01-14  9:31 UTC (permalink / raw)
  To: SzczurekYT, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Bjorn Andersson, Konrad Dybcio
  Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
	Yedaya Katsman, Kamil Gołda
In-Reply-To: <20260114-touchscreen-patches-v2-0-4215f94c8aba@gmail.com>

From: Yedaya Katsman <yedaya.ka@gmail.com>

The driver also works with FT3518, which supports up to 10 touch points.
 Add compatible data for it.

Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
---
 drivers/input/touchscreen/edt-ft5x06.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index bf498bd4dea9651ac939fe137b1c0f05e8557962..d0ab644be0069b5ab29ed037fa090a4279870193 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1475,6 +1475,10 @@ static const struct edt_i2c_chip_data edt_ft5x06_data = {
 	.max_support_points = 5,
 };
 
+static const struct edt_i2c_chip_data edt_ft3518_data = {
+	.max_support_points = 10,
+};
+
 static const struct edt_i2c_chip_data edt_ft5452_data = {
 	.max_support_points = 5,
 };
@@ -1503,6 +1507,7 @@ static const struct i2c_device_id edt_ft5x06_ts_id[] = {
 	{ .name = "edt-ft5x06", .driver_data = (long)&edt_ft5x06_data },
 	{ .name = "edt-ft5506", .driver_data = (long)&edt_ft5506_data },
 	{ .name = "ev-ft5726", .driver_data = (long)&edt_ft5506_data },
+	{ .name = "ft3518", .driver_data = (long)&edt_ft3518_data },
 	{ .name = "ft5452", .driver_data = (long)&edt_ft5452_data },
 	/* Note no edt- prefix for compatibility with the ft6236.c driver */
 	{ .name = "ft6236", .driver_data = (long)&edt_ft6236_data },
@@ -1519,6 +1524,7 @@ static const struct of_device_id edt_ft5x06_of_match[] = {
 	{ .compatible = "edt,edt-ft5406", .data = &edt_ft5x06_data },
 	{ .compatible = "edt,edt-ft5506", .data = &edt_ft5506_data },
 	{ .compatible = "evervision,ev-ft5726", .data = &edt_ft5506_data },
+	{ .compatible = "focaltech,ft3518", .data = &edt_ft3518_data },
 	{ .compatible = "focaltech,ft5426", .data = &edt_ft5506_data },
 	{ .compatible = "focaltech,ft5452", .data = &edt_ft5452_data },
 	/* Note focaltech vendor prefix for compatibility with ft6236.c */

-- 
2.52.0



^ permalink raw reply related

* Re: [PATCH v2 3/3] arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Add Focaltech FT3518 touchscreen
From: Konrad Dybcio @ 2026-01-14  9:36 UTC (permalink / raw)
  To: yedaya.ka, SzczurekYT, Dmitry Torokhov, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
  Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
	Kamil Gołda
In-Reply-To: <20260114-touchscreen-patches-v2-3-4215f94c8aba@gmail.com>

On 1/14/26 10:31 AM, Yedaya Katsman via B4 Relay wrote:
> From: Yedaya Katsman <yedaya.ka@gmail.com>
> 
> Add device tree node for the Focaltech FT3518 touchscreen on
> Xiaomi Mi A3 (laurel-sprout).
> 
> Enable qupv3_id_0 and i2c2 bus that the touchscreen is on.
> 
> Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com>
> Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com>
> Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
> ---
>  .../boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts  | 34 ++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
> index 994fb0412fcbdf5466f87a325c48b697a37b514b..97feed708d3b6483eab72cfb0ae39be6f5ae3a11 100644
> --- a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
> @@ -119,6 +119,18 @@ active-config0 {
>  			};
>  		};
>  	};
> +
> +	ts_vdd_supply: ts-vdd-supply {
> +		compatible = "regulator-fixed";
> +		regulator-name = "ts_vdd_supply";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +
> +		gpio = <&tlmm 83 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +
> +		startup-delay-us = <70000>;
> +	};
>  };
>  
>  &hsusb_phy1 {
> @@ -411,3 +423,25 @@ &usb3 {
>  &usb3_dwc3 {
>  	extcon = <&extcon_usb>;
>  };
> +
> +&qupv3_id_0 {
> +	status = "okay";
> +};
> +
> +&i2c2 {

Please sort the label references alphabetically

> +	status = "okay";
> +
> +	touchscreen@38 {
> +		compatible = "focaltech,ft3518";
> +		reg = <0x38>;
> +		interrupt-parent = <&tlmm>;
> +		interrupts = <88 IRQ_TYPE_EDGE_FALLING>;

interrupts-extended = <&tlmm 88 IRQ_TYPE_EDGE_FALLING>;
> +
> +		vcc-supply = <&ts_vdd_supply>;
> +
> +		reset-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;

You reference gpio83 (vdd en), 88 (interrupt) and 87 (reset), please add
a configuration for them under the TLMM node to ensure they're always in
a predictable state

You can probably find it in the downstream kernel, otherwise boot up a
downstream build and check /sys/kernel/debug/gpios

Konrad

^ permalink raw reply

* Re: [PATCH 2/2] Input: ili210x - add support for polling mode
From: Geert Uytterhoeven @ 2026-01-14  9:37 UTC (permalink / raw)
  To: Frank Li
  Cc: Marek Vasut, linux-input, Conor Dooley, Dmitry Torokhov,
	Job Noorman, Krzysztof Kozlowski, Rob Herring, devicetree,
	linux-kernel, linux-renesas-soc
In-Reply-To: <aWZ1pG5RRWlDSCwC@lizhi-Precision-Tower-5810>

Hi Frank,

On Tue, 13 Jan 2026 at 17:41, Frank Li <Frank.li@nxp.com> wrote:
> On Tue, Jan 13, 2026 at 12:44:57AM +0100, Marek Vasut wrote:
> > There are designs incorporating Ilitek ILI2xxx touch controller that
> > do not connect interrupt pin, for example Waveshare 13.3" DSI display.
> > To support such systems use polling mode for the input device when I2C
> > client does not have interrupt assigned to it.
> >
> > Factor out ili210x_firmware_update_noirq() to allow conditional scoped
> > guard around this code. The scoped guard has to be applied only in case
> > the IRQ line is connected, and not applied otherwise.
> >
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> > --- a/drivers/input/touchscreen/ili210x.c
> > +++ b/drivers/input/touchscreen/ili210x.c

> > @@ -1003,12 +1027,24 @@ static int ili210x_i2c_probe(struct i2c_client *client)
> >               return error;
> >       }
> >
> > -     error = devm_request_threaded_irq(dev, client->irq, NULL, ili210x_irq,
> > -                                       IRQF_ONESHOT, client->name, priv);
> > -     if (error) {
> > -             dev_err(dev, "Unable to request touchscreen IRQ, err: %d\n",
> > -                     error);
> > -             return error;
> > +     input_set_drvdata(input, priv);
> > +
> > +     if (client->irq) {
>
> 0 is validated irq number
>
> https://elixir.bootlin.com/linux/v6.19-rc4/source/drivers/base/platform.c#L284

Not anymore ;-)

https://elixir.bootlin.com/linux/v6.19-rc4/source/drivers/base/platform.c#L299

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH v2 2/3] drivers: input: touchscreen: edt-ft5x06: Add FocalTech FT3518
From: Dmitry Baryshkov @ 2026-01-14 13:02 UTC (permalink / raw)
  To: yedaya.ka
  Cc: SzczurekYT, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-input,
	devicetree, linux-kernel, linux-arm-msm, Kamil Gołda
In-Reply-To: <20260114-touchscreen-patches-v2-2-4215f94c8aba@gmail.com>

On Wed, Jan 14, 2026 at 11:31:07AM +0200, Yedaya Katsman via B4 Relay wrote:
> From: Yedaya Katsman <yedaya.ka@gmail.com>
> 
> The driver also works with FT3518, which supports up to 10 touch points.
>  Add compatible data for it.
> 
> Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com>
> Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com>
> Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
> ---
>  drivers/input/touchscreen/edt-ft5x06.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox