* Re: [PATCH 3/5] dt-bindings: clock: samsung: Add fimd1 and vpll muxes
From: Krzysztof Kozlowski @ 2026-04-25 9:56 UTC (permalink / raw)
To: Lukas Timmermann
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Douglas Anderson, Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar,
Michael Turquette, Stephen Boyd, dri-devel, devicetree,
linux-kernel, linux-samsung-soc, linux-clk, linux-arm-kernel
In-Reply-To: <20260423-manta-display-v1-3-196f80c5673a@timmermann.space>
On Thu, Apr 23, 2026 at 11:14:39PM +0200, Lukas Timmermann wrote:
> Add two clocks necessary for the google-manta board
> display.
>
> Signed-off-by: Lukas Timmermann <linux@timmermann.space>
> ---
> include/dt-bindings/clock/exynos5250.h | 2 ++
> 1 file changed, 2 insertions(+)
>
If there is going to be any new version, better to split this and send
all SoC patches (clk + DTS) separately from DRM.
No need to resend just for that, I will pick up Samsung SoC things after
the merge window.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/5] ARM: dts: exynos: Add display support for exynos5250-manta
From: Krzysztof Kozlowski @ 2026-04-25 9:58 UTC (permalink / raw)
To: Lukas Timmermann
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Douglas Anderson, Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar,
Michael Turquette, Stephen Boyd, dri-devel, devicetree,
linux-kernel, linux-samsung-soc, linux-clk, linux-arm-kernel,
Alexandre Marquet
In-Reply-To: <20260423-manta-display-v1-5-196f80c5673a@timmermann.space>
On Thu, Apr 23, 2026 at 11:14:41PM +0200, Lukas Timmermann wrote:
> Adds the necessary entries for panel and backlight as
> well as the fimd controller.
>
> Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
> Signed-off-by: Lukas Timmermann <linux@timmermann.space>
> ---
> arch/arm/boot/dts/samsung/exynos5250-manta.dts | 99 ++++++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/arch/arm/boot/dts/samsung/exynos5250-manta.dts b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> index 76d3657eb22f..eb97a28ff4e3 100644
> --- a/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> +++ b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> @@ -25,6 +25,29 @@ aliases {
> mmc1 = &mmc_1; /* WiFi */
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 1000000 0>;
> +
> + brightness-levels = <2 255>; /* TODO */
> + num-interpolated-steps = <254>; /* TODO */
> + default-brightness-level = <102>; /* TODO */
> + post-pwm-on-delay-ms = <97>; /* TODO */
> +
> + power-supply = <&backlight_reg>;
> + enable-gpios = <&gpg0 5 GPIO_ACTIVE_HIGH>;
> +
> + pinctrl-0 = <&led_bl_reset &pwm0_out>;
> + pinctrl-names = "default";
> + };
> +
> + backlight_reg: regulator-backlight {
> + compatible = "regulator-fixed";
> + regulator-name = "APS_EN_18V";
> + pinctrl-0 = <&aps_en_18v>;
> + pinctrl-names = "default";
No enable GPIO? No voltage?
> + };
> +
> /* Voltage source unknown */
> bmp180_vdda_reg: regulator-bmp180-vdda {
> compatible = "regulator-fixed";
> @@ -105,6 +128,28 @@ multi-led {
> leds = <&status_red>, <&status_green>, <&status_blue>, <&status_white>;
> };
>
> + panel {
> + compatible = "samsung,ltl101dl02-002";
> +
> + backlight = <&backlight>;
> + power-supply = <&panel_reg>;
> + enable-gpios = <&gph1 7 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&lcd_en>;
> + pinctrl-names = "default";
> + no-hpd;
> +
> + port {
> + panel: endpoint {
> + remote-endpoint = <&dp_out>;
> + };
> + };
> + };
> +
> + panel_reg: regulator-panel {
> + compatible = "regulator-fixed";
> + regulator-name = "LCD_EN";
That's incomplete. You should have at least voltage.
> + };
> +
> pwrseq: mmc1-pwrseq {
> compatible = "mmc-pwrseq-simple";
>
> @@ -146,10 +191,36 @@ &cpu1 {
> cpu-supply = <&buck2_reg>;
> };
>
> +&dp {
> + status = "okay";
> +
> + samsung,color-space = <0>;
> + samsung,color-depth = <1>;
> + samsung,link-rate = <0x0a>;
> + samsung,lane-count = <4>;
> + samsung,dynamic-range = <0>;
> + samsung,ycbcr-coeff = <0>;
> +
> + ports {
> + port {
> + dp_out: endpoint {
> + remote-endpoint = <&panel>;
> + };
> + };
> + };
> +};
> +
> &ehci {
> status = "disabled";
> };
>
> +&fimd {
> + status = "okay";
> +
> + assigned-clocks = <&clock CLK_MOUT_FIMD1>, <&clock CLK_MOUT_VPLL>;
> + assigned-clock-parents = <&clock CLK_MOUT_VPLL>;
> +};
> +
> &i2c_1 {
> status = "okay";
>
> @@ -396,6 +467,12 @@ ldo25_reg: LDO25 {
> };
> };
>
> +&mali {
> + status = "okay";
> +
> + mali-supply = <&buck4_reg>;
> +};
> +
> &mixer {
> status = "okay";
> };
> @@ -489,6 +566,14 @@ wlan_irq: wlan-irq-pins {
> };
>
> &pinctrl_1 {
> + aps_en_18v: aps-en-18v-pins {
> + samsung,pins = "gph1-6";
> + samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>; /* TODO */
TODO why? IOW, what are you missing here? Was this tested?
TODO note can stay, but I would prefer to see short comment explaining
why.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme interrupts
From: Krzysztof Kozlowski @ 2026-04-25 10:00 UTC (permalink / raw)
To: Conor Dooley
Cc: Richard Zhu, robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach,
lpieralisi, kwilczynski, mani, s.hauer, kernel, festevam,
linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel
In-Reply-To: <20260424-sinless-unfiled-d1087a894da5@spud>
On Fri, Apr 24, 2026 at 06:06:18PM +0100, Conor Dooley wrote:
> On Fri, Apr 24, 2026 at 10:57:33AM +0800, Richard Zhu wrote:
> > Add optional 'intr', 'aer', and 'pme' interrupt entries to the i.MX6Q
> > PCIe binding to support PCIe event-based interrupts for general
> > controller events, Advanced Error Reporting, and Power Management Events
> > respectively.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
>
> This binding supports lots of devices. Do they all have these additional
> interrupts?
Yep. Commit msg says only i.MX6Q...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v14 05/28] drm/display: bridge_connector: Use HDMI color format for HDMI conns
From: Dmitry Baryshkov @ 2026-04-25 11:02 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260423-color-format-v14-5-449a419ccbd4@collabora.com>
On Thu, Apr 23, 2026 at 09:03:28PM +0200, Nicolas Frattaroli wrote:
> For bridge connectors which contain an HDMI bridge at some stage, the
> HDMI state helpers' format selection logic should be involved.
>
> Add an implementation for the drm_bridge_funcs color_format function,
> which translates from the HDMI state's output format to a connector
> format for bridge connectors involving an HDMI bridge, but return the
> connector state's color_format member unchanged otherwise.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
Thanks! I like how it ended up looking.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: David Laight @ 2026-04-25 11:02 UTC (permalink / raw)
To: Helge Deller
Cc: Ai Chao, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas, linux-fbdev, dri-devel, linux-kernel,
linux-arm-kernel, linux-geode, linux-parisc
In-Reply-To: <ccd01f97-d4b7-4bd0-92c1-adc3b1136cbc@gmx.de>
On Sat, 25 Apr 2026 10:08:08 +0200
Helge Deller <deller@gmx.de> wrote:
> Hello Ai,
...
> > - strcpy(ivideo->myid, "SiS 730");
> > + strscpy(ivideo->myid, "SiS 730");
>
> The compiler knows at build time the length of myid, and the "SIS 730" string.
> Using strscpy() has no benefit here either. Contrary, the code generated
> because of using strscpy() is probably even larger.
> Don't replace such code with strscpy().
Both should get converted to a memcpy().
If you increase the literal to be too long I'm pretty sure you'll
get a compiler warning/error from strcpy().
OTOH strscpy() is more likely to truncate the string (I'd need to
check).
So leaving it as strcpy() is fine - and possibly even better.
The header files might get changed to error strcpy() unless the compiler
knows the source string has a constant length and the destination is
big enough - but that hasn't been done yet.
David
^ permalink raw reply
* Re: [PATCH v14 06/28] drm/bridge: Act on the DRM color format property
From: Dmitry Baryshkov @ 2026-04-25 11:03 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260423-color-format-v14-6-449a419ccbd4@collabora.com>
On Thu, Apr 23, 2026 at 09:03:29PM +0200, Nicolas Frattaroli wrote:
> The new DRM color format property allows userspace to request a specific
> color format on a connector. In turn, this fills the connector state's
> color_format member to switch color formats.
>
> Make drm_bridges consider the color_format set in the connector state
> during the atomic bridge check. Call into the connector function to get
> the connector state's connector color format. For bridge connectors
> including an HDMI bridge, this will make use of whatever the HDMI
> implementation set as output formats, and AUTO will never be part of the
> rejection logic.
>
> Reject any output bus formats that do not correspond to the requested
> color format. DRM_CONNECTOR_COLOR_FORMAT_AUTO is always accepted as a
> matching color format for a bus format, meaning that non-HDMI bridge
> chains will end up picking the first bus format choice that works, as
> has already been the case previously.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_bridge.c | 64 +++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
Nice, generic and easily reusable for DP!
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v14 04/28] drm/connector: Let connectors have a say in their color format
From: Dmitry Baryshkov @ 2026-04-25 11:09 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260423-color-format-v14-4-449a419ccbd4@collabora.com>
On Thu, Apr 23, 2026 at 09:03:27PM +0200, Nicolas Frattaroli wrote:
> Add a function to get the connector color format from a connector state,
> and a new function pointer in drm_connector_funcs to allow connectors to
> override what connector color format it returns.
>
> This is useful for the bridge chain recursive bus format selection code,
> which does not wish to implement connector implementation specific
> checks like whether it involves HDMI.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_connector.c | 16 ++++++++++++++++
> include/drm/drm_connector.h | 12 ++++++++++++
> 2 files changed, 28 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/5] drm/panel-edp: Add support for Samsung LTL101DL02-002 panel
From: Dmitry Baryshkov @ 2026-04-25 11:23 UTC (permalink / raw)
To: Doug Anderson
Cc: Lukas Timmermann, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Sam Ravnborg, Krzysztof Kozlowski,
Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Michael Turquette,
Stephen Boyd, dri-devel, devicetree, linux-kernel,
linux-samsung-soc, linux-clk, linux-arm-kernel, Alexandre Marquet
In-Reply-To: <CAD=FV=VNvPtG_f1W942SKJfM4ptK8Wvd-nZs4geBCG3bO_A0BA@mail.gmail.com>
On Thu, Apr 23, 2026 at 02:49:53PM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Apr 23, 2026 at 2:15 PM Lukas Timmermann <linux@timmermann.space> wrote:
> >
> > From: Alexandre Marquet <tb@a-marquet.fr>
> >
> > Add a panel entry for the Samsung LTL101DL02-002 panel, as found in
> > Samsung Manta (Google Nexus 10).
> >
> > Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
> > Signed-off-by: Lukas Timmermann <linux@timmermann.space>
> > ---
> > drivers/gpu/drm/panel/panel-edp.c | 31 +++++++++++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
>
> Adding new panels like this is discouraged these days. Is there a
> reason you can't use the generic "edp-panel" compatible? I know that
> the exynos5 driver is pretty old, but a quick glance shows that it's
> based on the same analogix-dp core that "rockchip,analogix-dp" is, and
> that seems to have support for aux-bus...
I'd also prefer to NAK this change. If the driver can't cope with the
"edp-panel", the driver must be modified rather than pushing more and
more legacy panel compatibile strings.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 5/5] ARM: dts: exynos: Add display support for exynos5250-manta
From: Dmitry Baryshkov @ 2026-04-25 11:27 UTC (permalink / raw)
To: Lukas Timmermann
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Douglas Anderson, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Michael Turquette, Stephen Boyd,
dri-devel, devicetree, linux-kernel, linux-samsung-soc, linux-clk,
linux-arm-kernel, Alexandre Marquet
In-Reply-To: <20260423-manta-display-v1-5-196f80c5673a@timmermann.space>
On Thu, Apr 23, 2026 at 11:14:41PM +0200, Lukas Timmermann wrote:
> Adds the necessary entries for panel and backlight as
> well as the fimd controller.
>
> Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
> Signed-off-by: Lukas Timmermann <linux@timmermann.space>
> ---
> arch/arm/boot/dts/samsung/exynos5250-manta.dts | 99 ++++++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/arch/arm/boot/dts/samsung/exynos5250-manta.dts b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> index 76d3657eb22f..eb97a28ff4e3 100644
> --- a/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> +++ b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> @@ -25,6 +25,29 @@ aliases {
> mmc1 = &mmc_1; /* WiFi */
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 1000000 0>;
> +
> + brightness-levels = <2 255>; /* TODO */
> + num-interpolated-steps = <254>; /* TODO */
> + default-brightness-level = <102>; /* TODO */
> + post-pwm-on-delay-ms = <97>; /* TODO */
> +
> + power-supply = <&backlight_reg>;
> + enable-gpios = <&gpg0 5 GPIO_ACTIVE_HIGH>;
> +
> + pinctrl-0 = <&led_bl_reset &pwm0_out>;
> + pinctrl-names = "default";
> + };
> +
> + backlight_reg: regulator-backlight {
> + compatible = "regulator-fixed";
> + regulator-name = "APS_EN_18V";
> + pinctrl-0 = <&aps_en_18v>;
> + pinctrl-names = "default";
> + };
> +
> /* Voltage source unknown */
> bmp180_vdda_reg: regulator-bmp180-vdda {
> compatible = "regulator-fixed";
> @@ -105,6 +128,28 @@ multi-led {
> leds = <&status_red>, <&status_green>, <&status_blue>, <&status_white>;
> };
>
> + panel {
> + compatible = "samsung,ltl101dl02-002";
> +
> + backlight = <&backlight>;
> + power-supply = <&panel_reg>;
> + enable-gpios = <&gph1 7 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&lcd_en>;
> + pinctrl-names = "default";
> + no-hpd;
> +
> + port {
> + panel: endpoint {
> + remote-endpoint = <&dp_out>;
> + };
> + };
> + };
No, the panel is not just being attached to the device. I asumme it is
controlled over the AUX bus, so it shoud be a child device of the
AUX bus.
> +
> + panel_reg: regulator-panel {
> + compatible = "regulator-fixed";
> + regulator-name = "LCD_EN";
> + };
> +
> pwrseq: mmc1-pwrseq {
> compatible = "mmc-pwrseq-simple";
>
> @@ -146,10 +191,36 @@ &cpu1 {
> cpu-supply = <&buck2_reg>;
> };
>
> +&dp {
> + status = "okay";
> +
> + samsung,color-space = <0>;
> + samsung,color-depth = <1>;
> + samsung,link-rate = <0x0a>;
> + samsung,lane-count = <4>;
> + samsung,dynamic-range = <0>;
> + samsung,ycbcr-coeff = <0>;
> +
> + ports {
> + port {
> + dp_out: endpoint {
> + remote-endpoint = <&panel>;
> + };
> + };
> + };
> +};
> +
> &ehci {
> status = "disabled";
> };
>
> +&fimd {
> + status = "okay";
> +
> + assigned-clocks = <&clock CLK_MOUT_FIMD1>, <&clock CLK_MOUT_VPLL>;
> + assigned-clock-parents = <&clock CLK_MOUT_VPLL>;
> +};
> +
> &i2c_1 {
> status = "okay";
>
> @@ -396,6 +467,12 @@ ldo25_reg: LDO25 {
> };
> };
>
> +&mali {
> + status = "okay";
> +
> + mali-supply = <&buck4_reg>;
> +};
> +
> &mixer {
> status = "okay";
> };
> @@ -489,6 +566,14 @@ wlan_irq: wlan-irq-pins {
> };
>
> &pinctrl_1 {
> + aps_en_18v: aps-en-18v-pins {
> + samsung,pins = "gph1-6";
> + samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>; /* TODO */
> + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_INPUT>; /* TODO */
> + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_UP>; /* TODO */
> + samsung,pin-val = <0>; /* TODO */
> + };
> +
> bh1721fvc_reset: bh1721fvc-reset-pins {
> samsung,pins = "gph1-2";
> samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
> @@ -509,6 +594,20 @@ bt_wake: bt-wake-pins {
> samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
> };
>
> + lcd_en: lcd-en-pins {
> + samsung,pins = "gph1-7";
> + samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>; /* TODO */
> + samsung,pin-val = <0>;
> + };
> +
> + led_bl_reset: led-bl-rst-pins {
> + samsung,pins = "gpg0-5";
> + samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>; /* TODO */
> + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_PREV>; /* TODO */
> + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>; /* TODO */
> + samsung,pin-val = <0>; /* TODO */
> + };
> +
> msense_reset: msense-reset-pins {
> samsung,pins = "gpg2-0";
> samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
>
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v8 3/6] drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
From: Laurent Pinchart @ 2026-04-25 11:28 UTC (permalink / raw)
To: Dennis Gilmore
Cc: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonas Karlman,
Jernej Skrabec, Maxime Ripard, Alexey Charkov, devicetree,
linux-rockchip, linux-arm-kernel, dri-devel, linux-kernel,
Dmitry Baryshkov
In-Reply-To: <20260425031011.2529364-4-dennis@ausil.us>
Hi Dennis,
Thank you for the patch.
On Fri, Apr 24, 2026 at 10:10:08PM -0500, Dennis Gilmore wrote:
> The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
> to HDMI2.0 converter, designed to connect a USB Type-C source or
> a DP1.4 source to an HDMI2.0 sink.
As far as I can tell, the LT8711UXD has an I2C control interface.
Shouldn't it be an I2C device ?
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
> index 8aa31ca3c72d..42c1f3d5ba0c 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
> .data = &(const struct simple_bridge_info) {
> .connector_type = DRM_MODE_CONNECTOR_HDMIA,
> },
> + }, {
> + .compatible = "lontium,lt8711uxd",
> + .data = &(const struct simple_bridge_info) {
> + .connector_type = DRM_MODE_CONNECTOR_HDMIA,
> + },
> }, {
> .compatible = "parade,ps185hdm",
> .data = &(const struct simple_bridge_info) {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2] raid6: arm64: add SVE optimized implementation for syndrome generation
From: Demian Shulhan @ 2026-04-25 11:46 UTC (permalink / raw)
To: Mark Brown
Cc: Ard Biesheuvel, Robin Murphy, Christoph Hellwig, Mark Rutland,
Song Liu, Yu Kuai, Will Deacon, Catalin Marinas, linux-arm-kernel,
Li Nan, linux-raid, linux-kernel
In-Reply-To: <2c2eb793-c0a4-4b65-93f1-0ece5cf820d7@sirena.org.uk>
Hi all!
In the future I will try to look at optimisation of current algorithms
instead of SVE realisation, looks like there are few interesting
cases, I will share details in future changes.
Thanks all for the discussion!
пт, 17 квіт. 2026 р. о 18:36 Mark Brown <broonie@kernel.org> пише:
>
> On Fri, Apr 17, 2026 at 04:43:06PM +0200, Ard Biesheuvel wrote:
>
> > On arm64, kernel mode NEON is mostly used to gain access to AES and SHA
> > instructions, and only to a lesser degree to speed up ordinary
> > arithmetic, and so XOR is somewhat of an outlier here.
>
> > Given that Neoverse V1 apparently already carves up ordinary arithmetic
> > performed on 256-bit vectors and operates on 128 bits at a time, I am
> > rather skeptical that we're likely to see any SVE implementations of the
> > crypto extensions soon that are meaningfully faster, given that these
> > are presumably much costlier to implement in terms of gate count, and
> > therefore likely to be split up even on SVE implementations that can
> > perform ordinary arithmetic on 256+ bit vectors in a single cycle. Note
> > that even the arm64 SIMD accelerated CRC implementations rely heavily on
> > 64x64->128 polynomial multiplication.
>
> I'd not be surprised to see something that delivers useful benefits
> using SVE at some point.
>
> > IOW, before we consider kernel mode SVE, I'd like to see some benchmarks
> > for other algorithms too.
>
> Definitely, it needs a solid win to merge anything. I do want to get
> back to the situation where we've got out of tree infrastructure patches
> so that people working on algorithms have something to base their work
> on (and see the overheads using SVE incurs) but unless theres's a
> practical user they should stay out of tree.
^ permalink raw reply
* [PATCH] net: stmmac: fix RX DMA leak on TX alloc failure
From: Abid Ali via B4 Relay @ 2026-04-25 12:38 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel, Abid Ali
From: Abid Ali <dev.taqnialabs@gmail.com>
Free RX DMA resources when alloc_dma_tx_desc_resources() fails in
alloc_dma_desc_resources().
Signed-off-by: Abid Ali <dev.taqnialabs@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 13d3cac05..8bb843b55 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2370,8 +2370,12 @@ static int alloc_dma_desc_resources(struct stmmac_priv *priv,
return ret;
ret = alloc_dma_tx_desc_resources(priv, dma_conf);
+ if (ret) {
+ free_dma_rx_desc_resources(priv, dma_conf);
+ return ret;
+ }
- return ret;
+ return 0;
}
/**
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260425-stmmac-rx-desc-cleanup-440f05845492
Best regards,
--
Abid Ali <dev.taqnialabs@gmail.com>
^ permalink raw reply related
* Re: [PATCH v3 0/3] crypto: atmel-sha204a - multiple RNG fixes
From: Lothar Rubusch @ 2026-04-25 13:34 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij, linux-crypto,
linux-arm-kernel, linux-kernel
In-Reply-To: <a82278e5-9b5e-4fb9-9e7a-800ef2898ec5@app.fastmail.com>
Hi Ard and ML!
On Thu, Apr 23, 2026 at 11:25 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Hi Lothar,
>
> On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> > When testing the RNG functionality on the Atmel SHA204a hardware, I
> > found the following issues: rngtest reported failures and hexdump
> > reveiled only the first 8 bytes out of 32 provided actually entropy.
> >
> > Having a closer look into it, I found a (small) memory leak, missing
> > to free work_data, miss-reading of the count field into the entropy
> > fields and parts of the 32 random bytes staying 0 due to reading the
> > slow i2c device.
> >
> > The series proposes fixes and how fixed functionality can be/was
> > verified. Executing rngtest afterward showed a decent result, due
> > to the i2c bus a bit slow.
> >
> > All setups require selecting the Atmel-sha204a as active RNG.
> > $ cat /sys/class/misc/hw_random/rng_available
> > 3f104000.rng 1-0064 none
> >
> > $ echo 1-0064 > /sys/class/misc/hw_random/rng_current
> >
> > $ cat /sys/class/misc/hw_random/rng_current
> > 1-0064
> >
> > Testing RNG properties currently shows problematic results:
> > $ rngtest < /dev/hwrng
> > rngtest 2.6
> > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 1040032
> > rngtest: FIPS 140-2 successes: 0
> > rngtest: FIPS 140-2 failures: 52
> > rngtest: FIPS 140-2(2001-10-10) Monobit: 52
> > rngtest: FIPS 140-2(2001-10-10) Poker: 52
> > rngtest: FIPS 140-2(2001-10-10) Runs: 52
> > rngtest: FIPS 140-2(2001-10-10) Long run: 52
> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 52
> > rngtest: input channel speed: (min=7.631; avg=7.804; max=7.827)Kibits/s
> > rngtest: FIPS tests speed: (min=32.273; avg=32.701; max=33.056)Mibits/s
> > rngtest: Program run time: 130177956 microseconds
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> > ---
> > v2 -> v3: Removal blank line, rebased
> > v1 -> v2: Removal of C++ style comment (I saw it too late, sry for that)
> > ---
> > Lothar Rubusch (3):
> > crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
> > crypto: atmel-sha204a - fix truncated 32-byte blocking read
> > crypto: atmel-sha204a - fix non-blocking read logic
> >
> > drivers/crypto/atmel-sha204a.c | 60 ++++++++++++++++++++++------------
> > 1 file changed, 39 insertions(+), 21 deletions(-)
> >
>
> Thanks for the report and the fixes. However, I'm not sure you are entirely
> on the right track here. I managed to fix the rngtest issues that you report by
> making the changes below. As I already replied, I think it would be better to
> propose this as a standalone patch, and backport it to stable.
>
Thank you so much for taking the time and answering, I really appreciate!
Like two months ago I started playing a bit more with these Atmel i2c
devices. Actually I wanted to prepare something
different (and still pretend doing so). Figuring out things here, I
noticed this RNG feature did not work as I expected.
Around that time I prepared this patch set.
Probably, I was a bit too euphoric - I mean, it's a bit unlikely the
driver was upstreamed and never really worked.
I have to admit, I did not go thoroughly through the git history
first, since the driver does not do significantly more than
RNG, there must have happened a degradation. I'll keep this in mind:
first to build up better understanding of the driver
history. than to start digging into the code. Anyway, I wanted to get
some feedback.
> The remaining changes are somewhat debatable IMO: the leak is not really a leak,
> so I'd like to understand better what you are fixing here. The command field
> changes seems completely misguided (unless I am missing something)
>
So, firstly in the current RNG implementation I definitely see an
issue. If that's ok, I'll to prepare a patch to re-init probably
rather
to what you proposed, since it makes more sense to me now. Thank you
for pointing this out.
Secondly, I noticed the device is picky about its i2c communication
timings. Yes, definitely. Nowadays, after having worked with
it a bit more, I'd rather say generally reducing response time is
probably not the solution. I still think I see some timing issue,
which
I wanted to better address in an upcoming patch set (but probably not
related to this RNG thing). Currently the AtSHA204a and
the AtECC508a (and related families) are sharing the same Atmel i2c
driver. This core driver uses hardcoded max timings for
its i2c command operations. Going over the datasheets of both chips,
both have totally different max timings.
Currently just having RNG for AtSHA204a and ECDH and related for AtECC
- it probably doesn't matter too much. Anyway, also
read and write command timings differ and mix up then in the Atmel i2c
core driver. I guess, this was kind of a starting point for
me to dig deeper. So, I probably will drop that i2c timing change from
this RNG fix set.
Thirdly, the "leak" I think is probably rather a theoretic issue. I'll
sepearate it out, think over it, and in case prepare something,
let me then know what you think.
>
>
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -47,8 +47,8 @@
>
> if (rng->priv) {
> work_data = (struct atmel_i2c_work_data *)rng->priv;
> - max = min(sizeof(work_data->cmd.data), max);
> - memcpy(data, &work_data->cmd.data, max);
> + max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
> + memcpy(data, &work_data->cmd.data[1], max);
> rng->priv = 0;
> } else {
> work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
> @@ -86,8 +86,8 @@
> if (ret)
> return ret;
>
> - max = min(sizeof(cmd.data), max);
> - memcpy(data, cmd.data, max);
> + max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
> + memcpy(data, &cmd.data[1], max);
>
> return max;
> }
^ permalink raw reply
* Re: [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read
From: Thorsten Blum @ 2026-04-25 13:46 UTC (permalink / raw)
To: Lothar Rubusch
Cc: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422210936.20095-3-l.rubusch@gmail.com>
Hi Lothar,
On Wed, Apr 22, 2026 at 09:09:35PM +0000, Lothar Rubusch wrote:
> The ATSHA204A returns a 35-byte packet consisting of a 1-byte count,
> 32 bytes of entropy, and a 2-byte CRC. The current blocking read
> implementation was incorrectly copying data starting from the
> count byte, leading to offset data and truncated entropy.
>
> Additionally, the chip requires significant execution time to
> generate random numbers, going by the datasheet. Reading the I2C bus
> too early results in the chip NACK-ing or returning a partial buffer
> followed by zeros.
>
> Verification:
> Tests before showed repeadetly reading only 8 bytes of entropy:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020
>
> After this patch applied, the result will be as follows:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
> 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
> 00000020
>
> Fix these issues by:
> Increase cmd.msecs to 30ms to provide sufficient execution time. Then
> set cmd.rxsize to RANDOM_RSP_SIZE (35 bytes) to capture the entire
> hardware response. Eventually, correct the memcpy() offset to index 1 of
> the data buffer to skip the count byte and retrieve exactly 32 bytes of
> entropy.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Thank you for your patches. I tested patch 2/3 on real hardware and it
fixes rngtest for me. However, I have a few comments below.
> ---
> drivers/crypto/atmel-sha204a.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index 19720bdd446d..f7dc00d0f4cd 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -19,6 +19,9 @@
> #include <linux/workqueue.h>
> #include "atmel-i2c.h"
>
> +#define ATMEL_RNG_BLOCK_SIZE 32
> +#define ATMEL_RNG_EXEC_TIME 30
> +
> static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
> void *areq, int status)
> {
> @@ -91,13 +94,15 @@ static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
> i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
>
> atmel_i2c_init_random_cmd(&cmd);
> + cmd.msecs = ATMEL_RNG_EXEC_TIME;
> + cmd.rxsize = RANDOM_RSP_SIZE;
atmel_i2c_init_random_cmd() already sets cmd.rxsize to RANDOM_RSP_SIZE.
Changing cmd.msecs does not appear to be strictly necessary for the fix.
The only difference I observe is that rngtest runs faster with the new
value.
Here are my test results without changing cmd.msecs:
$ sudo head -c 300000 /dev/hwrng | rngtest -c 100
[...]
rngtest: starting FIPS tests...
rngtest: bits received from input: 2000032
rngtest: FIPS 140-2 successes: 100
rngtest: FIPS 140-2 failures: 0
[...]
rngtest: input channel speed: (min=1.118; avg=3.746; max=6510416.667)Kibits/s
rngtest: FIPS tests speed: (min=26.272; avg=27.471; max=32.829)Mibits/s
rngtest: Program run time: 538942640 microseconds
and with 'cmd.msecs = ATMEL_RNG_EXEC_TIME':
$ sudo head -c 300000 /dev/hwrng | rngtest -c 100
[...]
rngtest: starting FIPS tests...
rngtest: bits received from input: 2000032
rngtest: FIPS 140-2 successes: 100
rngtest: FIPS 140-2 failures: 0
[...]
rngtest: input channel speed: (min=1.584; avg=5.295; max=6510416.667)Kibits/s
rngtest: FIPS tests speed: (min=26.602; avg=27.321; max=28.257)Mibits/s
rngtest: Program run time: 381309284 microseconds
> ret = atmel_i2c_send_receive(i2c_priv->client, &cmd);
> if (ret)
> return ret;
>
> - max = min(sizeof(cmd.data), max);
> - memcpy(data, cmd.data, max);
> + max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> + memcpy(data, &cmd.data[1], max);
This works and fixes rngtest for me on real hardware.
min_t() is not strictly necessary here, since the types are compatible
and min() is sufficient.
I agree with Ard that patch 2/3 should be a separate patch for easier
stable backporting.
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read
From: Thorsten Blum @ 2026-04-25 14:08 UTC (permalink / raw)
To: Lothar Rubusch
Cc: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <aezFsF8gLkABZZ1O@linux.dev>
On Sat, Apr 25, 2026 at 03:46:30PM +0200, Thorsten Blum wrote:
> Hi Lothar,
>
> On Wed, Apr 22, 2026 at 09:09:35PM +0000, Lothar Rubusch wrote:
> > The ATSHA204A returns a 35-byte packet consisting of a 1-byte count,
> > 32 bytes of entropy, and a 2-byte CRC. The current blocking read
> > implementation was incorrectly copying data starting from the
> > count byte, leading to offset data and truncated entropy.
> >
> > Additionally, the chip requires significant execution time to
> > generate random numbers, going by the datasheet. Reading the I2C bus
> > too early results in the chip NACK-ing or returning a partial buffer
> > followed by zeros.
> >
> > Verification:
> > Tests before showed repeadetly reading only 8 bytes of entropy:
> > $ head -c 32 /dev/hwrng | hexdump -C
> > 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > 00000020
> >
> > After this patch applied, the result will be as follows:
> > $ head -c 32 /dev/hwrng | hexdump -C
> > 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
> > 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
> > 00000020
> >
> > Fix these issues by:
> > Increase cmd.msecs to 30ms to provide sufficient execution time. Then
> > set cmd.rxsize to RANDOM_RSP_SIZE (35 bytes) to capture the entire
> > hardware response. Eventually, correct the memcpy() offset to index 1 of
> > the data buffer to skip the count byte and retrieve exactly 32 bytes of
> > entropy.
> >
> > Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
[...]
> > - max = min(sizeof(cmd.data), max);
> > - memcpy(data, cmd.data, max);
> > + max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> > + memcpy(data, &cmd.data[1], max);
I just noticed that index 1 is already defined as RSP_DATA_IDX in
drivers/crypto/atmel-i2c.h.
> This works and fixes rngtest for me on real hardware.
>
> min_t() is not strictly necessary here, since the types are compatible
> and min() is sufficient.
>
> I agree with Ard that patch 2/3 should be a separate patch for easier
> stable backporting.
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH net] net: airoha: Do not read uninitialized fragment address in airoha_dev_xmit()
From: Lorenzo Bianconi @ 2026-04-25 14:10 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260424-airoha-xmit-fix-read-frag-v1-1-fdc0a83c79e8@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]
> The transmit loop in airoha_dev_xmit() reads fragment address and length
> during its final iteration, when the loop index equals
> skb_shinfo(skb)->nr_frags, at which point the fragment data is
> uninitialized. While these values are never consumed, the read itself is
> unsafe and may trigger a page fault. Fix this by avoiding the fragment
> read on the last iteration.
> Additionally, move the skb pointer from the first to the last used packet
> descriptor, so that airoha_qdma_tx_napi_poll() defers freeing the skb
> until the final descriptor is processed.
>
> Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 2bb0a3ff9810..d3a841908c82 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1997,8 +1997,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> struct netdev_queue *txq;
> struct airoha_queue *q;
> LIST_HEAD(tx_list);
> + int i = 0, qid;
> void *data;
> - int i, qid;
> u16 index;
> u8 fport;
>
> @@ -2057,7 +2057,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> list);
> index = e - q->entry;
>
> - for (i = 0; i < nr_frags; i++) {
> + while (true) {
> struct airoha_qdma_desc *desc = &q->desc[index];
> skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
> dma_addr_t addr;
> @@ -2069,7 +2069,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> goto error_unmap;
>
> list_move_tail(&e->list, &tx_list);
> - e->skb = i ? NULL : skb;
> + e->skb = i == nr_frags - 1 ? skb : NULL;
> e->dma_addr = addr;
> e->dma_len = len;
>
> @@ -2088,6 +2088,9 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> WRITE_ONCE(desc->msg1, cpu_to_le32(msg1));
> WRITE_ONCE(desc->msg2, cpu_to_le32(0xffff));
>
> + if (++i == nr_frags)
> + break;
> +
> data = skb_frag_address(frag);
> len = skb_frag_size(frag);
> }
>
> ---
> base-commit: e728258debd553c95d2e70f9cd97c9fde27c7130
> change-id: 20260423-airoha-xmit-fix-read-frag-dc6aa001ca4b
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
Commenting on Sashiko reported issues:
https://sashiko.dev/#/patchset/20260424-airoha-xmit-fix-read-frag-v1-1-fdc0a83c79e8%40kernel.org
- Does the TSO checksum calculation earlier in this function ensure the
TCP header is in the linear portion of the SKB?
This issue is not related to the current patch. Moreover, can we have a TSO
packet where the tcp header is not in the linear area of the skb?
- If dma_map_single() fails partway through a multi-fragment packet and
triggers this goto error_unmap, will it break the Tx ring contiguity?
This issue is not related to the current patch. Moreover, I guess the hw is
capable of managing out-of-order descriptors.
- Is it safe to map fragment data using dma_map_single() instead of
skb_frag_dma_map()?
This issue is not related to the current patch. I will post a dedicated patch
for it.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read
From: Lothar Rubusch @ 2026-04-25 14:11 UTC (permalink / raw)
To: Thorsten Blum
Cc: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <aezFsF8gLkABZZ1O@linux.dev>
Hi Thorsten!
On Sat, Apr 25, 2026 at 3:46 PM Thorsten Blum <thorsten.blum@linux.dev> wrote:
>
> Hi Lothar,
>
> On Wed, Apr 22, 2026 at 09:09:35PM +0000, Lothar Rubusch wrote:
> > The ATSHA204A returns a 35-byte packet consisting of a 1-byte count,
> > 32 bytes of entropy, and a 2-byte CRC. The current blocking read
> > implementation was incorrectly copying data starting from the
> > count byte, leading to offset data and truncated entropy.
> >
> > Additionally, the chip requires significant execution time to
> > generate random numbers, going by the datasheet. Reading the I2C bus
> > too early results in the chip NACK-ing or returning a partial buffer
> > followed by zeros.
> >
> > Verification:
> > Tests before showed repeadetly reading only 8 bytes of entropy:
> > $ head -c 32 /dev/hwrng | hexdump -C
> > 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > 00000020
> >
> > After this patch applied, the result will be as follows:
> > $ head -c 32 /dev/hwrng | hexdump -C
> > 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
> > 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
> > 00000020
> >
> > Fix these issues by:
> > Increase cmd.msecs to 30ms to provide sufficient execution time. Then
> > set cmd.rxsize to RANDOM_RSP_SIZE (35 bytes) to capture the entire
> > hardware response. Eventually, correct the memcpy() offset to index 1 of
> > the data buffer to skip the count byte and retrieve exactly 32 bytes of
> > entropy.
> >
> > Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
>
> Thank you for your patches. I tested patch 2/3 on real hardware and it
> fixes rngtest for me. However, I have a few comments below.
>
> > ---
> > drivers/crypto/atmel-sha204a.c | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> > index 19720bdd446d..f7dc00d0f4cd 100644
> > --- a/drivers/crypto/atmel-sha204a.c
> > +++ b/drivers/crypto/atmel-sha204a.c
> > @@ -19,6 +19,9 @@
> > #include <linux/workqueue.h>
> > #include "atmel-i2c.h"
> >
> > +#define ATMEL_RNG_BLOCK_SIZE 32
> > +#define ATMEL_RNG_EXEC_TIME 30
> > +
> > static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
> > void *areq, int status)
> > {
> > @@ -91,13 +94,15 @@ static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
> > i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
> >
> > atmel_i2c_init_random_cmd(&cmd);
> > + cmd.msecs = ATMEL_RNG_EXEC_TIME;
> > + cmd.rxsize = RANDOM_RSP_SIZE;
>
> atmel_i2c_init_random_cmd() already sets cmd.rxsize to RANDOM_RSP_SIZE.
>
> Changing cmd.msecs does not appear to be strictly necessary for the fix.
> The only difference I observe is that rngtest runs faster with the new
> value.
>
> Here are my test results without changing cmd.msecs:
>
> $ sudo head -c 300000 /dev/hwrng | rngtest -c 100
> [...]
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 2000032
> rngtest: FIPS 140-2 successes: 100
> rngtest: FIPS 140-2 failures: 0
> [...]
> rngtest: input channel speed: (min=1.118; avg=3.746; max=6510416.667)Kibits/s
> rngtest: FIPS tests speed: (min=26.272; avg=27.471; max=32.829)Mibits/s
> rngtest: Program run time: 538942640 microseconds
>
> and with 'cmd.msecs = ATMEL_RNG_EXEC_TIME':
>
> $ sudo head -c 300000 /dev/hwrng | rngtest -c 100
> [...]
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 2000032
> rngtest: FIPS 140-2 successes: 100
> rngtest: FIPS 140-2 failures: 0
> [...]
> rngtest: input channel speed: (min=1.584; avg=5.295; max=6510416.667)Kibits/s
> rngtest: FIPS tests speed: (min=26.602; avg=27.321; max=28.257)Mibits/s
> rngtest: Program run time: 381309284 microseconds
>
> > ret = atmel_i2c_send_receive(i2c_priv->client, &cmd);
> > if (ret)
> > return ret;
> >
> > - max = min(sizeof(cmd.data), max);
> > - memcpy(data, cmd.data, max);
> > + max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> > + memcpy(data, &cmd.data[1], max);
>
> This works and fixes rngtest for me on real hardware.
>
> min_t() is not strictly necessary here, since the types are compatible
> and min() is sufficient.
>
> I agree with Ard that patch 2/3 should be a separate patch for easier
> stable backporting.
>
I appreciate your answers and will take the review into account. Looks
like we had similar plans for
this weekend. So, since I answered to Ard quite in parallel to your
review, I'll restructure as I said in my
last mail on this list. I'll go through your comments and think about it.
Best,
L
> Thanks,
> Thorsten
^ permalink raw reply
* Re: [RFC PATCH v3 4/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"
From: Jarkko Sakkinen @ 2026-04-25 14:19 UTC (permalink / raw)
To: Jonathan McDowell
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, jgg, sudeep.holla,
maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene, Yeoreum Yun
In-Reply-To: <2e7b4dc552b45ddf14cc43bc449cbebb4ade0027.1777036497.git.noodles@meta.com>
On Fri, Apr 24, 2026 at 02:24:42PM +0100, Jonathan McDowell wrote:
> From: Yeoreum Yun <yeoreum.yun@arm.com>
>
> This reverts commit 0e0546eabcd6c19765a8dbf5b5db3723e7b0ea75, which was
> added to address ordering issues with the IMA LSM initialisation where
> the TPM would not be fully ready by the time IMA wanted it. This has
> been resolved within IMA by retrying setup during late_initcall_sync if
> the TPM is not available at first.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Signed-off-by: Jonathan McDowell <noodles@meta.com>
> ---
> drivers/firmware/arm_ffa/driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> index f2f94d4d533e..01547c5c0e38 100644
> --- a/drivers/firmware/arm_ffa/driver.c
> +++ b/drivers/firmware/arm_ffa/driver.c
> @@ -2106,7 +2106,7 @@ static int __init ffa_init(void)
> kfree(drv_info);
> return ret;
> }
> -rootfs_initcall(ffa_init);
> +module_init(ffa_init);
>
> static void __exit ffa_exit(void)
> {
> --
> 2.53.0
>
LGTM (for both tpm patches).
However, I'll hold on any further comments/tags up until I've sorted 7.1 PRs
(just so that I have full focus).
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v8 3/6] drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
From: Dmitry Baryshkov @ 2026-04-25 14:24 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Dennis Gilmore, Heiko Stuebner, Andrzej Hajda, Neil Armstrong,
Robert Foss, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel
In-Reply-To: <20260425112844.GB2964234@killaraus.ideasonboard.com>
On Sat, Apr 25, 2026 at 02:28:44PM +0300, Laurent Pinchart wrote:
> Hi Dennis,
>
> Thank you for the patch.
>
> On Fri, Apr 24, 2026 at 10:10:08PM -0500, Dennis Gilmore wrote:
> > The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
> > to HDMI2.0 converter, designed to connect a USB Type-C source or
> > a DP1.4 source to an HDMI2.0 sink.
>
> As far as I can tell, the LT8711UXD has an I2C control interface.
> Shouldn't it be an I2C device ?
From the datasheet:
The device is capable of automatic operation which is
enabled by an integrated microprocessor that uses an
embedded SPI flash for firmware storage. System control
is also available through the use of a dedicated
configuration I2C slave interface.
My guess was that it can either be an I2C device or it can function as a
simple platdev with no I2C controls. Please correct me if my
understanding was wrong.
But now looking at the schematics, it seems to be connected to I2C6.
Which means that it should be desribed (and bound) as such.
>
> > Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> > drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
> > index 8aa31ca3c72d..42c1f3d5ba0c 100644
> > --- a/drivers/gpu/drm/bridge/simple-bridge.c
> > +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> > @@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
> > .data = &(const struct simple_bridge_info) {
> > .connector_type = DRM_MODE_CONNECTOR_HDMIA,
> > },
> > + }, {
> > + .compatible = "lontium,lt8711uxd",
> > + .data = &(const struct simple_bridge_info) {
> > + .connector_type = DRM_MODE_CONNECTOR_HDMIA,
> > + },
> > }, {
> > .compatible = "parade,ps185hdm",
> > .data = &(const struct simple_bridge_info) {
>
> --
> Regards,
>
> Laurent Pinchart
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 0/3] iio: adc: xilinx-ams: refactor alarm handling to table-driven design
From: Jonathan Cameron @ 2026-04-25 15:34 UTC (permalink / raw)
To: Guilherme Ivo Bozi
Cc: Salih Erim, Conall O'Griofa, Michal Simek, David Lechner,
Nuno Sá, Andy Shevchenko, linux-iio, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260414224245.8493-1-guilherme.bozi@usp.br>
On Tue, 14 Apr 2026 19:40:32 -0300
Guilherme Ivo Bozi <guilherme.bozi@usp.br> wrote:
> This series addresses significant code duplication in alarm handling
> logic across the Xilinx AMS IIO driver.
>
> To address this, the series introduces a centralized table-driven
> mapping (alarm_map) that replaces multiple switch statements spread
> across the driver.
>
> This improves:
> - maintainability (single source of truth for mappings)
> - readability (removes repeated switch logic)
> - extensibility (new alarms require only table updates)
>
> No functional changes are intended.
This series looks fine to me.
Given the AMD Xilinx folk are fairly active reviewers I'm just
waiting on them taking a look.
>
> Series overview:
> - Patch 1: fix out-of-bounds channel lookup
> - Patch 2: convert mutex handling to guard(mutex)
> - Patch 3: introduce table-driven alarm mapping
>
> v1 -> v2:
> - Fixed Fixes tag format
> - Replaced AMS_ALARM_INVALID with AMS_ALARM_NONE
> - Changed alarm_map base_offset type
>
> v2 -> v3:
> - Replace 'i >= num_channels' with 'i == num_channels'
> - Add missing trailing comma in alarm_map array initializer
>
> Guilherme Ivo Bozi (3):
> iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event
> handling
> iio: adc: xilinx-ams: use guard(mutex) for automatic locking
> iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
>
> drivers/iio/adc/xilinx-ams.c | 190 +++++++++++++----------------------
> 1 file changed, 71 insertions(+), 119 deletions(-)
>
^ permalink raw reply
* [PATCH] pinctrl: qcom: Make important drivers default
From: Krzysztof Kozlowski @ 2026-04-25 15:55 UTC (permalink / raw)
To: Russell King, Bjorn Andersson, Konrad Dybcio, Linus Walleij,
linux-arm-kernel, linux-kernel, linux-arm-msm, linux-gpio
Cc: Krzysztof Kozlowski
The main SoC TLMM (Top-Level Multiplexer) pin controller drivers are
essential for booting up SoCs and are not really optional for a given
platform. Kernel should not ask users choice of drivers when that
choice is obvious and known to the developers that answer should be
'yes' or 'module'.
Switch all Qualcomm TLMM pin controller drivers to a default 'yes' for
ARCH_QCOM. This has impact:
1. arm64 defconfig: enable PINCTRL_SM7150 and PINCTRL_HAWI, which were
not selected before but should be, because these platforms need them
for proper boot.
2. arm qcom_defconfig: no changes.
3. arm multi_v7 defconfig: enable drivers necessary to boot ARM 32-bit
platforms, which are already enabled on qcom_defconfig.
4. COMPILE_TEST builds: enable by default all drivers for arm or arm64
builds, whenever ARCH_QCOM is selected. This has impact on build
time and feels logical, because if one selects ARCH_QCOM then
probably by default wants to build test it entirely. Kernels with
COMPILE_TEST are not supposed to be used for booting.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I did similar change for clocks and I will be continuing with
interconnect and other missing pieces.
---
arch/arm/configs/multi_v7_defconfig | 8 ----
arch/arm/configs/qcom_defconfig | 15 --------
arch/arm64/configs/defconfig | 46 ----------------------
drivers/pinctrl/qcom/Kconfig | 1 +
drivers/pinctrl/qcom/Kconfig.msm | 60 +++++++++++++++++++++++++++++
5 files changed, 61 insertions(+), 69 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index bcc9aabc1202..3847a6c17193 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -483,14 +483,6 @@ CONFIG_PINCTRL_PALMAS=y
CONFIG_PINCTRL_STMFX=y
CONFIG_PINCTRL_OWL=y
CONFIG_PINCTRL_S500=y
-CONFIG_PINCTRL_MSM=y
-CONFIG_PINCTRL_APQ8064=y
-CONFIG_PINCTRL_APQ8084=y
-CONFIG_PINCTRL_IPQ8064=y
-CONFIG_PINCTRL_MSM8660=y
-CONFIG_PINCTRL_MSM8960=y
-CONFIG_PINCTRL_MSM8X74=y
-CONFIG_PINCTRL_MSM8916=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
CONFIG_PINCTRL_RZA2=y
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 29a1dea500f0..03309b89ea4c 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -123,22 +123,7 @@ CONFIG_I2C_QUP=y
CONFIG_SPI=y
CONFIG_SPI_QUP=y
CONFIG_SPMI=y
-CONFIG_PINCTRL_MSM=y
-CONFIG_PINCTRL_APQ8064=y
-CONFIG_PINCTRL_APQ8084=y
-CONFIG_PINCTRL_IPQ4019=y
-CONFIG_PINCTRL_IPQ8064=y
-CONFIG_PINCTRL_MSM8226=y
-CONFIG_PINCTRL_MSM8660=y
-CONFIG_PINCTRL_MSM8960=y
-CONFIG_PINCTRL_MDM9607=y
-CONFIG_PINCTRL_MDM9615=y
-CONFIG_PINCTRL_MSM8X74=y
-CONFIG_PINCTRL_MSM8909=y
-CONFIG_PINCTRL_MSM8916=y
CONFIG_GPIOLIB=y
-CONFIG_PINCTRL_SDX55=y
-CONFIG_PINCTRL_SDX65=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
CONFIG_GPIO_SYSFS=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index dd1ac01ee29b..f4dfd0cc853c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -652,54 +652,8 @@ CONFIG_PINCTRL_IMX8ULP=y
CONFIG_PINCTRL_IMX91=y
CONFIG_PINCTRL_IMX93=y
CONFIG_PINCTRL_IMX_SCMI=y
-CONFIG_PINCTRL_MSM=y
-CONFIG_PINCTRL_ELIZA=y
-CONFIG_PINCTRL_GLYMUR=y
-CONFIG_PINCTRL_IPQ5018=y
-CONFIG_PINCTRL_IPQ5210=y
-CONFIG_PINCTRL_IPQ5332=y
-CONFIG_PINCTRL_IPQ5424=y
-CONFIG_PINCTRL_IPQ8074=y
-CONFIG_PINCTRL_IPQ6018=y
-CONFIG_PINCTRL_IPQ9574=y
-CONFIG_PINCTRL_KAANAPALI=y
-CONFIG_PINCTRL_MSM8916=y
-CONFIG_PINCTRL_MSM8953=y
-CONFIG_PINCTRL_MSM8976=y
-CONFIG_PINCTRL_MSM8994=y
-CONFIG_PINCTRL_MSM8996=y
-CONFIG_PINCTRL_MSM8998=y
-CONFIG_PINCTRL_QCM2290=y
-CONFIG_PINCTRL_QCS404=y
-CONFIG_PINCTRL_QCS615=y
-CONFIG_PINCTRL_QCS8300=y
-CONFIG_PINCTRL_QDF2XXX=y
-CONFIG_PINCTRL_QDU1000=y
CONFIG_PINCTRL_RP1=m
-CONFIG_PINCTRL_SA8775P=y
-CONFIG_PINCTRL_SC7180=y
-CONFIG_PINCTRL_SC7280=y
-CONFIG_PINCTRL_SC8180X=y
-CONFIG_PINCTRL_SC8280XP=y
-CONFIG_PINCTRL_SDM660=y
-CONFIG_PINCTRL_SDM670=y
-CONFIG_PINCTRL_SDM845=y
-CONFIG_PINCTRL_SDX75=y
CONFIG_PINCTRL_SKY1=y
-CONFIG_PINCTRL_SM4450=y
-CONFIG_PINCTRL_SM6115=y
-CONFIG_PINCTRL_SM6125=y
-CONFIG_PINCTRL_SM6350=y
-CONFIG_PINCTRL_SM6375=y
-CONFIG_PINCTRL_MILOS=y
-CONFIG_PINCTRL_SM8150=y
-CONFIG_PINCTRL_SM8250=y
-CONFIG_PINCTRL_SM8350=y
-CONFIG_PINCTRL_SM8450=y
-CONFIG_PINCTRL_SM8550=y
-CONFIG_PINCTRL_SM8650=y
-CONFIG_PINCTRL_SM8750=y
-CONFIG_PINCTRL_X1E80100=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_LPASS_LPI=m
CONFIG_PINCTRL_MILOS_LPASS_LPI=m
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 80af372a1147..ed5347cebb4c 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -6,6 +6,7 @@ config PINCTRL_MSM
depends on GPIOLIB
# OF for pinconf_generic_dt_node_to_map_group() from GENERIC_PINCONF
depends on OF
+ default ARCH_QCOM
select QCOM_SCM
select PINMUX
select GENERIC_PINMUX_FUNCTIONS
diff --git a/drivers/pinctrl/qcom/Kconfig.msm b/drivers/pinctrl/qcom/Kconfig.msm
index 836cdeca1006..1f77ccb2dcaf 100644
--- a/drivers/pinctrl/qcom/Kconfig.msm
+++ b/drivers/pinctrl/qcom/Kconfig.msm
@@ -4,6 +4,7 @@ if PINCTRL_MSM
config PINCTRL_APQ8064
tristate "Qualcomm APQ8064 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm APQ8064 platform.
@@ -11,6 +12,7 @@ config PINCTRL_APQ8064
config PINCTRL_APQ8084
tristate "Qualcomm APQ8084 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm APQ8084 platform.
@@ -18,6 +20,7 @@ config PINCTRL_APQ8084
config PINCTRL_ELIZA
tristate "Qualcomm Technologies Inc Eliza pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc Top Level Mode Multiplexer block (TLMM)
@@ -28,6 +31,7 @@ config PINCTRL_ELIZA
config PINCTRL_GLYMUR
tristate "Qualcomm Technologies Inc Glymur pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc Top Level Mode Multiplexer block (TLMM)
@@ -38,6 +42,7 @@ config PINCTRL_GLYMUR
config PINCTRL_HAWI
tristate "Qualcomm Technologies Inc Hawi pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc Top Level Mode Multiplexer block (TLMM)
@@ -48,6 +53,7 @@ config PINCTRL_HAWI
config PINCTRL_IPQ4019
tristate "Qualcomm IPQ4019 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm IPQ4019 platform.
@@ -55,6 +61,7 @@ config PINCTRL_IPQ4019
config PINCTRL_IPQ5018
tristate "Qualcomm Technologies, Inc. IPQ5018 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -64,6 +71,7 @@ config PINCTRL_IPQ5018
config PINCTRL_IPQ8064
tristate "Qualcomm IPQ8064 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm IPQ8064 platform.
@@ -71,6 +79,7 @@ config PINCTRL_IPQ8064
config PINCTRL_IPQ5210
tristate "Qualcomm Technologies Inc IPQ5210 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -79,6 +88,7 @@ config PINCTRL_IPQ5210
config PINCTRL_IPQ5332
tristate "Qualcomm Technologies Inc IPQ5332 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -87,6 +97,7 @@ config PINCTRL_IPQ5332
config PINCTRL_IPQ5424
tristate "Qualcomm Technologies, Inc. IPQ5424 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -96,6 +107,7 @@ config PINCTRL_IPQ5424
config PINCTRL_IPQ8074
tristate "Qualcomm Technologies, Inc. IPQ8074 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -105,6 +117,7 @@ config PINCTRL_IPQ8074
config PINCTRL_IPQ6018
tristate "Qualcomm Technologies, Inc. IPQ6018 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -114,6 +127,7 @@ config PINCTRL_IPQ6018
config PINCTRL_IPQ9574
tristate "Qualcomm Technologies, Inc. IPQ9574 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -123,6 +137,7 @@ config PINCTRL_IPQ9574
config PINCTRL_KAANAPALI
tristate "Qualcomm Technologies Inc Kaanapali pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -131,6 +146,7 @@ config PINCTRL_KAANAPALI
config PINCTRL_MSM8226
tristate "Qualcomm 8226 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -139,6 +155,7 @@ config PINCTRL_MSM8226
config PINCTRL_MSM8660
tristate "Qualcomm 8660 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8660 platform.
@@ -146,12 +163,14 @@ config PINCTRL_MSM8660
config PINCTRL_MSM8960
tristate "Qualcomm 8960 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8960 platform.
config PINCTRL_MDM9607
tristate "Qualcomm 9607 pin controller driver"
+ default ARCH_QCOM if ARM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 9607 platform.
@@ -159,6 +178,7 @@ config PINCTRL_MDM9607
config PINCTRL_MDM9615
tristate "Qualcomm 9615 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 9615 platform.
@@ -166,6 +186,7 @@ config PINCTRL_MDM9615
config PINCTRL_MSM8X74
tristate "Qualcomm 8x74 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8974 platform.
@@ -173,12 +194,14 @@ config PINCTRL_MSM8X74
config PINCTRL_MSM8909
tristate "Qualcomm 8909 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found on the Qualcomm MSM8909 platform.
config PINCTRL_MSM8916
tristate "Qualcomm 8916 pin controller driver"
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found on the Qualcomm 8916 platform.
@@ -192,6 +215,7 @@ config PINCTRL_MSM8917
config PINCTRL_MSM8953
tristate "Qualcomm 8953 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found on the Qualcomm MSM8953 platform.
@@ -201,6 +225,7 @@ config PINCTRL_MSM8953
config PINCTRL_MSM8976
tristate "Qualcomm 8976 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found on the Qualcomm MSM8976 platform.
@@ -210,6 +235,7 @@ config PINCTRL_MSM8976
config PINCTRL_MSM8994
tristate "Qualcomm 8994 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8994 platform. The
@@ -218,6 +244,7 @@ config PINCTRL_MSM8994
config PINCTRL_MSM8996
tristate "Qualcomm MSM8996 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm MSM8996 platform.
@@ -225,6 +252,7 @@ config PINCTRL_MSM8996
config PINCTRL_MSM8998
tristate "Qualcomm MSM8998 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm MSM8998 platform.
@@ -232,6 +260,7 @@ config PINCTRL_MSM8998
config PINCTRL_QCM2290
tristate "Qualcomm QCM2290 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
TLMM block found in the Qualcomm QCM2290 platform.
@@ -239,6 +268,7 @@ config PINCTRL_QCM2290
config PINCTRL_QCS404
tristate "Qualcomm QCS404 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
TLMM block found in the Qualcomm QCS404 platform.
@@ -246,6 +276,7 @@ config PINCTRL_QCS404
config PINCTRL_QCS615
tristate "Qualcomm Technologies QCS615 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
TLMM block found on the Qualcomm QCS615 platform.
@@ -253,6 +284,7 @@ config PINCTRL_QCS615
config PINCTRL_QCS8300
tristate "Qualcomm Technologies QCS8300 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux and pinconf driver for the Qualcomm
TLMM block found on the Qualcomm QCS8300 platform.
@@ -260,6 +292,7 @@ config PINCTRL_QCS8300
config PINCTRL_QDF2XXX
tristate "Qualcomm Technologies QDF2xxx pin controller driver"
depends on ACPI
+ default ARCH_QCOM if ARM64
help
This is the GPIO driver for the TLMM block found on the
Qualcomm Technologies QDF2xxx SOCs.
@@ -267,6 +300,7 @@ config PINCTRL_QDF2XXX
config PINCTRL_QDU1000
tristate "Qualcomm Technologies Inc QDU1000/QRU1000 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf, and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -275,6 +309,7 @@ config PINCTRL_QDU1000
config PINCTRL_SA8775P
tristate "Qualcomm Technologies Inc SA8775P pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux and pinconf driver for the Qualcomm
TLMM block found on the Qualcomm SA8775P platforms.
@@ -290,6 +325,7 @@ config PINCTRL_SAR2130P
config PINCTRL_SC7180
tristate "Qualcomm Technologies Inc SC7180 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -298,6 +334,7 @@ config PINCTRL_SC7180
config PINCTRL_SC7280
tristate "Qualcomm Technologies Inc SC7280 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -307,6 +344,7 @@ config PINCTRL_SC8180X
tristate "Qualcomm Technologies Inc SC8180x pin controller driver"
depends on (OF || ACPI)
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -315,6 +353,7 @@ config PINCTRL_SC8180X
config PINCTRL_SC8280XP
tristate "Qualcomm Technologies Inc SC8280xp pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -323,6 +362,7 @@ config PINCTRL_SC8280XP
config PINCTRL_SDM660
tristate "Qualcomm Technologies Inc SDM660 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -331,6 +371,7 @@ config PINCTRL_SDM660
config PINCTRL_SDM670
tristate "Qualcomm Technologies Inc SDM670 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -340,6 +381,7 @@ config PINCTRL_SDM845
tristate "Qualcomm Technologies Inc SDM845 pin controller driver"
depends on (OF || ACPI)
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -348,6 +390,7 @@ config PINCTRL_SDM845
config PINCTRL_SDX55
tristate "Qualcomm Technologies Inc SDX55 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -356,6 +399,7 @@ config PINCTRL_SDX55
config PINCTRL_SDX65
tristate "Qualcomm Technologies Inc SDX65 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -364,6 +408,7 @@ config PINCTRL_SDX65
config PINCTRL_SDX75
tristate "Qualcomm Technologies Inc SDX75 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -372,6 +417,7 @@ config PINCTRL_SDX75
config PINCTRL_SM4450
tristate "Qualcomm Technologies Inc SM4450 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -380,6 +426,7 @@ config PINCTRL_SM4450
config PINCTRL_SM6115
tristate "Qualcomm Technologies Inc SM6115,SM4250 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -388,6 +435,7 @@ config PINCTRL_SM6115
config PINCTRL_SM6125
tristate "Qualcomm Technologies Inc SM6125 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -396,6 +444,7 @@ config PINCTRL_SM6125
config PINCTRL_SM6350
tristate "Qualcomm Technologies Inc SM6350 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -404,6 +453,7 @@ config PINCTRL_SM6350
config PINCTRL_SM6375
tristate "Qualcomm Technologies Inc SM6375 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -412,6 +462,7 @@ config PINCTRL_SM6375
config PINCTRL_SM7150
tristate "Qualcomm Technologies Inc SM7150 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -420,6 +471,7 @@ config PINCTRL_SM7150
config PINCTRL_MILOS
tristate "Qualcomm Technologies Inc Milos pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -428,6 +480,7 @@ config PINCTRL_MILOS
config PINCTRL_SM8150
tristate "Qualcomm Technologies Inc SM8150 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -436,6 +489,7 @@ config PINCTRL_SM8150
config PINCTRL_SM8250
tristate "Qualcomm Technologies Inc SM8250 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -444,6 +498,7 @@ config PINCTRL_SM8250
config PINCTRL_SM8350
tristate "Qualcomm Technologies Inc SM8350 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -452,6 +507,7 @@ config PINCTRL_SM8350
config PINCTRL_SM8450
tristate "Qualcomm Technologies Inc SM8450 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -460,6 +516,7 @@ config PINCTRL_SM8450
config PINCTRL_SM8550
tristate "Qualcomm Technologies Inc SM8550 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -468,6 +525,7 @@ config PINCTRL_SM8550
config PINCTRL_SM8650
tristate "Qualcomm Technologies Inc SM8650 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -476,6 +534,7 @@ config PINCTRL_SM8650
config PINCTRL_SM8750
tristate "Qualcomm Technologies Inc SM8750 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -484,6 +543,7 @@ config PINCTRL_SM8750
config PINCTRL_X1E80100
tristate "Qualcomm Technologies Inc X1E80100 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc Top Level Mode Multiplexer block (TLMM)
--
2.51.0
^ permalink raw reply related
* [PATCH] iio: adc: meson-saradc: fix calibration buffer leak on error
From: Felix Gu @ 2026-04-25 16:07 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rosen Penev
Cc: linux-iio, linux-arm-kernel, linux-amlogic, linux-kernel,
Jonathan Cameron, Felix Gu
meson_sar_adc_temp_sensor_init() allocates a buffer with
nvmem_cell_read(), but the old code leaked it if
syscon_regmap_lookup_by_phandle() failed.
Switch buf to __free(kfree) so all return paths release it.
Fixes: d6f2eac64403 ("iio: adc: meson: no devm for nvmem_cell_get")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/iio/adc/meson_saradc.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 23991a3612bd..9708ddcc4919 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -786,7 +786,7 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
static int meson_sar_adc_temp_sensor_init(struct iio_dev *indio_dev)
{
struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
- u8 *buf, trimming_bits, trimming_mask, upper_adc_val;
+ u8 trimming_bits, trimming_mask, upper_adc_val;
struct device *dev = indio_dev->dev.parent;
struct nvmem_cell *temperature_calib;
size_t read_len;
@@ -807,14 +807,12 @@ static int meson_sar_adc_temp_sensor_init(struct iio_dev *indio_dev)
}
read_len = MESON_SAR_ADC_EFUSE_BYTES;
- buf = nvmem_cell_read(temperature_calib, &read_len);
+ u8 *buf __free(kfree) = nvmem_cell_read(temperature_calib, &read_len);
nvmem_cell_put(temperature_calib);
if (IS_ERR(buf))
return dev_err_probe(dev, PTR_ERR(buf), "failed to read temperature_calib cell\n");
- if (read_len != MESON_SAR_ADC_EFUSE_BYTES) {
- kfree(buf);
+ if (read_len != MESON_SAR_ADC_EFUSE_BYTES)
return dev_err_probe(dev, -EINVAL, "invalid read size of temperature_calib cell\n");
- }
priv->tsc_regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "amlogic,hhi-sysctrl");
if (IS_ERR(priv->tsc_regmap))
@@ -835,8 +833,6 @@ static int meson_sar_adc_temp_sensor_init(struct iio_dev *indio_dev)
priv->temperature_sensor_adc_val |= upper_adc_val << BITS_PER_BYTE;
priv->temperature_sensor_adc_val >>= trimming_bits;
- kfree(buf);
-
return 0;
}
---
base-commit: 7080e32d3f09d8688c4a87d81bdcc71f7f606b16
change-id: 20260425-meson_saradc-54abc52d9b31
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH] iio: adc: meson-saradc: fix calibration buffer leak on error
From: David Lechner @ 2026-04-25 16:17 UTC (permalink / raw)
To: Felix Gu, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rosen Penev
Cc: linux-iio, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260426-meson_saradc-v1-1-6e96b2982c43@gmail.com>
On 4/25/26 11:07 AM, Felix Gu wrote:
> meson_sar_adc_temp_sensor_init() allocates a buffer with
> nvmem_cell_read(), but the old code leaked it if
> syscon_regmap_lookup_by_phandle() failed.
>
> Switch buf to __free(kfree) so all return paths release it.
>
> Fixes: d6f2eac64403 ("iio: adc: meson: no devm for nvmem_cell_get")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/iio/adc/meson_saradc.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 23991a3612bd..9708ddcc4919 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -786,7 +786,7 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
> static int meson_sar_adc_temp_sensor_init(struct iio_dev *indio_dev)
> {
Nice to see one of these cleanup.h patches that is actually fixing a bug.
Should `#include <linux/cleanup.h>` though rather that relying on it being
included through another header.
With that fixed...
Reviewed-by: David Lechner <dlechner@baylibre.com>
^ permalink raw reply
* [PATCH v6 01/59] perf inject: Fix itrace branch stack synthesis
From: Ian Rogers @ 2026-04-25 17:47 UTC (permalink / raw)
To: acme, adrian.hunter, james.clark, leo.yan, namhyung, tmricht
Cc: alice.mei.rogers, dapeng1.mi, linux-arm-kernel, linux-kernel,
linux-perf-users, mingo, peterz, Ian Rogers
In-Reply-To: <20260425174858.3922152-1-irogers@google.com>
When using "perf inject --itrace=L" to synthesize branch stacks from
AUX data, several issues caused failures:
1. The synthesized samples were delivered without the
PERF_SAMPLE_BRANCH_STACK flag if it was not in the original event's
sample_type. Fixed by using sample_type | evsel->synth_sample_type
in intel_pt_deliver_synth_event.
2. The record layout was misaligned because of inconsistent handling
of PERF_SAMPLE_BRANCH_HW_INDEX. Fixed by explicitly writing nr and
hw_idx in perf_event__synthesize_sample.
3. Modifying evsel->core.attr.sample_type early in __cmd_inject caused
parse failures for subsequent records in the input file. Fixed by
moving this modification to just before writing the header.
4. perf_event__repipe_sample was narrowed to only synthesize samples
when branch stack injection was requested, and restored the use of
perf_inject__cut_auxtrace_sample as a fallback to preserve
functionality.
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
---
Issues fixed in v2:
1. Potential Heap Overflow in perf_event__repipe_sample : Addressed by
adding a check that prints an error and returns -EFAULT if the
calculated event size exceeds PERF_SAMPLE_MAX_SIZE , as you
requested.
2. Header vs Payload Mismatch in __cmd_inject : Addressed by narrowing
the condition so that HEADER_BRANCH_STACK is only set in the file
header if add_last_branch was true.
3. NULL Pointer Dereference in intel-pt.c : Addressed by updating the
condition in intel_pt_do_synth_pebs_sample to fill sample.
branch_stack if it was synthesized, even if not in the original
sample_type .
4. Unsafe Reads for events lacking HW_INDEX in synthetic-events.c :
Addressed by using the perf_sample__branch_entries() macro and
checking sample->no_hw_idx .
5. Size mismatch in perf_event__sample_event_size : Addressed by
passing branch_sample_type to it and conditioning the hw_idx size on
PERF_SAMPLE_BRANCH_HW_INDEX .
---
tools/perf/bench/inject-buildid.c | 9 ++--
tools/perf/builtin-inject.c | 77 ++++++++++++++++++++++++++++--
tools/perf/tests/dlfilter-test.c | 8 +++-
tools/perf/tests/sample-parsing.c | 5 +-
tools/perf/util/arm-spe.c | 7 ++-
tools/perf/util/cs-etm.c | 6 ++-
tools/perf/util/intel-bts.c | 3 +-
tools/perf/util/intel-pt.c | 13 +++--
tools/perf/util/synthetic-events.c | 25 +++++++---
tools/perf/util/synthetic-events.h | 6 ++-
10 files changed, 129 insertions(+), 30 deletions(-)
diff --git a/tools/perf/bench/inject-buildid.c b/tools/perf/bench/inject-buildid.c
index aad572a78d7f..bfd2c5ec9488 100644
--- a/tools/perf/bench/inject-buildid.c
+++ b/tools/perf/bench/inject-buildid.c
@@ -228,9 +228,12 @@ static ssize_t synthesize_sample(struct bench_data *data, struct bench_dso *dso,
event.header.type = PERF_RECORD_SAMPLE;
event.header.misc = PERF_RECORD_MISC_USER;
- event.header.size = perf_event__sample_event_size(&sample, bench_sample_type, 0);
-
- perf_event__synthesize_sample(&event, bench_sample_type, 0, &sample);
+ event.header.size = perf_event__sample_event_size(&sample, bench_sample_type,
+ /*read_format=*/0,
+ /*branch_sample_type=*/0);
+ perf_event__synthesize_sample(&event, bench_sample_type,
+ /*read_format=*/0,
+ /*branch_sample_type=*/0, &sample);
return writen(data->input_pipe[1], &event, event.header.size);
}
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index f174bc69cec4..88c0ef4f5ff1 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -375,7 +375,59 @@ static int perf_event__repipe_sample(const struct perf_tool *tool,
build_id__mark_dso_hit(tool, event, sample, evsel, machine);
- if (inject->itrace_synth_opts.set && sample->aux_sample.size) {
+ if (inject->itrace_synth_opts.set &&
+ (inject->itrace_synth_opts.last_branch ||
+ inject->itrace_synth_opts.add_last_branch)) {
+ union perf_event *event_copy = (void *)inject->event_copy;
+ struct branch_stack dummy_bs = { .nr = 0 };
+ int err;
+ size_t sz;
+ u64 orig_type = evsel->core.attr.sample_type;
+ u64 orig_branch_type = evsel->core.attr.branch_sample_type;
+
+ if (event_copy == NULL) {
+ inject->event_copy = malloc(PERF_SAMPLE_MAX_SIZE);
+ if (!inject->event_copy)
+ return -ENOMEM;
+
+ event_copy = (void *)inject->event_copy;
+ }
+
+ if (!sample->branch_stack)
+ sample->branch_stack = &dummy_bs;
+
+ if (inject->itrace_synth_opts.add_last_branch) {
+ /* Temporarily add in type bits for synthesis. */
+ evsel->core.attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
+ evsel->core.attr.branch_sample_type |= PERF_SAMPLE_BRANCH_HW_INDEX;
+ evsel->core.attr.sample_type &= ~PERF_SAMPLE_AUX;
+ }
+
+ sz = perf_event__sample_event_size(sample, evsel->core.attr.sample_type,
+ evsel->core.attr.read_format,
+ evsel->core.attr.branch_sample_type);
+
+ if (sz > PERF_SAMPLE_MAX_SIZE) {
+ pr_err("Sample size %zu exceeds max size %d\n", sz, PERF_SAMPLE_MAX_SIZE);
+ return -EFAULT;
+ }
+
+ event_copy->header.type = PERF_RECORD_SAMPLE;
+ event_copy->header.size = sz;
+
+ err = perf_event__synthesize_sample(event_copy, evsel->core.attr.sample_type,
+ evsel->core.attr.read_format,
+ evsel->core.attr.branch_sample_type, sample);
+
+ evsel->core.attr.sample_type = orig_type;
+ evsel->core.attr.branch_sample_type = orig_branch_type;
+
+ if (err) {
+ pr_err("Failed to synthesize sample\n");
+ return err;
+ }
+ event = event_copy;
+ } else if (inject->itrace_synth_opts.set && sample->aux_sample.size) {
event = perf_inject__cut_auxtrace_sample(inject, event, sample);
if (IS_ERR(event))
return PTR_ERR(event);
@@ -464,7 +516,8 @@ static int perf_event__convert_sample_callchain(const struct perf_tool *tool,
sample_type &= ~(PERF_SAMPLE_STACK_USER | PERF_SAMPLE_REGS_USER);
perf_event__synthesize_sample(event_copy, sample_type,
- evsel->core.attr.read_format, sample);
+ evsel->core.attr.read_format,
+ evsel->core.attr.branch_sample_type, sample);
return perf_event__repipe_synth(tool, event_copy);
}
@@ -1100,7 +1153,8 @@ static int perf_inject__sched_stat(const struct perf_tool *tool,
sample_sw.period = sample->period;
sample_sw.time = sample->time;
perf_event__synthesize_sample(event_sw, evsel->core.attr.sample_type,
- evsel->core.attr.read_format, &sample_sw);
+ evsel->core.attr.read_format,
+ evsel->core.attr.branch_sample_type, &sample_sw);
build_id__mark_dso_hit(tool, event_sw, &sample_sw, evsel, machine);
ret = perf_event__repipe(tool, event_sw, &sample_sw, machine);
perf_sample__exit(&sample_sw);
@@ -2434,12 +2488,25 @@ static int __cmd_inject(struct perf_inject *inject)
* synthesized hardware events, so clear the feature flag.
*/
if (inject->itrace_synth_opts.set) {
+ struct evsel *evsel;
+
perf_header__clear_feat(&session->header,
HEADER_AUXTRACE);
- if (inject->itrace_synth_opts.last_branch ||
- inject->itrace_synth_opts.add_last_branch)
+
+ evlist__for_each_entry(session->evlist, evsel) {
+ evsel->core.attr.sample_type &= ~PERF_SAMPLE_AUX;
+ }
+
+ if (inject->itrace_synth_opts.add_last_branch) {
perf_header__set_feat(&session->header,
HEADER_BRANCH_STACK);
+
+ evlist__for_each_entry(session->evlist, evsel) {
+ evsel->core.attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
+ evsel->core.attr.branch_sample_type |=
+ PERF_SAMPLE_BRANCH_HW_INDEX;
+ }
+ }
}
/*
diff --git a/tools/perf/tests/dlfilter-test.c b/tools/perf/tests/dlfilter-test.c
index e63790c61d53..204663571943 100644
--- a/tools/perf/tests/dlfilter-test.c
+++ b/tools/perf/tests/dlfilter-test.c
@@ -188,8 +188,12 @@ static int write_sample(struct test_data *td, u64 sample_type, u64 id, pid_t pid
event->header.type = PERF_RECORD_SAMPLE;
event->header.misc = PERF_RECORD_MISC_USER;
- event->header.size = perf_event__sample_event_size(&sample, sample_type, 0);
- err = perf_event__synthesize_sample(event, sample_type, 0, &sample);
+ event->header.size = perf_event__sample_event_size(&sample, sample_type,
+ /*read_format=*/0,
+ /*branch_sample_type=*/0);
+ err = perf_event__synthesize_sample(event, sample_type,
+ /*read_format=*/0,
+ /*branch_sample_type=*/0, &sample);
if (err)
return test_result("perf_event__synthesize_sample() failed", TEST_FAIL);
diff --git a/tools/perf/tests/sample-parsing.c b/tools/perf/tests/sample-parsing.c
index a7327c942ca2..55f0b73ca20e 100644
--- a/tools/perf/tests/sample-parsing.c
+++ b/tools/perf/tests/sample-parsing.c
@@ -310,7 +310,8 @@ static int do_test(u64 sample_type, u64 sample_regs, u64 read_format)
sample.read.one.lost = 1;
}
- sz = perf_event__sample_event_size(&sample, sample_type, read_format);
+ sz = perf_event__sample_event_size(&sample, sample_type, read_format,
+ evsel.core.attr.branch_sample_type);
bufsz = sz + 4096; /* Add a bit for overrun checking */
event = malloc(bufsz);
if (!event) {
@@ -324,7 +325,7 @@ static int do_test(u64 sample_type, u64 sample_regs, u64 read_format)
event->header.size = sz;
err = perf_event__synthesize_sample(event, sample_type, read_format,
- &sample);
+ evsel.core.attr.branch_sample_type, &sample);
if (err) {
pr_debug("%s failed for sample_type %#"PRIx64", error %d\n",
"perf_event__synthesize_sample", sample_type, err);
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index e5835042acdf..c4ed9f10e731 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -484,8 +484,11 @@ static void arm_spe__prep_branch_stack(struct arm_spe_queue *speq)
static int arm_spe__inject_event(union perf_event *event, struct perf_sample *sample, u64 type)
{
- event->header.size = perf_event__sample_event_size(sample, type, 0);
- return perf_event__synthesize_sample(event, type, 0, sample);
+ event->header.type = PERF_RECORD_SAMPLE;
+ event->header.size = perf_event__sample_event_size(sample, type, /*read_format=*/0,
+ /*branch_sample_type=*/0);
+ return perf_event__synthesize_sample(event, type, /*read_format=*/0,
+ /*branch_sample_type=*/0, sample);
}
static inline int
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 8a639d2e51a4..1ebc1a6a5e75 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1425,8 +1425,10 @@ static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq,
static int cs_etm__inject_event(union perf_event *event,
struct perf_sample *sample, u64 type)
{
- event->header.size = perf_event__sample_event_size(sample, type, 0);
- return perf_event__synthesize_sample(event, type, 0, sample);
+ event->header.size = perf_event__sample_event_size(sample, type, /*read_format=*/0,
+ /*branch_sample_type=*/0);
+ return perf_event__synthesize_sample(event, type, /*read_format=*/0,
+ /*branch_sample_type=*/0, sample);
}
diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index 382255393fb3..0b18ebd13f7c 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -303,7 +303,8 @@ static int intel_bts_synth_branch_sample(struct intel_bts_queue *btsq,
event.sample.header.size = bts->branches_event_size;
ret = perf_event__synthesize_sample(&event,
bts->branches_sample_type,
- 0, &sample);
+ /*read_format=*/0, /*branch_sample_type=*/0,
+ &sample);
if (ret)
return ret;
}
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index fc9eec8b54b8..2dce6106c038 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -1731,8 +1731,12 @@ static void intel_pt_prep_b_sample(struct intel_pt *pt,
static int intel_pt_inject_event(union perf_event *event,
struct perf_sample *sample, u64 type)
{
- event->header.size = perf_event__sample_event_size(sample, type, 0);
- return perf_event__synthesize_sample(event, type, 0, sample);
+ event->header.type = PERF_RECORD_SAMPLE;
+ event->header.size = perf_event__sample_event_size(sample, type, /*read_format=*/0,
+ /*branch_sample_type=*/0);
+
+ return perf_event__synthesize_sample(event, type, /*read_format=*/0,
+ /*branch_sample_type=*/0, sample);
}
static inline int intel_pt_opt_inject(struct intel_pt *pt,
@@ -2486,7 +2490,7 @@ static int intel_pt_do_synth_pebs_sample(struct intel_pt_queue *ptq, struct evse
intel_pt_add_xmm(intr_regs, pos, items, regs_mask);
}
- if (sample_type & PERF_SAMPLE_BRANCH_STACK) {
+ if ((sample_type | evsel->synth_sample_type) & PERF_SAMPLE_BRANCH_STACK) {
if (items->mask[INTEL_PT_LBR_0_POS] ||
items->mask[INTEL_PT_LBR_1_POS] ||
items->mask[INTEL_PT_LBR_2_POS]) {
@@ -2557,7 +2561,8 @@ static int intel_pt_do_synth_pebs_sample(struct intel_pt_queue *ptq, struct evse
sample.transaction = txn;
}
- ret = intel_pt_deliver_synth_event(pt, event, &sample, sample_type);
+ ret = intel_pt_deliver_synth_event(pt, event, &sample,
+ sample_type | evsel->synth_sample_type);
perf_sample__exit(&sample);
return ret;
}
diff --git a/tools/perf/util/synthetic-events.c b/tools/perf/util/synthetic-events.c
index 85bee747f4cd..2461f25a4d7d 100644
--- a/tools/perf/util/synthetic-events.c
+++ b/tools/perf/util/synthetic-events.c
@@ -1455,7 +1455,8 @@ int perf_event__synthesize_stat_round(const struct perf_tool *tool,
return process(tool, (union perf_event *) &event, NULL, machine);
}
-size_t perf_event__sample_event_size(const struct perf_sample *sample, u64 type, u64 read_format)
+size_t perf_event__sample_event_size(const struct perf_sample *sample, u64 type, u64 read_format,
+ u64 branch_sample_type)
{
size_t sz, result = sizeof(struct perf_record_sample);
@@ -1515,8 +1516,10 @@ size_t perf_event__sample_event_size(const struct perf_sample *sample, u64 type,
if (type & PERF_SAMPLE_BRANCH_STACK) {
sz = sample->branch_stack->nr * sizeof(struct branch_entry);
- /* nr, hw_idx */
- sz += 2 * sizeof(u64);
+ /* nr */
+ sz += sizeof(u64);
+ if (branch_sample_type & PERF_SAMPLE_BRANCH_HW_INDEX)
+ sz += sizeof(u64);
result += sz;
}
@@ -1605,7 +1608,7 @@ static __u64 *copy_read_group_values(__u64 *array, __u64 read_format,
}
int perf_event__synthesize_sample(union perf_event *event, u64 type, u64 read_format,
- const struct perf_sample *sample)
+ u64 branch_sample_type, const struct perf_sample *sample)
{
__u64 *array;
size_t sz;
@@ -1719,9 +1722,17 @@ int perf_event__synthesize_sample(union perf_event *event, u64 type, u64 read_fo
if (type & PERF_SAMPLE_BRANCH_STACK) {
sz = sample->branch_stack->nr * sizeof(struct branch_entry);
- /* nr, hw_idx */
- sz += 2 * sizeof(u64);
- memcpy(array, sample->branch_stack, sz);
+
+ *array++ = sample->branch_stack->nr;
+
+ if (branch_sample_type & PERF_SAMPLE_BRANCH_HW_INDEX) {
+ if (sample->no_hw_idx)
+ *array++ = 0;
+ else
+ *array++ = sample->branch_stack->hw_idx;
+ }
+
+ memcpy(array, perf_sample__branch_entries((struct perf_sample *)sample), sz);
array = (void *)array + sz;
}
diff --git a/tools/perf/util/synthetic-events.h b/tools/perf/util/synthetic-events.h
index b0edad0c3100..8c7f49f9ccf5 100644
--- a/tools/perf/util/synthetic-events.h
+++ b/tools/perf/util/synthetic-events.h
@@ -81,7 +81,8 @@ int perf_event__synthesize_mmap_events(const struct perf_tool *tool, union perf_
int perf_event__synthesize_modules(const struct perf_tool *tool, perf_event__handler_t process, struct machine *machine);
int perf_event__synthesize_namespaces(const struct perf_tool *tool, union perf_event *event, pid_t pid, pid_t tgid, perf_event__handler_t process, struct machine *machine);
int perf_event__synthesize_cgroups(const struct perf_tool *tool, perf_event__handler_t process, struct machine *machine);
-int perf_event__synthesize_sample(union perf_event *event, u64 type, u64 read_format, const struct perf_sample *sample);
+int perf_event__synthesize_sample(union perf_event *event, u64 type, u64 read_format,
+ u64 branch_sample_type, const struct perf_sample *sample);
int perf_event__synthesize_stat_config(const struct perf_tool *tool, struct perf_stat_config *config, perf_event__handler_t process, struct machine *machine);
int perf_event__synthesize_stat_events(struct perf_stat_config *config, const struct perf_tool *tool, struct evlist *evlist, perf_event__handler_t process, bool attrs);
int perf_event__synthesize_stat_round(const struct perf_tool *tool, u64 time, u64 type, perf_event__handler_t process, struct machine *machine);
@@ -97,7 +98,8 @@ void perf_event__synthesize_final_bpf_metadata(struct perf_session *session,
int perf_tool__process_synth_event(const struct perf_tool *tool, union perf_event *event, struct machine *machine, perf_event__handler_t process);
-size_t perf_event__sample_event_size(const struct perf_sample *sample, u64 type, u64 read_format);
+size_t perf_event__sample_event_size(const struct perf_sample *sample, u64 type,
+ u64 read_format, u64 branch_sample_type);
int __machine__synthesize_threads(struct machine *machine, const struct perf_tool *tool,
struct target *target, struct perf_thread_map *threads,
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v6 00/59] perf: Reorganize scripting support
From: Ian Rogers @ 2026-04-25 17:47 UTC (permalink / raw)
To: acme, adrian.hunter, james.clark, leo.yan, namhyung, tmricht
Cc: alice.mei.rogers, dapeng1.mi, linux-arm-kernel, linux-kernel,
linux-perf-users, mingo, peterz, Ian Rogers
In-Reply-To: <20260424164721.2229025-1-irogers@google.com>
The perf script command has long supported running Python and Perl scripts by
embedding libpython and libperl. This approach has several drawbacks:
- overhead by creating Python dictionaries for every event (whether used or
not),
- complex build dependencies on specific Python/Perl versions,
- complications with threading due to perf being the interpreter,
- no clear way to run standalone scripts like ilist.py.
This series takes a different approach with some initial implementation posted
as an RFC last October:
https://lore.kernel.org/linux-perf-users/20251029053413.355154-1-irogers@google.com/
with the motivation coming up on the mailing list earlier:
https://lore.kernel.org/lkml/CAP-5=fWDqE8SYfOLZkg_0=4Ayx6E7O+h7uUp4NDeCFkiN4b7-w@mail.gmail.com/
The changes remove the embedded libpython and libperl support from perf
entirely. Instead, they expand the existing perf Python module to provide full
access to perf data files and events, allowing scripts to be run as standalone
Python applications.
To demonstrate the benefits, we ported all existing Python and Perl scripts to
use the new Python session API. The performance improvement is dramatic. For
example, porting mem-phys-addr.py:
Before (using embedded libpython in perf script):
```
$ perf mem record a sleep 1
$ time perf script tools/perf/scripts/python/mem-phys-addr.py
Event: cpu_core/mem-loads-aux/
Memory type count percentage
--------------------------------------- ---------- ----------
0-fff : Reserved 3217 100.0
real 0m3.754s
user 0m0.023s
sys 0m0.018s
```
After (using standalone Python script with perf module):
```
$ PYTHONPATH=/tmp/perf/python time python3 tools/perf/python/mem-phys-addr.py
Event: evsel(cpu_core/mem-loads-aux/)
Memory type count percentage
--------------------------------------- ---------- ----------
0-fff : Reserved 3217 100.0
real 0m0.106s
user 0m0.021s
sys 0m0.020s
```
This is a roughly 35x speedup!
The change is large (11423 insertions, 16029 deletions, net 4606
deletions) due to porting all existing perl and python code to the new
API. Gemini was used to achieve this and to improve the code
quality. Removing support may be controversial, however, the first 52
patches are additive and merging those would allow us to focus on the
remaining 7 patches that finalize the new perf script behavior.
---
v6 Changes
----------
- Refactored `pyrf_event__new` to take `evsel` and `session` arguments,
and use dynamic allocation based on the actual event size to improve
memory safety and efficiency.
- Moved callchain and branch stack resolution logic from
`pyrf_session_tool__sample` into `pyrf_event__new`, centralizing
initialization.
- Added an optional keyword-only `elf_machine` argument to `syscall_name`
and `syscall_id` functions to allow specifying non-host architectures,
defaulting to `EM_HOST`.
- Renamed `process` method to `find_thread` in the Python API and C
implementation for better intention-revealing naming.
- Fixed a terminal injection vulnerability in `flamegraph.py` by not
printing unverified downloaded content in the prompt.
- Fixed CWD exposure and symlink attack risks in `gecko.py` by using a
secure temporary directory for the HTTP server.
- Fixed a severe performance issue in `event_analyzing_sample.py` by
removing SQLite autocommit mode and batching commits.
- Fixed `AttributeError` crashes in `rw-by-file.py` and `rw-by-pid.py` by
correctly extracting event names.
- Fixed man page formatting issues in `perf-script-python.txt` by using
indented code blocks.
- Updated `perf.pyi` stubs file to reflect all API changes.
- Verified all commit messages with `checkpatch.pl` and ensured lines are
wrapped appropriately.
- Fixed segmentation faults in `perf sched stats` in diff mode.
v5 Changes
----------
Resending due to partial send of v4 due to a quota limit.
v4 Changes
----------
1. Git Fixup Cleanups
- Squashed the lingering `fixup!` commit remaining from the previous session back
into `perf check-perf-trace: Port check-perf-trace to use python module`.
v3 Changes
----------
1. Memory Safety & Reference Counting Fixes
- Stored transient mmap event data inside the Python object's permanent
`pevent->event` and invoked `evsel__parse_sample()` to safely point
attributes into it, resolving Use-After-Free vulnerabilities.
- Nullified `sample->evsel` after calling `evsel__put()` in
`perf_sample__exit()` to protect against potential refcount double-put
crashes in error paths.
- Reordered operations inside `evlist__remove()` to invoke
`perf_evlist__remove()` before reference release.
- Patched an `evsel` reference leak inside `evlist__deliver_deferred_callchain()`.
2. Sashiko AI Review Cleanups
- Corrected the broken event name equality check in `gecko.py` to search
for a substring match within the parsed event string.
- Fixed a latent `AttributeError` crash in `task-analyzer.py` by properly
assigning the session instance.
- Safeguarded thread reporting in `check-perf-trace.py` by utilizing
`sample_tid` instead of `sample_pid`, and wrapping the session thread
resolution in a try-except block.
3. Omitted Minor Issues
- The minor review comments (such as permanent iterator exhaustion on
`brstack`, or dead-code in `failed-syscalls-by-pid.py`) have been omitted
because they do not affect correctness, lead to crashes, or require
significant architectural rework.
v2 Changes
----------
1. String Match and Event Name Accuracy
- Replaced loose substring event matching across the script suite with exact
matches or specific prefix constraints (syscalls:sys_exit_,
evsel(skb:kfree_skb), etc.).
- Added getattr() safety checks to prevent script failures caused by
unresolved attributes from older kernel traces.
2. OOM and Memory Protections
- Refactored netdev-times.py to compute and process network statistics
chronologically on-the-fly, eliminating an unbounded in-memory list
that caused Out-Of-Memory crashes on large files.
- Implemented threshold limits on intel-pt-events.py to cap memory allocation
during event interleaving.
- Optimized export-to-sqlite.py to periodically commit database transactions
(every 10,000 samples) to reduce temporary SQLite journal sizes.
3. Portability & Environment Independence
- Re-keyed internal tracking dictionaries in scripts like powerpc-hcalls.py to
use thread PIDs instead of CPUs, ensuring correctness when threads migrate.
- Switched net_dropmonitor.py from host-specific /proc/kallsyms parsing to
perf's built-in symbol resolution API.
- Added the --iomem parameter to mem-phys-addr.py to support offline analysis
of data collected on different architectures.
4. Standalone Scripting Improvements
- Patched builtin-script.c to ensure --input parameters are successfully passed
down to standalone execution pipelines via execvp().
- Guarded against string buffer overflows during .py extension path resolving.
5. Code Cleanups
- Removed stale perl subdirectories from being detected by the TUI script
browser.
- Ran the entire script suite through mypy and pylint to achieve strict static
type checking and resolve unreferenced variables.
Ian Rogers (59):
perf inject: Fix itrace branch stack synthesis
perf arch arm: Sort includes and add missed explicit dependencies
perf arch x86: Sort includes and add missed explicit dependencies
perf tests: Sort includes and add missed explicit dependencies
perf script: Sort includes and add missed explicit dependencies
perf util: Sort includes and add missed explicit dependencies
perf python: Add missed explicit dependencies
perf evsel/evlist: Avoid unnecessary #includes
perf data: Add open flag
perf evlist: Add reference count
perf evsel: Add reference count
perf evlist: Add reference count checking
perf python: Use evsel in sample in pyrf_event
perf python: Add wrapper for perf_data file abstraction
perf python: Add python session abstraction wrapping perf's session
perf python: Add syscall name/id to convert syscall number and name
perf python: Refactor and add accessors to sample event
perf python: Add callchain support
perf python: Add config file access
perf python: Extend API for stat events in python.c
perf python: Expose brstack in sample event
perf python: Add perf.pyi stubs file
perf python: Add LiveSession helper
perf python: Move exported-sql-viewer.py and parallel-perf.py to
tools/perf/python/
perf stat-cpi: Port stat-cpi to use python module
perf mem-phys-addr: Port mem-phys-addr to use python module
perf syscall-counts: Port syscall-counts to use python module
perf syscall-counts-by-pid: Port syscall-counts-by-pid to use python
module
perf futex-contention: Port futex-contention to use python module
perf flamegraph: Port flamegraph to use python module
perf gecko: Port gecko to use python module
perf arm-cs-trace-disasm: Port arm-cs-trace-disasm to use python
module
perf check-perf-trace: Port check-perf-trace to use python module
perf compaction-times: Port compaction-times to use python module
perf event_analyzing_sample: Port event_analyzing_sample to use python
module
perf export-to-sqlite: Port export-to-sqlite to use python module
perf export-to-postgresql: Port export-to-postgresql to use python
module
perf failed-syscalls-by-pid: Port failed-syscalls-by-pid to use python
module
perf intel-pt-events: Port intel-pt-events/libxed to use python module
perf net_dropmonitor: Port net_dropmonitor to use python module
perf netdev-times: Port netdev-times to use python module
perf powerpc-hcalls: Port powerpc-hcalls to use python module
perf sched-migration: Port sched-migration/SchedGui to use python
module
perf sctop: Port sctop to use python module
perf stackcollapse: Port stackcollapse to use python module
perf task-analyzer: Port task-analyzer to use python module
perf failed-syscalls: Port failed-syscalls to use python module
perf rw-by-file: Port rw-by-file to use python module
perf rw-by-pid: Port rw-by-pid to use python module
perf rwtop: Port rwtop to use python module
perf wakeup-latency: Port wakeup-latency to use python module
perf test: Migrate Intel PT virtual LBR test to use Python API
perf: Remove libperl support, legacy Perl scripts and tests
perf: Remove libpython support and legacy Python scripts
perf Makefile: Update Python script installation path
perf script: Refactor to support standalone scripts and remove legacy
features
perf Documentation: Update for standalone Python scripts and remove
obsolete data
perf python: Improve perf script -l descriptions
perf sched stats: Fix segmentation faults in diff mode
tools/build/Makefile.feature | 5 +-
tools/build/feature/Makefile | 23 +-
tools/build/feature/test-all.c | 6 +-
tools/build/feature/test-libperl.c | 10 -
tools/build/feature/test-libpython.c | 10 -
tools/build/feature/test-python-module.c | 12 +
tools/perf/Documentation/perf-check.txt | 2 -
tools/perf/Documentation/perf-script-perl.txt | 216 --
.../perf/Documentation/perf-script-python.txt | 713 +-----
tools/perf/Documentation/perf-script.txt | 70 +-
tools/perf/Makefile.config | 37 +-
tools/perf/Makefile.perf | 22 +-
tools/perf/arch/arm/util/cs-etm.c | 36 +-
tools/perf/arch/arm64/util/arm-spe.c | 8 +-
tools/perf/arch/arm64/util/hisi-ptt.c | 2 +-
tools/perf/arch/x86/tests/hybrid.c | 22 +-
tools/perf/arch/x86/tests/topdown.c | 2 +-
tools/perf/arch/x86/util/auxtrace.c | 2 +-
tools/perf/arch/x86/util/intel-bts.c | 26 +-
tools/perf/arch/x86/util/intel-pt.c | 38 +-
tools/perf/arch/x86/util/iostat.c | 8 +-
tools/perf/bench/evlist-open-close.c | 29 +-
tools/perf/bench/inject-buildid.c | 9 +-
tools/perf/builtin-annotate.c | 2 +-
tools/perf/builtin-check.c | 3 +-
tools/perf/builtin-ftrace.c | 14 +-
tools/perf/builtin-inject.c | 81 +-
tools/perf/builtin-kvm.c | 14 +-
tools/perf/builtin-kwork.c | 8 +-
tools/perf/builtin-lock.c | 2 +-
tools/perf/builtin-record.c | 95 +-
tools/perf/builtin-report.c | 6 +-
tools/perf/builtin-sched.c | 111 +-
tools/perf/builtin-script.c | 895 +++----
tools/perf/builtin-stat.c | 81 +-
tools/perf/builtin-top.c | 104 +-
tools/perf/builtin-trace.c | 60 +-
tools/perf/python/SchedGui.py | 219 ++
tools/perf/python/arm-cs-trace-disasm.py | 338 +++
tools/perf/python/check-perf-trace.py | 113 +
tools/perf/python/compaction-times.py | 326 +++
tools/perf/python/counting.py | 1 +
tools/perf/python/event_analyzing_sample.py | 297 +++
tools/perf/python/export-to-postgresql.py | 701 ++++++
tools/perf/python/export-to-sqlite.py | 372 +++
.../python/exported-sql-viewer.py | 6 +-
tools/perf/python/failed-syscalls-by-pid.py | 119 +
tools/perf/python/failed-syscalls.py | 78 +
tools/perf/python/flamegraph.py | 250 ++
tools/perf/python/futex-contention.py | 87 +
tools/perf/python/gecko.py | 385 +++
tools/perf/python/intel-pt-events.py | 435 ++++
tools/perf/python/libxed.py | 122 +
.../{scripts => }/python/mem-phys-addr.py | 66 +-
tools/perf/python/net_dropmonitor.py | 58 +
tools/perf/python/netdev-times.py | 472 ++++
.../{scripts => }/python/parallel-perf.py | 0
tools/perf/python/perf.pyi | 581 +++++
tools/perf/python/perf_live.py | 48 +
tools/perf/python/powerpc-hcalls.py | 211 ++
tools/perf/python/rw-by-file.py | 103 +
tools/perf/python/rw-by-pid.py | 158 ++
tools/perf/python/rwtop.py | 219 ++
tools/perf/python/sched-migration.py | 469 ++++
tools/perf/python/sctop.py | 186 ++
tools/perf/python/stackcollapse.py | 126 +
tools/perf/python/stat-cpi.py | 151 ++
tools/perf/python/syscall-counts-by-pid.py | 88 +
tools/perf/python/syscall-counts.py | 72 +
tools/perf/python/task-analyzer.py | 547 ++++
tools/perf/python/tracepoint.py | 1 +
tools/perf/python/twatch.py | 1 +
tools/perf/python/wakeup-latency.py | 88 +
tools/perf/scripts/Build | 4 -
tools/perf/scripts/perl/Perf-Trace-Util/Build | 9 -
.../scripts/perl/Perf-Trace-Util/Context.c | 122 -
.../scripts/perl/Perf-Trace-Util/Context.xs | 42 -
.../scripts/perl/Perf-Trace-Util/Makefile.PL | 18 -
.../perf/scripts/perl/Perf-Trace-Util/README | 59 -
.../Perf-Trace-Util/lib/Perf/Trace/Context.pm | 55 -
.../Perf-Trace-Util/lib/Perf/Trace/Core.pm | 192 --
.../Perf-Trace-Util/lib/Perf/Trace/Util.pm | 94 -
.../perf/scripts/perl/Perf-Trace-Util/typemap | 1 -
.../scripts/perl/bin/check-perf-trace-record | 2 -
.../scripts/perl/bin/failed-syscalls-record | 3 -
.../scripts/perl/bin/failed-syscalls-report | 10 -
tools/perf/scripts/perl/bin/rw-by-file-record | 3 -
tools/perf/scripts/perl/bin/rw-by-file-report | 10 -
tools/perf/scripts/perl/bin/rw-by-pid-record | 2 -
tools/perf/scripts/perl/bin/rw-by-pid-report | 3 -
tools/perf/scripts/perl/bin/rwtop-record | 2 -
tools/perf/scripts/perl/bin/rwtop-report | 20 -
.../scripts/perl/bin/wakeup-latency-record | 6 -
.../scripts/perl/bin/wakeup-latency-report | 3 -
tools/perf/scripts/perl/check-perf-trace.pl | 106 -
tools/perf/scripts/perl/failed-syscalls.pl | 47 -
tools/perf/scripts/perl/rw-by-file.pl | 106 -
tools/perf/scripts/perl/rw-by-pid.pl | 184 --
tools/perf/scripts/perl/rwtop.pl | 203 --
tools/perf/scripts/perl/wakeup-latency.pl | 107 -
.../perf/scripts/python/Perf-Trace-Util/Build | 4 -
.../scripts/python/Perf-Trace-Util/Context.c | 225 --
.../Perf-Trace-Util/lib/Perf/Trace/Core.py | 116 -
.../lib/Perf/Trace/EventClass.py | 97 -
.../lib/Perf/Trace/SchedGui.py | 184 --
.../Perf-Trace-Util/lib/Perf/Trace/Util.py | 92 -
.../scripts/python/arm-cs-trace-disasm.py | 355 ---
.../python/bin/compaction-times-record | 2 -
.../python/bin/compaction-times-report | 4 -
.../python/bin/event_analyzing_sample-record | 8 -
.../python/bin/event_analyzing_sample-report | 3 -
.../python/bin/export-to-postgresql-record | 8 -
.../python/bin/export-to-postgresql-report | 29 -
.../python/bin/export-to-sqlite-record | 8 -
.../python/bin/export-to-sqlite-report | 29 -
.../python/bin/failed-syscalls-by-pid-record | 3 -
.../python/bin/failed-syscalls-by-pid-report | 10 -
.../perf/scripts/python/bin/flamegraph-record | 2 -
.../perf/scripts/python/bin/flamegraph-report | 3 -
.../python/bin/futex-contention-record | 2 -
.../python/bin/futex-contention-report | 4 -
tools/perf/scripts/python/bin/gecko-record | 2 -
tools/perf/scripts/python/bin/gecko-report | 7 -
.../scripts/python/bin/intel-pt-events-record | 13 -
.../scripts/python/bin/intel-pt-events-report | 3 -
.../scripts/python/bin/mem-phys-addr-record | 19 -
.../scripts/python/bin/mem-phys-addr-report | 3 -
.../scripts/python/bin/net_dropmonitor-record | 2 -
.../scripts/python/bin/net_dropmonitor-report | 4 -
.../scripts/python/bin/netdev-times-record | 8 -
.../scripts/python/bin/netdev-times-report | 5 -
.../scripts/python/bin/powerpc-hcalls-record | 2 -
.../scripts/python/bin/powerpc-hcalls-report | 2 -
.../scripts/python/bin/sched-migration-record | 2 -
.../scripts/python/bin/sched-migration-report | 3 -
tools/perf/scripts/python/bin/sctop-record | 3 -
tools/perf/scripts/python/bin/sctop-report | 24 -
.../scripts/python/bin/stackcollapse-record | 8 -
.../scripts/python/bin/stackcollapse-report | 3 -
.../python/bin/syscall-counts-by-pid-record | 3 -
.../python/bin/syscall-counts-by-pid-report | 10 -
.../scripts/python/bin/syscall-counts-record | 3 -
.../scripts/python/bin/syscall-counts-report | 10 -
.../scripts/python/bin/task-analyzer-record | 2 -
.../scripts/python/bin/task-analyzer-report | 3 -
tools/perf/scripts/python/check-perf-trace.py | 84 -
tools/perf/scripts/python/compaction-times.py | 311 ---
.../scripts/python/event_analyzing_sample.py | 192 --
.../scripts/python/export-to-postgresql.py | 1114 ---------
tools/perf/scripts/python/export-to-sqlite.py | 799 ------
.../scripts/python/failed-syscalls-by-pid.py | 79 -
tools/perf/scripts/python/flamegraph.py | 267 --
tools/perf/scripts/python/futex-contention.py | 57 -
tools/perf/scripts/python/gecko.py | 395 ---
tools/perf/scripts/python/intel-pt-events.py | 494 ----
tools/perf/scripts/python/libxed.py | 107 -
tools/perf/scripts/python/net_dropmonitor.py | 78 -
tools/perf/scripts/python/netdev-times.py | 473 ----
tools/perf/scripts/python/powerpc-hcalls.py | 202 --
tools/perf/scripts/python/sched-migration.py | 462 ----
tools/perf/scripts/python/sctop.py | 89 -
tools/perf/scripts/python/stackcollapse.py | 127 -
tools/perf/scripts/python/stat-cpi.py | 79 -
.../scripts/python/syscall-counts-by-pid.py | 75 -
tools/perf/scripts/python/syscall-counts.py | 65 -
tools/perf/scripts/python/task-analyzer.py | 934 -------
tools/perf/tests/backward-ring-buffer.c | 26 +-
tools/perf/tests/code-reading.c | 14 +-
tools/perf/tests/dlfilter-test.c | 8 +-
tools/perf/tests/event-times.c | 6 +-
tools/perf/tests/event_update.c | 4 +-
tools/perf/tests/evsel-roundtrip-name.c | 8 +-
tools/perf/tests/evsel-tp-sched.c | 4 +-
tools/perf/tests/expand-cgroup.c | 12 +-
tools/perf/tests/hists_cumulate.c | 2 +-
tools/perf/tests/hists_filter.c | 2 +-
tools/perf/tests/hists_link.c | 2 +-
tools/perf/tests/hists_output.c | 2 +-
tools/perf/tests/hwmon_pmu.c | 21 +-
tools/perf/tests/keep-tracking.c | 10 +-
tools/perf/tests/make | 9 +-
tools/perf/tests/mmap-basic.c | 42 +-
tools/perf/tests/openat-syscall-all-cpus.c | 6 +-
tools/perf/tests/openat-syscall-tp-fields.c | 26 +-
tools/perf/tests/openat-syscall.c | 6 +-
tools/perf/tests/parse-events.c | 139 +-
tools/perf/tests/parse-metric.c | 8 +-
tools/perf/tests/parse-no-sample-id-all.c | 2 +-
tools/perf/tests/perf-record.c | 38 +-
tools/perf/tests/perf-time-to-tsc.c | 12 +-
tools/perf/tests/pfm.c | 12 +-
tools/perf/tests/pmu-events.c | 11 +-
tools/perf/tests/pmu.c | 4 +-
tools/perf/tests/sample-parsing.c | 39 +-
.../perf/tests/shell/lib/perf_brstack_max.py | 43 +
tools/perf/tests/shell/script.sh | 4 +-
tools/perf/tests/shell/script_perl.sh | 102 -
tools/perf/tests/shell/script_python.sh | 113 -
.../tests/shell/test_arm_coresight_disasm.sh | 12 +-
tools/perf/tests/shell/test_intel_pt.sh | 35 +-
tools/perf/tests/shell/test_task_analyzer.sh | 79 +-
tools/perf/tests/sw-clock.c | 20 +-
tools/perf/tests/switch-tracking.c | 10 +-
tools/perf/tests/task-exit.c | 20 +-
tools/perf/tests/time-utils-test.c | 14 +-
tools/perf/tests/tool_pmu.c | 7 +-
tools/perf/tests/topology.c | 4 +-
tools/perf/ui/browsers/annotate.c | 2 +-
tools/perf/ui/browsers/hists.c | 22 +-
tools/perf/ui/browsers/scripts.c | 21 +-
tools/perf/util/Build | 1 -
tools/perf/util/amd-sample-raw.c | 2 +-
tools/perf/util/annotate-data.c | 2 +-
tools/perf/util/annotate.c | 10 +-
tools/perf/util/arm-spe.c | 7 +-
tools/perf/util/auxtrace.c | 14 +-
tools/perf/util/block-info.c | 4 +-
tools/perf/util/bpf_counter.c | 2 +-
tools/perf/util/bpf_counter_cgroup.c | 10 +-
tools/perf/util/bpf_ftrace.c | 9 +-
tools/perf/util/bpf_lock_contention.c | 12 +-
tools/perf/util/bpf_off_cpu.c | 44 +-
tools/perf/util/bpf_trace_augment.c | 8 +-
tools/perf/util/cgroup.c | 26 +-
tools/perf/util/cs-etm.c | 6 +-
tools/perf/util/data-convert-bt.c | 2 +-
tools/perf/util/data.c | 26 +-
tools/perf/util/data.h | 4 +-
tools/perf/util/evlist.c | 487 ++--
tools/perf/util/evlist.h | 273 +-
tools/perf/util/evsel.c | 109 +-
tools/perf/util/evsel.h | 35 +-
tools/perf/util/expr.c | 2 +-
tools/perf/util/header.c | 51 +-
tools/perf/util/header.h | 2 +-
tools/perf/util/intel-bts.c | 3 +-
tools/perf/util/intel-pt.c | 13 +-
tools/perf/util/intel-tpebs.c | 7 +-
tools/perf/util/map.h | 9 +-
tools/perf/util/metricgroup.c | 12 +-
tools/perf/util/parse-events.c | 10 +-
tools/perf/util/parse-events.y | 2 +-
tools/perf/util/perf_api_probe.c | 20 +-
tools/perf/util/pfm.c | 4 +-
tools/perf/util/print-events.c | 2 +-
tools/perf/util/print_insn.h | 5 +-
tools/perf/util/python.c | 1923 ++++++++++++--
tools/perf/util/record.c | 11 +-
tools/perf/util/s390-sample-raw.c | 19 +-
tools/perf/util/sample-raw.c | 4 +-
tools/perf/util/sample.c | 17 +-
tools/perf/util/scripting-engines/Build | 9 -
.../util/scripting-engines/trace-event-perl.c | 773 ------
.../scripting-engines/trace-event-python.c | 2209 -----------------
tools/perf/util/session.c | 59 +-
tools/perf/util/sideband_evlist.c | 40 +-
tools/perf/util/sort.c | 2 +-
tools/perf/util/stat-display.c | 6 +-
tools/perf/util/stat-shadow.c | 24 +-
tools/perf/util/stat.c | 20 +-
tools/perf/util/stream.c | 4 +-
tools/perf/util/synthetic-events.c | 36 +-
tools/perf/util/synthetic-events.h | 6 +-
tools/perf/util/time-utils.c | 12 +-
tools/perf/util/top.c | 4 +-
tools/perf/util/trace-event-parse.c | 65 -
tools/perf/util/trace-event-scripting.c | 410 ---
tools/perf/util/trace-event.h | 75 +-
268 files changed, 11423 insertions(+), 16029 deletions(-)
delete mode 100644 tools/build/feature/test-libperl.c
delete mode 100644 tools/build/feature/test-libpython.c
create mode 100644 tools/build/feature/test-python-module.c
delete mode 100644 tools/perf/Documentation/perf-script-perl.txt
create mode 100755 tools/perf/python/SchedGui.py
create mode 100755 tools/perf/python/arm-cs-trace-disasm.py
create mode 100755 tools/perf/python/check-perf-trace.py
create mode 100755 tools/perf/python/compaction-times.py
create mode 100755 tools/perf/python/event_analyzing_sample.py
create mode 100755 tools/perf/python/export-to-postgresql.py
create mode 100755 tools/perf/python/export-to-sqlite.py
rename tools/perf/{scripts => }/python/exported-sql-viewer.py (99%)
create mode 100755 tools/perf/python/failed-syscalls-by-pid.py
create mode 100755 tools/perf/python/failed-syscalls.py
create mode 100755 tools/perf/python/flamegraph.py
create mode 100755 tools/perf/python/futex-contention.py
create mode 100755 tools/perf/python/gecko.py
create mode 100755 tools/perf/python/intel-pt-events.py
create mode 100755 tools/perf/python/libxed.py
rename tools/perf/{scripts => }/python/mem-phys-addr.py (73%)
mode change 100644 => 100755
create mode 100755 tools/perf/python/net_dropmonitor.py
create mode 100755 tools/perf/python/netdev-times.py
rename tools/perf/{scripts => }/python/parallel-perf.py (100%)
create mode 100644 tools/perf/python/perf.pyi
create mode 100755 tools/perf/python/perf_live.py
create mode 100755 tools/perf/python/powerpc-hcalls.py
create mode 100755 tools/perf/python/rw-by-file.py
create mode 100755 tools/perf/python/rw-by-pid.py
create mode 100755 tools/perf/python/rwtop.py
create mode 100755 tools/perf/python/sched-migration.py
create mode 100755 tools/perf/python/sctop.py
create mode 100755 tools/perf/python/stackcollapse.py
create mode 100755 tools/perf/python/stat-cpi.py
create mode 100755 tools/perf/python/syscall-counts-by-pid.py
create mode 100755 tools/perf/python/syscall-counts.py
create mode 100755 tools/perf/python/task-analyzer.py
create mode 100755 tools/perf/python/wakeup-latency.py
delete mode 100644 tools/perf/scripts/perl/Perf-Trace-Util/Build
delete mode 100644 tools/perf/scripts/perl/Perf-Trace-Util/Context.c
delete mode 100644 tools/perf/scripts/perl/Perf-Trace-Util/Context.xs
delete mode 100644 tools/perf/scripts/perl/Perf-Trace-Util/Makefile.PL
delete mode 100644 tools/perf/scripts/perl/Perf-Trace-Util/README
delete mode 100644 tools/perf/scripts/perl/Perf-Trace-Util/lib/Perf/Trace/Context.pm
delete mode 100644 tools/perf/scripts/perl/Perf-Trace-Util/lib/Perf/Trace/Core.pm
delete mode 100644 tools/perf/scripts/perl/Perf-Trace-Util/lib/Perf/Trace/Util.pm
delete mode 100644 tools/perf/scripts/perl/Perf-Trace-Util/typemap
delete mode 100644 tools/perf/scripts/perl/bin/check-perf-trace-record
delete mode 100644 tools/perf/scripts/perl/bin/failed-syscalls-record
delete mode 100644 tools/perf/scripts/perl/bin/failed-syscalls-report
delete mode 100644 tools/perf/scripts/perl/bin/rw-by-file-record
delete mode 100644 tools/perf/scripts/perl/bin/rw-by-file-report
delete mode 100644 tools/perf/scripts/perl/bin/rw-by-pid-record
delete mode 100644 tools/perf/scripts/perl/bin/rw-by-pid-report
delete mode 100644 tools/perf/scripts/perl/bin/rwtop-record
delete mode 100644 tools/perf/scripts/perl/bin/rwtop-report
delete mode 100644 tools/perf/scripts/perl/bin/wakeup-latency-record
delete mode 100644 tools/perf/scripts/perl/bin/wakeup-latency-report
delete mode 100644 tools/perf/scripts/perl/check-perf-trace.pl
delete mode 100644 tools/perf/scripts/perl/failed-syscalls.pl
delete mode 100644 tools/perf/scripts/perl/rw-by-file.pl
delete mode 100644 tools/perf/scripts/perl/rw-by-pid.pl
delete mode 100644 tools/perf/scripts/perl/rwtop.pl
delete mode 100644 tools/perf/scripts/perl/wakeup-latency.pl
delete mode 100644 tools/perf/scripts/python/Perf-Trace-Util/Build
delete mode 100644 tools/perf/scripts/python/Perf-Trace-Util/Context.c
delete mode 100644 tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Core.py
delete mode 100755 tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
delete mode 100644 tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/SchedGui.py
delete mode 100644 tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py
delete mode 100755 tools/perf/scripts/python/arm-cs-trace-disasm.py
delete mode 100644 tools/perf/scripts/python/bin/compaction-times-record
delete mode 100644 tools/perf/scripts/python/bin/compaction-times-report
delete mode 100644 tools/perf/scripts/python/bin/event_analyzing_sample-record
delete mode 100644 tools/perf/scripts/python/bin/event_analyzing_sample-report
delete mode 100644 tools/perf/scripts/python/bin/export-to-postgresql-record
delete mode 100644 tools/perf/scripts/python/bin/export-to-postgresql-report
delete mode 100644 tools/perf/scripts/python/bin/export-to-sqlite-record
delete mode 100644 tools/perf/scripts/python/bin/export-to-sqlite-report
delete mode 100644 tools/perf/scripts/python/bin/failed-syscalls-by-pid-record
delete mode 100644 tools/perf/scripts/python/bin/failed-syscalls-by-pid-report
delete mode 100755 tools/perf/scripts/python/bin/flamegraph-record
delete mode 100755 tools/perf/scripts/python/bin/flamegraph-report
delete mode 100644 tools/perf/scripts/python/bin/futex-contention-record
delete mode 100644 tools/perf/scripts/python/bin/futex-contention-report
delete mode 100644 tools/perf/scripts/python/bin/gecko-record
delete mode 100755 tools/perf/scripts/python/bin/gecko-report
delete mode 100644 tools/perf/scripts/python/bin/intel-pt-events-record
delete mode 100644 tools/perf/scripts/python/bin/intel-pt-events-report
delete mode 100644 tools/perf/scripts/python/bin/mem-phys-addr-record
delete mode 100644 tools/perf/scripts/python/bin/mem-phys-addr-report
delete mode 100755 tools/perf/scripts/python/bin/net_dropmonitor-record
delete mode 100755 tools/perf/scripts/python/bin/net_dropmonitor-report
delete mode 100644 tools/perf/scripts/python/bin/netdev-times-record
delete mode 100644 tools/perf/scripts/python/bin/netdev-times-report
delete mode 100644 tools/perf/scripts/python/bin/powerpc-hcalls-record
delete mode 100644 tools/perf/scripts/python/bin/powerpc-hcalls-report
delete mode 100644 tools/perf/scripts/python/bin/sched-migration-record
delete mode 100644 tools/perf/scripts/python/bin/sched-migration-report
delete mode 100644 tools/perf/scripts/python/bin/sctop-record
delete mode 100644 tools/perf/scripts/python/bin/sctop-report
delete mode 100755 tools/perf/scripts/python/bin/stackcollapse-record
delete mode 100755 tools/perf/scripts/python/bin/stackcollapse-report
delete mode 100644 tools/perf/scripts/python/bin/syscall-counts-by-pid-record
delete mode 100644 tools/perf/scripts/python/bin/syscall-counts-by-pid-report
delete mode 100644 tools/perf/scripts/python/bin/syscall-counts-record
delete mode 100644 tools/perf/scripts/python/bin/syscall-counts-report
delete mode 100755 tools/perf/scripts/python/bin/task-analyzer-record
delete mode 100755 tools/perf/scripts/python/bin/task-analyzer-report
delete mode 100644 tools/perf/scripts/python/check-perf-trace.py
delete mode 100644 tools/perf/scripts/python/compaction-times.py
delete mode 100644 tools/perf/scripts/python/event_analyzing_sample.py
delete mode 100644 tools/perf/scripts/python/export-to-postgresql.py
delete mode 100644 tools/perf/scripts/python/export-to-sqlite.py
delete mode 100644 tools/perf/scripts/python/failed-syscalls-by-pid.py
delete mode 100755 tools/perf/scripts/python/flamegraph.py
delete mode 100644 tools/perf/scripts/python/futex-contention.py
delete mode 100644 tools/perf/scripts/python/gecko.py
delete mode 100644 tools/perf/scripts/python/intel-pt-events.py
delete mode 100644 tools/perf/scripts/python/libxed.py
delete mode 100755 tools/perf/scripts/python/net_dropmonitor.py
delete mode 100644 tools/perf/scripts/python/netdev-times.py
delete mode 100644 tools/perf/scripts/python/powerpc-hcalls.py
delete mode 100644 tools/perf/scripts/python/sched-migration.py
delete mode 100644 tools/perf/scripts/python/sctop.py
delete mode 100755 tools/perf/scripts/python/stackcollapse.py
delete mode 100644 tools/perf/scripts/python/stat-cpi.py
delete mode 100644 tools/perf/scripts/python/syscall-counts-by-pid.py
delete mode 100644 tools/perf/scripts/python/syscall-counts.py
delete mode 100755 tools/perf/scripts/python/task-analyzer.py
create mode 100644 tools/perf/tests/shell/lib/perf_brstack_max.py
delete mode 100755 tools/perf/tests/shell/script_perl.sh
delete mode 100755 tools/perf/tests/shell/script_python.sh
delete mode 100644 tools/perf/util/scripting-engines/Build
delete mode 100644 tools/perf/util/scripting-engines/trace-event-perl.c
delete mode 100644 tools/perf/util/scripting-engines/trace-event-python.c
delete mode 100644 tools/perf/util/trace-event-scripting.c
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox