Question: pxa GPIO direction callbacks and pinctrl_gpio_direction_*()

[Runyu Xiao]

Hi,

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

The driver registers a normal MMIO gpio_chip without setting can_sleep.
On PXA variants where pxa_gpio_has_pinctrl() is true,
pxa_gpio_direction_input() and pxa_gpio_direction_output() first call
pinctrl_gpio_direction_input/output(). That 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 pxa_init_gpio_chip(), pxa_gpio_has_pinctrl(), 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 pxa_gpio_direction_output(), pinctrl_gpio_direction_output()
and pinctrl_get_device_gpio_range() on the stack.

The part I would like to confirm is the intended fix. Commit a770d946371e
("gpio: pxa: add pin control gpio direction and request") says that when a
pinctrl driver is available, pinctrl should control the GPIO direction so
that only one driver controls the direction. Because of that, simply
removing the pinctrl_gpio_direction_*() calls from the GPIO direction
callbacks may be too broad even though the GPIO driver also updates GPDR
itself.

Would the preferred fix be to keep the pinctrl direction path and mark the
chip as sleeping, or is it acceptable to keep direction changes on the
existing GPDR path and remove the pinctrl direction round-trip? If there is
another preferred way to preserve the PXA pinctrl contract without
advertising the direction callbacks as atomic-safe, I can prepare a patch
in that direction.

Thanks,
Runyu