mirror of
https://github.com/edk2-porting/linux-next.git
synced 2025-01-06 20:53:54 +08:00
5df2be6333
There are various bug reports about oopses / hangs with the uas driver, which all point to the abort-command and logical-unit-reset (task-management) error handling paths. Getting these right is very hard, there are quite a few corner cases, and testing is almost impossible since under normal operation these code paths are not used at all. Another problem is that there are also some cases where it simply is not clear what to do at all. E.g. over usb-2 multiple outstanding commands share the same endpoint. What if a command gets aborted while its sense urb is half way through completing (so some data has been transfered but not all). Since the urb is not yet complete we don't know if the sense urb is actually for this command, or for one of the other oustanding commands. If it is for one of the other commands and we cancel it, then we end up in an undefined state. But if it is actually for the command we're aborting, and the abort succeeds, then it may never complete... This exact same problem applies to logical unit resets too, if there are multiple luns, then commands outstanding on both luns share the sense endpoint. If there is only a single lun, then doing a logical unit reset is little better then doing a full usb device reset. So summarizing because: 1) abort / lun-reset is very tricky to get right 2) Not being able to test the tricky code, which means it will have bugs 3) This being a code path which under normal operation will never happen, so being slow / sub-optimal here is not really an issue 4) Under error conditions we will still be able to recover through usb device resets. 5) This may be a bit slower in some cases, but this is actually faster in cases where the bridge ship has locked up, which seems to be the most common error case sofar. This commit removes the abort / lun-reset error handling paths, and also the taks-mgmt code since those are the only 2 task-mgmt users. Leaving only the (tested and testable) usb-device-reset error handling path in place. Note I realize that this is somewhat of a big hammer, but currently people are seeing very hard to debug oopses with uas. First let focus on making uas work reliable, then we can later look into adding more fine grained error handling. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
---|---|---|
.. | ||
atm | ||
c67x00 | ||
chipidea | ||
class | ||
common | ||
core | ||
dwc2 | ||
dwc3 | ||
early | ||
gadget | ||
host | ||
image | ||
misc | ||
mon | ||
musb | ||
phy | ||
renesas_usbhs | ||
serial | ||
storage | ||
usbip | ||
wusbcore | ||
Kconfig | ||
Makefile | ||
README | ||
usb-skeleton.c |
To understand all the Linux-USB framework, you'll use these resources: * This source code. This is necessarily an evolving work, and includes kerneldoc that should help you get a current overview. ("make pdfdocs", and then look at "usb.pdf" for host side and "gadget.pdf" for peripheral side.) Also, Documentation/usb has more information. * The USB 2.0 specification (from www.usb.org), with supplements such as those for USB OTG and the various device classes. The USB specification has a good overview chapter, and USB peripherals conform to the widely known "Chapter 9". * Chip specifications for USB controllers. Examples include host controllers (on PCs, servers, and more); peripheral controllers (in devices with Linux firmware, like printers or cell phones); and hard-wired peripherals like Ethernet adapters. * Specifications for other protocols implemented by USB peripheral functions. Some are vendor-specific; others are vendor-neutral but just standardized outside of the www.usb.org team. Here is a list of what each subdirectory here is, and what is contained in them. core/ - This is for the core USB host code, including the usbfs files and the hub class driver ("khubd"). host/ - This is for USB host controller drivers. This includes UHCI, OHCI, EHCI, and others that might be used with more specialized "embedded" systems. gadget/ - This is for USB peripheral controller drivers and the various gadget drivers which talk to them. Individual USB driver directories. A new driver should be added to the first subdirectory in the list below that it fits into. image/ - This is for still image drivers, like scanners or digital cameras. ../input/ - This is for any driver that uses the input subsystem, like keyboard, mice, touchscreens, tablets, etc. ../media/ - This is for multimedia drivers, like video cameras, radios, and any other drivers that talk to the v4l subsystem. ../net/ - This is for network drivers. serial/ - This is for USB to serial drivers. storage/ - This is for USB mass-storage drivers. class/ - This is for all USB device drivers that do not fit into any of the above categories, and work for a range of USB Class specified devices. misc/ - This is for all USB device drivers that do not fit into any of the above categories.