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

Re: device model documentation 2/3

[Oliver Neukum]

> SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> stops transactions, or what it should do with unfinished transactions
> is a policy of the driver. After this call, the driver should not
> accept any other I/O requests.

Does this mean that memory allocations in the suspend/resume
implementations must be made with GFP_NOIO respectively
GFP_ATOMIC ?
It would seem so.

	Regards
		Oliver

Re: device model documentation 2/3

[Patrick Mochel]

On Wed, 5 Jun 2002, Oliver Neukum wrote:

> 
> > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > stops transactions, or what it should do with unfinished transactions
> > is a policy of the driver. After this call, the driver should not
> > accept any other I/O requests.
> 
> Does this mean that memory allocations in the suspend/resume
> implementations must be made with GFP_NOIO respectively
> GFP_ATOMIC ?
> It would seem so.

Why would you allocate memory on a resume transition? 

As for suspending, this is something that has been discussed a few times 
before. No definitive decision has come out of it because it hasn't been 
implemented yet. It hasn't been implemented yet because the infrastructure 
isn't complete. It's real close, but still not quite there. 

Nonetheless, you have to do one of a couple things: use GFP_NOIO or
special case the swap device(s) so they don't stop I/O when everything
else does. (Of course, you have to eventually stop it)

Check the archives; there are lots of ideas there wrt this topic. But, 
there are bigger fish to fry in the meantime ;)

	-pat

Re: device model documentation 2/3

[Pavel Machek]

Hi!

> > > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > > stops transactions, or what it should do with unfinished transactions
> > > is a policy of the driver. After this call, the driver should not
> > > accept any other I/O requests.
> > 
> > Does this mean that memory allocations in the suspend/resume
> > implementations must be made with GFP_NOIO respectively
> > GFP_ATOMIC ?
> > It would seem so.
> 
> Why would you allocate memory on a resume transition? 
> 
> As for suspending, this is something that has been discussed a few times 
> before. No definitive decision has come out of it because it hasn't been 
> implemented yet. It hasn't been implemented yet because the infrastructure 
> isn't complete. It's real close, but still not quite there. 

swsusp works for me (tm). SO structure should be there ;-)

> Nonetheless, you have to do one of a couple things: use GFP_NOIO or
> special case the swap device(s) so they don't stop I/O when everything
> else does. (Of course, you have to eventually stop it)

Special casing swap is not enough -- you can well have memory full of data
for regular filesystem.

								Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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

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.

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