Clean up receive processing by dropping the character pointer and
keeping the length argument unchanged throughout the function.

Also make it more apparent that sysrq processing can consume a
characters by adding an explicit continue.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Use an unsigned type for the process-packet buffer argument and give it
a more apt name.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

On devices which do not support break signalling a break condition is
simulated by sending a NUL byte at the lowest possible speed. The break
condition will be 9 bit periods long (start bit and eight data bits),
but the transmission itself also includes the stop bit.

Add the missing safety margin of one bit which is intended to account
for timing differences, and fix up the corresponding comment.
Signed-off-by: NMichael Hanselmann <public@hansmi.ch>
Link: https://lore.kernel.org/r/9909b288-294d-16b9-9f14-51eb79c63b6c@msgid.hansmi.ch
[ johan: amend commit message ]
Signed-off-by: NJohan Hovold <johan@kernel.org>

CP210x hardware disables auto-RTS but leaves auto-CTS when in hardware
flow control mode and UART on cp210x hardware is disabled. When
re-opening the port, if auto-CTS is enabled on the cp210x, then auto-RTS
must be re-enabled in the driver.
Signed-off-by: NBrant Merryman <brant.merryman@silabs.com>
Co-developed-by: NPhu Luu <phu.luu@silabs.com>
Signed-off-by: NPhu Luu <phu.luu@silabs.com>
Link: https://lore.kernel.org/r/ECCF8E73-91F3-4080-BE17-1714BC8818FB@silabs.com
[ johan: fix up tags and problem description ]
Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control")
Cc: stable <stable@vger.kernel.org>     # 2.6.12
Signed-off-by: NJohan Hovold <johan@kernel.org>

Assign the .throttle and .unthrottle functions to be generic function
in the driver structure to prevent data loss that can otherwise occur
if the host does not enable USB throttling.
Signed-off-by: NBrant Merryman <brant.merryman@silabs.com>
Co-developed-by: NPhu Luu <phu.luu@silabs.com>
Signed-off-by: NPhu Luu <phu.luu@silabs.com>
Link: https://lore.kernel.org/r/57401AF3-9961-461F-95E1-F8AFC2105F5E@silabs.com
[ johan: fix up tags ]
Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control")
Cc: stable <stable@vger.kernel.org>     # 2.6.12
Signed-off-by: NJohan Hovold <johan@kernel.org>

A subset of all CH341 devices don't support a real break condition. This
fact is already used in the "ch341_detect_quirks" function. With this
change a quirk is implemented to simulate a break condition by
temporarily lowering the baud rate and sending a NUL byte.

The primary drawbacks of this approach are that the duration of the
break can't be controlled by userland and that data incoming during
a simulated break is corrupted.

The "TTY_DRIVER_HARDWARE_BREAK" serial driver flag was investigated as
an alternative. It's a driver-wide flag and would've required
significant changes to the serial and USB-serial driver frameworks to
expose it for individual USB-serial adapters.

Tested by sending a break condition and watching the TX pin using an
oscilloscope.
Signed-off-by: NMichael Hanselmann <public@hansmi.ch>
Link: https://lore.kernel.org/r/f34a9b6e-ec2a-0873-e97b-2d5b2170e2ff@msgid.hansmi.ch
[ johan: condense info message ]
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add support for enabling hardware flow control using the 'r' command
line option.

This also avoids a W=1 (-Wunused-but-set-variable) warning.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Drop two unused stub functions which only served as documentation.

This also avoids a W=1 (-Wunused-but-set-variable) warning.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Log failure to update the line settings in set_termios().

This also avoids a W=1 (-Wunused-but-set-variable) warning.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Drop the unused firmware reset status which would already have been
logged.

This suppresses the corresponding W=1 (-Wunused-but-set-variable)
warning.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

The driver is submitting URBs in various completion callbacks without
bothering to log errors yet still assigned the return value to temporary
variables. Let's drop those temporaries.

This suppresses the corresponding W=1 (-Wunused-but-set-variable)
warnings.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Don't compile the four unused packet definitions but keep them around
for documentation purposes.

This avoids the corresponding W=1 (-Wunused-const-variable) warning.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

The line-speed algorithm clamps the requested value to the supported
range instead of bailing out on unsupported values.

Provide min and max macros and indicate how they are derived instead of
hardcoding the limits.

Note that the algorithm depends on the minimum rate (45.78 bps)
being rounded up (and the maximum rate being rounded down) to avoid
special casing.
Suggested-by: NMichael Hanselmann <public@hansmi.ch>
Link: https://lore.kernel.org/r/20200630095756.GZ3334@localhostSigned-off-by: NJohan Hovold <johan@kernel.org>

Add constants for the prescaler and divisor registers. Document and
name register 0x25, and put the LCR define to more use.

The 0x25 register (CH341_REG_LCR2) is only used by CH341 chips before
version 0x30 and is involved in configuring the line control parameters.
It's not known to the author whether there any such chips in the wild,
and Linux' ch341 driver never supported them. For chip version 0x30 and
above the 0x25 register is always set to zero. The alternative would've
been to not set the register at all, but that may have unintended
effects.
Signed-off-by: NMichael Hanselmann <public@hansmi.ch>
Link: https://lore.kernel.org/r/2e80916d-1be8-dc0f-abf9-adc0feea1803@msgid.hansmi.ch
[ johan: fix up comment ]
Signed-off-by: NJohan Hovold <johan@kernel.org>

trace_printk should not be used in production code, replace it
call with dev_dbg.
Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>

Link: https://lore.kernel.org/r/20200627070307.516803-2-drinkcat@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In kgdb context, calling console handlers aren't safe due to locks used
in those handlers which could in turn lead to a deadlock. Although, using
oops_in_progress increases the chance to bypass locks in most console
handlers but it might not be sufficient enough in case a console uses
more locks (VT/TTY is good example).

Currently when a driver provides both polling I/O and a console then kdb
will output using the console. We can increase robustness by using the
currently active polling I/O driver (which should be lockless) instead
of the corresponding console. For several common cases (e.g. an
embedded system with a single serial port that is used both for console
output and debugger I/O) this will result in no console handler being
used.

In order to achieve this we need to reverse the order of preference to
use dbg_io_ops (uses polling I/O mode) over console APIs. So we just
store "struct console" that represents debugger I/O in dbg_io_ops and
while emitting kdb messages, skip console that matches dbg_io_ops
console in order to avoid duplicate messages. After this change,
"is_console" param becomes redundant and hence removed.
Suggested-by: NDaniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: NSumit Garg <sumit.garg@linaro.org>
Link: https://lore.kernel.org/r/1591264879-25920-5-git-send-email-sumit.garg@linaro.orgReviewed-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NPetr Mladek <pmladek@suse.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>

This driver assumed that dmaengine_tx_status() could return
the residue even if the transfer was completed. However,
this was not correct usage [1] and this caused to break getting
the residue after the commit 24461d97 ("dmaengine:
virt-dma: Fix access after free in vchan_complete()") actually.
So, this is possible to get wrong received size if the usb
controller gets a short packet. For example, g_zero driver
causes "bad OUT byte" errors.

The usb-dmac driver will support the callback_result, so this
driver can use it to get residue correctly. Note that even if
the usb-dmac driver has not supported the callback_result yet,
this patch doesn't cause any side-effects.

[1]
https://lore.kernel.org/dmaengine/20200616165550.GP2324254@vkoul-mobl/Reported-by: NHien Dang <hien.dang.eb@renesas.com>
Fixes: 24461d97 ("dmaengine: virt-dma: Fix access after free in vchan_complete()")
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/1592482277-19563-1-git-send-email-yoshihiro.shimoda.uh@renesas.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 07f68423.

Since SCLK_SCLK_USBD300 suspend clock need to be configured
for phy module, I wrongly mapped this clock to DWC3 code.

Cc: Felipe Balbi <balbi@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAnand Moon <linux.amoon@gmail.com>
Cc: stable <stable@vger.kernel.org>
Fixes: 07f68423 ("usb: dwc3: exynos: Add support for Exynos5422 suspend clk")
Link: https://lore.kernel.org/r/20200623074637.756-1-linux.amoon@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB2 devices with LPM enabled may interrupt the system suspend:
[  932.510475] usb 1-7: usb suspend, wakeup 0
[  932.510549] hub 1-0:1.0: hub_suspend
[  932.510581] usb usb1: bus suspend, wakeup 0
[  932.510590] xhci_hcd 0000:00:14.0: port 9 not suspended
[  932.510593] xhci_hcd 0000:00:14.0: port 8 not suspended
..
[  932.520323] xhci_hcd 0000:00:14.0: Port change event, 1-7, id 7, portsc: 0x400e03
..
[  932.591405] PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -16
[  932.591414] PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -16
[  932.591418] PM: Device 0000:00:14.0 failed to suspend async: error -16

During system suspend, USB core will let HC suspends the device if it
doesn't have remote wakeup enabled and doesn't have any children.
However, from the log above we can see that the usb 1-7 doesn't get bus
suspended due to not in U0. After a while the port finished U2 -> U0
transition, interrupts the suspend process.

The observation is that after disabling LPM, port doesn't transit to U0
immediately and can linger in U2. xHCI spec 4.23.5.2 states that the
maximum exit latency for USB2 LPM should be BESL + 10us. The BESL for
the affected device is advertised as 400us, which is still not enough
based on my testing result.

So let's use the maximum permitted latency, 10000, to poll for U0
status to solve the issue.

Cc: stable@vger.kernel.org
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200624135949.22611-6-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Just return if xHCI is quirked to disable LPM. We can save some time
from reading registers and doing spinlocks.

Add stable tag as we want this patch together with the next one,
"Poll for U0 after disabling USB2 LPM" which fixes a suspend issue
for some USB2 LPM devices

Cc: stable@vger.kernel.org
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200624135949.22611-5-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When runtime suspend was enabled, runtime suspend might happen
when xhci is removing hcd. This might cause kernel panic when hcd
has been freed but runtime pm suspend related handle need to
reference it.
Signed-off-by: NMacpaul Lin <macpaul.lin@mediatek.com>
Reviewed-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200624135949.22611-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Unable to complete the enumeration of a USB TV Tuner device.

Per XHCI spec (4.6.5), the EP state field of the input context shall
be cleared for a set address command. In the special case of an FS
device that has "MaxPacketSize0 = 8", the Linux XHCI driver does
not do this before evaluating the context. With an XHCI controller
that checks the EP state field for parameter context error this
causes a problem in cases such as the device getting reset again
after enumeration.

When that field is cleared, the problem does not occur.

This was found and fixed by Sasi Kumar.

Cc: stable@vger.kernel.org
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200624135949.22611-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

EP_STATE_MASK should be 0x7 instead of 0xf

xhci spec 6.2.3 shows that the EP state field in the endpoint context data
structure consist of bits [2:0].
The old value included a bit from the next field which fortunately is a
 RsvdZ region. So hopefully this hasn't caused too much harm

Cc: stable@vger.kernel.org
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200624135949.22611-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The other thread may access other endpoints when the cdns3_check_new_setup
is handling, add spinlock to protect it.

Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Cc: <stable@vger.kernel.org>
Reviewed-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20200623030918.8409-4-peter.chen@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It should use the correct direction value from register, not depends
on previous software setting. It fixed the EP number wrong issue at
trace when the TRBERR interrupt occurs for EP0IN.

When the EP0IN IOC has finished, software prepares the setup packet
request, the expected direction is OUT, but at that time, the TRBERR
for EP0IN may occur since it is DMULT mode, the DMA does not stop
until TRBERR has met.

Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Cc: <stable@vger.kernel.org>
Reviewed-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20200623030918.8409-3-peter.chen@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The 'tmode' is ctrl->wIndex, changing it as the real test
mode value for register assignment.

Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Cc: <stable@vger.kernel.org>
Reviewed-by: NJun Li <jun.li@nxp.com>
Reviewed-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20200623030918.8409-2-peter.chen@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For some reason, the TEST_ defines in the usb/ch9.h files did not have
the USB_ prefix on it, making it a bit confusing when reading the file,
as well as not the nicest thing to do in a uapi file.

So fix that up and add the USB_ prefix on to them, and fix up all
in-kernel usages.  This included deleting the duplicate copy in the
net2272.h file.

Cc: Felipe Balbi <balbi@kernel.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Pawel Laszczak <pawell@cadence.com>
Cc: YueHaibing <yuehaibing@huawei.com>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: Jason Yan <yanaijie@huawei.com>
Cc: Jia-Ju Bai <baijiaju1990@gmail.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jules Irenge <jbi.octave@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Rob Gill <rrobgill@protonmail.com>
Cc: Macpaul Lin <macpaul.lin@mediatek.com>
Acked-by: NMinas Harutyunyan <hminas@synopsys.com>
Acked-by: NBin Liu <b-liu@ti.com>
Acked-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Acked-by: NPeter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20200618144206.2655890-1-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 07f68423.

Since SCLK_SCLK_USBD300 suspend clock need to be configured
for phy module, I wrongly mapped this clock to DWC3 code.

Cc: Felipe Balbi <balbi@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAnand Moon <linux.amoon@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If this is in "transceiver" mode the the ->qwork isn't required and is
a NULL pointer.  This can lead to a NULL dereference when we call
destroy_workqueue(udc->qwork).

Fixes: 3517c31a ("usb: gadget: mv_udc: use devm_xxx for probe")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

In the function tegra_usb_phy_probe(), if usb_add_phy_dev() failed,
the return value will be given to err, and if usb_add_phy_dev() succeed,
the return value will be zero. Thus it is unnecessary to repeated check
here.
Signed-off-by: NZhang Shengju <zhangshengju@cmss.chinamobile.com>
Signed-off-by: NTang Bin <tangbin@cmss.chinamobile.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

dwc3_pci_resume_work() calls pm_runtime_get_sync() that increments
the reference counter. In case of failure, decrement the reference
before returning.
Signed-off-by: NAditya Pakki <pakki001@umn.edu>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

The other thread may access other endpoints when the cdns3_check_new_setup
is handling, add spinlock to protect it.

Cc: <stable@vger.kernel.org>
Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Reviewed-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

It should use the correct direction value from register, not depends
on previous software setting. It fixed the EP number wrong issue at
trace when the TRBERR interrupt occurs for EP0IN.

When the EP0IN IOC has finished, software prepares the setup packet
request, the expected direction is OUT, but at that time, the TRBERR
for EP0IN may occur since it is DMULT mode, the DMA does not stop
until TRBERR has met.

Cc: <stable@vger.kernel.org>
Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Reviewed-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

The 'tmode' is ctrl->wIndex, changing it as the real test
mode value for register assignment.

Cc: <stable@vger.kernel.org>
Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Reviewed-by: NJun Li <jun.li@nxp.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Rename the list of specific devices that an OTG device could support to
make it more obvious as to what this list is for and what it is doing.
Also rename the configuration option to make it more obvious as well.

Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: "Diego Elio Pettenò" <flameeyes@flameeyes.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: Qi Zhou <atmgnd@outlook.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Hardik Gajjar <hgajjar@de.adit-jv.com>
Cc: Harry Pan <harry.pan@intel.com>
Cc: David Heinzelmann <heinzelmann.david@gmail.com>
Cc: Nishad Kamdar <nishadkamdar@gmail.com>
Link: https://lore.kernel.org/r/20200618094300.1887727-9-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix up the wording in a comment for the scsi driver saying what it does
using better terminology.

Cc: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200618094300.1887727-8-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make it obvious that the UAS driver is being ignored for a specific
device by fixing up the wording to be more clear.

Cc: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200618094300.1887727-7-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The sierra driver had two different functions for trying to determine
different quirks that did the same exact thing.  Remove one and rename
things to make it more obvious exactly what the different lists do.

Cc: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20200618094300.1887727-6-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Better describe what is happening with a list of devices that are being
ignored by the driver.

Cc: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20200618094300.1887727-5-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>