[PATCH 1/4] usb: mtu3: add generic compatible string

The mtu3 driver is a generic driver for MediaTek usb3 DRD IP, add a generic compatible to avoid confusion when support new SoCs but use a compatible with specific SoC's name "mt8173". Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/mtu3_plat.c |1 + 1 file

[PATCH 2/4] usb: xhci-mtk: add generic compatible string

The xhci-mtk driver is a generic driver for MediaTek xHCI IP, add a generic compatible to avoid confusion when support new SoCs but use a compatible with specific SoC's name "mt8173". Signed-off-by: Chunfeng Yun --- drivers/usb/host/xhci-mtk.c |1 + 1 file

[PATCH 3/4] dt-bindings: mt8173-mtu3: add generic compatible and rename file

The mt8173-mtu3.txt actually holds the bindings for all mediatek SoCs with usb3 DRD IP, so add a generic compatible and change the name to mtu3.txt. Signed-off-by: Chunfeng Yun --- .../bindings/usb/{mt8173-mtu3.txt => mtu3.txt} |6 -- 1 file changed, 4

[PATCH 4/4] dt-bindings: mt8173-xhci: add generic compatible and rename file

The mt8173-xhci.txt actually holds the bindings for all mediatek SoCs with xHCI controller, so add a generic compatible and change the name to xhci-mtk.txt to reflect that. Signed-off-by: Chunfeng Yun --- .../bindings/usb/{mt8173-xhci.txt => xhci-mtk.txt} | 10

[PATCH] usb: dwc3: omap: fix error return code in dwc3_omap_probe()

platform_get_irq() returns an error code, but the dwc3-omap driver ignores it and always returns -EINVAL. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

new usb LTE modem device

Hi all, I'm working to port OpenWRT/LEDE on a new router with embedded usb LTE modem. The modem have 3 qmi_wwan interfaces and 2 option. I would like to prepare the patch, but before I would like to know if using the QMI_FIXED_INTF macro is the best way to identify the interface or if there is a

[PATCH] usb: imx21-hcd: fix error return code in imx21_probe()

platform_get_irq() returns an error code, but the imx21-hcd driver ignores it and always returns -ENXIO. This is not correct, and prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

[PATCH v5 1/1] usb:host:xhci support option to disable the xHCI USB2 HW LPM

XHCI specification 1.1 does not require xHCI-compliant controllers to always enable hardware USB2 LPM. However, the current xHCI driver always enable it when seeing HLC=1. This patch supports an option for users to control disabling USB2 Hardware LPM via DT/ACPI attribute. This option is needed in

Re: [PATCH v2 2/3] usb: chipidea: Hook into mux framework to toggle usb switch

Quoting Peter Rosin (2017-07-31 03:33:22) > On 2017-07-14 23:40, Stephen Boyd wrote: > > @@ -1964,16 +1965,26 @@ void ci_hdrc_gadget_destroy(struct ci_hdrc *ci) > > > > static int udc_id_switch_for_device(struct ci_hdrc *ci) > > { > > + int ret = 0; > > + > > if (ci->is_otg) > >

Re: [PATCH v2 2/4] usb: common: Move u_serial from gadget/function to usb/common

Hi, On 08/07/2017 04:13 PM, Felipe Balbi wrote: > Hi, > > Lu Baolu writes: >> The component u_serial provides a glue layer between TTY layer >> and a USB gadget device needed to provide a basic serial port >> functionality. Currently, u_serial sits under gadget/function

work as our crude oil facilitator

Venon Oil/Energy Corporation Us is looking for a partner, to be our coordinator in Europe and Asia, which you will act as an intermediary between our company and the final buyer of petroleum products in those regions,Inform us if you are interested Sincerely, Randell Waters (Managing Director,

Re: [PATCH] arm64: dts: hi6220: improve g-tx-fifo-size setting for usb device

On Sun, Aug 6, 2017 at 10:01 PM, Shawn Guo wrote: > From: Shawn Guo > > The current usb device g-tx-fifo-size setting in DT causes two problems > for kernel driver. > > 1. On hi6220, there are 15 tx_fifo dedicated for all EPs except EP0, >while DT

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

On Mon, Aug 7, 2017 at 2:05 PM, John Stultz wrote: > So, with recent testing with my HiKey board, I've been noticing some > quirky behavior with my USB eth adapter. > > Basically, pluging the usb eth adapter in and then removing it, when > plugging it back in I often find

unregister_netdevice: waiting for eth0 to become free. Usage count = 1

So, with recent testing with my HiKey board, I've been noticing some quirky behavior with my USB eth adapter. Basically, pluging the usb eth adapter in and then removing it, when plugging it back in I often find that its not detected, and the system slowly spits out the following message over and

Re: [PATCH V1 0/3] asix: Improve robustness

From: Dean Jenkins Date: Mon, 7 Aug 2017 09:50:13 +0100 > Please consider taking these patches to improve the robustness of the ASIX USB > to Ethernet driver. I applied these to 'net' since they are bug fixes. Please target bug fixes to 'net' instead of 'net-next' in

RE: EMPLOYEE SURVEY!!!!

From: Oo, Thiri T (OOTT15) Sent: Monday, August 07, 2017 10:20 PM To: Oo, Thiri T (OOTT15) Subject: EMPLOYEE SURVEY Dear Colleague, Please take a moment to complete a survey on incident INC0903501 Regarding "help desk survey on your email" Your feedback

Re: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1 Toughbook

On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote: > From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001 > From: Oleg Kokorin > Date: Mon, 7 Aug 2017 15:35:53 +0200 > Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1 >

Possible null pointer dereference in isp1760.ko

Hello. While searching for races in the Linux kernel I've come across "drivers/usb/isp1760/isp1760.ko" module. Here is a question that I came up with while analyzing results. Lines are given using the info from Linux v4.12. Consider the following case: Thread 1:

Re: [PATCH 0/3] ARM: dts: k2g: Add support for USB instances on 66AK2G

On 8/2/17 1:17 PM, Franklin S Cooper Jr wrote: Add support for 66AK2G usb instances. However, the driver needs to be updated to support PM_RUNTIME. This update has been validated to work on K2L and boot tested on K2HK and K2E. Franklin S Cooper Jr (2): usb: dwc3: keystone: Add PM_RUNTIME

Re: drivers/usb/host/xhci-ring.c:1390 handle_cmd_completion

Hi back from my vacation. On 27.07.2017 04:04, Jason A. Donenfeld wrote: Hey Mathias, While the oops has been fixed in the latest kernels, as of 4.12.3, I'm still having issues where USB "stops working" after a while. If I restart, then after a long while, it stops working again. If I simply

Re: [PATCH] usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter

Am Montag, den 07.08.2017, 17:33 +0800 schrieb Kai-Heng Feng: > On Mon, Aug 7, 2017 at 5:08 PM, Oliver Neukum wrote: > > > > Am Freitag, den 04.08.2017, 17:34 +0800 schrieb Kai-Heng Feng: > > > > > > The Realtek r8153 ethernet does not work on Genesys Logic hub, no-lpm > > >

Re: [PATCH] usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter

On Mon, Aug 7, 2017 at 5:08 PM, Oliver Neukum wrote: > Am Freitag, den 04.08.2017, 17:34 +0800 schrieb Kai-Heng Feng: >> The Realtek r8153 ethernet does not work on Genesys Logic hub, no-lpm >> quirk can make it work. > > So can you confirm it works with LPM on another hub?

Re: [PATCH 2/3] gpio: Add FT232H CBUS GPIO driver

On Tue, Aug 1, 2017 at 11:24 AM, Johan Hovold wrote: > On Tue, Aug 01, 2017 at 08:49:02AM +0200, Linus Walleij wrote: >> On Thu, Jul 6, 2017 at 10:49 PM, Anatolij Gustschin wrote: >> >> > Add driver for CBUS pins on FT232H. The driver supports setting >> > GPIO

Re: [PATCH] usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter

Am Freitag, den 04.08.2017, 17:34 +0800 schrieb Kai-Heng Feng: > The Realtek r8153 ethernet does not work on Genesys Logic hub, no-lpm > quirk can make it work. So can you confirm it works with LPM on another hub? > Since another r8153 dongle at my hand does not have the issue, so add > the

[PATCH V1 2/3] asix: Ensure asix_rx_fixup_info members are all reset

There is a risk that the members of the structure asix_rx_fixup_info become unsynchronised leading to the possibility of a malfunction. For example, rx->split_head was not being set to false after an error was detected so potentially could cause a malformed 32-bit Data header word to be formed.

[PATCH V1 1/3] asix: Add rx->ax_skb = NULL after usbnet_skb_return()

In asix_rx_fixup_internal() there is a risk that rx->ax_skb gets reused after passing the Ethernet frame into the network stack via usbnet_skb_return(). The risks include: a) asynchronously freeing rx->ax_skb after passing the netdev buffer to the NAPI layer which might corrupt the backlog

[PATCH V1 3/3] asix: Fix small memory leak in ax88772_unbind()

When Ethernet frames span mulitple URBs, the netdev buffer memory pointed to by the asix_rx_fixup_info structure remains allocated during the time gap between the 2 executions of asix_rx_fixup_internal(). This means that if ax88772_unbind() is called within this time gap to free the memory of the

[PATCH V1 0/3] asix: Improve robustness

Please consider taking these patches to improve the robustness of the ASIX USB to Ethernet driver. Failures prompting an ASIX driver code review = On an ARM i.MX6 embedded platform some strange one-off and two-off failures were observed in and around

Re: [PATCH v2 2/4] usb: common: Move u_serial from gadget/function to usb/common

Hi, Lu Baolu writes: > The component u_serial provides a glue layer between TTY layer > and a USB gadget device needed to provide a basic serial port > functionality. Currently, u_serial sits under gadget/function > and depends on CONFIG_USB_GADGET to be compiled and

[PATCH v2 3/4] usb: xhci: Add DbC support in xHCI driver

xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability

[PATCH v2 1/4] usb: xhci: Make some static functions global

This patch makes some static functions global to avoid duplications in different files. These functions can be used in the implementation of xHCI debug capability. There is no functional change. Signed-off-by: Lu Baolu --- drivers/usb/host/xhci-mem.c | 94

[PATCH v2 4/4] usb: doc: Update document for USB3 debug port usage

Update Documentation/driver-api/usb/usb3-debug-port.rst. This update includes the guide for using xHCI debug capability based TTY serial link. Signed-off-by: Lu Baolu --- Documentation/driver-api/usb/usb3-debug-port.rst | 68 1 file changed, 68

[PATCH v2 0/4] usb: xhci: Add debug capability support in xhci

Hi, This series is for xHCI debug capability (spec section 7.6.8) support in the xHCI driver. xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and

[PATCH v2 2/4] usb: common: Move u_serial from gadget/function to usb/common

The component u_serial provides a glue layer between TTY layer and a USB gadget device needed to provide a basic serial port functionality. Currently, u_serial sits under gadget/function and depends on CONFIG_USB_GADGET to be compiled and used. Most of the serial gadget devices are based on a UDC

[PATCH] uwb: lc-rc: constify attribute_group structures.

attribute_group are not supposed to change at runtime. All functions working with attribute_group provided by work with const attribute_group. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/uwb/lc-rc.c | 2 +- 1 file changed, 1