Re: [PATCH v7 4/5] gpio: aaeon: Add GPIO driver for SRG-IMX8P MCU

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Destructive hardware initialization of GPIOs during probe
--

--- Patch [4]: [PATCH v7 4/5] gpio: aaeon: Add GPIO driver for SRG-IMX8P MCU ---
commit e6765071ae5a9056f6fe12662ec59273ff8b1ac7
Author: Thomas Perrot (Schneider Electric) <[email protected]>

gpio: aaeon: Add GPIO driver for SRG-IMX8P MCU

Add GPIO driver for the Aaeon SRG-IMX8P embedded controller. This driver
supports 7 GPO pins and 12 GPIO pins and implements state management.
During probe, all pins are reset to a known state.

> diff --git a/drivers/gpio/gpio-aaeon-mcu.c b/drivers/gpio/gpio-aaeon-mcu.c
> new file mode 100644
> index 0000000000000..a9e048c865f5c
> --- /dev/null
> +++ b/drivers/gpio/gpio-aaeon-mcu.c
[ ... ]
> +static int aaeon_mcu_gpio_probe(struct platform_device *pdev)
> +{
> +	struct aaeon_mcu_gpio *data;
[ ... ]
> +	/*
> +	 * Reset all GPIO states to a known configuration. The MCU does not
> +	 * reset GPIO state on soft reboot, only on power cycle (hard reboot).
> +	 * Without this reset, GPIOs would retain their previous state across
> +	 * reboots, which could lead to unexpected behavior.
> +	 */
> +	aaeon_mcu_gpio_reset(data, &pdev->dev);

[Severity: Medium]
Could this unconditional reset during probe abruptly disable critical system
resources like power regulators or displays that were initialized earlier by
the bootloader?

While the comment explains this is an intentional design choice to prevent
undefined behavior across soft reboots, unconditionally resetting all GPOs
to low and GPIOs to inputs in aaeon_mcu_gpio_reset() overrides any existing
hardware setup.

Does this bypass the usual GPIO subsystem convention of safely inheriting
the existing hardware state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4