From: Greg KH <greg@kroah.com>
To: Nigel Cunningham <nigel@nigel.suspend2.net>
Cc: linux-pm@lists.osdl.org, Pekka J Enberg <penberg@cs.helsinki.fi>,
pavel@ucw.cz
Subject: Re: [RFC/PATCH 2/2] driver core: power management debugging
Date: Sat, 28 Apr 2007 23:50:51 -0700 [thread overview]
Message-ID: <20070429065051.GA31628@kroah.com> (raw)
In-Reply-To: <1177800952.7652.4.camel@nigel.suspend2.net>
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 :(
thanks,
greg k-h
next prev parent reply other threads:[~2007-04-29 6:50 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
2007-04-29 6:50 ` Greg KH [this message]
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=20070429065051.GA31628@kroah.com \
--to=greg@kroah.com \
--cc=linux-pm@lists.osdl.org \
--cc=nigel@nigel.suspend2.net \
--cc=pavel@ucw.cz \
--cc=penberg@cs.helsinki.fi \
/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.