On Sat, 21 Feb 2004, David Brownell wrote:
> Alan Stern wrote:
> >
> > Is it true that the various callbacks emanating from hcd-pci.c have
> > guaranteed mutual exclusion?
>
> Not entirely. Ones initiated by "rmmod" or power management have
> to go right in, no matter what else is going on. If an HCD needs
> mutual exclusion for any purpose, it must handle that itself.
Does the PCI layer at least guarantee that it won't call through any of
the other routines while either probe or remove is running?
> And I've been thinking that such "restart this
> controller" policy choices probably should be triggered from
> userspace/sysfs. (Along with "shut down the controller"; in
> general, device management should be explicit, not just a
> side-effect of "modprobe". Among other things, not everyone
> uses modular builds...)
One approach might be to have a "running" sysfs attribute (0 or 1), plus a
max_restarts attribute (max number of times the controller will be
automatically restarted within a 1-minute interval).
> > Who really owns hcd->state? Some of the routines in hcd-pci.c set it
> > while others expect the HCD to set it. It's not protected by any lock.
> > Doesn't this need to be sorted out?
>
> Maybe, if there's a particular problem. Mostly the HCD glue
> changes that to reflect HCD initialization or shutdown.
>
> The HCD changing it to RUNNING the instant before the
> hardware is actually turned on. The HCD glue can't make
> that particular transition, since usbcore _does_ end up
> needing to do things almost immediately (IRQs fire etc);
> things which would be errors on non-RUNNING hardware.
> And that's before calls could return to hcd-pci.c ...
That's not so much of a problem if probe is atomic. It might become a
problem later for restarts, if one should occur at the same time as a
suspend for instance. Anyway, what's wrong with having probe or resume
set the state to RUNNING _before_ calling the HCD?
And what about things like usb_hcd_pci_remove() changing the state to
QUIESCING? The HCD might be modifying the state at the same time, not
good.
> It certainly wouldn't hurt to eyeball that logic; I notice
> the OMAP and SA1111 code has some old logic that should
> maybe removed now, for example. And of course, UHCI is
> not trying to use it at all!
>
> That state model isn't as clean as it might be, but so
> far that hasn't been an issue ... and it was better than
> what went before, where there was no notion of what sorts
> of operations made sense. (Queuing urbs to disabled HCDs,
> for example, never makes sense.)
Is the main point then to keep track of things and prevent bad operations
(like queueing URBs to or handling IRQs for disabled controllers)? Come
right down to it, what operations does the glue layer care about?
1. Resetting the hardware into a known idle condition
2. Telling the HCD to start/stop the controller
3. Knowing when the controller dies
4. Allowing URBs to be queued
5. Allowing IRQs to propagate
6. Passing PM suspend/resume messages down to the HCD
Have I missed anything? This all looks private to the glue layer (with
the exception of 3, which needs a notification from the HCD).
Why not simply decide that the hcd glue layer owns the state? Drivers
needn't change it at all; they can let the glue layer know whether
transitions succeed by way of return codes. And there could be callbacks,
like usb_hc_died(), for drivers to notify the glue layer about spontaneous
transitions. (Maybe that's the only one needed.)
Alan Stern
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
