On Tue, 18 Apr 2006 kaustav.majumdar@xxxxxxxxx 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
