Question: mvebu GPIO can_sleep and pinctrl direction helpers

[Runyu Xiao]

Hi,

I found a possible sleep-in-atomic problem in the MVEBU GPIO direction
callbacks and would like to check the intended gpio_chip contract before
sending a patch.

mvebu_gpio_probe() currently registers the GPIO controller with
mvchip->chip.can_sleep = false. At the same time,
mvebu_gpio_direction_input() and mvebu_gpio_direction_output() call
pinctrl_gpio_direction_input/output(), and that helper path can reach the
pinctrl core and take pctldev->mutex.

This was found by our static analysis tool and then confirmed by manual
review of mvebu_gpio_probe() and the direction callbacks. I also used a
directed runtime validation that preserves the non-sleeping gpio_chip
registration and drives the direction callback through the pinctrl
direction helper. Lockdep reports a sleep-in-atomic warning with
mvebu_gpio_direction_output(), pinctrl_gpio_direction_output() and
pinctrl_get_device_gpio_range() on the stack.

Before sending a fix, I would like to confirm which contract is preferred
for this driver. Should the controller be marked can_sleep because its
direction callbacks may sleep, or would that be too broad for an otherwise
MMIO-backed GPIO controller whose get/set paths are fast register accesses?

If marking the whole chip as sleeping is too broad, would it be preferable
to avoid or restructure the pinctrl direction round-trip instead?

Thanks,
Runyu