* [PATCH] firmware: raspberrypi: Change dependency to ARCH_BCM2835 and COMPILE_TEST
From: Chen-Yu Tsai @ 2026-04-08 8:11 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list
Cc: Chen-Yu Tsai, linux-rpi-kernel, linux-arm-kernel, linux-kernel
The Raspberry Pi firmware driver has no compile dependencies on the
BCM2835 mailbox driver. It's just a indirect runtime dependency: the
driver only works on a Raspberry Pi.
Change the dependency from BCM2835_MBOX to ARCH_BCM2835. Also allow
compile tests. This allows drivers that have build time dependencies
on this firmware driver to be compile tested as well.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/firmware/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index bbd2155d8483..f99d27c1f6a4 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -114,7 +114,7 @@ config ISCSI_IBFT
config RASPBERRYPI_FIRMWARE
tristate "Raspberry Pi Firmware Driver"
- depends on BCM2835_MBOX
+ depends on ARCH_BCM2835 || COMPILE_TEST
help
This option enables support for communicating with the firmware on the
Raspberry Pi.
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* Re: [PATCH] crypto: tstmgr - guard xxhash tests
From: Herbert Xu @ 2026-04-08 8:08 UTC (permalink / raw)
To: Hamza Mahfooz
Cc: linux-crypto, David S. Miller, Maxime Coquelin, Alexandre Torgue,
linux-stm32, linux-arm-kernel, linux-kernel, Jeff Barnes,
Paul Monson
In-Reply-To: <20260407192859.270745-1-hamzamahfooz@linux.microsoft.com>
On Tue, Apr 07, 2026 at 12:28:59PM -0700, Hamza Mahfooz wrote:
> If the kernel isn't built with CONFIG_CRYPTO_XXHASH and booted with FIPS
> mode enabled it will currently panic. So, only benchmark xxhash64 if
> CRYPTO_XXHASH is enabled.
>
> Cc: Jeff Barnes <jeffbarnes@linux.microsoft.com>
> Cc: Paul Monson <paul.monson@capgemini.com>
> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
> ---
> crypto/testmgr.c | 2 ++
> 1 file changed, 2 insertions(+)
Please show me the panic. Normally it's not an issue if an algorithm
is not present while the test vectors are.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-08 8:08 UTC (permalink / raw)
To: Frank Li
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <adYKtjPvIgoK2oou@lizhi-Precision-Tower-5810>
On Wed, Apr 08, 2026 at 03:58:59AM -0400, Frank Li wrote:
> On Wed, Apr 08, 2026 at 02:02:54PM +0800, Liu Ying wrote:
>> Hi Frank,
>>
>> On Tue, Apr 07, 2026 at 05:55:29AM -0400, Frank Li wrote:
>>> On Tue, Apr 07, 2026 at 05:15:31PM +0800, Liu Ying wrote:
>>>> Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
>>>>
>>>> The panel connects with the QSB board through an adapter board[1]
>>>> designed by NXP.
>>>>
>>>> Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>> ---
>>>> arch/arm64/boot/dts/freescale/Makefile | 2 +
>>>> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 +++++++++++++++++++++
>>>> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-------------------
>>>
>>> Can you add some description about raname in commit message?
>>
>> I'll add some description about the file copy in commit message.
>>
>>> Use -C option to create patch.
>>
>> Will do.
>>
>>>
>>> ...
>>>> diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
>>>> new file mode 100644
>>>> index 000000000000..c233797ec28c
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
>>>> @@ -0,0 +1,14 @@
>>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>>> +/*
>>>> + * Copyright 2026 NXP
>>>> + */
>>>> +
>>>> +#include <dt-bindings/gpio/gpio.h>
>>>> +#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
>>>> +
>>>> +&{/} {
>>>> + panel {
>>>> + compatible = "tianma,tm050rdh03";
>>>> + enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
>>>> + };
>>>> +};
>>>
>>> Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
>>>
>>> to imx93-9x9-qsb.dtb, so needn't create dtsi.
>>
>> I'm sorry, I don't get your question here.
>> Anyway, the DT overlays are needed, because the 40-pin EXP/PRI interface on
>> the i.MX93 9x9 QSB board can not only connect to a DPI panel adapter board
>> but also to an audio hat[2], and maybe more. The newly introduced .dtsi
>> file just aims to avoid duplicated code.
>
> My means apply two overlay files to dtb
>
> imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo imx93-9x9-qsb-tianma-tm050rdh03.dtbo
>
> In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
> &{/} {
> panel {
> compatible = "tianma,tm050rdh03";
> enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
> };
> };
If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
DPI panel, then it won't work unless the user also apply
imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
>
> Frank
>>
>> [2] https://www.nxp.com/design/design-center/development-boards-and-designs/mx93aud-hat-audio-board:MX93AUD-HAT
>>
>>>
>>> Frank
>>>>
>>>> ---
>>>> base-commit: 816f193dd0d95246f208590924dd962b192def78
>>>> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
>>>>
>>>> Best regards,
>>>> --
>>>> Liu Ying <victor.liu@nxp.com>
>>>>
>>
>> --
>> Regards,
>> Liu Ying
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v4 1/2] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
From: Sakari Ailus @ 2026-04-08 8:05 UTC (permalink / raw)
To: michael.riesch
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Collabora Kernel Team, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260305-rk3588-csi2rx-v4-1-81c6bcfefa63@collabora.com>
Hi Michael,
On Fri, Mar 27, 2026 at 12:10:00AM +0100, Michael Riesch via B4 Relay wrote:
> From: Michael Riesch <michael.riesch@collabora.com>
>
> The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
> the RK3568.
> Introduce a list of compatible variants and add the RK3588 variant to
> it.
Please use your editor to wrap the commit messages in the future as needed.
It became:
The RK3588 MIPI CSI-2 receivers are compatible to the ones found in the
RK3568. Introduce a list of compatible variants and add the RK3588 variant
to it.
--
Sakari Ailus
^ permalink raw reply
* [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-04-08 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gregor Herburger
In-Reply-To: <20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de>
Raspberry Pis have OTP registers which can be accessed through the
videocore firmware. Add a nvmem driver to support these OTP registers.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/nvmem/Kconfig | 12 +++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 2 +
4 files changed, 174 insertions(+)
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..892d05fe67be 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
This driver can also be built as a module. If so, the module
will be called nvmem_qoriq_efuse.
+config NVMEM_RASPBERRYPI_OTP
+ tristate "Raspberry Pi OTP support"
+ # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+ # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+ depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
+ help
+ This driver provides access to the Raspberry Pi OTP memory via the
+ nvmem subsystem. The driver supports the customer otp as well as the
+ device specific private key OTP.
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-otp.
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d4..8ca2095e068f 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
nvmem_zynqmp_nvmem-y := zynqmp_nvmem.o
obj-$(CONFIG_NVMEM_QORIQ_EFUSE) += nvmem-qoriq-efuse.o
nvmem-qoriq-efuse-y := qoriq-efuse.o
+obj-$(CONFIG_NVMEM_RASPBERRYPI_OTP) += raspberrypi-otp.o
diff --git a/drivers/nvmem/raspberrypi-otp.c b/drivers/nvmem/raspberrypi-otp.c
new file mode 100644
index 000000000000..13ee3784b137
--- /dev/null
+++ b/drivers/nvmem/raspberrypi-otp.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+struct rpi_otp_priv {
+ struct rpi_firmware *fw;
+ struct device *dev;
+ u32 read_tag;
+ u32 write_tag;
+};
+
+struct rpi_otp_driver_data {
+ const char *name;
+ u32 read_tag;
+ u32 write_tag;
+};
+
+struct rpi_otp_header {
+ u32 start;
+ u32 count;
+ u32 data[];
+};
+
+static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ int ret;
+
+ fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = offset / 4;
+ fwbuf->count = bytes / 4;
+
+ ret = rpi_firmware_property(priv->fw, priv->read_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+ if (ret)
+ goto out;
+
+ memcpy(buf, fwbuf->data, bytes);
+
+out:
+ kfree(fwbuf);
+ return ret;
+}
+
+static int rpi_otp_write(void *context, unsigned int offset, void *val, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ int ret;
+
+ fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = offset / 4;
+ fwbuf->count = bytes / 4;
+ memcpy(fwbuf->data, val, bytes);
+
+ ret = rpi_firmware_property(priv->fw, priv->write_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+
+ kfree(fwbuf);
+ return ret;
+}
+
+static const struct rpi_otp_driver_data rpi_otp_customer = {
+ .name = "rpi-otp-customer",
+ .read_tag = RPI_FIRMWARE_GET_CUSTOMER_OTP,
+ .write_tag = RPI_FIRMWARE_SET_CUSTOMER_OTP,
+};
+
+static const struct rpi_otp_driver_data rpi_otp_private = {
+ .name = "rpi-otp-private",
+ .read_tag = RPI_FIRMWARE_GET_PRIVATE_OTP,
+ .write_tag = RPI_FIRMWARE_SET_PRIVATE_OTP,
+};
+
+static int rpi_otp_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct nvmem_device *nvmem;
+ struct rpi_otp_priv *priv;
+ struct device_node *np;
+ const struct rpi_otp_driver_data *data;
+ struct nvmem_config config = {
+ .read_only = false,
+ .word_size = 4,
+ .stride = 4,
+ .reg_read = rpi_otp_read,
+ .reg_write = rpi_otp_write,
+ .size = 32,
+ };
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ data = device_get_match_data(dev);
+ if (!data)
+ return -ENODEV;
+
+ np = of_get_parent(dev->of_node);
+ if (!np) {
+ dev_err(dev, "Missing firmware node\n");
+ return -ENOENT;
+ }
+
+ priv->fw = devm_rpi_firmware_get(&pdev->dev, np);
+ of_node_put(np);
+ if (!priv->fw)
+ return -EPROBE_DEFER;
+
+ priv->dev = dev;
+ priv->read_tag = data->read_tag;
+ priv->write_tag = data->write_tag;
+ config.dev = dev;
+ config.priv = priv;
+ config.name = data->name;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ if (IS_ERR(nvmem))
+ return dev_err_probe(dev, PTR_ERR(nvmem), "error registering nvmem config\n");
+
+ return 0;
+}
+
+static const struct of_device_id rpi_otp_of_match[] = {
+ {
+ .compatible = "raspberrypi,firmware-otp-customer",
+ .data = &rpi_otp_customer
+ },
+ {
+ .compatible = "raspberrypi,firmware-otp-private",
+ .data = &rpi_otp_private,
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rpi_otp_of_match);
+
+static struct platform_driver raspberry_otp_driver = {
+ .probe = rpi_otp_probe,
+ .driver = {
+ .name = "rpi-otp",
+ .of_match_table = rpi_otp_of_match,
+ },
+};
+module_platform_driver(raspberry_otp_driver);
+
+MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
+MODULE_DESCRIPTION("Raspberry OTP driver");
+MODULE_LICENSE("GPL");
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe554..6e94ccf34f47 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -92,6 +92,8 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
+ RPI_FIRMWARE_GET_PRIVATE_OTP = 0x00030081,
+ RPI_FIRMWARE_SET_PRIVATE_OTP = 0x00038081,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
--
2.47.3
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Gregor Herburger @ 2026-04-08 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gregor Herburger
In-Reply-To: <20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de>
The Raspberry Pi 5 has two OTP registers (private and customer), add these
to the devicetree.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
index b7a6bc34ae1a..676081198213 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
@@ -60,6 +60,14 @@ reset: reset {
#reset-cells = <1>;
};
+ otp_customer: otp-customer {
+ compatible = "raspberrypi,firmware-otp-customer";
+ };
+
+ otp_private: otp-private {
+ compatible = "raspberrypi,firmware-otp-private";
+ };
+
power: power {
compatible = "raspberrypi,bcm2835-power";
firmware = <&firmware>;
--
2.47.3
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
From: Gregor Herburger @ 2026-04-08 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gregor Herburger
In-Reply-To: <20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de>
The firmware running on the Raspberry Pi VideoCore can be used to access
OTP registers. There are two OTP regions (private and customer). Add a
binding for these.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 983ea80eaec9..975c8927d75b 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -137,6 +137,20 @@ required:
- compatible
- mboxes
+patternProperties:
+ "^otp-(customer|private)$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - raspberrypi,firmware-otp-customer
+ - raspberrypi,firmware-otp-private
+
+ required:
+ - compatible
+
additionalProperties: false
examples:
@@ -156,6 +170,10 @@ examples:
#gpio-cells = <2>;
};
+ otp: otp-private {
+ compatible = "raspberrypi,firmware-otp-private";
+ };
+
reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
--
2.47.3
^ permalink raw reply related
* [PATCH 0/3] nvmem: Add Raspberry Pi OTP nvmem driver
From: Gregor Herburger @ 2026-04-08 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gregor Herburger
Hi,
This series adds support for the Raspberry Pis OTP registers. The
Raspberry Pi has one or more OTP regions. These registers are accessible
through the firmware. Add a driver for it and add the corresponding
devicetree scheme.
I also added the devicetree nodes for the Raspberry Pi as I tested the
series on it.
---
Gregor Herburger (3):
dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
nvmem: Add the Raspberry Pi OTP driver
arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 +++
.../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 8 ++
drivers/nvmem/Kconfig | 12 ++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 2 +
6 files changed, 200 insertions(+)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-rpi-otp-driver-75fce1dcff7d
Best regards,
--
Gregor Herburger <gregor.herburger@linutronix.de>
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Frank Li @ 2026-04-08 7:58 UTC (permalink / raw)
To: Liu Ying
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <a31e926e-9e7e-4ba4-aafd-0f76f53fa176@nxp.com>
On Wed, Apr 08, 2026 at 02:02:54PM +0800, Liu Ying wrote:
> Hi Frank,
>
> On Tue, Apr 07, 2026 at 05:55:29AM -0400, Frank Li wrote:
> > On Tue, Apr 07, 2026 at 05:15:31PM +0800, Liu Ying wrote:
> >> Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
> >>
> >> The panel connects with the QSB board through an adapter board[1]
> >> designed by NXP.
> >>
> >> Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
> >> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >> ---
> >> arch/arm64/boot/dts/freescale/Makefile | 2 +
> >> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 +++++++++++++++++++++
> >> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-------------------
> >
> > Can you add some description about raname in commit message?
>
> I'll add some description about the file copy in commit message.
>
> > Use -C option to create patch.
>
> Will do.
>
> >
> > ...
> >> diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
> >> new file mode 100644
> >> index 000000000000..c233797ec28c
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
> >> @@ -0,0 +1,14 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >> +/*
> >> + * Copyright 2026 NXP
> >> + */
> >> +
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
> >> +
> >> +&{/} {
> >> + panel {
> >> + compatible = "tianma,tm050rdh03";
> >> + enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
> >> + };
> >> +};
> >
> > Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
> >
> > to imx93-9x9-qsb.dtb, so needn't create dtsi.
>
> I'm sorry, I don't get your question here.
> Anyway, the DT overlays are needed, because the 40-pin EXP/PRI interface on
> the i.MX93 9x9 QSB board can not only connect to a DPI panel adapter board
> but also to an audio hat[2], and maybe more. The newly introduced .dtsi
> file just aims to avoid duplicated code.
My means apply two overlay files to dtb
imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo imx93-9x9-qsb-tianma-tm050rdh03.dtbo
In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
&{/} {
panel {
compatible = "tianma,tm050rdh03";
enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
};
};
Frank
>
> [2] https://www.nxp.com/design/design-center/development-boards-and-designs/mx93aud-hat-audio-board:MX93AUD-HAT
>
> >
> > Frank
> >>
> >> ---
> >> base-commit: 816f193dd0d95246f208590924dd962b192def78
> >> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
> >>
> >> Best regards,
> >> --
> >> Liu Ying <victor.liu@nxp.com>
> >>
>
> --
> Regards,
> Liu Ying
^ permalink raw reply
* Re: [PATCH 2/3] KVM: arm64: vgic: Allow userspace to set IIDR revision 1
From: Marc Zyngier @ 2026-04-08 7:54 UTC (permalink / raw)
To: David Woodhouse
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Paolo Bonzini, Shuah Khan,
David Woodhouse, Raghavendra Rao Ananta, Eric Auger, Kees Cook,
Arnd Bergmann, Nathan Chancellor, linux-arm-kernel, kvmarm,
linux-kernel, kvm, linux-kselftest
In-Reply-To: <20260407210949.2076251-3-dwmw2@infradead.org>
On Tue, 07 Apr 2026 21:27:03 +0100,
David Woodhouse <dwmw2@infradead.org> wrote:
>
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> Allow userspace to select GICD_IIDR revision 1, which restores the
> original pre-d53c2c29ae0d ("KVM: arm/arm64: vgic: Allow configuration
> of interrupt groups") behaviour where interrupt groups are not
> guest-configurable.
I'm a bit surprised by this.
Either your guest knows that the group registers are not writable and
already deals with the buggy behaviour by not configuring the groups
(or configuring them in a way that matches what the implementation
does). Or it configures them differently and totally fails to handle
the interrupts as they are delivered using the wrong exception type,
if at all.
I'd expect that your guests fall in the former category and not the
latter, as we'd be discussing a very different problem. And my vague
recollection of this issue is that we had established that as long as
the reset values were unchanged, there was no harm in letting things
rip.
So what is this *really* fixing?
>
> When revision 1 is selected:
> - GICv2: IGROUPR reads as zero (group 0), writes are ignored
> - GICv3: IGROUPR reads as all-ones (group 1), writes are ignored
> - v2_groups_user_writable is not set
>
> This is implemented by checking the implementation revision in
> vgic_mmio_read_group() and vgic_mmio_write_group() and returning
> the fixed values when the revision is below 2.
>
> Fixes: d53c2c29ae0d ("KVM: arm/arm64: vgic: Allow configuration of interrupt groups")
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> arch/arm64/kvm/vgic/vgic-mmio-v2.c | 5 +++++
> arch/arm64/kvm/vgic/vgic-mmio-v3.c | 4 ++++
> arch/arm64/kvm/vgic/vgic-mmio.c | 15 +++++++++++++++
> include/kvm/arm_vgic.h | 1 +
> 4 files changed, 25 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v2.c b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
> index 0643e333db35..14aa49f86f60 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio-v2.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
> @@ -20,6 +20,8 @@
> * Revision 1: Report GICv2 interrupts as group 0 instead of group 1
> * Revision 2: Interrupt groups are guest-configurable and signaled using
> * their configured groups.
> + * Revision 3: GICv2 behaviour is unchanged from revision 2.
> + * (GICv3 gains GICR_CTLR.{IR,CES}; see vgic-mmio-v3.c)
nit: I don't think we need cross-version documentation, so just drop
the second line.
> */
>
> static unsigned long vgic_mmio_read_v2_misc(struct kvm_vcpu *vcpu,
> @@ -93,6 +95,9 @@ static int vgic_mmio_uaccess_write_v2_misc(struct kvm_vcpu *vcpu,
> */
> reg = FIELD_GET(GICD_IIDR_REVISION_MASK, val);
> switch (reg) {
> + case KVM_VGIC_IMP_REV_1:
> + dist->implementation_rev = reg;
> + return 0;
> case KVM_VGIC_IMP_REV_2:
> case KVM_VGIC_IMP_REV_3:
> vcpu->kvm->arch.vgic.v2_groups_user_writable = true;
nit: move the v1 handling down with a fallthrough in v2/v3 so that we
don't duplicate the basic handling:
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v2.c b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
index 406845b3117cf..34f8b2b615fc5 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v2.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
@@ -96,6 +96,8 @@ static int vgic_mmio_uaccess_write_v2_misc(struct kvm_vcpu *vcpu,
case KVM_VGIC_IMP_REV_2:
case KVM_VGIC_IMP_REV_3:
vcpu->kvm->arch.vgic.v2_groups_user_writable = true;
+ fallthrough;
+ case KVM_VGIC_IMP_REV_1:
dist->implementation_rev = reg;
return 0;
default:
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> index 5913a20d8301..0130db71cfc9 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> @@ -74,8 +74,11 @@ bool vgic_supports_direct_sgis(struct kvm *kvm)
> /*
> * The Revision field in the IIDR have the following meanings:
> *
> + * Revision 1: Interrupt groups are not guest-configurable.
> + * IGROUPR reads as all-ones (group 1), writes ignored.
> * Revision 2: Interrupt groups are guest-configurable and signaled using
> * their configured groups.
> + * Revision 3: GICR_CTLR.{IR,CES} are advertised.
> */
>
> static unsigned long vgic_mmio_read_v3_misc(struct kvm_vcpu *vcpu,
> @@ -196,6 +199,7 @@ static int vgic_mmio_uaccess_write_v3_misc(struct kvm_vcpu *vcpu,
>
> reg = FIELD_GET(GICD_IIDR_REVISION_MASK, val);
> switch (reg) {
> + case KVM_VGIC_IMP_REV_1:
> case KVM_VGIC_IMP_REV_2:
> case KVM_VGIC_IMP_REV_3:
> dist->implementation_rev = reg;
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio.c b/arch/arm64/kvm/vgic/vgic-mmio.c
> index a573b1f0c6cb..9eb95f13b9b6 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio.c
> @@ -48,6 +48,17 @@ unsigned long vgic_mmio_read_group(struct kvm_vcpu *vcpu,
> u32 value = 0;
> int i;
>
> + /*
> + * Revision 1 and below: groups are not guest-configurable.
> + * GICv2 reports all interrupts as group 0 (RAZ).
> + * GICv3 reports all interrupts as group 1 (RAO).
> + */
> + if (vgic_get_implementation_rev(vcpu) < KVM_VGIC_IMP_REV_2) {
> + if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
> + return -1UL;
Hmmm... This can only be a 32bit access, so returning non-zero bits in
the top half is weird. It will be narrowed down before hitting the
guest, but still. Anyway, see below.
> + return 0;
> + }
> +
Why is this needed at all? The group reset values are already the
expected ones for v1, and as long as we prevent writes, the reported
group configuration will be as expected.
> /* Loop over all IRQs affected by this read */
> for (i = 0; i < len * 8; i++) {
> struct vgic_irq *irq = vgic_get_vcpu_irq(vcpu, intid + i);
> @@ -73,6 +84,10 @@ void vgic_mmio_write_group(struct kvm_vcpu *vcpu, gpa_t addr,
> int i;
> unsigned long flags;
>
> + /* Revision 1 and below: groups are not guest-configurable. */
> + if (vgic_get_implementation_rev(vcpu) < KVM_VGIC_IMP_REV_2)
> + return;
> +
> for (i = 0; i < len * 8; i++) {
> struct vgic_irq *irq = vgic_get_vcpu_irq(vcpu, intid + i);
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index f2eafc65bbf4..90fb6cd3c91c 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -248,6 +248,7 @@ struct vgic_dist {
>
> /* Implementation revision as reported in the GICD_IIDR */
> u32 implementation_rev;
> +#define KVM_VGIC_IMP_REV_1 1 /* GICv2 interrupts as group 0 */
> #define KVM_VGIC_IMP_REV_2 2 /* GICv2 restorable groups */
> #define KVM_VGIC_IMP_REV_3 3 /* GICv3 GICR_CTLR.{IW,CES,RWP} */
> #define KVM_VGIC_IMP_REV_LATEST KVM_VGIC_IMP_REV_3
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply related
* Re: [PATCH 2/3] ARM: dts: aspeed: anacapa: add EVT1 devicetree and point wrapper to it
From: Krzysztof Kozlowski @ 2026-04-08 7:52 UTC (permalink / raw)
To: Colin Huang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <20260407-anacapa-devlop-phase-devicetree-v1-2-97b96367cac3@gmail.com>
On Tue, Apr 07, 2026 at 09:54:33PM +0800, Colin Huang wrote:
> This change introduces a development-phase devicetree for the
> Facebook Anacapa BMC EVT1 hardware revision and updates the Anacapa
> wrapper DTS to reference it.
>
> A dedicated EVT1 DTS is added for revision-specific hardware while
> keeping a single, Anacapa entrypoint used by the build and deployment
> flow. The top-level aspeed-bmc-facebook-anacapa.dts
>
> Signed-off-by: Colin Huang <u8813345@gmail.com>
> ---
> .../aspeed/aspeed-bmc-facebook-anacapa-evt1.dts | 1069 ++++++++++++++++++++
> .../dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 1064 +------------------
> 2 files changed, 1070 insertions(+), 1063 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> new file mode 100644
> index 000000000000..a29b7fa1155b
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> @@ -0,0 +1,1069 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +/dts-v1/;
> +#include "aspeed-g6.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +#include <dt-bindings/i2c/i2c.h>
> +
> +/ {
> + model = "Facebook Anacapa BMC";
> + compatible = "facebook,anacapa-bmc-evt1",
> + "facebook,anacapa-bmc",
> + "aspeed,ast2600";
Test your DTS before you send, not after. Your binding clearly said
something else.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 3/3] perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
From: Peng Fan (OSS) @ 2026-04-08 7:51 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-0-d75dac96e828@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The PMCG is described as a child device of the SMMU in Devicetree and
its register space occupies a sub-region of the parent SMMU MMIO window.
That MMIO region is already requested by the arm-smmu-v3 driver during
SMMU probe.
Using devm_platform_get_and_ioremap_resource() or
devm_platform_ioremap_resource() for the PMCG would attempt to request
the same memory region again and fail with -EBUSY.
Switch to explicitly retrieving the PMCG memory resources and mapping
them with devm_ioremap(), avoiding double-requesting already owned SMMU
MMIO while preserving correct register offsets for both page 0 and the
optional relocated counter page.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/perf/arm_smmuv3_pmu.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 621f02a7f43be364e5c260fd97aa375f5e8e3404..1c9585ef2618397b59158aa18c21054ef672dc83 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -847,7 +847,7 @@ static void smmu_pmu_get_iidr(struct smmu_pmu *smmu_pmu)
static int smmu_pmu_probe(struct platform_device *pdev)
{
struct smmu_pmu *smmu_pmu;
- struct resource *res_0;
+ struct resource *res_0, *res_1;
u32 cfgr, reg_size;
u64 ceid_64[2];
int irq, err;
@@ -877,7 +877,16 @@ static int smmu_pmu_probe(struct platform_device *pdev)
.capabilities = PERF_PMU_CAP_NO_EXCLUDE,
};
- smmu_pmu->reg_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res_0);
+ res_0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res_0)
+ return dev_err_probe(dev, -ENOENT, "missing PMCG page 0 MMIO resource\n");
+
+ /*
+ * PMCG registers might be a sub-region of the parent SMMU MMIO window,
+ * which is already requested by the SMMU driver. Do not call
+ * devm_ioremap_resource() here to avoid double-requesting the region.
+ */
+ smmu_pmu->reg_base = devm_ioremap(dev, res_0->start, resource_size(res_0));
if (IS_ERR(smmu_pmu->reg_base))
return PTR_ERR(smmu_pmu->reg_base);
@@ -885,7 +894,11 @@ static int smmu_pmu_probe(struct platform_device *pdev)
/* Determine if page 1 is present */
if (cfgr & SMMU_PMCG_CFGR_RELOC_CTRS) {
- smmu_pmu->reloc_base = devm_platform_ioremap_resource(pdev, 1);
+ res_1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res_1)
+ return dev_err_probe(dev, -ENOENT, "missing PMCG page 1 MMIO resource\n");
+
+ smmu_pmu->reloc_base = devm_ioremap(dev, res_1->start, resource_size(res_1));
if (IS_ERR(smmu_pmu->reloc_base))
return PTR_ERR(smmu_pmu->reloc_base);
} else {
--
2.37.1
^ permalink raw reply related
* [PATCH 2/3] iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
From: Peng Fan (OSS) @ 2026-04-08 7:51 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-0-d75dac96e828@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The Arm SMMU v3 can expose optional child devices such as the PMCG-based
PMU, which are described as child nodes in Devicetree. While the binding
allows these nodes, the driver did not populate them, preventing the
corresponding platform devices from being created.
Call devm_of_platform_populate() after a successful SMMU DT probe to
instantiate any child nodes associated with the SMMU device.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e8d7dbe495f0302191c3c7ec4c6d7564062f6236..0ce1d41c5ba6864ccad8291551f7f5c91c27b3db 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -5363,6 +5363,9 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu"))
tegra_cmdqv_dt_probe(dev->of_node, smmu);
+ if (!ret)
+ return devm_of_platform_populate(dev);
+
return ret;
}
--
2.37.1
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
From: Peng Fan (OSS) @ 2026-04-08 7:51 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-0-d75dac96e828@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The Arm SMMU v3 specification defines an optional PMCG (Performance
Monitor Control Group) block. Per MMU-700 TRM, it has three 64KB pages,
with TCU Performance Monitor Counter Group (PMCG) registers starting at
offset 0x02000 in page 0. So PMCG could be described as a child node of the
SMMU in Devicetree.
Add a patternProperties entry to the arm,smmu-v3 binding to allow child
nodes matching "pmu@<addr>" and reference the existing
arm,smmu-v3-pmcg.yaml schema.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
index 82957334bea24402b583e47eb61b5724c91e4378..1d09c5476e5f1a7c3e5c935b677641ee6cc9897e 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
@@ -50,6 +50,10 @@ properties:
- cmdq-sync # CMD_SYNC complete
- priq # PRI Queue not empty
+ '#address-cells': true
+ '#size-cells': true
+ ranges: true
+
'#iommu-cells':
const: 1
@@ -83,6 +87,12 @@ properties:
register access with page 0 offsets. Set for Cavium ThunderX2 silicon that
doesn't support SMMU page1 register space.
+patternProperties:
+ '^pmu@[0-9a-f]+$':
+ type: object
+ $ref: /schemas/perf/arm,smmu-v3-pmcg.yaml#
+ unevaluatedProperties: false
+
allOf:
- if:
not:
--
2.37.1
^ permalink raw reply related
* [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping
From: Peng Fan (OSS) @ 2026-04-08 7:51 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
This patch series adds proper support for describing and probing the
Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
the SMMU in Devicetree, and updates the relevant drivers accordingly.
The SMMU v3 architecture allows an optional PMCG block, typically
associated with TCUs, to be implemented within the SMMU register
address space. For example, mmu700 PMCG is at the offset 0x2000 of the
TCU page 0.
Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
referencing the existing arm,smmu-v3-pmcg binding.
Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
child nodes described in DT once the SMMU probe succeeds.
Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
PMCG is described as a child node. The PMCG registers occupy a sub-region
of the parent SMMU MMIO window, which is already requested by the SMMU
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
.../devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
drivers/perf/arm_smmuv3_pmu.c | 19 ++++++++++++++++---
3 files changed, 29 insertions(+), 3 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-smmu-perf-754367fe66c8
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH] dmaengine: lpc18xx-dmamux: simplify allocation
From: Frank Li @ 2026-04-08 7:48 UTC (permalink / raw)
To: Rosen Penev
Cc: dmaengine, Vinod Koul, Frank Li, Vladimir Zapolskiy, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/LPC18XX ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260407035132.99037-1-rosenp@gmail.com>
On Mon, Apr 06, 2026 at 08:51:32PM -0700, Rosen Penev wrote:
Subject need descript summary.
dmaengine: lpc18xx-dmamux: use flexible array to simplify allocation
Frank
^ permalink raw reply
* Re: [PATCH] arm64: clear_page[s] using memset
From: Linus Walleij @ 2026-04-08 7:47 UTC (permalink / raw)
To: Catalin Marinas, Ryan Roberts
Cc: Will Deacon, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, linux-arm-kernel, kvmarm
In-Reply-To: <adULAT2xus5z3HdQ@arm.com>
On Tue, Apr 7, 2026 at 3:47 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Apr 07, 2026 at 11:25:55AM +0200, Linus Walleij wrote:
> > Quoting my own commit message hehe:
> >
> > > No performance regressions can be seen, the fastpath
> > > benchmarks differences are in the noise.
> >
> > This was tested on hardware with Ryan Robert's fastpath tool.
>
> BTW, have you tried the perf bench mmap test again with the new
> clear_page? Both with single page and multiple pages scenarios. And
> ideally on more than one platform.
>
> Will pointed out (in a private chat) that current clear_page() uses
> non-temporal stores while memset() doesn't. It may not make any
> difference in practice but it would be good to have some numbers.
Hm interesting point, the perf bench mmap test isn't specifically
in fastpath but since it tends to come up I guess we can add it?
Ryan: is it easy to add this test to fastpath? Or easy for me to do
myself? I looked at the instructions but they were a bit intimidating...
The test is the following:
We boot the kernel with cmdline like this:
"default_hugepagesz=1G hugepagesz=1G hugepages=32" to make sure
we have ample hugepages. This was then tested with the same
cmdline as the original series:
perf bench mem mmap -p 1GB -f demand -s 32GB -l 5
The first run was discarded as the memory hierarchy is cold on
the first run. Then I ran the above command 5 times and averaged
the throughput
The x86 commit cb431accb36e51b64ce34b5cc4d5ed292895fd84
also mentions this test:
perf bench mem memset -k 1GB -f default -s 16GB
I tried it on QEMU, no real benefits with either the previous or this
patch, and no regressions either. (x86 passes -f x86-64-stosq
which are some optimized memset instructions)
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH v4 net-next 07/14] net: enetc: add support for "Add" and "Delete" operations to IPFT
From: Wei Fang @ 2026-04-08 7:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011734.1795551-1-kuba@kernel.org>
> > +int ntmp_ipft_add_entry(struct ntmp_user *user,
> > + struct ipft_entry_data *entry)
> > +{
> [ ... ]
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd(&req->crd, user->tbl.ipft_ver, NTMP_QA_ENTRY_ID,
> > + NTMP_GEN_UA_CFGEU | NTMP_GEN_UA_STSEU);
> > + req->ak.keye = entry->keye;
> > + req->cfge = entry->cfge;
>
> The request sets NTMP_GEN_UA_STSEU to indicate statistics data is present,
> but struct ipft_req_ua does not appear to contain a match_count or STSE data
> field before cfge.
>
> Since the hardware expects STSE data before CFGE data (as seen in
> struct ipft_resp_query), will this cause the hardware to misinterpret the
> first 8 bytes of cfge as the match_count, and then read the actual filter
> configuration from out-of-bounds or uninitialized memory?
Based on NETC manual, the STSE_DATA is present only for the commands
which perform a query. So for the 'add' command, we do not need to
provide the STSE_DATA buffer. And STSE_DATA is the statistics of the
entry, which is stored in the internal buffer of IPF table. Performing
NTMP_GEN_UA_STSEU is to reset the statistic counter when adding
an entry.
[...]
> > +struct ipft_pld_byte {
> > + u8 data;
> > + u8 mask;
> > +};
> > +
> > +struct ipft_keye_data {
> > + __le16 precedence;
> > + __le16 resv0[3];
> > + __le16 frm_attr_flags;
> > +#define IPFT_FAF_OVLAN BIT(2)
> > +#define IPFT_FAF_IVLAN BIT(3)
> > +#define IPFT_FAF_IP_HDR BIT(7)
> > +#define IPFT_FAF_IP_VER6 BIT(8)
> > +#define IPFT_FAF_L4_CODE GENMASK(11, 10)
> > +#define IPFT_FAF_TCP_HDR 1
> > +#define IPFT_FAF_UDP_HDR 2
> > +#define IPFT_FAF_SCTP_HDR 3
> > +#define IPFT_FAF_WOL_MAGIC BIT(12)
> > + __le16 frm_attr_flags_mask;
> > + __le16 dscp;
> > +#define IPFT_DSCP GENMASK(5, 0)
> > +#define IPFT_DSCP_MASK GENMASK(11, 0)
>
> Does IPFT_DSCP_MASK completely overlap with IPFT_DSCP?
>
> If it is defined as GENMASK(11, 0) instead of GENMASK(11, 6), using
> FIELD_PREP with this mask will not shift the value into the upper bits,
> which might overwrite the actual DSCP value in bits 0-5.
Thanks, this is a bug, I will fix it.
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: clock: qcom: Add video clock controller on Eliza SoC
From: Taniya Das @ 2026-04-08 7:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Vladimir Zapolskiy
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <4c4e80be-4aeb-4275-977f-b3f8c6ab26b0@oss.qualcomm.com>
On 4/7/2026 7:10 PM, Krzysztof Kozlowski wrote:
> On 17/03/2026 18:14, Taniya Das wrote:
>> Add compatible string for Eliza video clock controller and the bindings
>> for Eliza Qualcomm SoC.
>>
>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>> ---
>> .../bindings/clock/qcom,sm8450-videocc.yaml | 16 ++++++++++
>> include/dt-bindings/clock/qcom,eliza-videocc.h | 37 ++++++++++++++++++++++
>> 2 files changed, 53 insertions(+)
>>
>
> Although I already suggested that this was not tested (and you never
> replied where did you test it), but I also checked and this fails checks
> - constraints are mismatched now.
I will update the bindings for videocc.
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Bartosz Golaszewski @ 2026-04-08 7:31 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai, linusw,
brgl, robh, krzk+dt, conor+dt, afaerber, tychang
In-Reply-To: <20260408025243.1155482-4-eleanor.lin@realtek.com>
On Wed, 8 Apr 2026 04:52:42 +0200, Yu-Chun Lin <eleanor.lin@realtek.com> said:
> From: Tzuyi Chang <tychang@realtek.com>
>
> Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
>
> Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> which manages pins via shared bank registers, the RTD1625 introduces
> a per-pin register architecture. Each GPIO line now has its own
> dedicated 32-bit control register to manage configuration independently,
> including direction, output value, input value, interrupt enable, and
> debounce. Therefore, this distinct hardware design requires a separate
> driver.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
> Changes in v2:
> - Remove "default y".
> - Add base_offset member to struct rtd1625_gpio_info to handle merged regions.
> ---
> drivers/gpio/Kconfig | 11 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-rtd1625.c | 584 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 596 insertions(+)
> create mode 100644 drivers/gpio/gpio-rtd1625.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 5ee11a889867..281549ad72ac 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -638,6 +638,17 @@ config GPIO_RTD
> Say yes here to support GPIO functionality and GPIO interrupt on
> Realtek DHC SoCs.
>
> +config GPIO_RTD1625
> + tristate "Realtek DHC RTD1625 GPIO support"
> + depends on ARCH_REALTEK || COMPILE_TEST
> + select GPIOLIB_IRQCHIP
> + help
> + This option enables support for the GPIO controller on Realtek
> + DHC (Digital Home Center) RTD1625 SoC.
> +
> + Say yes here to support both basic GPIO line functionality
> + and GPIO interrupt handling capabilities for this platform.
> +
> config GPIO_SAMA5D2_PIOBU
> tristate "SAMA5D2 PIOBU GPIO support"
> depends on MFD_SYSCON
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index c05f7d795c43..c95ba218d53a 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -159,6 +159,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
> obj-$(CONFIG_GPIO_REG) += gpio-reg.o
> obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
> obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
> +obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
> obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
> obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
> obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
> diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
> new file mode 100644
> index 000000000000..bcc1bbb115fa
> --- /dev/null
> +++ b/drivers/gpio/gpio-rtd1625.c
> @@ -0,0 +1,584 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Realtek DHC RTD1625 gpio driver
> + *
> + * Copyright (c) 2023 Realtek Semiconductor Corp.
No modifications since 2023?
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqchip/chained_irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>
> +
> +#define RTD1625_GPIO_DIR BIT(0)
> +#define RTD1625_GPIO_OUT BIT(2)
> +#define RTD1625_GPIO_IN BIT(4)
> +#define RTD1625_GPIO_EDGE_INT_DP BIT(6)
> +#define RTD1625_GPIO_EDGE_INT_EN BIT(8)
> +#define RTD1625_GPIO_LEVEL_INT_EN BIT(16)
> +#define RTD1625_GPIO_LEVEL_INT_DP BIT(18)
> +#define RTD1625_GPIO_DEBOUNCE GENMASK(30, 28)
> +#define RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
> +
> +#define RTD1625_GPIO_WREN(x) ((x) << 1)
> +
> +/* Write-enable masks for all GPIO configs and reserved hardware bits */
> +#define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a
> +#define RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
> +
> +#define RTD1625_GPIO_DEBOUNCE_1US 0
> +#define RTD1625_GPIO_DEBOUNCE_10US 1
> +#define RTD1625_GPIO_DEBOUNCE_100US 2
> +#define RTD1625_GPIO_DEBOUNCE_1MS 3
> +#define RTD1625_GPIO_DEBOUNCE_10MS 4
> +#define RTD1625_GPIO_DEBOUNCE_20MS 5
> +#define RTD1625_GPIO_DEBOUNCE_30MS 6
> +#define RTD1625_GPIO_DEBOUNCE_50MS 7
> +
> +#define GPIO_CONTROL(gpio) ((gpio) * 4)
> +
> +/**
> + * struct rtd1625_gpio_info - Specific GPIO register information
> + * @num_gpios: The number of GPIOs
> + * @irq_type_support: Supported IRQ types
> + * @gpa_offset: Offset for GPIO assert interrupt status registers
> + * @gpda_offset: Offset for GPIO deassert interrupt status registers
> + * @level_offset: Offset of level interrupt status register
> + * @write_en_all: Write-enable mask for all configurable bits
> + */
> +struct rtd1625_gpio_info {
> + unsigned int num_gpios;
> + unsigned int irq_type_support;
> + unsigned int base_offset;
> + unsigned int gpa_offset;
> + unsigned int gpda_offset;
> + unsigned int level_offset;
> + unsigned int write_en_all;
> +};
Please remove the tabs in the above struct.
> +
> +struct rtd1625_gpio {
> + struct gpio_chip gpio_chip;
> + const struct rtd1625_gpio_info *info;
> + void __iomem *base;
> + void __iomem *irq_base;
> + unsigned int irqs[3];
> + raw_spinlock_t lock;
> + unsigned int *save_regs;
> +};
I'd also personally remove these tabs here but won't die on that hill.
> +
> +static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->gpa_offset + ((offset / 32) * 4);
> +}
> +
> +static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->gpda_offset + ((offset / 32) * 4);
> +}
> +
> +static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->level_offset + ((offset / 32) * 4);
> +}
Looking at these, I'm under the impression that this driver could quite easily
be converted to using gpio-mmio or even gpio-regmap with an MMIO regmap, have
you looked into it by any chance?
Bart
^ permalink raw reply
* Re: [PATCH] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Markus Elfring @ 2026-04-08 7:28 UTC (permalink / raw)
To: vulab, imx, linux-pm, linux-arm-kernel, Georgi Djakov,
Sascha Hauer, Shawn Guo
Cc: kernel, stable, LKML, Fabio Estevam
In-Reply-To: <20260408031004.309483-1-vulab@iscas.ac.cn>
> Move of_node_put(dn) after the last use of dn, and add a missing put
> in the error path to avoid both use-after-free and reference leak.
How do you think about to increase the application of scope-based resource management?
https://elixir.bootlin.com/linux/v7.0-rc7/source/include/linux/of.h#L138
https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/interconnect/imx/imx.c#L117-L160
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: realtek: Add GPIO support for RTD1625
From: Bartosz Golaszewski @ 2026-04-08 7:28 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai, linusw,
brgl, robh, krzk+dt, conor+dt, afaerber, tychang
In-Reply-To: <20260408025243.1155482-5-eleanor.lin@realtek.com>
On Wed, 8 Apr 2026 04:52:43 +0200, Yu-Chun Lin <eleanor.lin@realtek.com> said:
> Add the GPIO node for the Realtek RTD1625 SoC.
>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* RE: [PATCH v4 net-next 06/14] net: enetc: add support for the "Update" operation to buffer pool table
From: Wei Fang @ 2026-04-08 7:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011731.1795517-1-kuba@kernel.org>
> > @@ -702,5 +708,38 @@ int ntmp_vft_add_entry(struct ntmp_user *user,
> u16 vid,
> > }
> > EXPORT_SYMBOL_GPL(ntmp_vft_add_entry);
> >
> > +int ntmp_bpt_update_entry(struct ntmp_user *user, u32 entry_id,
> > + const struct bpt_cfge_data *cfge)
> > +{
> > + struct ntmp_dma_buf data = {
> > + .dev = user->dev,
> > + .size = sizeof(struct bpt_req_update),
> > + };
> > + struct bpt_req_update *req;
> > + union netc_cbd cbd;
> > + int err;
> > +
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd_eid(&req->rbe, user->tbl.bpt_ver, 0,
> > + NTMP_GEN_UA_CFGEU | BPT_UA_BPSEU, entry_id);
>
> Does this update action mask match the size of the request buffer?
>
> The mask includes both NTMP_GEN_UA_CFGEU and BPT_UA_BPSEU, which
> instructs
> the hardware to update both the configuration entry and the status entry.
> However, struct bpt_req_update only contains the configuration data,
> omitting the status data.
>
> If the hardware attempts to read the missing BPSE data, could it reject
> the command due to an undersized request length, or read beyond the
> intended payload into zero-initialized DMA padding? This might overwrite
> critical buffer pool tracking variables like amount_used_hwm.
>
> If only the configuration is being updated, should the BPT_UA_BPSEU flag
> be removed?
The BPSE_DATA is a set of statistics and status records kept by the hardware
(internal buffer), and does not require the user to provide additional data to
the hardware for updates. Therefore, for the 'update' operation, the request
buffer does not need to provide BPSE_DATA data.
^ permalink raw reply
* Re: [PATCH] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Frank Li @ 2026-04-08 7:24 UTC (permalink / raw)
To: Wentao Liang
Cc: Georgi Djakov, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-pm, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20260408031004.309483-1-vulab@iscas.ac.cn>
On Wed, Apr 08, 2026 at 03:10:04AM +0000, Wentao Liang wrote:
> Move of_node_put(dn) after the last use of dn, and add a missing put
> in the error path to avoid both use-after-free and reference leak.
>
> Fixes: f0d8048525d7 ("interconnect: Add imx core driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/interconnect/imx/imx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
> index 9511f80cf041..75431b5ccef8 100644
> --- a/drivers/interconnect/imx/imx.c
> +++ b/drivers/interconnect/imx/imx.c
> @@ -143,15 +143,16 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
> }
>
Please use auto cleanup to fix this problem
struct device_node * __free(device_nod) dn = of_parse_phandle(dev->of_node, adj->phandle_name, 0);
Frank
> pdev = of_find_device_by_node(dn);
> - of_node_put(dn);
> if (!pdev) {
> dev_warn(dev, "node %s[%d] missing device for %pOF\n",
> node->name, node->id, dn);
> + of_node_put(dn);
> return -EPROBE_DEFER;
> }
> node_data->qos_dev = &pdev->dev;
> dev_dbg(dev, "node %s[%d] has device node %pOF\n",
> node->name, node->id, dn);
> + of_node_put(dn);
> }
>
> return dev_pm_qos_add_request(node_data->qos_dev,
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH RESEND] arm64: dts: apple: fix spelling error
From: Axel Flordal @ 2026-04-08 7:21 UTC (permalink / raw)
To: asahi, linux-arm-kernel, devicetree, linux-kernel
Cc: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Change "configiguration" to "configuration".
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Axel Flordal <axel@flordal.net>
---
Original patch: https://lore.kernel.org/asahi/CAEg-Je-KwNNGoi3mpPeNq3Jmtzj_5seuj1Qeh2_1dt994iCJSA@mail.gmail.com/T/#t
If this is unwanted I of course won't send again.
---
arch/arm64/boot/dts/apple/spi1-nvram.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
index 9740fbf200f0..d2720b307774 100644
--- a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
+++ b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
@@ -2,7 +2,7 @@
//
// Devicetree include for common spi-nor nvram flash.
//
-// Apple uses a consistent configiguration for the nvram on all known M1* and
+// Apple uses a consistent configuration for the nvram on all known M1* and
// M2* devices.
//
// Copyright The Asahi Linux Contributors
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox