* Re: [PATCH 2/2] Input: ili210x - add support for polling mode
From: Frank Li @ 2026-01-14 15:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Marek Vasut, linux-input, Conor Dooley, Dmitry Torokhov,
Job Noorman, Krzysztof Kozlowski, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdXb3-EFy8WA9FTAqvyYHaF4nGch60bUQ6bbKu6Dzbh6YQ@mail.gmail.com>
On Wed, Jan 14, 2026 at 10:37:15AM +0100, Geert Uytterhoeven wrote:
> 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,
Thanks, negative error number on failure
It should be
if (client->irq > 0)
Frank
>
> 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
* Report
From: minecraftend @ 2026-01-14 14:10 UTC (permalink / raw)
To: linux-input@vger.kernel.org
psmouse serio1: synaptics: Your touchpad (PNP: LEN2043 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Add Focaltech FT3518 touchscreen
From: Dmitry Baryshkov @ 2026-01-14 13:04 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-3-4215f94c8aba@gmail.com>
On Wed, Jan 14, 2026 at 11:31:08AM +0200, 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 {
ts_vdd_supply: vreg-ts-vdd
OR
ts_vdd_supply: regulator-ts-vdd
(It migth require to be moved up in the file according to the sorting
rules).
> + 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>;
> + };
> };
>
--
With best wishes
Dmitry
^ 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
* 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 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
* [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
* [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 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 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
* 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
* 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] 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 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 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 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 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] 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 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 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: 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: 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: 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: 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: 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
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