linux-stable.git/drivers/usb/gadget, branch linux-3.18.y

usb: gadget: net2272: Fix net2272_dequeue()

2019-05-16T07:17:15+00:00

[ Upstream commit 091dacc3cc10979ab0422f0a9f7fcc27eee97e69 ]

Restore the status of ep->stopped in function net2272_dequeue().

When the given request is not found in the endpoint queue
the function returns -EINVAL without restoring the state of
ep->stopped. Thus the endpoint keeps blocked and does not transfer
any data anymore.

This fix is only compile-tested, since we do not have a
corresponding hardware. An analogous fix was tested in the sibling
driver. See "usb: gadget: net2280: Fix net2280_dequeue()"

Acked-by: Alan Stern 
Signed-off-by: Guido Kiener 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin (Microsoft)

usb: gadget: net2280: Fix overrun of OUT messages

2019-05-16T07:17:15+00:00

[ Upstream commit 9d6a54c1430647355a5e23434881b2ca3d192b48 ]

The OUT endpoint normally blocks (NAK) subsequent packets when a
short packet was received and returns an incomplete queue entry to
the gadget driver. Thereby the gadget driver can detect a short packet
when reading queue entries with a length that is not equal to a
multiple of packet size.

The start_queue() function enables receiving OUT packets regardless of
the content of the OUT FIFO. This results in a race: With the current
code, it's possible that the "!ep->is_in && (readl(&ep->regs->ep_stat)
& BIT(NAK_OUT_PACKETS))" test in start_dma() will fail, then a short
packet will be received, and then start_queue() will call
stop_out_naking(). That's what we don't want (OUT naking gets turned
off while there is data in the FIFO) because then the next driver
request might receive a mixture of old and new packets.

With the patch, this race can't occur because the FIFO's state is
tested after we know that OUT naking is already turned on, and OUT
naking is stopped only when both of the conditions are met.  This
ensures that all received data is delivered to the gadget driver,
which can detect a short packet now before new packets are appended
to the last short packet.

Acked-by: Alan Stern 
Signed-off-by: Guido Kiener 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin (Microsoft)

usb: gadget: configfs: add mutex lock before unregister gadget

2019-04-03T04:22:11+00:00

[ Upstream commit cee51c33f52ebf673a088a428ac0fecc33ab77fa ]

There may be a race condition if f_fs calls unregister_gadget_item in
ffs_closed() when unregister_gadget is called by UDC store at the same time.
this leads to a kernel NULL pointer dereference:

[  310.644928] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[  310.645053] init: Service 'adbd' is being killed...
[  310.658938] pgd = c9528000
[  310.662515] [00000004] *pgd=19451831, *pte=00000000, *ppte=00000000
[  310.669702] Internal error: Oops: 817 [#1] PREEMPT SMP ARM
[  310.675211] Modules linked in:
[  310.678294] CPU: 0 PID: 1537 Comm: ->transport Not tainted 4.1.15-03725-g793404c #2
[  310.685958] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  310.692493] task: c8e24200 ti: c945e000 task.ti: c945e000
[  310.697911] PC is at usb_gadget_unregister_driver+0xb4/0xd0
[  310.703502] LR is at __mutex_lock_slowpath+0x10c/0x16c
[  310.708648] pc : []    lr : []    psr: 600f0113

[  311.565585] [] (usb_gadget_unregister_driver) from [] (unregister_gadget_item+0x1c/0x34)
[  311.575426] [] (unregister_gadget_item) from [] (ffs_closed+0x8c/0x9c)
[  311.583702] [] (ffs_closed) from [] (ffs_data_reset+0xc/0xa0)
[  311.591194] [] (ffs_data_reset) from [] (ffs_data_closed+0x90/0xd0)
[  311.599208] [] (ffs_data_closed) from [] (ffs_ep0_release+0xc/0x14)
[  311.607224] [] (ffs_ep0_release) from [] (__fput+0x80/0x1d0)
[  311.614635] [] (__fput) from [] (task_work_run+0xb0/0xe8)
[  311.621788] [] (task_work_run) from [] (do_work_pending+0x7c/0xa4)
[  311.629718] [] (do_work_pending) from [] (work_pending+0xc/0x20)

for functions using functionFS, i.e. android adbd will close /dev/usb-ffs/adb/ep0
when usb IO thread fails, but switch adb from on to off also triggers write
"none" > UDC. These 2 operations both call unregister_gadget, which will lead
to the panic above.

add a mutex before calling unregister_gadget for api used in f_fs.

Signed-off-by: Winter Wang 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

usb: gadget: Potential NULL dereference on allocation error

2019-03-23T07:18:53+00:00

[ Upstream commit df28169e1538e4a8bcd8b779b043e5aa6524545c ]

The source_sink_alloc_func() function is supposed to return error
pointers on error.  The function is called from usb_get_function() which
doesn't check for NULL returns so it would result in an Oops.

Of course, in the current kernel, small allocations always succeed so
this doesn't affect runtime.

Signed-off-by: Dan Carpenter 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

usb: gadget: udc: net2272: Fix bitwise and boolean operations

2019-02-20T09:09:06+00:00

commit 07c69f1148da7de3978686d3af9263325d9d60bd upstream.

(!x & y) strikes again.

Fix bitwise and boolean operations by enclosing the expression:

	intcsr & (1 << NET2272_PCI_IRQ)

in parentheses, before applying the boolean operator '!'.

Notice that this code has been there since 2011. So, it would
be helpful if someone can double-check this.

This issue was detected with the help of Coccinelle.

Fixes: ceb80363b2ec ("USB: net2272: driver for PLX NET2272 USB device controller")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

USB: omap_udc: fix USB gadget functionality on Palm Tungsten E

2018-12-17T09:07:11+00:00

[ Upstream commit 2c2322fbcab8102b8cadc09d66714700a2da42c2 ]

On Palm TE nothing happens when you try to use gadget drivers and plug
the USB cable. Fix by adding the board to the vbus sense quirk list.

Signed-off-by: Aaro Koskinen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

USB: omap_udc: fix omap_udc_start() on 15xx machines

2018-12-17T09:07:11+00:00

[ Upstream commit 6ca6695f576b8453fe68865e84d25946d63b10ad ]

On OMAP 15xx machines there are no transceivers, and omap_udc_start()
always fails as it forgot to adjust the default return value.

Signed-off-by: Aaro Koskinen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

USB: omap_udc: fix crashes on probe error and module removal

2018-12-17T09:07:10+00:00

[ Upstream commit 99f700366fcea1aa2fa3c49c99f371670c3c62f8 ]

We currently crash if usb_add_gadget_udc_release() fails, since the
udc->done is not initialized until in the remove function.
Furthermore, on module removal the udc data is accessed although
the release function is already triggered by usb_del_gadget_udc()
early in the function.

Fix by rewriting the release and remove functions, basically moving
all the cleanup into the release function, and doing the completion
only in the module removal case.

The patch fixes omap_udc module probe with a failing gadged, and also
allows the removal of omap_udc. Tested by running "modprobe omap_udc;
modprobe -r omap_udc" in a loop.

Signed-off-by: Aaro Koskinen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

USB: omap_udc: use devm_request_irq()

2018-12-17T09:07:10+00:00

[ Upstream commit 286afdde1640d8ea8916a0f05e811441fbbf4b9d ]

The current code fails to release the third irq on the error path
(observed by reading the code), and we get also multiple WARNs with
failing gadget drivers due to duplicate IRQ releases. Fix by using
devm_request_irq().

Signed-off-by: Aaro Koskinen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

usb: gadget: dummy: fix nonsensical comparisons

2018-12-13T08:22:30+00:00

commit 7661ca09b2ff98f48693f431bb01fed62830e433 upstream.

gcc-8 points out two comparisons that are clearly bogus
and almost certainly not what the author intended to write:

drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed':
drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
         USB_PORT_STAT_ENABLE) == 1 &&
                               ^~
drivers/usb/gadget/udc/dummy_hcd.c:381:25: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
      USB_SS_PORT_LS_U0) == 1 &&
                         ^~

I looked at the code for a bit and came up with a change that makes
it look like what the author probably meant here. This makes it
look reasonable to me and to gcc, shutting up the warning.

It does of course change behavior as the two conditions are actually
evaluated rather than being hardcoded to false, and I have made no
attempt at verifying that the changed logic makes sense in the context
of a USB HCD, so that part needs to be reviewed carefully.

Fixes: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support")
Cc: Tatyana Brokhman 
Cc: Felipe Balbi 
Acked-by: Alan Stern 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman