Some platforms (eg cdns3) may have special sequences between
xhci_bus_suspend and xhci_suspend, add .suspend_quick for it.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200918131752.16488-3-mathias.nyman@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some xhci hosts (eg dwc3 and cdns3) do not use OF to create
platform device, they create xhci-plat platform device runtime.
And these platforms may also have quirks, and the quirks could
be supplied by their parent device through platform data.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200918131752.16488-2-mathias.nyman@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Buffers should be u8*, not unsigned char*
Buffers have an unsigned length and using an int
as a boolean is a bit outdated.

No functional change intended.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20200917110235.11854-1-oneukum@suse.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Handling for removal of the controller was missing at one place.
Add it.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20200917112600.26508-1-oneukum@suse.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

If the dwc2 driver fails to probe after having enabled the regulators,
it ends up being unregistered with regulators enabled, something the
core regulator code is legitimately upset about:

   dwc2 ff400000.usb: supply vusb_d not found, using dummy regulator
   dwc2 ff400000.usb: supply vusb_a not found, using dummy regulator
   dwc2 ff400000.usb: dwc2_core_reset: HANG! AHB Idle timeout GRSTCTL GRSTCTL_AHBIDLE
   WARNING: CPU: 2 PID: 112 at drivers/regulator/core.c:2074 _regulator_put.part.0+0x16c/0x174
   Modules linked in: dwc2(E+) dwc3(E) udc_core(E) rtc_hym8563(E) dwmac_generic(E) ulpi(E) usbcore(E) dwc3_meson_g12a(E) roles(E) meson_gx_mmc(E+) i2c_meson(E) mdio_mux_meson_g12a(E) mdio_mux(E) dwmac_meson8b(E) stmmac_platform(E) stmmac(E) mdio_xpcs(E) phylink(E) of_mdio(E) fixed_phy(E) libphy(E) pwm_regulator(E) fixed(E)
   CPU: 2 PID: 112 Comm: systemd-udevd Tainted: G            E     5.9.0-rc4-00102-g423583bc8cf9 #1840
   Hardware name: amlogic w400/w400, BIOS 2020.04 05/22/2020
   pstate: 80400009 (Nzcv daif +PAN -UAO BTYPE=--)
   pc : _regulator_put.part.0+0x16c/0x174
   lr : regulator_bulk_free+0x6c/0x9c
   sp : ffffffc012353820
   x29: ffffffc012353820 x28: ffffff805a4b7000
   x27: ffffff8059c2eac0 x26: ffffff8059c2e810
   x25: ffffff805a4b7d00 x24: ffffffc008cf3028
   x23: ffffffc011729ef8 x22: ffffff807e2761d8
   x21: ffffffc01171df78 x20: ffffff805a4b7700
   x19: ffffff805a4b7700 x18: 0000000000000030
   x17: 0000000000000000 x16: 0000000000000000
   x15: ffffff807ea8d178 x14: 3935312820435455
   x13: 2038323a36313a37 x12: ffffffffffffffff
   x11: 0000000000000040 x10: 0000000000000007
   x9 : ffffffc0106f77d0 x8 : ffffffffffffffe0
   x7 : ffffffffffffffff x6 : 0000000000017702
   x5 : ffffff805a4b7400 x4 : 0000000000000000
   x3 : ffffffc01171df78 x2 : ffffff807ea8cc40
   x1 : 0000000000000000 x0 : 0000000000000001
   Call trace:
    _regulator_put.part.0+0x16c/0x174
    regulator_bulk_free+0x6c/0x9c
    devm_regulator_bulk_release+0x28/0x3c
    release_nodes+0x1c8/0x2c0
    devres_release_all+0x44/0x6c
    really_probe+0x1ec/0x504
    driver_probe_device+0x100/0x170
    device_driver_attach+0xcc/0xd4
    __driver_attach+0xb0/0x17c
    bus_for_each_dev+0x7c/0xd4
    driver_attach+0x30/0x3c
    bus_add_driver+0x154/0x250
    driver_register+0x84/0x140
    __platform_driver_register+0x54/0x60
    dwc2_platform_driver_init+0x2c/0x1000 [dwc2]
    do_one_initcall+0x54/0x2d0
    do_init_module+0x68/0x29c

In order to fix this, tie the regulator disabling to the teardown
process by registering a devm action callback. This makes sure that
the regulators are disabled at the right time (just before they are
released).

Cc: Minas Harutyunyan <hminas@synopsys.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200914130634.2424496-1-maz@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ROLE_CONTROL register would not have the actual CC terminations
unless the port does not set ROLE_CONTROL.DRP. For DRP ports,
CC_STATUS.cc1/cc2 indicates the final terminations applied
when TCPC enters potential_connect_as_source/_sink.
For DRP ports, infer port role from CC_STATUS and set corresponding
CC terminations before setting the orientation.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20200901025927.3596190-4-badhri@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

TCPCI spec forbids direct access of TX_BUF_BYTE_x register.
The existing version of tcpci driver assumes that those registers
are directly addressible. Add support for tcpci chips which do
not support direct access to TX_BUF_BYTE_x registers. TX_BUF_BYTE_x
can only be accessed by I2C_WRITE_BYTE_COUNT.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20200901025927.3596190-3-badhri@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add register definitions to trap extended alerts.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20200901025927.3596190-2-badhri@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The SCSI layer has introduced a new macro for recording the result
of a command. Use it.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20200916094026.30085-3-oneukum@suse.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The SCSI layer can go into an ugly loop if you ignore that a device is
gone. You need to report an error in the command rather than in the
return value of the queue method.

We need to specifically check for ENODEV. The issue goes back to the
introduction of the driver.

Fixes: 115bb1ff ("USB: Add UAS driver")
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20200916094026.30085-2-oneukum@suse.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The SoC expects the USB Type-C ports numbers to be starting with 0.
If the port number is passed as it is, the IOM status will not be
updated. The IOM port status check fails which will eventually
lead to PMC IPC communication failure.

Fixes: 43d596e3 ("usb: typec: intel_pmc_mux: Check the port status before connect")
Suggested-by: Utkarsh Patel <utkarsh.h.patel@intel.com>
Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200916091102.27118-3-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Since the driver now needs to find the IOM ACPI node, the
driver depends on ACPI. Without the dependency set, the
driver will only fail to compile when ACPI is not enabled.

Fixes: 43d596e3 ("usb: typec: intel_pmc_mux: Check the port status before connect")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200916091102.27118-2-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The SCSI layer is providing a new macro. Let's use it.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20200916100302.30855-1-oneukum@suse.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

A USB device will always haev a bi-directional endpoint 0, that's just
how the devices work, so no need to check for that in a few quirk tests
as it will always pass.

Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Alexander Tsoy <alexander@tsoy.me>
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200914153756.3412156-12-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb_control_msg_send() and usb_control_msg_recv() calls can return
an error if a "short" write/read happens, and they can handle data off
of the stack, so move the driver over to using those calls instead,
saving some logic when dynamically allocating memory.

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Link: https://lore.kernel.org/r/20200914153756.3412156-11-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb_control_msg_send() call can return an error if a "short" write
happens, so move the driver over to using that call instead.

Cc: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-10-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb_control_msg_send() and usb_control_msg_recv() calls can return
an error if a "short" write/read happens, and they can handle data off
of the stack, so move the driver over to using those calls instead,
saving some logic when dynamically allocating memory.

Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-9-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb_control_msg_send() and usb_control_msg_recv() calls can return
an error if a "short" write/read happens, so move the driver over to
using those calls instead, saving some logic in the wrapper functions
that were being used in this driver.

This also resolves a long-staging bug where data on the stack was being
sent in a USB control message, which was not allowed.

Cc: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-8-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb_control_msg_send() call can handle data on the stack, as well as
returning an error if a "short" write happens, so move the driver over
to using that call instead.  This ends up removing a helper function
that is no longer needed.

Cc: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-7-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb_control_msg_recv() function can handle data on the stack, as
well as properly detecting short reads, so move to use that function
instead of the older usb_control_msg() call.  This ends up removing a
lot of extra lines in the driver.

Cc: Juergen Stuber <starblue@users.sourceforge.net>
Link: https://lore.kernel.org/r/20200914153756.3412156-6-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There are a few calls to usb_control_msg() that can be converted to use
usb_control_msg_send() instead, so do that in order to make the error
checking a bit simpler and the code smaller.
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200914153756.3412156-5-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There are a few calls to usb_control_msg() that can be converted to use
usb_control_msg_send() instead, so do that in order to make the error
checking a bit simpler.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200914153756.3412156-4-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

New core functions to make sending/receiving USB control messages easier
and saner.

In discussions, it turns out that the large majority of users of
usb_control_msg() do so in potentially incorrect ways.  The most common
issue is where a "short" message is received, yet never detected
properly due to "incorrect" error handling.

Handle all of this in the USB core with two new functions to try to make
working with USB control messages simpler.

No more need for dynamic data, messages can be on the stack, and only
"complete" send/receive will work without causing an error.

Link: https://lore.kernel.org/r/20200914153756.3412156-3-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

snd_usb_pipe_sanity_check() is a great function, so let's move it into
the USB core so that other parts of the kernel, including the USB core,
can call it.

Name it usb_pipe_type_check() to match the existing
usb_urb_ep_type_check() call, which now uses this function.

Cc: Jaroslav Kysela <perex@perex.cz>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Eli Billauer <eli.billauer@gmail.com>
Cc: Emiliano Ingrassia <ingrassia@epigenesys.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Alexander Tsoy <alexander@tsoy.me>
Cc: "Geoffrey D. Bennett" <g@b4.vu>
Cc: Jussi Laako <jussi@sonarnerd.net>
Cc: Nick Kossifidis <mickflemm@gmail.com>
Cc: Dmitry Panchenko <dmitry@d-systems.ee>
Cc: Chris Wulff <crwulff@gmail.com>
Cc: Jesus Ramos <jesus-ramos@live.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-2-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Simplify the return expression.
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Link: https://lore.kernel.org/r/20200915032631.1772673-1-liushixin2@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a devicetree binding documentation for the MT6360 Type-C driver.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1598928042-22115-2-git-send-email-u0084500@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Mediatek MT6360 is a multi-functional IC that includes USB Type-C.
It works with Type-C Port Controller Manager to provide USB PD
and USB Type-C functionalities.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1598928042-22115-1-git-send-email-u0084500@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix typo/spello of "function".

Cc: Felipe Balbi <balbi@kernel.org>
Cc: Jiri Kosina <trivial@kernel.org>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/1be7e71f-6b79-290a-f38e-b51ccaf85e8e@infradead.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b35c5009 ("USB: EHCI: create per-TT bandwidth tables")
left behind this, remove it.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200909134405.34036-1-yuehaibing@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The 'distrust_firmware' module parameter dates from 2004 and the USB
subsystem is a lot more mature and reliable now than it was then.
Alter the default to false now.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20200910212512.16670-2-hamish.martin@alliedtelesis.co.nzSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some integrated OHCI controller hubs do not expose all ports of the hub
to pins on the SoC. In some cases the unconnected ports generate
spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC
contains a nominally 3 port hub but only the first port is wired.

Default behaviour for ohci-platform driver is to use global over-current
protection mode (AKA "ganged"). This leads to the spurious over-current
events affecting all ports in the hub.

We now alter the default to use per-port over-current protection.

This patch results in the following configuration changes depending
on quirks:
- For quirk OHCI_QUIRK_SUPERIO no changes. These systems remain set up
  for ganged power switching and no over-current protection.
- For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching
  remains at none, while over-current protection is now guaranteed to be
  set to per-port rather than the previous behaviour where it was either
  none or global over-current protection depending on the value at
  function entry.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20200910212512.16670-1-hamish.martin@alliedtelesis.co.nzSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit f24f27b8 ("MAINTAINERS: add entry for mediatek usb3 DRD IP
driver") claims linux-usb@vger.kernel.org is moderated for
non-subscribers, but all other 46 entries for linux-usb@vger.kernel.org
do not mention that.

Adjust this entry to be consistent with all others.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20200912121346.2796-1-lukas.bulwahn@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The ehci controller found in some Broadcom switches with integrated SoCs
has an issue which causes a soft lockup with large transfers like you
see when running ext4 on USB3 flash drive.

Port the fix from the Broadcom XLDK to increase the OUT_THRESHOLD to
avoid the problem.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20200913215926.29880-1-chris.packham@alliedtelesis.co.nzSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We need the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull ARM SoC fixes from Olof Johansson:
 "A collection of fixes I've been accruing over the last few weeks, none
  of them have been severe enough to warrant flushing the queue but it's
  been long enough now that it's a good idea to send them in.

  A handful of them are fixups for QSPI DT/bindings/compatibles, some
  smaller fixes for system DMA clock control and TMU interrupts on i.MX,
  a handful of fixes for OMAP, including a fix for DSI (display) on
  omap5"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (27 commits)
  arm64: dts: ns2: Fixed QSPI compatible string
  ARM: dts: BCM5301X: Fixed QSPI compatible string
  ARM: dts: NSP: Fixed QSPI compatible string
  ARM: dts: bcm: HR2: Fixed QSPI compatible string
  dt-bindings: spi: Fix spi-bcm-qspi compatible ordering
  ARM: dts: imx6sx: fix the pad QSPI1B_SCLK mux mode for uart3
  arm64: dts: imx8mp: correct sdma1 clk setting
  arm64: dts: imx8mq: Fix TMU interrupt property
  ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy
  ARM: dts: vfxxx: Add syscon compatible with OCOTP
  ARM: dts: imx6q-logicpd: Fix broken PWM
  arm64: dts: imx: Add missing imx8mm-beacon-kit.dtb to build
  ARM: dts: imx6q-prtwd2: Remove unneeded i2c unit name
  ARM: dts: imx6qdl-gw51xx: Remove unneeded #address-cells/#size-cells
  ARM: dts: imx7ulp: Correct gpio ranges
  ARM: dts: ls1021a: fix QuadSPI-memory reg range
  arm64: defconfig: Enable ptn5150 extcon driver
  arm64: defconfig: Enable USB gadget with configfs
  ARM: configs: Update Integrator defconfig
  ARM: dts: omap5: Fix DSI base address and clocks
  ...

Pull USB/Thunderbolt fixes from Greg KH:
 "Here are some small USB and Thunderbolt driver fixes for 5.9-rc5.

  Nothing huge, just a number of bugfixes and new device ids for
  problems reported:

   - new USB serial driver ids

   - bug fixes for syzbot reported problems

   - typec driver fixes

   - thunderbolt driver fixes

   - revert of reported broken commit

  All of these have been in linux-next with no reported issues"

* tag 'usb-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  usb: typec: intel_pmc_mux: Do not configure SBU and HSL Orientation in Alternate modes
  usb: typec: intel_pmc_mux: Do not configure Altmode HPD High
  usb: core: fix slab-out-of-bounds Read in read_descriptors
  Revert "usb: dwc3: meson-g12a: fix shared reset control use"
  usb: typec: ucsi: acpi: Check the _DEP dependencies
  usb: typec: intel_pmc_mux: Un-register the USB role switch
  usb: Fix out of sync data toggle if a configured device is reconfigured
  USB: serial: option: support dynamic Quectel USB compositions
  USB: serial: option: add support for SIM7070/SIM7080/SIM7090 modules
  thunderbolt: Use maximum USB3 link rate when reclaiming if link is not up
  thunderbolt: Disable ports that are not implemented
  USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter

Pull staging/IIO driver fixes from Greg KH:
 "Here are a number of staging and IIO driver fixes for 5.9-rc5.

  The majority of these are IIO driver fixes, to resolve a timestamp
  issue that was recently found to affect a bunch of IIO drivers.

  The other fixes in here are:

   - small IIO driver fixes

   - greybus driver fix

   - counter driver fix (came in through the IIO fixes tree)

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'staging-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (23 commits)
  iio: adc: mcp3422: fix locking on error path
  iio: adc: mcp3422: fix locking scope
  iio: adc: meson-saradc: Use the parent device to look up the calib data
  iio:adc:max1118 Fix alignment of timestamp and data leak issues
  iio:adc:ina2xx Fix timestamp alignment issue.
  iio:adc:ti-adc084s021 Fix alignment and data leak issues.
  iio:adc:ti-adc081c Fix alignment and data leak issues
  iio:magnetometer:ak8975 Fix alignment and data leak issues.
  iio:light:ltr501 Fix timestamp alignment issue.
  iio:light:max44000 Fix timestamp alignment and prevent data leak.
  iio:chemical:ccs811: Fix timestamp alignment and prevent data leak.
  iio:proximity:mb1232: Fix timestamp alignment and prevent data leak.
  iio:accel:mma7455: Fix timestamp alignment and prevent data leak.
  iio:accel:bmc150-accel: Fix timestamp alignment and prevent data leak.
  iio:accel:mma8452: Fix timestamp alignment and prevent data leak.
  iio: accel: kxsd9: Fix alignment of local buffer.
  iio: adc: rockchip_saradc: select IIO_TRIGGERED_BUFFER
  iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set
  counter: microchip-tcb-capture: check the correct variable
  iio: cros_ec: Set Gyroscope default frequency to 25Hz
  ...

Pull driver core fixes from Greg KH:
 "Here are some small driver core and debugfs fixes for 5.9-rc5

  Included in here are:

   - firmware loader memory leak fix

   - firmware loader testing fixes for non-EFI systems

   - device link locking fixes found by lockdep

   - kobject_del() bugfix that has been affecting some callers

   - debugfs minor fix

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'driver-core-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  test_firmware: Test platform fw loading on non-EFI systems
  PM: <linux/device.h>: fix @em_pd kernel-doc warning
  kobject: Drop unneeded conditional in __kobject_del()
  driver core: Fix device_pm_lock() locking for device links
  MAINTAINERS: Add the security document to SECURITY CONTACT
  driver code: print symbolic error code
  debugfs: Fix module state check condition
  kobject: Restore old behaviour of kobject_del(NULL)
  firmware_loader: fix memory leak for paged buffer

This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
5.9, please pull the following:

- Florian fixes the Broadcom QSPI controller binding such that the most
  specific compatible string is the left most one, and all existing
  in-tree users are updated as well.

* tag 'arm-soc/for-5.9/devicetree-fixes' of https://github.com/Broadcom/stblinux:
  arm64: dts: ns2: Fixed QSPI compatible string
  ARM: dts: BCM5301X: Fixed QSPI compatible string
  ARM: dts: NSP: Fixed QSPI compatible string
  ARM: dts: bcm: HR2: Fixed QSPI compatible string
  dt-bindings: spi: Fix spi-bcm-qspi compatible ordering

Link: https://lore.kernel.org/r/20200909211857.4144718-1-f.fainelli@gmail.comSigned-off-by: Olof Johansson <olof@lixom.net>