Re: [PATCH 3/3] pinctrl: tegra: Add support for Tegra268

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] pinctrl: tegra: missing -1 initialization in PIN_PINGROUP_ENTRY_Y corrupts pinmux
- [Medium] pinctrl: tegra: missing hardware pins (SDMMC1, UART9) from configuration arrays
- [Medium] pinctrl: tegra: NULL pointer dereference in tegra268_pinctrl_probe()
--

commit 6edd21c4b852f6086992a569432d8b85b70c1f2d
Author: Prathamesh Shete <pshete@nvidia.com>
Subject: pinctrl: tegra: Add support for Tegra268

This commit adds the Tegra268 pinctrl driver supporting the MAIN, AON, and
UPHY pin controllers.

[Severity: High]
In the file drivers/pinctrl/tegra/pinctrl-tegra268.c, looking at the
PIN_PINGROUP_ENTRY_Y macro around line 1475, does this leave unsupported
pinconf fields like odrain_bit, ioreset_bit, and rcv_sel_bit
zero-initialized? Since omitted fields in a designated initializer default
to zero, they might pass the validity check in tegra_pinconf_reg() which
verifies if the bit is less than zero. If a device tree node attempts to
write an unsupported parameter, could this end up writing to bit 0 of the
register and silently corrupt the active pin multiplexing configuration
because mux_bit is also explicitly set to 0?

[Severity: Medium]
Also in drivers/pinctrl/tegra/pinctrl-tegra268.c, are the hardware pins for
SDMMC1, UART9, and PU0-PU7 missing from the tegra268_main_pins array around
line 275 and the tegra268_main_groups array around line 1737? The driver
defines pin ID enumerations like TEGRA_PIN_SDMMC1_CLK_PX0 and the
associated drive group helpers, but omitting them from the tracking arrays
means they will never be registered with the pinctrl core. Could this
prevent these pins from being configured and render critical peripherals
like the SDMMC1 interface unusable?

[Severity: Medium]
In the tegra268_pinctrl_probe function around line 1909 of the same file,
is it possible for device_get_match_data() to return a NULL pointer if the
platform device is manually created and bound via sysfs without a matching
device tree node? Passing a NULL soc pointer into the core
tegra_pinctrl_probe() function might lead to a kernel panic when it
unconditionally dereferences soc_data->ngroups. Would adding a validation
check before passing the pointer to the core prevent this?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261004192921.2460405-1-praagarwal@nvidia.com?part=3