Re: [linux-usb-devel] Re: device model documentation 2/3

Re: [linux-usb-devel] Re: device model documentation 2/3

[David Brownell]

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

Re: [linux-usb-devel] Re: device model documentation 2/3

[Pavel Machek]

Hi!

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

> 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
-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] Re: device model documentation 2/3

[Oliver Neukum]

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

_______________________________________________
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