On Thu, Jun 18, 2026 at 03:25:49PM +0200, Linus Walleij wrote:
> Hi Runyu,
> 
> thanks for your report!
> 
> On Thu, Jun 18, 2026 at 5:11 AM Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:
> 
> > The class of path we looked at is:
> >
> >   gpiod_direction_output_raw_commit()
> >     -> <driver>_gpio_direction_output()
> >        -> pinctrl_gpio_direction_output()
> >        -> pinctrl_get_device_gpio_range()
> >        -> mutex_lock(&pctldev->mutex)
> 
> Again that is mutex_lock(&pinctrldev_list_mutex); is it not?
> 
> If we go with my suggestion in the previous report to just
> replace this mutex with a spinlock, I think this issue will
> also be solved.
> 
> Am I right?

I'm not sure it's that simple to convert this to a spinlock. One one
hand this lock is taken around calls to mutex_lock(&pctldev->mutex), so
those could sleep and a spinlock would be wrong.

There's one other case where in addition to the nested pctldev->mutex,
we call some of the generic cleanup functions under the lock. Luckily it
looks like all of those should be safe to call under a spinlock since
they don't sleep themselves from what I can tell.

Maybe the locking order of pinctrldev_list_mutex vs. pctldev->mutex can
be changed to avoid that first issue?

Thierry