> > >Not entirely true. OHCI tries to safeguard against broken drivers, > > >and in 2.5 anything using the new HCD code in usbcore does the > > >same safeguarding. (Such as EHCI ...) The UHCI drivers may do > > >things differently. > > > > Actually I would not call it broken driver. I think it make sense for HCD > > or USB core to cancel all outstanding requests prior to calling > 'disconnect'. > >Not without (a) defining a new URB status code to indicate >"canceled due to disconnect, and (b) doing a major rework >of the relationship between the hub driver and the HCDs. (a) == -ENOENT (ie URB killed). It doesn't really matter who called unlink_urb. We can add new one if it does.
>It'd be possible to do (b) in the context of 2.5, but that'd be >a fair amount of work. But you're saying that OHCI and EHCI already do that ? >Are you volunteering to help change all the HCDs, and the hub driver ? >And all the other parts of usbcore that'd be affected by such a change ? Not yet :) I still have to do a lot of things for Bluetooth. > > Why can't HCD just cancel them itself before calling > > disconnect ? > >As I wrote earlier, the HCD isn't calling disconnect. It's >the hub driver. I meant any part of USB core. Whoever calls disconnect could potentially tell HCD to cancel all requests on this device. Max _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
