| Message ID | 20250121135833.3769310-1-niklas.soderlund+renesas@ragnatech.se |
|---|---|
| State | New |
| Headers | show |
| Series | gpio: rcar: Use raw_spinlock to protect register access | expand |
Hi Niklas, On Tue, Jan 21, 2025 at 2:59 PM Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> wrote: > Use raw_spinlock in order to fix spurious messages about invalid context > when spinlock debugging is enabled. The lock is only used to serialize > register access. > > [ 4.239592] ============================= > [ 4.239595] [ BUG: Invalid wait context ] [...] > [ 4.426274] lock_acquire+0x1c4/0x33c > [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 > [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 > [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Thanks for your patch! This indeed gets rid of the annoying messages on various R-Car boards. Unfortunately I now start seeing other scary messages during resume from s2idle/s2ram. On marzen (R-Car H1): ============================= [ BUG: Invalid wait context ] 6.13.0-marzen-08235-gb3d2b6c82b8c #193 Not tainted ----------------------------- swapper/0/0 is trying to lock: c2d3c994 (&dev->event_lock){..-.}-{3:3}, at: input_event+0x38/0x60 other info that might help us debug this: context-{2:2} no locks held by swapper/0/0. stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-marzen-08235-gb3d2b6c82b8c #193 Hardware name: Generic R8A7779 (Flattened Device Tree) Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xb0 dump_stack_lvl from __lock_acquire+0x38c/0x1698 __lock_acquire from lock_acquire+0x29c/0x338 lock_acquire from _raw_spin_lock_irqsave+0x50/0x64 _raw_spin_lock_irqsave from input_event+0x38/0x60 input_event from gpio_keys_irq_timer+0x30/0x50 gpio_keys_irq_timer from __hrtimer_run_queues+0x208/0x370 __hrtimer_run_queues from hrtimer_interrupt+0xbc/0x1f8 hrtimer_interrupt from twd_handler+0x30/0x3c twd_handler from handle_percpu_devid_irq+0x58/0xfc handle_percpu_devid_irq from handle_irq_desc+0x68/0x80 handle_irq_desc from gic_handle_irq+0x74/0x84 gic_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from __irq_svc+0x8c/0xb8 Exception stack(0xc0e01f30 to 0xc0e01f78) 1f20: ffffffff 00000001 2b229000 00000001 1f40: c0e0be40 c0173ae0 c0e09090 c0e0be40 c0e09054 c0e09090 ffffffff 00000000 1f60: 00000000 c0e01f80 c08d13b8 c08d13c0 200f0013 ffffffff __irq_svc from cpu_idle_poll+0xc4/0x130 cpu_idle_poll from do_idle+0xb0/0x288 do_idle from cpu_startup_entry+0x28/0x2c cpu_startup_entry from rest_init+0x150/0x178 rest_init from start_kernel+0x544/0x5d8 On Salvator-X(S) (R-Car Gen3) and Gray/White Hawk (R-Car Gen4): ============================= WARNING: suspicious RCU usage 6.13.0-rcar3-08235-gb3d2b6c82b8c #174 Tainted: G W ----------------------------- drivers/net/phy/phy_device.c:1970 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 5 locks held by s2idle/1070: #0: ffffff84c6c173f0 (sb_writers#5){.+.+}-{0:0}, at: file_start_write.isra.0+0x24/0x30 #1: ffffff84cdbf3888 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xf8/0x180 #2: ffffff84c1007168 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x180 #3: ffffffc0812d51e8 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x84/0x248 #4: ffffff84c211a8f8 (&dev->mutex){....}-{4:4}, at: device_resume+0xb4/0x1c4 stack backtrace: CPU: 1 UID: 0 PID: 1070 Comm: s2idle Tainted: G W 6.13.0-rcar3-08235-gb3d2b6c82b8c #174 Tainted: [W]=WARN Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x78/0xa8 dump_stack+0x14/0x1c lockdep_rcu_suspicious+0x138/0x184 phy_detach+0xc0/0x188 phy_disconnect+0x44/0x50 ravb_close+0x7c/0x1b8 ravb_resume+0xb0/0x130 dpm_run_callback+0x5c/0xc8 device_resume+0xf0/0x1c4 dpm_resume+0x150/0x168 dpm_resume_end+0x14/0x28 suspend_devices_and_enter+0x150/0x59c pm_suspend+0x214/0x248 state_store+0xa8/0xe8 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x138/0x180 vfs_write+0x148/0x1b4 ksys_write+0x78/0xe0 __arm64_sys_write+0x14/0x1c invoke_syscall+0x68/0xf0 el0_svc_common.constprop.0+0xb0/0xcc do_el0_svc+0x18/0x20 el0_svc+0x38/0x90 el0t_64_sync_handler+0x80/0x130 el0t_64_sync+0x158/0x15c Probably they were just masked by the other issue before? Gr{oetje,eeting}s, Geert
Hi, Geert, Niklas, On 21.01.2025 16:49, Geert Uytterhoeven wrote: > Hi Niklas, > > On Tue, Jan 21, 2025 at 2:59 PM Niklas Söderlund > <niklas.soderlund+renesas@ragnatech.se> wrote: >> Use raw_spinlock in order to fix spurious messages about invalid context >> when spinlock debugging is enabled. The lock is only used to serialize >> register access. >> >> [ 4.239592] ============================= >> [ 4.239595] [ BUG: Invalid wait context ] > > [...] > >> [ 4.426274] lock_acquire+0x1c4/0x33c >> [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 >> [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 >> [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 > >> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > Thanks for your patch! > This indeed gets rid of the annoying messages on various R-Car boards. > Unfortunately I now start seeing other scary messages during resume > from s2idle/s2ram. > > On marzen (R-Car H1): > > ============================= > [ BUG: Invalid wait context ] > 6.13.0-marzen-08235-gb3d2b6c82b8c #193 Not tainted > ----------------------------- > swapper/0/0 is trying to lock: > c2d3c994 (&dev->event_lock){..-.}-{3:3}, at: input_event+0x38/0x60 > other info that might help us debug this: > context-{2:2} > no locks held by swapper/0/0. > stack backtrace: > CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted > 6.13.0-marzen-08235-gb3d2b6c82b8c #193 > Hardware name: Generic R8A7779 (Flattened Device Tree) > Call trace: > unwind_backtrace from show_stack+0x10/0x14 > show_stack from dump_stack_lvl+0x7c/0xb0 > dump_stack_lvl from __lock_acquire+0x38c/0x1698 > __lock_acquire from lock_acquire+0x29c/0x338 > lock_acquire from _raw_spin_lock_irqsave+0x50/0x64 > _raw_spin_lock_irqsave from input_event+0x38/0x60 > input_event from gpio_keys_irq_timer+0x30/0x50 > gpio_keys_irq_timer from __hrtimer_run_queues+0x208/0x370 > __hrtimer_run_queues from hrtimer_interrupt+0xbc/0x1f8 > hrtimer_interrupt from twd_handler+0x30/0x3c > twd_handler from handle_percpu_devid_irq+0x58/0xfc > handle_percpu_devid_irq from handle_irq_desc+0x68/0x80 > handle_irq_desc from gic_handle_irq+0x74/0x84 > gic_handle_irq from generic_handle_arch_irq+0x28/0x3c > generic_handle_arch_irq from __irq_svc+0x8c/0xb8 > Exception stack(0xc0e01f30 to 0xc0e01f78) > 1f20: ffffffff 00000001 > 2b229000 00000001 > 1f40: c0e0be40 c0173ae0 c0e09090 c0e0be40 c0e09054 c0e09090 > ffffffff 00000000 > 1f60: 00000000 c0e01f80 c08d13b8 c08d13c0 200f0013 ffffffff > __irq_svc from cpu_idle_poll+0xc4/0x130 > cpu_idle_poll from do_idle+0xb0/0x288 > do_idle from cpu_startup_entry+0x28/0x2c > cpu_startup_entry from rest_init+0x150/0x178 > rest_init from start_kernel+0x544/0x5d8 > > On Salvator-X(S) (R-Car Gen3) and Gray/White Hawk (R-Car Gen4): > > ============================= > WARNING: suspicious RCU usage > 6.13.0-rcar3-08235-gb3d2b6c82b8c #174 Tainted: G W > ----------------------------- > drivers/net/phy/phy_device.c:1970 suspicious > rcu_dereference_protected() usage! > > other info that might help us debug this: > > rcu_scheduler_active = 2, debug_locks = 1 > 5 locks held by s2idle/1070: > #0: ffffff84c6c173f0 (sb_writers#5){.+.+}-{0:0}, at: > file_start_write.isra.0+0x24/0x30 > #1: ffffff84cdbf3888 (&of->mutex#2){+.+.}-{4:4}, at: > kernfs_fop_write_iter+0xf8/0x180 > #2: ffffff84c1007168 (kn->active#64){.+.+}-{0:0}, at: > kernfs_fop_write_iter+0x100/0x180 > #3: ffffffc0812d51e8 (system_transition_mutex){+.+.}-{4:4}, > at: pm_suspend+0x84/0x248 > #4: ffffff84c211a8f8 (&dev->mutex){....}-{4:4}, at: > device_resume+0xb4/0x1c4 > > stack backtrace: > CPU: 1 UID: 0 PID: 1070 Comm: s2idle Tainted: G W > 6.13.0-rcar3-08235-gb3d2b6c82b8c #174 > Tainted: [W]=WARN > Hardware name: Renesas Salvator-X 2nd version board based on > r8a77951 (DT) > Call trace: > show_stack+0x14/0x1c (C) > dump_stack_lvl+0x78/0xa8 > dump_stack+0x14/0x1c > lockdep_rcu_suspicious+0x138/0x184 > phy_detach+0xc0/0x188 > phy_disconnect+0x44/0x50 > ravb_close+0x7c/0x1b8 > ravb_resume+0xb0/0x130 > dpm_run_callback+0x5c/0xc8 > device_resume+0xf0/0x1c4 > dpm_resume+0x150/0x168 > dpm_resume_end+0x14/0x28 > suspend_devices_and_enter+0x150/0x59c > pm_suspend+0x214/0x248 > state_store+0xa8/0xe8 > kobj_attr_store+0x14/0x24 > sysfs_kf_write+0x48/0x60 > kernfs_fop_write_iter+0x138/0x180 > vfs_write+0x148/0x1b4 > ksys_write+0x78/0xe0 > __arm64_sys_write+0x14/0x1c > invoke_syscall+0x68/0xf0 > el0_svc_common.constprop.0+0xb0/0xcc > do_el0_svc+0x18/0x20 > el0_svc+0x38/0x90 > el0t_64_sync_handler+0x80/0x130 > el0t_64_sync+0x158/0x15c The ravb issue is under discussion here: https://lore.kernel.org/all/20250120141926.1290763-1-kory.maincent@bootlin.com Thank you, Claudiu > > Probably they were just masked by the other issue before? > > Gr{oetje,eeting}s, > > Geert >
Hi Geert, On 2025-01-21 15:49:59 +0100, Geert Uytterhoeven wrote: > Hi Niklas, > > On Tue, Jan 21, 2025 at 2:59 PM Niklas Söderlund > <niklas.soderlund+renesas@ragnatech.se> wrote: > > Use raw_spinlock in order to fix spurious messages about invalid context > > when spinlock debugging is enabled. The lock is only used to serialize > > register access. > > > > [ 4.239592] ============================= > > [ 4.239595] [ BUG: Invalid wait context ] > > [...] > > > [ 4.426274] lock_acquire+0x1c4/0x33c > > [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 > > [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 > > [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > Thanks for your patch! > This indeed gets rid of the annoying messages on various R-Car boards. > Unfortunately I now start seeing other scary messages during resume > from s2idle/s2ram. I think this might be symtom of issues in those drivers too. As Claudiu points out the issue in RAVB was discussed and fixed by patch [1]. With this and patch and [1] applied I no longer see a splat when resuming on M3N using WoL. I still think this patch is correct, but of course the bug on Marzen should be fixed, but that is unrelated to this patch. Would you agree? 1.[PATCH net 1/2] net: ravb: Fix missing rtnl lock in suspend path > > On marzen (R-Car H1): > > ============================= > [ BUG: Invalid wait context ] > 6.13.0-marzen-08235-gb3d2b6c82b8c #193 Not tainted > ----------------------------- > swapper/0/0 is trying to lock: > c2d3c994 (&dev->event_lock){..-.}-{3:3}, at: input_event+0x38/0x60 > other info that might help us debug this: > context-{2:2} > no locks held by swapper/0/0. > stack backtrace: > CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted > 6.13.0-marzen-08235-gb3d2b6c82b8c #193 > Hardware name: Generic R8A7779 (Flattened Device Tree) > Call trace: > unwind_backtrace from show_stack+0x10/0x14 > show_stack from dump_stack_lvl+0x7c/0xb0 > dump_stack_lvl from __lock_acquire+0x38c/0x1698 > __lock_acquire from lock_acquire+0x29c/0x338 > lock_acquire from _raw_spin_lock_irqsave+0x50/0x64 > _raw_spin_lock_irqsave from input_event+0x38/0x60 > input_event from gpio_keys_irq_timer+0x30/0x50 > gpio_keys_irq_timer from __hrtimer_run_queues+0x208/0x370 > __hrtimer_run_queues from hrtimer_interrupt+0xbc/0x1f8 > hrtimer_interrupt from twd_handler+0x30/0x3c > twd_handler from handle_percpu_devid_irq+0x58/0xfc > handle_percpu_devid_irq from handle_irq_desc+0x68/0x80 > handle_irq_desc from gic_handle_irq+0x74/0x84 > gic_handle_irq from generic_handle_arch_irq+0x28/0x3c > generic_handle_arch_irq from __irq_svc+0x8c/0xb8 > Exception stack(0xc0e01f30 to 0xc0e01f78) > 1f20: ffffffff 00000001 > 2b229000 00000001 > 1f40: c0e0be40 c0173ae0 c0e09090 c0e0be40 c0e09054 c0e09090 > ffffffff 00000000 > 1f60: 00000000 c0e01f80 c08d13b8 c08d13c0 200f0013 ffffffff > __irq_svc from cpu_idle_poll+0xc4/0x130 > cpu_idle_poll from do_idle+0xb0/0x288 > do_idle from cpu_startup_entry+0x28/0x2c > cpu_startup_entry from rest_init+0x150/0x178 > rest_init from start_kernel+0x544/0x5d8 > > On Salvator-X(S) (R-Car Gen3) and Gray/White Hawk (R-Car Gen4): > > ============================= > WARNING: suspicious RCU usage > 6.13.0-rcar3-08235-gb3d2b6c82b8c #174 Tainted: G W > ----------------------------- > drivers/net/phy/phy_device.c:1970 suspicious > rcu_dereference_protected() usage! > > other info that might help us debug this: > > rcu_scheduler_active = 2, debug_locks = 1 > 5 locks held by s2idle/1070: > #0: ffffff84c6c173f0 (sb_writers#5){.+.+}-{0:0}, at: > file_start_write.isra.0+0x24/0x30 > #1: ffffff84cdbf3888 (&of->mutex#2){+.+.}-{4:4}, at: > kernfs_fop_write_iter+0xf8/0x180 > #2: ffffff84c1007168 (kn->active#64){.+.+}-{0:0}, at: > kernfs_fop_write_iter+0x100/0x180 > #3: ffffffc0812d51e8 (system_transition_mutex){+.+.}-{4:4}, > at: pm_suspend+0x84/0x248 > #4: ffffff84c211a8f8 (&dev->mutex){....}-{4:4}, at: > device_resume+0xb4/0x1c4 > > stack backtrace: > CPU: 1 UID: 0 PID: 1070 Comm: s2idle Tainted: G W > 6.13.0-rcar3-08235-gb3d2b6c82b8c #174 > Tainted: [W]=WARN > Hardware name: Renesas Salvator-X 2nd version board based on > r8a77951 (DT) > Call trace: > show_stack+0x14/0x1c (C) > dump_stack_lvl+0x78/0xa8 > dump_stack+0x14/0x1c > lockdep_rcu_suspicious+0x138/0x184 > phy_detach+0xc0/0x188 > phy_disconnect+0x44/0x50 > ravb_close+0x7c/0x1b8 > ravb_resume+0xb0/0x130 > dpm_run_callback+0x5c/0xc8 > device_resume+0xf0/0x1c4 > dpm_resume+0x150/0x168 > dpm_resume_end+0x14/0x28 > suspend_devices_and_enter+0x150/0x59c > pm_suspend+0x214/0x248 > state_store+0xa8/0xe8 > kobj_attr_store+0x14/0x24 > sysfs_kf_write+0x48/0x60 > kernfs_fop_write_iter+0x138/0x180 > vfs_write+0x148/0x1b4 > ksys_write+0x78/0xe0 > __arm64_sys_write+0x14/0x1c > invoke_syscall+0x68/0xf0 > el0_svc_common.constprop.0+0xb0/0xcc > do_el0_svc+0x18/0x20 > el0_svc+0x38/0x90 > el0t_64_sync_handler+0x80/0x130 > el0t_64_sync+0x158/0x15c > > Probably they were just masked by the other issue before? > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi Niklas, On Wed, 22 Jan 2025 at 18:27, Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> wrote: > On 2025-01-21 15:49:59 +0100, Geert Uytterhoeven wrote: > > On Tue, Jan 21, 2025 at 2:59 PM Niklas Söderlund > > <niklas.soderlund+renesas@ragnatech.se> wrote: > > > Use raw_spinlock in order to fix spurious messages about invalid context > > > when spinlock debugging is enabled. The lock is only used to serialize > > > register access. > > > > > > [ 4.239592] ============================= > > > [ 4.239595] [ BUG: Invalid wait context ] > > > > [...] > > > > > [ 4.426274] lock_acquire+0x1c4/0x33c > > > [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 > > > [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 > > > [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 > > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > > > Thanks for your patch! > > This indeed gets rid of the annoying messages on various R-Car boards. > > Unfortunately I now start seeing other scary messages during resume > > from s2idle/s2ram. > > I think this might be symtom of issues in those drivers too. As Claudiu > points out the issue in RAVB was discussed and fixed by patch [1]. > > With this and patch and [1] applied I no longer see a splat when > resuming on M3N using WoL. > > I still think this patch is correct, but of course the bug on Marzen > should be fixed, but that is unrelated to this patch. Would you agree? Yes, I think we should proceed with this patch. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> > 1.[PATCH net 1/2] net: ravb: Fix missing rtnl lock in suspend path Gr{oetje,eeting}s, Geert
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> On Tue, 21 Jan 2025 14:58:33 +0100, Niklas Söderlund wrote: > Use raw_spinlock in order to fix spurious messages about invalid context > when spinlock debugging is enabled. The lock is only used to serialize > register access. > > [ 4.239592] ============================= > [ 4.239595] [ BUG: Invalid wait context ] > [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted > [ 4.239603] ----------------------------- > [ 4.239606] kworker/u8:5/76 is trying to lock: > [ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164 > [ 4.239641] other info that might help us debug this: > [ 4.239643] context-{5:5} > [ 4.239646] 5 locks held by kworker/u8:5/76: > [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c > [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value. > [ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c > [ 4.254109] #2: ffff00000920c8f8 > [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value. > [ 4.264803] (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc > [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690 > [ 4.264840] #4: > [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value. > [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690 > [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz > [ 4.304082] stack backtrace: > [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 > [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) > [ 4.304097] Workqueue: async async_run_entry_fn > [ 4.304106] Call trace: > [ 4.304110] show_stack+0x14/0x20 (C) > [ 4.304122] dump_stack_lvl+0x6c/0x90 > [ 4.304131] dump_stack+0x14/0x1c > [ 4.304138] __lock_acquire+0xdfc/0x1584 > [ 4.426274] lock_acquire+0x1c4/0x33c > [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 > [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 > [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 > [ 4.444422] __irq_set_trigger+0x5c/0x178 > [ 4.448435] __setup_irq+0x2e4/0x690 > [ 4.452012] request_threaded_irq+0xc4/0x190 > [ 4.456285] devm_request_threaded_irq+0x7c/0xf4 > [ 4.459398] ata1: link resume succeeded after 1 retries > [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0 > [ 4.470660] mmc_start_host+0x50/0xac > [ 4.474327] mmc_add_host+0x80/0xe4 > [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440 > [ 4.482094] renesas_sdhi_probe+0x488/0x6f4 > [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78 > [ 4.491509] platform_probe+0x64/0xd8 > [ 4.495178] really_probe+0xb8/0x2a8 > [ 4.498756] __driver_probe_device+0x74/0x118 > [ 4.503116] driver_probe_device+0x3c/0x154 > [ 4.507303] __device_attach_driver+0xd4/0x160 > [ 4.511750] bus_for_each_drv+0x84/0xe0 > [ 4.515588] __device_attach_async_helper+0xb0/0xdc > [ 4.520470] async_run_entry_fn+0x30/0xd8 > [ 4.524481] process_one_work+0x210/0x62c > [ 4.528494] worker_thread+0x1ac/0x340 > [ 4.532245] kthread+0x10c/0x110 > [ 4.535476] ret_from_fork+0x10/0x20 > > [...] Applied, thanks! [1/1] gpio: rcar: Use raw_spinlock to protect register access commit: f02c41f87cfe61440c18bf77d1ef0a884b9ee2b5 Best regards,
diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c index 2ecee3269a0c..8e0544e92488 100644 --- a/drivers/gpio/gpio-rcar.c +++ b/drivers/gpio/gpio-rcar.c @@ -40,7 +40,7 @@ struct gpio_rcar_info { struct gpio_rcar_priv { void __iomem *base; - spinlock_t lock; + raw_spinlock_t lock; struct device *dev; struct gpio_chip gpio_chip; unsigned int irq_parent; @@ -123,7 +123,7 @@ static void gpio_rcar_config_interrupt_input_mode(struct gpio_rcar_priv *p, * "Setting Level-Sensitive Interrupt Input Mode" */ - spin_lock_irqsave(&p->lock, flags); + raw_spin_lock_irqsave(&p->lock, flags); /* Configure positive or negative logic in POSNEG */ gpio_rcar_modify_bit(p, POSNEG, hwirq, !active_high_rising_edge); @@ -142,7 +142,7 @@ static void gpio_rcar_config_interrupt_input_mode(struct gpio_rcar_priv *p, if (!level_trigger) gpio_rcar_write(p, INTCLR, BIT(hwirq)); - spin_unlock_irqrestore(&p->lock, flags); + raw_spin_unlock_irqrestore(&p->lock, flags); } static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type) @@ -246,7 +246,7 @@ static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip, * "Setting General Input Mode" */ - spin_lock_irqsave(&p->lock, flags); + raw_spin_lock_irqsave(&p->lock, flags); /* Configure positive logic in POSNEG */ gpio_rcar_modify_bit(p, POSNEG, gpio, false); @@ -261,7 +261,7 @@ static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip, if (p->info.has_outdtsel && output) gpio_rcar_modify_bit(p, OUTDTSEL, gpio, false); - spin_unlock_irqrestore(&p->lock, flags); + raw_spin_unlock_irqrestore(&p->lock, flags); } static int gpio_rcar_request(struct gpio_chip *chip, unsigned offset) @@ -347,7 +347,7 @@ static int gpio_rcar_get_multiple(struct gpio_chip *chip, unsigned long *mask, return 0; } - spin_lock_irqsave(&p->lock, flags); + raw_spin_lock_irqsave(&p->lock, flags); outputs = gpio_rcar_read(p, INOUTSEL); m = outputs & bankmask; if (m) @@ -356,7 +356,7 @@ static int gpio_rcar_get_multiple(struct gpio_chip *chip, unsigned long *mask, m = ~outputs & bankmask; if (m) val |= gpio_rcar_read(p, INDT) & m; - spin_unlock_irqrestore(&p->lock, flags); + raw_spin_unlock_irqrestore(&p->lock, flags); bits[0] = val; return 0; @@ -367,9 +367,9 @@ static void gpio_rcar_set(struct gpio_chip *chip, unsigned offset, int value) struct gpio_rcar_priv *p = gpiochip_get_data(chip); unsigned long flags; - spin_lock_irqsave(&p->lock, flags); + raw_spin_lock_irqsave(&p->lock, flags); gpio_rcar_modify_bit(p, OUTDT, offset, value); - spin_unlock_irqrestore(&p->lock, flags); + raw_spin_unlock_irqrestore(&p->lock, flags); } static void gpio_rcar_set_multiple(struct gpio_chip *chip, unsigned long *mask, @@ -386,12 +386,12 @@ static void gpio_rcar_set_multiple(struct gpio_chip *chip, unsigned long *mask, if (!bankmask) return; - spin_lock_irqsave(&p->lock, flags); + raw_spin_lock_irqsave(&p->lock, flags); val = gpio_rcar_read(p, OUTDT); val &= ~bankmask; val |= (bankmask & bits[0]); gpio_rcar_write(p, OUTDT, val); - spin_unlock_irqrestore(&p->lock, flags); + raw_spin_unlock_irqrestore(&p->lock, flags); } static int gpio_rcar_direction_output(struct gpio_chip *chip, unsigned offset, @@ -505,7 +505,7 @@ static int gpio_rcar_probe(struct platform_device *pdev) return -ENOMEM; p->dev = dev; - spin_lock_init(&p->lock); + raw_spin_lock_init(&p->lock); /* Get device configuration from DT node */ ret = gpio_rcar_parse_dt(p, &npins);
Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access. [ 4.239592] ============================= [ 4.239595] [ BUG: Invalid wait context ] [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted [ 4.239603] ----------------------------- [ 4.239606] kworker/u8:5/76 is trying to lock: [ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.239641] other info that might help us debug this: [ 4.239643] context-{5:5} [ 4.239646] 5 locks held by kworker/u8:5/76: [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value. [ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c [ 4.254109] #2: ffff00000920c8f8 [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value. [ 4.264803] (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690 [ 4.264840] #4: [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value. [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690 [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz [ 4.304082] stack backtrace: [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) [ 4.304097] Workqueue: async async_run_entry_fn [ 4.304106] Call trace: [ 4.304110] show_stack+0x14/0x20 (C) [ 4.304122] dump_stack_lvl+0x6c/0x90 [ 4.304131] dump_stack+0x14/0x1c [ 4.304138] __lock_acquire+0xdfc/0x1584 [ 4.426274] lock_acquire+0x1c4/0x33c [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 [ 4.444422] __irq_set_trigger+0x5c/0x178 [ 4.448435] __setup_irq+0x2e4/0x690 [ 4.452012] request_threaded_irq+0xc4/0x190 [ 4.456285] devm_request_threaded_irq+0x7c/0xf4 [ 4.459398] ata1: link resume succeeded after 1 retries [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0 [ 4.470660] mmc_start_host+0x50/0xac [ 4.474327] mmc_add_host+0x80/0xe4 [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440 [ 4.482094] renesas_sdhi_probe+0x488/0x6f4 [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78 [ 4.491509] platform_probe+0x64/0xd8 [ 4.495178] really_probe+0xb8/0x2a8 [ 4.498756] __driver_probe_device+0x74/0x118 [ 4.503116] driver_probe_device+0x3c/0x154 [ 4.507303] __device_attach_driver+0xd4/0x160 [ 4.511750] bus_for_each_drv+0x84/0xe0 [ 4.515588] __device_attach_async_helper+0xb0/0xdc [ 4.520470] async_run_entry_fn+0x30/0xd8 [ 4.524481] process_one_work+0x210/0x62c [ 4.528494] worker_thread+0x1ac/0x340 [ 4.532245] kthread+0x10c/0x110 [ 4.535476] ret_from_fork+0x10/0x20 Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> --- Hi Geert, This is similar to what was done to other GPIO drivers to solve the same situation see [1], [2], [3] and [4] for some examples. 1. 3c938cc5cebc ("gpio: use raw spinlock for gpio chip shadowed data") 2. 37174f334130 ("gpio: tegra: Use raw_spinlock") 3. 4dbada2be460 ("gpio: omap: use raw locks for locking") 3. 505936131ea7 ("gpio: mpc8xxx: Convert mpc8xxx_gpio_chip.lock to raw_spinlock") --- drivers/gpio/gpio-rcar.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-)