The function meson_clk_pll_enable() can be invoked under the enable_lock
spinlock from the clk core logic, which risks a kernel panic during the
usleep_range() call:
BUG: scheduling while atomic: kworker/u4:2/36/0x00000002
Modules linked in: g_ffs usb_f_fs libcomposite
CPU: 1 PID: 36 Comm: kworker/u4:2 Not tainted 6.4.0-rc5 #273
Workqueue: events_unbound async_run_entry_fn
Call trace:
dump_backtrace+0x9c/0x128
show_stack+0x20/0x38
dump_stack_lvl+0x48/0x60
dump_stack+0x18/0x28
__schedule_bug+0x58/0x78
__schedule+0x828/0xa88
schedule+0x64/0xd8
schedule_hrtimeout_range_clock+0xd0/0x208
schedule_hrtimeout_range+0x1c/0x30
usleep_range_state+0x6c/0xa8
meson_clk_pll_enable+0x1f4/0x310
clk_core_enable+0x78/0x200
clk_core_enable+0x58/0x200
clk_core_enable+0x58/0x200
clk_core_enable+0x58/0x200
clk_enable+0x34/0x60
So it is required to use the udelay() function instead of usleep_range()
for the atomic context safety.
Fixes: b6ec400aa1 ("clk: meson: introduce new pll power-on sequence for A1 SoC family")
Reported-by: Jan Dakinevich <yvdakinevich@sberdevices.ru>
Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru>
Link: https://lore.kernel.org/r/20230704215404.11533-1-ddrokosov@sberdevices.ru
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>