All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <nigel@nigel.suspend2.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Pekka J Enberg <penberg@cs.helsinki.fi>,
	linux-pm@lists.osdl.org, pavel@ucw.cz
Subject: Re: [RFC/PATCH 2/2] driver core: power management debugging
Date: Sun, 29 Apr 2007 08:55:52 +1000	[thread overview]
Message-ID: <1177800952.7652.4.camel@nigel.suspend2.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0704281035530.31211-100000@netrider.rowland.org>


[-- Attachment #1.1: Type: text/plain, Size: 2687 bytes --]

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.

> > > On the other hand, the drivers' maintainers are probably quite aware of 
> > > the missing PM support, so it's not clear that printing out warning 
> > > messages will actually help anybody.
> > 
> > It can help the user, when they're looking for possibilities as to why things aren't working.
> 
> Maybe.  But the warnings will occur when the driver is registered, which 
> is often long before the problem shows up.  The user may not make the 
> connection.

True, but if we make them show up earlier, they at least have a chance
to see what might cause problems before the problems occur. If we do it
at the time, they might have zero chance to see messages like this.

> On a completely different topic: Nigel, now's your big chance!  If you 
> hurry, you can rename Suspend2 to Hibernate -- beating out Pavel, who will 
> then be forced to rename swsusp to Hibernate2!  :-)

LOL. I don't care about names, or about beating Pavel at anything. I
just want to get better hibernation support in the kernel. It would be
nice to get rid of that awful swsusp name though! :)

Nigel

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2007-04-28 22:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-27 12:25 [RFC/PATCH 2/2] driver core: power management debugging Pekka J Enberg
2007-04-27 12:37 ` Pavel Machek
2007-04-27 14:08 ` Alan Stern
2007-04-27 14:13   ` Pekka Enberg
2007-04-27 21:25   ` Nigel Cunningham
2007-04-27 21:46     ` Greg KH
2007-04-28 14:42     ` Alan Stern
2007-04-28 22:55       ` Nigel Cunningham [this message]
2007-04-29  6:50         ` Greg KH
2007-04-29  7:47           ` Nigel Cunningham
2007-04-29  7:50             ` Greg KH
2007-04-27 15:40 ` Greg KH
2007-04-27 21:38   ` Nigel Cunningham
2007-04-27 21:45     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1177800952.7652.4.camel@nigel.suspend2.net \
    --to=nigel@nigel.suspend2.net \
    --cc=linux-pm@lists.osdl.org \
    --cc=pavel@ucw.cz \
    --cc=penberg@cs.helsinki.fi \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.