* Re: [PATCH v4 11/24] iommu: Add iommu_report_device_broken() to quarantine a broken device
From: Jason Gunthorpe @ 2026-05-19 12:07 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: <745da1a819eb943f2519e660c8bcfde715885c6c.1779161849.git.nicolinc@nvidia.com>
On Mon, May 18, 2026 at 08:38:54PM -0700, Nicolin Chen wrote:
> +void iommu_report_device_broken(struct device *dev)
> +{
> + struct group_device *gdev;
> +
> + /*
> + * We cannot hold group->mutex here. Rely on iommu_group_broken_worker()
> + * to validate dev_has_iommu(). The iommu_group memory is RCU-protected
> + * via kfree_rcu() in iommu_group_release(), and group->devices is an
> + * RCU-protected list, so the lookup runs entirely under rcu_read_lock.
> + *
> + * Note the device might have been concurrently removed from the group
> + * (list_del_rcu) before iommu_deinit_device() cleared the dev->iommu.
> + */
> + rcu_read_lock();
> + gdev = __dev_to_gdev_rcu(dev);
> + if (gdev) {
If this is why the RCU is being added it seems like overkill.
Just add the worker to struct dev_iommu and push it there so it can
use a mutex but I'm confused why are we even adding this function?
The entire design of this series was supposed to have the IOMMU driver
itself adjust it's "STE" to inhibit translated TLPs synchronosly
within its fully locked invalidation loop.
Whats the async worker for?
Jason
^ permalink raw reply
* Re: [PATCH v7 09/23] drm: bridge: dw_hdmi: Unregister CEC notifier during connector cleanup
From: Luca Ceresoli @ 2026-05-19 12:06 UTC (permalink / raw)
To: Jonas Karlman
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Heiko Stuebner,
Laurent Pinchart, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Liu Ying, Sandy Huang, Andy Yan, Chen-Yu Tsai,
Christian Hewitt, Diederik de Haas, Nicolas Frattaroli,
Dmitry Baryshkov, dri-devel, linux-arm-kernel, linux-rockchip,
linux-amlogic, linux-sunxi, imx, linux-kernel
In-Reply-To: <20260518180206.2480119-10-jonas@kwiboo.se>
On Mon, 18 May 2026 18:01:45 +0000, Jonas Karlman <jonas@kwiboo.se> wrote:
> The CEC notifier is being unregistered when the bridge detach,
> something that happens earlier than normal connector cleanup.
>
> Change to unregister the CEC notifier at connector cleanup, in the
> connector .destroy() func, to align the lifetime of the connector and
> the CEC notifier and closer match a drmres handled generic CEC notifier.
>
> [...]
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v7 04/23] drm: bridge: dw_hdmi: Hold bridge ref until connector cleanup
From: Luca Ceresoli @ 2026-05-19 12:06 UTC (permalink / raw)
To: Jonas Karlman
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Heiko Stuebner,
Laurent Pinchart, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Cristian Ciocaltea, Louis Chauvet, Liu Ying,
Sandy Huang, Andy Yan, Chen-Yu Tsai, Christian Hewitt,
Diederik de Haas, Nicolas Frattaroli, Dmitry Baryshkov, dri-devel,
linux-arm-kernel, linux-rockchip, linux-amlogic, linux-sunxi, imx,
linux-kernel
In-Reply-To: <20260518180206.2480119-5-jonas@kwiboo.se>
On Mon, 18 May 2026 18:01:40 +0000, Jonas Karlman <jonas@kwiboo.se> wrote:
Hello Jonas,
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index b7bfc0e9a6b2..9d795c550f8a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2600,10 +2609,14 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
>
> drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
>
> - drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
> - &dw_hdmi_connector_funcs,
> - DRM_MODE_CONNECTOR_HDMIA,
> - hdmi->ddc);
> + ret = drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
> + &dw_hdmi_connector_funcs,
> + DRM_MODE_CONNECTOR_HDMIA,
> + hdmi->ddc);
> + if (ret)
> + return ret;
> +
> + drm_bridge_get(&hdmi->bridge);
I'm not fully following the code paths, but both the report and the fix
make sense to me. Only I'd move the drm_bridge_get() before
drm_connector_init_with_ddc(), to avoid a short window where no reference
is held and the bridge might be destroyed before drm_bridge_get() is
called. I'm not sure this can happen, but it's better to write the code in
a way that clearly makes it impossible.
Otherwise looks good.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 18/24] iommu/arm-smmu-v3: Introduce master->ats_broken flag
From: Jason Gunthorpe @ 2026-05-19 12:06 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: <49dde0a2e2dc88e421a3010956db33d47cc92aa8.1779161849.git.nicolinc@nvidia.com>
On Mon, May 18, 2026 at 08:39:01PM -0700, Nicolin Chen wrote:
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index cde2ff2dcc49b..638956e2535b4 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2429,6 +2429,10 @@ static int arm_smmu_atc_inv_master(struct arm_smmu_master *master,
> struct arm_smmu_cmd cmd;
> struct arm_smmu_cmdq_batch cmds;
>
> + /* Do not issue ATC_INV that will definitely time out */
> + if (READ_ONCE(master->ats_broken))
> + return 0;
> +
> cmd = arm_smmu_make_cmd_atc_inv_all(0, IOMMU_NO_PASID);
> arm_smmu_cmdq_batch_init_cmd(master->smmu, &cmds, &cmd);
> for (i = 0; i < master->num_streams; i++)
> @@ -2651,12 +2655,18 @@ static void __arm_smmu_domain_inv_range(struct arm_smmu_invs *invs,
> cur->id));
> break;
> case INV_TYPE_ATS:
> + /* Do not issue ATC_INV that will definitely time out */
> + if (READ_ONCE(cur->master->ats_broken))
> + break;
Yuk, this should be a bool in the invs list, not the master.
If the flow is to have the core code always attach a blocked domain before
reset_done then the invs list will naturally fix itself.
> @@ -3007,6 +3027,14 @@ static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
> if (!(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS))
> return false;
>
> + /*
> + * Do not enable ATS if master->ats_broken is set. The PCI device should
> + * go through a recovery (reset) that shall notify the SMMUv3 driver via
> + * a reset_device_done callback.
> + */
Should just fail attach of paging domains at this point, the core code
should arguably be preventing races like this. Attaching a paging
domain in a broken way is going to create more problems.
Jason
^ permalink raw reply
* Re: [PATCH] [v2] iommu, debugobjects: avoid gcc-16.1 section mismatch warnings
From: Will Deacon @ 2026-05-19 12:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Joerg Roedel, Miguel Ojeda, Andrew Morton, Thomas Gleixner,
Nathan Chancellor, Arnd Bergmann, linux-kbuild, stable,
Robin Murphy, Kees Cook, linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <20260513145425.1579430-1-arnd@kernel.org>
On Wed, May 13, 2026 at 04:53:54PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> gcc-16 has gained some more advanced inter-procedual optimization
> techniques that enable it to inline the dummy_tlb_add_page() and
> dummy_tlb_flush() function pointers into a specialized version of
> __arm_v7s_unmap:
>
> WARNING: modpost: vmlinux: section mismatch in reference: __arm_v7s_unmap+0x2cc (section: .text) -> dummy_tlb_add_page (section: .init.text)
> ERROR: modpost: Section mismatches detected.
>
> From what I can tell, the transformation is correct, as this is only
> called when __arm_v7s_unmap() is called from arm_v7s_do_selftests(),
> which is also __init. Since __arm_v7s_unmap() however is not __init,
> gcc cannot inline the inner function calls directly.
>
> In debug_objects_selftest(), the same thing happens. Both the
> caller and the leaf function are __init, but the IPA pulls
> it into a non-init one:
>
> WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc+0x7c (section: .text.lookup_object_or_alloc) -> is_static_object (section: .init.text)
>
> Marking the affected functions as not "__init" would reliably avoid this
> issue but is not a good solution because it removes an otherwise correct
> annotation. I tried marking the functions as 'noinline', but that ended
> up not covering all the affected configurations.
>
> With some more experimenting, I found that marking these functions as
> __attribute__((noipa)) is both logical and reliable.
>
> In order to keep the syntax readable, add a custom macro for this in
> include/linux/compiler_attributes.h next to other related macros and
> use it to annotate both files.
>
> Link: https://lore.kernel.org/all/abRB6g-48ZX6Yl2r@willie-the-truck/
> Cc: Will Deacon <will@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Cc: linux-kbuild@vger.kernel.org
> Cc: stable@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: I merged both patches into one, to simplify the dependency
> on the new compiler_attributes.h macro.
> ---
> drivers/iommu/io-pgtable-arm-v7s.c | 18 ++++++++++++------
> include/linux/compiler_attributes.h | 11 +++++++++++
> lib/debugobjects.c | 2 +-
> 3 files changed, 24 insertions(+), 7 deletions(-)
For the io-pgtable change:
Acked-by: Will Deacon <will@kernel.org>
Thanks, Arnd.
Will
^ permalink raw reply
* Re: [PATCH v4 17/24] iommu/arm-smmu-v3: Add master in arm_smmu_inv for ATS entries
From: Jason Gunthorpe @ 2026-05-19 12:01 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: <2ea9edeaf0b23840670c62a57e71e7cf73f41ad6.1779161849.git.nicolinc@nvidia.com>
On Mon, May 18, 2026 at 08:39:00PM -0700, Nicolin Chen wrote:
> Storing the master pointer allows backtracking it from an ATS invalidation
> entry, which will be useful when handling ATC invalidation timeouts.
>
> Don't simply swap the "smmu" pointer for the "master": a non-ATS entry may
> be shared across multiple devices (masters). An ATS entry is okay since it
> is tied to a unique SID.
>
> Master must outlive any concurrent RCU reader iterating the domain->invs,
> because inv->master is dereferenced inside the read-side critical section.
>
> Add a synchronize_rcu() in arm_smmu_release_device() before freeing master.
>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 14 +++++++++++---
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index 604f7edf54158..df6e539f75274 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -738,6 +738,7 @@ enum arm_smmu_inv_type {
>
> struct arm_smmu_inv {
> struct arm_smmu_device *smmu;
> + struct arm_smmu_master *master; /* INV_TYPE_ATS* */
I don't like this and the locking for just a slow error case.. You
should use the SID for this and have a spinlocked ATS master list to
search for the SID.
Jason
^ permalink raw reply
* Re: [PATCH v6 2/2] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ2 in host handler
From: Fuad Tabba @ 2026-05-19 11:59 UTC (permalink / raw)
To: perlarsen
Cc: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Yeoreum Yun, Ben Horgan,
Oliver Upton, Armelle Laine, Sebastien Ene, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <20260501-host-direct-messages-v6-2-3f4af727ed85@google.com>
Hi Per,
On Fri, 1 May 2026 at 06:34, Per Larsen via B4 Relay
<devnull+perlarsen.google.com@kernel.org> wrote:
>
> From: Per Larsen <perlarsen@google.com>
>
> FF-A 1.2 adds the DIRECT_REQ2 messaging interface which is similar to
> the existing FFA_MSG_SEND_DIRECT_{REQ,RESP} functions and can use the
> existing handler function. Add support for FFA_MSG_SEND_DIRECT_REQ2 in
> the host ffa handler.
>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Signed-off-by: Per Larsen <perlarsen@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 3a58e01d255f..e5718c0f1c31 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -684,11 +684,12 @@ static bool ffa_call_supported(u64 func_id)
> case FFA_NOTIFICATION_GET:
> case FFA_NOTIFICATION_INFO_GET:
> /* Optional interfaces added in FF-A 1.2 */
> - case FFA_MSG_SEND_DIRECT_REQ2: /* Optional per 7.5.1 */
> case FFA_MSG_SEND_DIRECT_RESP2: /* Optional per 7.5.1 */
> case FFA_CONSOLE_LOG: /* Optional per 13.1: not in Table 13.1 */
> case FFA_PARTITION_INFO_GET_REGS: /* Optional for virtual instances per 13.1 */
> return false;
> + case FFA_MSG_SEND_DIRECT_REQ2: /* Optional per 7.5.1 */
> + return hyp_ffa_version >= FFA_VERSION_1_2;
> }
>
> return true;
> @@ -865,6 +866,7 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
> static void do_ffa_direct_msg(struct arm_smccc_1_2_regs *res,
> struct kvm_cpu_context *ctxt)
> {
> + DECLARE_REG(u64, func_id, ctxt, 0);
> DECLARE_REG(u32, endp, ctxt, 1);
> DECLARE_REG(u32, flags, ctxt, 2);
>
> @@ -875,8 +877,12 @@ static void do_ffa_direct_msg(struct arm_smccc_1_2_regs *res,
> return;
> }
>
> - /* filter out framework messages and validate SBZ/MBZ bits */
> - if (flags) {
> + /*
> + * filter out framework messages and validate SBZ/MBZ flag bits.
> + * FFA_MSG_SEND_DIRECT_REQ2 implies flag-less partition message.
> + */
> + if ((func_id == FFA_MSG_SEND_DIRECT_REQ ||
> + func_id == FFA_FN64_MSG_SEND_DIRECT_REQ) && flags) {
I don't have much experience with FFA, however, Sashiko flagged this
[1], and I think it found a real issue.
handle_host_smc() in hyp-main.c clears ARM_SMCCC_CALL_HINTS from its
local func_id and rejects calls with non-zero x0[63:32] before
dispatching here, so the upper bits (u64) aren't the issue. The issue is
that the hint-bit clear in handle_host_smc() only touches the local variable.
host_ctxt->regs.regs[0] still carries whatever the host wrote.
The DECLARE_REG() you added re-reads the raw X0 from ctxt, so the
SVE_HINT bit (0x10000) reappears. With the host setting that bit,
func_id becomes 0x8401006F and the equality test against
FFA_MSG_SEND_DIRECT_REQ (0x8400006F) falls through, skipping the
flags check. Note this isn't u64-specific -- u32 would capture the
same bit.
I think it's safest to pass the canonicalised func_id from
kvm_host_ffa_handler() rather than re-deriving here, matching the
__do_ffa_mem_xfer() style.
Cheers,
/fuad
https://sashiko.dev/#/patchset/20260501-host-direct-messages-v6-0-3f4af727ed85%40google.com
> ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
> return;
> }
> @@ -942,6 +948,10 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> case FFA_PARTITION_INFO_GET:
> do_ffa_part_get(&res, host_ctxt);
> goto out_handled;
> + case FFA_MSG_SEND_DIRECT_REQ2:
> + if (!ffa_call_supported(func_id))
> + goto out_not_supported;
> + fallthrough;
> case FFA_MSG_SEND_DIRECT_REQ:
> case FFA_FN64_MSG_SEND_DIRECT_REQ:
> do_ffa_direct_msg(&res, host_ctxt);
> @@ -951,6 +961,7 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> if (ffa_call_supported(func_id))
> return false; /* Pass through */
>
> +out_not_supported:
> ffa_to_smccc_error(&res, FFA_RET_NOT_SUPPORTED);
> out_handled:
> ffa_set_retval(host_ctxt, &res);
>
> --
> 2.54.0.545.g6539524ca2-goog
>
>
>
^ 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
* 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
* 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] 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] 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 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 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] 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
* [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
* [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 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 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 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 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
* 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
* 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
* [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
* [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
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