arm/arm64: dts: adi: replace adi,port-sizes with adi,npins

[jiez]

Replace the per-port size array adi,port-sizes with a single total pin count adi,npins. Update the pinctrl driver accordingly.

This is mainly for aligning with u-boot.

PR Type

• Bug fix (a change that fixes an issue)
• New feature (a change that adds new functionality)
• Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• I have conducted a self-review of my own code changes
• I have compiled my changes, including the documentation
• I have tested the changes only on SC598 SOM EZKIT board
• I have updated the documentation outside this repo accordingly
• I have provided links for the relevant upstream lore

[CalebEthridgeADI]

I believe this needs a rebase. Also this commit should be split into two commits, one for arm and another for arm64

[jiez]

It's now rebased onto adsp-6.18.31-y.

Split cannot be done easily unless we give up bisectability or make this PR more complicated just for split it.

[github-actions]

LLM review

This series replaces the per-port pin-count array adi,port-sizes with a single
total-pin-count property adi,npins in the ADSP pinctrl driver and four DTS files.

run: 28013114231

c18e4f49605d - arm/arm64: dts: adi: replace adi,port-sizes with adi,npins

Missing zero guard — potential heap overflow:

The old adi,port-sizes code path contained an explicit check for an empty array:

if (num_ports == 0) {
    dev_err(dev, "pinctrl missing `adi,port-sizes` port size definition\n");
    return -ENOENT;
}

The replacement code reads adi,npins into a u32 successfully even when the DT
contains adi,npins = <0>. In that case DIV_ROUND_UP(0, 16) = 0 sets
num_ports = 0 (type int), and the loop below runs with undefined behaviour:

for (i = 0; i < num_ports - 1; ++i)   /* i: unsigned int, num_ports-1 = -1 */
    adsp_pinctrl->pin_counts[i] = ADSP_PORT_NGPIO;

Because i is unsigned int, the comparison promotes the int value -1 to
UINT_MAX, causing the loop to run ~4 billion iterations and overflow the heap
allocation. The equivalent protection from the old code was not carried forward.

A fixup that adds if (!pin_total) return -EINVAL; after the of_property_read_u32
call restores the guard.

Verified by cross-compiling drivers/pinctrl/adi/pinctrl-adsp.o for gcc_aarch64
(sc598-som-ezkit_defconfig) and gcc_arm (sc594-som-ezlite_defconfig) — both
build cleanly before and after the fixup. Pin-count arithmetic for all four SoC
families was confirmed correct (sc57x: 5×16+12=92, sc58x: 6×16+6=102, sc59x: 8×16+7=135).

CI warnings

The three CI warnings (coccicheck sizeof-to-pointer at line 761, gcc_fanalyzer
NULL-dereference at line 778, smatch unsigned-<=0 at line 223) are all pre-existing
in the baseline commit 5ca414293905 and are not introduced or worsened by this series.

Suggested patches

Apply the suggested patches with:

cd path/to/repository
export GITHUB_TOKEN=ghp_***
apply-patches --repo=analogdevicesinc/linux 28013114231

Install instructions

The following one-liner installs the script if not present already:

curl -fSsL "https://raw.githubusercontent.com/analogdevicesinc/doctools/refs/heads/main/ci/scripts/apply-patches.sh" \
     -o ~/.local/bin/apply-patches.sh && \
  grep -q "/apply-patches.sh" ~/.bashrc || echo "source ~/.local/bin/apply-patches.sh" >> $_ ; . $_

More information at AI Usage.

[jiez]

LLM review

This series replaces the per-port pin-count array adi,port-sizes with a single total-pin-count property adi,npins in the ADSP pinctrl driver and four DTS files.

run: 28013114231

c18e4f49605d - arm/arm64: dts: adi: replace adi,port-sizes with adi,npins

Missing zero guard — potential heap overflow:

The old adi,port-sizes code path contained an explicit check for an empty array:

if (num_ports == 0) {
    dev_err(dev, "pinctrl missing `adi,port-sizes` port size definition\n");
    return -ENOENT;
}

The replacement code reads adi,npins into a u32 successfully even when the DT contains adi,npins = <0>. In that case DIV_ROUND_UP(0, 16) = 0 sets num_ports = 0 (type int), and the loop below runs with undefined behaviour:

for (i = 0; i < num_ports - 1; ++i)   /* i: unsigned int, num_ports-1 = -1 */
    adsp_pinctrl->pin_counts[i] = ADSP_PORT_NGPIO;

Because i is unsigned int, the comparison promotes the int value -1 to UINT_MAX, causing the loop to run ~4 billion iterations and overflow the heap allocation. The equivalent protection from the old code was not carried forward.

A fixup that adds if (!pin_total) return -EINVAL; after the of_property_read_u32 call restores the guard.

Verified by cross-compiling drivers/pinctrl/adi/pinctrl-adsp.o for gcc_aarch64 (sc598-som-ezkit_defconfig) and gcc_arm (sc594-som-ezlite_defconfig) — both build cleanly before and after the fixup. Pin-count arithmetic for all four SoC families was confirmed correct (sc57x: 5×16+12=92, sc58x: 6×16+6=102, sc59x: 8×16+7=135).

CI warnings

The three CI warnings (coccicheck sizeof-to-pointer at line 761, gcc_fanalyzer NULL-dereference at line 778, smatch unsigned-<=0 at line 223) are all pre-existing in the baseline commit 5ca414293905 and are not introduced or worsened by this series.

Suggested patches

Apply the suggested patches with:

cd path/to/repository
export GITHUB_TOKEN=ghp_***
apply-patches --repo=analogdevicesinc/linux 28013114231

Install instructions

The guard is restored.

[sipraga]

Why a vendor property when there is the standard ngpios per dtchema/schemas/gpio/gpio.yaml?

In any case, maybe take a look at #3397 where I am nearly finished replacing these drivers and their bindings. That will probably supersede these changes anyway.

[sipraga]

Why a vendor property when there is the standard ngpios per dtchema/schemas/gpio/gpio.yaml?

In any case, maybe take a look at #3397 where I am nearly finished replacing these drivers and their bindings. That will probably supersede these changes anyway.

Oh right, this is pinctrl. Ignore my question then. 2nd part still applies though.

[jiez]

Why a vendor property when there is the standard ngpios per dtchema/schemas/gpio/gpio.yaml?
In any case, maybe take a look at #3397 where I am nearly finished replacing these drivers and their bindings. That will probably supersede these changes anyway.

Oh right, this is pinctrl. Ignore my question then. 2nd part still applies though.

OK. We can keep this PR open until your changes are merged.