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

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-pm] Behavior of PCMCIA based HCD in the event of SUSPEND

[kaustav.majumdar]

-----Original Message-----
From: Alan Stern [mailto:stern@rowland.harvard.edu] 
Sent: Monday, April 17, 2006 7:45 PM
To: Kaustav Majumdar (WT01 - Semiconductors & Consumer Electronics)
Cc: linux-usb-devel@lists.sourceforge.net; linux-pm@lists.osdl.org
Subject: Re: [linux-pm] Behavior of PCMCIA based HCD in the event of
SUSPEND

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.

As per my understanding, the Host Controller can be suspended only if
all the child devices are already suspended. If they are not then
suspension of HC will fail. 
Also the PCMCIA subsystem's behavior is to power off the socket
irrespective of whether the PCMCIA client driver has successfully
handled the SUSPEND event or not.
So if the child devices of HC are not suspended and PCMCIA subsystem
will get a SUSPEND event (may be initiated by some user space tool
through /sys) then there is a possibility of HC being in operational
state (from driver perspective) but the PC Card itself not powered - a
chaos I think.


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

First of all, is there any way to check the state of all the clients
from inside the PCMCIA client driver? Please suggest.
Secondly, what should we do in the PCMCIA client driver if the check
fails? Here point to be noted is, as already mentioned, the PCMCIA
socket will be powered off.

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

Actually we are not calling usb_remove_hcd directly. We are implementing
the HCD module and there we have a function which is exported. From
PCMCIA client driver we call this function, which in turn calls
usb_remove_hcd.
I am not sure whether this will be ok or not.

Thank you,
With regards,
Kaustav 

> 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\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 Tue, 18 Apr 2006 kaustav.majumdar@wipro.com wrote:

> > 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.
> 
> As per my understanding, the Host Controller can be suspended only if
> all the child devices are already suspended. If they are not then
> suspension of HC will fail.

That's right.

> Also the PCMCIA subsystem's behavior is to power off the socket
> irrespective of whether the PCMCIA client driver has successfully
> handled the SUSPEND event or not.

I don't know how the PCMCIA subsystem works.  If it behaves the way you 
described then it is broken and should be fixed.

> So if the child devices of HC are not suspended and PCMCIA subsystem
> will get a SUSPEND event (may be initiated by some user space tool
> through /sys) then there is a possibility of HC being in operational
> state (from driver perspective) but the PC Card itself not powered - a
> chaos I think.

I doubt it will cause chaos, although it might.  More likely the driver 
will just decide that the host controller has died.

> > 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.
> 
> First of all, is there any way to check the state of all the clients
> from inside the PCMCIA client driver? Please suggest.

Since I don't know anything about how the PCMCIA subsystem or the client 
drivers work, I can't suggest anything specific.  The general approach is 
to go through the list of child devices and for each one, check the 
power state (it's embedded in the struct device).

> Secondly, what should we do in the PCMCIA client driver if the check
> fails? Here point to be noted is, as already mentioned, the PCMCIA
> socket will be powered off.

The client driver should fail the suspend call and the PCMCIA socket 
should remain powered on.

> > The PCMCIA client driver should not call usb_remove_hcd at all.  Only
> a
> > USB host controller driver is allowed to call that routine.
> 
> Actually we are not calling usb_remove_hcd directly. We are implementing
> the HCD module and there we have a function which is exported. From
> PCMCIA client driver we call this function, which in turn calls
> usb_remove_hcd.
> I am not sure whether this will be ok or not.

I suppose it might work, but it adds a bunch of extra code for no good 
reason.  You would be much better off directing your efforts toward fixing 
the PCMCIA socket driver.

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-pm] Behavior of PCMCIA based HCD in the event of SUSPEND

[Dominik Brodowski]

On Tue, Apr 18, 2006 at 09:45:50AM -0400, Alan Stern wrote:
> On Tue, 18 Apr 2006 kaustav.majumdar@wipro.com wrote:
> > Also the PCMCIA subsystem's behavior is to power off the socket
> > irrespective of whether the PCMCIA client driver has successfully
> > handled the SUSPEND event or not.
> 
> I don't know how the PCMCIA subsystem works.  If it behaves the way you 
> described then it is broken and should be fixed.

At least with latest 2.6.17-rc1, if the PCMCIA driver returns an error in
its suspend function, this error is passed to the PM layer which should stop
the suspend-to-?-path. If you're calling "pccardctl suspend", the PCMCIA
layer itself checks for this error AFAICS.

	Dominik


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