Behavior of PCMCIA based HCD in the event of SUSPEND

Behavior of PCMCIA based HCD in the event of SUSPEND

[kaustav.majumdar]

Hi all,

I have the following queries regarding the power management on a PCMCIA
based USB host controller driver.

1. The SUSPEND event in the PCMCIA client driver is handled in the
following way:

In the PCMCIA layer, on a SUSPEND event, the socket layer powers off the
card. As the USB framework behavior is not allowed to suspend if lower
nodes are not already suspended, we assume that the correct behavior for
the above case should be to shut down the Host Controller.
I want to confirm whether the assumed behavior is ok or should the
behavior be something else?


2. And if the correct behavior is what we had assumed, then to implement
that we call usb_remove_hcd from the PCMCIA client driver. Is this the
correct way to do so? 
The reason for the question is it can happen that after suspending the
card, before resume card may be manually removed. In that case, there is
a possibility of usb_remove_hcd being called twice consecutively which
can cause error.
Please suggest if any better way of implementing the above.

Looking forward to you replies and thanks in advance

Thank you,
With Regards,
Kaustav Majumdar


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-pm] Behavior of PCMCIA based HCD in the event of SUSPEND

[Alan Stern]

On Mon, 17 Apr 2006 kaustav.majumdar@wipro.com wrote:

> Hi all,
> 
> I have the following queries regarding the power management on a PCMCIA
> based USB host controller driver.
> 
> 1. The SUSPEND event in the PCMCIA client driver is handled in the
> following way:
> 
> In the PCMCIA layer, on a SUSPEND event, the socket layer powers off the
> card. As the USB framework behavior is not allowed to suspend if lower
> nodes are not already suspended, we assume that the correct behavior for
> the above case should be to shut down the Host Controller.
> I want to confirm whether the assumed behavior is ok or should the
> behavior be something else?

The HCD's behavior should be to suspend the host controller, with the 
understanding that factors beyond the HCD's control (such as the 
behavior of the PCMCIA client driver) may cause the host controller to be 
shut down entirely.  The HCD should not shut down the host controller 
during a suspend event.

> 2. And if the correct behavior is what we had assumed, then to implement
> that we call usb_remove_hcd from the PCMCIA client driver. Is this the
> correct way to do so? 

No.  The PCMCIA client driver should not make any assumptions about its 
clients.  All it should do is check that all the clients have been 
suspended already before allowing itself to be suspended.

> The reason for the question is it can happen that after suspending the
> card, before resume card may be manually removed. In that case, there is
> a possibility of usb_remove_hcd being called twice consecutively which
> can cause error.
> Please suggest if any better way of implementing the above.

The PCMCIA client driver should not call usb_remove_hcd at all.  Only a
USB host controller driver is allowed to call that routine.

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Behavior of PCMCIA based HCD in the event of SUSPEND

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]

On Sunday 16 April 2006 11:30 pm, kaustav.majumdar@wipro.com wrote:
> Hi all,
> 
> I have the following queries regarding the power management on a PCMCIA
> based USB host controller driver.

You mean PCMCIA as in the 16-bit ISA-ish bus?

Or PCMCIA as in the "PC Card" form factor with Cardbus/PCI options?

Right now we have working examples of both of those.  ("sl811_cs" for
PCMCIA/CF, and at least OHCI and EHCI for CardBus/PCI.)  I wouldn't say
either work perfectly -- lack of constant testing being a predictable
source of trouble -- but they have differences which matter.

Look at any of those drivers for code models.  They all used to work
correctly in these cases, maybe they still do.  ;)


> 1. The SUSPEND event in the PCMCIA client driver is handled in the
> following way:
> 
> In the PCMCIA layer, on a SUSPEND event, the socket layer powers off the
> card. As the USB framework behavior is not allowed to suspend if lower
> nodes are not already suspended, we assume that the correct behavior for
> the above case should be to shut down the Host Controller.
> I want to confirm whether the assumed behavior is ok or should the
> behavior be something else?

Shutting down the host controller at suspend() is what I'd like to see
happen, but it kept deadlocking in the PM infrastructure, which has been
designed with odd assumptions like "devices can't go away now".


What the existing drivers do is rely on the rest of Linux (usbcore and
the PM framework) to have cleanly shut down all child devices before
anyone asks the HCD to suspend ... and then HCDs will shut down politely.
(If that's not happening, something outside the HCD is broken.)

If power to a host controller gets lost during suspend, implicitly
disconnecting all the USB devices, that must be noticed in its HCD's
resume() method, at which point it marks the child devices as dead and
reinitializes itself.

And if the power is dropped _before_ the resume method gets called,
no big deal.  Ignore that fact until later; you can just handle it
later when the PM and USB frameworks are ready to handle it too.


Of course, another option is that on resume() the HCD notices that the
hardware has been unplugged, which is a somewhat different situation
that arguably reflects a bug in the bus glue used by that adapter ...
that is, the HCD should have gotten a remove() call not resume().  But
I've certainly seen Cardbus/PCI use that bogus call sequence, so the
HCDs have code to also mark the USB controller itself as dead.  That
way, until the bus glue eventually calls remove(), all is fine.



> 2. And if the correct behavior is what we had assumed, then to implement
> that we call usb_remove_hcd from the PCMCIA client driver. Is this the
> correct way to do so? 
> The reason for the question is it can happen that after suspending the
> card, before resume card may be manually removed. In that case, there is
> a possibility of usb_remove_hcd being called twice consecutively which
> can cause error.

Keep things simple, and rely on your bus glue (PCMCIA or Cardbus) to
handle disconnections; just handle suspend() and resume() sanely, while
also detecting the "card removed" cases as normal non-error operations.

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]