linux.git/drivers/usb, branch v4.19-rc4

Revert "cdc-acm: implement put_char() and flush_chars()"

2018-09-10T18:40:29+00:00

This reverts commit a81cf9799ad7299b03a4dff020d9685f9ac5f3e0.

The patch causes a regression, which I cannot find the reason for.
So let's revert for now, as a revert hurts only performance.

Original report:
I was trying to resolve the problem with Oliver but we don't get any conclusion
for 5 months, so I am now sending this to mail list and cdc_acm authors.

I am using simple request-response protocol to obtain the boiller parameters
in constant intervals.

A simple one transaction is:
1. opening the /dev/ttyACM0
2. sending the following 10-bytes request to the device:
   unsigned char req[] = {0x02, 0xfe, 0x01, 0x05, 0x08, 0x02, 0x01, 0x69, 0xab, 0x03};
3. reading response (frame of 74 bytes length).
4. closing the descriptor
I am doing this transaction with 5 seconds intervals.

Before the bad commit everything was working correctly: I've got a requests and
a responses in a timely manner.

After the bad commit more time I am using the kernel module, more problems I have.
The graph [2] is showing the problem.

As you can see after module load all seems fine but after about 30 minutes I've got
a plenty of EAGAINs when doing read()'s and trying to read back the data.

When I rmmod and insmod the cdc_acm module again, then the situation is starting
over again: running ok shortly after load, and more time it is running, more EAGAINs
I have when calling read().

As a bonus I can see the problem on the device itself:
The device is configured as you can see here on this screen [3].
It has two transmision LEDs: TX and RX. Blink duration is set for 100ms.
This is a recording before the bad commit when all is working fine: [4]
And this is with the bad commit: [5]
As you can see the TX led is blinking wrongly long (indicating transmission?)
and I have problems doing read() calls (EAGAIN).

Reported-by: Mariusz Bialonczyk 
Signed-off-by: Oliver Neukum 
Fixes: a81cf9799ad7 ("cdc-acm: implement put_char() and flush_chars()")
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: Change usb_of_get_companion_dev() place to usb/common

2018-09-10T18:40:29+00:00

Since renesas_usb3 udc driver calls usb_of_get_companion_dev()
which is on usb/core/of.c, build error like below happens if we
disable CONFIG_USB because the usb/core/ needs CONFIG_USB:

ERROR: "usb_of_get_companion_dev" [drivers/usb/gadget/udc/renesas_usb3.ko] undefined!

According to the usb/gadget/Kconfig, "NOTE:  Gadget support
** DOES NOT ** depend on host-side CONFIG_USB !!".
So, to fix the issue, this patch changes the usb_of_get_companion_dev()
place from usb/core/of.c to usb/common/common.c to be called by both
host and gadget.

Reported-by: John Garry 
Fixes: 39facfa01c9f ("usb: gadget: udc: renesas_usb3: Add register of usb role switch")
Signed-off-by: Yoshihiro Shimoda 
Acked-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix interrupt transfer error happened on MTK platforms

2018-09-10T18:40:29+00:00

The MTK xHCI controller use some reserved bytes in endpoint context for
bandwidth scheduling, so need keep them in xhci_endpoint_copy();

The issue is introduced by:
commit f5249461b504 ("xhci: Clear the host side toggle manually when
endpoint is soft reset")
It resets endpoints and will drop bandwidth scheduling parameters used
by interrupt or isochronous endpoints on MTK xHCI controller.
Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when
endpoint is soft reset")

Cc: stable@vger.kernel.org
Signed-off-by: Chunfeng Yun 
Tested-by: Sean Wang 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'fixes-for-v4.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus

2018-09-06T09:21:54+00:00

Felipe writes:

usb: fixes for v4.19-rc2

NET2280 got a fix to an old patch attempting to fix locking for gadget
framework callbacks.

DWC2 fixed a bug where driver was attempting to access registers before
clocks were enabled.

DWC3 got a fix for ULPI clock configuration on Baytrail devices.

FOTG210 plugged a memory leak and Renesas USB3 fixed ep0 maxpacket size.

Merge tag 'usb-serial-4.19-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus

2018-09-05T14:25:02+00:00

Johan writes:

USB-serial fixes for v4.19-rc3

Here are two fixes for array-underflow bugs in completion handlers due
to insufficient sanity checks.

All have been in linux-next with no reported issues.

Signed-off-by: Johan Hovold

usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()

2018-09-05T12:48:40+00:00

wdm_in_callback() is a completion handler function for the USB driver.
So it should not sleep. But it calls service_outstanding_interrupt(),
which calls usb_submit_urb() with GFP_KERNEL.

To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.

This bug is found by my static analysis tool DSAC.

Signed-off-by: Jia-Ju Bai 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: misc: uss720: Fix two sleep-in-atomic-context bugs

2018-09-05T12:36:53+00:00

async_complete() in uss720.c is a completion handler function for the
USB driver. So it should not sleep, but it is can sleep according to the
function call paths (from bottom to top) in Linux-4.16.

[FUNC] set_1284_register(GFP_KERNEL)
drivers/usb/misc/uss720.c, 372:
  set_1284_register in parport_uss720_frob_control
drivers/parport/ieee1284.c, 560:
  [FUNC_PTR]parport_uss720_frob_control in parport_ieee1284_ack_data_avail
drivers/parport/ieee1284.c, 577:
  parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt
./include/linux/parport.h, 474:
  parport_ieee1284_interrupt in parport_generic_irq
drivers/usb/misc/uss720.c, 116:
  parport_generic_irq in async_complete

[FUNC] get_1284_register(GFP_KERNEL)
drivers/usb/misc/uss720.c, 382:
  get_1284_register in parport_uss720_read_status
drivers/parport/ieee1284.c, 555:
  [FUNC_PTR]parport_uss720_read_status in parport_ieee1284_ack_data_avail
drivers/parport/ieee1284.c, 577:
  parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt
./include/linux/parport.h, 474:
  parport_ieee1284_interrupt in parport_generic_irq
drivers/usb/misc/uss720.c, 116:
  parport_generic_irq in async_complete

Note that [FUNC_PTR] means a function pointer call is used.

To fix these bugs, GFP_KERNEL is replaced with GFP_ATOMIC.

These bugs are found by my static analysis tool DSAC.

Signed-off-by: Jia-Ju Bai 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: host: u132-hcd: Fix a sleep-in-atomic-context bug in u132_get_frame()

2018-09-05T12:36:53+00:00

i_usX2Y_subs_startup in usbusx2yaudio.c is a completion handler function
for the USB driver. So it should not sleep, but it is can sleep
according to the function call paths (from bottom to top) in Linux-4.16.

[FUNC] msleep
drivers/usb/host/u132-hcd.c, 2558:
	msleep in u132_get_frame
drivers/usb/core/hcd.c, 2231:
	[FUNC_PTR]u132_get_frame in usb_hcd_get_frame_number
drivers/usb/core/usb.c, 822:
	usb_hcd_get_frame_number in usb_get_current_frame_number
sound/usb/usx2y/usbusx2yaudio.c, 303:
	usb_get_current_frame_number in i_usX2Y_urb_complete
sound/usb/usx2y/usbusx2yaudio.c, 366:
	i_usX2Y_urb_complete in i_usX2Y_subs_startup

Note that [FUNC_PTR] means a function pointer call is used.

To fix this bug, msleep() is replaced with mdelay().

This bug is found by my static analysis tool DSAC.

Signed-off-by: Jia-Ju Bai 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: Avoid use-after-free by flushing endpoints early in usb_set_interface()

2018-09-05T12:36:53+00:00

The steps taken by usb core to set a new interface is very different from
what is done on the xHC host side.

xHC hardware will do everything in one go. One command is used to set up
new endpoints, free old endpoints, check bandwidth, and run the new
endpoints.

All this is done by xHC when usb core asks the hcd to check for
available bandwidth. At this point usb core has not yet flushed the old
endpoints, which will cause use-after-free issues in xhci driver as
queued URBs are cancelled on a re-allocated endpoint.

To resolve this add a call to usb_disable_interface() which will flush
the endpoints before calling usb_hcd_alloc_bandwidth()

Additional checks in xhci driver will also be implemented to gracefully
handle stale URB cancel on freed and re-allocated endpoints

Cc: 
Reported-by: Sudip Mukherjee 
Signed-off-by: Mathias Nyman 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb/typec: fix kernel-doc notation warning for typec_match_altmode

2018-09-05T12:36:53+00:00

Fix kernel-doc warning for missing function parameter 'mode' description:

../drivers/usb/typec/bus.c:268: warning: Function parameter or member 'mode' not described in 'typec_match_altmode'

Also fix typos for same function documentation.

Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes")

Signed-off-by: Randy Dunlap 
Acked-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman