Re: [RFC/PATCH 2/2] driver core: power management debugging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Apr 29, 2007 at 05:47:11PM +1000, Nigel Cunningham wrote:
> Hi.
> 
> On Sat, 2007-04-28 at 23:50 -0700, Greg KH wrote:
> > On Sun, Apr 29, 2007 at 08:55:52AM +1000, Nigel Cunningham wrote:
> > > Hi.
> > > 
> > > On Sat, 2007-04-28 at 10:42 -0400, Alan Stern wrote:
> > > > On Sat, 28 Apr 2007, Nigel Cunningham wrote:
> > > > 
> > > > > Hi Alan.
> > > > 
> > > > > Sorry. I thought you were wrong for a minute, but then I looked again at
> > > > > the messages in my dmesg...
> > > > > 
> > > > > [   33.944214] Device driver usbdev1.1_ep00 lacks bus and class support for being resumed.
> > > > > [   34.051765] Device driver usbdev1.1_ep81 lacks bus and class support for being resumed.
> > > > > [   34.113740] Device driver usbdev2.1_ep00 lacks bus and class support for being resumed.
> > > > > [   34.221541] Device driver usbdev2.1_ep81 lacks bus and class support for being resumed.
> > > > > [   34.251562] Device driver usbdev3.1_ep00 lacks bus and class support for being resumed.
> > > > > [   34.361345] Device driver usbdev3.1_ep81 lacks bus and class support for being resumed.
> > > > > 
> > > > > They're coming from the other printk, of course.
> > > > > 
> > > > > > Now perhaps you would prefer to check the USB interface drivers -- there 
> > > > > > are many of them, and quite a few don't have suspend or resume methods.  
> > > > > > You would need to modify usb_register_driver() instead of 
> > > > > > usb_register_device_driver().
> > > > > 
> > > > > Would they be the ones covered above?
> > > > 
> > > > No.  As Greg pointed out, these usbdevXX_epYY "devices" are nothing but 
> > > > placeholders at the moment.  They don't actually do anything and they have 
> > > > no need for power management.  (But they do manage to clutter up the 
> > > > system log with lots of extraneous warnings from the PM core...)
> > > 
> > > Ok, so they could have the pm_safe flag set to suppress the message.
> > 
> > No, we don't want a flag just to shut up a message, that's the first
> > thing a developer will do when they see that message, without realizing
> > what exactly they should be doing instead.
> > 
> > Trust me, I know the lengths kernel developers go to to try to work
> > around "helpful hints" that the kernel can spit out at you :(
> 
> Ok, then. So... what would you suggest (if anything)?

As your check was for something that wasn't really correct at all, I
suggest just dropping the patch :)

thanks,

greg k-h
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux