linux.git/drivers/usb/misc, branch v5.18-rc2

usb: misc: USB_QCOM_EUD should depend on ARCH_QCOM

2022-02-24T10:19:55+00:00

The Qualcomm Embedded USB Debugger is not a pluggable USB device, and
can only be present on Qualcomm SoCs.  Hence add a dependency on
ARCH_QCOM, to prevent asking the user about this driver when configuring
a kernel without Qualcomm SoC support.

Fixes: 9a1bf58ccd443268 ("usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)")
Signed-off-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/f3ba3ea0d7f5e628c71cb7a9d62c9fb4589297b1.1645630266.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman

Merge 5.17-rc4 into usb-next

2022-02-14T08:04:36+00:00

We need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)

2022-02-11T11:01:02+00:00

Add support for control peripheral of EUD (Embedded USB Debugger) to
listen to events such as USB attach/detach, pet EUD to indicate software
is functional.Reusing the platform device kobj, sysfs entry 'enable' is
created to enable or disable EUD.

To enable the eud the following needs to be done
echo 1 > /sys/bus/platform/.../enable

To disable eud, following is the command
echo 0 > /sys/bus/platform/.../enable

Signed-off-by: Souradeep Chowdhury 
Link: https://lore.kernel.org/r/0ac5c2b2c8e4ce4f4f342a08b48cfc61aeaf7ee8.1644339918.git.quic_schowdhu@quicinc.com
Signed-off-by: Greg Kroah-Hartman

usb: usb251xb: add boost-up property support

2022-01-31T13:22:49+00:00

Add support for boost-up register of usb251xb hub.
boost-up property control USB electrical drive strength
This register can be set:

 - Normal mode -> 0x00
 - Low         -> 0x01
 - Medium      -> 0x10
 - High        -> 0x11

(Normal Default)

References:
 - http://www.mouser.com/catalog/specsheets/2514.pdf p29

Reviewed-by: Richard Leitner 
Signed-off-by: Tommaso Merciai 
Link: https://lore.kernel.org/r/20220128181713.96856-1-tomm.merciai@gmail.com
Signed-off-by: Greg Kroah-Hartman

usb: misc: ehset: Rework test mode entry

2021-12-17T16:02:04+00:00

The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going
under test needs to be put in suspend state before sending the test
command. Many hubs, don't enforce this precondition and they work fine
without this step. We should follow the specification and put the USB
port in suspend before sending the test command.

Also there are some "special" hubs, which requires to disable the USB
port power instead of putting it in suspend. I found out only three hubs
which requires this step, but if more are found, they can be added to
the list.

Since this changes the default implementation, it raises the posibility
of finding other broken hubs which are not compliant with the spec and
the test command might not work is the port is suspended. If such hubs
are found, a similar workaround like the disable part can be implemented
to skip putting the port in suspend.

Signed-off-by: Razvan Heghedus 
Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com
Signed-off-by: Greg Kroah-Hartman

usb: ftdi-elan: fix memory leak on device disconnect

2021-12-17T15:54:12+00:00

'ftdi' is alloced when probe device, but not free on device disconnect,
this cause a memory leak as follows:

unreferenced object 0xffff88800d584000 (size 8400):
  comm "kworker/0:2", pid 3809, jiffies 4295453055 (age 13.784s)
  hex dump (first 32 bytes):
    00 40 58 0d 80 88 ff ff 00 40 58 0d 80 88 ff ff  .@X......@X.....
    00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de  .............N..
  backtrace:
    [<000000000d47f947>] kmalloc_order_trace+0x19/0x110 mm/slab_common.c:960
    [<000000008548ac68>] ftdi_elan_probe+0x8c/0x880 drivers/usb/misc/ftdi-elan.c:2647
    [<000000007f73e422>] usb_probe_interface+0x31b/0x800 drivers/usb/core/driver.c:396
    [<00000000fe8d07fc>] really_probe+0x299/0xc30 drivers/base/dd.c:517
    [<0000000005da7d32>] __driver_probe_device+0x357/0x500 drivers/base/dd.c:751
    [<000000003c2c9579>] driver_probe_device+0x4e/0x140 drivers/base/dd.c:781

Fix it by freeing 'ftdi' after nobody use it.

Fixes: a5c66e4b2418 ("USB: ftdi-elan: client driver for ELAN Uxxx adapters")
Reported-by: Hulk Robot 
Signed-off-by: Wei Yongjun 
Link: https://lore.kernel.org/r/20211217083428.2441-1-weiyongjun1@huawei.com
Signed-off-by: Greg Kroah-Hartman

USB: iowarrior: fix control-message timeouts

2021-10-26T17:12:28+00:00

USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.

Use the common control-message timeout define for the five-second
timeout and drop the driver-specific one.

Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
Cc: stable@vger.kernel.org      # 2.6.21
Signed-off-by: Johan Hovold 
Link: https://lore.kernel.org/r/20211025115159.4954-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

Revert "usb: misc: ehset: Workaround for "special" hubs"

2021-10-07T10:48:54+00:00

This reverts commit ce3e90d5a0cdbcb2ddebbf9e4363e59fa779ad3a.

The commit in question added list of quirky hubs, but the match
implementation clearly hasn't been tested at all.

First, hub_udev->dev.parent does not represent a USB interface so using
to_usb_interface() makes no sense and we'd be passing a random pointer
to usb_match_id().

Second, if hub_udev is a root hub it doesn't even even represent a USB
device.

Signed-off-by: Johan Hovold 
Fixes: ce3e90d5a0cd ("usb: misc: ehset: Workaround for "special" hubs")
Cc: Razvan Heghedus 
Link: https://lore.kernel.org/r/20211007090601.19156-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

usb: misc: ehset: Workaround for "special" hubs

2021-10-05T10:39:46+00:00

The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going
under test needs to be put in suspend state before sending the test
command. Many hubs, don't enforce this precondition and they work fine
without this step. But there are some "special" hubs, which requires to
disable the port power before sending the test command.

Because the USB spec mention that the port should be suspended, also
do this step before sending the test command. This could rise the
problem with other hubs which are not compliant with the spec and the
test command will not work if the port is suspend. If such hubs are
found, a similar workaround like the disable part could be implemented
to skip the suspend port command.

Signed-off-by: Razvan Heghedus 
Link: https://lore.kernel.org/r/20210915121615.3790-1-heghedus.razvan@gmail.com
Signed-off-by: Greg Kroah-Hartman

usb: misc: brcmstb-usb-pinmap: add IRQ check

2021-08-13T11:05:50+00:00

The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_irq() (which takes
*unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original
error code.  Stop calling devm_request_irq() with the invalid IRQ #s.

Fixes: 517c4c44b323 ("usb: Add driver to allow any GPIO to be used for 7211 USB signals")
Reviewed-by: Florian Fainelli 
Signed-off-by: Sergey Shtylyov 
Link: https://lore.kernel.org/r/806d0b1a-365b-93d9-3fc1-922105ca5e61@omp.ru
Signed-off-by: Greg Kroah-Hartman