- 14 Dec, 2017 31 commits
-
-
Guenter Roeck authored
commit 811d7e02 upstream. vpd sections are initialized during probe and thus should be destroyed in the remove function. Fixes: 049a59db ("firmware: Google VPD sysfs driver") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Robin H. Johnson authored
commit 0946b2fb upstream. The help for FIRMWARE_IN_KERNEL still references the firmware_install command that was recently removed by commit 5620a0d1 ("firmware: delete in-kernel firmware"). Clean up the message to direct the user to their distribution's linux-firmware package, and remove any reference to firmware being included in the kernel source tree. Fixes: 5620a0d1 ("firmware: delete in-kernel firmware"). Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
Robin H. Johnson <robbat2@gentoo.org> Signed-off-by:
-
Paul Meyer authored
commit 297d6b6e upstream. While reading in more than one block (50) of KVP records, the allocation goes per block, but the reads used the total number of allocated records (without resetting the pointer/stream). This causes the records buffer to overrun when the refresh reads more than one block over the previous capacity (e.g. reading more than 100 KVP records whereas the in-memory database was empty before). Fix this by reading the correct number of KVP records from file each time. Signed-off-by:
Paul Meyer <Paul.Meyer@microsoft.com> Signed-off-by:
Long Li <longli@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
commit 7fa32e5e upstream. The current rescind processing code will not correctly handle the case where the host immediately rescinds a channel that has been offerred. In this case, we could be blocked in the open call and since the channel is rescinded, the host will not respond and we could be blocked forever in the vmbus open call.i Fix this problem. Signed-off-by:
-
Gregory CLEMENT authored
commit 6702abb3 upstream. The direction_output callback of the gpio_chip structure is supposed to set the output direction but also to set the value of the gpio. For the armada-37xx driver this callback acted as the gpio_set_direction callback for the pinctrl. This patch fixes the behavior of the direction_output callback by also applying the value received as parameter. Fixes: 5715092a ("pinctrl: armada-37xx: Add gpio support") Reported-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Martin Blumenstingl authored
commit 96748823 upstream. The Meson GXBB and newer SoCs have a few more registers than the older Meson8 and Meson8b SoCs. Use a separate regmap config to limit the older SoCs to the DELTA_10 register. Fixes: 6c76ed31 ("iio: adc: meson-saradc: add Meson8b SoC compatibility") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Martin Blumenstingl authored
commit d85eed9f upstream. Meson8 and Meson8b do not have the MESON_SAR_ADC_REG11 register. The bandgap setting for these SoCs is configured in the MESON_SAR_ADC_DELTA_10 register instead. Make the driver aware of this difference and use the correct bandgap register depending on the SoC. This has worked fine on Meson8 and Meson8b because the bootloader is already initializing the bandgap setting. Fixes: 6c76ed31 ("iio: adc: meson-saradc: add Meson8b SoC compatibility") Signed-off-by:
-
Martin Blumenstingl authored
commit 7a6b0420 upstream. Meson8 and Meson8b SoCs use the the SAR ADC gate clock provided by the MESON_SAR_ADC_REG3 register within the SAR ADC register area. According to the datasheet (and the existing MESON_SAR_ADC_REG3_CLK_EN definition) the gate is on bit 30. The fls() function returns the last set bit, which is "bit index + 1" (fls(MESON_SAR_ADC_REG3_CLK_EN) returns 31). Fix this by switching to __ffs() which returns the first set bit, which is bit 30 in our case. This off by one error results in the ADC not being usable on devices where the bootloader did not enable the clock. Fixes: 3adbf342 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs") Signed-off-by:
-
Pan Bian authored
commit 81b039ec upstream. Function platform_get_irq_byname() returns a negative error code on failure, and a zero or positive number on success. However, in function cpcap_adc_probe(), positive IRQ numbers are also taken as error cases. Use "if (ddata->irq < 0)" instead of "if (!ddata->irq)" to validate the return value of platform_get_irq_byname(). Signed-off-by:
Pan Bian <bianpan2016@163.com> Fixes: 25ec2496 ("iio: adc: cpcap: Add minimal support for CPCAP PMIC ADC") Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.co.uk> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Peter Meerwald-Stadler authored
commit ad44a9f8 upstream. As per ABI temperature should be in milli Celsius after scaling, not Celsius Note on stable cc. This driver is breaking the standard IIO ABI. (JC) Signed-off-by:
Peter Meerwald-Stadler <pmeerw@pmeerw.net> Acked-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
-
Arnd Bergmann authored
commit 6d745ee8 upstream. The ADC driver can trigger on either the timer or the lptim trigger, but it only uses a Kconfig 'select' statement to ensure that the first of the two is present. When the lptim trigger is enabled as a loadable module, and the adc driver is built-in, we now get a link error: drivers/iio/adc/stm32-adc.o: In function `stm32_adc_get_trig_extsel': stm32-adc.c:(.text+0x4e0): undefined reference to `is_stm32_lptim_trigger' We could use a second 'select' statement and always have both trigger drivers enabled when the adc driver is, but it seems that the lptimer trigger was intentionally left optional, so it seems better to keep it that way. This adds a hack to use 'IS_REACHABLE()' rather than 'IS_ENABLED()', which avoids the link error, but instead leads to the lptimer trigger not being used in the broken configuration. I've added a runtime warning for this case to help users figure out what they did wrong if this should ever be done by accident. Fixes: f0b638a7 ("iio: adc: stm32: add support for lptimer triggers") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
weiping zhang authored
commit e60ea67b upstream. index can be reused by other virtio device. Signed-off-by:
weiping zhang <zhangweiping@didichuxing.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Stephane Grosjean authored
commit 91785de6 upstream. Don't rely on can_get_echo_skb() return value to wake the network tx queue up: can_get_echo_skb() returns 0 if the echo array slot was not occupied, but also when the DLC of the released echo frame was 0. Signed-off-by:
Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Martin Kelly authored
commit 12147edc upstream. In mcba_usb, we have observed that when you unplug the device, the driver will endlessly resubmit failing URBs, which can cause CPU stalls. This issue is fixed in mcba_usb by catching the codes seen on device disconnect (-EPIPE and -EPROTO). This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it in the same way. Signed-off-by:
Martin Kelly <mkelly@xevo.com> Signed-off-by:
-
Martin Kelly authored
commit 7a31ced3 upstream. In mcba_usb, we have observed that when you unplug the device, the driver will endlessly resubmit failing URBs, which can cause CPU stalls. This issue is fixed in mcba_usb by catching the codes seen on device disconnect (-EPIPE and -EPROTO). This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it in the same way. Signed-off-by:
-
Martin Kelly authored
commit bd352e1a upstream. In mcba_usb, we have observed that when you unplug the device, the driver will endlessly resubmit failing URBs, which can cause CPU stalls. This issue is fixed in mcba_usb by catching the codes seen on device disconnect (-EPIPE and -EPROTO). This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it in the same way. Signed-off-by:
-
Martin Kelly authored
commit c7f33023 upstream. When we unplug the device, we can see both -EPIPE and -EPROTO depending on exact timing and what system we run on. If we continue to resubmit URBs, they will immediately fail, and they can cause stalls, especially on slower CPUs. Fix this by not resubmitting on -EPROTO, as we already do on -EPIPE. Signed-off-by:
-
Martin Kelly authored
commit 6aa8d594 upstream. In mcba_usb, we have observed that when you unplug the device, the driver will endlessly resubmit failing URBs, which can cause CPU stalls. This issue is fixed in mcba_usb by catching the codes seen on device disconnect (-EPIPE and -EPROTO). This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it in the same way. Signed-off-by:
-
Jimmy Assarsson authored
commit 8bd13bd5 upstream. Avoid flooding the kernel log with "Formate error", if incomplete message are received. Signed-off-by:
Jimmy Assarsson <jimmyassarsson@gmail.com> Signed-off-by:
-
Jimmy Assarsson authored
commit e84f44eb upstream. The conditon in the while-loop becomes true when actual_length is less than 2 (MSG_HEADER_LEN). In best case we end up with a former, already dispatched msg, that got msg->len greater than actual_length. This will result in a "Format error" error printout. Problem seen when unplugging a Kvaser USB device connected to a vbox guest. warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Signed-off-by:
-
Jimmy Assarsson authored
commit 435019b4 upstream. The allocated buffer was not freed if usb_submit_urb() failed. Signed-off-by:
-
Oliver Stäbler authored
commit f6c23b17 upstream. After commit d75b1ade ("net: less interrupt masking in NAPI") napi repoll is done only when work_done == budget. So we need to return budget if there are still packets to receive. Signed-off-by:
Oliver Stäbler <oliver.staebler@bytesatwork.ch> Signed-off-by:
-
Marc Kleine-Budde authored
commit 29c64b17 upstream. Enable FLEXCAN_QUIRK_BROKEN_PERR_STATE for VF610 to report correct state transitions. Tested-by:
Mirza Krak <mirza.krak@gmail.com> Signed-off-by:
-
Stephane Grosjean authored
commit 5c2cb02e upstream. PCI/PCIe drivers for PEAK-System CAN/CAN-FD interfaces do some access to the PCI config during probing. In case one of these accesses fails, a POSITIVE PCIBIOS_xxx error code is returned back. This POSITIVE error code MUST be converted into a NEGATIVE errno for the probe() function to indicate it failed. Using the pcibios_err_to_errno() function, we make sure that the return code will always be negative. Signed-off-by:
-
Martin Kelly authored
commit 1cb35a33 upstream. Currently, when you disconnect the device, the driver infinitely resubmits all URBs, so you see: Rx URB aborted (-32) in an infinite loop. Fix this by catching -EPIPE (what we get in urb->status when the device disconnects) and not resubmitting. With this patch, I can plug and unplug many times and the driver recovers correctly. Signed-off-by:
-
John Keeping authored
commit a3acc696 upstream. The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT must have the value "1", but when this feature was first implemented we rejected any non-zero values. This was adjusted to accept all non-zero values (while now rejecting zero) in commit 53642399 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace programs that worked previously by returning EINVAL when Reserved1 == 0 which was previously the only value that succeeded! If we just set the field to "1" ourselves, both old and new userspace programs continue to work correctly and, as a bonus, old programs are now compliant with the specification without having to fix anything themselves. Fixes: 53642399 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT") Signed-off-by:
John Keeping <john@metanate.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Johan Hovold authored
commit 90dbad8c upstream. Make sure to hold the tty lock as required when calling tty-driver close() (e.g. to avoid racing with hangup()). Note that the serport active flag is currently set under the lock at controller open, but really isn't protected by it. Fixes: cd6484e1 ("serdev: Introduce new bus for serial attached devices") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 8bcd4e6a upstream. Make sure to use a properly refcounted tty_struct in write_wake up to avoid dereferencing a NULL-pointer when a port is being hung up. Fixes: bed35c6d ("serdev: add a tty port controller driver") Signed-off-by:
-
Johan Hovold authored
commit eb281683 upstream. The receive_buf tty-port callback should return the number of bytes accepted and must specifically never return a negative errno (or a value larger than the buffer size) to the tty layer. A serdev driver not providing a receive_buf callback would currently cause the flush_to_ldisc() worker to spin in a tight loop when the tty buffer pointers are incremented with -EINVAL (-22) after data has been received. A serdev driver occasionally returning a negative errno (or a too large byte count) could cause information leaks or crashes when accessing memory outside the tty buffers in consecutive callbacks. Fixes: cd6484e1 ("serdev: Introduce new bus for serial attached devices") Signed-off-by:
-
Roger Quadros authored
commit a4f0927e upstream. Currently UDC core calls ->udc_set_speed() with the speed parameter containing the maximum speed supported by the gadget function driver. This might very well be more than that supported by the UDC controller driver. Select the lesser of the 2 speeds so both UDC and gadget function driver are operating within limits. This fixes PHY Erratic errors and 2 second enumeration delay on TI's AM437x platforms. Fixes: 6099eca796ae ("usb: gadget: core: introduce ->udc_set_speed() method") Reported-by:
Dylan Howey <Dylan.Howey@tennantco.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Yoshihiro Shimoda authored
commit a58204ab upstream. This controller on R-Car Gen3 has 6 pipes that included PIPE 0 for control actually. But, the datasheet has error in writing as it has 31 pipes. (However, the previous code defined 30 pipes wrongly...) Anyway, this patch fixes it. Fixes: 746bfe63 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
- 10 Dec, 2017 9 commits
-
-
Greg Kroah-Hartman authored
-
Kees Cook authored
commit b562c171 upstream. The refcount_t protection on x86 was not intended to use the stricter GPL export. This adjusts the linkage again to avoid a regression in the availability of the refcount API. Reported-by:
Dave Airlie <airlied@gmail.com> Fixes: 7a46ec0e ("locking/refcounts, x86/asm: Implement fast refcount overflow protection") Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Ivan Kozik <ivan@ludios.org> Cc: Thomas Backlund <tmb@mageia.org> Signed-off-by:
-
Colin Ian King authored
commit 1d5a3158 upstream. The variable temp is incorrectly being updated, instead it should be offset otherwise the loop just reads the same capability value and loops forever. Thanks to Alan Stern for pointing out the correct fix to my original fix. Fix also cleans up clang warning: drivers/usb/host/ehci-dbg.c:840:4: warning: Value stored to 'temp' is never read Fixes: d49d4317 ("USB: misc ehci updates") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Oliver Neukum authored
commit 446f666d upstream. USBDEVFS_URB_ISO_ASAP must be accepted only for ISO endpoints. Improve sanity checking. Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Oliver Neukum <oneukum@suse.com> Acked-by:
-
Masakazu Mokuno authored
commit 81cf4a45 upstream. As most of BOS descriptors are longer in length than their header 'struct usb_dev_cap_header', comparing solely with it is not sufficient to avoid out-of-bounds access to BOS descriptors. This patch adds descriptor type specific length check in usb_get_bos_descriptor() to fix the issue. Signed-off-by:
Masakazu Mokuno <masakazu.mokuno@gmail.com> Signed-off-by:
-
Yu Chen authored
commit 80e45769 upstream. Check vdev->real_port 0 to avoid panic [ 9.261347] [<ffffff800884a390>] xhci_free_virt_devices_depth_first+0x58/0x108 [ 9.261352] [<ffffff800884a814>] xhci_mem_cleanup+0x1bc/0x570 [ 9.261355] [<ffffff8008842de8>] xhci_stop+0x140/0x1c8 [ 9.261365] [<ffffff80087ed304>] usb_remove_hcd+0xfc/0x1d0 [ 9.261369] [<ffffff80088551c4>] xhci_plat_remove+0x6c/0xa8 [ 9.261377] [<ffffff80086e928c>] platform_drv_remove+0x2c/0x70 [ 9.261384] [<ffffff80086e6ea0>] __device_release_driver+0x80/0x108 [ 9.261387] [<ffffff80086e7a1c>] device_release_driver+0x2c/0x40 [ 9.261392] [<ffffff80086e5f28>] bus_remove_device+0xe0/0x120 [ 9.261396] [<ffffff80086e2e34>] device_del+0x114/0x210 [ 9.261399] [<ffffff80086e9e00>] platform_device_del+0x30/0xa0 [ 9.261403] [<ffffff8008810bdc>] dwc3_otg_work+0x204/0x488 [ 9.261407] [<ffffff80088133fc>] event_work+0x304/0x5b8 [ 9.261414] [<ffffff80080e31b0>] process_one_work+0x148/0x490 [ 9.261417] [<ffffff80080e3548>] worker_thread+0x50/0x4a0 [ 9.261421] [<ffffff80080e9ea0>] kthread+0xe8/0x100 [ 9.261427] [<ffffff8008083680>] ret_from_fork+0x10/0x50 The problem can occur if xhci_plat_remove() is called shortly after xhci_plat_probe(). While xhci_free_virt_devices_depth_first been called before the device has been setup and get real_port initialized. The problem occurred on Hikey960 and was reproduced by Guenter Roeck on Kevin with chromeos-4.4. Fixes: ee8665e2 ("xhci: free xhci virtual devices with leaf nodes first") Cc: Guenter Roeck <groeck@google.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Tested-by:
Fan Ning <fanning4@hisilicon.com> Signed-off-by:
Li Rui <lirui39@hisilicon.com> Signed-off-by:
yangdi <yangdi10@hisilicon.com> Signed-off-by:
Yu Chen <chenyu56@huawei.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit e4ec40ec upstream. xHC can generate two events for a short transfer if the short TRB and last TRB in the TD are not the same TRB. The driver will handle the TD after the first short event, and remove it from its internal list. Driver then incorrectly prints a warning for the second event: "WARN Event TRB for slot x ep y with no TDs queued" Fix this by not printing a warning if we get a event on a empty list if the previous event was a short event. Signed-off-by:
-
Johan Hovold authored
commit 33c309eb upstream. Fix bus-node lookup during registration, which ended up searching the whole device tree depth-first starting at the parent (or grand parent) rather than just matching on its children. To make things worse, the parent (or grand-parent) node could end being prematurely freed as well. Fixes: ef6a7bcf ("usb: ulpi: Support device discovery via DT") Reported-by:
Peter Robinson <pbrobinson@gmail.com> Reported-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Mike Looijmans authored
commit 973593a9 upstream. Sometimes the USB device gets confused about the state of the initialization and the connection fails. In particular, the device thinks that it's already set up and running while the host thinks the device still needs to be configured. To work around this issue, power-cycle the hub's output to issue a sort of "reset" to the device. This makes the device restart its state machine and then the initialization succeeds. This fixes problems where the kernel reports a list of errors like this: usb 1-1.3: device not accepting address 19, error -71 The end result is a non-functioning device. After this patch, the sequence becomes like this: usb 1-1.3: new high-speed USB device number 18 using ci_hdrc usb 1-1.3: device not accepting address 18, error -71 usb 1-1.3: new high-speed USB device number 19 using ci_hdrc usb 1-1.3: device not accepting address 19, error -71 usb 1-1-port3: attempt power cycle usb 1-1.3: new high-speed USB device number 21 using ci_hdrc usb-storage 1-1.3:1.2: USB Mass Storage device detected Signed-off-by:
Mike Looijmans <mike.looijmans@topic.nl> Acked-by:
-
