From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: [linux-usb-devel] Re: device model documentation 2/3
Date: Thu, 06 Jun 2002 19:15:22 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-102339217310406@msgid-missing> (raw)
> > All calls are made with interrupts enabled, except for the
> > SUSPEND_POWER_DOWN level.
>
> This is a slight problem for USB. We need to switch on interupts
> to send a message to the device.
For example, to enable remote wakeup (whenever we start to
support that). I understand that a lot of USB hardware does
not work reliably if that's enabled much before a USB suspend.
If only SUSPEND_POWER_DOWN notification was delivered, that'd
have to be enabled at that point.
>>Why would you allocate memory on a resume transition?
One example comes to mind. There are systems that, rather
than supporting a "suspend to reduced power", are actually
set up so they "suspend to no power". Or in short, they
power off in cases when other systems don't ... saving even
more power. (I think that is the difference between D3hot
and D3cold, or somesuch, but there are so many different
names for the various states and contexts that I've been
known to get them wrong.)
In that case, a "resume" needs to be able to completely
re-initialize the hardware. As a rule, that's going to
want to be able to allocate memory.
... though FWIW I missed seeing anything that showed how
those API summaries would place constraints on allocating
memory, so I didn't assume there could be any.
What did seem to be missing was anything saying whether
those device methods would be called in_interrupt() or
whether instead they could sleep. I'd hope all of them
would be specified to allow blocking as needed, like their
current analogues in PCI and USB.
Also, there was some mention not that long ago about
desirability of some kind of device abort() call. That
would differ from the current remove() call because an
abort() would pass the explicit knowledge that hardware
was gone ... unplugged before driver shutdown, for one
example. That could also be achieved using some kind
of mode parameter to remove() -- perhaps three values,
saying whether the hardware was present, removed, or
in some indeterminate state.
- Dave
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next reply other threads:[~2002-06-06 19:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-06 19:15 David Brownell [this message]
2002-06-06 19:24 ` [linux-usb-devel] Re: device model documentation 2/3 Pavel Machek
2002-06-06 20:00 ` Oliver Neukum
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=marc-linux-hotplug-102339217310406@msgid-missing \
--to=david-b@pacbell.net \
--cc=linux-hotplug@vger.kernel.org \
/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 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).