On Wed, Nov 26, 2025 at 3:35 PM Bjorn Andersson andersson@kernel.org wrote:
On Wed, Nov 26, 2025 at 01:22:19PM +0100, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski bartosz.golaszewski@linaro.org
The gpio_chip settings in this driver say the controller can't sleep but it actually uses a mutex for synchronization. This triggers the following BUG():
[ 9.233659] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281 [ 9.233665] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 554, name: (udev-worker) [ 9.233669] preempt_count: 1, expected: 0 [ 9.233673] RCU nest depth: 0, expected: 0 [ 9.233688] Tainted: [W]=WARN [ 9.233690] Hardware name: Dell Inc. Latitude 7455/0FK7MX, BIOS 2.10.1 05/20/2025 [ 9.233694] Call trace: [ 9.233696] show_stack+0x24/0x38 (C) [ 9.233709] dump_stack_lvl+0x40/0x88 [ 9.233716] dump_stack+0x18/0x24 [ 9.233722] __might_resched+0x148/0x160 [ 9.233731] __might_sleep+0x38/0x98 [ 9.233736] mutex_lock+0x30/0xd8
As far as I can see, this mutex only protects mmio accesses.
Is it preferable to mark the gpio chip can_sleep over replacing the mutex with a non-sleep lock?
I'd say let's do this as a fix and convert the driver to non-sleeping with a spinlock next cycle?
Bart
Mark the controller as sleeping.
Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver") Cc: stable@vger.kernel.org Reported-by: Val Packett val@packett.cool Closes: https://lore.kernel.org/all/98c0f185-b0e0-49ea-896c-f3972dd011ca@packett.coo... Signed-off-by: Bartosz Golaszewski bartosz.golaszewski@linaro.org
If we stick to the mutex, the patch LGTM
Reviewed-by: Bjorn Andersson andersson@kernel.org