* [PATCH v6 10/10] ARM: multi_v7_defconfig: Enable the raspberrypi otp driver as module
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Enable the newly added Raspberry Pi OTP driver as module to allow access
to the otp registers. This driver provides access to the OTP registers
present on all Raspberry Pi boards.
Enabling this in the multi_v7_defconfg allows standard upstream kernels
to use these registers out of the box.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index bcc9aabc12028..4b61ad5f46ce7 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1281,6 +1281,7 @@ CONFIG_NVMEM_ROCKCHIP_EFUSE=m
CONFIG_NVMEM_STM32_ROMEM=m
CONFIG_NVMEM_SUNXI_SID=y
CONFIG_NVMEM_VF610_OCOTP=y
+CONFIG_NVMEM_RASPBERRYPI_OTP=m
CONFIG_FSI=m
CONFIG_FSI_MASTER_GPIO=m
CONFIG_FSI_MASTER_HUB=m
--
2.47.3
^ permalink raw reply related
* [PATCH v6 09/10] ARM: bcm2835_defconfig: Enable the raspberrypi otp driver as module
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Enable the newly added Raspberry Pi OTP driver as module to allow access
to the otp registers. This driver provides access to the OTP registers
present on all Raspberry Pi boards.
Enabling this in the bcm2835 defconfig allows standard upstream kernels
to use these registers out of the box.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm/configs/bcm2835_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 4a8ac09843d73..fd83bda9cfaaf 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -151,6 +151,8 @@ CONFIG_BCM2835_MBOX=y
CONFIG_RASPBERRYPI_POWER=y
CONFIG_PWM=y
CONFIG_PWM_BCM2835=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_RASPBERRYPI_OTP=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
--
2.47.3
^ permalink raw reply related
* [PATCH v6 07/10] dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Conor Dooley, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The "select" in schema is not necessary anymore since dtschema drops
simple-mfd when constructing the select/filter query for schemas with
compatibles.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index a3a5243b91706..7cf9a6fa1e5be 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -10,15 +10,6 @@ maintainers:
- Eric Anholt <eric@anholt.net>
- Stefan Wahren <wahrenst@gmx.net>
-select:
- properties:
- compatible:
- contains:
- const: raspberrypi,bcm2835-firmware
-
- required:
- - compatible
-
properties:
compatible:
oneOf:
--
2.47.3
^ permalink raw reply related
* [PATCH v6 05/10] firmware: raspberrypi: register nvmem driver
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The Raspberry Pi firmware exposes two regions with otp registers. The
first region called "customer otp" is available on all Raspberry Pi
models. The second is only available on the Raspberry Pi 5 (bcm2712).
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/firmware/raspberrypi.c | 59 +++++++++++++++++++++++++++++-
include/soc/bcm2835/raspberrypi-firmware.h | 5 +++
2 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 0aa322e9a2e73..1d3b8c190b2fd 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -24,12 +24,15 @@
static struct platform_device *rpi_hwmon;
static struct platform_device *rpi_clk;
+static struct platform_device *rpi_otp_customer;
+static struct platform_device *rpi_otp_private;
struct rpi_firmware {
struct mbox_client cl;
struct mbox_chan *chan; /* The property channel. */
struct completion c;
u32 enabled;
+ enum rpi_firmware_soc soc;
struct kref consumers;
};
@@ -231,6 +234,47 @@ static void rpi_register_clk_driver(struct device *dev)
-1, NULL, 0);
}
+static const struct rpi_otp_driver_data rpi_otp_customer_data = {
+ .name = "rpi-otp-customer",
+ .read_tag = RPI_FIRMWARE_GET_CUSTOMER_OTP,
+ .write_tag = RPI_FIRMWARE_SET_CUSTOMER_OTP,
+ .size = 32,
+ .root_only = false,
+};
+
+static const struct rpi_otp_driver_data rpi_otp_private_data = {
+ .name = "rpi-otp-private",
+ .read_tag = RPI_FIRMWARE_GET_PRIVATE_OTP,
+ .write_tag = RPI_FIRMWARE_SET_PRIVATE_OTP,
+ .size = 32,
+ .root_only = true,
+};
+
+static void rpi_register_otp_driver(struct device *dev)
+{
+ struct rpi_firmware *fw = dev_get_drvdata(dev);
+
+ rpi_otp_customer = platform_device_register_data(dev, "raspberrypi-otp",
+ PLATFORM_DEVID_AUTO,
+ &rpi_otp_customer_data,
+ sizeof(rpi_otp_customer_data));
+
+ if (IS_ERR(rpi_otp_customer))
+ dev_err(dev, "Failed to register customer OTP device: %pe\n",
+ rpi_otp_customer);
+
+ if (fw->soc == RPI_FIRMWARE_SOC_BCM2712) {
+ rpi_otp_private = platform_device_register_data(dev, "raspberrypi-otp",
+ PLATFORM_DEVID_AUTO,
+ &rpi_otp_private_data,
+ sizeof(rpi_otp_private_data));
+
+ if (IS_ERR(rpi_otp_private))
+ dev_err(dev, "Failed to register private OTP device: %pe\n",
+ rpi_otp_private);
+ }
+}
+
unsigned int rpi_firmware_clk_get_max_rate(struct rpi_firmware *fw, unsigned int id)
{
struct rpi_firmware_clk_rate_request msg =
@@ -299,12 +343,14 @@ static int rpi_firmware_probe(struct platform_device *pdev)
init_completion(&fw->c);
kref_init(&fw->consumers);
+ fw->soc = (uintptr_t)device_get_match_data(dev);
platform_set_drvdata(pdev, fw);
rpi_firmware_print_firmware_revision(fw);
rpi_register_hwmon_driver(dev, fw);
rpi_register_clk_driver(dev);
+ rpi_register_otp_driver(dev);
return 0;
}
@@ -327,12 +373,23 @@ static void rpi_firmware_remove(struct platform_device *pdev)
rpi_hwmon = NULL;
platform_device_unregister(rpi_clk);
rpi_clk = NULL;
+ platform_device_unregister(rpi_otp_customer);
+ rpi_otp_customer = NULL;
+ platform_device_unregister(rpi_otp_private);
+ rpi_otp_private = NULL;
rpi_firmware_put(fw);
}
static const struct of_device_id rpi_firmware_of_match[] = {
- { .compatible = "raspberrypi,bcm2835-firmware", },
+ {
+ .compatible = "raspberrypi,bcm2835-firmware",
+ .data = (void *)RPI_FIRMWARE_SOC_BCM2835,
+ },
+ {
+ .compatible = "raspberrypi,bcm2712-firmware",
+ .data = (void *)RPI_FIRMWARE_SOC_BCM2712,
+ },
{},
};
MODULE_DEVICE_TABLE(of, rpi_firmware_of_match);
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index 1e5e5f7e378d0..a4c94b85b7aa9 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -9,6 +9,11 @@
#include <linux/types.h>
#include <linux/of_device.h>
+enum rpi_firmware_soc {
+ RPI_FIRMWARE_SOC_BCM2835,
+ RPI_FIRMWARE_SOC_BCM2712,
+};
+
struct rpi_firmware;
enum rpi_firmware_property_status {
--
2.47.3
^ permalink raw reply related
* [PATCH v6 06/10] arm64: dts: broadcom: bcm2712: add raspberrypi,bcm2712-firmware compatible
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The Raspberry Pi 5 (BCM2712) firmware exposes additional features such
as the additional OTP register region called 'private OTP'.
Add the raspberrypi,bcm2712-firmware compatible to allow drivers to
distinguish this hardware variant while keeping
raspberrypi,bcm2835-firmware as a fallback for backward compatibility
with existing drivers.
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
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 b7a6bc34ae1ab..4aa8ec7601b84 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
@@ -46,7 +46,9 @@ power_button: power-button {
firmware {
firmware: rpi-firmware {
- compatible = "raspberrypi,bcm2835-firmware", "simple-mfd";
+ compatible = "raspberrypi,bcm2712-firmware",
+ "raspberrypi,bcm2835-firmware",
+ "simple-mfd";
mboxes = <&mailbox>;
--
2.47.3
^ permalink raw reply related
* [PATCH v6 08/10] arm64: defconfig: Enable the raspberrypi otp driver as module
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Enable the newly added Raspberry Pi OTP driver as module to allow access
to the otp registers. This driver provides access to the OTP registers
present on all Raspberry Pi boards and the private OTP registers present
on the Raspberry Pi 5.
Enabling this in the generic arm64 defconfig allows standard upstream
kernels to use these registers on Raspberry Pi 3, 4 and 5 out of the
box.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e44e83bc57812..3abb3ca34c708 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1849,6 +1849,7 @@ CONFIG_NVMEM_SPMI_SDAM=m
CONFIG_NVMEM_SUNXI_SID=y
CONFIG_NVMEM_UNIPHIER_EFUSE=y
CONFIG_NVMEM_ZYNQMP=m
+CONFIG_NVMEM_RASPBERRYPI_OTP=m
CONFIG_FPGA=y
CONFIG_FPGA_MGR_ALTERA_CVP=m
CONFIG_FPGA_MGR_STRATIX10_SOC=m
--
2.47.3
^ permalink raw reply related
* [PATCH v6 02/10] nvmem: core: Enforce stride and alignment checks for nvmem_device functions
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The stride and word_size attributes in the nvmem_config struct are
currently only used when reading/writing through sysfs functions
bin_attr_nvmem_read/bin_attr_nvmem_write and in the nvmem_cell api.
Reads and writes with nvmem_device_write/nvmem_device_read still allow
unaligned access.
Add a check to these functions to enforce word_size and stride_length
aligned reads and writes.
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/nvmem/core.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 311cb2e5a5c02..6b313f63d07ef 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -2068,6 +2068,12 @@ int nvmem_device_read(struct nvmem_device *nvmem,
if (!nvmem)
return -EINVAL;
+ if (!IS_ALIGNED(offset, nvmem->stride))
+ return -EINVAL;
+
+ if (!IS_ALIGNED(bytes, nvmem->word_size))
+ return -EINVAL;
+
rc = nvmem_reg_read(nvmem, offset, buf, bytes);
if (rc)
@@ -2096,6 +2102,12 @@ int nvmem_device_write(struct nvmem_device *nvmem,
if (!nvmem)
return -EINVAL;
+ if (!IS_ALIGNED(offset, nvmem->stride))
+ return -EINVAL;
+
+ if (!IS_ALIGNED(bytes, nvmem->word_size))
+ return -EINVAL;
+
rc = nvmem_reg_write(nvmem, offset, buf, bytes);
if (rc)
--
2.47.3
^ permalink raw reply related
* [PATCH v6 04/10] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Raspberry Pis have OTP registers which can be accessed through the
videocore firmware. Add a nvmem driver to support these OTP registers.
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/nvmem/Kconfig | 11 +++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/raspberrypi-otp.c | 131 +++++++++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 10 +++
4 files changed, 153 insertions(+)
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0e..a1922b48d0c2e 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -483,4 +483,15 @@ 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"
+ depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
+ 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 (BCM2712 only).
+
+ 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 7252b8ec88d46..8ca2095e068f3 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 0000000000000..2e2537ee6793b
--- /dev/null
+++ b/drivers/nvmem/raspberrypi-otp.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+struct rpi_otp_priv {
+ struct rpi_firmware *fw;
+ u32 read_tag;
+ u32 write_tag;
+};
+
+struct rpi_otp_header {
+ __le32 start;
+ __le32 count;
+ __le32 data[] __counted_by_le(count);
+};
+
+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;
+ u32 count;
+ int ret;
+
+ count = bytes / 4;
+
+ fwbuf = kzalloc(struct_size(fwbuf, data, count), GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = cpu_to_le32(offset / 4);
+ fwbuf->count = cpu_to_le32(count);
+
+ 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;
+ u32 count;
+ int ret;
+
+ count = bytes / 4;
+
+ fwbuf = kzalloc(struct_size(fwbuf, data, count), GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = cpu_to_le32(offset / 4);
+ fwbuf->count = cpu_to_le32(count);
+ 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 int rpi_otp_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct nvmem_device *nvmem;
+ struct rpi_otp_priv *priv;
+ 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,
+ .id = NVMEM_DEVID_NONE,
+ };
+
+ data = dev_get_platdata(dev);
+ if (!data)
+ return -ENODEV;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->fw = dev_get_drvdata(dev->parent);
+ priv->read_tag = data->read_tag;
+ priv->write_tag = data->write_tag;
+ config.dev = dev;
+ config.priv = priv;
+ config.name = data->name;
+ config.size = data->size;
+ config.root_only = data->root_only;
+
+ 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 platform_device_id raspberrypi_otp_id[] = {
+ { "raspberrypi-otp" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, raspberrypi_otp_id);
+
+static struct platform_driver raspberrypi_otp_driver = {
+ .probe = rpi_otp_probe,
+ .driver = {
+ .name = "raspberrypi-otp",
+ },
+ .id_table = raspberrypi_otp_id,
+};
+module_platform_driver(raspberrypi_otp_driver);
+
+MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
+MODULE_DESCRIPTION("Raspberry Pi OTP driver");
+MODULE_LICENSE("GPL");
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index eb33838e0cd10..1e5e5f7e378d0 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,
@@ -174,6 +176,14 @@ struct rpi_firmware_clk_rate_request {
.id = cpu_to_le32(_id), \
}
+struct rpi_otp_driver_data {
+ const char *name;
+ u32 read_tag;
+ u32 write_tag;
+ int size;
+ bool root_only;
+};
+
#if IS_REACHABLE(CONFIG_RASPBERRYPI_FIRMWARE)
int rpi_firmware_property(struct rpi_firmware *fw,
u32 tag, void *data, size_t len);
--
2.47.3
^ permalink raw reply related
* [PATCH v6 03/10] dt-bindings: raspberrypi,bcm2835-firmware: Add bcm2712-firmware compatible
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Conor Dooley, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Add a compatible string for the bcm2712 firmware. The bcm2712-firmware
is compatible with the bcm2835-firmware so allow the bcm2835-firmware as
fallback.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 983ea80eaec97..a3a5243b91706 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -21,9 +21,14 @@ select:
properties:
compatible:
- items:
- - const: raspberrypi,bcm2835-firmware
- - const: simple-mfd
+ oneOf:
+ - items:
+ - const: raspberrypi,bcm2835-firmware
+ - const: simple-mfd
+ - items:
+ - const: raspberrypi,bcm2712-firmware
+ - const: raspberrypi,bcm2835-firmware
+ - const: simple-mfd
mboxes:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH v6 01/10] soc: bcm2835: Use IS_REACHABLE for function declaration
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The drivers that depend on the RASPBERRYPI_FIRMWARE use
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
This should ensure that the driver is not compiled in when
RASPBERRYPI_FIRMWARE is 'm' on COMPILE_TEST which leads to linker
errors.
The same can be achieved by using IS_REACHABLE in the
raspberrypi-firmware header. This evaluates to false when invoked from
built-in code. This way the Kconfig can be written as
depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
Which is a more readable variant.
Suggested-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
include/soc/bcm2835/raspberrypi-firmware.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe5542..eb33838e0cd10 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -174,7 +174,7 @@ struct rpi_firmware_clk_rate_request {
.id = cpu_to_le32(_id), \
}
-#if IS_ENABLED(CONFIG_RASPBERRYPI_FIRMWARE)
+#if IS_REACHABLE(CONFIG_RASPBERRYPI_FIRMWARE)
int rpi_firmware_property(struct rpi_firmware *fw,
u32 tag, void *data, size_t len);
int rpi_firmware_property_list(struct rpi_firmware *fw,
--
2.47.3
^ permalink raw reply related
* [PATCH v6 00/10] nvmem: Add Raspberry Pi OTP nvmem driver
From: Gregor Herburger @ 2026-05-22 15:40 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, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger, Conor Dooley
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 updates the devicetree
for the Raspberry Pi 5.
---
Changes in v6:
- Use %pe in dev_err
- Include <linux/slab.h> to fix build on arm
- Add arm defconfigs: multi_v7_defconfig and bcm2835_defconfig
- Reword commit messages
- Link to v5: https://patch.msgid.link/20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de
Changes in v5:
- Move alignment check to nvmem core
- Use IS_REACHABLE to simplify Kconfig
- use root_only for private driver
- Add driver as module to arch64 defconfig
- Use MODULE_DEVICE_TABLE
- Remove some unused attributes, fix typos, minor fixups
- Link to v4: https://patch.msgid.link/20260508-rpi-otp-driver-v4-0-cf8d725d8821@linutronix.de
Changes in v4:
- Additional patch to drop unnecessary select schema
- fix dt-bindings
- use __counted_by_le
- additional alignment check in read/write callbacks
- Link to v3: https://patch.msgid.link/20260506-rpi-otp-driver-v3-0-294602663695@linutronix.de
Changes in v3:
- dts: add "raspberrypi,bcm2835-firmware" as fallback and fix dt-bindings
- Fix Kconfig depends
- Changed firmware data fields to __le32
- Add MODULE_ALIAS
- Link to v2: https://patch.msgid.link/20260505-rpi-otp-driver-v2-0-e9176ec72837@linutronix.de
Changes in v2:
- register nvmem driver from firmware driver and drop firmware sub nodes
- Use struct_size and __counted_by for dynamic array
- Drop unneeded comment in Kconfig
- Use NVMEM_DEVID_NONE
- Use kzalloc
- Update module description
- Link to v1: https://patch.msgid.link/20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de
---
Gregor Herburger (10):
soc: bcm2835: Use IS_REACHABLE for function declaration
nvmem: core: Enforce stride and alignment checks for nvmem_device functions
dt-bindings: raspberrypi,bcm2835-firmware: Add bcm2712-firmware compatible
nvmem: Add the Raspberry Pi OTP driver
firmware: raspberrypi: register nvmem driver
arm64: dts: broadcom: bcm2712: add raspberrypi,bcm2712-firmware compatible
dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
arm64: defconfig: Enable the raspberrypi otp driver as module
ARM: bcm2835_defconfig: Enable the raspberrypi otp driver as module
ARM: multi_v7_defconfig: Enable the raspberrypi otp driver as module
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 ++--
arch/arm/configs/bcm2835_defconfig | 2 +
arch/arm/configs/multi_v7_defconfig | 1 +
.../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 4 +-
arch/arm64/configs/defconfig | 1 +
drivers/firmware/raspberrypi.c | 59 +++++++++-
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/core.c | 12 ++
drivers/nvmem/raspberrypi-otp.c | 131 +++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 17 ++-
11 files changed, 244 insertions(+), 15 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-rpi-otp-driver-75fce1dcff7d
Best regards,
--
Gregor Herburger <gregor.herburger@linutronix.de>
^ permalink raw reply
* Re: [PATCH v2 6/7] arm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs
From: Geert Uytterhoeven @ 2026-05-22 15:34 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Nguyen Tran, Brian Masney, Conor Dooley,
Krzysztof Kozlowski, Kuninori Morimoto, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, Ulf Hansson,
Wolfram Sang, devicetree, linux-clk, linux-kernel, linux-mmc,
linux-renesas-soc
In-Reply-To: <20260504144534.43745-7-marek.vasut+renesas@mailbox.org>
On Mon, 4 May 2026 at 16:46, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> From: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
>
> Add support for the Renesas R-Car M3Le (R8A779MD) SoC, a variant of the
> R-Car M3-N (R8A77965) SoC. The Renesas M3Le SoC is a register-compatible
> variant of the R8A77965 (M3-N) with reduced set of peripherals.
>
> Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> V2: - Drop DU until it can be tested
> - Reinstate sdhi3, switch SDHI to dedicated M3Le compatible strings
> - Add no-mmc DT property to SDHI3/MMC1, because MMC1 is not supported
> - Disable ohci1, ehci1, usb2_phy1
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: Add Display Port audio on Arduino Monza
From: Loic Poulain @ 2026-05-22 15:30 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260522100026.94760-1-srinivas.kandagatla@oss.qualcomm.com>
On Fri, May 22, 2026 at 12:00 PM Srinivas Kandagatla
<srinivas.kandagatla@oss.qualcomm.com> wrote:
>
> Add support for Display port Audio on Arduino VENTUNO-Q board.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
> CC: Loic Poulain <loic.poulain@oss.qualcomm.com>
Tested-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> alsa tplg changes are:
> https://github.com/linux-msm/audioreach-topology/pull/63
> Ucm changes are:
> https://github.com/Srinivas-Kandagatla/alsa-ucm-conf/tree/ventuno-q
>
>
> .../arm64/boot/dts/qcom/monaco-arduino-monza.dts | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> index ca14f0ea4dae..01acc8363cbb 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> +++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> @@ -117,6 +117,22 @@ platform {
> sound-dai = <&q6apm>;
> };
> };
> +
> + displayport-0-dai-link {
> + link-name = "DisplayPort0 Playback";
> +
> + codec {
> + sound-dai = <&mdss_dp0>;
> + };
> +
> + cpu {
> + sound-dai = <&q6apmbedai DISPLAY_PORT_RX_0>;
> + };
> +
> + platform {
> + sound-dai = <&q6apm>;
> + };
> + };
> };
>
> vdc_3v3: regulator-3v3 {
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2 5/7] soc: renesas: Identify Renesas R-Car R8A779MD M3Le SoC
From: Geert Uytterhoeven @ 2026-05-22 15:29 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Brian Masney, Conor Dooley, Krzysztof Kozlowski,
Kuninori Morimoto, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, Ulf Hansson, Wolfram Sang, devicetree, linux-clk,
linux-kernel, linux-mmc, linux-renesas-soc
In-Reply-To: <20260504144534.43745-6-marek.vasut+renesas@mailbox.org>
On Mon, 4 May 2026 at 16:46, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add support for identifying the R-Car M3Le (R8A779MD) SoC.
>
> The Renesas R-Car R8A779MD M3Le SoC is a variant of the
> already supported R-Car M3-N SoC with reduced peripherals.
> Enable support for the M3Le SoC through already existing
> ARCH_R8A77965 configuration symbol. PRR reads 0x67c05501 .
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks, will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 4/7] dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
From: Geert Uytterhoeven @ 2026-05-22 15:28 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Brian Masney, Conor Dooley,
Krzysztof Kozlowski, Kuninori Morimoto, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, Ulf Hansson,
Wolfram Sang, devicetree, linux-clk, linux-kernel, linux-mmc,
linux-renesas-soc
In-Reply-To: <20260504144534.43745-5-marek.vasut+renesas@mailbox.org>
On Mon, 4 May 2026 at 16:46, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Document the compatible value for the Renesas R-Car M3Le (R8A779MD)
> SoC and the Renesas Geist development board. The Renesas M3Le SoC is
> a register-compatible variant of the R8A77965 (M3-N) with reduced set
> of peripherals. The Geist board is derived from Renesas Salvator-X/XS
> boards, with adjustment for the R8A779MD SoC.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> V2: - Add AB from Conor
> - Fill in Geist (RTP8A779MDASKB0F10S)
> - Add RB from Geert
Thanks, will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v7 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: sashiko-bot @ 2026-05-22 15:27 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: vkoul, neil.armstrong, olteanv, linux-phy, robh, conor+dt,
devicetree
In-Reply-To: <20260522-x1e-csi2-phy-v7-2-79cb1280fad6@linaro.org>
Thank you for your contribution! Sashiko AI review found 9 potential issue(s) to consider:
- [High] Lane polarity configuration overwrites the same hardcoded register instead of applying per-lane offsets.
- [High] The driver attaches PM domains but fails to enable Runtime PM or power them on.
- [High] Unconditional dereference of `pd_list` which can be NULL.
- [High] The power-off sequence incorrectly drops the PM domain performance state before disabling clocks and dropping the OPP rate.
- [High] A zero return value from `clk_round_rate()` is incorrectly treated as success, leading to a divide-by-zero panic.
- [Medium] Missing resource cleanup in the error paths of `phy_qcom_mipi_csi2_power_on()`.
- [Medium] Integer underflow in `settle_cnt` calculation.
- [Medium] Unvalidated lane positions from Device Tree lead to undefined behavior in bitwise shifts.
- [Low] Missing bounds check on `args_count` in the PHY xlate callback.
--
commit 9960771b4e31e9a37ca7022cc7945264d506b447
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date: Fri May 22 14:45:10 2026 +0000
phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
Add a new MIPI CSI2 driver in DPHY mode initially. The entire set of
existing CAMSS CSI PHY init sequences are imported in order to save time
and effort in later patches.
> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
> new file mode 100644
> index 0000000000000..1e7729d4ee5d0
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
[ ... ]
> +static u8 phy_qcom_mipi_csi2_settle_cnt_calc(s64 link_freq, u32 timer_clk_rate)
> +{
[ ... ]
> + timer_period_ps = div_u64(PSEC_PER_SEC, timer_clk_rate);
> + settle_cnt = t_hs_settle_ps / timer_period_ps - 6;
[Severity: Medium]
Could this underflow if timer_period_ps is large?
Because settle_cnt is an unsigned u8, an underflow here would result in a
large wrap-around value (like 251) being written to the hardware,
corrupting the PHY timing settings.
> +
> + return settle_cnt;
> +}
[ ... ]
> +static int phy_qcom_mipi_csi2_lanes_enable(struct mipi_csi2phy_device *csi2phy,
> + struct mipi_csi2phy_stream_cfg *cfg)
> +{
[ ... ]
> + settle_cnt = phy_qcom_mipi_csi2_settle_cnt_calc(cfg->link_freq, csi2phy->timer_clk_rate);
> +
> + /* Lane position enable in common reg offset */
> + val = BIT(csi2phy->stream_cfg.lane_cfg.clk.pos);
> + for (i = 0; i < cfg->num_data_lanes; i++)
> + val |= BIT(lane_cfg->data[i].pos);
[Severity: Medium]
Is it possible for unvalidated lane positions from the Device Tree to
cause undefined behavior here?
If a parsed position value is >= 32, this might result in an invalid
shift. Additionally, since val is a u8, any position >= 8 would
silently truncate to 0 and fail to enable the lane.
> +
> + writel(val, csi2phy->base +
> + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->common_regs_offset, 5));
> +
> + /* Lane configuration for polarity @ CSIPHY-base + CTRL9 */
> + for (i = 0; i < cfg->num_data_lanes; i++) {
> + if (lane_cfg->data[i].pol) {
> + writel(BIT(2), csi2phy->base + CSIPHY_2PH_LN_CSI_2PHASE_CTRLn(9));
[Severity: High]
Does this overwrite the same hardcoded register for all lanes?
Since CSIPHY_2PH_LN_CSI_2PHASE_CTRLn(9) expands to a static offset, this
repeatedly writes to lane 0's polarity register regardless of which lane
is being configured, and seems to ignore the clock lane polarity setting
entirely.
> + }
> + }
> +
[ ... ]
> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
> new file mode 100644
> index 0000000000000..578926bfaef45
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
[ ... ]
> +static int
> +phy_qcom_mipi_csi2_set_clock_rates(struct mipi_csi2phy_device *csi2phy,
> + s64 link_freq)
> +{
[ ... ]
> + for (i = 0; i < csi2phy->pd_list->num_pds; i++) {
[Severity: High]
Can pd_list be NULL here?
If CONFIG_PM_GENERIC_DOMAINS is disabled, devm_pm_domain_attach_list()
returns 0 but leaves csi2phy->pd_list as NULL. This would lead to a
kernel panic when dereferencing pd_list->num_pds.
> + unsigned int perf = dev_pm_opp_get_required_pstate(opp, i);
> +
> + ret = dev_pm_genpd_set_performance_state(csi2phy->pd_list->pd_devs[i], perf);
[ ... ]
> + timer_rate = clk_round_rate(csi2phy->timer_clk, link_freq / 4);
> + if (timer_rate <= 0) {
> + ret = timer_rate;
> + goto unset_opp_rate;
[Severity: High]
If clk_round_rate() returns 0, does this incorrectly treat it as a success?
Setting ret to 0 and jumping to unset_opp_rate would leave timer_clk_rate
as 0, which later causes a divide-by-zero panic in
phy_qcom_mipi_csi2_settle_cnt_calc().
> + }
> +
> + ret = clk_set_rate(csi2phy->timer_clk, timer_rate);
[ ... ]
> +static int phy_qcom_mipi_csi2_power_on(struct phy *phy)
> +{
[ ... ]
> + ret = clk_bulk_prepare_enable(csi2phy->soc_cfg->num_clk,
> + csi2phy->clks);
> + if (ret) {
> + dev_err(dev, "failed to enable clocks, %d\n", ret);
> + goto unset_rate;
> + }
> +
> + ops->reset(csi2phy);
[ ... ]
> +unset_rate:
> + dev_pm_opp_set_rate(csi2phy->dev, 0);
[Severity: Medium]
Does this error path miss cleaning up the PM domain performance states?
While it drops the OPP rate and regulator votes, it completely skips
unwinding the performance states that were elevated during
phy_qcom_mipi_csi2_set_clock_rates(), leaking the votes.
> +
> +poweroff_phy:
> + regulator_bulk_disable(csi2phy->soc_cfg->num_supplies,
> + csi2phy->supplies);
> +
> + return ret;
> +}
> +
> +static int phy_qcom_mipi_csi2_power_off(struct phy *phy)
> +{
> + struct mipi_csi2phy_device *csi2phy = phy_get_drvdata(phy);
> + const struct mipi_csi2phy_hw_ops *ops = csi2phy->soc_cfg->ops;
> + int i;
> +
> + ops->lanes_disable(csi2phy, &csi2phy->stream_cfg);
> +
> + for (i = 0; i < csi2phy->pd_list->num_pds; i++)
> + dev_pm_genpd_set_performance_state(csi2phy->pd_list->pd_devs[i], 0);
> +
> + clk_bulk_disable_unprepare(csi2phy->soc_cfg->num_clk,
> + csi2phy->clks);
[Severity: High]
Is this sequence dropping the PM domain performance state before
disabling the clocks?
Removing the voltage (performance state) while hardware logic is still
driven by high-frequency clocks can cause logic timing failures and system
hangs.
Also, similarly to phy_qcom_mipi_csi2_set_clock_rates(), accessing
pd_list->num_pds unconditionally here could panic if pd_list is NULL.
> + dev_pm_opp_set_rate(csi2phy->dev, 0);
> + regulator_bulk_disable(csi2phy->soc_cfg->num_supplies,
> + csi2phy->supplies);
> +
> + return 0;
> +}
[ ... ]
> +static struct phy *qcom_csi2_phy_xlate(struct device *dev,
> + const struct of_phandle_args *args)
> +{
> + struct mipi_csi2phy_device *csi2phy = dev_get_drvdata(dev);
> +
> + if (args->args[0] != PHY_TYPE_DPHY) {
[Severity: Low]
Can we add a bounds check for args->args_count here?
If a malformed Device Tree node specifies #phy-cells = <0>, this will
read uninitialized memory from the args array.
> + dev_err(csi2phy->dev, "mode %d -EOPNOTSUPP\n", args->args[0]);
> + return ERR_PTR(-EOPNOTSUPP);
> + }
[ ... ]
> +static int phy_qcom_mipi_csi2_probe(struct platform_device *pdev)
> +{
[ ... ]
> + ret = phy_qcom_mipi_csi2_attach_pm_domains(csi2phy);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to attach power-domain list\n");
[Severity: High]
Are we missing Runtime PM initialization for the attached PM domains?
devm_pm_domain_attach_list() creates virtual devices, but without
pm_runtime_enable() and pm_runtime_get_sync(), these domains remain
suspended. As a result, any dev_pm_genpd_set_performance_state() votes
are just cached and never applied to the hardware, leaving the PHY
unpowered.
> +
> + for (i = 0; i < num_clk; i++)
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-x1e-csi2-phy-v7-0-79cb1280fad6@linaro.org?part=2
^ permalink raw reply
* Re: [PATCH RFC 0/3] iio: add Open Sensor Fusion UART driver
From: Jonathan Cameron @ 2026-05-22 15:22 UTC (permalink / raw)
To: Jinseob Kim
Cc: linux-iio, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel
In-Reply-To: <20260520072843.3593-1-kimjinseob88@gmail.com>
On Wed, 20 May 2026 16:28:40 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:
> Open Sensor Fusion is a UART-attached sensor aggregation device. The current
> prototype sends OSF protocol v0 frames over a host UART link. This RFC adds the
> first Linux IIO receive path for that UART stream.
>
> The first transport is serdev UART. USB, real sensor reads, fusion output, and
> production timestamp correlation are intentionally left out of this series.
>
> The driver code is kept in one patch for the first RFC to avoid intermediate
> non-buildable states. The internal files are still split by protocol, stream,
> core, transport, and IIO code.
Even for an RFC you need to break it up. If you do it right there won't
be non-buildable states. Take a look at how any complex IIO driver is added.
Key thing here seems to be that we need some references.
Superficially sounds like an open source sensor hub implementation but
we need a datasheet / reference manual to be able to review this properly.
I'll have a first look but it's likely to be somewhat superficial.
^ permalink raw reply
* Re: [PATCH V1 1/3] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Add Hawi UFS PHY compatible
From: Palash Kambar @ 2026-05-22 15:18 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, alim.akhtar,
avri.altman, bvanassche, andersson, dmitry.baryshkov, abel.vesa,
luca.weiss, linux-arm-msm, linux-phy, devicetree, linux-kernel,
linux-scsi
In-Reply-To: <uut3u6djc2dc23aznjxdqvkehpx3ooa7eknzjzubnlmylwvxxb@aow3lpjurhnt>
On 5/19/2026 11:35 AM, Manivannan Sadhasivam wrote:
> On Mon, May 18, 2026 at 10:23:44PM +0530, palash.kambar@oss.qualcomm.com wrote:
>> From: Palash Kambar <palash.kambar@oss.qualcomm.com>
>>
>> Document QMP UFS PHY compatible for Hawi SoC.
>>
>> Signed-off-by: Palash Kambar <palash.kambar@oss.qualcomm.com>
>> ---
>> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
>> index 9616c736b6d4..2326dcf38a46 100644
>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
>> @@ -37,6 +37,7 @@ properties:
>> - qcom,kaanapali-qmp-ufs-phy
>> - const: qcom,sm8750-qmp-ufs-phy
>> - enum:
>> + - qcom,hawi-qmp-ufs-phy
>
> Don't you need to add the Hawi compatible to the below check for clocks?
>
> - Mani
>
Sure Mani Will update. Thanks.
^ permalink raw reply
* [PATCH v4 2/2] cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC
From: Imran Shaik @ 2026-05-22 15:16 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-pm, devicetree,
linux-kernel, linux-arm-msm, Imran Shaik, Konrad Dybcio
In-Reply-To: <20260522-shikra-cpufreq-scaling-v4-0-f042a25896c5@oss.qualcomm.com>
From: Taniya Das <taniya.das@oss.qualcomm.com>
The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
but supports only up to 12 frequency lookup table (LUT) entries. When all
12 entries are populated, the existing repetitive LUT entry check may read
beyond valid entries and expose incorrect frequencies. Hence, introduce
shikra_epss_soc_data that reuses EPSS configuration with appropriate LUT
entries limit.
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
---
drivers/cpufreq/qcom-cpufreq-hw.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index ea9a20d27b8fdceb9341ee53e5fa27b7a6d92483..3d5a865fb8a35e112cb4d040fb519e2c122a91dc 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
*/
#include <linux/bitfield.h>
@@ -40,6 +41,7 @@ struct qcom_cpufreq_soc_data {
u32 reg_intr_clr;
u32 reg_current_vote;
u32 reg_perf_state;
+ u32 lut_max_entries;
u8 lut_row_size;
};
@@ -156,7 +158,7 @@ static unsigned int qcom_cpufreq_get_freq(struct cpufreq_policy *policy)
soc_data = qcom_cpufreq.soc_data;
index = readl_relaxed(data->base + soc_data->reg_perf_state);
- index = min(index, LUT_MAX_ENTRIES - 1);
+ index = min(index, soc_data->lut_max_entries - 1);
return policy->freq_table[index].frequency;
}
@@ -211,7 +213,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
struct qcom_cpufreq_data *drv_data = policy->driver_data;
const struct qcom_cpufreq_soc_data *soc_data = qcom_cpufreq.soc_data;
- table = kzalloc_objs(*table, LUT_MAX_ENTRIES + 1);
+ table = kzalloc_objs(*table, soc_data->lut_max_entries + 1);
if (!table)
return -ENOMEM;
@@ -236,7 +238,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
icc_scaling_enabled = false;
}
- for (i = 0; i < LUT_MAX_ENTRIES; i++) {
+ for (i = 0; i < soc_data->lut_max_entries; i++) {
data = readl_relaxed(drv_data->base + soc_data->reg_freq_lut +
i * soc_data->lut_row_size);
src = FIELD_GET(LUT_SRC, data);
@@ -405,6 +407,7 @@ static const struct qcom_cpufreq_soc_data qcom_soc_data = {
.reg_current_vote = 0x704,
.reg_perf_state = 0x920,
.lut_row_size = 32,
+ .lut_max_entries = LUT_MAX_ENTRIES,
};
static const struct qcom_cpufreq_soc_data epss_soc_data = {
@@ -416,11 +419,25 @@ static const struct qcom_cpufreq_soc_data epss_soc_data = {
.reg_intr_clr = 0x308,
.reg_perf_state = 0x320,
.lut_row_size = 4,
+ .lut_max_entries = LUT_MAX_ENTRIES,
+};
+
+static const struct qcom_cpufreq_soc_data shikra_epss_soc_data = {
+ .reg_enable = 0x0,
+ .reg_domain_state = 0x20,
+ .reg_dcvs_ctrl = 0xb0,
+ .reg_freq_lut = 0x100,
+ .reg_volt_lut = 0x200,
+ .reg_intr_clr = 0x308,
+ .reg_perf_state = 0x320,
+ .lut_row_size = 4,
+ .lut_max_entries = 12,
};
static const struct of_device_id qcom_cpufreq_hw_match[] = {
{ .compatible = "qcom,cpufreq-hw", .data = &qcom_soc_data },
{ .compatible = "qcom,cpufreq-epss", .data = &epss_soc_data },
+ { .compatible = "qcom,shikra-epss", .data = &shikra_epss_soc_data },
{}
};
MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: cpufreq: Document Qualcomm Shikra SoC EPSS
From: Imran Shaik @ 2026-05-22 15:16 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-pm, devicetree,
linux-kernel, linux-arm-msm, Imran Shaik, Krzysztof Kozlowski
In-Reply-To: <20260522-shikra-cpufreq-scaling-v4-0-f042a25896c5@oss.qualcomm.com>
The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
but supports only up to 12 frequency lookup table (LUT) entries. Introduce
Shikra specific bindings to represent this constrained EPSS variant.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
---
.../bindings/cpufreq/qcom,shikra-epss.yaml | 96 ++++++++++++++++++++++
1 file changed, 96 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..1a3105e86980a14069f8fb40c92d1f9cc71c6c1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/qcom,shikra-epss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Shikra SoC EPSS
+
+maintainers:
+ - Imran Shaik <imran.shaik@oss.qualcomm.com>
+ - Taniya Das <taniya.das@oss.qualcomm.com>
+
+description: |
+ EPSS is a hardware engine used by some Qualcomm SoCs to manage
+ frequency in hardware. It is capable of controlling frequency for
+ multiple clusters.
+
+ The Qualcomm Shikra SoC EPSS supports up to 12 frequency lookup table
+ (LUT) entries.
+
+properties:
+ compatible:
+ enum:
+ - qcom,shikra-epss
+
+ reg:
+ items:
+ - description: Frequency domain 0 register region
+ - description: Frequency domain 1 register region
+
+ reg-names:
+ items:
+ - const: freq-domain0
+ - const: freq-domain1
+
+ clocks:
+ items:
+ - description: XO Clock
+ - description: GPLL0 Clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: alternate
+
+ interrupts:
+ items:
+ - description: IRQ line for DCVSH 0
+ - description: IRQ line for DCVSH 1
+
+ interrupt-names:
+ items:
+ - const: dcvsh-irq-0
+ - const: dcvsh-irq-1
+
+ '#freq-domain-cells':
+ const: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - '#freq-domain-cells'
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpufreq@fd91000 {
+ compatible = "qcom,shikra-epss";
+ reg = <0x0fd91000 0x1000>, <0x0fd92000 0x1000>;
+ reg-names = "freq-domain0", "freq-domain1";
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&gpll0>;
+ clock-names = "xo", "alternate";
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "dcvsh-irq-0", "dcvsh-irq-1";
+ #freq-domain-cells = <1>;
+ #clock-cells = <1>;
+ };
+ };
+...
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/2] Add cpufreq scaling support for Qualcomm Shikra SoC
From: Imran Shaik @ 2026-05-22 15:16 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-pm, devicetree,
linux-kernel, linux-arm-msm, Imran Shaik, Krzysztof Kozlowski,
Konrad Dybcio
This series adds cpufreq scaling support on Qualcomm Shikra SoC.
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
---
Changes in v4:
- Drop CPUFREQ and use EPSS in bindings [Krzysztof]
- Update bindings patch commit subject with correct subsystem prefix [Krzysztof]
- Link to v3: https://lore.kernel.org/r/20260521-shikra-cpufreq-scaling-v3-0-883c13d1e514@oss.qualcomm.com
Changes in v3:
- Updated bindings as per the review comments [Krzysztof]
- Updated driver patch commit text [Dmitry]
- Updated compatible in driver patch as per the bindings
- Link to v2: https://lore.kernel.org/r/20260519-shikra-cpufreq-scaling-v2-0-2b09f0e1c9d8@oss.qualcomm.com
Changes in v2:
- Dropped the generic compatible approach, and introduced Shikra
specific bindings [Krzysztof]
- Updated the driver patch as per the latest bindings changes
- Added R-By tag received in V1.
- Link to v1: https://lore.kernel.org/r/20260501-shikra-cpufreq-scaling-v1-0-c78b95f53b91@oss.qualcomm.com
---
Imran Shaik (1):
dt-bindings: cpufreq: Document Qualcomm Shikra SoC EPSS
Taniya Das (1):
cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC
.../bindings/cpufreq/qcom,shikra-epss.yaml | 96 ++++++++++++++++++++++
drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++-
2 files changed, 116 insertions(+), 3 deletions(-)
---
base-commit: 0787c45ea08a13b5482e701fabc741877cf681f6
change-id: 20260430-shikra-cpufreq-scaling-aff690130063
Best regards,
--
Imran Shaik <imran.shaik@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable PCIe
From: Geert Uytterhoeven @ 2026-05-22 15:09 UTC (permalink / raw)
To: Prabhakar
Cc: Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260501105116.33452-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, 1 May 2026 at 12:51, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Enable the PCIE1 slot available on the RZ/V2N EVK.
>
> Note, the PCIE_REFCLK comes from 5L35023B versa clock generator, once the
> support for this clock generator is added, the fixed clock node can be
> removed and can be replaced with a reference to the clock generator.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: renesas: r9a09g056: Add PCIe node
From: Geert Uytterhoeven @ 2026-05-22 15:06 UTC (permalink / raw)
To: Prabhakar
Cc: Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260501105116.33452-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, 1 May 2026 at 12:51, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add PCIe node to Renesas RZ/V2N ("R9A09G056") SoC DTSI.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/2] remoteproc: qcom: pas: Add Shikra remoteproc support
From: Komal Bajaj @ 2026-05-22 14:53 UTC (permalink / raw)
To: Dmitry Baryshkov, Konrad Dybcio
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, Bibek Kumar Patro
In-Reply-To: <zirwveacipcy2wamaqntykkwhhdirw5ln35qkqs7aqrv7v4evl@qyk2tygwrbdu>
On 5/22/2026 7:48 PM, Dmitry Baryshkov wrote:
> On Fri, May 22, 2026 at 02:13:08PM +0200, Konrad Dybcio wrote:
>> On 5/19/26 5:03 PM, Komal Bajaj wrote:
>>> On 5/14/2026 12:48 AM, Dmitry Baryshkov wrote:
>>>> On Thu, May 14, 2026 at 12:17:31AM +0530, Komal Bajaj wrote:
>>>>> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>>>
>>>>> Add the CDSP, LPAICP and MPSS Peripheral Authentication Service support
>>>>> for the Qualcomm Shikra SoC.
>>>>>
>>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>>> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
>>>>> ---
>> [...]
>>
>>> Ack, I'll address it in next revision.
>>>
>>>> point you can use sc8180x_mpss_resource instead.
>>> minidump_id is required for Shikra. (decrypt_shutdown is not applicable and will be removed in the next revision.)
>>> For minidump_id, we still need to use shikra_mpss_resource instead of sc8180x_mpss_resource. <?>
>> Is there a chance the same ID would be applicable to 8180 as well,
>> just that we missed it in the past?
> Do we know, which platforms were the first to support minidump at all?
I am not entirely sure from which target minidump support was
introduced, but SC8180X does not seem to support it.
Thanks
Komal
>
>> Konrad
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: sashiko-bot @ 2026-05-22 14:53 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: robh, devicetree, conor+dt, olteanv, neil.armstrong, vkoul,
linux-phy
In-Reply-To: <20260522-x1e-csi2-phy-v7-1-79cb1280fad6@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The device tree example fails schema validation because `port@2`'s endpoint includes `data-lanes` and `clock-lanes` which are forbidden by the schema.
--
commit f15340b905d3f2f95e02027798a2eb5d4ed06bf5
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
This commit adds a new base schema for the x1e80100 MIPI CSI2 PHY devices.
It supports CPHY, DPHY, and DPHY split-mode by modeling the CSIPHY devices
as individual nodes with three distinct ports.
> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> new file mode 100644
> index 0000000000000..f434fb04447f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
[ ... ]
> + port@2:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + description: Output to CAMSS controller.
> +
> + properties:
> + endpoint:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + unevaluatedProperties: false
> + properties:
> + remote-endpoint: true
> + required:
> + - remote-endpoint
[ ... ]
> +examples:
> + - |
[ ... ]
> + port@2 {
> + reg = <2>;
> + csiphy0_out_ep: endpoint {
> + data-lanes = <3>;
> + clock-lanes = <4>;
[Severity: Low]
Will this example fail dt_binding_check schema validation?
The schema definition above for port@2's endpoint points to endpoint-base and
sets unevaluatedProperties to false, without locally defining data-lanes or
clock-lanes.
However, the example uses them here. Does the port@2 definition need a
reference to video-interfaces.yaml like the other ports, or should these
properties be removed from the example?
> + remote-endpoint = <&controller_in>;
> + };
> + };
> + };
> + };
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-x1e-csi2-phy-v7-0-79cb1280fad6@linaro.org?part=1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox