* [PATCH v6 05/10] drm/rockchip: analogix_dp: Enable hclk for RK3588
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
Acquire and enable the HCLK_VO1 bus clock explicitly for RK3588
eDP controller to guarantee register and datapath access.
The clock was previously enabled implicitly via rockchip,vo-grf
phandle reference, which relies on side effect and is fragile.
Fetch optional "hclk" clock in driver to align with updated device
tree binding and keep consistent with hardware clock dependency.
Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 06072efd7fca..d2af5eb29dbb 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -311,6 +311,7 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
{
struct device *dev = dp->dev;
struct device_node *np = dev->of_node;
+ struct clk *clk;
dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(dp->grf))
@@ -327,6 +328,11 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
return dev_err_probe(dev, PTR_ERR(dp->pclk),
"failed to get pclk property\n");
+ clk = devm_clk_get_optional_enabled(dev, "hclk");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "failed to get hclk property\n");
+
dp->rst = devm_reset_control_get(dev, "dp");
if (IS_ERR(dp->rst))
return dev_err_probe(dev, PTR_ERR(dp->rst),
--
2.34.1
^ permalink raw reply related
* [PATCH v6 06/10] dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding,
Conor Dooley
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
RK3576 integrates an eDP TX controller compatible with the existing
RK3588 hardware design, reuse the same binding configuration directly.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v2:
- Split out a separate patch to add the "hclk" clock reference.
Chanegs in v4:
- Modify the commit msg.
Changes in v5:
- Add Acked-by tag.
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index d679da70947d..bb75d898a5c5 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -15,6 +15,7 @@ properties:
enum:
- rockchip,rk3288-dp
- rockchip,rk3399-edp
+ - rockchip,rk3576-edp
- rockchip,rk3588-edp
clocks:
@@ -92,6 +93,7 @@ allOf:
compatible:
contains:
enum:
+ - rockchip,rk3576-edp
- rockchip,rk3588-edp
then:
properties:
--
2.34.1
^ permalink raw reply related
* [PATCH v6 07/10] arm64: dts: rockchip: Add eDP node for RK3576
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
Add full device tree definition for the integrated eDP controller
on RK3576, following the existing RK3588 hardware layout.
Configure required register range, clocks, interrupt, phy, power
domain, reset and grf properties to fully describe the controller.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v2:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 28 ++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
index 28175d8200d5..733449cb88b1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
@@ -1496,6 +1496,34 @@ hdmi_out: port@1 {
};
};
+ edp: edp@27dc0000 {
+ compatible = "rockchip,rk3576-edp";
+ reg = <0x0 0x27dc0000 0x0 0x1000>;
+ clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>, <&cru HCLK_VO0_ROOT>;
+ clock-names = "dp", "pclk", "hclk";
+ interrupts = <GIC_SPI 365 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&hdptxphy>;
+ phy-names = "dp";
+ power-domains = <&power RK3576_PD_VO0>;
+ resets = <&cru SRST_EDP0_24M>, <&cru SRST_P_EDP0>;
+ reset-names = "dp", "apb";
+ rockchip,grf = <&vo0_grf>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in: port@0 {
+ reg = <0>;
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
dp: dp@27e40000 {
compatible = "rockchip,rk3576-dp";
reg = <0x0 0x27e40000 0x0 0x30000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Geert Uytterhoeven @ 2026-05-21 8:00 UTC (permalink / raw)
To: Cristian Marussi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sudeep Holla,
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: <agor5HJ0JFBoX3sZ@pluto>
Hi Cristian,
On Sun, 17 May 2026 at 22:58, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Fri, May 15, 2026 at 05:39:45PM +0200, Geert Uytterhoeven wrote:
> > 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....
> >
> > [...]
> >
> > > 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...
> >
> > So let's forward to the future, where the firmware is fixed, is fully
> > compliant with the SCMI spec, and all IDs are stable, so no quirks are
> > needed.
> >
> > Where do we specify the SCMI IDs to use? Unless when using the
> > remapping driver proposed in this patch series, they must end up in the
> > DTB. Existing upstream users put them either in the SoC-specific .dtsi,
> > or in board-specific .dts.
> >
> > The SCMI server is supposed to expose to an agent (e.g. Linux) a
> > sequential and contiguous list of IDs that represent only resources that
> > the agent is allowed to use.
> > - We cannot put the SCMI IDs in the SoC-specific .dtsi, as that
> > describes all hardware in the SoC, which is typically much more than
> > Linux can or even wants to use when running on a specific board.
> > - You would think we could put the SCMI IDs in the board-specific
> > .dts. However, that would limit actual use cases later, which do
> > not necessarily depend on the board solely.
> > - E.g. when moving control of the CAN-FD controller from Linux to
> > the Realtime OS, the CAN-FD node must be disabled in the DTB (by
> > overriding status to "reserved", or by just deleting the CAN-FD
> > node, both of which can be done by the boot loader). However,
> > with SCMI, the IDs corresponding to CAN-FD resources must be
> > removed from the ID space, causing a full renumbering. Who is
> > supposed to update the IDs in the DTB?
>
> As per my previous email, after such a breaking change I would expect a
> new DTB describing the new HW to be needed anyway.
The underlying hardware would still be the same...
> > - E.g. when partitioning a single Linux system in multiple VMs,
> > and distributing hardware across these VMs, all VMs need
> > different DTBs, each describing a subset of the hardware. With
> > SCMI, each VM needs different SCMI ID spaces, causing not a
> > simple partitioning of the devices in the DTB, but also a
> > renumbering of all IDs.
>
> Ok now I am lost..why do you need a distinct IDs space for each VM ?
Aren't the different VMs different SCMI agents? If not, how do you
prevent them from stepping on each other's resources?
> In a virtualized env, I would expect to leverage the SCMI stack to
> realize the exact opposite: same set of IDs advertised to each VM (and
> so same DTB potentially) by the server which in turn can decide to
> assign the same device (and handle the sharing) to some ID or assign
> different devices to the same or different IDs on each VM: i.e. you
> have a set of virtual_IDs that is what the server exposes to each VM
> SCMI agent, and then a bunch of real physical IDs, without any contraint
> on their numbering, that the server uses in the backstage to refer to
> the real resources and that it properly remaps to each per-VM set of
> exposed virtual_IDs during the build and/or boot board configuration
> phase....i.e. when the FW adapts and reconfigures to the specific
> board that is finally running on.
Again[1], how would that work? Clock, resets, and power domains are
not the final resources that are used by the OS. They are merely
resources for devices that are described in DTB with other resources
(MMIO register ranges, interrupt numbers, ...) which are not handled
by SCMI. If the server remaps e.g. a clock to a different clock,
it will no longer work with the corresponding device described in DT.
[1] https://lore.kernel.org/all/CAMuHMdVunEehM01pLa3t5a6o0NmMOCQRwh7n5J+OkDk2YR9kUA@mail.gmail.com
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] devfreq: Factor out devfreq_set_governor()
From: zhenglifeng (A) @ 2026-05-21 8:06 UTC (permalink / raw)
To: Jie Zhan, cwchoi00, cw00.choi, myungjoo.ham, kyungmin.park,
linux-pm, linux-arm-kernel
Cc: linuxarm, tianyaxiong, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <20260519113251.3745140-4-zhanjie9@hisilicon.com>
On 5/19/2026 7:32 PM, Jie Zhan wrote:
> governor_store() and devfreq_add_device() contain similar logic for setting
> a governor when devfreq->governor is NULL. Merge this into a common
> function, devfreq_set_governor(), to reduce code duplication and unify the
> entry of setting governors.
>
> This also prepares for further changes that get / put a module refcount of
> the active governor and prevent the governor module from being unloaded
> while it's in use.
>
> Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
> ---
> drivers/devfreq/devfreq.c | 117 ++++++++++++++++++--------------------
> 1 file changed, 56 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 53c40d795a13..9e3e6a7348f8 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -318,6 +318,59 @@ static struct devfreq_governor *try_then_request_governor(const char *name)
> return governor;
> }
>
> +static int devfreq_set_governor(struct devfreq *df,
> + const struct devfreq_governor *new_gov)
> +{
> + const struct devfreq_governor *old_gov;
> + struct device *dev;
> + int ret;
> +
> + lockdep_assert_held(&devfreq_list_lock);
> +
> + old_gov = df->governor;
> + dev = &df->dev;
> +
> + if (old_gov) {
> + if (old_gov == new_gov)
> + return 0;
> +
> + if (IS_SUPPORTED_FLAG(old_gov->flags, IMMUTABLE) ||
> + IS_SUPPORTED_FLAG(new_gov->flags, IMMUTABLE))
> + return -EINVAL;
> +
> + /* Stop the current governor */
> + ret = df->governor->event_handler(df, DEVFREQ_GOV_STOP, NULL);
> + if (ret) {
> + dev_warn(dev, "%s: Governor %s not stopped(%d)\n",
> + __func__, df->governor->name, ret);
> + return ret;
> + }
> + }
> +
> + /* Start the new governor */
> + df->governor = new_gov;
> + ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
> + if (ret) {
> + dev_warn(dev, "%s: Governor %s not started(%d)\n",
> + __func__, df->governor->name, ret);
> +
> + /* Restore previous governor */
> + df->governor = old_gov;
> + if (!df->governor)
> + return ret;
> +
> + ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
> + if (ret) {
> + dev_err(dev, "%s: restore Governor %s failed (%d)\n",
> + __func__, df->governor->name, ret);
> + df->governor = NULL;
> + return ret;
> + }
> + }
> +
> + return sysfs_update_group(&df->dev.kobj, &gov_attr_group);
Here is a little problem which is not introduced by this patch. When
starting new governor fails but restoring old governor succeeds, this
function will return 0. This might lead users to believe that the governor
has been successfully modified.
^ permalink raw reply
* Re: [PATCH v5 8/8] ARM: defconfig: Add a zx29 defconfig file
From: Stefan Dösinger @ 2026-05-21 8:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Jonathan Corbet, Shuah Khan, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <30b96e0d-f296-4c31-8701-a15c568ebffc@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 3910 bytes --]
Hi Arnd,
I saw your reply to my defconfig pull request, but apparently never received your original reply. I only found this mail here. It looks like I have to look for a better E-Mail provider as gmail is choking on the volume of the linux-arm-kernel mailing list.
To answer your questions I found at https://lore.kernel.org/all/61452117-0cdc-4ec2-83eb-dc03ccbd410b@app.fastmail.com/ :
> Either way, the patch description above should at least explain
> why you think you need your own defconfig, as we don't normally
> take those.
It was more cluelessness / being new to kernel development that gave me the impression that boards should have defconfigs. Since then I ran across scripts/dt_to_config. I haven't tested it yet on my DT, but if it does the right thing I don't think this board needs a defconfig.
>> +CONFIG_CMDLINE="console=ttyAMA0 earlyprintk root=/dev/ram rw"
> A definconfig should normall not rely on earlyprintk, just add
> that when you actually need to debug the super-early boot
> stages. With "earlycon" it should pick up the right console
> from the stdout path and work almost as early.
>> +CONFIG_BINFMT_FLAT=y
> Are you actually using flat binaries? I wasn't aware that this
> is still possible on MMU-enabled kernels.
>> +CONFIG_BLK_DEV_RAM=y
>> +CONFIG_BLK_DEV_RAM_COUNT=4
> The old ramdisk boot is going away in the future, please use
> initramfs instead. This should also save a good amount of RAM.
I'll fix those in my tree and keep the defconfig around just in case, but otherwise drop it from the submission. We can revisit it later when the board is more complete.
>> +CONFIG_DEVTMPFS=y # FIXME: This is specific to my initrd. Remove
>> before upstream
>stale comment?
I believe I removed this in later versions though :-)
Cheers,
Stefan
> Am 24.04.2026 um 11:54 schrieb Arnd Bergmann <arnd@arndb.de>:
>
> On Fri, Apr 24, 2026, at 09:13, Linus Walleij wrote:
>> On Tue, Apr 21, 2026 at 10:24 PM Stefan Dösinger
>> <stefandoesinger@gmail.com> wrote:
>>
>>> This enables existing drivers that already are (UART) or will be (USB,
>>> GPIO) necessary to operate this board even if they aren't declared in
>>> the DTS yet.
>>>
>>> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>>
>> *I* personally (as SoC maintainer) think that having a few more defconfigs
>> is fine, even helpful.
>>
>> But I would defer this to the more senior SoC maintainers because I think
>> their stance is something like:
>>
>> - We have multi_v7_defconfig for compile testing
>>
>> - We know that binary gets way to big for your system: it's for build
>> testing and perhaps booting in QEMU or systems with many MB of
>> RAM, not for actually running it on products.
>>
>> - You are encouraged to keep your own defconfig out-of-tree.
>
> Right, we clearly need to do something better than what we are with
> the general defconfigs, as I'm sure many of the existing ones are
> never actually used for booting a machine, and are horribly out of
> date with the Kconfig options.
>
> I wouldn't object to adding another defconfig for a new (or revived)
> soc family, but I don't want to have more per-board ones.
> Overall, we have about 70 defconfigs and 55 soc families that have their
> own mach-* directory (plus a few without code), and the number of
> defconfigs alone makes it hard to keep them up to date.
>
>> However I even challenged this myself by adding a defconfig for memory
>> constrained Broadcoms a while back (NACKed/ignored ;) so if it was all
>> up to me I would merge this.
>
> I don't even remember that discussion ;-)
>
> One idea might be to have a tiny base defconfig, plus platform
> specific fragments that add drivers. The problem is agreeing
> what bits are essential enough to still get enabled in the
> tiny config.
>
> Arnd
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Geert Uytterhoeven @ 2026-05-21 7:53 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: <agooKghZJw3iElvp@pluto>
Hi Cristian,
On Sun, 17 May 2026 at 22:42, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Fri, May 08, 2026 at 12:26:19PM +0200, Geert Uytterhoeven wrote:
> > On Mon, 27 Apr 2026 at 01:03, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > On Fri, Apr 24, 2026 at 02:08:55PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > > 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?
> > >
> > > I would NOT say that an SCMI FW must behave like this regarding IDs, but it
> > > is a possible SCMI deployed setup that can be useful in virtualized setups
> > >
> > > I mean, the DT describes the hardware of course BUT when you refer to
> > > some of this hardware DT bits from some other subsystem by referencing a
> > > phandle, even in the non-SCMI world, you are in fact selecting a specific
> > > resource that fit you use case, right ? Can we say this ?
> > > I mean you needed that specific clock or regulator that you described
> > > previously so as to be able to enable some other piece of HW...
> > >
> > > Now, the SCMI provides an abstraction on top of this, since you really
> > > discover domain IDs of a specific class (clocks/regulators etc) you are
> > > in fact describing an HW abstraction that you then refer with the usual
> > > phandle...also because there is NOT so much SCMI hardware to describe,
> > > given that the HW is handled transparently (opaquely really :P) by the
> > > driver on the FW side...
> > >
> > > ...you basically obtain such domain ID, usable as phandles through dynamic
> > > SCMI enumeration so that you can use it all over your DT to make use of such
> > > resources...
> > >
> > > ...on top of this, consider that the SCMI server CAN provide to its agents
> > > a per-agent-view of the world, IOW it can (and should) expose to a specific
> > > agent ONLY the resources needed by that agent, i.e. it can expose the set
> > > of resources 1-N to two distinct agents and that does NOT mean that the
> > > underlying physical resource mapped by ID=3 in both agents has to be
> > > effectively the same piece of hardware: it could be the case, and this
> > > would be useful to exposed and managed properly a shared resource, or
> > > it could also be that the same ID=3 could refer to completely distinct
> > > pieces of the same class of hardware...(same protocol same class of
> > > resource...)
> >
> > Exposing only the clocks/reset/power domains the agent can use,
> > in a contiguous list of IDS, means that the number space changes,
> > depending on which resources are exposed.
>
> Yes, potentially, it depedns on how the HW/FW stack was designed I
> suppose...
>
> > Suppose you have a system where you want to assign a specific hardware
> > block in the SoC to the realtime CPU core instead of the application
> > CPU core running Linux.
>
> Ok, so this is definitely a considerable change.
>
> > That means all resources used by that block must no longer be exposed
> > to the Linux agent, and the corresponding IDs must be removed from
> > the ID space exposed to Linux. As the ID space must be sequential
> > and contiguous, the IDs must be renumbered, impacting resources that
> > are exposed to Linux. As these IDs are used in the SoC .dtsi, they
> > must be changed there, too, However, these IDs have become part of
> > the stable DT ABI, and thus cannot be changed.
>
> Well, you have to ship a final DTB blob that is crafted to describe the
> actual HW at the end, right ?
>
> I mean, in your example, it seems to me that you have changed considerably
> the HW surface by moving a clock (and its related resources) away from the
> reach of Linux as a whole, so should not be expected to have an updated
> DTB shipped ?
It is not necessary to ship an updated DTB.
The bootloader stack can just change the "status" properties of devices
nodes that are be taken away from Linux from "okay" to "reserved":
Devicetree Specification, Release v0.4, Table 2.4: Values for statu
property states:
Value: "reserved"
Description:
Indicates that the device is operational, but should not be
used. Typically this is used for devices that are controlled
by another software component, such as platform firmware.
When all SCMI IDs change, too, much more work needs to be done.
The remap driver could also help here: it could scan for device nodes
that are marked "reserved", remove SCMI IDs used in these nodes from
its internal tables, and adjust all later (higher) IDs.
E.g. the existing drivers/clk/renesas/renesas-cpg-mssr.c already handles
(ignores) clocks used by reserved nodes.
> And I am NOT saying to do this by changing the base SoC dtsi, but via build
> time overrides and/or runtime overlays so as to derive from that same SoC
> base dtsi a properly reviewed final DTB that describes how the HW has actually
> changed, becasue beside the renumbering that you mention there will be
> also a bunch of HW pieces that were relying on that clock that now will
> have to be removed from the DTB if no more usable (or remapped to use a
> different, maybe non SCMI resource)
>
> I maybe too naive and not used to very complex DTBs, but why all of the
> above cannot be done along the lines of how is done as an example in
> JUNO [1], where some initial base dtsi was overriden by virtue of includes
> and overrides to properly describe the board at hand (r0/r1/r2), even going
> to the extreme, funny enough, to move from the old SCPI to SCMI.
>
> [1]: https://elixir.bootlin.com/linux/v7.0.8/source/arch/arm64/boot/dts/arm/juno-scmi.dts
As long as the IDs in arch/arm64/boot/dts/arm/juno-scmi.dtsi
match the actual SCMI implementation, that works...
> > This patch series fixes that issue, too, by describing the actual
> > hardware in DT, and doing the mapping to exposed SCMI features in the
> > kernel, based on which firmware version is running on the SCP.
>
> Which seems to me to go in the opposite direction to what SCMI expects:
> but I understand that we have to deal and cope with the existing already
> shipped FW, so my concern is not really around enabling this in particular,
> is much more the fact that we open the door and normalize this kind of
> design even with future, still to be developed, SCMI FWs.
>
> ...otherwise...have the spec changed/clarified to allow for such
> non-contiguos IDs...
>
> ...anyway let's hear Sudeep opinion on this general issue of contiguos
> remapped IDs and being able to peek into SCMI version from outside the
> SCMI world...
As long as the ID space becomes stable.
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 7/8] sched_ext: Sub-allocator over kernel-claimed BPF arena pages
From: Andrea Righi @ 2026-05-21 7:56 UTC (permalink / raw)
To: Tejun Heo
Cc: David Vernet, Changwoo Min, Alexei Starovoitov, Andrii Nakryiko,
Daniel Borkmann, Martin KaFai Lau, Kumar Kartikeya Dwivedi,
Peter Zijlstra, Catalin Marinas, Will Deacon, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, Andrew Morton,
David Hildenbrand, Mike Rapoport, Emil Tsalapatis, sched-ext, bpf,
x86, linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <20260520235052.4180316-8-tj@kernel.org>
Hi Tejun,
On Wed, May 20, 2026 at 01:50:51PM -1000, Tejun Heo wrote:
> Build a per-scheduler sub-allocator on top of pages claimed from the BPF
> arena registered in the previous patch. Subsequent kernel-managed
> arena-resident structures (e.g. per-CPU set_cmask cmask) carve their storage
> from this pool.
>
> scx_arena_pool_init() creates a gen_pool. scx_arena_alloc() returns the
> kernel VA. On exhaustion, the pool grows by claiming more pages via
> bpf_arena_alloc_pages_sleepable(). Chunks are added at the kernel-side
> mapping address; callers translate to the BPF-arena form themselves if
> needed.
>
> Allocations sleep (GFP_KERNEL) - they may grow the pool through vzalloc and
> arena page allocation. All current consumers run from the enable path (after
> ops.init() and the kernel-side arena auto-discovery, before validate_ops()),
> where sleeping is fine.
>
> scx_arena_pool_destroy() walks each chunk, returns outstanding ranges to the
> gen_pool with gen_pool_free() and then calls gen_pool_destroy(). The
> underlying arena pages are released when the arena map itself is torn down,
> so the pool destroy doesn't free them explicitly.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
...
> +/*
> + * Allocate @size bytes from the arena pool. Returns kernel VA on success, NULL
> + * on failure. May grow the pool via scx_arena_grow() which sleeps. Caller must
> + * be in a GFP_KERNEL context.
> + */
> +void *scx_arena_alloc(struct scx_sched *sch, size_t size)
> +{
> + unsigned long kern_va;
> + u32 page_cnt;
> +
> + might_sleep();
> +
> + if (!sch->arena_pool)
> + return NULL;
> +
> + kern_va = gen_pool_alloc(sch->arena_pool, size);
> + if (!kern_va) {
> + page_cnt = max_t(u32, SCX_ARENA_GROW_PAGES,
> + (size + PAGE_SIZE - 1) >> PAGE_SHIFT);
> + if (scx_arena_grow(sch, page_cnt))
> + return NULL;
> + kern_va = gen_pool_alloc(sch->arena_pool, size);
> + if (!kern_va)
> + return NULL;
IIUC, since @page_cnt is sized to cover @size and the new chunk is added empty
to the pool, gen_pool_alloc() here should always succeed. Should we do:
if (WARN_ON_ONCE(!kern_va))
return NULL;
to catch potential logical bugs / future concurrency / exotic configurations?
Thanks,
-Andrea
^ permalink raw reply
* Re: [PATCH v6 02/22] drm/connector: Add HDMI 2.0 scrambler infrastructure
From: Maxime Ripard @ 2026-05-21 7:52 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Sandy Huang,
Heiko Stübner, Andy Yan, Luca Ceresoli, Daniel Stone, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260520-dw-hdmi-qp-scramb-v6-2-24b74603b782@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 4981 bytes --]
Hi,
Thanks for working on this!
On Wed, May 20, 2026 at 09:38:13PM +0300, Cristian Ciocaltea wrote:
> Add the connector-level infrastructure to support HDMI 2.0 scrambling:
>
> - .scrambler_src_{enable|disable}() callbacks in
> drm_connector_hdmi_funcs for source-side scrambling control
> - A delayed work item (scdc_work) with an associated callback (scdc_cb)
> for periodic monitoring of sink-side scrambling status
> - A scrambler_enabled flag to track whether scrambling is currently
> active
>
> These are intended to be used by SCDC scrambling helpers to coordinate
> scrambling setup and teardown between the source driver and the DRM
> core.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> drivers/gpu/drm/drm_connector.c | 14 +++++++++++
> include/drm/drm_connector.h | 52 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 66 insertions(+)
So we would need kunit tests for this.
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 3fa4d2082cd7..91e58362fbc0 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -220,6 +220,19 @@ void drm_connector_free_work_fn(struct work_struct *work)
> }
> }
>
> +static void drm_connector_hdmi_scdc_work(struct work_struct *work)
> +{
> + struct drm_connector *connector;
> + struct drm_connector_hdmi *hdmi;
> +
> + hdmi = container_of(to_delayed_work(work), struct drm_connector_hdmi,
> + scdc_work);
> + connector = container_of(hdmi, struct drm_connector, hdmi);
> +
> + if (hdmi->scdc_cb)
> + hdmi->scdc_cb(connector);
> +}
> +
> static int drm_connector_init_only(struct drm_device *dev,
> struct drm_connector *connector,
> const struct drm_connector_funcs *funcs,
> @@ -285,6 +298,7 @@ static int drm_connector_init_only(struct drm_device *dev,
> mutex_init(&connector->edid_override_mutex);
> mutex_init(&connector->hdmi.infoframes.lock);
> mutex_init(&connector->hdmi_audio.lock);
> + INIT_DELAYED_WORK(&connector->hdmi.scdc_work, drm_connector_hdmi_scdc_work);
> connector->edid_blob_ptr = NULL;
> connector->epoch_counter = 0;
> connector->tile_blob_ptr = NULL;
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 5ad62c207d00..49eaa30b1329 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -28,6 +28,7 @@
> #include <linux/ctype.h>
> #include <linux/hdmi.h>
> #include <linux/notifier.h>
> +#include <linux/workqueue.h>
> #include <drm/drm_mode_object.h>
> #include <drm/drm_util.h>
> #include <drm/drm_property.h>
> @@ -1358,6 +1359,36 @@ struct drm_connector_hdmi_funcs {
> */
> const struct drm_edid *(*read_edid)(struct drm_connector *connector);
>
> + /**
> + * @scrambler_src_enable:
> + *
> + * This callback is invoked through @drm_scdc_start_scrambling during
> + * a commit to setup SCDC scrambling and high TMDS clock ratio on
> + * source side.
> + *
> + * The @scrambler_src_enable callback is mandatory if HDMI 2.0 is
> + * to be supported.
> + *
> + * Returns:
> + * 0 on success, a negative error code otherwise
> + */
> + int (*scrambler_src_enable)(struct drm_connector *connector);
> +
> + /**
> + * @scrambler_src_disable:
> + *
> + * This callback is invoked through @drm_scdc_stop_scrambling during
> + * a commit to disable SCDC scrambling and high TMDS clock ratio on
> + * source side.
> + *
> + * The @scrambler_src_disable callback is mandatory if HDMI 2.0 is
> + * to be supported.
> + *
> + * Returns:
> + * 0 on success, a negative error code otherwise
> + */
> + int (*scrambler_src_disable)(struct drm_connector *connector);
> +
> /**
> * @avi:
> *
> @@ -1944,6 +1975,27 @@ struct drm_connector_hdmi {
> */
> unsigned long supported_formats;
>
> + /**
> + * @scrambler_enabled: Tracks whether HDMI 2.0 scrambler is currently enabled.
> + */
> + bool scrambler_enabled;
> +
> + /**
> + * @scdc_work: Work item currently used to monitor sink-side scrambling
> + * status and retry setup if the sink resets it.
> + */
> + struct delayed_work scdc_work;
> +
> + /** @scdc_cb: Callback to be invoked as part of @scdc_work.
> + *
> + * Currently used to monitor sink-side scrambling status and retry
> + * setup if the sink resets it.
> + *
> + * This is assigned by the framework when making use of
> + * drm_scdc_start_scrambling() helper.
> + */
> + void (*scdc_cb)(struct drm_connector *connector);
> +
I'm really not sure what the monitor thing is about. If we have setup
the scrambler at enable time, and we set it again on hotplugging, why
would we need to monitor anything?
Also, scrambling is only relevant for HDMI 2.0. We need a way to expose
that somehow and make sure that HDMI 2.0 drivers actually have
scrambling setup.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] mfd: max77620: override PSCI poweroff handler on Pixel C
From: Thierry Reding @ 2026-05-21 7:52 UTC (permalink / raw)
To: Diogo Ivo
Cc: Mark Rutland, Lorenzo Pieralisi, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, linux-arm-kernel, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <20260514-smaug-poweroff-v1-3-30f9a4688966@tecnico.ulisboa.pt>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
On Thu, May 14, 2026 at 04:47:21PM +0200, Diogo Ivo wrote:
> On Pixel C, shutdown must be handled by the MAX77620 PMIC rather
> than the PSCI SYSTEM_OFF call, whose firmware implementation is:
>
> __dead2 void tegra_system_off(void)
> {
> ERROR("Tegra System Off: operation not handled.\n");
> panic();
> }
Ugh... sounds very familiar. We have similar stub implementations on
Jetson TX1 and/or Nano, if I remember correctly. Luckily newer platforms
seem to have proper implementations for these.
Thanks for doing this. I might want to take inspiration from this for
these older Jetson platforms.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v3 1/6] drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()
From: Maxime Ripard @ 2026-05-21 7:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou, dri-devel, linux-kernel, linux-usb, intel-gfx,
intel-xe, linux-amlogic, linux-arm-kernel, linux-arm-msm,
freedreno
In-Reply-To: <20260513-hpd-irq-events-v3-1-086857017f16@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 3098 bytes --]
On Wed, May 13, 2026 at 09:23:21PM +0300, Dmitry Baryshkov wrote:
> The DisplayPort standard defines a special kind of events called IRQ.
> These events are used to notify DP Source about the events on the Sink
> side. It is extremely important for DP MST handling, where the MST
> events are reported through this IRQ.
>
> In case of the USB-C DP AltMode there is no actual HPD pulse, but the
> events are ported through the bits in the AltMode VDOs.
>
> Extend the drm_connector_oob_hotplug_event() interface and report IRQ
> events to the DisplayPort Sink drivers.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpu/drm/drm_connector.c | 5 ++++-
> drivers/usb/typec/altmodes/displayport.c | 15 +++++++++++----
> include/drm/drm_connector.h | 19 ++++++++++++++++++-
> 3 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 47dc53c4a738..edee9daccd51 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -3510,6 +3510,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to connector
> * @connector_fwnode: fwnode_handle to report the event on
> * @status: hot plug detect logical state
> + * @extra_status: additional information provided by the sink without changing
> + * the HPD state (or in addition to such a change).
> *
> * On some hardware a hotplug event notification may come from outside the display
> * driver / device. An example of this is some USB Type-C setups where the hardware
> @@ -3520,7 +3522,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> * a drm_connector reference through calling drm_connector_find_by_fwnode().
> */
> void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct drm_connector *connector;
>
> diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
> index 35d9c3086990..7182a8e2e710 100644
> --- a/drivers/usb/typec/altmodes/displayport.c
> +++ b/drivers/usb/typec/altmodes/displayport.c
> @@ -189,7 +189,9 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
> } else {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> hpd ? connector_status_connected :
> - connector_status_disconnected);
> + connector_status_disconnected,
> + (hpd && irq_hpd) ? DRM_CONNECTOR_DP_IRQ_HPD :
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
Since the extra status itself, and what the options mean, are DP specific, do we really want to
extend drm_connector_oob_hotplug_event()? I think I'd prefer to have a DP specific variant, with its
own set of parameters.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v8 2/5] dt-bindings: phy: Add documentation for Airoha AN7581 USB PHY
From: Krzysztof Kozlowski @ 2026-05-21 7:44 UTC (permalink / raw)
To: Christian Marangi
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Lorenzo Bianconi, Felix Fietkau, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260520150912.11614-3-ansuelsmth@gmail.com>
On Wed, May 20, 2026 at 05:09:07PM +0200, Christian Marangi wrote:
> Add documentation for Airoha AN7581 USB PHY that describe the USB PHY
> for the USB controller.
>
> Airoha AN7581 SoC support a maximum of 2 USB port. The USB 2.0 mode is
> always supported. The USB 3.0 mode is optional and depends on the Serdes
> mode currently configured on the system for the relevant USB port.
>
> To correctly calibrate, the USB 2.0 port require correct value in
> "airoha,usb2-monitor-clk-sel" property. Both the 2 USB 2.0 port permit
> selecting one of the 4 monitor clock for calibration (internal clock not
> exposed to the system) but each port have only one of the 4 actually
> connected in HW hence the correct value needs to be specified in DT
> based on board and the physical port. Normally it's monitor clock 1 for
> USB1 and monitor clock 2 for USB2.
>
> To correctly setup the Serdes mode attached to the USB 3.0 mode, a phys
> property is required with the phandle pointing to the correct Serdes port
> provided by the SCU node.
^^^ here - required but:
> + phys:
> + items:
> + - description: phandle to Serdes PHY
> +
> + '#phy-cells':
> + description: The cell contains the mode, PHY_TYPE_USB2 or PHY_TYPE_USB3,
> + as defined in dt-bindings/phy/phy.h.
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - airoha,usb2-monitor-clk-sel
'phys' is not required? I think you need it to configure the serdes
correctly, no?
> + - '#phy-cells'
> +
> +additionalProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 1/5] dt-bindings: clock: airoha: Add PHY binding for Serdes port
From: Krzysztof Kozlowski @ 2026-05-21 7:41 UTC (permalink / raw)
To: Christian Marangi
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Lorenzo Bianconi, Felix Fietkau, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260520150912.11614-2-ansuelsmth@gmail.com>
On Wed, May 20, 2026 at 05:09:06PM +0200, Christian Marangi wrote:
> Add PHY cell property for Serdes port selection. Currently supported only
> for Airoha AN7581 SoC, that support up to 4 Serdes port.
>
> The Serdes port can support both PCIe, USB3 or Ethernet mode.
>
> - PCIe1 Serdes can support PCIe or Ethernet mode.
> - PCIe2 Serdes can support PCIe or Ethernet mode.
> - USB1 Serdes can support USB3 or HSGMII mode.
> - USB2 Serdes can support USB3 or PCIe mode.
>
> Add bindings to permit correct reference of the Serdes ports in DT.
> Values are just symbolic and enumerates the Serdes port with a specific
> number for precise reference.
>
> The available Serdes port can be selected following the dt-binding header
> in [2].
>
> [2] <include/dt-bindings/soc/airoha,scu-ssr.h>
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> .../devicetree/bindings/clock/airoha,en7523-scu.yaml | 9 +++++++++
> include/dt-bindings/soc/airoha,scu-ssr.h | 11 +++++++++++
> 2 files changed, 20 insertions(+)
> create mode 100644 include/dt-bindings/soc/airoha,scu-ssr.h
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
From: Baolu Lu @ 2026-05-21 7:39 UTC (permalink / raw)
To: Joonwon Kang, jgg, will, robin.murphy, joro, jpb
Cc: Alexander.Grest, amhetre, easwar.hariharan, jacob.jun.pan, kees,
kevin.tian, nicolinc, praan, smostafa, tglx, mingo, bp,
dave.hansen, x86, hpa, peterz, sohil.mehta, kas,
alexander.shishkin, ryasuoka, xin, linux-kernel, iommu,
linux-arm-kernel
In-Reply-To: <20260520150743.727106-1-joonwonkang@google.com>
On 5/20/26 23:07, 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-process; when a process wants to
> communicate with multiple devices with the ENQCMD instruction, it cannot
> change its PASID for each device without the kernel's intervention. Also
> note that ARM introduced a similar instruction, which is ST64BV0.
>
> Due to this nature, SVA with ARM SMMU v3 has been found not working in
> our environment when other modules/devices compete for PASID. The
> environment looks as follows:
>
> - 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.
>
> 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.
>
> This commit resolves the issue by allowing device driver to maintain its
> own PASID space and assign a PASID from that for the process-device bond
> via a new API called `iommu_sva_bind_device_pasid(dev, mm, pasid)`. Doing
> that, however, will disallow the process to execute the ENQCMD-like
> instructions at EL0. It is because the process cannot change its PASID in
> IA32_PASID(or ACCDATA_EL1 on ARM) for each device without the kernel's
> intervention. For this reason, calling `iommu_sva_bind_device()` and then
> `iommu_sva_bind_device_pasid()` for the same process will not be allowed
> and vice versa.
>
> Currently, there is a limitation that a process simultaneously doing SVA
> with multiple devices with different PASIDs is not supported. So, calling
> `iommu_sva_bind_device_pasid()` multiple times for the same process with
> different devices will not be allowed for now while that for
> `iommu_sva_bind_device()` will be.
>
> Another limitation is that a process cannot do `iommu_sva_bind_device()`
> if it has ever done `iommu_sva_bind_device_pasid()` even though it has
> been unbound after use.
>
> Suggested-by: Jason Gunthorpe<jgg@ziepe.ca>
> Suggested-by: Kevin Tian<kevin.tian@intel.com>
> Signed-off-by: Joonwon Kang<joonwonkang@google.com>
> ---
> v2: Reuse iommu_mm->pasid after SVA bound by iommu_sva_bind_device_pasid()
> is unbound.
> v1: Initial version.
>
> arch/x86/kernel/traps.c | 9 +--
> drivers/iommu/iommu-sva.c | 151 +++++++++++++++++++++++++++++---------
> include/linux/iommu.h | 14 +++-
> 3 files changed, 134 insertions(+), 40 deletions(-)
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 0ca3912ecb7f..0131c8e5fb10 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -857,13 +857,12 @@ static bool try_fixup_enqcmd_gp(void)
> return false;
>
> /*
> - * If the mm has not been allocated a
> - * PASID, the #GP can not be fixed up.
> + * If the mm has not been allocated a PASID or ENQCMD has been
> + * disallowed, the #GP can not be fixed up.
> */
> - if (!mm_valid_pasid(current->mm))
> - return false;
> -
> pasid = mm_get_enqcmd_pasid(current->mm);
> + if (pasid == IOMMU_PASID_INVALID)
> + return false;
>
> /*
> * Did this thread already have its PASID activated?
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index bc7c7232a43e..a83333651ad0 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -10,6 +10,9 @@
>
> #include "iommu-priv.h"
>
> +/* Whether pasid is to be allocated from the global PASID space */
> +#define IOMMU_PASID_GLOBAL_ANY IOMMU_NO_PASID
> +
> static DEFINE_MUTEX(iommu_sva_lock);
> static bool iommu_sva_present;
> static LIST_HEAD(iommu_sva_mms);
> @@ -17,10 +20,11 @@ static struct iommu_domain *iommu_sva_domain_alloc(struct device *dev,
> struct mm_struct *mm);
>
> /* Allocate a PASID for the mm within range (inclusive) */
> -static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct device *dev)
> +static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm,
> + struct device *dev,
> + ioasid_t pasid)
> {
> struct iommu_mm_data *iommu_mm;
> - ioasid_t pasid;
>
> lockdep_assert_held(&iommu_sva_lock);
>
> @@ -30,8 +34,27 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de
> iommu_mm = mm->iommu_mm;
> /* Is a PASID already associated with this mm? */
> if (iommu_mm) {
> + if ((pasid == IOMMU_PASID_GLOBAL_ANY && !iommu_mm->pasid_global) ||
> + (pasid != IOMMU_PASID_GLOBAL_ANY && iommu_mm->pasid_global))
> + return ERR_PTR(-EBUSY);
> +
> + if (!iommu_mm->pasid_global) {
> + if (list_empty(&iommu_mm->sva_domains))
> + iommu_mm->pasid = pasid;
> +
> + if (pasid != iommu_mm->pasid) {
> + /*
> + * Currently, a process simultaneously doing
> + * SVA with multiple devices with different
> + * PASIDs is not supported.
> + */
I am a bit confused by the change in this helper and the comments above.
Currently, when an mm is bound to a device, it uses a PASID allocated
from the global pool. That implies that all devices access the
application's address space with the same PASID. Now we want to extend
this by allowing the device driver to manage the PASID for SVA, which
should mean different devices might use different PASIDs to access the
application's address space. But this does not seem to match the logic
in this helper.
Perhaps I overlooked something?
> + return ERR_PTR(-ENOSPC);
> + }
> + }
> +
> if (iommu_mm->pasid >= dev->iommu->max_pasids)
> return ERR_PTR(-EOVERFLOW);
> +
> return iommu_mm;
> }
Thanks,
baolu
^ permalink raw reply
* Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Mukesh Savaliya @ 2026-05-21 7:40 UTC (permalink / raw)
To: Carlos Song (OSS), o.rempel, kernel, andi.shyti, Frank.Li,
s.hauer, festevam, carlos.song, haibo.chen
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260520101504.2885873-1-carlos.song@oss.nxp.com>
Hi Carlos,
On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
> From: Carlos Song <carlos.song@nxp.com>
>
> Mark the I2C adapter as suspended during system suspend to block further
> transfers, and resume it on system resume. This prevents potential hangs
> when the hardware is powered down but clients still attempt I2C transfers.
>
Code changes looks fine to me but have comment on commit log.
It seems, you are adding support of _noirq() callbacks to allow
transfers during suspend/resume noirq phase of PM.
Would it make sense if you can write "Replace system PM callbacks with
noirq PM callbacks" OR "Allow transfers during _noirq phase of the PM
ops" instead of "mark I2C adapter when hardware is powered down" ?
> Fixes: 358025ac091e ("i2c: imx: make controller available until system suspend_noirq() and from resume_noirq()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
> ---
> Change for v3:
> - Add hrtimer_cancel in i2c_imx_suspend_noirq to cancel slave_timer for
> safe suspend in i2c slave mode.
> Change for v2:
> - Call i2c_mark_adapter_suspended() before pm_runtime_force_suspend()
> to prevent potential deadlock if a transfer is active during suspend.
> - Roll back with i2c_mark_adapter_resumed() if pm_runtime_force_suspend()
> fails.
> ---
[...]
^ permalink raw reply
* [PATCH v4 3/3] media: meson: vdec: Cancel esparser work in error and stop paths
From: Anand Moon @ 2026-05-21 7:34 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Maxime Jourdan,
Hans Verkuil,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:STAGING SUBSYSTEM,
moderated list:ARM/Amlogic Meson SoC support, open list
Cc: Sashiko, Nicolas Dufresne
In-Reply-To: <20260521073449.10057-1-linux.amoon@gmail.com>
Ensure that esparser_queue_work is canceled before freeing the
session context. Add cancel_work_sync() in both the error path
of vdec_close() and vdec_start_streaming() and in vdec_stop_streaming().
This prevents background work from dereferencing a freed sess
structure and triggering a use-after-free.
Cc: Nicolas Dufresne <nicolas@ndufresne.ca>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260520045905.6ACBA1F000E9@smtp.kernel.org/#t
Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
v4: new patch
If vdec_close() calls kfree(sess) without first stopping or synchronizing
with this background work via cancel_work_sync(), could a concurrently
running esparser_queue_all_src() dereference the freed sess structure and
trigger a use-after-free?
---
drivers/staging/media/meson/vdec/vdec.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 8615a935e86d..a57bd4a8e33c 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -358,6 +358,8 @@ static int vdec_start_streaming(struct vb2_queue *q, unsigned int count)
dma_free_coherent(sess->core->dev, sess->vififo_size,
sess->vififo_vaddr, sess->vififo_paddr);
bufs_done:
+ cancel_work_sync(&sess->esparser_queue_work);
+
if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
sess->streamon_out = 0;
else
@@ -415,6 +417,7 @@ static void vdec_stop_streaming(struct vb2_queue *q)
if (vdec_codec_needs_recycle(sess))
kthread_stop(sess->recycle_thread);
+ cancel_work_sync(&sess->esparser_queue_work);
vdec_poweroff(sess);
vdec_free_canvas(sess);
dma_free_coherent(sess->core->dev, sess->vififo_size,
@@ -937,6 +940,7 @@ static int vdec_close(struct file *file)
v4l2_m2m_ctx_release(sess->m2m_ctx);
v4l2_m2m_release(sess->m2m_dev);
v4l2_ctrl_handler_free(&sess->ctrl_handler);
+ cancel_work_sync(&sess->esparser_queue_work);
v4l2_fh_del(&sess->fh, file);
v4l2_fh_exit(&sess->fh);
--
2.50.1
^ permalink raw reply related
* [PATCH v4 2/3] media: meson: vdec: Add error handling for recycle thread creation
From: Anand Moon @ 2026-05-21 7:34 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Hans Verkuil,
Maxime Jourdan,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:STAGING SUBSYSTEM,
moderated list:ARM/Amlogic Meson SoC support, open list
Cc: Sashiko, Nicolas Dufresne
In-Reply-To: <20260521073449.10057-1-linux.amoon@gmail.com>
Add proper error handling for kthread_run() in vdec_start_streaming().
If thread creation fails and returns an ERR_PTR, record the error,
reset sess->recycle_thread to NULL, and unwind resources via err_cleanup.
This prevents later calls to kthread_stop() in vdec_stop_streaming() from
dereferencing an ERR_PTR and causing a kernel panic. Fix this by adding the
label and invoking vdec_poweroff() to prevent hardware power leaks.
Additionally, reorder the error path to properly mirror the allocation
sequence clear the streamon status flags before emptying the M2M buffers
to avoid race conditions, and ensure DMA buffers are released gracefully
relative to the hardware state lifecycle.
Cc: Nicolas Dufresne <nicolas@ndufresne.ca>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260520045905.6ACBA1F000E9@smtp.kernel.org/#t
Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
v4: new patch
[Severity: High]
This isn't a bug introduced by this patch, but does the driver verify if
kthread_run() returns an ERR_PTR when starting the recycle thread?
If thread creation fails in vdec_start_streaming() and returns an ERR_PTR,
could a later call to kthread_stop(sess->recycle_thread) in
vdec_stop_streaming() attempt to dereference that ERR_PTR and cause a
kernel panic?
---
drivers/staging/media/meson/vdec/vdec.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 9244fb09eb36..8615a935e86d 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -337,29 +337,37 @@ static int vdec_start_streaming(struct vb2_queue *q, unsigned int count)
sess->sequence_cap = 0;
sess->sequence_out = 0;
- if (vdec_codec_needs_recycle(sess))
+ if (vdec_codec_needs_recycle(sess)) {
sess->recycle_thread = kthread_run(vdec_recycle_thread, sess,
"vdec_recycle");
+ if (IS_ERR(sess->recycle_thread)) {
+ ret = PTR_ERR(sess->recycle_thread);
+ sess->recycle_thread = NULL;
+ goto err_cleanup;
+ }
+ }
sess->status = STATUS_INIT;
core->cur_sess = sess;
schedule_work(&sess->esparser_queue_work);
return 0;
+err_cleanup:
+ vdec_poweroff(sess);
vififo_free:
dma_free_coherent(sess->core->dev, sess->vififo_size,
sess->vififo_vaddr, sess->vififo_paddr);
bufs_done:
- while ((buf = v4l2_m2m_src_buf_remove(sess->m2m_ctx)))
- v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
- while ((buf = v4l2_m2m_dst_buf_remove(sess->m2m_ctx)))
- v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
-
if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
sess->streamon_out = 0;
else
sess->streamon_cap = 0;
+ while ((buf = v4l2_m2m_src_buf_remove(sess->m2m_ctx)))
+ v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
+ while ((buf = v4l2_m2m_dst_buf_remove(sess->m2m_ctx)))
+ v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
+
return ret;
}
--
2.50.1
^ permalink raw reply related
* [PATCH v4 1/3] media: meson: vdec: Fix memory leak in error path of vdec_open
From: Anand Moon @ 2026-05-21 7:34 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Hans Verkuil,
Maxime Jourdan,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:STAGING SUBSYSTEM,
moderated list:ARM/Amlogic Meson SoC support, open list
Cc: Sashiko, Nicolas Dufresne
In-Reply-To: <20260521073449.10057-1-linux.amoon@gmail.com>
The vdec_open() function previously jumped directly to err_m2m_release
when vdec_init_ctrls() failed, skipping release of the m2m context.
This caused a resource leak.
Fix it by introducing a proper err_m2m_ctx_release label that calls
v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device.
Also free the v4l2 control handler memory allocated by vdec_init_ctrls()
in vdec_close().
This was identified via kmemleak:
unreferenced object 0xffff0000205d6878 (size 8):
comm "v4l_id", pid 5289, jiffies 4294938580
hex dump (first 8 bytes):
40 d2 49 18 00 00 ff ff @.I.....
backtrace (crc d3204599):
kmemleak_alloc+0xc8/0xf0
__kvmalloc_node_noprof+0x60c/0x850
v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev]
vdec_open+0x1f4/0x788 [meson_vdec]
v4l2_open+0x144/0x460 [videodev]
chrdev_open+0x1ac/0x500
do_dentry_open+0x3f0/0xfe8
vfs_open+0x68/0x320
do_open+0x2d8/0x9a8
path_openat+0x1d0/0x4f0
do_filp_open+0x190/0x380
do_sys_openat2+0xf8/0x1b0
__arm64_sys_openat+0x13c/0x1e8
invoke_syscall+0xdc/0x268
el0_svc_common.constprop.0+0x178/0x258
do_el0_svc+0x4c/0x70
Cc: Nicolas Dufresne <nicolas@ndufresne.ca>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260520045905.6ACBA1F000E9@smtp.kernel.org/#t
Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
v4: update the commit message to add v4l2_ctrl_handler_free() in vdec_close()
to adderss the issue:
This isn't a bug introduced by this patch, but does vdec_close() properly
free the v4l2 control handler memory allocated by vdec_init_ctrls() here?
v3: https://lore.kernel.org/all/20260520044046.7553-1-linux.amoon@gmail.com/
update the commit messagee.
v2: https://lore.kernel.org/all/20260321065408.209723-1-linux.amoon@gmail.com/
updated the commit message, applied the suggestion from sashiko below.
[3] https://sashiko.dev/#/patchset/20260321065408.209723-1-linux.amoon%40gmail.com
v1: https://lore.kernel.org/all/20260304100557.126488-1-linux.amoon@gmail.com/
tried to address the issue reported by Nicolas improve the commit message.
---
drivers/staging/media/meson/vdec/vdec.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 4b77ec1af5a7..9244fb09eb36 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -889,7 +889,7 @@ static int vdec_open(struct file *file)
ret = vdec_init_ctrls(sess);
if (ret)
- goto err_m2m_release;
+ goto err_m2m_ctx_release;
sess->pixfmt_cap = formats[0].pixfmts_cap[0];
sess->fmt_out = &formats[0];
@@ -913,6 +913,8 @@ static int vdec_open(struct file *file)
return 0;
+err_m2m_ctx_release:
+ v4l2_m2m_ctx_release(sess->m2m_ctx);
err_m2m_release:
v4l2_m2m_release(sess->m2m_dev);
err_free_sess:
@@ -926,6 +928,7 @@ static int vdec_close(struct file *file)
v4l2_m2m_ctx_release(sess->m2m_ctx);
v4l2_m2m_release(sess->m2m_dev);
+ v4l2_ctrl_handler_free(&sess->ctrl_handler);
v4l2_fh_del(&sess->fh, file);
v4l2_fh_exit(&sess->fh);
--
2.50.1
^ permalink raw reply related
* [PATCH v4 0/3] media: meson: Fix memory leak in error path in
From: Anand Moon @ 2026-05-21 7:34 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Hans Verkuil,
Maxime Jourdan,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:STAGING SUBSYSTEM,
moderated list:ARM/Amlogic Meson SoC support, open list
Cc: Sashiko
Following chamges try to fix the memory leak reported by Sashiko
Pre-existing issues:
- [Critical] The `sess->esparser_queue_work` work item is not canceled
before freeing the session context, leading to a potential Use-After-Free
vulnerability.
- [High] The patch attempts to fix a memory leak reported by kmemleak,
but misdiagnoses the root cause and leaves the primary memory leak
(the V4L2 control handler) unresolved.
- [High] The driver does not verify if `kthread_run()` returns an `ERR_PTR`,
leading to a kernel panic when `kthread_stop()` is called.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260520045905.6ACBA1F000E9@smtp.kernel.org/#t
Thanks
-Anand
Anand Moon (3):
media: meson: vdec: Fix memory leak in error path of vdec_open
media: meson: vdec: Add error handling for recycle thread creation
media: meson: vdec: Cancel esparser work in error and stop paths
drivers/staging/media/meson/vdec/vdec.c | 27 +++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
base-commit: 8bc67e4db64aa72732c474b44ea8622062c903f0
--
2.50.1
^ permalink raw reply
* [RFC PATCH 2/2] arm64: mm: add SMCCC-backed cache invalidate provider
From: Srirangan Madhavan @ 2026-05-21 7:30 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla
Cc: conor, jic23, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams,
Srirangan Madhavan
In-Reply-To: <20260521073047.320614-1-smadhavan@nvidia.com>
Add an arm64 cache maintenance backend that discovers SMCCC cache
clean+invalidate support, queries attributes, handles transient BUSY and
RATE_LIMITED responses with bounded retries, and registers with the generic
cache coherency framework.
Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
---
MAINTAINERS | 1 +
arch/arm64/mm/Makefile | 1 +
arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++++++
3 files changed, 182 insertions(+)
create mode 100644 arch/arm64/mm/cache_maint.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 2fb1c75afd16..33c35f8e6e40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25383,6 +25383,7 @@ M: Jonathan Cameron <jic23@kernel.org>
S: Maintained
T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
F: Documentation/devicetree/bindings/cache/
+F: arch/arm64/mm/cache_maint.c
F: drivers/cache
F: include/linux/cache_coherency.h
F: lib/cache_maint.c
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index c26489cf96cd..b247dc5dfd45 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_TRANS_TABLE) += trans_pgd-asm.o
obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
obj-$(CONFIG_ARM64_MTE) += mteswap.o
obj-$(CONFIG_ARM64_GCS) += gcs.o
+obj-$(CONFIG_ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION) += cache_maint.o
KASAN_SANITIZE_physaddr.o += n
obj-$(CONFIG_KASAN) += kasan_init.o
diff --git a/arch/arm64/mm/cache_maint.c b/arch/arm64/mm/cache_maint.c
new file mode 100644
index 000000000000..ea7dd30d5dfa
--- /dev/null
+++ b/arch/arm64/mm/cache_maint.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 NVIDIA Corporation
+ *
+ * Arm64 cache maintenance provider using SMCCC cache clean+invalidate calls.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/cache_coherency.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mutex.h>
+#include <linux/nmi.h>
+
+#define SMCCC_CACHE_MAX_RETRIES 5
+#define SMCCC_CACHE_MAX_DELAY_US 20000
+
+/* DEN0028 v1.7: bit[0] == 1 means implementation flushes all caches globally */
+#define SMCCC_CACHE_ATTR_GLOBAL_OP BIT(0)
+
+struct arm64_smccc_cache {
+ /* Must be first member */
+ struct cache_coherency_ops_inst cci;
+ struct mutex lock; /* Serializes SMCCC cache maintenance calls. */
+ u32 latency_us;
+ u32 rate_limit;
+ bool global_op;
+ u64 global_flush_gen;
+};
+
+static struct arm64_smccc_cache *arm64_smccc_cache;
+
+static int smccc_cache_status_to_errno(s32 status)
+{
+ switch (status) {
+ case SMCCC_RET_SUCCESS:
+ return 0;
+ case SMCCC_RET_NOT_SUPPORTED:
+ case SMCCC_RET_NOT_REQUIRED:
+ return -EOPNOTSUPP;
+ case SMCCC_RET_INVALID_PARAMETER:
+ return -EINVAL;
+ case SMCCC_RET_RATE_LIMITED:
+ return -EAGAIN;
+ case SMCCC_RET_BUSY:
+ return -EBUSY;
+ default:
+ return -EIO;
+ }
+}
+
+static int smccc_cache_delay_us(const struct arm64_smccc_cache *cache)
+{
+ u64 delay_us = 0;
+
+ if (cache->rate_limit)
+ delay_us = DIV_ROUND_UP_ULL(USEC_PER_SEC, cache->rate_limit);
+
+ if (cache->latency_us)
+ delay_us = max_t(u64, delay_us, cache->latency_us);
+
+ if (!delay_us)
+ delay_us = 1000;
+
+ return min_t(u64, delay_us, SMCCC_CACHE_MAX_DELAY_US);
+}
+
+static int arm64_smccc_cache_wbinv(struct cache_coherency_ops_inst *cci,
+ struct cc_inval_params *invp)
+{
+ struct arm64_smccc_cache *cache =
+ container_of(cci, struct arm64_smccc_cache, cci);
+ struct arm_smccc_res res = {};
+ int delay_us = smccc_cache_delay_us(cache);
+ u64 gen = 0;
+ s32 status;
+ int ret;
+ int i;
+
+ if (!invp->size)
+ return -EINVAL;
+
+ if (cache->global_op)
+ gen = READ_ONCE(cache->global_flush_gen);
+
+ guard(mutex)(&cache->lock);
+
+ /*
+ * If firmware reports a global operation type, a successful operation
+ * covers every request that was already waiting behind it. Skip if the
+ * generation advanced while this request was waiting to enter the
+ * serialized firmware call path.
+ */
+ if (cache->global_op && gen != READ_ONCE(cache->global_flush_gen))
+ return 0;
+
+ for (i = 0; i < SMCCC_CACHE_MAX_RETRIES; i++) {
+ /* Long firmware operations can trigger watchdog checks. */
+ touch_nmi_watchdog();
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION,
+ invp->addr, invp->size, 0UL, &res);
+ status = (s32)res.a0;
+ ret = smccc_cache_status_to_errno(status);
+ if (!ret) {
+ if (cache->global_op) {
+ WRITE_ONCE(cache->global_flush_gen,
+ cache->global_flush_gen + 1);
+ }
+ return 0;
+ }
+
+ if (ret != -EBUSY && ret != -EAGAIN)
+ return ret;
+
+ usleep_range(delay_us, delay_us + 100);
+ }
+
+ return -EBUSY;
+}
+
+static const struct cache_coherency_ops arm64_smccc_cache_ops = {
+ .wbinv = arm64_smccc_cache_wbinv,
+};
+
+static int __init arm64_smccc_cache_init(void)
+{
+ struct arm_smccc_res res = {};
+ s32 status;
+ int ret;
+
+ if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_1)
+ return -ENODEV;
+
+ if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE)
+ return -ENODEV;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION, &res);
+ status = (s32)res.a0;
+ if (status < 0)
+ return -ENODEV;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
+ status = (s32)res.a0;
+ if (status < 0)
+ return -ENODEV;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
+ status = (s32)res.a0;
+ if (status)
+ return -ENODEV;
+
+ arm64_smccc_cache =
+ cache_coherency_ops_instance_alloc(&arm64_smccc_cache_ops,
+ struct arm64_smccc_cache,
+ cci);
+ if (!arm64_smccc_cache)
+ return -ENOMEM;
+
+ mutex_init(&arm64_smccc_cache->lock);
+ arm64_smccc_cache->latency_us = lower_32_bits(res.a2);
+ arm64_smccc_cache->rate_limit = lower_32_bits(res.a3);
+ arm64_smccc_cache->global_op = !!(res.a1 & SMCCC_CACHE_ATTR_GLOBAL_OP);
+
+ ret = cache_coherency_ops_instance_register(&arm64_smccc_cache->cci);
+ if (ret) {
+ cache_coherency_ops_instance_put(&arm64_smccc_cache->cci);
+ arm64_smccc_cache = NULL;
+ return ret;
+ }
+
+ pr_info("SMCCC cache clean+invalidate provider registered\n");
+ return 0;
+}
+arch_initcall(arm64_smccc_cache_init);
--
2.43.0
^ permalink raw reply related
* [RFC PATCH 1/2] arm64: smccc: add cache clean/invalidate IDs and return codes
From: Srirangan Madhavan @ 2026-05-21 7:30 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla
Cc: conor, jic23, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams,
Srirangan Madhavan
In-Reply-To: <20260521073047.320614-1-smadhavan@nvidia.com>
Define SMCCC Arch function IDs for CLEAN_INV_MEMREGION and its ATTRIBUTES
call, and add RATE_LIMITED/BUSY return codes from DEN0028 for callers that
need transient error handling.
Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
---
include/linux/arm-smccc.h | 17 +++++++++++++++--
tools/include/linux/arm-smccc.h | 17 +++++++++++++++--
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 50b47eba7d01..cca9adbcc433 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -105,6 +105,18 @@
ARM_SMCCC_SMC_32, \
0, 0x3fff)
+#define ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x5)
+
+#define ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x6)
+
#define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
ARM_SMCCC_SMC_32, \
@@ -294,13 +306,14 @@
0x53)
/*
- * Return codes defined in ARM DEN 0070A
- * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028 C
+ * Return codes defined by Arm SMCCC (DEN0028).
*/
#define SMCCC_RET_SUCCESS 0
#define SMCCC_RET_NOT_SUPPORTED -1
#define SMCCC_RET_NOT_REQUIRED -2
#define SMCCC_RET_INVALID_PARAMETER -3
+#define SMCCC_RET_RATE_LIMITED -4
+#define SMCCC_RET_BUSY -5
#ifndef __ASSEMBLY__
diff --git a/tools/include/linux/arm-smccc.h b/tools/include/linux/arm-smccc.h
index 63ce9bebccd3..65fd4630e739 100644
--- a/tools/include/linux/arm-smccc.h
+++ b/tools/include/linux/arm-smccc.h
@@ -96,6 +96,18 @@
ARM_SMCCC_SMC_32, \
0, 0x3fff)
+#define ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x5)
+
+#define ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x6)
+
#define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
ARM_SMCCC_SMC_32, \
@@ -182,12 +194,13 @@
0x53)
/*
- * Return codes defined in ARM DEN 0070A
- * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028 C
+ * Return codes defined by Arm SMCCC (DEN0028).
*/
#define SMCCC_RET_SUCCESS 0
#define SMCCC_RET_NOT_SUPPORTED -1
#define SMCCC_RET_NOT_REQUIRED -2
#define SMCCC_RET_INVALID_PARAMETER -3
+#define SMCCC_RET_RATE_LIMITED -4
+#define SMCCC_RET_BUSY -5
#endif /*__LINUX_ARM_SMCCC_H*/
--
2.43.0
^ permalink raw reply related
* [RFC PATCH 0/2] arm64: add SMCCC cache invalidation backend for memregion users
From: Srirangan Madhavan @ 2026-05-21 7:30 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla
Cc: conor, jic23, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams,
Srirangan Madhavan
This series adds an arm64 backend for memregion cache invalidation users
based on the Arm SMCCC cache clean+invalidate interface.
Per DEN0028, this interface targets systems where a Normal Cacheable
memory region can be modified in ways that are not handled by usual PE
coherency mechanisms, and where VA-based CMOs may be too slow or
insufficient for large ranges and/or system-cache implementations.
Representative use cases include device-backed memory state transitions
where stale CPU/system cache lines must be invalidated reliably (for
example secure erase, reset/offline flows, and dynamic memory
reconfiguration).
Patch 1 introduces the Arm SMCCC cache clean/invalidate function IDs and
transient return codes needed by callers [1].
Patch 2 adds an arm64 cache maintenance provider that:
- discovers SMCCC support and attributes at init time
- registers with the generic cache coherency framework used by
cpu_cache_invalidate_memregion()
- handles transient BUSY/RATE_LIMITED responses with bounded retries
- coalesces waiters when firmware reports a global operation type
This patch set does not add a software fallback path; when firmware does
not implement the SMCCC cache maintenance interface, the provider is not
registered and existing behavior is preserved.
Reference:
[1] https://developer.arm.com/documentation/den0028/latest
Srirangan Madhavan (2):
arm64: smccc: add cache clean/invalidate IDs and return codes
arm64: mm: add SMCCC-backed cache invalidate provider
MAINTAINERS | 1 +
arch/arm64/mm/Makefile | 1 +
arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++
include/linux/arm-smccc.h | 17 ++-
tools/include/linux/arm-smccc.h | 17 ++-
5 files changed, 212 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/mm/cache_maint.c
base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
--
2.43.0
^ permalink raw reply
* [PATCH v7 0/2] dmaengine: arm-dma350: handle shared channel IRQ wiring on sky1
From: Jun Guo @ 2026-05-21 7:29 UTC (permalink / raw)
To: peter.chen, fugang.duan, robh, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li
Cc: dmaengine, devicetree, linux-kernel, cix-kernel-upstream,
linux-arm-kernel, Jun Guo
This series updates DMA-350 support for the SKY1 integration where all
DMA
channel interrupt outputs are wired to the same GIC SPI.
Patch 1 enables DMANSECCTRL.INTREN_ANYCHINTR in the driver so
per-channel
interrupt status is propagated even when channels share one parent IRQ
line.
Patch 2 adds the SKY1 DMA-350 DT node and describes the channel
interrupt
sources using 8 channel entries, while all entries map to the same SPI.
Tested on CIX SKY1 with dmatest:
% echo 2000 > /sys/module/dmatest/parameters/timeout
% echo 1 > /sys/module/dmatest/parameters/iterations
% echo "" > /sys/module/dmatest/parameters/channel
% echo 1 > /sys/module/dmatest/parameters/run
Changes in v7:
- Modify the commit log format for the driver patch.
Changes in v6:
- Drop the dt-binding update and keep the existing 8-channel interrupt
schema.
- Simplify driver change to a minimal fix:
enable DMANSECCTRL.INTREN_ANYCHINTR.
- Update SKY1 DT node to describe 8 channel interrupt entries mapped
to one SPI.
Changes in v5:
- Fix the formatting issue in the AI tag.
- Remove the unnecessary "cix,sky1-dma-350".
Changes in v4:
- Reword binding text to align with kernel style.
- Revise the AI attribution to the standard format.
- Remove redundant links from the commit log.
Changes in v3:
- Rework binding compatible description to match generic-first model.
- Keep interrupts schema support for both 1-IRQ and 8-IRQ topologies.
- Drop SoC match-data dependency for IRQ mode selection.
- Detect IRQ topology via platform_irq_count() in probe path.
- Refactor IRQ handling into a shared channel handler.
- Enable DMANSECCTRL.INTREN_ANYCHINTR only in combined IRQ mode.
Changes in v2:
- Update to kernel standards, enhance patch description, and refactor
driver to use match data for hardware differentiation instead of
compatible strings.
Jun Guo (2):
dmaengine: arm-dma350: enable ANYCH interrupt for shared IRQ wiring
arm64: dts: cix: add sky1 DMA-350 node with channel IRQ entries
arch/arm64/boot/dts/cix/sky1.dtsi | 14 ++++++++++++++
drivers/dma/arm-dma350.c | 9 +++++++++
2 files changed, 23 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH v7 1/2] dmaengine: arm-dma350: enable ANYCH interrupt for shared IRQ wiring
From: Jun Guo @ 2026-05-21 7:29 UTC (permalink / raw)
To: peter.chen, fugang.duan, robh, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li
Cc: dmaengine, devicetree, linux-kernel, cix-kernel-upstream,
linux-arm-kernel, Jun Guo
In-Reply-To: <20260521072924.3000282-1-jun.guo@cixtech.com>
Enable DMANSECCTRL.INTREN_ANYCHINTR during probe so channel
interrupts are propagated when integrators wire DMA-350 channels
onto a shared IRQ line.
Signed-off-by: Jun Guo <jun.guo@cixtech.com>
---
drivers/dma/arm-dma350.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/dma/arm-dma350.c b/drivers/dma/arm-dma350.c
index 84220fa83029..09403aca8bb0 100644
--- a/drivers/dma/arm-dma350.c
+++ b/drivers/dma/arm-dma350.c
@@ -13,6 +13,11 @@
#include "dmaengine.h"
#include "virt-dma.h"
+#define DMANSECCTRL 0x200
+
+#define NSEC_CTRL 0x0c
+#define INTREN_ANYCHINTR_EN BIT(0)
+
#define DMAINFO 0x0f00
#define DMA_BUILDCFG0 0xb0
@@ -582,6 +587,10 @@ static int d350_probe(struct platform_device *pdev)
dmac->dma.device_issue_pending = d350_issue_pending;
INIT_LIST_HEAD(&dmac->dma.channels);
+ reg = readl_relaxed(base + DMANSECCTRL + NSEC_CTRL);
+ writel_relaxed(reg | INTREN_ANYCHINTR_EN,
+ base + DMANSECCTRL + NSEC_CTRL);
+
/* Would be nice to have per-channel caps for this... */
memset = true;
for (int i = 0; i < nchan; i++) {
--
2.34.1
^ permalink raw reply related
* [PATCH v7 2/2] arm64: dts: cix: add sky1 DMA-350 node with channel IRQ entries
From: Jun Guo @ 2026-05-21 7:29 UTC (permalink / raw)
To: peter.chen, fugang.duan, robh, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li
Cc: dmaengine, devicetree, linux-kernel, cix-kernel-upstream,
linux-arm-kernel, Jun Guo
In-Reply-To: <20260521072924.3000282-1-jun.guo@cixtech.com>
Describe the DMA-350 channel interrupt sources in DT using 8
interrupt entries, while all entries map to the same GIC SPI
as wired on this platform.
Signed-off-by: Jun Guo <jun.guo@cixtech.com>
---
arch/arm64/boot/dts/cix/sky1.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/cix/sky1.dtsi b/arch/arm64/boot/dts/cix/sky1.dtsi
index bb5cfb1f2113..823adeef51f1 100644
--- a/arch/arm64/boot/dts/cix/sky1.dtsi
+++ b/arch/arm64/boot/dts/cix/sky1.dtsi
@@ -444,6 +444,20 @@ iomuxc: pinctrl@4170000 {
reg = <0x0 0x04170000 0x0 0x1000>;
};
+ fch_dmac: dma-controller@4190000 {
+ compatible = "arm,dma-350";
+ reg = <0x0 0x4190000 0x0 0x10000>;
+ interrupts = <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>;
+ #dma-cells = <1>;
+ };
+
mbox_ap2se: mailbox@5060000 {
compatible = "cix,sky1-mbox";
reg = <0x0 0x05060000 0x0 0x10000>;
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox