Hi Pranav,
On 2026-07-29T08:12:14, Pranav Sanwal <[email protected]> wrote:
> gpio: delay: free wrapped real GPIOs on remove
>
> gpio_delay_probe() requests the real GPIOs it wraps via
> gpio_request_by_name_nodev(), which strdup()s a label into the real
> GPIO device's own uc_priv->name[] array. The driver had no .remove
> hook, so those requests, and their strdup'd labels, were never
> released when the gpio-delay device was torn down.
>
> Add gpio_delay_remove() to free each wrapped real GPIO. Guard each
> free with device_active() on the real GPIO's device: generic DM
> teardown (e.g. dm_leak_check_end()'s uclass-by-uclass destroy) does
> not guarantee a consumer is removed before the provider it wraps, so
> the real GPIO device may already be inactive with its uclass_priv
> freed by the time this runs.
>
> Fixes: c866f2f197e2 ("gpio: Add GPIO delay driver")
> Signed-off-by: Pranav Sanwal <[email protected]>
>
> drivers/gpio/gpio-delay.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> diff --git a/drivers/gpio/gpio-delay.c b/drivers/gpio/gpio-delay.c
> @@ -90,6 +90,20 @@ static int gpio_delay_xlate(struct udevice *dev, struct
> gpio_desc *desc,
> +static int gpio_delay_remove(struct udevice *dev)
> +{
> + struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> + struct gpio_delay_priv *priv = dev_get_priv(dev);
> + int i;
> +
> + for (i = 0; i < uc_priv->gpio_count; i++) {
> + if (device_active(priv->descs[i].real_gpio.dev))
> + dm_gpio_free(dev, &priv->descs[i].real_gpio);
> + }
> +
> + return 0;
> +}
Please can you add a short in-code comment explaining why the
device_active() guard is needed - a future reader touching this loop
won't have the commit message to hand and the guard otherwise looks
superfluous.
One related question: gpio_delay_probe() bails out on the first failed
gpio_request_by_name_nodev() without freeing the descs it has already
populated, so any partial-probe leak is not covered by this .remove
hook. That's pre-existing rather than something to fix here, but if
you're respinning anyway it would be worth cleaning up in probe by
calling the same free path on error.
Reviewed-by: Simon Glass <[email protected]>
