Hi Alan,
I went through the reply sent by you to Kaustav.I have some
doubts.
----------------------------------------------------------------------
Message: 3
Date: Mon, 17 Apr 2006 10:15:04 -0400 (EDT)
From: Alan Stern <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: linux-usb-devel@lists.sourceforge.net, <[EMAIL PROTECTED]>
Subject: [linux-usb-devel] Re: [linux-pm] Behavior of PCMCIA based HCD
in the event of SUSPEND
On Mon, 17 Apr 2006 [EMAIL PROTECTED] 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
------------------------------------------------------------------------
--------
Now the problem is PCMCIA powers of the card when it gets the suspend
event. So consider the following case:
Let the device,port,roothub interface and the Host controller,
which are the nodes of the device tree are not suspened.Now a user
suspends the PCMCIA card. So PCMCIA gets the suspend event and powers of
the card. We have a check in PCMCIA suspend event that whether the Host
controller is suspended or not. So considering the above case we find
that Host controller is not suspended. Now according to LINUX USB
framework, parent node should not be supended if all the child devices
are not suspended. So we thought up three solutions for this.
First is, fail the suspend event which we cant do because PCMCIA powes
off the card.
Second is, mark Host Controller as suspended. But I hope this is against
the LINUX USB framework because we should not suspend the host
controller when the bus,port and the device connected to the port are
still active.So you suspend the device connected to the port first, then
the port ,then the roothub interface and then the Host controller.
Third is, as the card is physically powered off, we shutdown the
controller. So we thought up doing this.
As you have replied, PCMCIA should not make assumption about its
client. So doing second and third solution are not feasible as we will
be handling/changing HCD stuff from PCMCIA layer. So only thing can be
done is, when PCMCIA gets the suspend event ,it should check whether the
Host Controller is suspended or not. Acoording to the check result,
PCMCIA should handle the suspend event. i.e. it should power off the
card if the Controller is suspended. Otherwise fail the suspend event by
not powering off the card. But PCMCIA behavior is, power off the card
irrespective anything. Then what should be the solution ?
Please suggest.
Thanks and regards,
Rasmit Ranjan Swain.
-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
