user/sven/linux.git/tools/usb, branch v4.14.72

tools: usb: ffs-test: Fix build on big endian systems

2018-09-05T07:26:26Z

[ Upstream commit a2b22dddc7bb6110ac3b5ed1a60aa9279836fadb ] The tools/usb/ffs-test.c file defines cpu_to_le16/32 by using the C library htole16/32 function calls. However, cpu_to_le16/32 are used when initializing structures, i.e in a context where a function call is not allowed. It works fine on little endian systems because htole16/32 are defined by the C library as no-ops. But on big-endian systems, they are actually doing something, which might involve calling a function, causing build failures, such as: ffs-test.c:48:25: error: initializer element is not constant #define cpu_to_le32(x) htole32(x) ^~~~~~~ ffs-test.c:128:12: note: in expansion of macro ‘cpu_to_le32’ .magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2), ^~~~~~~~~~~ To solve this, we code cpu_to_le16/32 in a way that allows them to be used when initializing structures. This fix was imported from meta-openembedded/android-tools/fix-big-endian-build.patch written by Thomas Petazzoni . CC: Thomas Petazzoni Signed-off-by: Peter Senna Tschudin Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usbip: dynamically allocate idev by nports found in sysfs

2018-08-03T05:50:26Z

[ Upstream commit de19ca6fd72c7dd45ad82403e7b3fe9c74ef6767 ] As the amount of available ports varies by the kernels build configuration. To remove the limitation of the fixed 128 ports we allocate the amount of idevs by using the number we get from the kernel. Signed-off-by: Michael Grzeschik Acked-by: Shuah Khan (Samsung OSG) Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usbip: usbip_detach: Fix memory, udev context and udev leak

2018-08-03T05:50:26Z

[ Upstream commit d179f99a651685b19333360e6558110da2fe9bd7 ] detach_port() fails to call usbip_vhci_driver_close() from its error path after usbip_vhci_detach_device() returns failure, leaking memory allocated in usbip_vhci_driver_open() and holding udev_context and udev references. Fix it to call usbip_vhci_driver_close(). Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

tools/usbip: fixes build with musl libc toolchain

2018-03-19T07:42:53Z

[ Upstream commit 77be4c878c72e411ad22af96b6f81dd45c26450a ] Indeed musl doesn't define old SIGCLD signal name but only new one SIGCHLD. SIGCHLD is the new POSIX name for that signal so it doesn't change anything on other libcs. This fixes this kind of build error: usbipd.c: In function ‘set_signal’: usbipd.c:459:12: error: 'SIGCLD' undeclared (first use in this function) sigaction(SIGCLD, &act, NULL); ^~~~~~ usbipd.c:459:12: note: each undeclared identifier is reported only once for each function it appears in Makefile:407: recipe for target 'usbipd.o' failed make[3]: *** [usbipd.o] Error 1 Signed-off-by: Julien BOIBESSOT Acked-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usbip: list: don't list devices attached to vhci_hcd

2018-02-03T16:39:20Z

commit ef824501f50846589f02173d73ce3fe6021a9d2a upstream. usbip host lists devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Fix it to check and not list devices that are attached to vhci_hcd. Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

usbip: prevent bind loops on devices attached to vhci_hcd

2018-02-03T16:39:20Z

commit ef54cf0c600fb8f5737fb001a9e357edda1a1de8 upstream. usbip host binds to devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Unbind followed by bind works, however device is left in a bad state with accesses via the attached busid result in errors and system hangs during shutdown. Fix it to check and bail out if the device is already attached to vhci_hcd. Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

usbip: fix usbip bind writing random string after command in match_busid

2018-01-02T19:31:13Z

commit 544c4605acc5ae4afe7dd5914147947db182f2fb upstream. usbip bind writes commands followed by random string when writing to match_busid attribute in sysfs, caused by using full variable size instead of string length. Signed-off-by: Juan Zea Acked-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

usbip: prevent vhci_hcd driver from leaking a socket pointer address

2017-12-20T09:10:19Z

commit 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 upstream. When a client has a USB device attached over IP, the vhci_hcd driver is locally leaking a socket pointer address via the /sys/devices/platform/vhci_hcd/status file (world-readable) and in debug output when "usbip --debug port" is run. Fix it to not leak. The socket pointer address is not used at the moment and it was made visible as a convenient way to find IP address from socket pointer address by looking up /proc/net/{tcp,tcp6}. As this opens a security hole, the fix replaces socket pointer address with sockfd. Reported-by: Secunia Research Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

usbip: tools: Install all headers needed for libusbip development

2017-12-10T12:40:42Z

[ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ] usbip_host_driver.h now depends on several additional headers, which need to be installed along with it. Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver ...") Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with ...") Signed-off-by: Ben Hutchings Acked-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usbip: fix usbip attach to find a port that matches the requested speed

2017-12-10T12:40:37Z

commit 1ac7c8a78be85f84b019d3d2742d1a9f07255cc5 upstream. usbip attach fails to find a free port when the device on the first port is a USB_SPEED_SUPER device and non-super speed device is being attached. It keeps checking the first port and returns without a match getting stuck in a loop. Fix it check to find the first port with matching speed. Reported-by: Juan Zea Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman