device model documentation 2/3

linux-usb-devel David Brownell 3 participants 3 messages Jun 6, 2002

Share & tools

David Brownell

author

2002-06-06 19:15 UTC #0 lore raw

Quoted 5 lines

Quoted 2 lines
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.

Quoted 1 line

Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Pavel Machek

2002-06-06 19:24 UTC #1 lore raw

Hi!

Quoted 5 lines

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.

Look better, it was there.

Quoted 9 lines

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.

I'd prefer parameter to remove...

Your hardware may die physically, and driver should try to be able to remove() even if hardware dies.
Pavel

Signature · 12 lines

Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

_______________________________________________________________

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Oliver Neukum

2002-06-06 20:00 UTC #2 lore raw

In reply to David Brownell

Quoted 4 lines

... 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.

It specified that there would be no valid assumptions on the order of devices woken up. Thus the devices that would be paged to may still be sleaping. Indeed this situation will always arise if you have more than one device that may be swapped to or by (storage, network, bluetooth, ...)

So only GFP_NOIO until every every is awake.

Regards
Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm