Re: [PATCH v10 3/3] gpio: gpio-ltc4283: Add support for the LTC4283 Swap Controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Unchecked NULL pointer dereference in ltc4283_init_valid_mask() leads to guaranteed kernel panic on probe.
- [Medium] Hardware glitch in ltc4283_gpio_direction_output() caused by setting pin direction before the output value.
--

commit b21abd683d70453a9fa63ff159113ec69ce2380a
Author: Nuno Sá <nuno.sa@analog.com>

gpio: gpio-ltc4283: Add support for the LTC4283 Swap Controller

This commit introduces a driver for the GPIO functionality found on the
LTC4283 Negative Voltage Hot Swap Controller. It provides support for up to
8 pins configured via an auxiliary bus.

> diff --git a/drivers/gpio/gpio-ltc4283.c b/drivers/gpio/gpio-ltc4283.c
> new file mode 100644
> index 000000000000..6609443c5d62
> --- /dev/null
> +++ b/drivers/gpio/gpio-ltc4283.c

[ ... ]

> +static int ltc4283_gpio_direction_output(struct gpio_chip *gc, unsigned int off, int val)
> +{
> +	struct ltc4283_gpio *st = gpiochip_get_data(gc);
> +	int ret;
> +
> +	ret = ltc4283_gpio_direction_set(st, off, false);
> +	if (ret)
> +		return ret;
> +
> +	return __ltc4283_gpio_set_value(st, off, val);
> +}

Will this cause a transient hardware glitch on the output pin?

If ltc4283_gpio_direction_set() configures the pin as an output before
__ltc4283_gpio_set_value() establishes the intended logic level, the pin
might temporarily drive a stale value from the output data register.

Since the registers are accessed via an I2C regmap, there is a measurable
delay between these two operations. Would it be safer to reverse the order
and set the output value before changing the pin direction?

[ ... ]

> +static int ltc4283_init_valid_mask(struct gpio_chip *gc, unsigned long *valid_mask,
> +				   unsigned int ngpios)
> +{
> +	unsigned long *mask = dev_get_platdata(gc->parent);
> +
> +	bitmap_copy(valid_mask, mask, ngpios);
> +	return 0;
> +}

Will this cause a NULL pointer dereference during device probe?

If the parent driver creates the auxiliary device without setting
platform_data, dev_get_platdata() returns NULL. Passing this directly to
bitmap_copy() as the source argument:

include/linux/bitmap.h:bitmap_copy()
    if (small_const_nbits(nbits))
        *dst = *src;

will dereference the NULL pointer. Should there be a check to verify mask
is valid before copying it?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260428-ltc4283-support-v10-0-4f26f46491c3@analog.com?part=3