Re: [PATCH] gpio: rcar: Use raw_spinlock to protect register access

[Claudiu Beznea <claudiu.beznea@tuxon.dev>]

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
>