David:

As part of the ongoing changes to the hcd glue layer, I'd like to discuss
some more the hcd->state field.  I'm still uncomfortable about the way it
gets used:

        It's not clearly owned either by usbcore or by the HCD.

        It's not protected by a semaphore or spinlock.

HCDs may have their own uses for it, but here's a list of all the ways it 
gets used in the core:

        1. Tested during URB submission for a device on the bus.

        2. Tested during root-hub control URB submission.

        3. Tested during root-hub status polling.

        4. Tested during IRQ handling.

        5. Tested in get_frame_number.

        6. Used incorrectly for root-hub power-level checking during
           HC suspend and resume in hcd-pci.c.

        7. Used for warning about unlink while the HC isn't running.

        8. Used for warning about endpoint-disable while the HC isn't
           running.

The different tests look for different things, like HC running, HC 
suspended, HC stopped, HC died...

I think it would be a lot better to make the conditions being tested more 
explicit and not have usbcore worry about the overall state of the HC, or 
at least worry about it as little as possible.  So for example, we might 
create some bitfields in the usb_hcd struct:

        unsigned        okay_to_submit_urbs:1;
        unsigned        okay_to_use_root_hub:1;
        unsigned        okay_to_handle_irq:1;

Maybe a couple of others too.  They could be set by the HCDs, although
synchronizing testing with setting would still be problematic.  Testing
for whether an HC or root hub is suspended can be done through the struct
device power setting; it doesn't need an extra flag.

The warnings can be removed.  HCDs should be able to handle unlinks while 
the HC isn't running -- or else we should guarantee that such unlinks 
never happen.  We can avoid the need to disable endpoints while an HC is 
stopped by delaying altsetting changes for a device until the device is 
resumed (there's already a comment about that in the hub driver).

What do you think?

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to