| Message ID | 20230703200404.20361-1-ddrokosov@sberdevices.ru (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1] clk: meson: change usleep_range() to udelay() for atomic context | expand |
On Mon 03 Jul 2023 at 23:04, Dmitry Rokosov <ddrokosov@sberdevices.ru> wrote: > The function meson_clk_pll_enable() can be invoked under the enable_lock > spinlock from the clk core logic --- > (please refer to > drivers/clk/clk.c:clk_core_enable_lock()), which risks a kernel panic > during the usleep_range() call: > This part of the comment is not very useful - please drop it > 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 > > Considering that this code is expected to be used in an atomic context, > it is required to use the udelay() function instead of usleep_range() > for the atomic context safety. Please use an imperative form, instructing the code to change > > Fixes: b6ec400aa153 ("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> > Signed-off-by: Jan Dakinevich <yvdakinevich@sberdevices.ru> The tags are confusing here I suppose a 2 lines change has not be been written with 4 hands ;) If Jan just reported and you made the change then drop his signed-off If he did the job, then drop the reported-by and change the author > --- > drivers/clk/meson/clk-pll.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c > index 56ec2210f1ad..eef6f37c8d8d 100644 > --- a/drivers/clk/meson/clk-pll.c > +++ b/drivers/clk/meson/clk-pll.c > @@ -367,9 +367,9 @@ static int meson_clk_pll_enable(struct clk_hw *hw) > * 3. enable the lock detect module > */ > if (MESON_PARM_APPLICABLE(&pll->current_en)) { > - usleep_range(10, 20); > + udelay(10); > meson_parm_write(clk->map, &pll->current_en, 1); > - usleep_range(40, 50); > + udelay(40); > }; > > if (MESON_PARM_APPLICABLE(&pll->l_detect)) {
Hello Jerome, Thank you for the review! On Tue, Jul 04, 2023 at 09:43:41PM +0200, Jerome Brunet wrote: > > On Mon 03 Jul 2023 at 23:04, Dmitry Rokosov <ddrokosov@sberdevices.ru> wrote: > > > The function meson_clk_pll_enable() can be invoked under the enable_lock > > spinlock from the clk core logic > > --- > > (please refer to > > drivers/clk/clk.c:clk_core_enable_lock()), which risks a kernel panic > > during the usleep_range() call: > > > > This part of the comment is not very useful - please drop it > Do you mean a stack trace or reference to clk_core_enable_lock()? > > 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 > > > > Considering that this code is expected to be used in an atomic context, > > it is required to use the udelay() function instead of usleep_range() > > for the atomic context safety. > > Please use an imperative form, instructing the code to change > Ack > > > > Fixes: b6ec400aa153 ("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> > > Signed-off-by: Jan Dakinevich <yvdakinevich@sberdevices.ru> > > The tags are confusing here > I suppose a 2 lines change has not be been written with 4 hands ;) > > If Jan just reported and you made the change then drop his signed-off > If he did the job, then drop the reported-by and change the author > No problem :) Sometimes 2 lines change is produced during 4 hands debugging :) > > --- > > drivers/clk/meson/clk-pll.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c > > index 56ec2210f1ad..eef6f37c8d8d 100644 > > --- a/drivers/clk/meson/clk-pll.c > > +++ b/drivers/clk/meson/clk-pll.c > > @@ -367,9 +367,9 @@ static int meson_clk_pll_enable(struct clk_hw *hw) > > * 3. enable the lock detect module > > */ > > if (MESON_PARM_APPLICABLE(&pll->current_en)) { > > - usleep_range(10, 20); > > + udelay(10); > > meson_parm_write(clk->map, &pll->current_en, 1); > > - usleep_range(40, 50); > > + udelay(40); > > }; > > > > if (MESON_PARM_APPLICABLE(&pll->l_detect)) { >
On Tue 04 Jul 2023 at 22:54, Dmitry Rokosov <ddrokosov@sberdevices.ru> wrote: > Hello Jerome, > > Thank you for the review! > > On Tue, Jul 04, 2023 at 09:43:41PM +0200, Jerome Brunet wrote: >> >> On Mon 03 Jul 2023 at 23:04, Dmitry Rokosov <ddrokosov@sberdevices.ru> wrote: >> >> > The function meson_clk_pll_enable() can be invoked under the enable_lock >> > spinlock from the clk core logic >> >> --- >> > (please refer to >> > drivers/clk/clk.c:clk_core_enable_lock()), which risks a kernel panic >> > during the usleep_range() call: >> > >> >> This part of the comment is not very useful - please drop it >> > > Do you mean a stack trace or reference to clk_core_enable_lock()? The comment about clk_core_enable_lock. The stack trace is useful, it may help people googling the warning > >> > 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 >> > >> > Considering that this code is expected to be used in an atomic context, >> > it is required to use the udelay() function instead of usleep_range() >> > for the atomic context safety. >> >> Please use an imperative form, instructing the code to change >> > > Ack > >> > >> > Fixes: b6ec400aa153 ("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> >> > Signed-off-by: Jan Dakinevich <yvdakinevich@sberdevices.ru> >> >> The tags are confusing here >> I suppose a 2 lines change has not be been written with 4 hands ;) >> >> If Jan just reported and you made the change then drop his signed-off >> If he did the job, then drop the reported-by and change the author >> > > No problem :) Sometimes 2 lines change is produced during 4 hands > debugging :) > >> > --- >> > drivers/clk/meson/clk-pll.c | 4 ++-- >> > 1 file changed, 2 insertions(+), 2 deletions(-) >> > >> > diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c >> > index 56ec2210f1ad..eef6f37c8d8d 100644 >> > --- a/drivers/clk/meson/clk-pll.c >> > +++ b/drivers/clk/meson/clk-pll.c >> > @@ -367,9 +367,9 @@ static int meson_clk_pll_enable(struct clk_hw *hw) >> > * 3. enable the lock detect module >> > */ >> > if (MESON_PARM_APPLICABLE(&pll->current_en)) { >> > - usleep_range(10, 20); >> > + udelay(10); >> > meson_parm_write(clk->map, &pll->current_en, 1); >> > - usleep_range(40, 50); >> > + udelay(40); >> > }; >> > >> > if (MESON_PARM_APPLICABLE(&pll->l_detect)) { >>
diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c index 56ec2210f1ad..eef6f37c8d8d 100644 --- a/drivers/clk/meson/clk-pll.c +++ b/drivers/clk/meson/clk-pll.c @@ -367,9 +367,9 @@ static int meson_clk_pll_enable(struct clk_hw *hw) * 3. enable the lock detect module */ if (MESON_PARM_APPLICABLE(&pll->current_en)) { - usleep_range(10, 20); + udelay(10); meson_parm_write(clk->map, &pll->current_en, 1); - usleep_range(40, 50); + udelay(40); }; if (MESON_PARM_APPLICABLE(&pll->l_detect)) {
The function meson_clk_pll_enable() can be invoked under the enable_lock spinlock from the clk core logic (please refer to drivers/clk/clk.c:clk_core_enable_lock()), 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 Considering that this code is expected to be used in an atomic context, it is required to use the udelay() function instead of usleep_range() for the atomic context safety. Fixes: b6ec400aa153 ("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> Signed-off-by: Jan Dakinevich <yvdakinevich@sberdevices.ru> --- drivers/clk/meson/clk-pll.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)