kernel/linux.git/drivers/usb/wusbcore, branch v3.18.62

USB: wusbcore: fix NULL-deref at probe

2017-04-18T05:55:53+00:00

commit 03ace948a4eb89d1cf51c06afdfc41ebca5fdb27 upstream. Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. This specifically fixes the NULL-pointer dereference when probing HWA HC devices. Fixes: df3654236e31 ("wusb: add the Wire Adapter (WA) core") Cc: Inaky Perez-Gonzalez Cc: David Vrabel Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

usb: hub: rename khubd to hub_wq in documentation and comments

2014-09-24T05:33:19+00:00

USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: wusbcore: fix device disconnect on rekey timeout

2014-09-24T05:06:59+00:00

If three or more wireless devices are connected and two of them disconnect between 1-3 seconds apart, it can cause the HWA to disconnect the remaining devices due to failing to see a DN_Alive message from them. This happens because when the HWA detects that the first device is gone, it will attempt to rekey the remaining devices. If one of the devices is not responding because it has also been disconnected but not yet timed out, the synchronous rekey operation running on the wusbd workqueue can block for up to 5 seconds. This will prevent the KEEPALIVE timer from running and DN_Alive messages from being processed because they are processed by the same workqueue. This patch moves the rekey operation to a separate workqueue since it is the only wusb work item that needs to communicate directly with wireless devices. The rest of the WUSB work items either perform no device IO or communicate directly with the host controller and should not be blocked out by a non-responding wireless device. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman

usb: wusbcore: skip done segs before completing aborted transfer

2014-09-24T05:06:59+00:00

When completing an aborted transfer, skip done segs before calling wa_complete_remaining_xfer_segs to avoid a runtime warning. The warning is harmless in this case but avoiding it prevents false error reports. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman

usb: wusbcore: USB_WUSB_CBAF depends on USB

2014-09-24T05:06:33+00:00

Add USB build dependency for USB_WUSB_CBAF. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman

usb: wusbcore: remove USB_WUSB build dependency on PCI

2014-09-24T05:06:33+00:00

Wireless USB does not require PCI so remove USB_WUSB build dependency on PCI. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman

wusb: delete double assignment

2014-09-24T05:03:54+00:00

Delete successive assignments to the same location. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression i; @@ *i = ...; i = ...; // Signed-off-by: Julia Lawall Signed-off-by: Greg Kroah-Hartman

usb: wusbcore: fix below build warning

2014-08-19T16:28:53+00:00

linux-2.6/drivers/usb/wusbcore/wa-xfer.c: In function 'wa_buf_in_cb': linux-2.6/drivers/usb/wusbcore/wa-xfer.c:2590: warning: 'rpipe' may be used uninitialized in this function Signed-off-by: Peter Chen Suggested-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman

USB: wusbcore: fix control-pipe directions

2014-05-27T22:04:10+00:00

Fix incorrect pipe directions in control requests (which has been silently fixed up by USB core). Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

usb: wusbcore: fix panic in wusbhc_chid_set

2014-04-24T19:45:41+00:00

If no valid CHID value has previously been set on an HWA, writing a value of all zeros will cause a kernel panic in uwb_radio_stop because wusbhc->uwb_rc has not been set. This patch skips the call to uwb_radio_stop if wusbhc->uwb_rc has not been initialized. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman