Re: [PATCH v8 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:
- [High] Unconditionally resetting all GPIO and GPO pin states during probe=
 breaks bootloader handoff and can cause severe hardware glitches.
--

--- Patch [4]: [PATCH v8 4/5] gpio: aaeon: Add GPIO driver for SRG-IMX8P MC=
U ---
commit 039db3f85a7d9e8ca0a6aa50fb1e051d88e24a0b
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 (General Purpose Output) pins and 12 GPIO pins
that can be configured as inputs or outputs.

> 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 void aaeon_mcu_gpio_reset(struct aaeon_mcu_gpio *data, struct dev=
ice *dev)
> +{
> +	unsigned int i;
> +	int ret;
> +
> +	/* Reset all GPOs */
> +	for (i =3D 0; i < MAX_GPOS; i++) {
> +		ret =3D aaeon_mcu_gpo_set_cmd(data, i, 0);
> +		if (ret < 0)
> +			dev_warn(dev, "Failed to reset GPO %u state: %d\n", i, ret);
> +		clear_bit(i, data->dir_in);
> +	}
> +
> +	/* Reset all GPIOs */
> +	for (i =3D MAX_GPOS; i < MAX_GPOS + MAX_GPIOS; i++) {
> +		ret =3D aaeon_mcu_gpio_config_input_cmd(data, i);
> +		if (ret < 0)
> +			dev_warn(dev, "Failed to reset GPIO %u state: %d\n", i, ret);
> +		set_bit(i, data->dir_in);
> +	}
> +}
[ ... ]
> +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: High]
Does this unconditional reset during probe interfere with bootloader handof=
f?

If the bootloader has set a GPO high or configured a GPIO as an output to
drive a critical component (like a voltage regulator or display backlight),
forcing it low or to an input state could immediately cut power or cause a
hardware glitch.

Could the driver read the hardware registers to populate its internal state
instead of wiping the physical state during initialization?

> +
> +	return devm_gpiochip_add_data(&pdev->dev, &data->gc, data);
> +}

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260731-dev-b4-aae=
[email protected]?part=3D4