* Re: [PATCH v2 08/13] firmware: arm_scmi: Harden clock protocol initialization
From: Nicolas Frattaroli @ 2026-04-24 12:07 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, arm-scmi, linux-clk,
linux-renesas-soc, Cristian Marussi
Cc: sudeep.holla, philip.radford, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
dan.carpenter, geert+renesas, kuninori.morimoto.gx,
marek.vasut+renesas, Cristian Marussi
In-Reply-To: <20260310184030.3669330-9-cristian.marussi@arm.com>
On Tuesday, 10 March 2026 19:40:25 Central European Summer Time Cristian Marussi wrote:
> Add proper error handling on failure to enumerate clocks features or
> rates.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> drivers/firmware/arm_scmi/clock.c | 22 ++++++++++++++++------
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
> index c9b62edce4fd..bf956305a8fe 100644
> --- a/drivers/firmware/arm_scmi/clock.c
> +++ b/drivers/firmware/arm_scmi/clock.c
> @@ -402,10 +402,16 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
> SUPPORTS_RATE_CHANGE_REQUESTED_NOTIF(attributes))
> clk->rate_change_requested_notifications = true;
> if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
> - if (SUPPORTS_PARENT_CLOCK(attributes))
> - scmi_clock_possible_parents(ph, clk_id, cinfo);
> - if (SUPPORTS_GET_PERMISSIONS(attributes))
> - scmi_clock_get_permissions(ph, clk_id, clk);
> + if (SUPPORTS_PARENT_CLOCK(attributes)) {
> + ret = scmi_clock_possible_parents(ph, clk_id, cinfo);
> + if (ret)
> + return ret;
> + }
> + if (SUPPORTS_GET_PERMISSIONS(attributes)) {
> + ret = scmi_clock_get_permissions(ph, clk_id, clk);
> + if (ret)
> + return ret;
> + }
> if (SUPPORTS_EXTENDED_CONFIG(attributes))
> clk->extended_config = true;
> }
> @@ -1143,8 +1149,12 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
> for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
> cinfo->clkds[clkid].id = clkid;
> ret = scmi_clock_attributes_get(ph, clkid, cinfo);
> - if (!ret)
> - scmi_clock_describe_rates_get(ph, clkid, cinfo);
> + if (ret)
> + return ret;
> +
> + ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
> + if (ret)
> + return ret;
> }
>
> if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
>
I see that a quirk is being added for this, but I thought I should chime
in with my opinion for future approaches in this direction.
I don't see how this hardens anything. All this does is break platforms
that were previously working by returning early. At most, this should
be a warning (as in not WARN but pr_warn/dev_warn/...). If firmware
returns nonsense, a clock driver should imho try its best to work
around the nonsense in a safe way, because the alternative is that
a major part of the system (and thus likely the entire system) no
longer works. It's basically the same reason why we avoid BUG(): sure,
you prevented a problem, but you tore down the entire system to tell
the user about it.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Geert Uytterhoeven @ 2026-04-24 12:08 UTC (permalink / raw)
To: Cristian Marussi
Cc: Sudeep Holla, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Saravana Kannan, Michael Turquette, Stephen Boyd,
Philipp Zabel, Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
Florian Fainelli, Wolfram Sang, Marek Vasut, Kuninori Morimoto,
arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel
In-Reply-To: <aekXUvIPb8nkhdKu@pluto>
Hi Cristian,
On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Tue, Apr 21, 2026 at 08:11:38PM +0200, Geert Uytterhoeven wrote:
> > Currently non-SCMI drivers cannot find out what the specific versions of
> > each SCMI provider implementation on the running system are.
>
> Thanks for your patches....this is not a proper full review of the series,
> BUT this patch catched my eye..
>
> Indeed, yes, it is deliberate that the SCMI version information is NOT
> exposed out of the SCMI world, since being the SCMI an attempt to
> standardize a common FW interface (as in [1] of course), you should not
> know what runs inside the black-box, it should be irrelevant...
>
> ...indeed the versioning is used inside the SCMI stack to deal properly
> with different protocol versions implemented by the server OR to apply
> proper quirks when needed, but all the rest should be standard....
>
> ...you should NOT really behave differently based on the underneath
> protocol or firmare implementation version...it is the SCMI stack that
> should behave properly, transparently...
Oh well...
> Having said that...I understand that at least it could be useful to be able
> to query the SCMI stack to know, even from non-SCMI drivers, WHICH quirks
> have been applied/activated at run time...but anything more than that it
I see no need for that, but we can discover which quirks have been
applied from the kernel log ;-)
> seems to me dangerous and prone to a number of abuses of the SCMI stack
> itself...
>
> (Also...exposing the versions itself means also tracking that bit of info
> in more than one place: the quirk framework and your drivers.)
I'll see if I can get everything handled as quirks instead...
> > However, different versions may use different ABIs (e.g. different clock
> > IDs), or behave different, requiring remapping or workarounds in other
> > drivers.
>
> ...abuse like this indeed :P ... the SCMI server is supposed to be that
> one entity remapping the IDs in the background if the same IDs happen to
> be representing different physical resources across a number of distinct
> platforms all supported by the same firmware blob...so as to present
> a consistent set of contiguos IDs...
In our case it is just a single platform, with different ID number
spaces for different firmware versions.
> Also because this should be one of the selling point of the SCMI stack
> in a virtualized environment: you can ship the same kernel drivers with
> the same DT and you know that ID=<N> will always identify the specific
> resource that is needed by your driver without worrying about the fact
> that in reality in the backstage the effectively managed physical resource
> could be different across different platforms, because that does not matter
This sounds strange to me, do I understand it correctly?
So the ID should (1) be tied to the use-case, and not to the underlying
hardware, and (2) be the same for different platforms?
For (1): Then we must not put these IDs in DT at all, as DT is supposed
to describe the hardware (and firmware IDs in DT were IMHO already
a stretch before).
For (2): How can there be a contiguous list of IDs, as not all platforms
may have the same underlying hardware?
> if the SCMI platform server had properly remapped (at build time/run-time ?)
> the resources to your expected ID...alternatively of course you can ship
> with different DTs to describe different hardware...BUT remmapping stuff
That is a different issue: as SCMI covers the full platform, not just
the SoC, the IDs can be board-specific, and thus should be specified
in the board .dts, not in the SoC .dtsi?
Then the SoC .dtsi should describe the hardware, and we end up with
things like arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts?
> in the drivers themselves guessing on the vendor/subvendor/impl_vers
> seems a dangerous abuse...
There is no guessing.
> I watched a bit of the LPC discussions around this (from Marek I think)
> but sincerely most of those problems had one (not necessarily simple)
> solution: fix your firmwares AND/OR apply quirks in the meantime...
Unfortunately (at this point) we have to work with the firmware that exists.
From that LPC discussion, we learned that we are actually the lucky
guys: some other vendors tend to change the IDs and/or behavior without
bumping the version, so Linux cannot even act upon that...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/1] arm: traps: remove fp underflow checking
From: Russell King (Oracle) @ 2026-04-24 12:21 UTC (permalink / raw)
To: Maninder Singh
Cc: linus.walleij, ardb, ndesaulniers, linux-arm-kernel, linux-kernel
In-Reply-To: <20260424043029.4101133-1-maninder1.s@samsung.com>
On Fri, Apr 24, 2026 at 10:00:29AM +0530, Maninder Singh wrote:
> with IRQSTACKS fp can point outside of thread's stack.
> And when there is crash reported from IRQ side, it always report
> "frame pointer underflow", which is not real underflow.
>
> Unhandled fault: page domain fault (0x81b) at 0x00000000
> ..
> PC is at handle_irq_desc+0x68/0xa4
> LR is at generic_handle_domain_irq+0x18/0x1c
> ..
>
> Call trace: frame pointer underflow
> handle_irq_desc from generic_handle_domain_irq+0x18/0x1c
> generic_handle_domain_irq from gic_handle_irq+0x78/0x8c
> gic_handle_irq from generic_handle_arch_irq+0x3c/0x4c
> ..
>
> It is just warning print and there is no decision based on this
> to stop backtrack or etc. So it can be removed.
Please find a way to check whether the frame pointer is within the
IRQ stack rather than removing this.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: (subset) [PATCH 1/3] KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value
From: David Woodhouse @ 2026-04-24 12:24 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Shuah Khan, Raghavendra Rao Ananta, Eric Auger, Kees Cook,
Arnd Bergmann, Nathan Chancellor, linux-arm-kernel, kvmarm,
linux-kernel, kvm, linux-kselftest
In-Reply-To: <177702878141.537738.13460155220731277452.b4-ty@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]
On Fri, 2026-04-24 at 12:07 +0100, Marc Zyngier wrote:
> On Tue, 07 Apr 2026 21:27:02 +0100, David Woodhouse wrote:
> > The uaccess write handlers for GICD_IIDR in both GICv2 and GICv3
> > extract the revision field from 'reg' (the current IIDR value read back
> > from the emulated distributor) instead of 'val' (the value userspace is
> > trying to write). This means userspace can never actually change the
> > implementation revision — the extracted value is always the current one.
> >
> > Fix the FIELD_GET to use 'val' so that userspace can select a different
> > revision for migration compatibility.
> >
> > [...]
>
> Applied to fixes, thanks!
>
> [1/3] KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value
> commit: a0e6ae45af17e8b27958830595799c702ffbab8d
There was a v2 of this series which also cleaned up the weird
inconsistency of the IIDR value with the actual behaviour, and which
fixed the fact that it's currently not possible to maintain guest
compatibility when upgrading from a pre-d53c2c29ae0d kernel to a new
one — despite the fact that that kind of compatibility is *precisely*
what the revision field in the IIDR is designed for.
https://lore.kernel.org/all/20260408113256.2095505-1-dwmw2@infradead.org/
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v22 3/8] dt-bindings: display: bridge: Add Cadence MHDP8501
From: Rob Herring (Arm) @ 2026-04-24 12:31 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Krzysztof Kozlowski, dri-devel, Jonas Karlman, Maarten Lankhorst,
linux-kernel, Thomas Zimmermann, Jernej Skrabec, Neil Armstrong,
Simona Vetter, linux-arm-kernel, Maxime Ripard, imx, linux,
devicetree, linux-phy, Alexander Stein, Robert Foss, Conor Dooley,
Ying Liu, Laurent Pinchart, David Airlie, Andrzej Hajda
In-Reply-To: <20260424-dcss-hdmi-upstreaming-v22-3-30a28f89298d@oss.nxp.com>
On Fri, 24 Apr 2026 11:07:16 +0000, Laurentiu Palcu wrote:
> From: Sandor Yu <Sandor.yu@nxp.com>
>
> Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
>
> Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
> .../bindings/display/bridge/cdns,mhdp8501.yaml | 135 +++++++++++++++++++++
> 1 file changed, 135 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml: Unresolvable reference: /schemas/phy/fsl,imx8mq-hdptx-phy.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.example.dtb: display-bridge@32c00000 (fsl,imx8mq-mhdp8501): phy: False schema does not allow {'compatible': ['fsl,imx8mq-hdptx-phy'], '#phy-cells': 0, 'clocks': [[4294967295], [4294967295, 248]], 'clock-names': ['ref', 'apb'], 'phandle': 2}
from schema $id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.example.dtb: /example-0/display-bridge@32c00000/phy: failed to match any schema with compatible: ['fsl,imx8mq-hdptx-phy']
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260424-dcss-hdmi-upstreaming-v22-3-30a28f89298d@oss.nxp.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH v2 1/2] i2c: imx: Don't recover bus when arbitration lost
From: Daniel Scally @ 2026-04-24 12:36 UTC (permalink / raw)
To: Oleksij Rempel, Pengutronix Kernel Team, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Gao Pan, Fugang Duan, Wolfram Sang
Cc: linux-i2c, imx, linux-arm-kernel, Daniel Scally
In-Reply-To: <20260424-i2c-imx-fixes-v2-0-34fb9504aaeb@ideasonboard.com>
In i2c_imx_xfer_common(), the driver attempts bus recovery whenever
i2c_imx_start() fails. One of the failure modes for i2c_imx_start()
is an arbitration-lost signal which results when a second I2C master
on the bus tries to control the bus simultaneously, which is a normal
and expected behaviour.
Bus recovery is not the right response for this case. Add a check for
the -EAGAIN return code to avoid running the bus recovery.
Fixes: 1c4b6c3bcf30d ("i2c: imx: implement bus recovery")
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
---
drivers/i2c/busses/i2c-imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index a208fefd3c3b35672a00eda8448f24859aaa793a..b68a0f7105682006bbcfee52891c9a9c2d8c009e 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1552,7 +1552,7 @@ static int i2c_imx_xfer_common(struct i2c_adapter *adapter,
/* Start I2C transfer */
result = i2c_imx_start(i2c_imx, atomic);
- if (result) {
+ if (result && result != -EAGAIN) {
/*
* Bus recovery uses gpiod_get_value_cansleep() which is not
* allowed within atomic context.
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] i2c: imx: Retry failed transfers 3 times
From: Daniel Scally @ 2026-04-24 12:36 UTC (permalink / raw)
To: Oleksij Rempel, Pengutronix Kernel Team, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Gao Pan, Fugang Duan, Wolfram Sang
Cc: linux-i2c, imx, linux-arm-kernel, Daniel Scally
In-Reply-To: <20260424-i2c-imx-fixes-v2-0-34fb9504aaeb@ideasonboard.com>
Set the retries member of the i2c_adapter to 3, which will cause the
i2c-core code to retry transfers that lose arbitration 3 times before
giving up.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
---
drivers/i2c/busses/i2c-imx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index b68a0f7105682006bbcfee52891c9a9c2d8c009e..e70e64cc633ff1e13dc61920c0c7960fb6a02622 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1749,6 +1749,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
i2c_imx->adapter.dev.parent = &pdev->dev;
i2c_imx->adapter.nr = pdev->id;
i2c_imx->adapter.dev.of_node = pdev->dev.of_node;
+ i2c_imx->adapter.retries = 3;
i2c_imx->base = base;
ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] Minor changes for i2c-imx driver
From: Daniel Scally @ 2026-04-24 12:36 UTC (permalink / raw)
To: Oleksij Rempel, Pengutronix Kernel Team, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Gao Pan, Fugang Duan, Wolfram Sang
Cc: linux-i2c, imx, linux-arm-kernel, Daniel Scally
Hello all
These small changes helped resolve issues we experienced using the
i2c-imx driver on a multi-master bus. The device was losing
arbitration which triggered the driver to attempt to recover the bus
rather than retry the transfer. The set stops the bus recovery
attempts on lost arbitration and instructs the driver to retry
transfers 3 times, which seems sufficient for our setup.
I had intended to make a larger change that added a new devicetree
property for i2c-controller.yaml that held the number of retries an
adapter should use, and then parse that to set adap->retries. I found
a relatively old discussion on the list though in which a similar
idea was discussed and rejected so I dropped that, but I thought I'd
mention it in case things had changed.
Thanks
Dan
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
---
Changes in v2:
- Updated the commit message in v1, and added a Fixes tag.
- Link to v1: https://lore.kernel.org/r/20260311-i2c-imx-fixes-v1-0-e625034d8202@ideasonboard.com
---
Daniel Scally (2):
i2c: imx: Don't recover bus when arbitration lost
i2c: imx: Retry failed transfers 3 times
drivers/i2c/busses/i2c-imx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
---
base-commit: 4a181746639404023abfcb28eb6f6c66974be5a7
change-id: 20260311-i2c-imx-fixes-3e23164a8a8f
Best regards,
--
Daniel Scally <dan.scally@ideasonboard.com>
^ permalink raw reply
* [PATCH net v3] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Daniel Golle @ 2026-04-24 12:37 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Russell King,
Christian Marangi, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
The .get_stats64 callback runs in atomic context, but on
MDIO-connected switches every register read acquires the MDIO bus
mutex, which can sleep:
[ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
[ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
[ 12.663377] preempt_count: 0, expected: 0
[ 12.667410] RCU nest depth: 1, expected: 0
[ 12.671511] INFO: lockdep is turned off.
[ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
[ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
[ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
[ 12.675459] Call trace:
[ 12.675462] show_stack+0x14/0x1c (C)
[ 12.675477] dump_stack_lvl+0x68/0x8c
[ 12.675487] dump_stack+0x14/0x1c
[ 12.675495] __might_resched+0x14c/0x220
[ 12.675504] __might_sleep+0x44/0x80
[ 12.675511] __mutex_lock+0x50/0xb10
[ 12.675523] mutex_lock_nested+0x20/0x30
[ 12.675532] mt7530_get_stats64+0x40/0x2ac
[ 12.675542] dsa_user_get_stats64+0x2c/0x40
[ 12.675553] dev_get_stats+0x44/0x1e0
[ 12.675564] dev_seq_printf_stats+0x24/0xe0
[ 12.675575] dev_seq_show+0x14/0x3c
[ 12.675583] seq_read_iter+0x37c/0x480
[ 12.675595] seq_read+0xd0/0xec
[ 12.675605] proc_reg_read+0x94/0xe4
[ 12.675615] vfs_read+0x98/0x29c
[ 12.675625] ksys_read+0x54/0xdc
[ 12.675633] __arm64_sys_read+0x18/0x20
[ 12.675642] invoke_syscall.constprop.0+0x54/0xec
[ 12.675653] do_el0_svc+0x3c/0xb4
[ 12.675662] el0_svc+0x38/0x200
[ 12.675670] el0t_64_sync_handler+0x98/0xdc
[ 12.675679] el0t_64_sync+0x158/0x15c
For MDIO-connected switches, poll MIB counters asynchronously using a
delayed workqueue every second and let .get_stats64 return the cached
values under a spinlock. A mod_delayed_work() call on each read
triggers an immediate refresh so counters stay responsive when queried
more frequently.
MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
because their regmap does not sleep, so they continue to read MIB
counters directly in .get_stats64.
Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
v3:
* move `stats_last` access under the spinlock to avoid potential race
v2:
* use spin_lock_bh()/spin_unlock_bh() to prevent potential deadlock
* rate-limit mod_delayed_work() refresh to at most once per 100ms
* move cancel_delayed_work_sync() after dsa_unregister_switch()
* add mt753x_teardown() callback to cancel the stats work
* fix commit message
drivers/net/dsa/mt7530.c | 69 ++++++++++++++++++++++++++++++++++++++--
drivers/net/dsa/mt7530.h | 8 +++++
2 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index b9423389c2ef..9733ff9fc322 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -25,6 +25,9 @@
#include "mt7530.h"
+#define MT7530_STATS_POLL_INTERVAL (1 * HZ)
+#define MT7530_STATS_RATE_LIMIT (HZ / 10)
+
static struct mt753x_pcs *pcs_to_mt753x_pcs(struct phylink_pcs *pcs)
{
return container_of(pcs, struct mt753x_pcs, pcs);
@@ -906,10 +909,9 @@ static void mt7530_get_rmon_stats(struct dsa_switch *ds, int port,
*ranges = mt7530_rmon_ranges;
}
-static void mt7530_get_stats64(struct dsa_switch *ds, int port,
- struct rtnl_link_stats64 *storage)
+static void mt7530_read_port_stats64(struct mt7530_priv *priv, int port,
+ struct rtnl_link_stats64 *storage)
{
- struct mt7530_priv *priv = ds->priv;
uint64_t data;
/* MIB counter doesn't provide a FramesTransmittedOK but instead
@@ -951,6 +953,48 @@ static void mt7530_get_stats64(struct dsa_switch *ds, int port,
&storage->rx_crc_errors);
}
+static void mt7530_stats_poll(struct work_struct *work)
+{
+ struct mt7530_priv *priv = container_of(work, struct mt7530_priv,
+ stats_work.work);
+ struct rtnl_link_stats64 stats = {};
+ struct dsa_port *dp;
+ int port;
+
+ dsa_switch_for_each_user_port(dp, priv->ds) {
+ port = dp->index;
+
+ mt7530_read_port_stats64(priv, port, &stats);
+
+ spin_lock_bh(&priv->stats_lock);
+ priv->ports[port].stats = stats;
+ priv->stats_last = jiffies;
+ spin_unlock_bh(&priv->stats_lock);
+ }
+
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+}
+
+static void mt7530_get_stats64(struct dsa_switch *ds, int port,
+ struct rtnl_link_stats64 *storage)
+{
+ struct mt7530_priv *priv = ds->priv;
+ bool refresh;
+
+ if (priv->bus) {
+ spin_lock_bh(&priv->stats_lock);
+ *storage = priv->ports[port].stats;
+ refresh = time_after(jiffies, priv->stats_last +
+ MT7530_STATS_RATE_LIMIT);
+ spin_unlock_bh(&priv->stats_lock);
+ if (refresh)
+ mod_delayed_work(system_wq, &priv->stats_work, 0);
+ } else {
+ mt7530_read_port_stats64(priv, port, storage);
+ }
+}
+
static void mt7530_get_eth_ctrl_stats(struct dsa_switch *ds, int port,
struct ethtool_eth_ctrl_stats *ctrl_stats)
{
@@ -3137,9 +3181,24 @@ mt753x_setup(struct dsa_switch *ds)
if (ret && priv->irq_domain)
mt7530_free_mdio_irq(priv);
+ if (!ret && priv->bus) {
+ spin_lock_init(&priv->stats_lock);
+ INIT_DELAYED_WORK(&priv->stats_work, mt7530_stats_poll);
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+ }
+
return ret;
}
+static void mt753x_teardown(struct dsa_switch *ds)
+{
+ struct mt7530_priv *priv = ds->priv;
+
+ if (priv->bus)
+ cancel_delayed_work_sync(&priv->stats_work);
+}
+
static int mt753x_set_mac_eee(struct dsa_switch *ds, int port,
struct ethtool_keee *e)
{
@@ -3257,6 +3316,7 @@ static int mt7988_setup(struct dsa_switch *ds)
static const struct dsa_switch_ops mt7530_switch_ops = {
.get_tag_protocol = mtk_get_tag_protocol,
.setup = mt753x_setup,
+ .teardown = mt753x_teardown,
.preferred_default_local_cpu_port = mt753x_preferred_default_local_cpu_port,
.get_strings = mt7530_get_strings,
.get_ethtool_stats = mt7530_get_ethtool_stats,
@@ -3409,6 +3469,9 @@ mt7530_remove_common(struct mt7530_priv *priv)
dsa_unregister_switch(priv->ds);
+ if (priv->bus)
+ cancel_delayed_work_sync(&priv->stats_work);
+
mutex_destroy(&priv->reg_mutex);
}
EXPORT_SYMBOL_GPL(mt7530_remove_common);
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 3e0090bed298..dd33b0df3419 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -796,6 +796,7 @@ struct mt7530_fdb {
* @pvid: The VLAN specified is to be considered a PVID at ingress. Any
* untagged frames will be assigned to the related VLAN.
* @sgmii_pcs: Pointer to PCS instance for SerDes ports
+ * @stats: Cached port statistics for MDIO-connected switches
*/
struct mt7530_port {
bool enable;
@@ -803,6 +804,7 @@ struct mt7530_port {
u32 pm;
u16 pvid;
struct phylink_pcs *sgmii_pcs;
+ struct rtnl_link_stats64 stats;
};
/* Port 5 mode definitions of the MT7530 switch */
@@ -875,6 +877,9 @@ struct mt753x_info {
* @create_sgmii: Pointer to function creating SGMII PCS instance(s)
* @active_cpu_ports: Holding the active CPU ports
* @mdiodev: The pointer to the MDIO device structure
+ * @stats_lock: Protects cached per-port stats from concurrent access
+ * @stats_work: Delayed work for polling MIB counters on MDIO switches
+ * @stats_last: Jiffies timestamp of last MIB counter poll
*/
struct mt7530_priv {
struct device *dev;
@@ -900,6 +905,9 @@ struct mt7530_priv {
int (*create_sgmii)(struct mt7530_priv *priv);
u8 active_cpu_ports;
struct mdio_device *mdiodev;
+ spinlock_t stats_lock; /* protects cached stats counters */
+ struct delayed_work stats_work;
+ unsigned long stats_last;
};
struct mt7530_hw_vlan_entry {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Catalin Marinas @ 2026-04-24 12:51 UTC (permalink / raw)
To: Jinjie Ruan
Cc: Thomas Gleixner, peterz, sudeep.holla, yangyicong,
dietmar.eggemann, Jonathan Cameron, linux-kernel, James Morse,
linux-arm-kernel
In-Reply-To: <c6fe5e31-c397-4cf1-a422-f8d1a28fe20b@huawei.com>
(updating Jonathan's email address to match MAINTAINERS)
On Fri, Apr 24, 2026 at 09:56:24AM +0800, Jinjie Ruan wrote:
> On 4/24/2026 4:11 AM, Catalin Marinas wrote:
> > On Thu, Apr 23, 2026 at 08:32:34PM +0800, Jinjie Ruan wrote:
> >> On 4/23/2026 6:08 PM, Thomas Gleixner wrote:
> >>> On Sat, Apr 18 2026 at 12:55, Catalin Marinas wrote:
> >>>> Another option would have been to avoid marking such CPUs present but I
> >>>> think this will break other things. Yet another option is to register
> >>>> all CPU devices even if they never come up (like maxcpus greater than
> >>>> actual CPUs).
> >>>>
> >>>> Opinions? It might be an arm64+ACPI-only thing.
> >>>
> >>> I think so. The proper thing to do is to apply sane limits:
> >>>
> >>> 1) The possible CPUs enumerated by firmware N_POSSIBLE_FW
> >>>
> >>> 2) The maxcpus limit on the command line N_MAXCPUS_CL
> >>>
> >>> So the actual possible CPUs evaluates to:
> >>>
> >>> num_possible = min(N_POSSIBLE_FW, N_MAXCPUS_CL, CONFIG_NR_CPUS);
> >>>
> >>> The evaluation of the firmware should not mark CPUs present which are
> >>> actually not. ACPI gives you that information. See:
> >>>
> >>> 5.2.12.14 GIC CPU Interface (GICC) Structure
> >>>
> >>> in the ACPI spec. That has two related bits:
> >>>
> >>> Enabled:
> >>>
> >>> If this bit is set, the processor is ready for use. If this bit is
> >>> clear and the Online Capable bit is set, the system supports enabling
> >>> this processor during OS runtime. If this bit is clear and the Online
> >>> Capable bit is also clear, this processor is un- usable, and the
> >>> operating system support will not attempt to use it.
> >>>
> >>> Online Capable:
> >>>
> >>> The information conveyed by this bit depends on the value of the
> >>> Enabled bit. If the Enabled bit is set, this bit is reserved and must
> >>> be zero. Otherwise, if this bit is set, the system supports enabling
> >>> this processor later during OS runtime
> >>>
> >>> So the combination of those gives you the right answer:
> >>>
> >>> Enabled Online
> >>> Capable
> >>> 0 0 Not present, not possible
> >>> 0 1 Not present, but possible to "hotplug" layter
> >>> 1 0 Present
> >>> 1 1 Invalid
> >>
> >> On x86, it seems that all CPUs with the ACPI_MADT_ENABLED bit set will
> >> be marked as present.
> >>
> >> acpi_parse_x2apic()
> >> -> enabled = processor->lapic_flags & ACPI_MADT_ENABLED
> >> -> topology_register_apic(enabled)
> >> -> topo_register_apic(enabled)
> >> -> set_cpu_present(cpu, true)
> >
> > Yes but arm64 marks all CPUs present even if !ACPI_MADT_ENABLED as we
> > don't have the notion of hardware CPU hotplug.
> >
> > I need to dig some more into the original vCPU hotplug support and why
> > we ended up with all CPUs marked as present even if not calling
> > register_cpu():
> >
> > https://lore.kernel.org/linux-arm-kernel/20240529133446.28446-1-Jonathan.Cameron@huawei.com/
> >
> > What's the MADT GICC provided by qemu with "-smp cpus=4,maxcpus=8"? If
> > it says Enabled for the first 4 and Online Capable for the rest, maybe
> > we can try something like below:
>
> Yes, you are absolutely right,Enabled for the first 4(with GIC Flags:
> 0x1, bit0 set) and Online Capable for the rest(with GIC Flags: 0x8, bit3
> set). The ACPI MADT disassembly result is as follows:
That's great, thanks for checking.
I'd like to get some feedback from Jonathan and James as they
contributed the vCPU hotplug support. The reason was for kubernetes to
add vCPUs to an existing VM. Hopefully no-one relied on
/sys/devices/system/cpu/present to report 0-7 in the above
configuration.
Have you tried the vCPU hotplug with this patch (the original use-case)?
Anyway, feel free to post a v2 with the above proposal, cc Jonathan (on
kernel.org) and James Morse and we'll take it from there. You can add a
suggested-by me.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH v3 05/11] iommu: Change group->devices to RCU-protected list
From: Jason Gunthorpe @ 2026-04-24 13:11 UTC (permalink / raw)
To: Nicolin Chen
Cc: Baolu Lu, Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Kevin Tian, linux-arm-kernel, iommu, linux-kernel, linux-acpi,
linux-pci, vsethi, Shuai Xue
In-Reply-To: <aerey+ULGG589rdi@Asurada-Nvidia>
On Thu, Apr 23, 2026 at 08:08:59PM -0700, Nicolin Chen wrote:
> On Fri, Apr 24, 2026 at 10:53:49AM +0800, Baolu Lu wrote:
> > On 4/17/26 07:28, Nicolin Chen wrote:
> > mutex_unlock(&group->mutex);
> > /*
> > * FIXME: Mis-locked because the ops->probe_finalize() call-back
> > * of some IOMMU drivers calls arm_iommu_attach_device() which
> > * in-turn might call back into IOMMU core code, where it tries
> > * to take group->mutex, resulting in a deadlock.
> > */
> > for_each_group_device(group, gdev)
> > iommu_group_do_probe_finalize(gdev->dev);
> > }
> >
> > return 0;
> > }
> >
> > Will the change above trigger a lockdep splat due to this "mis-locked"
> > case?"
>
> Oh, I missed this one. That's a good finding!
>
> Perhaps we can just change it to list_for_each_entry_rcu holding
> rcu_read_lock() and drop the FIXME.
You can't hold rcu across that function IIRC
Jason
^ permalink raw reply
* [RFC PATCH v3 0/4] Fix IMA + TPM initialisation ordering issue
From: Jonathan McDowell @ 2026-04-24 13:23 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene, Yeoreum Yun
This is a slight reworking of the series from Yeoreum Yun, adding
functionality for IMA initialisation during the late_initcall_sync
stage. This solves the situation where the TPM is not fully registered
at the point IMA wants to initialise, avoiding a failure to correctly
extend TPM measurements from IMA. This has been observed on both Arm
FF-A and SPI attached TPM setups.
As part of this series we also revert the original changes made to the
FF-A driver to try and solve this problem.
(I have left Yeoreum credited in all the diffs except my rework of the
IMA piece. Yeoreum, please yell if you're not happy with this.)
Patch history
=============
from v2 to v3:
- Drop ff-a/pKVM diff (this seems to have a separate set of
discussion)
- Rework IMA delayed initialisation to avoid delaying when unnecessary
- Ensure IMA log clearly indicates when we've initialised late
from v1 to v2:
- add notifier to make ffa-driver pkvm initialised.
- modify to try initailisation again when IMA coudln't find proper TPM device.
- https://lore.kernel.org/all/20260417175759.3191279-1-yeoreum.yun@arm.com/#t
Jonathan McDowell (1):
security: ima: call ima_init() again at late_initcall_sync for defered
TPM
Yeoreum Yun (3):
lsm: Allow LSMs to register for late_initcall_sync init
Revert "tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in"
Revert "firmware: arm_ffa: Change initcall level of ffa_init() to
rootfs_initcall"
drivers/char/tpm/tpm_crb_ffa.c | 19 ++----------
drivers/firmware/arm_ffa/driver.c | 2 +-
include/linux/lsm_hooks.h | 2 ++
security/integrity/ima/ima.h | 3 +-
security/integrity/ima/ima_init.c | 25 ++++++++-------
security/integrity/ima/ima_main.c | 37 ++++++++++++++++++++---
security/integrity/ima/ima_template_lib.c | 3 +-
security/lsm_init.c | 13 ++++++--
8 files changed, 67 insertions(+), 37 deletions(-)
--
2.53.0
^ permalink raw reply
* [RFC PATCH v3 1/4] lsm: Allow LSMs to register for late_initcall_sync init
From: Jonathan McDowell @ 2026-04-24 13:24 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene, Yeoreum Yun
In-Reply-To: <cover.1777036497.git.noodles@meta.com>
From: Yeoreum Yun <yeoreum.yun@arm.com>
There are situations where LSMs have dependencies that might mean they
want to be initialised later in the boot process, to ensure those
dependencies are available. In particular there are some TPM setups (Arm
FF-A devices, SPI attached TPMs) required by IMA which are not
guaranteed to be initialised for regular initcall_late.
Add an initcall_late_sync option that can be used in these situations.
[noodles: Split out from actual IMA changes]
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Jonathan McDowell <noodles@meta.com>
---
include/linux/lsm_hooks.h | 2 ++
security/lsm_init.c | 13 +++++++++++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index d48bf0ad26f4..88fe105b7f00 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -166,6 +166,7 @@ enum lsm_order {
* @initcall_fs: LSM callback for fs_initcall setup, optional
* @initcall_device: LSM callback for device_initcall() setup, optional
* @initcall_late: LSM callback for late_initcall() setup, optional
+ * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
*/
struct lsm_info {
const struct lsm_id *id;
@@ -181,6 +182,7 @@ struct lsm_info {
int (*initcall_fs)(void);
int (*initcall_device)(void);
int (*initcall_late)(void);
+ int (*initcall_late_sync)(void);
};
#define DEFINE_LSM(lsm) \
diff --git a/security/lsm_init.c b/security/lsm_init.c
index 573e2a7250c4..4e5c59beb82a 100644
--- a/security/lsm_init.c
+++ b/security/lsm_init.c
@@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
* security_initcall_late - Run the LSM late initcalls
*/
static int __init security_initcall_late(void)
+{
+ return lsm_initcall(late);
+}
+late_initcall(security_initcall_late);
+
+/**
+ * security_initcall_late_sync - Run the LSM late initcalls sync
+ */
+static int __init security_initcall_late_sync(void)
{
int rc;
- rc = lsm_initcall(late);
+ rc = lsm_initcall(late_sync);
lsm_pr_dbg("all enabled LSMs fully activated\n");
call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
return rc;
}
-late_initcall(security_initcall_late);
+late_initcall_sync(security_initcall_late_sync);
--
2.53.0
^ permalink raw reply related
* [RFC PATCH v3 2/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Jonathan McDowell @ 2026-04-24 13:24 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene, Yeoreum Yun
In-Reply-To: <cover.1777036497.git.noodles@meta.com>
From: Jonathan McDowell <noodles@meta.com>
The Linux IMA (Integrity Measurement Architecture) subsystem used for
secure boot, file integrity, or remote attestation cannot be a loadable
module for few reasons listed below:
o Boot-Time Integrity: IMA’s main role is to measure and appraise files
before they are used. This includes measuring critical system files
during early boot (e.g., init, init scripts, login binaries). If IMA
were a module, it would be loaded too late to cover those.
o TPM Dependency: IMA integrates tightly with the TPM to record
measurements into PCRs. The TPM must be initialized early (ideally
before init_ima()), which aligns with IMA being built-in.
o Security Model: IMA is part of a Trusted Computing Base (TCB). Making
it a module would weaken the security model, as a potentially
compromised system could delay or tamper with its initialization.
IMA must be built-in to ensure it starts measuring from the earliest
possible point in boot which inturn implies TPM must be initialised and
ready to use before IMA.
Unfortunately some TPM drivers (such as Arm FF-A, or SPI attached TPM
devices) are not reliably available during the initcall_late stage,
resulting in a log error:
ima: No TPM chip found, activating TPM-bypass!
and no measurements into the TPM by IMA. We can avoid this by doing IMA
init in the initcall_late_sync stage, after the drivers have completed
their init + registration.
Rather than do this everywhere, and needlessly delay the initialisation
of IMA when there is no need to do so, we continue to try to initialise
at the earlier stage, only deferring to the later point if the TPM is
not available yet.
Signed-off-by: Jonathan McDowell <noodles@meta.com>
---
security/integrity/ima/ima.h | 3 +-
security/integrity/ima/ima_init.c | 25 ++++++++-------
security/integrity/ima/ima_main.c | 37 ++++++++++++++++++++---
security/integrity/ima/ima_template_lib.c | 3 +-
4 files changed, 50 insertions(+), 18 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 89ebe98ffc5e..b3677b403a5a 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -65,6 +65,7 @@ extern struct ima_algo_desc *ima_algo_array __ro_after_init;
extern int ima_appraise;
extern struct tpm_chip *ima_tpm_chip;
extern const char boot_aggregate_name[];
+extern const char boot_aggregate_late_name[];
/* IMA event related data */
struct ima_event_data {
@@ -257,7 +258,7 @@ static inline void ima_measure_kexec_event(const char *event_name) {}
extern bool ima_canonical_fmt;
/* Internal IMA function definitions */
-int ima_init(void);
+int ima_init_core(bool late);
int ima_fs_init(void);
int ima_add_template_entry(struct ima_template_entry *entry, int violation,
const char *op, struct inode *inode,
diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
index a2f34f2d8ad7..5f335834a9bb 100644
--- a/security/integrity/ima/ima_init.c
+++ b/security/integrity/ima/ima_init.c
@@ -22,6 +22,7 @@
/* name for boot aggregate entry */
const char boot_aggregate_name[] = "boot_aggregate";
+const char boot_aggregate_late_name[] = "boot_aggregate_late";
struct tpm_chip *ima_tpm_chip;
/* Add the boot aggregate to the IMA measurement list and extend
@@ -39,17 +40,17 @@ struct tpm_chip *ima_tpm_chip;
* a different value.) Violations add a zero entry to the measurement
* list and extend the aggregate PCR value with ff...ff's.
*/
-static int __init ima_add_boot_aggregate(void)
+static int __init ima_add_boot_aggregate(bool late)
{
static const char op[] = "add_boot_aggregate";
const char *audit_cause = "ENOMEM";
struct ima_template_entry *entry;
struct ima_iint_cache tmp_iint, *iint = &tmp_iint;
- struct ima_event_data event_data = { .iint = iint,
- .filename = boot_aggregate_name };
+ struct ima_event_data event_data = { .iint = iint };
struct ima_max_digest_data hash;
struct ima_digest_data *hash_hdr = container_of(&hash.hdr,
struct ima_digest_data, hdr);
+ const char *filename;
int result = -ENOMEM;
int violation = 0;
@@ -59,6 +60,12 @@ static int __init ima_add_boot_aggregate(void)
iint->ima_hash->algo = ima_hash_algo;
iint->ima_hash->length = hash_digest_size[ima_hash_algo];
+ if (late)
+ filename = boot_aggregate_late_name;
+ else
+ filename = boot_aggregate_name;
+ event_data.filename = filename;
+
/*
* With TPM 2.0 hash agility, TPM chips could support multiple TPM
* PCR banks, allowing firmware to configure and enable different
@@ -86,7 +93,7 @@ static int __init ima_add_boot_aggregate(void)
}
result = ima_store_template(entry, violation, NULL,
- boot_aggregate_name,
+ filename,
CONFIG_IMA_MEASURE_PCR_IDX);
if (result < 0) {
ima_free_template_entry(entry);
@@ -95,7 +102,7 @@ static int __init ima_add_boot_aggregate(void)
}
return 0;
err_out:
- integrity_audit_msg(AUDIT_INTEGRITY_PCR, NULL, boot_aggregate_name, op,
+ integrity_audit_msg(AUDIT_INTEGRITY_PCR, NULL, filename, op,
audit_cause, result, 0);
return result;
}
@@ -115,14 +122,10 @@ void __init ima_load_x509(void)
}
#endif
-int __init ima_init(void)
+int __init ima_init_core(bool late)
{
int rc;
- ima_tpm_chip = tpm_default_chip();
- if (!ima_tpm_chip)
- pr_info("No TPM chip found, activating TPM-bypass!\n");
-
rc = integrity_init_keyring(INTEGRITY_KEYRING_IMA);
if (rc)
return rc;
@@ -140,7 +143,7 @@ int __init ima_init(void)
rc = ima_init_digests();
if (rc != 0)
return rc;
- rc = ima_add_boot_aggregate(); /* boot aggregate must be first entry */
+ rc = ima_add_boot_aggregate(late); /* boot aggregate must be first entry */
if (rc != 0)
return rc;
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 1d6229b156fb..0b93a286c0d3 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -1237,7 +1237,7 @@ static int ima_kernel_module_request(char *kmod_name)
#endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
-static int __init init_ima(void)
+static int __init init_ima(bool late)
{
int error;
@@ -1247,10 +1247,26 @@ static int __init init_ima(void)
return 0;
}
+ /*
+ * If we found the TPM during our first attempt, or we know there's no
+ * TPM, nothing further to do
+ */
+ if (late && (ima_tpm_chip || !IS_ENABLED(CONFIG_TCG_TPM)))
+ return 0;
+
+ ima_tpm_chip = tpm_default_chip();
+ if (!ima_tpm_chip && !late && IS_ENABLED(CONFIG_TCG_TPM)) {
+ pr_debug("TPM not available, will try later\n");
+ return -EPROBE_DEFER;
+ }
+
+ if (!ima_tpm_chip)
+ pr_info("No TPM chip found, activating TPM-bypass!\n");
+
ima_appraise_parse_cmdline();
ima_init_template_list();
hash_setup(CONFIG_IMA_DEFAULT_HASH);
- error = ima_init();
+ error = ima_init_core(late);
if (error && strcmp(hash_algo_name[ima_hash_algo],
CONFIG_IMA_DEFAULT_HASH) != 0) {
@@ -1258,7 +1274,7 @@ static int __init init_ima(void)
hash_algo_name[ima_hash_algo], CONFIG_IMA_DEFAULT_HASH);
hash_setup_done = 0;
hash_setup(CONFIG_IMA_DEFAULT_HASH);
- error = ima_init();
+ error = ima_init_core(late);
}
if (error)
@@ -1274,6 +1290,16 @@ static int __init init_ima(void)
return error;
}
+static int __init init_ima_late(void)
+{
+ return init_ima(false);
+}
+
+static int __init init_ima_late_sync(void)
+{
+ return init_ima(true);
+}
+
static struct security_hook_list ima_hooks[] __ro_after_init = {
LSM_HOOK_INIT(bprm_check_security, ima_bprm_check),
LSM_HOOK_INIT(bprm_creds_for_exec, ima_bprm_creds_for_exec),
@@ -1319,6 +1345,7 @@ DEFINE_LSM(ima) = {
.init = init_ima_lsm,
.order = LSM_ORDER_LAST,
.blobs = &ima_blob_sizes,
- /* Start IMA after the TPM is available */
- .initcall_late = init_ima,
+ /* Ensure we start IMA after the TPM is available */
+ .initcall_late = init_ima_late,
+ .initcall_late_sync = init_ima_late_sync,
};
diff --git a/security/integrity/ima/ima_template_lib.c b/security/integrity/ima/ima_template_lib.c
index 0e627eac9c33..8a89236f926c 100644
--- a/security/integrity/ima/ima_template_lib.c
+++ b/security/integrity/ima/ima_template_lib.c
@@ -363,7 +363,8 @@ int ima_eventdigest_init(struct ima_event_data *event_data,
goto out;
}
- if ((const char *)event_data->filename == boot_aggregate_name) {
+ if ((const char *)event_data->filename == boot_aggregate_name ||
+ (const char *)event_data->filename == boot_aggregate_late_name) {
if (ima_tpm_chip) {
hash.hdr.algo = HASH_ALGO_SHA1;
result = ima_calc_boot_aggregate(hash_hdr);
--
2.53.0
^ permalink raw reply related
* [RFC PATCH v3 3/4] Revert "tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in"
From: Jonathan McDowell @ 2026-04-24 13:24 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene, Yeoreum Yun
In-Reply-To: <cover.1777036497.git.noodles@meta.com>
From: Yeoreum Yun <yeoreum.yun@arm.com>
This reverts commit 746d9e9f62a6e8ba0eba2b83fc61cfe7fa8797ce.
Now that IMA will retry in the late_initcall_sync level if the TPM is
not available at first, this change is no longer required.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Jonathan McDowell <noodles@meta.com>
---
drivers/char/tpm/tpm_crb_ffa.c | 19 +++----------------
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
index 99f1c1e5644b..05f19c0ebf82 100644
--- a/drivers/char/tpm/tpm_crb_ffa.c
+++ b/drivers/char/tpm/tpm_crb_ffa.c
@@ -123,7 +123,6 @@ struct tpm_crb_ffa {
};
static struct tpm_crb_ffa *tpm_crb_ffa;
-static struct ffa_driver tpm_crb_ffa_driver;
static int tpm_crb_ffa_to_linux_errno(int errno)
{
@@ -177,23 +176,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
*/
int tpm_crb_ffa_init(void)
{
- int ret = 0;
-
- if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
- ret = ffa_register(&tpm_crb_ffa_driver);
- if (ret) {
- tpm_crb_ffa = ERR_PTR(-ENODEV);
- return ret;
- }
- }
-
if (!tpm_crb_ffa)
- ret = -ENOENT;
+ return -ENOENT;
if (IS_ERR_VALUE(tpm_crb_ffa))
- ret = -ENODEV;
+ return -ENODEV;
- return ret;
+ return 0;
}
EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
@@ -405,9 +394,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
.id_table = tpm_crb_ffa_device_id,
};
-#ifdef MODULE
module_ffa_driver(tpm_crb_ffa_driver);
-#endif
MODULE_AUTHOR("Arm");
MODULE_DESCRIPTION("TPM CRB FFA driver");
--
2.53.0
^ permalink raw reply related
* [RFC PATCH v3 4/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"
From: Jonathan McDowell @ 2026-04-24 13:24 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene, Yeoreum Yun
In-Reply-To: <cover.1777036497.git.noodles@meta.com>
From: Yeoreum Yun <yeoreum.yun@arm.com>
This reverts commit 0e0546eabcd6c19765a8dbf5b5db3723e7b0ea75, which was
added to address ordering issues with the IMA LSM initialisation where
the TPM would not be fully ready by the time IMA wanted it. This has
been resolved within IMA by retrying setup during late_initcall_sync if
the TPM is not available at first.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Jonathan McDowell <noodles@meta.com>
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index f2f94d4d533e..01547c5c0e38 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2106,7 +2106,7 @@ static int __init ffa_init(void)
kfree(drv_info);
return ret;
}
-rootfs_initcall(ffa_init);
+module_init(ffa_init);
static void __exit ffa_exit(void)
{
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 08/13] firmware: arm_scmi: Harden clock protocol initialization
From: Cristian Marussi @ 2026-04-24 13:32 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: linux-kernel, linux-arm-kernel, arm-scmi, linux-clk,
linux-renesas-soc, Cristian Marussi, sudeep.holla, philip.radford,
james.quinlan, f.fainelli, vincent.guittot, etienne.carriere,
peng.fan, michal.simek, dan.carpenter, geert+renesas,
kuninori.morimoto.gx, marek.vasut+renesas
In-Reply-To: <WNCeTzosRbKm_zGsbSPx8w@collabora.com>
On Fri, Apr 24, 2026 at 02:07:59PM +0200, Nicolas Frattaroli wrote:
> On Tuesday, 10 March 2026 19:40:25 Central European Summer Time Cristian Marussi wrote:
> > Add proper error handling on failure to enumerate clocks features or
> > rates.
> >
Hi,
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > drivers/firmware/arm_scmi/clock.c | 22 ++++++++++++++++------
> > 1 file changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
> > index c9b62edce4fd..bf956305a8fe 100644
> > --- a/drivers/firmware/arm_scmi/clock.c
> > +++ b/drivers/firmware/arm_scmi/clock.c
> > @@ -402,10 +402,16 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
> > SUPPORTS_RATE_CHANGE_REQUESTED_NOTIF(attributes))
> > clk->rate_change_requested_notifications = true;
> > if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
> > - if (SUPPORTS_PARENT_CLOCK(attributes))
> > - scmi_clock_possible_parents(ph, clk_id, cinfo);
> > - if (SUPPORTS_GET_PERMISSIONS(attributes))
> > - scmi_clock_get_permissions(ph, clk_id, clk);
> > + if (SUPPORTS_PARENT_CLOCK(attributes)) {
> > + ret = scmi_clock_possible_parents(ph, clk_id, cinfo);
> > + if (ret)
> > + return ret;
> > + }
> > + if (SUPPORTS_GET_PERMISSIONS(attributes)) {
> > + ret = scmi_clock_get_permissions(ph, clk_id, clk);
> > + if (ret)
> > + return ret;
> > + }
> > if (SUPPORTS_EXTENDED_CONFIG(attributes))
> > clk->extended_config = true;
> > }
> > @@ -1143,8 +1149,12 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
> > for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
> > cinfo->clkds[clkid].id = clkid;
> > ret = scmi_clock_attributes_get(ph, clkid, cinfo);
> > - if (!ret)
> > - scmi_clock_describe_rates_get(ph, clkid, cinfo);
> > + if (ret)
> > + return ret;
> > +
> > + ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
> > + if (ret)
> > + return ret;
> > }
> >
> > if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
> >
>
> I see that a quirk is being added for this, but I thought I should chime
> in with my opinion for future approaches in this direction.
>
> I don't see how this hardens anything. All this does is break platforms
> that were previously working by returning early. At most, this should
Certainly the naming in the subject was chosen badly (by me!)...indeed it
should be more something like "Enforce strict protocol compliance",
because at the end all of the broken platforms really run a slighly odd
out of spec SCMI firmware that does NOT implement one or more of the SCMI
mandatory command...
> be a warning (as in not WARN but pr_warn/dev_warn/...). If firmware
> returns nonsense, a clock driver should imho try its best to work
> around the nonsense in a safe way, because the alternative is that
> a major part of the system (and thus likely the entire system) no
..well yes we definitely dont want to break deployed platforms BUT also
we dont want to legalize this kind of out of spec behaviour in future
firmwares...hence (a number ?) of quirks an FW_BUG warns probably to
let already broken deployed platforms survive while discouraging such
implementation in future fw implementations...
These firmware most certainly wont pass the SCMI compliance test suite [1],
which indeed we do not mandate, but the reason these bugs happened is
exactly because the kernel SCMI stack was buggy and left that door open...
More specifically these kind of out-of-spec behaviours are not really just
a matter being 'picky', the problem is that any resource set in any
SCMI protocol is defined by the spec such as to be described by a
contiguos set of IDs and the drivers are designed anyway under that
assumption from the allocation point of view, so allowing a clock ID to
just fail one of the mandatory commands and skip a domain would jeopardize
all of this and, even if clearly is NOT a problem here, seems a fragile
assumption.
> longer works. It's basically the same reason why we avoid BUG(): sure,
> you prevented a problem, but you tore down the entire system to tell
> the user about it.
No I feel this is a lot different from the BUG() scenario: we'll never
merge this like this without enough quirks to let survive all the
existing impacted platforms, but the shout here is for the fw-developer
of a new un-deployed firmware: that WILL fail and no quirk will be accepted
if they plan to design a future FW out of spec from scratch because they
think is better....well...they can anyway of course but they will have
to keep their own quirks donwstream forever :P
Thanks,
Cristian
[1]: https://gitlab.arm.com/tests/scmi-tests/-/commits/master?ref_type=heads
^ permalink raw reply
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Jason Gunthorpe @ 2026-04-24 13:39 UTC (permalink / raw)
To: Joonwon Kang
Cc: will, robin.murphy, joro, jpb, nicolinc, praan, kees, amhetre,
Alexander.Grest, baolu.lu, smostafa, linux-arm-kernel, iommu,
linux-kernel
In-Reply-To: <20260424085339.3503582-1-joonwonkang@google.com>
On Fri, Apr 24, 2026 at 08:53:39AM +0000, Joonwon Kang wrote:
> For SVA, the IOMMU core always allocates PASID from the global PASID
> space. The use of this global PASID space comes from the limitation of
> the ENQCMD instruction in Intel CPUs that it fetches its PASID operand
> from IA32_PASID, which is per-task.
That's right, and all the iommu drivers should have no issue with
per-device pasid or they are not following the API contract.. I
believe that has been taking care of already.
So, I don't think this is an iommu driver capability.
Instead, you have to decide if the PASID is per device or not based on
if the system will use ENQCMD or any similar instruction. I
understand ARM has introduced a similar instruction.
So you may be better off with some kind of 'arch has enqcmd like
instruction' to control this instead of involving the iommu driver.
> - The device is not a PCIe device.
> - The device is to use SVA.
> - The supported SSID/PASID space is very small for the device; only 1 to
> 3 SSIDs are supported.
Yuk
> With this setup, when other modules have allocated all the PASIDs that
> our device is expected to use from the global PASID space via APIs like
> iommu_alloc_global_pasid() or iommu_sva_bind_device(), SVA binding to
> our device fails due to the lack of available PASIDs.
So you have multiple SVA using devices as well? Or multiple instances
of the same device?
Jason
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile A1
From: Geert Uytterhoeven @ 2026-04-24 13:44 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260422233744.149872-2-marek.vasut+renesas@mailbox.org>
On Thu, 23 Apr 2026 at 01:38, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Document ZT trace bus and ZTR trace clock on the R-Mobile A1.
> These clock supply the coresight tracing modules, PTM, TPIU,
> ETB and replicator. Without these clock, the coresight tracing
> can not be operated. While this does change the ABI, it does so
> by extending the existing clock-output-names, therefore if an
> old software is used with new DT, the coresight tracing parts
> will likely fail to probe, otherwise if new software is used
> with an old DT, there is no impact.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue for v7.2 in a branch shared by clock and DTS.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 2/4] clk: renesas: r8a7740: Implement ZT/ZTR trace clock on R-Mobile A1
From: Geert Uytterhoeven @ 2026-04-24 13:44 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260422233744.149872-3-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Thu, 23 Apr 2026 at 01:38, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Implement ZT trace bus and ZTR trace clock on the R-Mobile A1.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/drivers/clk/renesas/clk-r8a7740.c
> +++ b/drivers/clk/renesas/clk-r8a7740.c
> @@ -37,6 +37,8 @@ static struct div4_clk div4_clks[] = {
> { "zg", CPG_FRQCRA, 16 },
> { "b", CPG_FRQCRA, 8 },
> { "m1", CPG_FRQCRA, 4 },
> + { "ztr", CPG_FRQCRB, 20 },
This is not 100% correct: ZTR has an optional /2 post-divider that is
controlled by the ZTRCKCR.CKSEL bit. As the Coresight drivers do
not seem to care about the clock rate, I guess this is fine.
> + { "zt", CPG_FRQCRB, 16 },
> { "hp", CPG_FRQCRB, 4 },
> { "hpp", CPG_FRQCRC, 20 },
> { "usbp", CPG_FRQCRC, 16 },
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Geert Uytterhoeven @ 2026-04-24 13:45 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260422233744.149872-4-marek.vasut+renesas@mailbox.org>
On Thu, 23 Apr 2026 at 01:38, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
> These clock supply the coresight tracing modules, PTM, TPIU,
> ETB and replicator. Without these clock, the coresight tracing
> can not be operated.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Add ztr/zt clock at the end of the list to match bindings
> V3: Keep only the trace clock DT part here, extend the commit message.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: dts: renesas: r8a7740: Describe coresight on R-Mobile A1
From: Geert Uytterhoeven @ 2026-04-24 13:47 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260422233744.149872-5-marek.vasut+renesas@mailbox.org>
On Thu, 23 Apr 2026 at 01:38, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Describe coresight topology on R-Mobile A1. Extend the current PTM node
> with connection funnel, TPIU, ETB and replicator. The coresight on this
> hardware is clocked from the ZT/ZTR trace clock.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
LGTM, so
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 08/13] firmware: arm_scmi: Harden clock protocol initialization
From: Geert Uytterhoeven @ 2026-04-24 13:55 UTC (permalink / raw)
To: Cristian Marussi
Cc: Nicolas Frattaroli, linux-kernel, linux-arm-kernel, arm-scmi,
linux-clk, linux-renesas-soc, sudeep.holla, philip.radford,
james.quinlan, f.fainelli, vincent.guittot, etienne.carriere,
peng.fan, michal.simek, dan.carpenter, geert+renesas,
kuninori.morimoto.gx, marek.vasut+renesas
In-Reply-To: <aetw1WcSCDxk11AV@pluto>
Hi Cristian,
On Fri, 24 Apr 2026 at 15:32, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Fri, Apr 24, 2026 at 02:07:59PM +0200, Nicolas Frattaroli wrote:
> > On Tuesday, 10 March 2026 19:40:25 Central European Summer Time Cristian Marussi wrote:
> > > Add proper error handling on failure to enumerate clocks features or
> > > rates.
> > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > > ---
> > > drivers/firmware/arm_scmi/clock.c | 22 ++++++++++++++++------
> > > 1 file changed, 16 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
> > > index c9b62edce4fd..bf956305a8fe 100644
> > > --- a/drivers/firmware/arm_scmi/clock.c
> > > +++ b/drivers/firmware/arm_scmi/clock.c
> > > @@ -402,10 +402,16 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
> > > SUPPORTS_RATE_CHANGE_REQUESTED_NOTIF(attributes))
> > > clk->rate_change_requested_notifications = true;
> > > if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
> > > - if (SUPPORTS_PARENT_CLOCK(attributes))
> > > - scmi_clock_possible_parents(ph, clk_id, cinfo);
> > > - if (SUPPORTS_GET_PERMISSIONS(attributes))
> > > - scmi_clock_get_permissions(ph, clk_id, clk);
> > > + if (SUPPORTS_PARENT_CLOCK(attributes)) {
> > > + ret = scmi_clock_possible_parents(ph, clk_id, cinfo);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > + if (SUPPORTS_GET_PERMISSIONS(attributes)) {
> > > + ret = scmi_clock_get_permissions(ph, clk_id, clk);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > if (SUPPORTS_EXTENDED_CONFIG(attributes))
> > > clk->extended_config = true;
> > > }
> > > @@ -1143,8 +1149,12 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
> > > for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
> > > cinfo->clkds[clkid].id = clkid;
> > > ret = scmi_clock_attributes_get(ph, clkid, cinfo);
> > > - if (!ret)
> > > - scmi_clock_describe_rates_get(ph, clkid, cinfo);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
> > > + if (ret)
> > > + return ret;
> > > }
> > >
> > > if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
> > >
> >
> > I see that a quirk is being added for this, but I thought I should chime
> > in with my opinion for future approaches in this direction.
> >
> > I don't see how this hardens anything. All this does is break platforms
> > that were previously working by returning early. At most, this should
>
> Certainly the naming in the subject was chosen badly (by me!)...indeed it
> should be more something like "Enforce strict protocol compliance",
> because at the end all of the broken platforms really run a slighly odd
> out of spec SCMI firmware that does NOT implement one or more of the SCMI
> mandatory command...
>
> > be a warning (as in not WARN but pr_warn/dev_warn/...). If firmware
> > returns nonsense, a clock driver should imho try its best to work
> > around the nonsense in a safe way, because the alternative is that
> > a major part of the system (and thus likely the entire system) no
>
> ..well yes we definitely dont want to break deployed platforms BUT also
> we dont want to legalize this kind of out of spec behaviour in future
> firmwares...hence (a number ?) of quirks an FW_BUG warns probably to
> let already broken deployed platforms survive while discouraging such
> implementation in future fw implementations...
>
> These firmware most certainly wont pass the SCMI compliance test suite [1],
> which indeed we do not mandate, but the reason these bugs happened is
> exactly because the kernel SCMI stack was buggy and left that door open...
>
> More specifically these kind of out-of-spec behaviours are not really just
> a matter being 'picky', the problem is that any resource set in any
> SCMI protocol is defined by the spec such as to be described by a
> contiguos set of IDs and the drivers are designed anyway under that
> assumption from the allocation point of view, so allowing a clock ID to
> just fail one of the mandatory commands and skip a domain would jeopardize
> all of this and, even if clearly is NOT a problem here, seems a fragile
> assumption.
How can you have all of:
1. a contiguous list of IDs,
2. implement all mandatory commands,
2. restrict the use of some clocks to a subset of the agents in the system?
Use a different list of IDs for each agent?
What if a mistake was made, and a clock was exposed to an agent by
accident?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 5/8] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
From: linux-kernel-dev @ 2026-04-24 14:00 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andi Shyti, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Beniamino Galvani,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Liam Girdwood, Mark Brown
In-Reply-To: <f057dbd9-5fa7-414f-98f4-1bbb691e2fc7@linaro.org>
Thanks for your review.
On 4/24/26 12:00 PM, Neil Armstrong wrote:
> On 4/21/26 13:49, Ronald Claveau via B4 Relay wrote:
>> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>>
>> Replace the hardcoded MAX_LEVEL constant and fan register
>> with values read from platform_data (fan_reg, max_level),
>> as new MCUs need different values.
>>
>> Optionally acquire and enable a "fan" regulator supply
>> at probe time and on resume,
>> so boards that gate fan power through a regulator are handled.
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> drivers/thermal/khadas_mcu_fan.c | 49 ++++++++++++++++++++++++++++++
>> +++++-----
>> 1 file changed, 43 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/
>> khadas_mcu_fan.c
>> index d35e5313bea41..24559bf65de46 100644
>> --- a/drivers/thermal/khadas_mcu_fan.c
>> +++ b/drivers/thermal/khadas_mcu_fan.c
>> @@ -13,13 +13,15 @@
>> #include <linux/regmap.h>
>> #include <linux/sysfs.h>
>> #include <linux/thermal.h>
>> -
>> -#define MAX_LEVEL 3
>> +#include <linux/regulator/consumer.h>
>> struct khadas_mcu_fan_ctx {
>> struct khadas_mcu *mcu;
>> + unsigned int fan_reg;
>> unsigned int level;
>> + unsigned int max_level;
>> struct thermal_cooling_device *cdev;
>> + struct regulator *power;
>> };
>> static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
>> @@ -27,8 +29,7 @@ static int khadas_mcu_fan_set_level(struct
>> khadas_mcu_fan_ctx *ctx,
>> {
>> int ret;
>> - ret = regmap_write(ctx->mcu->regmap,
>> KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
>> - level);
>> + ret = regmap_write(ctx->mcu->regmap, ctx->fan_reg, level);
>> if (ret)
>> return ret;
>> @@ -40,7 +41,9 @@ static int khadas_mcu_fan_set_level(struct
>> khadas_mcu_fan_ctx *ctx,
>> static int khadas_mcu_fan_get_max_state(struct
>> thermal_cooling_device *cdev,
>> unsigned long *state)
>> {
>> - *state = MAX_LEVEL;
>> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> +
>> + *state = ctx->max_level;
>> return 0;
>> }
>> @@ -61,7 +64,7 @@ khadas_mcu_fan_set_cur_state(struct
>> thermal_cooling_device *cdev,
>> {
>> struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> - if (state > MAX_LEVEL)
>> + if (state > ctx->max_level)
>> return -EINVAL;
>> if (state == ctx->level)
>> @@ -83,11 +86,32 @@ static int khadas_mcu_fan_probe(struct
>> platform_device *pdev)
>> struct device *dev = &pdev->dev;
>> struct khadas_mcu_fan_ctx *ctx;
>> int ret;
>> + const struct khadas_mcu_fan_pdata *pdata =
>> dev_get_platdata(&pdev->dev);
>
> Move this on top to respect reverse christmas ordering.
>
Ok I will do that.
>> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> if (!ctx)
>> return -ENOMEM;
>> +
>> ctx->mcu = mcu;
>> + ctx->fan_reg = pdata->fan_reg;
>> + ctx->max_level = pdata->max_level;
>> +
>> + ctx->power = devm_regulator_get_optional(dev->parent, "fan");
>> + if (IS_ERR(ctx->power)) {
>> + if (PTR_ERR(ctx->power) == -ENODEV)
>> + ctx->power = NULL;
>> + else
>> + return PTR_ERR(ctx->power);
>> + }
>> +
>> + if (ctx->power) {
>> + ret = regulator_enable(ctx->power);
>> + if (ret) {
>> + dev_err(dev, "Failed to enable fan power supply: %d\n",
>> ret);
>> + return ret; + }
>> + }
>
> Or you can request with devm_regulator_get(dev->parent, "fan"); which will
> return a dummy regulator, and then you can just call regulator_enable &
> disable
> and remove all those checks.
>
Make sense, I'm on it.
>> +
>> platform_set_drvdata(pdev, ctx);
>> cdev = devm_thermal_of_cooling_device_register(dev->parent,
>> @@ -124,12 +148,25 @@ static int khadas_mcu_fan_suspend(struct device
>> *dev)
>> ctx->level = level_save;
>> + if (ctx->power) {
>> + ret = regulator_disable(ctx->power);
>> + if (ret)
>> + return ret;
>> + }
>
> if (ctx->power)
> return regulator_disable(ctx->power);
>
>> +
>> return 0;
>> }
>> static int khadas_mcu_fan_resume(struct device *dev)
>> {
>> struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
>> + int ret;
>> +
>> + if (ctx->power) {
>> + ret = regulator_enable(ctx->power);
>> + if (ret)
>> + return ret;
>> + }
>> return khadas_mcu_fan_set_level(ctx, ctx->level);
>> }
>>
>
> Thanks,
> Neil
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v11 00/14] barrier: Add smp_cond_load_{relaxed, acquire}_timeout()
From: Okanovic, Haris @ 2026-04-24 14:10 UTC (permalink / raw)
To: akpm@linux-foundation.org, ankur.a.arora@oracle.com
Cc: joao.m.martins@oracle.com, xueshuai@linux.alibaba.com,
david.laight.linux@gmail.com, boris.ostrovsky@oracle.com,
memxor@gmail.com, ashok.bhat@arm.com, zhenglifeng1@huawei.com,
konrad.wilk@oracle.com, cl@gentwo.org,
linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
ast@kernel.org, rdunlap@infradead.org, daniel.lezcano@linaro.org,
linux-arch@vger.kernel.org, arnd@arndb.de, will@kernel.org,
mark.rutland@arm.com, peterz@infradead.org, bpf@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Okanovic, Haris,
rafael@kernel.org, linux-pm@vger.kernel.org
In-Reply-To: <20260423101631.84f26592d629eee46fbde6f8@linux-foundation.org>
On Thu, 2026-04-23 at 10:16 -0700, Andrew Morton wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Wed, 8 Apr 2026 17:55:24 +0530 Ankur Arora <ankur.a.arora@oracle.com> wrote:
>
> > The core kernel often uses smp_cond_load_{relaxed,acquire}() to spin
> > on condition variables with architectural primitives used to avoid
> > hammering the relevant cachelines.
> >
> > ...
> >
> > Accordingly add two interfaces (with their generic and arm64 specific
> > implementations):
> >
> > smp_cond_load_relaxed_timeout(ptr, cond_expr, time_expr, timeout)
> > smp_cond_load_acquire_timeout(ptr, cond_expr, time_expr, timeout)
> >
> > Also add tif_need_resched_relaxed_wait() which wraps the polling
> > pattern and its scheduler specific details in poll_idle().
> > In addition add atomic_cond_read_*_timeout(),
>
> Thanks, I'll add this to mm.git's mm-new branch today.
That's great news! Thanks for jumping in to move this forward.
>
> This isn't am MM patchset, but mm-new isn't included in linux-next, and
> linux-next isn't presently open for 7.1 material.
>
> After -rc1 I'll move the series into mm.git's mm-nonmm-unstable branch,
> where it will get linux-next exposure.
>
> I see that further review/comment has been requested - hopefully this
> will happen over the next couple of months, but please do continue to
> chase this down if you feel the need.
>
> > Haris Okanovic also saw improvement in real workloads due to the
> > cpuidle changes: "observed 4-6% improvements in memcahed, cassandra,
> > mysql, and postgresql under certain loads. Other applications likely
> > benefit too." [12]
>
> Those are significant improvements. Three years :(
Regards,
Haris Okanovic
AWS Graviton Software
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox