Re: [PATCH v4 8/8] arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Adding `compatible = "fixed-partitions"` to the `partitions-boot1` node causes the block layer OF partition parser to process the `nvmem-layout` child node as a partition. Since `nvmem-layout` lacks a `reg` property, `of_get_property(np, "reg", &len)` in `block/partitions/of.c` returns NULL and leaves the stack variable `len` uninitialized. This leads to either a boot-time kernel panic (if the uninitialized `len` happens to satisfy `len / sizeof(*reg) == a_cells + s_cells`, causing an unconditional NULL pointer dereference of `reg` in `of_read_number()`) or an `-EINVAL` error that aborts partition scanning for the entire `mmcblk0boot0` block device.
--

commit 1fb34b213f52de7d901295d011ead6f3136f8d92
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>

arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses

This commit adds NVMEM cell definitions for WiFi and Bluetooth MAC addresses
to the eMMC boot1 partition on Arduino Uno-Q. It modifies the SDHC1 node to
declare a fixed-partitions block with an nvmem-layout.

> diff --git a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
> index bf088fa9807f0..128c7a7e76b5b 100644
> --- a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
> +++ b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
> @@ -409,7 +409,40 @@ &sdhc_1 {
[ ... ]
> +	card@0 {
> +		compatible = "mmc-card";
> +		reg = <0>;
> +
> +		partitions-boot1 {
> +			compatible = "fixed-partitions";
> +
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			nvmem-layout {

[Severity: High]
Does adding compatible = "fixed-partitions" here cause the block layer
OF partition parser to process the nvmem-layout child node as a partition?

Since nvmem-layout lacks a reg property, this appears to trigger an issue
in block/partitions/of.c where of_get_property(np, "reg", &len) returns
NULL and leaves the stack variable len uninitialized.

Depending on the uninitialized stack value, couldn't this cause either a
boot-time kernel panic due to a NULL pointer dereference in
of_read_number(), or an -EINVAL error that aborts partition scanning for
the entire mmcblk0boot0 block device?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-block-as-nvmem-v4-0-45712e6b22c6@oss.qualcomm.com?part=8