linux-stable.git/drivers/usb/typec, branch v5.8.7 Linux kernel stable tree usb: typec: tcpm: Fix Fix source hard reset response for TDA 2.3.1.1 and TDA 2.3.1.2 failures 2020-09-03T09:29:50+00:00 Badhri Jagan Sridharan badhri@google.com 2020-08-17T18:46:01+00:00 b727b92fd33b7d09b986cfb043d71a47ae362633 commit 23e26d0577535f5ffe4ff8ed6d06e009553c0bca upstream. The patch addresses the compliance test failures while running TDA 2.3.1.1 and TDA 2.3.1.2 of the "PD Communications Engine USB PD Compliance MOI" test plan published in https://www.usb.org/usbc. For a product to be Type-C compliant, it's expected that these tests are run on usb.org certified Type-C compliance tester as mentioned in https://www.usb.org/usbc. While the purpose of TDA 2.3.1.1 and TDA 2.3.1.2 is to verify that the static and dynamic electrical capabilities of a Source meet the requirements for each PDO offered, while doing so, the tests also monitor that the timing of the VBUS waveform versus the messages meets the requirements for Hard Reset defined in PROT-PROC-HR-TSTR as mentioned in step 11 of TDA.2.3.1.1 and step 15 of TDA.2.3.1.2. TDB.2.2.13.1: PROT-PROC-HR-TSTR Procedure and Checks for Tester Originated Hard Reset Purpose: To perform the appropriate protocol checks relating to any circumstance in which the Hard Reset signal is sent by the Tester. UUT is behaving as source: The Tester sends a Hard Reset signal. 1. Check VBUS stays within present valid voltage range for tPSHardReset min (25ms) after last bit of Hard Reset signal. [PROT_PROC_HR_TSTR_1] 2. Check that VBUS starts to fall below present valid voltage range by tPSHardReset max (35ms). [PROT_PROC_HR_TSTR_2] 3. Check that VBUS reaches vSafe0V within tSafe0v max (650 ms). [PROT_PROC_HR_TSTR_3] 4. Check that VBUS starts rising to vSafe5V after a delay of tSrcRecover (0.66s - 1s) from reaching vSafe0V. [PROT_PROC_HR_TSTR_4] 5. Check that VBUS reaches vSafe5V within tSrcTurnOn max (275ms) of rising above vSafe0v max (0.8V). [PROT_PROC_HR_TSTR_5] Power Delivery Compliance Plan 139 6. Check that Source Capabilities are finished sending within tFirstSourceCap max (250ms) of VBUS reaching vSafe5v min. [PROT_PROC_HR_TSTR_6]. This is in line with 7.1.5 Response to Hard Resets of the USB Power Delivery Specification Revision 3.0, Version 1.2, "Hard Reset Signaling indicates a communication failure has occurred and the Source Shall stop driving VCONN, Shall remove Rp from the VCONN pin and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The USB connection May reset during a Hard Reset since the VBUS voltage will be less than vSafe5V for an extended period of time. After establishing the vSafe0V voltage condition on VBUS, the Source Shall wait tSrcRecover before re-applying VCONN and restoring VBUS to vSafe5V. A Source Shall conform to the VCONN timing as specified in [USB Type-C 1.3]." With the above guidelines from the spec in mind, TCPM does not turn off VCONN while entering SRC_HARD_RESET_VBUS_OFF. The patch makes TCPM turn off VCONN while entering SRC_HARD_RESET_VBUS_OFF and turn it back on while entering SRC_HARD_RESET_VBUS_ON along with vbus instead of having VCONN on through hardreset. Also, the spec clearly states that "After establishing the vSafe0V voltage condition on VBUS", the Source Shall wait tSrcRecover before re-applying VCONN and restoring VBUS to vSafe5V. TCPM does not conform to this requirement. If the TCPC driver calls tcpm_vbus_change with vbus off signal, TCPM right away enters SRC_HARD_RESET_VBUS_ON without waiting for tSrcRecover. For TCPC's which are buggy/does not call tcpm_vbus_change, TCPM assumes that the vsafe0v is instantaneous as TCPM only waits tSrcRecover instead of waiting for tSafe0v + tSrcRecover. This patch also fixes this behavior by making sure that TCPM waits for tSrcRecover before transitioning into SRC_HARD_RESET_VBUS_ON when tcpm_vbus_change is called by TCPC. When TCPC does not call tcpm_vbus_change, TCPM assumes the worst case i.e. tSafe0v + tSrcRecover before transitioning into SRC_HARD_RESET_VBUS_ON. Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20200817184601.1899929-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 23e26d0577535f5ffe4ff8ed6d06e009553c0bca upstream.

The patch addresses the compliance test failures while running  TDA
2.3.1.1 and  TDA 2.3.1.2 of the "PD Communications Engine USB PD
Compliance MOI" test plan published in https://www.usb.org/usbc.
For a product to be Type-C compliant, it's expected that these tests
are run on usb.org certified Type-C compliance tester as mentioned in
https://www.usb.org/usbc.

While the purpose of TDA 2.3.1.1 and  TDA 2.3.1.2 is to verify that
the static and dynamic electrical capabilities of a Source meet the
requirements for each PDO offered,  while doing so, the tests also
monitor that the timing of the VBUS waveform versus the messages meets
the requirements for Hard Reset defined in PROT-PROC-HR-TSTR as
mentioned in step 11 of TDA.2.3.1.1 and step 15 of TDA.2.3.1.2.

TDB.2.2.13.1: PROT-PROC-HR-TSTR Procedure and Checks for Tester
Originated Hard Reset
Purpose: To perform the appropriate protocol checks relating to any
circumstance in which the Hard Reset signal is sent by the Tester.

UUT is behaving as source:
The Tester sends a Hard Reset signal.
1. Check VBUS stays within present valid voltage range for
tPSHardReset min (25ms) after last bit of Hard Reset signal.
[PROT_PROC_HR_TSTR_1]
2. Check that VBUS starts to fall below present valid voltage range by
tPSHardReset max (35ms). [PROT_PROC_HR_TSTR_2]
3. Check that VBUS reaches vSafe0V within tSafe0v max (650 ms).
[PROT_PROC_HR_TSTR_3]
4. Check that VBUS starts rising to vSafe5V after a delay of
tSrcRecover (0.66s - 1s) from reaching vSafe0V. [PROT_PROC_HR_TSTR_4]
5. Check that VBUS reaches vSafe5V within tSrcTurnOn max (275ms) of
rising above vSafe0v max (0.8V). [PROT_PROC_HR_TSTR_5] Power Delivery
Compliance Plan 139 6. Check that Source Capabilities are finished
sending within tFirstSourceCap max (250ms) of VBUS reaching vSafe5v
min. [PROT_PROC_HR_TSTR_6].

This is in line with 7.1.5 Response to Hard Resets of the USB Power
Delivery Specification Revision 3.0, Version 1.2,
"Hard Reset Signaling indicates a communication failure has occurred
and the Source Shall stop driving VCONN, Shall remove Rp from the
VCONN pin and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The
USB connection May reset during a Hard Reset since the VBUS voltage
will be less than vSafe5V for an extended period of time. After
establishing the vSafe0V voltage condition on VBUS, the Source Shall
wait tSrcRecover before re-applying VCONN and restoring VBUS to
vSafe5V. A Source Shall conform to the VCONN timing as specified in
[USB Type-C 1.3]."

With the above guidelines from the spec in mind, TCPM does not turn
off VCONN while entering SRC_HARD_RESET_VBUS_OFF. The patch makes TCPM
turn off VCONN while entering SRC_HARD_RESET_VBUS_OFF and turn it back
on while entering SRC_HARD_RESET_VBUS_ON along with vbus instead of
having VCONN on through hardreset.

Also, the spec clearly states that "After establishing the vSafe0V
voltage condition on VBUS",  the Source Shall wait tSrcRecover before
re-applying VCONN and restoring VBUS to vSafe5V.
TCPM does not conform to this requirement. If the TCPC driver calls
tcpm_vbus_change with vbus off signal, TCPM right away enters
SRC_HARD_RESET_VBUS_ON without waiting for tSrcRecover.
For TCPC's which are buggy/does not call tcpm_vbus_change, TCPM
assumes that the vsafe0v is instantaneous as TCPM only waits
tSrcRecover instead of waiting for tSafe0v + tSrcRecover.
This patch also fixes this behavior by making sure that TCPM waits for
tSrcRecover before transitioning into SRC_HARD_RESET_VBUS_ON when
tcpm_vbus_change is called by TCPC.
When TCPC does not call tcpm_vbus_change, TCPM assumes the worst case
i.e.  tSafe0v + tSrcRecover before transitioning into
SRC_HARD_RESET_VBUS_ON.

Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20200817184601.1899929-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: Hold con->lock for the entire duration of ucsi_register_port() 2020-09-03T09:29:50+00:00 Hans de Goede hdegoede@redhat.com 2020-08-09T14:19:04+00:00 d597f82cc262cd67d49a3e8337ff8ff7ae07cc13 commit bed97b30968ba354035a020989df0623e52b5536 upstream. Commit 081da1325d35 ("usb: typec: ucsi: displayport: Fix a potential race during registration") made the ucsi code hold con->lock in ucsi_register_displayport(). But we really don't want any interactions with the connector to run before the port-registration process is fully complete. This commit moves the taking of con->lock from ucsi_register_displayport() into ucsi_register_port() to achieve this. Cc: stable@vger.kernel.org Fixes: 081da1325d35 ("usb: typec: ucsi: displayport: Fix a potential race during registration") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200809141904.4317-5-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit bed97b30968ba354035a020989df0623e52b5536 upstream.

Commit 081da1325d35 ("usb: typec: ucsi: displayport: Fix a potential race
during registration") made the ucsi code hold con->lock in
ucsi_register_displayport(). But we really don't want any interactions
with the connector to run before the port-registration process is fully
complete.

This commit moves the taking of con->lock from ucsi_register_displayport()
into ucsi_register_port() to achieve this.

Cc: stable@vger.kernel.org
Fixes: 081da1325d35 ("usb: typec: ucsi: displayport: Fix a potential race during registration")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20200809141904.4317-5-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: Rework ppm_lock handling 2020-09-03T09:29:50+00:00 Hans de Goede hdegoede@redhat.com 2020-08-09T14:19:03+00:00 3c4cd68799f8d2e43c37b1b5707e1d281d193dae commit 25794e3079d2a98547b6bf5764ef0240aa89b798 upstream. The ppm_lock really only needs to be hold during 2 functions: ucsi_reset_ppm() and ucsi_run_command(). Push the taking of the lock down into these 2 functions, renaming ucsi_run_command() to ucsi_send_command() which was an existing wrapper already taking the lock for its callers. This simplifies things for the callers and removes the difference between ucsi_send_command() and ucsi_run_command() which has led to various locking bugs in the past. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200809141904.4317-4-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 25794e3079d2a98547b6bf5764ef0240aa89b798 upstream.

The ppm_lock really only needs to be hold during 2 functions:
ucsi_reset_ppm() and ucsi_run_command().

Push the taking of the lock down into these 2 functions, renaming
ucsi_run_command() to ucsi_send_command() which was an existing
wrapper already taking the lock for its callers.

This simplifies things for the callers and removes the difference
between ucsi_send_command() and ucsi_run_command() which has led
to various locking bugs in the past.

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20200809141904.4317-4-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: Fix 2 unlocked ucsi_run_command calls 2020-09-03T09:29:49+00:00 Hans de Goede hdegoede@redhat.com 2020-08-09T14:19:02+00:00 84e29c7cf5913311b72b663d93c3fac03626efd0 commit 7e90057f125c8c852940b848e06e7a72f050fc6f upstream. Fix 2 unlocked ucsi_run_command calls: 1. ucsi_handle_connector_change() contains one ucsi_send_command() call, which takes the ppm_lock for it; and one ucsi_run_command() call which relies on the caller have taking the ppm_lock. ucsi_handle_connector_change() does not take the lock, so the second (ucsi_run_command) calls should also be ucsi_send_command(). 2. ucsi_get_pdos() gets called from ucsi_handle_connector_change() which does not hold the ppm_lock, so it also must use ucsi_send_command(). This commit also adds a WARN_ON(!mutex_is_locked(&ucsi->ppm_lock)); to ucsi_run_command() to avoid similar problems getting re-introduced in the future. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200809141904.4317-3-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7e90057f125c8c852940b848e06e7a72f050fc6f upstream.

Fix 2 unlocked ucsi_run_command calls:

1. ucsi_handle_connector_change() contains one ucsi_send_command() call,
which takes the ppm_lock for it; and one ucsi_run_command() call which
relies on the caller have taking the ppm_lock.
ucsi_handle_connector_change() does not take the lock, so the
second (ucsi_run_command) calls should also be ucsi_send_command().

2. ucsi_get_pdos() gets called from ucsi_handle_connector_change() which
does not hold the ppm_lock, so it also must use ucsi_send_command().

This commit also adds a WARN_ON(!mutex_is_locked(&ucsi->ppm_lock)); to
ucsi_run_command() to avoid similar problems getting re-introduced in
the future.

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20200809141904.4317-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: Fix AB BA lock inversion 2020-09-03T09:29:49+00:00 Hans de Goede hdegoede@redhat.com 2020-08-09T14:19:01+00:00 4b59dabd317089f9c7addbc529bd49a45b246a77 commit 0ff0705a2ef2929e9326c95df48bdbebb0dafaad upstream. Lockdep reports an AB BA lock inversion between ucsi_init() and ucsi_handle_connector_change(): AB order: 1. ucsi_init takes ucsi->ppm_lock (it runs with that locked for the duration of the function) 2. usci_init eventually end up calling ucsi_register_displayport, which takes ucsi_connector->lock BA order: 1. ucsi_handle_connector_change work is started, takes ucsi_connector->lock 2. ucsi_handle_connector_change calls ucsi_send_command which takes ucsi->ppm_lock The ppm_lock really only needs to be hold during 2 functions: ucsi_reset_ppm() and ucsi_run_command(). This commit fixes the AB BA lock inversion by making ucsi_init drop the ucsi->ppm_lock before it starts registering ports; and replacing any ucsi_run_command() calls after this point with ucsi_send_command() (which is a wrapper around run_command taking the lock while handling the command). Some of the replacing of ucsi_run_command with ucsi_send_command in the helpers used during port registration also fixes a number of code paths after registration which call ucsi_run_command() without holding the ppm_lock: 1. ucsi_altmode_update_active() call in ucsi/displayport.c 2. ucsi_register_altmodes() call from ucsi_handle_connector_change() (through ucsi_partner_change()) Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200809141904.4317-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 0ff0705a2ef2929e9326c95df48bdbebb0dafaad upstream.

Lockdep reports an AB BA lock inversion between ucsi_init() and
ucsi_handle_connector_change():

AB order:

1. ucsi_init takes ucsi->ppm_lock (it runs with that locked for the
   duration of the function)
2. usci_init eventually end up calling ucsi_register_displayport,
   which takes ucsi_connector->lock

BA order:

1. ucsi_handle_connector_change work is started, takes ucsi_connector->lock
2. ucsi_handle_connector_change calls ucsi_send_command which takes
   ucsi->ppm_lock

The ppm_lock really only needs to be hold during 2 functions:
ucsi_reset_ppm() and ucsi_run_command().

This commit fixes the AB BA lock inversion by making ucsi_init drop the
ucsi->ppm_lock before it starts registering ports; and replacing any
ucsi_run_command() calls after this point with ucsi_send_command()
(which is a wrapper around run_command taking the lock while handling
the command).

Some of the replacing of ucsi_run_command with ucsi_send_command
in the helpers used during port registration also fixes a number of
code paths after registration which call ucsi_run_command() without
holding the ppm_lock:
1. ucsi_altmode_update_active() call in ucsi/displayport.c
2. ucsi_register_altmodes() call from ucsi_handle_connector_change()
   (through ucsi_partner_change())

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20200809141904.4317-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: tcpci_rt1711h: avoid screaming irq causing boot hangs 2020-06-18T08:42:53+00:00 Li Jun jun.li@nxp.com 2020-06-04T11:21:18+00:00 302c570bf36e997d55ad0d60628a2feec76954a4 John reported screaming irq caused by rt1711h when system boot[1], this is because irq request is done before tcpci_register_port(), so the chip->tcpci has not been setup, irq handler is entered but can't do anything, this patch is to address this by moving the irq request after tcpci_register_port(). [1] https://lore.kernel.org/linux-usb/20200530040157.31038-1-john.stultz@linaro.org Fixes: ce08eaeb6388 ("staging: typec: rt1711h typec chip driver") Cc: stable <stable@vger.kernel.org> # v4.18+ Cc: John Stultz <john.stultz@linaro.org> Reported-and-tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Li Jun <jun.li@nxp.com> Link: https://lore.kernel.org/r/20200604112118.38062-1-jun.li@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
John reported screaming irq caused by rt1711h when system boot[1],
this is because irq request is done before tcpci_register_port(),
so the chip->tcpci has not been setup, irq handler is entered but
can't do anything, this patch is to address this by moving the irq
request after tcpci_register_port().

[1] https://lore.kernel.org/linux-usb/20200530040157.31038-1-john.stultz@linaro.org

Fixes: ce08eaeb6388 ("staging: typec: rt1711h typec chip driver")
Cc: stable <stable@vger.kernel.org> # v4.18+
Cc: John Stultz <john.stultz@linaro.org>
Reported-and-tested-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
Link: https://lore.kernel.org/r/20200604112118.38062-1-jun.li@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: mux: intel_pmc_mux: Fix DP alternate mode entry 2020-06-18T08:40:57+00:00 Heikki Krogerus heikki.krogerus@linux.intel.com 2020-05-29T13:17:53+00:00 130206a88683d859f63ed6d4a56ab5c2b4930c8e The PMC needs to be notified separately about HPD (hotplug detected) signal being high after mode entry. There is a bit "HPD High" in the Alternate Mode Request that the driver already sets, but that bit is only valid when the DisplayPort Alternate Mode is directly entered from disconnected state. Fixes: 5c4edcdbcd97 ("usb: typec: mux: intel: Fix DP_HPD_LVL bit field") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: stable <stable@vger.kernel.org> Tested-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20200529131753.15587-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The PMC needs to be notified separately about HPD (hotplug
detected) signal being high after mode entry. There is a bit
"HPD High" in the Alternate Mode Request that the driver
already sets, but that bit is only valid when the
DisplayPort Alternate Mode is directly entered from
disconnected state.

Fixes: 5c4edcdbcd97 ("usb: typec: mux: intel: Fix DP_HPD_LVL bit field")
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Tested-by: Prashant Malani <pmalani@chromium.org>
Link: https://lore.kernel.org/r/20200529131753.15587-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'usb-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb 2020-06-07T16:42:16+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-06-07T16:42:16+00:00 e611c0fe318c6d6827ee2bba660fbc23cf73f7dc Pull USB/PHY driver updates from Greg KH: "Here are the large set of USB and PHY driver updates for 5.8-rc1. Nothing huge, just lots of little things: - USB gadget fixes and additions all over the place - new PHY drivers - PHY driver fixes and updates - XHCI driver updates - musb driver updates - more USB-serial driver ids added - various USB quirks added - thunderbolt minor updates and fixes - typec updates and additions All of these have been in linux-next for a while with no reported issues" * tag 'usb-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (245 commits) usb: dwc3: meson-g12a: fix USB2 PHY initialization on G12A and A1 SoCs usb: dwc3: meson-g12a: fix error path when fetching the reset line fails Revert "dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings" Revert "dt-bindings: usb: qcom,dwc3: Add compatible for SC7180" Revert "dt-bindings: usb: qcom,dwc3: Introduce interconnect properties for Qualcomm DWC3 driver" USB: serial: ch341: fix lockup of devices with limited prescaler USB: serial: ch341: add basis for quirk detection CDC-ACM: heed quirk also in error handling USB: serial: option: add Telit LE910C1-EUX compositions usb: musb: Fix runtime PM imbalance on error usb: musb: jz4740: Prevent lockup when CONFIG_SMP is set usb: musb: mediatek: add reset FADDR to zero in reset interrupt handle usb: musb: use true for 'use_dma' usb: musb: start session in resume for host port usb: musb: return -ESHUTDOWN in urb when three-strikes error happened USB: serial: qcserial: add DW5816e QDL support thunderbolt: Add trivial .shutdown usb: dwc3: keystone: Turn on USB3 PHY before controller dt-bindings: usb: ti,keystone-dwc3.yaml: Add USB3.0 PHY property dt-bindings: usb: convert keystone-usb.txt to YAML ... 
Pull USB/PHY driver updates from Greg KH:
 "Here are the large set of USB and PHY driver updates for 5.8-rc1.

  Nothing huge, just lots of little things:

   - USB gadget fixes and additions all over the place

   - new PHY drivers

   - PHY driver fixes and updates

   - XHCI driver updates

   - musb driver updates

   - more USB-serial driver ids added

   - various USB quirks added

   - thunderbolt minor updates and fixes

   - typec updates and additions

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

* tag 'usb-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (245 commits)
  usb: dwc3: meson-g12a: fix USB2 PHY initialization on G12A and A1 SoCs
  usb: dwc3: meson-g12a: fix error path when fetching the reset line fails
  Revert "dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings"
  Revert "dt-bindings: usb: qcom,dwc3: Add compatible for SC7180"
  Revert "dt-bindings: usb: qcom,dwc3: Introduce interconnect properties for Qualcomm DWC3 driver"
  USB: serial: ch341: fix lockup of devices with limited prescaler
  USB: serial: ch341: add basis for quirk detection
  CDC-ACM: heed quirk also in error handling
  USB: serial: option: add Telit LE910C1-EUX compositions
  usb: musb: Fix runtime PM imbalance on error
  usb: musb: jz4740: Prevent lockup when CONFIG_SMP is set
  usb: musb: mediatek: add reset FADDR to zero in reset interrupt handle
  usb: musb: use true for 'use_dma'
  usb: musb: start session in resume for host port
  usb: musb: return -ESHUTDOWN in urb when three-strikes error happened
  USB: serial: qcserial: add DW5816e QDL support
  thunderbolt: Add trivial .shutdown
  usb: dwc3: keystone: Turn on USB3 PHY before controller
  dt-bindings: usb: ti,keystone-dwc3.yaml: Add USB3.0 PHY property
  dt-bindings: usb: convert keystone-usb.txt to YAML
  ...
Merge tag 'platform-drivers-x86-v5.8-1' of git://git.infradead.org/linux-platform-drivers-x86 2020-06-02T19:56:58+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-06-02T19:56:58+00:00 a5a82e0a5918fb2ae27b80d3b9c954b16ae6a7b7 Pull x86 platform driver updates from Andy Shevchenko: - Add a support of the media keys on the ASUS laptop UX325JA/UX425JA - ASUS WMI driver can now handle 2-in-1 models T100TA, T100CHI, T100HA, T200TA - Big refactoring of Intel SCU driver with Elkhart Lake support has been added - Slim Bootloarder firmware update signaling WMI driver has been added - Thinkpad ACPI driver can handle dual fan configuration on new P and X models - Touchscreen DMI driver has been extended to support - MP-man MPWIN895CL tablet - ONDA V891 v5 tablet - techBite Arc 11.6 - Trekstor Twin 10.1 - Trekstor Yourbook C11B - Vinga J116 - Virtual Button driver got a few fixes to detect mode of 2-in-1 tablet models - Intel Speed Select tools update - Plenty of small cleanups here and there * tag 'platform-drivers-x86-v5.8-1' of git://git.infradead.org/linux-platform-drivers-x86: (89 commits) platform/x86: dcdbas: Check SMBIOS for protected buffer address platform/x86: asus_wmi: Reserve more space for struct bias_args platform/x86: intel-vbtn: Only blacklist SW_TABLET_MODE on the 9 / "Laptop" chasis-type platform/x86: intel-hid: Add a quirk to support HP Spectre X2 (2015) platform/x86: touchscreen_dmi: Update Trekstor Twin 10.1 entry platform/x86: touchscreen_dmi: Add info for the Trekstor Yourbook C11B platform/x86: hp-wmi: Introduce HPWMI_POWER_FW_OR_HW as convenient shortcut platform/x86: hp-wmi: Convert simple_strtoul() to kstrtou32() platform/x86: hp-wmi: Refactor postcode_store() to follow standard patterns platform/x86: acerhdf: replace space by * in modalias platform/x86: ISST: Increase timeout tools/power/x86/intel-speed-select: Fix invalid core mask tools/power/x86/intel-speed-select: Increase CPU count tools/power/x86/intel-speed-select: Fix json perf-profile output output platform/x86: dell-wmi: Ignore keyboard attached / detached events platform/x86: dell-laptop: don't register micmute LED if there is no token platform/x86: thinkpad_acpi: Replace custom approach by kstrtoint() platform/x86: thinkpad_acpi: Use strndup_user() in dispatch_proc_write() platform/x86: thinkpad_acpi: Replace next_cmd(&buf) with strsep(&buf, ",") platform/x86: intel-vbtn: Detect switch position before registering the input-device ... 
Pull x86 platform driver updates from Andy Shevchenko:

 - Add a support of the media keys on the ASUS laptop UX325JA/UX425JA

 - ASUS WMI driver can now handle 2-in-1 models T100TA, T100CHI, T100HA,
   T200TA

 - Big refactoring of Intel SCU driver with Elkhart Lake support has
   been added

 - Slim Bootloarder firmware update signaling WMI driver has been added

 - Thinkpad ACPI driver can handle dual fan configuration on new P and X
   models

 - Touchscreen DMI driver has been extended to support
    - MP-man MPWIN895CL tablet
    - ONDA V891 v5 tablet
    - techBite Arc 11.6
    - Trekstor Twin 10.1
    - Trekstor Yourbook C11B
    - Vinga J116

 - Virtual Button driver got a few fixes to detect mode of 2-in-1 tablet
   models

 - Intel Speed Select tools update

 - Plenty of small cleanups here and there

* tag 'platform-drivers-x86-v5.8-1' of git://git.infradead.org/linux-platform-drivers-x86: (89 commits)
  platform/x86: dcdbas: Check SMBIOS for protected buffer address
  platform/x86: asus_wmi: Reserve more space for struct bias_args
  platform/x86: intel-vbtn: Only blacklist SW_TABLET_MODE on the 9 / "Laptop" chasis-type
  platform/x86: intel-hid: Add a quirk to support HP Spectre X2 (2015)
  platform/x86: touchscreen_dmi: Update Trekstor Twin 10.1 entry
  platform/x86: touchscreen_dmi: Add info for the Trekstor Yourbook C11B
  platform/x86: hp-wmi: Introduce HPWMI_POWER_FW_OR_HW as convenient shortcut
  platform/x86: hp-wmi: Convert simple_strtoul() to kstrtou32()
  platform/x86: hp-wmi: Refactor postcode_store() to follow standard patterns
  platform/x86: acerhdf: replace space by * in modalias
  platform/x86: ISST: Increase timeout
  tools/power/x86/intel-speed-select: Fix invalid core mask
  tools/power/x86/intel-speed-select: Increase CPU count
  tools/power/x86/intel-speed-select: Fix json perf-profile output output
  platform/x86: dell-wmi: Ignore keyboard attached / detached events
  platform/x86: dell-laptop: don't register micmute LED if there is no token
  platform/x86: thinkpad_acpi: Replace custom approach by kstrtoint()
  platform/x86: thinkpad_acpi: Use strndup_user() in dispatch_proc_write()
  platform/x86: thinkpad_acpi: Replace next_cmd(&buf) with strsep(&buf, ",")
  platform/x86: intel-vbtn: Detect switch position before registering the input-device
  ...
usb: typec: Ensure USB_ROLE_SWITCH is set as a dependency for tps6598x 2020-05-21T07:36:42+00:00 Bryan O'Donoghue bryan.odonoghue@linaro.org 2020-05-20T15:36:17+00:00 e9ccc35b86653cb15e9bffbe2cbef8781ea2c1dd When I switched on USB role switching for the tps6598x I completely forgot to add the Kconfig dependency. Ensure USB_ROLE_SWITCH is selected to prevent the typs6598x driver being compiled in but the role-switch driver being compiled as a module, leading to link error. Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200520153617.610909-1-bryan.odonoghue@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
When I switched on USB role switching for the tps6598x I completely forgot
to add the Kconfig dependency.

Ensure USB_ROLE_SWITCH is selected to prevent the typs6598x driver being
compiled in but the role-switch driver being compiled as a module, leading
to link error.

Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200520153617.610909-1-bryan.odonoghue@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>