* [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
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-24 14:16 UTC (permalink / raw)
To: Mathias Stearn, Dmitry Vyukov
Cc: Jinjie Ruan, linux-man, Mark Rutland, Mathieu Desnoyers,
Catalin Marinas, Will Deacon, Boqun Feng, Paul E. McKenney,
Chris Kennelly, regressions, linux-kernel, linux-arm-kernel,
Peter Zijlstra, Ingo Molnar, Blake Oler
In-Reply-To: <CAHnCjA1LqbaUGkPe79EeP6Mpaki8QWeR-JBSbrG0z6pTm9CmUg@mail.gmail.com>
On Fri, Apr 24 2026 at 10:32, Mathias Stearn wrote:
> On Fri, Apr 24, 2026 at 9:57 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>> The only problem is with membarrier (it used to force write to
>> __rseq_abi.cpu_id_start for all threads, but now it does not).
>> Otherwise the caching scheme works.
>
> I almost wrote a message last night saying that we didn't need
> cpu_id_start invalidation on preemption. However, I remembered that
> the Grow() function[1] does a load outside of a critical section then
> stores a derived value inside the critical section, guarded only by
> the cpu_id_start invalidation check in StoreCurrentCpu[2]. It really
> should be doing a compare against the original value inside the
> critical section (or just do the whole thing inside), but it doesn't.
> I haven't reasoned end-to-end through this fully to prove corruption
> is possible, but I suspect that it is if another thread same-cpu
> preempts between the loads and the store and updates the header before
> the original thread resumes and writes its original intended header
> value. Ditto for signals, which sometimes allocate even though they
> shouldn't.
>
> I was really hoping that we would only need to do the "redundant"
> cpu_id_start writes would only be needed on membarrier_rseq IPIs where
> it really is a pay-for-what-you-use functionality,
That's fine and can be solved without adding this sequence overhead into
the scheduler hotpath.
> I think existing binaries depend on invalidation on
> preemption. Luckily that should be cheap enough to be ~free.
That's only free when it can be burried in the rseq_cs update, which
means the ID update would not happen when rseq_cs is NULL.
If those two changes fix it w/o requiring additional tcmalloc changes,
I'm happy to hack that up tomorrow.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v11 00/14] barrier: Add smp_cond_load_{relaxed, acquire}_timeout()
From: Okanovic, Haris @ 2026-04-24 14:16 UTC (permalink / raw)
To: ankur.a.arora@oracle.com, akpm@linux-foundation.org
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: <87tst1fpb0.fsf@oracle.com>
On Thu, 2026-04-23 at 12:29 -0700, Ankur Arora 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.
>
>
>
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> > 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.
>
> Great. Thanks!
>
> > 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.
>
> Ack that.
>
> > 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.
>
> Will do.
>
> > > 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 :(
>
> Part of the reason was that the barrier interface was part of a series
> focused on virtualization via cpuidle-haltpoll. As that was reviewed,
> the tale changed in the telling, and it made more sense to separate
> the two.
>
> Will send out the cpuidle changes for review which Haris is running
> with.
It needs some minor refactors for latest maintain.
This is what I tested last week:
https://github.com/harisokanovic/linux/tree/dev/harisokn/arm-haltpoll-2026-april-test
>
> --
> ankur
Regards,
Haris Okanovic
AWS Graviton Software
^ permalink raw reply
* [PATCH v5 0/8] Add VIM4 MCU/FAN support
From: Ronald Claveau via B4 Relay @ 2026-04-24 14:17 UTC (permalink / raw)
To: Neil Armstrong, 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
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau, Conor Dooley
The Khadas VIM4 board features a different MCU variant compared to
previous VIM boards.
While it shares the same I2C-based communication model,
it differs in some ways:
- A distinct register map with its own volatile/writeable register set
- A fan control with 0–100 levels instead of the 0–3 levels previously
- A fan power supply gated through a regulator
This series adds support for this new variant by:
1. Refactoring the khadas-mcu MFD driver to use per-variant data
structures (regmap config, cells, fan platform data),
and adding the khadas,vim4-mcu compatible string.
2. Extending the fan thermal driver to retrieve the fan register
and maximum level from platform_data,
and to optionally manage a power regulator for the fan supply.
3. Adding the corresponding DTS node for the VIM4, wiring the MCU to
the I2C AO_A bus and exposing it as a thermal cooling device.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v5:
- PATCH 5: Replace devm_regulator_get_optional() with devm_regulator_get()
to simplify error handling and remove NULL checks, also
ordering as reverse christmas according to Neil's feedback.
- Link to v4: https://lore.kernel.org/r/20260421-add-mcu-fan-khadas-vim4-v4-0-447114a28f2d@aliel.fr
Changes in v4:
- PATCH 1: limit fan-supply property by compatible according to Conor's feedback.
- Link to v3: https://lore.kernel.org/r/20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr
Changes in v3:
- PATCH 1: adding comment on vim4 compatible saying it is not discoverable,
thanks to Rob's and Neil's feedback.
- Link to v2: https://lore.kernel.org/r/20260403-add-mcu-fan-khadas-vim4-v2-0-70536b22439a@aliel.fr
Changes in v2:
- PATCH 5: Add regulator_disable on suspend thanks to Neil's feedback.
- Link to v1: https://lore.kernel.org/r/20260402-add-mcu-fan-khadas-vim4-v1-0-2b12eb4ac7b0@aliel.fr
---
Ronald Claveau (8):
dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
dt-bindings: i2c: amlogic: Add compatible for T7 SOC
mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
mfd: khadas-mcu: Add support for VIM4 MCU variant
thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
arm64: dts: amlogic: t7: Add i2c pinctrl node
arm64: dts: amlogic: t7: Add i2c controller node
arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node
.../bindings/i2c/amlogic,meson6-i2c.yaml | 13 ++-
.../devicetree/bindings/mfd/khadas,mcu.yaml | 18 ++++
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 13 +++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 20 ++++
drivers/mfd/khadas-mcu.c | 106 ++++++++++++++++++---
drivers/thermal/khadas_mcu_fan.c | 37 +++++--
include/linux/mfd/khadas-mcu.h | 39 +++++++-
7 files changed, 222 insertions(+), 24 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* [PATCH v5 6/8] arm64: dts: amlogic: t7: Add i2c pinctrl node
From: Ronald Claveau via B4 Relay @ 2026-04-24 14:17 UTC (permalink / raw)
To: Neil Armstrong, 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
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260424-add-mcu-fan-khadas-vim4-v5-0-afcfa7157b23@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add the T7 pinctrl used by the Khadas VIM4 for MCU communication.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7fe72c94ed623..e96fe10b251a0 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -376,6 +376,16 @@ mux {
};
};
+ i2c0_ao_d_pins: i2c0-ao-d {
+ mux {
+ groups = "i2c0_ao_sck_d",
+ "i2c0_ao_sda_d";
+ function = "i2c0_ao";
+ bias-disable;
+ drive-strength-microamp = <3000>;
+ };
+ };
+
pwm_a_pins: pwm-a {
mux {
groups = "pwm_a";
--
2.49.0
^ permalink raw reply related
* [PATCH v5 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Ronald Claveau via B4 Relay @ 2026-04-24 14:17 UTC (permalink / raw)
To: Neil Armstrong, 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
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau, Conor Dooley
In-Reply-To: <20260424-add-mcu-fan-khadas-vim4-v5-0-afcfa7157b23@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
The Khadas VIM4 MCU register is slightly different
from previous boards' MCU.
This board also features a switchable power source for its fan.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 084960fd5a1fd..1f135618e3b6f 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- khadas,mcu # MCU revision is discoverable
+ - khadas,vim4-mcu # Different MCU variant, not discoverable
"#cooling-cells": # Only needed for boards having FAN control feature
const: 2
@@ -25,10 +26,27 @@ properties:
reg:
maxItems: 1
+ fan-supply:
+ description: Phandle to the regulator that powers the fan.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
required:
- compatible
- reg
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: khadas,vim4-mcu
+ then:
+ required:
+ - fan-supply
+ else:
+ properties:
+ fan-supply: false
+
additionalProperties: false
examples:
--
2.49.0
^ permalink raw reply related
* [PATCH v5 8/8] arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node
From: Ronald Claveau via B4 Relay @ 2026-04-24 14:17 UTC (permalink / raw)
To: Neil Armstrong, 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
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260424-add-mcu-fan-khadas-vim4-v5-0-afcfa7157b23@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Enable and configure i2c MCU node to get fan working on Khadas VIM4.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 69d6118ba57e7..5d7f5390f3a66 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -157,6 +157,19 @@ wifi32k: wifi32k {
};
};
+&i2c_m_ao_a {
+ status = "okay";
+ pinctrl-0 = <&i2c0_ao_d_pins>;
+ pinctrl-names = "default";
+
+ khadas_mcu: system-controller@18 {
+ compatible = "khadas,vim4-mcu";
+ reg = <0x18>;
+ fan-supply = <&vcc5v>;
+ #cooling-cells = <2>;
+ };
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_pins>;
--
2.49.0
^ permalink raw reply related
* [PATCH v5 3/8] mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
From: Ronald Claveau via B4 Relay @ 2026-04-24 14:17 UTC (permalink / raw)
To: Neil Armstrong, 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
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260424-add-mcu-fan-khadas-vim4-v5-0-afcfa7157b23@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Introduce a per-variant configuration structure (khadas_mcu_data)
holding the regmap config and MFD cells,
selected at probe time via the of_device_id match data.
This makes adding other variants straightforward.
Also introduce khadas_mcu_fan_pdata to pass fan register address and
maximum level to the fan sub-driver, removing the hardcoded constants.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
include/linux/mfd/khadas-mcu.h | 39 +++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/khadas-mcu.h b/include/linux/mfd/khadas-mcu.h
index a99ba2ed0e4e0..75e275d3fa8d9 100644
--- a/include/linux/mfd/khadas-mcu.h
+++ b/include/linux/mfd/khadas-mcu.h
@@ -70,6 +70,13 @@
#define KHADAS_MCU_WOL_INIT_START_REG 0x87 /* WO */
#define KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG 0x88 /* WO */
+/* VIM4 specific registers */
+#define KHADAS_MCU_VIM4_REST_CONF_REG 0x2c /* WO - reset EEPROM */
+#define KHADAS_MCU_VIM4_LED_ON_RAM_REG 0x89 /* WO - LED volatile */
+#define KHADAS_MCU_VIM4_FAN_CTRL_REG 0x8a /* WO */
+#define KHADAS_MCU_VIM4_WDT_EN_REG 0x8b /* WO */
+#define KHADAS_MCU_VIM4_SYS_RST_REG 0x91 /* WO */
+
enum {
KHADAS_BOARD_VIM1 = 0x1,
KHADAS_BOARD_VIM2,
@@ -82,10 +89,38 @@ enum {
* struct khadas_mcu - Khadas MCU structure
* @device: device reference used for logs
* @regmap: register map
+ * @data: pointer to variant-specific config
*/
struct khadas_mcu {
- struct device *dev;
- struct regmap *regmap;
+ struct device *dev;
+ struct regmap *regmap;
+ const struct khadas_mcu_data *data;
+};
+
+/**
+ * struct khadas_mcu_data - per-variant configuration
+ * @regmap_config: regmap configuration
+ * @cells: MFD sub-devices
+ * @ncells: number of sub-devices
+ * @fan_cells: MFD fan sub-devices
+ * @nfan_cells: number of fan sub-devices
+ */
+struct khadas_mcu_data {
+ const struct regmap_config *regmap_config;
+ const struct mfd_cell *cells;
+ int ncells;
+ const struct mfd_cell *fan_cells;
+ int nfan_cells;
+};
+
+/**
+ * struct khadas_mcu_fan_pdata - fan sub-driver configuration
+ * @fan_reg: register address to write the fan level
+ * @max_level: maximum fan level
+ */
+struct khadas_mcu_fan_pdata {
+ unsigned int fan_reg;
+ unsigned int max_level;
};
#endif /* MFD_KHADAS_MCU_H */
--
2.49.0
^ permalink raw reply related
* [PATCH v5 5/8] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
From: Ronald Claveau via B4 Relay @ 2026-04-24 14:17 UTC (permalink / raw)
To: Neil Armstrong, 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
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260424-add-mcu-fan-khadas-vim4-v5-0-afcfa7157b23@aliel.fr>
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 | 37 ++++++++++++++++++++++++++++++-------
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/khadas_mcu_fan.c
index d35e5313bea41..5603fa099a858 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)
@@ -78,6 +81,7 @@ static const struct thermal_cooling_device_ops khadas_mcu_fan_cooling_ops = {
static int khadas_mcu_fan_probe(struct platform_device *pdev)
{
+ const struct khadas_mcu_fan_pdata *pdata = dev_get_platdata(&pdev->dev);
struct khadas_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
struct thermal_cooling_device *cdev;
struct device *dev = &pdev->dev;
@@ -87,7 +91,21 @@ static int khadas_mcu_fan_probe(struct platform_device *pdev)
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(dev->parent, "fan");
+ if (IS_ERR(ctx->power))
+ return PTR_ERR(ctx->power);
+
+ ret = regulator_enable(ctx->power);
+ if (ret) {
+ dev_err(dev, "Failed to enable fan power supply: %d\n", ret);
+ return ret;
+ }
+
platform_set_drvdata(pdev, ctx);
cdev = devm_thermal_of_cooling_device_register(dev->parent,
@@ -124,12 +142,17 @@ static int khadas_mcu_fan_suspend(struct device *dev)
ctx->level = level_save;
- return 0;
+ return regulator_disable(ctx->power);
}
static int khadas_mcu_fan_resume(struct device *dev)
{
struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = regulator_enable(ctx->power);
+ if (ret)
+ return ret;
return khadas_mcu_fan_set_level(ctx, ctx->level);
}
--
2.49.0
^ permalink raw reply related
* [PATCH v5 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Ronald Claveau via B4 Relay @ 2026-04-24 14:17 UTC (permalink / raw)
To: Neil Armstrong, 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
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260424-add-mcu-fan-khadas-vim4-v5-0-afcfa7157b23@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add the T7 SOC compatible which fallback to AXG compatible.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../devicetree/bindings/i2c/amlogic,meson6-i2c.yaml | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
index c4cc8af182807..7b59b60b62e5b 100644
--- a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
@@ -16,10 +16,15 @@ allOf:
properties:
compatible:
- enum:
- - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
- - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
- - amlogic,meson-axg-i2c # AXG and compatible SoCs
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,t7-i2c
+ - const: amlogic,meson-axg-i2c
+ - enum:
+ - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
+ - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
+ - amlogic,meson-axg-i2c # AXG and compatible SoCs
reg:
maxItems: 1
--
2.49.0
^ permalink raw reply related
* [PATCH v5 7/8] arm64: dts: amlogic: t7: Add i2c controller node
From: Ronald Claveau via B4 Relay @ 2026-04-24 14:17 UTC (permalink / raw)
To: Neil Armstrong, 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
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260424-add-mcu-fan-khadas-vim4-v5-0-afcfa7157b23@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add the T7 i2c controller node used by the Khadas VIM4
for MCU communication.
Use amlogic,meson-axg-i2c as fallback compatible.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index e96fe10b251a0..560c9dce35266 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -711,6 +711,16 @@ pwm_ao_cd: pwm@60000 {
status = "disabled";
};
+ i2c_m_ao_a: i2c@76000 {
+ compatible = "amlogic,t7-i2c", "amlogic,meson-axg-i2c";
+ reg = <0x0 0x76000 0x0 0x48>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 330 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc_periphs CLKID_SYS_I2C_AO_A>;
+ status = "disabled";
+ };
+
sd_emmc_a: mmc@88000 {
compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
reg = <0x0 0x88000 0x0 0x800>;
--
2.49.0
^ permalink raw reply related
* [PATCH v5 4/8] mfd: khadas-mcu: Add support for VIM4 MCU variant
From: Ronald Claveau via B4 Relay @ 2026-04-24 14:17 UTC (permalink / raw)
To: Neil Armstrong, 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
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260424-add-mcu-fan-khadas-vim4-v5-0-afcfa7157b23@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Refactor probe() to use per-variant khadas_mcu_data
instead of hardcoded globals.
Add dedicated regmap configuration and device data for the VIM4 MCU,
with its own volatile/writeable registers.
Add the fan control register
(0–100 levels vs 0–3 for previous supported boards).
Add a new compatible string "khadas,vim4-mcu".
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/mfd/khadas-mcu.c | 106 ++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 95 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
index ba981a7886921..b36b3b3ab73c0 100644
--- a/drivers/mfd/khadas-mcu.c
+++ b/drivers/mfd/khadas-mcu.c
@@ -75,15 +75,91 @@ static const struct regmap_config khadas_mcu_regmap_config = {
.cache_type = REGCACHE_MAPLE,
};
+static const struct khadas_mcu_fan_pdata khadas_mcu_fan_pdata = {
+ .fan_reg = KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
+ .max_level = 3,
+};
+
static struct mfd_cell khadas_mcu_fan_cells[] = {
/* VIM1/2 Rev13+ and VIM3 only */
- { .name = "khadas-mcu-fan-ctrl", },
+ {
+ .name = "khadas-mcu-fan-ctrl",
+ .platform_data = &khadas_mcu_fan_pdata,
+ .pdata_size = sizeof(khadas_mcu_fan_pdata),
+ },
};
static struct mfd_cell khadas_mcu_cells[] = {
{ .name = "khadas-mcu-user-mem", },
};
+static const struct khadas_mcu_data khadas_mcu_data = {
+ .regmap_config = &khadas_mcu_regmap_config,
+ .cells = khadas_mcu_cells,
+ .ncells = ARRAY_SIZE(khadas_mcu_cells),
+ .fan_cells = khadas_mcu_fan_cells,
+ .nfan_cells = ARRAY_SIZE(khadas_mcu_fan_cells),
+};
+
+static bool khadas_mcu_vim4_reg_volatile(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case KHADAS_MCU_PWR_OFF_CMD_REG:
+ case KHADAS_MCU_VIM4_REST_CONF_REG:
+ case KHADAS_MCU_WOL_INIT_START_REG:
+ case KHADAS_MCU_VIM4_LED_ON_RAM_REG:
+ case KHADAS_MCU_VIM4_FAN_CTRL_REG:
+ case KHADAS_MCU_VIM4_WDT_EN_REG:
+ case KHADAS_MCU_VIM4_SYS_RST_REG:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool khadas_mcu_vim4_reg_writeable(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case KHADAS_MCU_VERSION_0_REG:
+ case KHADAS_MCU_VERSION_1_REG:
+ case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
+ return false;
+ default:
+ return true;
+ }
+}
+
+static const struct regmap_config khadas_mcu_vim4_regmap_config = {
+ .reg_bits = 8,
+ .reg_stride = 1,
+ .val_bits = 8,
+ .max_register = KHADAS_MCU_VIM4_SYS_RST_REG,
+ .volatile_reg = khadas_mcu_vim4_reg_volatile,
+ .writeable_reg = khadas_mcu_vim4_reg_writeable,
+ .cache_type = REGCACHE_MAPLE,
+};
+
+static const struct khadas_mcu_fan_pdata khadas_vim4_fan_pdata = {
+ .fan_reg = KHADAS_MCU_VIM4_FAN_CTRL_REG,
+ .max_level = 0x64,
+};
+
+static const struct mfd_cell khadas_mcu_vim4_cells[] = {
+ {
+ .name = "khadas-mcu-fan-ctrl",
+ .platform_data = &khadas_vim4_fan_pdata,
+ .pdata_size = sizeof(khadas_vim4_fan_pdata),
+ },
+};
+
+static const struct khadas_mcu_data khadas_vim4_mcu_data = {
+ .regmap_config = &khadas_mcu_vim4_regmap_config,
+ .cells = NULL,
+ .ncells = 0,
+ .fan_cells = khadas_mcu_vim4_cells,
+ .nfan_cells = ARRAY_SIZE(khadas_mcu_vim4_cells),
+};
+
static int khadas_mcu_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
@@ -94,28 +170,35 @@ static int khadas_mcu_probe(struct i2c_client *client)
if (!ddata)
return -ENOMEM;
+ ddata->data = i2c_get_match_data(client);
+ if (!ddata->data)
+ return -EINVAL;
+
i2c_set_clientdata(client, ddata);
ddata->dev = dev;
- ddata->regmap = devm_regmap_init_i2c(client, &khadas_mcu_regmap_config);
+ ddata->regmap = devm_regmap_init_i2c(client,
+ ddata->data->regmap_config);
if (IS_ERR(ddata->regmap)) {
ret = PTR_ERR(ddata->regmap);
dev_err(dev, "Failed to allocate register map: %d\n", ret);
return ret;
}
- ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
- khadas_mcu_cells,
- ARRAY_SIZE(khadas_mcu_cells),
- NULL, 0, NULL);
- if (ret)
- return ret;
+ if (ddata->data->cells && ddata->data->ncells) {
+ ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
+ ddata->data->cells,
+ ddata->data->ncells,
+ NULL, 0, NULL);
+ if (ret)
+ return ret;
+ }
if (of_property_present(dev->of_node, "#cooling-cells"))
return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
- khadas_mcu_fan_cells,
- ARRAY_SIZE(khadas_mcu_fan_cells),
+ ddata->data->fan_cells,
+ ddata->data->nfan_cells,
NULL, 0, NULL);
return 0;
@@ -123,7 +206,8 @@ static int khadas_mcu_probe(struct i2c_client *client)
#ifdef CONFIG_OF
static const struct of_device_id khadas_mcu_of_match[] = {
- { .compatible = "khadas,mcu", },
+ { .compatible = "khadas,mcu", .data = &khadas_mcu_data },
+ { .compatible = "khadas,vim4-mcu", .data = &khadas_vim4_mcu_data },
{},
};
MODULE_DEVICE_TABLE(of, khadas_mcu_of_match);
--
2.49.0
^ permalink raw reply related
* [PATCH] arm64: dts: rockchip: Add DT overlay to use Sige5 SD slot for SPI flashing
From: Alexey Charkov @ 2026-04-24 14:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Alexey Charkov
ArmSoM Sige5, just as most RK3576 based boards, has its SD card pins
multiplexed with the FSPI1 controller, allowing for high-speed SPI access
to flash chips. If one has a microSD breakout board, a voltage regulator
to provide the necessary 1.8V power, a 6x5mm flash socket, and some jumper
wires, it's possible to use this to flash SPI chips directly from the
Sige5 with full hardware acceleration.
Add a DT overlay to set up the necessary pinmux and enable the FSPI1
controller for this purpose. This is specifically targeted at 1.8V flash
chips, and relies on an external regulator or power supply to provide the
necessary 1.8V power to the flash chip.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
arch/arm64/boot/dts/rockchip/Makefile | 5 ++
.../rk3576-armsom-sige5-fspi1-flasher.dtso | 80 ++++++++++++++++++++++
2 files changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index cb55c6b70d0e..ece5bdb387bc 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-display-vz.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-100ask-dshanpi-a1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-fspi1-flasher.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10-pcie1.dtbo
@@ -289,6 +290,10 @@ rk3568-wolfvision-pf5-vz-2-uhd-dtbs := rk3568-wolfvision-pf5.dtb \
rk3568-wolfvision-pf5-display-vz.dtbo \
rk3568-wolfvision-pf5-io-expander.dtbo
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-fspi1-flasher.dtb
+rk3576-armsom-sige5-fspi1-flasher-dtbs := rk3576-armsom-sige5.dtb \
+ rk3576-armsom-sige5-fspi1-flasher.dtbo
+
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtb
rk3576-armsom-sige5-v1.2-wifibt-dtbs := rk3576-armsom-sige5.dtb \
rk3576-armsom-sige5-v1.2-wifibt.dtbo
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5-fspi1-flasher.dtso b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5-fspi1-flasher.dtso
new file mode 100644
index 000000000000..b2ed735a43fc
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5-fspi1-flasher.dtso
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * DT-overlay to use the SD card slot on the Sige5 for flashing SPI chips via
+ * the hardware FSPI1 controller.
+ *
+ * This is specifically targeted at 1.8V SPI flash chips, and requires an
+ * external regulator or power supply to provide the power to the flash chip,
+ * as the one on Sige5 is fixed at 3.3V.
+ *
+ * Here's an example circuit:
+ * -----------------------------------------------------------------
+ * SD card slot SPI flash chip (e.g. MX25U12832F)
+ * (Pin 1) DAT2 <----------------------------> WP/SIO2 (Pin 3)
+ * (Pin 2) CD/DAT3 <----------------------------> RESET/SIO3 (Pin 7)
+ * (Pin 3) CMD <----------------------------> CS# (Pin 1)
+ * (Pin 5) CLK <----------------------------> SCLK (Pin 6)
+ * (Pin 7) DAT0 <----------------------------> SI/SIO0 (Pin 5)
+ * (Pin 8) DAT1 <----------------------------> SO/SIO1 (Pin 2)
+ * +-------+
+ * (Pin 4) 3V3 VDD <-> VIN 3 |MCP1700| 2 VOUT <-> 1V8 VCC (Pin 8)
+ * +-------+
+ * 1 GND
+ * |
+ * (Pin 6) VSS <-------------+--------------> GND (Pin 4)
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+&{/} {
+ vcc3v3_sd_s0: regulator-vcc-3v3-sd {
+ compatible = "regulator-fixed";
+ pinctrl-0 = <&sdmmc0_pwren>;
+ pinctrl-names = "default";
+ regulator-name = "vcc3v3_sd_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+};
+
+&pinctrl {
+ sd {
+ sdmmc0_pwren: sdmmc0-pwren {
+ rockchip,pins = <0 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&sfc1 {
+ pinctrl-0 = <&fspi1m0_csn0>, <&fspi1m0_pins>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <1>;
+ vcc-supply = <&vcc3v3_sd_s0>; /* Need a discrete LDO!!! */
+ };
+};
+
+&sdmmc {
+ status = "disabled";
+};
+
+&vccio_sd_s0 {
+ regulator-max-microvolt = <1800000>;
+};
---
base-commit: 7080e32d3f09d8688c4a87d81bdcc71f7f606b16
change-id: 20260424-sige5-flasher-e745282292bd
Best regards,
--
Alexey Charkov <alchark@flipper.net>
^ permalink raw reply related
* Re: [PATCH v11 00/14] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: Andrew Morton @ 2026-04-24 14:28 UTC (permalink / raw)
To: Ankur Arora
Cc: linux-kernel, linux-arch, linux-arm-kernel, linux-pm, bpf, arnd,
catalin.marinas, will, peterz, mark.rutland, harisokn, cl, ast,
rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai, rdunlap,
david.laight.linux, joao.m.martins, boris.ostrovsky, konrad.wilk,
ashok.bhat
In-Reply-To: <20260408122538.3610871-1-ankur.a.arora@oracle.com>
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(),
> atomic64_cond_read_*_timeout(), and atomic_long wrappers.
AI review has been busy:
https://sashiko.dev/#/patchset/20260408122538.3610871-1-ankur.a.arora@oracle.com
^ permalink raw reply
* Re: [PATCH v22 3/8] dt-bindings: display: bridge: Add Cadence MHDP8501
From: Laurentiu Palcu @ 2026-04-24 14:37 UTC (permalink / raw)
To: Rob Herring (Arm)
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: <177703391401.3671402.9330071570952735700.robh@kernel.org>
On Fri, Apr 24, 2026 at 07:31:54AM -0500, Rob Herring (Arm) wrote:
>
> 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.
>
It appears the problem is triggered by the fact that the dt-binding
patch adding fsl,imx8mq-hdptx-phy.yaml comes later than this patch... I
only tested with dt_binding_check after all patches were applied. :/
I'll reorder the patches in the next version.
--
Thanks,
Laurentiu
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Peter Zijlstra @ 2026-04-24 15:03 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mathias Stearn, Dmitry Vyukov, Jinjie Ruan, linux-man,
Mark Rutland, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Blake Oler
In-Reply-To: <87v7dgzbo7.ffs@tglx>
On Fri, Apr 24, 2026 at 04:16:08PM +0200, Thomas Gleixner wrote:
> On Fri, Apr 24 2026 at 10:32, Mathias Stearn wrote:
> > On Fri, Apr 24, 2026 at 9:57 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >> The only problem is with membarrier (it used to force write to
> >> __rseq_abi.cpu_id_start for all threads, but now it does not).
> >> Otherwise the caching scheme works.
> >
> > I almost wrote a message last night saying that we didn't need
> > cpu_id_start invalidation on preemption. However, I remembered that
> > the Grow() function[1] does a load outside of a critical section then
> > stores a derived value inside the critical section, guarded only by
> > the cpu_id_start invalidation check in StoreCurrentCpu[2]. It really
> > should be doing a compare against the original value inside the
> > critical section (or just do the whole thing inside), but it doesn't.
> > I haven't reasoned end-to-end through this fully to prove corruption
> > is possible, but I suspect that it is if another thread same-cpu
> > preempts between the loads and the store and updates the header before
> > the original thread resumes and writes its original intended header
> > value. Ditto for signals, which sometimes allocate even though they
> > shouldn't.
> >
> > I was really hoping that we would only need to do the "redundant"
> > cpu_id_start writes would only be needed on membarrier_rseq IPIs where
> > it really is a pay-for-what-you-use functionality,
>
> That's fine and can be solved without adding this sequence overhead into
> the scheduler hotpath.
Something like so? (probably needs help for !GENERIC bits)
---
diff --git a/include/asm-generic/thread_info_tif.h b/include/asm-generic/thread_info_tif.h
index 528e6fc7efe9..1d786003e42a 100644
--- a/include/asm-generic/thread_info_tif.h
+++ b/include/asm-generic/thread_info_tif.h
@@ -48,7 +48,10 @@
#define TIF_RSEQ 11 // Run RSEQ fast path
#define _TIF_RSEQ BIT(TIF_RSEQ)
-#define TIF_HRTIMER_REARM 12 // re-arm the timer
+#define TIF_RSEQ_FORCE_RESTART 12 // Reset RSEQ-CS from membarrier
+#define _TIF_RSEQ_FORCE_RESTART BIT(TIF_RSEQ_FORCE_RESTART)
+
+#define TIF_HRTIMER_REARM 13 // re-arm the timer
#define _TIF_HRTIMER_REARM BIT(TIF_HRTIMER_REARM)
#endif /* _ASM_GENERIC_THREAD_INFO_TIF_H_ */
diff --git a/include/linux/rseq.h b/include/linux/rseq.h
index b9d62fc2140d..2cbee6d41198 100644
--- a/include/linux/rseq.h
+++ b/include/linux/rseq.h
@@ -158,6 +158,8 @@ static inline unsigned int rseq_alloc_align(void)
return 1U << get_count_order(offsetof(struct rseq, end));
}
+extern void rseq_prepare_membarrier(struct mm_struct *mm);
+
#else /* CONFIG_RSEQ */
static inline void rseq_handle_slowpath(struct pt_regs *regs) { }
static inline void rseq_signal_deliver(struct ksignal *ksig, struct pt_regs *regs) { }
@@ -167,6 +169,7 @@ static inline void rseq_force_update(void) { }
static inline void rseq_virt_userspace_exit(void) { }
static inline void rseq_fork(struct task_struct *t, u64 clone_flags) { }
static inline void rseq_execve(struct task_struct *t) { }
+static inline void rseq_prepare_membarrier(struct mm_struct *mm) { }
#endif /* !CONFIG_RSEQ */
#ifdef CONFIG_DEBUG_RSEQ
diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
index f11ebd34f8b9..3dfaca776971 100644
--- a/include/linux/rseq_entry.h
+++ b/include/linux/rseq_entry.h
@@ -686,7 +686,12 @@ static __always_inline bool __rseq_exit_to_user_mode_restart(struct pt_regs *reg
#ifdef CONFIG_HAVE_GENERIC_TIF_BITS
static __always_inline bool test_tif_rseq(unsigned long ti_work)
{
- return ti_work & _TIF_RSEQ;
+ return ti_work & (_TIF_RSEQ | _TIF_RSEQ_FORCE_RESTART);
+}
+
+static __always_inline void clear_tif_rseq_force_restart(void)
+{
+ clear_thread_flag(TIF_RSEQ_FORCE_RESTART);
}
static __always_inline void clear_tif_rseq(void)
@@ -696,6 +701,7 @@ static __always_inline void clear_tif_rseq(void)
}
#else
static __always_inline bool test_tif_rseq(unsigned long ti_work) { return true; }
+static __always_inline void clear_tif_rseq_force_restart(void) { }
static __always_inline void clear_tif_rseq(void) { }
#endif
@@ -703,6 +709,11 @@ static __always_inline bool
rseq_exit_to_user_mode_restart(struct pt_regs *regs, unsigned long ti_work)
{
if (unlikely(test_tif_rseq(ti_work))) {
+ if (unlikely(ti_work & _TIF_RSEQ_FORCE_RESTART)) {
+ current->rseq.event.sched_switch = true;
+ current->rseq.event.ids_changed = true;
+ clear_tif_rseq_force_restart();
+ }
if (unlikely(__rseq_exit_to_user_mode_restart(regs))) {
current->rseq.event.slowpath = true;
set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
diff --git a/kernel/rseq.c b/kernel/rseq.c
index 38d3ef540760..9adc7f63adf5 100644
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -255,6 +255,19 @@ static bool rseq_handle_cs(struct task_struct *t, struct pt_regs *regs)
return false;
}
+void rseq_prepare_membarrier(struct mm_struct *mm)
+{
+ struct task_struct *t;
+
+ guard(mutex)(&mm->mm_cid.mutex);
+
+ hlist_for_each_entry(t, &mm->mm_cid.user_list, mm_cid.node) {
+ if (t == current)
+ continue;
+ set_tsk_thread_flag(t, TIF_RSEQ_FORCE_RESTART);
+ }
+}
+
static void rseq_slowpath_update_usr(struct pt_regs *regs)
{
/*
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 623445603725..696988bb991b 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -334,6 +334,7 @@ static int membarrier_private_expedited(int flags, int cpu_id)
MEMBARRIER_STATE_PRIVATE_EXPEDITED_RSEQ_READY))
return -EPERM;
ipi_func = ipi_rseq;
+ rseq_prepare_membarrier(mm);
} else {
WARN_ON_ONCE(flags);
if (!(atomic_read(&mm->membarrier_state) &
^ 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