* [PATCH] video: fbdev: savage: Replace mdelay with usleep_range in savage_init_hw
@ 2018-04-10 1:05 ` Jia-Ju Bai
2018-04-24 15:42 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 2+ messages in thread
From: Jia-Ju Bai @ 2018-04-10 1:05 UTC (permalink / raw)
To: adaplas, b.zolnierkie; +Cc: linux-fbdev, linux-kernel, Jia-Ju Bai
savage_init_hw() is never called in atomic context.
The call chains ending up at savage_init_hw() are:
[1] savage_init_hw() <- savagefb_probe()
[2] savage_init_hw() <- savagefb_resume()
savagefb_probe() is only set as ".probe" in struct pci_driver.
savagefb_resume) is only set as ".resume" in struct pci_driver.
These functions are not called in atomic context.
Despite never getting called from atomic context, savage_init_hw()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/video/fbdev/savage/savagefb_driver.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/savage/savagefb_driver.c b/drivers/video/fbdev/savage/savagefb_driver.c
index c204683..c09d742 100644
--- a/drivers/video/fbdev/savage/savagefb_driver.c
+++ b/drivers/video/fbdev/savage/savagefb_driver.c
@@ -1892,11 +1892,11 @@ static int savage_init_hw(struct savagefb_par *par)
vga_out8(0x3d4, 0x66, par);
cr66 = vga_in8(0x3d5, par);
vga_out8(0x3d5, cr66 | 0x02, par);
- mdelay(10);
+ usleep_range(10000, 11000);
vga_out8(0x3d4, 0x66, par);
vga_out8(0x3d5, cr66 & ~0x02, par); /* clear reset flag */
- mdelay(10);
+ usleep_range(10000, 11000);
/*
@@ -1906,11 +1906,11 @@ static int savage_init_hw(struct savagefb_par *par)
vga_out8(0x3d4, 0x3f, par);
cr3f = vga_in8(0x3d5, par);
vga_out8(0x3d5, cr3f | 0x08, par);
- mdelay(10);
+ usleep_range(10000, 11000);
vga_out8(0x3d4, 0x3f, par);
vga_out8(0x3d5, cr3f & ~0x08, par); /* clear reset flags */
- mdelay(10);
+ usleep_range(10000, 11000);
/* Savage ramdac speeds */
par->numClocks = 4;
--
1.9.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] video: fbdev: savage: Replace mdelay with usleep_range in savage_init_hw
2018-04-10 1:05 ` [PATCH] video: fbdev: savage: Replace mdelay with usleep_range in savage_init_hw Jia-Ju Bai
@ 2018-04-24 15:42 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 2+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2018-04-24 15:42 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: adaplas, linux-fbdev, linux-kernel
On Tuesday, April 10, 2018 09:05:59 AM Jia-Ju Bai wrote:
> savage_init_hw() is never called in atomic context.
>
> The call chains ending up at savage_init_hw() are:
> [1] savage_init_hw() <- savagefb_probe()
> [2] savage_init_hw() <- savagefb_resume()
>
> savagefb_probe() is only set as ".probe" in struct pci_driver.
> savagefb_resume) is only set as ".resume" in struct pci_driver.
> These functions are not called in atomic context.
>
> Despite never getting called from atomic context, savage_init_hw()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range to
> avoid busy waiting.
>
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Patch queued for 4.18, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-04-24 15:43 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20180410010607epcas4p2d1b0cb70e0676a6d6f215fe7e204e699@epcas4p2.samsung.com>
2018-04-10 1:05 ` [PATCH] video: fbdev: savage: Replace mdelay with usleep_range in savage_init_hw Jia-Ju Bai
2018-04-24 15:42 ` Bartlomiej Zolnierkiewicz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).