From: Chas W. <3c...@gm...> - 2018-01-30 16:30:00
|
On Thu, Jan 25, 2018 at 10:42 PM, Jia-Ju Bai <bai...@gm...> wrote: > After checking all possible call chains to idt77252_preset() here, > my tool finds that idt77252_preset() is never called in atomic context, > namely never in an interrupt handler or holding a spinlock. > And idt77252_preset() calls deinit_card, which calls free_irq (can sleep), > so it indicates that idt77252_preset() can call functions which can sleep. > Thus mdelay can be replaced with usleep_range to avoid busy wait. > > This is found by a static analysis tool named DCNS written by myself. > > Signed-off-by: Jia-Ju Bai <bai...@gm...> > --- > drivers/atm/idt77252.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c > index 0277f36..cea4bf2 100644 > --- a/drivers/atm/idt77252.c > +++ b/drivers/atm/idt77252.c > @@ -3563,7 +3563,7 @@ static int idt77252_preset(struct idt77252_dev *card) > > /* Software reset */ > writel(SAR_CFG_SWRST, SAR_REG_CFG); > - mdelay(1); > + usleep_range(500, 1000); > Yes, this is a sleepable context. I would err on the side of caution here and choose a range that is a minimum of 1ms instead of 0.5ms. > writel(0, SAR_REG_CFG); > > IPRINTK("%s: Software resetted.\n", card->name); > -- > 1.7.9.5 > > |