- Properly dismiss the enable status changed interrupt to avoid an interrupt storm after a device is disconnected
svn path=/branches/usb-bringup-trunk/; revision=55189
- Fix GetPortStatus() and remove the cached status stuff (except for reset that we have to cache because the EHCI spec has no port reset complete bit)
svn path=/branches/usb-bringup-trunk/; revision=55188
- Revert r55167 now that OHCI is fixed
- USB drives attached to an OHCI controller before boot are now enumerated without a reconnect needed
svn path=/branches/usb-bringup-trunk/; revision=55187
- Remove the hacky way of determining if a device connect occurred (prone to all sorts of race conditions) and just always create a device since the only reason we reset right now is for a device connect
svn path=/branches/usb-bringup-trunk/; revision=55186
- Fix and enable the proper GetPortStatus implementation
- Remove the old hacked cached port status mess
svn path=/branches/usb-bringup-trunk/; revision=55185
- Fix StartController() to perform initialization according to OHCI spec
- Fixes the infamous OHCI initialization hang on real hardware
svn path=/branches/usb-bringup-trunk/; revision=55181
- No need to turn off interrupts
- Check if bios is active
- Check for timeouts when resetting host controller
svn path=/branches/usb-bringup-trunk/; revision=55171
- Don't turn off interrupts before setting the OHCI_OWNERSHIP_CHANGE_REQUEST bit because it prevents the SMM driver from receiving the interrupt that tells it to give up ownership of the host controller
- This fix should be merged to Haiku also which has the same bug
svn path=/branches/usb-bringup-trunk/; revision=55170
- Add debug trace
[USBOHCI]
- Implement proper GetPortStatus
[USBHUB]
- Reset all connected ports before sending first SCE
- USB Devices present before booting are now detected with OHCI controller. EHCI code is present but not yet activated
svn path=/branches/usb-bringup-trunk/; revision=55167
- Rewrite pending SRB handling and change some behavior of the IRP queue
- The caller is no longer responsible for checking whether it can call USBSTOR_QueueNextRequest; frozen IRP queue and pending SRB are both handled for them
- It's no longer required for the caller of USBSTOR_QueueTerminateRequest to know whether the SRB was active (which was impossible before when handling a cancellation)
- Many potential race issues with IRP cancellation are eliminated
- Debugging hung SRBs is much easier now that pointer to the active one is stored in the FDO
svn path=/branches/usb-bringup-trunk/; revision=55157
- Fix bugs introduced in 55134, 55135
- USB Mass Storage devices should now automatically install again
svn path=/branches/usb-bringup-trunk/; revision=55147
- Fix cancellation for IRPs that have already been dispatched for processing by IoStartNextPacket
- Don't complete IRPs with the IRP list lock held
- Clear the cancel routine before completing the IRP
svn path=/branches/usb-bringup-trunk/; revision=55138
- Check if the device is a composite device
- Report USB\COMPOSITE as compatible id when a usb compsite device is detected
svn path=/branches/usb-bringup-trunk/; revision=55134
- Use the same lock in the IUSBQueue as in the IDMAMemoryManager
- add debug traces (default off)
svn path=/branches/usb-bringup-trunk/; revision=55110
- Compute the frame interval correctly
- Fixes a deadlock on real hardware after enabling interrupts
svn path=/branches/usb-bringup-trunk/; revision=55094
- Fix a broken check that resulted in freeing the same device object twice
- Enable the IoDetachDevice call in usbstor now that the kernel bug is fixed
svn path=/branches/usb-bringup-trunk/; revision=55086
- Implement device disconnect indication for usbehci and usbohci
- Implement device removal for FDOs and PDOs in usbstor and usbhub
svn path=/branches/usb-bringup-trunk/; revision=55080