On Sat, Sep 29, 2012 at 01:29:17PM +0800, Jun Nie wrote: > diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c > index 1d00736..7759c82 100644 > --- a/drivers/video/s3fb.c > +++ b/drivers/video/s3fb.c > @@ -1445,12 +1444,12 @@ static int s3_pci_suspend(struct pci_dev* dev, > pm_message_t state) > > dev_info(info->device, "suspend\n"); > > - console_lock(); > + fb_fb_console_lock(); > mutex_lock(&(par->open_lock)); > Compiling is overrated anyways. > diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c > index 8e4a446..e266b6b 100644 > --- a/drivers/video/tmiofb.c > +++ b/drivers/video/tmiofb.c > @@ -959,7 +958,7 @@ static int tmiofb_suspend(struct platform_device > *dev, pm_message_t state) > if (cell->suspend) > retval = cell->suspend(dev); > > - console_unlock(); > + fb_fb_console_unlock(); > > return retval; > } > @@ -986,7 +985,7 @@ static int tmiofb_resume(struct platform_device *dev) > > fb_set_suspend(info, 0); > out: > - console_unlock(); > + fb_fb_console_unlock(); > return retval; > } > #else Here too. Turning locks in to no-ops without auditing every single driver's use of said lock and converting to something to protect the work being done under lock suggests that this conversion is more mechanical than thought out beyond your specific use case. While you've obviously identified a problem that's worth pursuing, it's going to take a bit more work than mechanical conversion, and it's going to have to be something that's moved towards incrementally. If you haven't even compile tested the impacted drivers, it suggests you haven't spent a great deal of time thinking about what they are doing under said lock, either.. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
