* Re: [PATCH v2 05/12] drm/bridge: synopsys: dw-dp: Add follow-up bridge support
From: Luca Ceresoli @ 2026-05-19 11:08 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Airlie,
Simona Vetter, Dmitry Baryshkov, Luca Ceresoli,
Cristian Ciocaltea, Damon Ding, Dmitry Baryshkov, Alexey Charkov,
dri-devel, linux-rockchip, linux-kernel, devicetree, kernel,
linux-arm-kernel
In-Reply-To: <20260501-synopsys-dw-dp-improvements-v2-5-d7e7f6bac77f@collabora.com>
On Fri, 01 May 2026 00:20:32 +0200, Sebastian Reichel <sebastian.reichel@collabora.com> wrote:
Hello Sebastian,
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> index fc4ddb7792d7..ccc55e40e81c 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> @@ -2064,6 +2064,20 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
> goto unregister_aux;
> }
>
> + next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
devm_drm_of_get_bridge() looks for either a panel or a bridge. Is it
possible to have a panel connected here?
If it isn't, then using of_drm_get_bridge_by_endpoint() which has just been
merged [0] would be much simpler and cleaner.
[0] https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/03d1078112fddd706b2c1e4a7d98cf18700eb5df
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: Will Deacon @ 2026-05-19 11:11 UTC (permalink / raw)
To: David Woodhouse
Cc: Paolo Bonzini, Marc Zyngier, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <3f9d731c3d26b0367600f1069e6425099bc34eac.camel@infradead.org>
On Tue, May 19, 2026 at 11:41:26AM +0100, David Woodhouse wrote:
> On Wed, 2026-05-13 at 18:24 +0200, Paolo Bonzini wrote:
> >
> > > See commit https://git.kernel.org/torvalds/c/49a1a2c70a7f which adds a
> > > new guest-visible feature in revision 3, but allowed userspace to
> > > restore the old behaviour by setting it to revision 2. All my patch
> > > above does, is make it possible to set it to revision 1 as
> > > well. Because https://git.kernel.org/torvalds/c/d53c2c29ae0d previously
> > > changed the behaviour and bumped the default to 2 *without* allowing
> > > userspace to restore the prior behaviour, and we've been carrying a
> > > *revert* of that patch.
> > >
> > > Why would we *not* accept such a patch?
> >
> > Agreed. Even ignoring your revert, there's no reason why any upgrade
> > past 49a1a2c70a7f has to be from after d53c2c29ae0d.
>
> So where do we go from here?
>
> I assume you'll be taking this Documentation patch via the KVM tree?
>
> But what about the actual fix at
> https://lore.kernel.org/all/20260511113558.3325004-2-dwmw2@infradead.org/
>
> This is a simple and unintrusive bug fix to make KVM/arm64 follow the
> "common sense" requirement that the doc patch codifies, apparently
> being rejected with the rather bizarre claim that KVM has no *need* to
> maintain guest-visible compatibility across host kernel changes.
>
> So... what next? Is one of the other KVM/arm64 maintainers going to
> speak up? Paolo would you consider taking the fixes through your tree
> directly?
>
> Does Arm not actually *care* whether AArch64 is considered a stable and
> mature platform for KVM hosting?
Hey, come on. Marc cares more about this stuff than anybody else on the
planet. He's been single-handedly maintaining the tree for the past
couple of releases while Oliver was out and he's on the end of a _lot_
of patches. I'm only cc'd on a fraction of the KVM/arm64 changes and
it's bedlam.
Will
^ permalink raw reply
* Re: [PATCH v9 1/7] pinctrl: s32cc: use dev_err_probe() and improve error messages
From: Enric Balletbo i Serra @ 2026-05-19 11:12 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chester Lin, Matthias Brugger,
Ghennadi Procopciuc, Larisa Grigore, Lee Jones, Shawn Guo,
Sascha Hauer, Fabio Estevam, Dong Aisheng, Jacky Bai,
Greg Kroah-Hartman, Rafael J. Wysocki, Srinivas Kandagatla,
Alberto Ruiz, Christophe Lizzi, devicetree, Eric Chanudet, imx,
linux-arm-kernel, linux-gpio, linux-kernel, NXP S32 Linux Team,
Pengutronix Kernel Team, Vincent Guittot
In-Reply-To: <20260504131148.3622697-2-khristineandreea.barbulescu@oss.nxp.com>
Hi,
On Mon, May 4, 2026 at 3:12 PM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
>
> Change dev_err&return statements into dev_err_probe throughout the driver
> on the probing path.
>
> Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
> drivers/pinctrl/nxp/pinctrl-s32cc.c | 64 ++++++++++++++---------------
> 1 file changed, 30 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/pinctrl/nxp/pinctrl-s32cc.c b/drivers/pinctrl/nxp/pinctrl-s32cc.c
> index fe7cd641fddd..56be6e8d624e 100644
> --- a/drivers/pinctrl/nxp/pinctrl-s32cc.c
> +++ b/drivers/pinctrl/nxp/pinctrl-s32cc.c
> @@ -2,7 +2,7 @@
> /*
> * Core driver for the S32 CC (Common Chassis) pin controller
> *
> - * Copyright 2017-2022,2024 NXP
> + * Copyright 2017-2022,2024-2025 NXP
> * Copyright (C) 2022 SUSE LLC
> * Copyright 2015-2016 Freescale Semiconductor, Inc.
> */
> @@ -236,10 +236,10 @@ static int s32_dt_group_node_to_map(struct pinctrl_dev *pctldev,
> }
>
> ret = pinconf_generic_parse_dt_config(np, pctldev, &cfgs, &n_cfgs);
> - if (ret) {
> - dev_err(dev, "%pOF: could not parse node property\n", np);
> - return ret;
> - }
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "%pOF: could not parse node property\n",
> + np);
>
Nitpick: I think this is not part of the probe path but is called when
a consumer requests a pin group, so using dev_err_probe is slightly
misleading here, although I think it's harmless.
In any case, with or without that change it looks good to me, so
Reviewed-by: Enric Balletbo i Serra <eballetb@redhat.com>
> if (n_cfgs)
> reserve++;
> @@ -763,15 +763,15 @@ static int s32_pinctrl_parse_groups(struct device_node *np,
> grp->data.name = np->name;
>
> npins = of_property_count_elems_of_size(np, "pinmux", sizeof(u32));
> - if (npins < 0) {
> - dev_err(dev, "Failed to read 'pinmux' property in node %s.\n",
> - grp->data.name);
> - return -EINVAL;
> - }
> - if (!npins) {
> - dev_err(dev, "The group %s has no pins.\n", grp->data.name);
> - return -EINVAL;
> - }
> + if (npins < 0)
> + return dev_err_probe(dev, -EINVAL,
> + "Failed to read 'pinmux' in node %s\n",
> + grp->data.name);
> +
> + if (!npins)
> + return dev_err_probe(dev, -EINVAL,
> + "The group %s has no pins\n",
> + grp->data.name);
>
> grp->data.npins = npins;
>
> @@ -812,10 +812,9 @@ static int s32_pinctrl_parse_functions(struct device_node *np,
> /* Initialise function */
> func->name = np->name;
> func->ngroups = of_get_child_count(np);
> - if (func->ngroups == 0) {
> - dev_err(info->dev, "no groups defined in %pOF\n", np);
> - return -EINVAL;
> - }
> + if (func->ngroups == 0)
> + return dev_err_probe(info->dev, -EINVAL,
> + "No groups defined in %pOF\n", np);
>
> groups = devm_kcalloc(info->dev, func->ngroups,
> sizeof(*func->groups), GFP_KERNEL);
> @@ -886,10 +885,9 @@ static int s32_pinctrl_probe_dt(struct platform_device *pdev,
> }
>
> nfuncs = of_get_child_count(np);
> - if (nfuncs <= 0) {
> - dev_err(&pdev->dev, "no functions defined\n");
> - return -EINVAL;
> - }
> + if (nfuncs <= 0)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "No functions defined\n");
>
> info->nfunctions = nfuncs;
> info->functions = devm_kcalloc(&pdev->dev, nfuncs,
> @@ -919,18 +917,17 @@ static int s32_pinctrl_probe_dt(struct platform_device *pdev,
> int s32_pinctrl_probe(struct platform_device *pdev,
> const struct s32_pinctrl_soc_data *soc_data)
> {
> - struct s32_pinctrl *ipctl;
> - int ret;
> - struct pinctrl_desc *s32_pinctrl_desc;
> - struct s32_pinctrl_soc_info *info;
> #ifdef CONFIG_PM_SLEEP
> struct s32_pinctrl_context *saved_context;
> #endif
> + struct pinctrl_desc *s32_pinctrl_desc;
> + struct s32_pinctrl_soc_info *info;
> + struct s32_pinctrl *ipctl;
> + int ret;
>
> - if (!soc_data || !soc_data->pins || !soc_data->npins) {
> - dev_err(&pdev->dev, "wrong pinctrl info\n");
> - return -EINVAL;
> - }
> + if (!soc_data || !soc_data->pins || !soc_data->npins)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "Wrong pinctrl info\n");
>
> info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
> if (!info)
> @@ -965,10 +962,9 @@ int s32_pinctrl_probe(struct platform_device *pdev,
> s32_pinctrl_desc->owner = THIS_MODULE;
>
> ret = s32_pinctrl_probe_dt(pdev, ipctl);
> - if (ret) {
> - dev_err(&pdev->dev, "fail to probe dt properties\n");
> - return ret;
> - }
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "Fail to probe dt properties\n");
>
> ipctl->pctl = devm_pinctrl_register(&pdev->dev, s32_pinctrl_desc,
> ipctl);
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH 0/5] arm64: dts: imx91-11x11-evk/imx91-9x9-qsb: misc cleanups and improvements
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
Remove unused clock-frequency property from mdio node for i.MX91 QSB.
Add watchdog pinctrl configuration for i.MX91 EVK and QSB to support
external reset output.
Add Ethernet PHY reset GPIO configuration for i.MX91 EVK and QSB to
ensure proper PHY initialization.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
Joy Zou (5):
arm64: dts: imx91-9x9-qsb: remove unused property clock-frequency from mdio node
arm64: dts: imx91-9x9-qsb: add pinctrl for wdog3 reset
arm64: dts: imx91-11x11-evk: add pinctrl for wdog3 reset
arm64: dts: imx91-11x11-evk: add reset gpios for ethernet PHYs
arm64: dts: imx91-9x9-qsb: add reset gpios for ethernet PHYs
arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts | 14 ++++++++++++++
arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts | 12 +++++++++++-
2 files changed, 25 insertions(+), 1 deletion(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260519-b4-imx91-qsb-opt-583b781ee250
Best regards,
--
Joy Zou <joy.zou@nxp.com>
^ permalink raw reply
* [PATCH 1/5] arm64: dts: imx91-9x9-qsb: remove unused property clock-frequency from mdio node
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com>
The clock-frequency property is not implemented. Remove it to clean up the
device tree.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
index 1239bbf579da44ab3f4be2dc566c53a1e5db6c05..9cbfe57be2d3c37208611dfba5acd428f0b58c3e 100644
--- a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
@@ -79,7 +79,6 @@ mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <1>;
#size-cells = <0>;
- clock-frequency = <5000000>;
ethphy1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.37.1
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: imx91-9x9-qsb: add pinctrl for wdog3 reset
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com>
The wdog3 node enables fsl,ext-reset-output to assert an external
reset signal upon watchdog timeout, but lacks pinctrl configuration
for the physical pad.
Without proper pinctrl settings, which could cause the watchdog timeout
to fail to reset the board hardware.
Add pinctrl configuration to ensure the pin is properly muxed and
configured for external watchdog reset functionality.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
index 9cbfe57be2d3c37208611dfba5acd428f0b58c3e..62549a6de1b64496ffa5cf3f543145a00dbb10a8 100644
--- a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
@@ -230,6 +230,12 @@ MX91_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe
MX91_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX91_PAD_WDOG_ANY__WDOG1_WDOG_ANY 0x31e
+ >;
+ };
};
&lpi2c1 {
@@ -419,6 +425,8 @@ &usdhc2 {
};
&wdog3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
fsl,ext-reset-output;
status = "okay";
};
--
2.37.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: imx91-11x11-evk: add pinctrl for wdog3 reset
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com>
The wdog3 node enables fsl,ext-reset-output to assert an external
reset signal upon watchdog timeout, but lacks pinctrl configuration
for the physical pad.
Without proper pinctrl settings, which could cause the watchdog timeout
to fail to reset the board hardware.
Add pinctrl configuration to ensure the pin is properly muxed and
configured for external watchdog reset functionality.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
index de524f1921de808ee29895852fcbea37565a7e07..3fbdcb87a2f3acf44c15b98d7b6ee212fb62699f 100644
--- a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
@@ -586,6 +586,8 @@ &usdhc3 {
};
&wdog3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
fsl,ext-reset-output;
status = "okay";
};
@@ -947,4 +949,10 @@ MX91_PAD_SD3_DATA2__GPIO3_IO24 0x31e
MX91_PAD_SD3_DATA3__GPIO3_IO25 0x31e
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX91_PAD_WDOG_ANY__WDOG1_WDOG_ANY 0x31e
+ >;
+ };
};
--
2.37.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: imx91-11x11-evk: add reset gpios for ethernet PHYs
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com>
Both the PHYs of the EQOS interface and the FEC interface are supported
to be reset by I2C GPIO expander. So add the support to reset PHYs.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
index 3fbdcb87a2f3acf44c15b98d7b6ee212fb62699f..5716febb5a50f67b7b57a3cc856410857325c206 100644
--- a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
@@ -198,6 +198,9 @@ mdio {
ethphy1: ethernet-phy@1 {
reg = <1>;
+ reset-gpios = <&pcal6524 15 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
realtek,clkout-disable;
};
};
@@ -219,6 +222,9 @@ mdio {
ethphy2: ethernet-phy@2 {
reg = <2>;
+ reset-gpios = <&pcal6524 16 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
realtek,clkout-disable;
};
};
--
2.37.1
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: imx91-9x9-qsb: add reset gpios for ethernet PHYs
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com>
The PHYs of the EQOS interface is supported to be reset by I2C GPIO
expander. So add the support to reset PHYs.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
index 62549a6de1b64496ffa5cf3f543145a00dbb10a8..ea8cf14e0bc6ac434eb1e1a6aad82d9007653eb6 100644
--- a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
@@ -83,6 +83,9 @@ mdio {
ethphy1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
+ reset-gpios = <&pcal6524 15 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
realtek,clkout-disable;
};
};
--
2.37.1
^ permalink raw reply related
* Re: [PATCH v6 8/9] sframe: Initialize debug info for kernel sections
From: Jens Remus @ 2026-05-19 11:20 UTC (permalink / raw)
To: Dylan Hatch
Cc: Prasanna Kumar T S M, Puranjay Mohan, Song Liu, joe.lawrence,
linux-toolchains, linux-kernel, live-patching, linux-arm-kernel,
Randy Dunlap, Mostafa Saleh, Herbert Xu, David S. Miller,
Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Mark Rutland
In-Reply-To: <20260519064950.493949-9-dylanbhatch@google.com>
On 5/19/2026 8:49 AM, Dylan Hatch wrote:
> Setup the optional unwinder debug information for kernel .sframe
> sections. Modules are indicated by the format "(<module-name>)".
>
> Suggested-by: Jens Remus <jremus@linux.ibm.com>
> Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
> ---
> kernel/unwind/sframe.c | 4 ++++
> kernel/unwind/sframe_debug.h | 13 +++++++++++++
> 2 files changed, 17 insertions(+)
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [Linaro-mm-sig] Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Boris Brezillon @ 2026-05-19 11:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chia-I Wu, Liviu Dudau, Marcin Ślusarz, Ketil Johnsen,
David Airlie, Simona Vetter, Maarten Lankhorst, Thomas Zimmermann,
Jonathan Corbet, Shuah Khan, Sumit Semwal, Benjamin Gaignard,
Brian Starkey, John Stultz, T.J. Mercier, Christian König,
Steven Price, Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek,
Florent Tomasin, nd
In-Reply-To: <20260519-loutish-beautiful-trogon-67453f@houat>
On Tue, 19 May 2026 11:52:13 +0200
Maxime Ripard <mripard@kernel.org> wrote:
> Hi Boris,
>
> On Mon, May 18, 2026 at 09:16:50AM +0200, Boris Brezillon wrote:
> > On Wed, 13 May 2026 12:31:32 -0700
> > Chia-I Wu <olvaffe@gmail.com> wrote:
> >
> > > On Tue, May 12, 2026 at 8:39 AM Liviu Dudau <liviu.dudau@arm.com> wrote:
> > > >
> > > > On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote:
> > > > > On Tue, 12 May 2026 14:47:27 +0100
> > > > > Liviu Dudau <liviu.dudau@arm.com> wrote:
> > > > >
> > > > > > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > > > > > > On Thu, 7 May 2026 11:02:26 +0200
> > > > > > > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> > > > > > >
> > > > > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > > > > > > return ret;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > > > > > > >
> > > > > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > > > > > > name is "" already?
> > > > > > > >
> > > > > > > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > > > > > > This check prevents that.
> > > > > > >
> > > > > > > Yeah, that's also a questionable design choice. I mean, we can
> > > > > > > currently probe and boot the FW even though we never setup the
> > > > > > > protected FW sections, so why should we defer the probe here? Can't we
> > > > > > > just retry the next time a group with the protected bit is created and
> > > > > > > fail if we can find a protected heap?
> > > > > >
> > > > > > The problem we have with the current firmware is that it does a number of setup steps at "boot"
> > > > > > time only. One of the steps is preparing its internal structures for when it enters protected
> > > > > > mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> > > > > > process when we have a group with protected mode set.
> > > > >
> > > > > No, but we can force a full/slow reset and have that thing
> > > > > re-initialized, can't we? I mean, that's basically what we do when a
> > > > > fast reset fails: we re-initialize all the sections and reset again, at
> > > > > which point the FW should start from a fresh state, and be able to
> > > > > properly initialize the protected-related stuff if protected sections
> > > > > are populated. Am I missing something?
> > > >
> > > > Right, we can do that. For some reason I keep associating the reset with the
> > > > error handling and not with "normal" operations.
> > > I kind of hope we end up with either
> > >
> > > - panthor knows the exact heap to use and fails with EPROBE_DEFER if
> > > the heap is missing, or
> > > - panthor gets a dma-buf from userspace and does the full reset
> > > - userspace also needs to provide a dma-buf for each protected
> > > group for the suspend buffer
> > >
> > > than something in-between. The latter is more ad-hoc and basically
> > > kicks the issue to the userspace.
> >
> > Indeed, the second option is more ad-hoc, but when you think about it,
> > userspace has to have this knowledge, because it needs to know the
> > dma-heap to use for buffer allocation that cross a device boundary
> > anyway. Think about frames produced by a video decoder, and composited
> > by the GPU into a protected scanout buffer that's passed to the KMS
> > device. Why would the GPU driver be source of truth when it comes to
> > choosing the heap to use to allocate protected buffers for the video
> > decoder or those used for the display?
>
> Just fyi, the trend is to go to devices listing the heaps userspace
> should allocate from
Devices listing the heaps they are able to import buffers from
(with the list being different based on the buffer properties, I
guess) is a good thing. This way the central allocator is in a position
where it can intersect the devices lists and decide which heap to
allocate from based on its buffer sharing knowledge.
> and/or using the heaps internally to allocate their
> buffers,
Yes, that too. For internal buffers (especially the device-wide ones,
like the protected FW sections we were discussing), it makes sense to
leave that up to the driver.
> so that last part is where we're headed, and feels totally
> reasonable to me.
Just to be clear, my main concern right now is not the long term plan,
but how realistic it is to assume we'll have all the DT/dma_heap pieces
in place in a reasonable amount of time. Looking at the current state
of affairs (based on this patchset), it feels like we're a long way
till we can have a robust way of exposing dma_heaps to in-kernel users
(refcounting, lifetime issues, describing allowed heaps, ensuring heaps
truly provide buffers with the expected properties, ...). I'm certainly
not saying these are not valid concerns, but I'd like to have a
temporary solution to support protected rendering in the meantime...
>
> Maxime
^ permalink raw reply
* [PATCH v3 0/4] devfreq: Add refcounts for governor modules
From: Jie Zhan @ 2026-05-19 11:32 UTC (permalink / raw)
To: cwchoi00, cw00.choi, myungjoo.ham, kyungmin.park, linux-pm,
linux-arm-kernel
Cc: linuxarm, tianyaxiong, zhanjie9, zhenglifeng1, zhangpengjie2,
lihuisong, prime.zeng
A governor module can be dynamically inserted or removed if compiled as a
kernel module. 'devfreq->governor' would become NULL if the governor
module is removed when it's in use.
For user-friendliness, get and put the module refcount of a governor module
when it's in use. As a result, unloading a governor module in use returns
an error, e.g.:
$ cat governor
performance
$ rmmod governor_performance
rmmod: ERROR: Module governor_performance is in use
Note that this can't stop force unload, so it's more of a
user-friendliness improvement rather than strict protection. The
existing code that keeps devfreq working when 'devfreq->governor' is
NULL should still be there.
Patch 1-3 clean up mutex with guards and factor out a common governor
setting function, so as to prepare for implementing governor reference
counting. They can be applied separately.
Patch 4 adds the reference counting mechanism for devfreq governor
modules.
Changelog
v3:
- Rework patch 4 to make the 'owner' field assignment optional in the
governor code. This prevents device-driver-bundled governors (such as
those in hisi_uncore_freq and tegra30-devfreq) from causing
self-reference issues that block module removal. Additionally, merge
patches 4 and 5 to clearly present the new 'owner' member alongside
its usage.
- Drop patch 6 because it's no longer needed since v2.
- Update commit logs of patch 3 and 4 to clarify background and
motivation.
- Pick up 2 tags from Yaxiong (thanks!).
- Trivial cleanups.
v2:
https://lore.kernel.org/all/20260513093832.1645890-1-zhanjie9@hisilicon.com/
- Rebase on devfreq-next of 7.1-rc1.
- Drop the patches related to the NULL pointer deference issue of
'devfreq->governor', which has been solved and merged recently.
- Remove the dedicated mutex for 'devfreq_governor_list' because the
refcount changes don't depend on that.
- Some minor cleanups and fixes.
v1:
https://lore.kernel.org/all/20260326123428.800407-1-zhanjie9@hisilicon.com/
Jie Zhan (4):
devfreq: Use mutex guard in governor_store()
devfreq: Use mutex guard in devfreq_add/remove_governor()
devfreq: Factor out devfreq_set_governor()
devfreq: Refcount governor modules while in use
drivers/devfreq/devfreq.c | 174 +++++++++++-----------
drivers/devfreq/governor_passive.c | 1 +
drivers/devfreq/governor_performance.c | 1 +
drivers/devfreq/governor_powersave.c | 1 +
drivers/devfreq/governor_simpleondemand.c | 1 +
drivers/devfreq/governor_userspace.c | 1 +
include/linux/devfreq-governor.h | 11 ++
7 files changed, 101 insertions(+), 89 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v3 4/4] devfreq: Refcount governor modules while in use
From: Jie Zhan @ 2026-05-19 11:32 UTC (permalink / raw)
To: cwchoi00, cw00.choi, myungjoo.ham, kyungmin.park, linux-pm,
linux-arm-kernel
Cc: linuxarm, tianyaxiong, zhanjie9, zhenglifeng1, zhangpengjie2,
lihuisong, prime.zeng
In-Reply-To: <20260519113251.3745140-1-zhanjie9@hisilicon.com>
A governor module can be inserted or removed dynamically when built as a
kernel module. 'devfreq->governor' would become NULL if the governor
module is removed when it's in use.
Add a refcount mechanism for governor modules to prevent the governor
module from being removed (except for force unload):
1. Add an optional 'owner' member to struct devfreq_governor so the devfreq
core can identify the module that holds the governor code.
2. Get and put a refcount of the governor module when starting and stopping
the governor.
The new 'owner' field is optional:
- Common governor modules (performance, powersave, simple_ondemand,
userspace, passive) set 'owner' to THIS_MODULE.
- Governors that are bundled into a device driver module must leave 'owner'
NULL. The device's lifetime already pins that module, and setting
'owner' would create a self-reference that blocks the driver from being
unloaded.
As a result, a non-forced rmmod of an in-use stand-alone governor now
fails with -EBUSY, e.g.:
$ cat governor
performance
$ rmmod governor_performance
rmmod: ERROR: Module governor_performance is in use
Force unloads (rmmod -f, if configured) can't be blocked.
Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
---
drivers/devfreq/devfreq.c | 17 ++++++++++++++++-
drivers/devfreq/governor_passive.c | 1 +
drivers/devfreq/governor_performance.c | 1 +
drivers/devfreq/governor_powersave.c | 1 +
drivers/devfreq/governor_simpleondemand.c | 1 +
drivers/devfreq/governor_userspace.c | 1 +
include/linux/devfreq-governor.h | 11 +++++++++++
7 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 9e3e6a7348f8..1cee43636ded 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -345,24 +345,37 @@ static int devfreq_set_governor(struct devfreq *df,
__func__, df->governor->name, ret);
return ret;
}
+ module_put(old_gov->owner);
}
/* Start the new governor */
+ if (!try_module_get(new_gov->owner)) {
+ df->governor = NULL;
+ return -EINVAL;
+ }
+
df->governor = new_gov;
ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
if (ret) {
dev_warn(dev, "%s: Governor %s not started(%d)\n",
__func__, df->governor->name, ret);
+ module_put(new_gov->owner);
/* Restore previous governor */
df->governor = old_gov;
if (!df->governor)
return ret;
+ if (!try_module_get(old_gov->owner)) {
+ df->governor = NULL;
+ return -EINVAL;
+ }
+
ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
if (ret) {
dev_err(dev, "%s: restore Governor %s failed (%d)\n",
__func__, df->governor->name, ret);
+ module_put(old_gov->owner);
df->governor = NULL;
return ret;
}
@@ -1040,9 +1053,11 @@ int devfreq_remove_device(struct devfreq *devfreq)
devfreq_cooling_unregister(devfreq->cdev);
- if (devfreq->governor)
+ if (devfreq->governor) {
devfreq->governor->event_handler(devfreq,
DEVFREQ_GOV_STOP, NULL);
+ module_put(devfreq->governor->owner);
+ }
device_unregister(&devfreq->dev);
return 0;
diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
index d7feecd900f1..3e63dd200a04 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -449,6 +449,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
static struct devfreq_governor devfreq_passive = {
.name = DEVFREQ_GOV_PASSIVE,
.flags = DEVFREQ_GOV_FLAG_IMMUTABLE,
+ .owner = THIS_MODULE,
.get_target_freq = devfreq_passive_get_target_freq,
.event_handler = devfreq_passive_event_handler,
};
diff --git a/drivers/devfreq/governor_performance.c b/drivers/devfreq/governor_performance.c
index fdb22bf512cf..0a08b067ea6b 100644
--- a/drivers/devfreq/governor_performance.c
+++ b/drivers/devfreq/governor_performance.c
@@ -37,6 +37,7 @@ static int devfreq_performance_handler(struct devfreq *devfreq,
static struct devfreq_governor devfreq_performance = {
.name = DEVFREQ_GOV_PERFORMANCE,
+ .owner = THIS_MODULE,
.get_target_freq = devfreq_performance_func,
.event_handler = devfreq_performance_handler,
};
diff --git a/drivers/devfreq/governor_powersave.c b/drivers/devfreq/governor_powersave.c
index ee2d6ec8a512..3ae296d55e3e 100644
--- a/drivers/devfreq/governor_powersave.c
+++ b/drivers/devfreq/governor_powersave.c
@@ -37,6 +37,7 @@ static int devfreq_powersave_handler(struct devfreq *devfreq,
static struct devfreq_governor devfreq_powersave = {
.name = DEVFREQ_GOV_POWERSAVE,
+ .owner = THIS_MODULE,
.get_target_freq = devfreq_powersave_func,
.event_handler = devfreq_powersave_handler,
};
diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
index ac9c5e9e51a4..46287b279ded 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -119,6 +119,7 @@ static struct devfreq_governor devfreq_simple_ondemand = {
.name = DEVFREQ_GOV_SIMPLE_ONDEMAND,
.attrs = DEVFREQ_GOV_ATTR_POLLING_INTERVAL
| DEVFREQ_GOV_ATTR_TIMER,
+ .owner = THIS_MODULE,
.get_target_freq = devfreq_simple_ondemand_func,
.event_handler = devfreq_simple_ondemand_handler,
};
diff --git a/drivers/devfreq/governor_userspace.c b/drivers/devfreq/governor_userspace.c
index 3906ebedbae8..b1acccc79f7f 100644
--- a/drivers/devfreq/governor_userspace.c
+++ b/drivers/devfreq/governor_userspace.c
@@ -135,6 +135,7 @@ static int devfreq_userspace_handler(struct devfreq *devfreq,
static struct devfreq_governor devfreq_userspace = {
.name = DEVFREQ_GOV_USERSPACE,
+ .owner = THIS_MODULE,
.get_target_freq = devfreq_userspace_func,
.event_handler = devfreq_userspace_handler,
};
diff --git a/include/linux/devfreq-governor.h b/include/linux/devfreq-governor.h
index dfdd0160a29f..ae1721e58401 100644
--- a/include/linux/devfreq-governor.h
+++ b/include/linux/devfreq-governor.h
@@ -12,6 +12,7 @@
#define __LINUX_DEVFREQ_DEVFREQ_H__
#include <linux/devfreq.h>
+struct module;
#define DEVFREQ_NAME_LEN 16
@@ -53,6 +54,15 @@
* @name: Governor's name
* @attrs: Governor's sysfs attribute flags
* @flags: Governor's feature flags
+ * @owner: Optional, module that owns this governor.
+ * When set (typically to THIS_MODULE), the devfreq core
+ * takes a reference on @owner while this governor is in
+ * use so that the governor module cannot be removed,
+ * except by a forced unload. Governors that are bundled
+ * into a device driver module must leave @owner NULL: the
+ * device's lifetime already pins that module, and setting
+ * @owner would create a self-reference that prevents the
+ * driver from being unloaded.
* @get_target_freq: Returns desired operating frequency for the device.
* Basically, get_target_freq will run
* devfreq_dev_profile.get_dev_status() to get the
@@ -70,6 +80,7 @@ struct devfreq_governor {
const char name[DEVFREQ_NAME_LEN];
const u64 attrs;
const u64 flags;
+ struct module *owner;
int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
int (*event_handler)(struct devfreq *devfreq,
unsigned int event, void *data);
--
2.43.0
^ permalink raw reply related
* [PATCH v3 3/4] devfreq: Factor out devfreq_set_governor()
From: Jie Zhan @ 2026-05-19 11:32 UTC (permalink / raw)
To: cwchoi00, cw00.choi, myungjoo.ham, kyungmin.park, linux-pm,
linux-arm-kernel
Cc: linuxarm, tianyaxiong, zhanjie9, zhenglifeng1, zhangpengjie2,
lihuisong, prime.zeng
In-Reply-To: <20260519113251.3745140-1-zhanjie9@hisilicon.com>
governor_store() and devfreq_add_device() contain similar logic for setting
a governor when devfreq->governor is NULL. Merge this into a common
function, devfreq_set_governor(), to reduce code duplication and unify the
entry of setting governors.
This also prepares for further changes that get / put a module refcount of
the active governor and prevent the governor module from being unloaded
while it's in use.
Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
---
drivers/devfreq/devfreq.c | 117 ++++++++++++++++++--------------------
1 file changed, 56 insertions(+), 61 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 53c40d795a13..9e3e6a7348f8 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -318,6 +318,59 @@ static struct devfreq_governor *try_then_request_governor(const char *name)
return governor;
}
+static int devfreq_set_governor(struct devfreq *df,
+ const struct devfreq_governor *new_gov)
+{
+ const struct devfreq_governor *old_gov;
+ struct device *dev;
+ int ret;
+
+ lockdep_assert_held(&devfreq_list_lock);
+
+ old_gov = df->governor;
+ dev = &df->dev;
+
+ if (old_gov) {
+ if (old_gov == new_gov)
+ return 0;
+
+ if (IS_SUPPORTED_FLAG(old_gov->flags, IMMUTABLE) ||
+ IS_SUPPORTED_FLAG(new_gov->flags, IMMUTABLE))
+ return -EINVAL;
+
+ /* Stop the current governor */
+ ret = df->governor->event_handler(df, DEVFREQ_GOV_STOP, NULL);
+ if (ret) {
+ dev_warn(dev, "%s: Governor %s not stopped(%d)\n",
+ __func__, df->governor->name, ret);
+ return ret;
+ }
+ }
+
+ /* Start the new governor */
+ df->governor = new_gov;
+ ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
+ if (ret) {
+ dev_warn(dev, "%s: Governor %s not started(%d)\n",
+ __func__, df->governor->name, ret);
+
+ /* Restore previous governor */
+ df->governor = old_gov;
+ if (!df->governor)
+ return ret;
+
+ ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
+ if (ret) {
+ dev_err(dev, "%s: restore Governor %s failed (%d)\n",
+ __func__, df->governor->name, ret);
+ df->governor = NULL;
+ return ret;
+ }
+ }
+
+ return sysfs_update_group(&df->dev.kobj, &gov_attr_group);
+}
+
static int devfreq_notify_transition(struct devfreq *devfreq,
struct devfreq_freqs *freqs, unsigned int state)
{
@@ -942,9 +995,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
goto err_init;
}
- devfreq->governor = governor;
- err = devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_START,
- NULL);
+ err = devfreq_set_governor(devfreq, governor);
if (err) {
dev_err_probe(dev, err,
"%s: Unable to start governor for the device\n",
@@ -952,10 +1003,6 @@ struct devfreq *devfreq_add_device(struct device *dev,
goto err_init;
}
- err = sysfs_update_group(&devfreq->dev.kobj, &gov_attr_group);
- if (err)
- goto err_init;
-
list_add(&devfreq->node, &devfreq_list);
mutex_unlock(&devfreq_list_lock);
@@ -1380,7 +1427,7 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
struct devfreq *df = to_devfreq(dev);
int ret;
char str_governor[DEVFREQ_NAME_LEN + 1];
- const struct devfreq_governor *governor, *prev_governor;
+ const struct devfreq_governor *governor;
ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", str_governor);
if (ret != 1)
@@ -1391,59 +1438,7 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
if (IS_ERR(governor))
return PTR_ERR(governor);
- if (!df->governor)
- goto start_new_governor;
-
- if (df->governor == governor)
- return count;
-
- if (IS_SUPPORTED_FLAG(df->governor->flags, IMMUTABLE) ||
- IS_SUPPORTED_FLAG(governor->flags, IMMUTABLE))
- return -EINVAL;
-
- /*
- * Stop the current governor and remove the specific sysfs files
- * which depend on current governor.
- */
- ret = df->governor->event_handler(df, DEVFREQ_GOV_STOP, NULL);
- if (ret) {
- dev_warn(dev, "%s: Governor %s not stopped(%d)\n",
- __func__, df->governor->name, ret);
- return ret;
- }
-
-start_new_governor:
- /*
- * Start the new governor and create the specific sysfs files
- * which depend on the new governor.
- */
- prev_governor = df->governor;
- df->governor = governor;
- ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
- if (ret) {
- dev_warn(dev, "%s: Governor %s not started(%d)\n",
- __func__, df->governor->name, ret);
-
- /* Restore previous governor */
- df->governor = prev_governor;
- if (!df->governor)
- return ret;
-
- ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
- if (ret) {
- dev_err(dev,
- "%s: reverting to Governor %s failed (%d)\n",
- __func__, prev_governor->name, ret);
- df->governor = NULL;
- return ret;
- }
- }
-
- /*
- * Create the sysfs files for the new governor. But if failed to start
- * the new governor, restore the sysfs files of previous governor.
- */
- ret = sysfs_update_group(&df->dev.kobj, &gov_attr_group);
+ ret = devfreq_set_governor(df, governor);
if (ret)
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH v3 2/4] devfreq: Use mutex guard in devfreq_add/remove_governor()
From: Jie Zhan @ 2026-05-19 11:32 UTC (permalink / raw)
To: cwchoi00, cw00.choi, myungjoo.ham, kyungmin.park, linux-pm,
linux-arm-kernel
Cc: linuxarm, tianyaxiong, zhanjie9, zhenglifeng1, zhangpengjie2,
lihuisong, prime.zeng
In-Reply-To: <20260519113251.3745140-1-zhanjie9@hisilicon.com>
Use mutex guard in devfreq_add/remove_governor() so as to simplify the
locking logic.
No functional impact intended.
Reviewed-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
---
drivers/devfreq/devfreq.c | 22 +++++++---------------
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 7a70dd051644..53c40d795a13 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1261,28 +1261,23 @@ void devfreq_resume(void)
int devfreq_add_governor(struct devfreq_governor *governor)
{
struct devfreq_governor *g;
- int err = 0;
if (!governor) {
pr_err("%s: Invalid parameters.\n", __func__);
return -EINVAL;
}
- mutex_lock(&devfreq_list_lock);
+ guard(mutex)(&devfreq_list_lock);
g = find_devfreq_governor(governor->name);
if (!IS_ERR(g)) {
pr_err("%s: governor %s already registered\n", __func__,
g->name);
- err = -EINVAL;
- goto err_out;
+ return -EINVAL;
}
list_add(&governor->node, &devfreq_governor_list);
-err_out:
- mutex_unlock(&devfreq_list_lock);
-
- return err;
+ return 0;
}
EXPORT_SYMBOL(devfreq_add_governor);
@@ -1320,21 +1315,20 @@ int devfreq_remove_governor(struct devfreq_governor *governor)
{
struct devfreq_governor *g;
struct devfreq *devfreq;
- int err = 0;
if (!governor) {
pr_err("%s: Invalid parameters.\n", __func__);
return -EINVAL;
}
- mutex_lock(&devfreq_list_lock);
+ guard(mutex)(&devfreq_list_lock);
g = find_devfreq_governor(governor->name);
if (IS_ERR(g)) {
pr_err("%s: governor %s not registered\n", __func__,
governor->name);
- err = PTR_ERR(g);
- goto err_out;
+ return PTR_ERR(g);
}
+
list_for_each_entry(devfreq, &devfreq_list, node) {
int ret;
struct device *dev = devfreq->dev.parent;
@@ -1356,10 +1350,8 @@ int devfreq_remove_governor(struct devfreq_governor *governor)
}
list_del(&governor->node);
-err_out:
- mutex_unlock(&devfreq_list_lock);
- return err;
+ return 0;
}
EXPORT_SYMBOL(devfreq_remove_governor);
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/4] devfreq: Use mutex guard in governor_store()
From: Jie Zhan @ 2026-05-19 11:32 UTC (permalink / raw)
To: cwchoi00, cw00.choi, myungjoo.ham, kyungmin.park, linux-pm,
linux-arm-kernel
Cc: linuxarm, tianyaxiong, zhanjie9, zhenglifeng1, zhangpengjie2,
lihuisong, prime.zeng
In-Reply-To: <20260519113251.3745140-1-zhanjie9@hisilicon.com>
Use mutex guard in governor_store() so as to simplify the locking logic.
No functional impact intended.
Reviewed-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
---
drivers/devfreq/devfreq.c | 38 ++++++++++++++++----------------------
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index f08fc6966eae..7a70dd051644 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1394,23 +1394,20 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
if (ret != 1)
return -EINVAL;
- mutex_lock(&devfreq_list_lock);
+ guard(mutex)(&devfreq_list_lock);
governor = try_then_request_governor(str_governor);
- if (IS_ERR(governor)) {
- ret = PTR_ERR(governor);
- goto out;
- }
+ if (IS_ERR(governor))
+ return PTR_ERR(governor);
+
if (!df->governor)
goto start_new_governor;
- if (df->governor == governor) {
- ret = 0;
- goto out;
- } else if (IS_SUPPORTED_FLAG(df->governor->flags, IMMUTABLE)
- || IS_SUPPORTED_FLAG(governor->flags, IMMUTABLE)) {
- ret = -EINVAL;
- goto out;
- }
+ if (df->governor == governor)
+ return count;
+
+ if (IS_SUPPORTED_FLAG(df->governor->flags, IMMUTABLE) ||
+ IS_SUPPORTED_FLAG(governor->flags, IMMUTABLE))
+ return -EINVAL;
/*
* Stop the current governor and remove the specific sysfs files
@@ -1420,7 +1417,7 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
if (ret) {
dev_warn(dev, "%s: Governor %s not stopped(%d)\n",
__func__, df->governor->name, ret);
- goto out;
+ return ret;
}
start_new_governor:
@@ -1438,7 +1435,7 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
/* Restore previous governor */
df->governor = prev_governor;
if (!df->governor)
- goto out;
+ return ret;
ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
if (ret) {
@@ -1446,7 +1443,7 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
"%s: reverting to Governor %s failed (%d)\n",
__func__, prev_governor->name, ret);
df->governor = NULL;
- goto out;
+ return ret;
}
}
@@ -1455,13 +1452,10 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
* the new governor, restore the sysfs files of previous governor.
*/
ret = sysfs_update_group(&df->dev.kobj, &gov_attr_group);
+ if (ret)
+ return ret;
-out:
- mutex_unlock(&devfreq_list_lock);
-
- if (!ret)
- ret = count;
- return ret;
+ return count;
}
static DEVICE_ATTR_RW(governor);
--
2.43.0
^ permalink raw reply related
* [PATCH v2] media: dt-bindings: nxp,imx8mq-mipi-csi2: Fix example endpoint label typo
From: Laurent Pinchart @ 2026-05-19 11:38 UTC (permalink / raw)
To: Robby Cai, Frank Li, Martin Kepplinger-Novakovic,
Martin Kepplinger, Rui Miguel Silva, Purism Kernel Team,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: imx, linux-media, devicetree, linux-arm-kernel, linux-kernel
From: Robby Cai <robby.cai@nxp.com>
The example in imx8mq-mipi-csi2.yaml uses imx8mm_mipi_csi_{in,out}
endpoint labels, which is confusing for an i.MX8MQ binding. The labels
could be removed as they are not functionally required in the example,
but they have a documentation purpose that brings value to the reader.
Rename them mipi_csi_{in,out} to avoid the confusion.
Signed-off-by: Robby Cai <robby.cai@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes since v1:
- Drop imx8mpq_ prefix from label name
- Update commit message
- Drop Fixes: tag
---
.../devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
index 4fcfc4fd3565..9eee67ed2685 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
@@ -220,7 +220,7 @@ examples:
port@0 {
reg = <0>;
- imx8mm_mipi_csi_in: endpoint {
+ mipi_csi_in: endpoint {
remote-endpoint = <&imx477_out>;
data-lanes = <1 2 3 4>;
};
@@ -229,7 +229,7 @@ examples:
port@1 {
reg = <1>;
- imx8mm_mipi_csi_out: endpoint {
+ mipi_csi_out: endpoint {
remote-endpoint = <&csi_in>;
};
};
base-commit: d97d13c24d7893abcfb80d38630ce74daaa1434c
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH] arm64/daifflags: Make local_daif_*() helpers __always_inline
From: Leonardo Bras @ 2026-05-19 11:38 UTC (permalink / raw)
To: Will Deacon
Cc: Leonardo Bras, mark.rutland, catalin.marinas, kernel-team, leitao,
leo.yan, linux-arm-kernel, linux-kernel, palmer, paulmck,
puranjay, rmikey, usama.arif
In-Reply-To: <agw98k7XVGNCR4RM@willie-the-truck>
On Tue, May 19, 2026 at 11:39:46AM +0100, Will Deacon wrote:
> On Mon, Apr 27, 2026 at 03:01:26PM +0100, Leonardo Bras wrote:
> > Make sure those helpers are always inlined and instrumentation safe.
> >
> > Signed-off-by: Leonardo Bras <leo.bras@arm.com>
> > ---
> > arch/arm64/include/asm/daifflags.h | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
>
> b4 really doesn't like this patch being a reply to another one, so I'm
> just replying to say that I've picked it up manually.
>
> Cheers,
>
> Will
Hi Will,
Noted. I will avoid doing this in the future.
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v4 06/24] iommu: Defer iommu_group free via kfree_rcu()
From: Jason Gunthorpe @ 2026-05-19 11:39 UTC (permalink / raw)
To: Nicolin Chen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <a65846f5514fd3b7ef6c19e060ed3a25af75bf03.1779161849.git.nicolinc@nvidia.com>
On Mon, May 18, 2026 at 08:38:49PM -0700, Nicolin Chen wrote:
> dev->iommu_group will be read in an ISR-context to look up a group_device
> for fault reporting, in which case mutex cannot be used. For that read to
> be safe, two things are needed:
What driver does this? iommu_report_device_fault() has to be called in
a sleepable context - usually a threaded IRQ handler. So mutex is no
problem.
This seems like Sashiko slop - iommu_group does not change while a
driver is attached and a driver is not permitted to do any "fault
handling" after it has detached, it must flush and synchronize its
IRQ if it is using this from a hard IRQ for some bad reason.
You need to be alot more critical about the noise that Sashiko
generates, alot is useful, alot is not. It is a not a tool you want to
have 0 reports, complaining about hallucinations is expected.
> +#define dev_iommu_group_rcu(dev) \
> + (*((struct iommu_group __rcu __force **)&(dev)->iommu_group))
Don't do things like this.
Jason
^ permalink raw reply
* Re: [PATCH v4] perf/arm_pmu: Skip PMCCNTR_EL0 on NVIDIA Olympus
From: Will Deacon @ 2026-05-19 11:41 UTC (permalink / raw)
To: Besar Wicaksono
Cc: mark.rutland, james.clark, yangyccccc, linux-arm-kernel,
linux-kernel, linux-tegra, treding, jonathanh, vsethi, rwiley,
sdonthineni, mochs, nirmoyd, skelley
In-Reply-To: <20260504175204.3122979-1-bwicaksono@nvidia.com>
On Mon, May 04, 2026 at 05:52:04PM +0000, Besar Wicaksono wrote:
> PMCCNTR_EL0 may continue to increment on NVIDIA Olympus CPUs while the
> PE is in WFI/WFE. That does not necessarily match the CPU_CYCLES event
> counted by a programmable counter, so using PMCCNTR_EL0 for cycles can
> give results that differ from the programmable counter path.
>
> Extend the existing PMCCNTR avoidance decision from the SMT case to
> also cover Olympus. Store the result in the common arm_pmu state at
> registration time, so arm_pmuv3 can keep using a single flag when
> deciding whether CPU_CYCLES may use PMCCNTR_EL0.
>
> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com>
> ---
>
> Changes from v1:
> * add CONFIG_ARM64 check to fix build error found by kernel test robot
> * add explicit include of <asm/cputype.h>
> v1: https://lore.kernel.org/linux-arm-kernel/20260406232034.2566133-1-bwicaksono@nvidia.com/
>
> Changes from v2:
> * Move the Olympus PMCCNTR avoidance check from arm_pmuv3.c to the
> common arm_pmu registration path.
> * Replace the PMUv3-only has_smt flag with avoid_pmccntr, covering both
> the existing SMT restriction and the Olympus MIDR restriction.
> * Use the cached per-CPU MIDR from cpu_data instead of calling
> is_midr_in_range_list() from armv8pmu_can_use_pmccntr().
> * Add the required asm/cpu.h include for cpu_data.
> v2: https://lore.kernel.org/linux-arm-kernel/20260421203856.3539186-1-bwicaksono@nvidia.com/#t
>
> Changes from v3:
> * Move avoidance check based on MIDR to __armv8pmu_probe_pmu() to make sure
> the MIDR is retrieved from the correct online CPU.
> v3: https://lore.kernel.org/linux-arm-kernel/20260429215614.1793131-1-bwicaksono@nvidia.com/
>
> ---
> drivers/perf/arm_pmu.c | 7 ++++-
> drivers/perf/arm_pmuv3.c | 51 +++++++++++++++++++++++++++++++-----
> include/linux/perf/arm_pmu.h | 2 +-
> 3 files changed, 51 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 939bcbd433aa..aa1dac0b440f 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -931,8 +931,13 @@ int armpmu_register(struct arm_pmu *pmu)
> /*
> * By this stage we know our supported CPUs on either DT/ACPI platforms,
> * detect the SMT implementation.
> + * On SMT CPUs, the PMCCNTR_EL0 increments from the processor clock rather
> + * than the PE clock (ARM DDI0487 L.b D13.1.3) which means it'll continue
> + * counting on a WFI PE if one of its SMT sibling is not idle on a
> + * multi-threaded implementation. So don't use it on SMT cores.
> */
> - pmu->has_smt = topology_core_has_smt(cpumask_first(&pmu->supported_cpus));
> + pmu->avoid_pmccntr |=
> + topology_core_has_smt(cpumask_first(&pmu->supported_cpus));
>
> if (!pmu->set_event_filter)
> pmu->pmu.capabilities |= PERF_PMU_CAP_NO_EXCLUDE;
> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index 8014ff766cff..1ee4a09d0dcc 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -8,6 +8,7 @@
> * This code is based heavily on the ARMv7 perf event code.
> */
>
> +#include <asm/cputype.h>
> #include <asm/irq_regs.h>
> #include <asm/perf_event.h>
> #include <asm/virt.h>
> @@ -1002,13 +1003,7 @@ static bool armv8pmu_can_use_pmccntr(struct pmu_hw_events *cpuc,
> if (has_branch_stack(event))
> return false;
>
> - /*
> - * The PMCCNTR_EL0 increments from the processor clock rather than
> - * the PE clock (ARM DDI0487 L.b D13.1.3) which means it'll continue
> - * counting on a WFI PE if one of its SMT sibling is not idle on a
> - * multi-threaded implementation. So don't use it on SMT cores.
> - */
> - if (cpu_pmu->has_smt)
> + if (cpu_pmu->avoid_pmccntr)
> return false;
>
> return true;
> @@ -1299,6 +1294,41 @@ static int armv8_vulcan_map_event(struct perf_event *event)
> &armv8_vulcan_perf_cache_map);
> }
>
> +#ifdef CONFIG_ARM64
> +/*
> + * List of CPUs that should avoid using PMCCNTR_EL0.
> + */
> +static struct midr_range armv8pmu_avoid_pmccntr_cpus[] = {
> + /*
> + * The PMCCNTR_EL0 in Olympus CPU may still increment while in WFI/WFE state.
> + * This is an implementation specific behavior and not an erratum.
> + *
> + * From ARM DDI0487 D14.4:
> + * It is IMPLEMENTATION SPECIFIC whether CPU_CYCLES and PMCCNTR count
> + * when the PE is in WFI or WFE state, even if the clocks are not stopped.
So surely the weird part here is that Olypmus chose one behaviour for
PMCCNTR and another for the CPU_CYCLES event? The Arm ARM text isn't
clear to me as to whether that's permitted but I think we should call
it out here.
> + * From ARM DDI0487 D24.5.2:
> + * All counters are subject to any changes in clock frequency, including
> + * clock stopping caused by the WFI and WFE instructions.
> + * This means that it is CONSTRAINED UNPREDICTABLE whether or not
> + * PMCCNTR_EL0 continues to increment when clocks are stopped by WFI and
> + * WFE instructions.
> + */
> + MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
> + {}
> +};
> +
> +static bool armv8pmu_is_in_avoid_pmccntr_cpus(void)
> +{
> + return is_midr_in_range_list(armv8pmu_avoid_pmccntr_cpus);
> +}
> +#else
> +static bool armv8pmu_is_in_avoid_pmccntr_cpus(void)
> +{
> + return false;
> +}
> +#endif
> +
> struct armv8pmu_probe_info {
> struct arm_pmu *pmu;
> bool present;
> @@ -1348,6 +1378,13 @@ static void __armv8pmu_probe_pmu(void *info)
> else
> cpu_pmu->reg_pmmir = 0;
>
> + /*
> + * On some CPUs, PMCCNTR_EL0 does not match the behavior of CPU_CYCLES
> + * programmable counter, so avoid routing cycles through PMCCNTR_EL0 to
> + * prevent inconsistency in the results.
> + */
> + cpu_pmu->avoid_pmccntr |= armv8pmu_is_in_avoid_pmccntr_cpus();
Do we also want to hide the cycle counter from userspace? It sounds like
it's going to get very confused if it tries to use it...
Will
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-19 11:44 UTC (permalink / raw)
To: Will Deacon
Cc: Paolo Bonzini, Marc Zyngier, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <agxFbniU_6eQ98t2@willie-the-truck>
[-- Attachment #1: Type: text/plain, Size: 3074 bytes --]
On Tue, 2026-05-19 at 12:11 +0100, Will Deacon wrote:
> On Tue, May 19, 2026 at 11:41:26AM +0100, David Woodhouse wrote:
> > On Wed, 2026-05-13 at 18:24 +0200, Paolo Bonzini wrote:
> > >
> > > > See commit https://git.kernel.org/torvalds/c/49a1a2c70a7f which adds a
> > > > new guest-visible feature in revision 3, but allowed userspace to
> > > > restore the old behaviour by setting it to revision 2. All my patch
> > > > above does, is make it possible to set it to revision 1 as
> > > > well. Because https://git.kernel.org/torvalds/c/d53c2c29ae0d previously
> > > > changed the behaviour and bumped the default to 2 *without* allowing
> > > > userspace to restore the prior behaviour, and we've been carrying a
> > > > *revert* of that patch.
> > > >
> > > > Why would we *not* accept such a patch?
> > >
> > > Agreed. Even ignoring your revert, there's no reason why any upgrade
> > > past 49a1a2c70a7f has to be from after d53c2c29ae0d.
> >
> > So where do we go from here?
> >
> > I assume you'll be taking this Documentation patch via the KVM tree?
> >
> > But what about the actual fix at
> > https://lore.kernel.org/all/20260511113558.3325004-2-dwmw2@infradead.org/
> >
> > This is a simple and unintrusive bug fix to make KVM/arm64 follow the
> > "common sense" requirement that the doc patch codifies, apparently
> > being rejected with the rather bizarre claim that KVM has no *need* to
> > maintain guest-visible compatibility across host kernel changes.
> >
> > So... what next? Is one of the other KVM/arm64 maintainers going to
> > speak up? Paolo would you consider taking the fixes through your tree
> > directly?
> >
> > Does Arm not actually *care* whether AArch64 is considered a stable and
> > mature platform for KVM hosting?
>
> Hey, come on. Marc cares more about this stuff than anybody else on the
> planet. He's been single-handedly maintaining the tree for the past
> couple of releases while Oliver was out and he's on the end of a _lot_
> of patches. I'm only cc'd on a fraction of the KVM/arm64 changes and
> it's bedlam.
I certainly wouldn't disagree with any of that. The depth of knowledge
and the amount of energy that Marc displays through this work is
impressive, and I'm sure we all have an enormous amount of respect for
it, and for him. I know I do.
Nevertheless, the specific technical decision to reject the simple bug
fix linked above is dead wrong.
Because the principle under which it was rejected — the idea that KVM
has no responsibility to maintain compatibility of guest-visible
behaviour from one kernel version to the next — is also dead wrong.
If KVM on arm64 doesn't aspire to maintain guest compatibility across
host kernel changes — regardless of whether the previous kernel's
behaviour was "blessed" by the architecture specification or not — then
it does not meet the expectation that we have of KVM implementations in
the Linux kernel.
Or indeed the standards that we've held for Linux kernel ABIs for the
last 35 years.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: Fix garbled logs caused by race between multiple stack traces
From: Will Deacon @ 2026-05-19 11:45 UTC (permalink / raw)
To: David Sauerwein
Cc: Catalin Marinas, Mark Rutland, linux-kernel, linux-arm-kernel,
nh-open-source
In-Reply-To: <20260507123846.35621-1-dssauerw@amazon.de>
On Thu, May 07, 2026 at 12:38:46PM +0000, David Sauerwein wrote:
> On Wed, May 06, 2026 at 11:58:44AM +0100, Catalin Marinas wrote:
> > While the above does solve the line splitting, the trace is still not
> > that readable as we get line interleaving.
> >
> > I wonder whether we could do something like dump_stack_lvl() at the
> > show_regs() level to synchronise the printing. If that works, we
> > wouldn't need the above change (which isn't incorrect but maybe we can
> > do better).
>
> I think the change is still needed in either case. Other threads can log
> something unrelated to the stack traces which can still cause the
> register lines to be broken. After all, use of pr_cont is discouraged.
> checkpatch.pl warns saying "Avoid logging continuation uses where
> feasible" when adding new callers of pr_cont.
>
> I agree though that forcing stack traces to be printed sequentially
> would help with readability. Maybe this can be added as a separate
> change.
Presumably it would replace this patch?
Will
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: Add usbphynop and usbotg pinctrl for S32G platforms
From: Enric Balletbo i Serra @ 2026-05-19 11:45 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pengutronix Kernel Team, linux-arm-kernel, imx,
devicetree, linux-kernel, NXP S32 Linux, Christophe Lizzi,
Alberto Ruiz
In-Reply-To: <20260518061522.2884441-2-khristineandreea.barbulescu@oss.nxp.com>
Hi,
Thank you for the patch.
On Mon, May 18, 2026 at 8:15 AM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
>
> Add the usbphynop node and the usbotg pinctrl
> support for the S32G2 and S32G3 SoCs.
>
> This enables the USB controller to reference the
> generic PHY and use the required pinmux for USB OTG ops.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
> .../boot/dts/freescale/s32gxxxa-evb.dtsi | 53 ++++++++++++++++++-
> .../boot/dts/freescale/s32gxxxa-rdb.dtsi | 53 ++++++++++++++++++-
> 2 files changed, 104 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi b/arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi
> index 803ff4531077..d096744cdb0f 100644
> --- a/arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi
> @@ -1,12 +1,19 @@
> // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> /*
> - * Copyright 2024 NXP
> + * Copyright 2024, 2026 NXP
> *
> * Authors: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> * Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
> * Larisa Grigore <larisa.grigore@nxp.com>
> */
>
> +/ {
> + usbphynop: usbphynop {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0>;
> + };
> +};
I'm wondering if it it would be more appropriate in the SoC-level dtsi
(s32g2.dtsi/s32g3.dtsi), similar to other Freescale boards,it doesn't
represent any board-specific hardware but a virtual NOP transceiver
used by the SoC.
> +
> &pinctrl {
> can0_pins: can0-pins {
> can0-grp0 {
> @@ -245,6 +252,39 @@ dspi5-grp4 {
> bias-pull-up;
> };
> };
> +
> + usbotg_pins: usbotg_pins {
> + usbotg_grp0 {
The label can remain usbotg_pins but node names should use hyphens
usbotg_pins: usbotg-pins {
usbotg-grp0 {
You can run this to catch this kind of issues:
make W=1 CHECK_DTBS=y ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
freescale/s32g399a-rdb3.dtb
> + pinmux = <0x3802>, <0x3812>,
> + <0x3822>, <0x3832>,
> + <0x3842>, <0x3852>,
> + <0x3862>, <0x3872>,
> + <0x37f2>, <0x3882>,
> + <0x3892>;
> + };
> +
> + usbotg_grp1 {
> + pinmux = <0x3e1>, <0x3f1>,
> + <0x401>, <0x411>,
> + <0xbc1>, <0xbd1>,
> + <0xbe1>, <0x701>;
> + output-enable;
> + input-enable;
> + slew-rate = <208>;
> + };
> +
> + usbotg_grp2 {
> + pinmux = <0xb80>, <0xb90>, <0xbb0>;
> + input-enable;
> + slew-rate = <208>;
> + };
> +
> + usbotg_grp3 {
> + pinmux = <0xba1>;
> + output-enable;
> + slew-rate = <208>;
> + };
> + };
> };
>
> &can0 {
> @@ -304,3 +344,14 @@ &spi5 {
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +&usbmisc {
> + status = "okay";
> +};
> +
> +&usbotg {
> + pinctrl-names = "default";
> + pinctrl-0 = <&usbotg_pins>;
> + fsl,usbphy = <&usbphynop>;
According to the binding this option is deprecated. Could you use
"phys" instead?
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi b/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
> index 979868f6d2c5..b756bcf6469d 100644
> --- a/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
> @@ -1,12 +1,19 @@
> // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> /*
> - * Copyright 2024 NXP
> + * Copyright 2024, 2026 NXP
> *
> * Authors: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> * Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
> * Larisa Grigore <larisa.grigore@nxp.com>
> */
>
> +/ {
> + usbphynop: usbphynop {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0>;
> + };
> +};
> +
> &pinctrl {
> can0_pins: can0-pins {
> can0-grp0 {
> @@ -199,6 +206,39 @@ dspi5-grp4 {
> bias-pull-up;
> };
> };
> +
> + usbotg_pins: usbotg_pins {
> + usbotg_grp0 {
ditto
> + pinmux = <0x3802>, <0x3812>,
> + <0x3822>, <0x3832>,
> + <0x3842>, <0x3852>,
> + <0x3862>, <0x3872>,
> + <0x37f2>, <0x3882>,
> + <0x3892>;
> + };
> +
> + usbotg_grp1 {
> + pinmux = <0x3e1>, <0x3f1>,
> + <0x401>, <0x411>,
> + <0xbc1>, <0xbd1>,
> + <0xbe1>, <0x701>;
> + output-enable;
> + input-enable;
> + slew-rate = <208>;
> + };
> +
> + usbotg_grp2 {
> + pinmux = <0xb80>, <0xb90>, <0xbb0>;
> + input-enable;
> + slew-rate = <208>;
> + };
> +
> + usbotg_grp3 {
> + pinmux = <0xba1>;
> + output-enable;
> + slew-rate = <208>;
> + };
> + };
> };
>
> &can0 {
> @@ -257,3 +297,14 @@ &i2c4 {
> pinctrl-1 = <&i2c4_gpio_pins>;
> status = "okay";
> };
> +
> +&usbmisc {
> + status = "okay";
> +};
> +
> +&usbotg {
> + pinctrl-names = "default";
> + pinctrl-0 = <&usbotg_pins>;
> + fsl,usbphy = <&usbphynop>;
ditto
> + status = "okay";
> +};
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v4 07/24] iommu: Defer __iommu_group_free_device() to be outside group->mutex
From: Jason Gunthorpe @ 2026-05-19 11:47 UTC (permalink / raw)
To: Nicolin Chen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <bae489d600425a014bfed1c2290ee7c0c657f198.1779161849.git.nicolinc@nvidia.com>
On Mon, May 18, 2026 at 08:38:50PM -0700, Nicolin Chen wrote:
> __iommu_group_remove_device() holds group->mutex across the entire call to
> __iommu_group_free_device() that performs sysfs removals, tracing, and the
> final kfree(). But in fact, most of these operations don't really need the
> group->mutex.
Are you sure? sysfs requires unique names, and this mutex is providing
a guarentee that will happen. While it shouldn't be possible to race
remove and attach, it is easier to reason about if we don't have to
make this assumption.
> Subsequent changes will introduce sleepable operations to this function:
> + synchronize_rcu() to defer the gdev->dev put past a grace period.
I'm not keen on that at all.
Jason
^ permalink raw reply
* [PATCH v2] usb: dwc3: xilinx: fix error handling in zynqmp init error paths
From: Radhey Shyam Pandey @ 2026-05-19 11:55 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey, stable
Fix error handling and resource cleanup i.e remove invalid
phy_exit() after failed phy_init(), route failures through
proper cleanup paths and return 0 explicitly on success.
Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")
Cc: stable@vger.kernel.org
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- Split this functional fix into a separate patch.
- Add Thinh Nguyen acked-by tag.
Link to v1:
https://lore.kernel.org/all/20260511160814.2904882-4-radhey.shyam.pandey@amd.com
---
drivers/usb/dwc3/dwc3-xilinx.c | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index f41b0da5e89d..9b9525592a85 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -184,15 +184,13 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
}
ret = phy_init(priv_data->usb3_phy);
- if (ret < 0) {
- phy_exit(priv_data->usb3_phy);
+ if (ret < 0)
goto err;
- }
ret = reset_control_deassert(apbrst);
if (ret < 0) {
dev_err(dev, "Failed to release APB reset\n");
- goto err;
+ goto err_phy_exit;
}
if (priv_data->usb3_phy) {
@@ -208,26 +206,24 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
ret = reset_control_deassert(crst);
if (ret < 0) {
dev_err(dev, "Failed to release core reset\n");
- goto err;
+ goto err_phy_exit;
}
ret = reset_control_deassert(hibrst);
if (ret < 0) {
dev_err(dev, "Failed to release hibernation reset\n");
- goto err;
+ goto err_phy_exit;
}
ret = phy_power_on(priv_data->usb3_phy);
- if (ret < 0) {
- phy_exit(priv_data->usb3_phy);
- goto err;
- }
+ if (ret < 0)
+ goto err_phy_exit;
/* ulpi reset via gpio-modepin or gpio-framework driver */
reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(reset_gpio)) {
- return dev_err_probe(dev, PTR_ERR(reset_gpio),
- "Failed to request reset GPIO\n");
+ ret = PTR_ERR(reset_gpio);
+ goto err_phy_power_off;
}
if (reset_gpio) {
@@ -237,6 +233,13 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
}
dwc3_xlnx_set_coherency(priv_data, XLNX_USB_TRAFFIC_ROUTE_CONFIG);
+
+ return 0;
+
+err_phy_power_off:
+ phy_power_off(priv_data->usb3_phy);
+err_phy_exit:
+ phy_exit(priv_data->usb3_phy);
err:
return ret;
}
base-commit: ab5fce87a778cb780a05984a2ca448f2b41aafbf
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox