linux.git/drivers/usb/typec, branch v5.7-rc3 Linux kernel source tree usb: typec: altmode: Fix typec_altmode_get_partner sometimes returning an invalid pointer 2020-04-22T17:23:19+00:00 Naoki Kiryu naonaokiryu2@gmail.com 2020-04-22T14:43:45+00:00 0df9433fcae02215c8fd79690c134d535c7bb905 Before this commit, typec_altmode_get_partner would return a const struct typec_altmode * pointing to address 0x08 when to_altmode(adev)->partner was NULL. Add a check for to_altmode(adev)->partner being NULL to fix this. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1785972 Fixes: 5f54a85db5df ("usb: typec: Make sure an alt mode exist before getting its partner") Cc: stable@vger.kernel.org Signed-off-by: Naoki Kiryu <naonaokiryu2@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200422144345.43262-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Before this commit, typec_altmode_get_partner would return a
const struct typec_altmode * pointing to address 0x08 when
to_altmode(adev)->partner was NULL.

Add a check for to_altmode(adev)->partner being NULL to fix this.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1785972
Fixes: 5f54a85db5df ("usb: typec: Make sure an alt mode exist before getting its partner")
Cc: stable@vger.kernel.org
Signed-off-by: Naoki Kiryu <naonaokiryu2@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200422144345.43262-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: tcpm: Ignore CC and vbus changes in PORT_RESET change 2020-04-16T13:01:42+00:00 Badhri Jagan Sridharan badhri@google.com 2020-04-02T21:59:47+00:00 901789745a053286e0ced37960d44fa60267b940 After PORT_RESET, the port is set to the appropriate default_state. Ignore processing CC changes here as this could cause the port to be switched into sink states by default. echo source > /sys/class/typec/port0/port_type Before: [ 154.528547] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [ 154.528560] CC1: 0 -> 0, CC2: 3 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 154.528564] state change PORT_RESET -> SNK_UNATTACHED After: [ 151.068814] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS] [ 151.072440] CC1: 3 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 151.172117] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 151.172136] pending state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED @ 870 ms [rev3 NONE_AMS] [ 152.060106] state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED [delayed 870 ms] [ 152.060118] Start toggling Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200402215947.176577-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
After PORT_RESET, the port is set to the appropriate
default_state. Ignore processing CC changes here as this
could cause the port to be switched into sink states
by default.

echo source > /sys/class/typec/port0/port_type

Before:
[  154.528547] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms
[  154.528560] CC1: 0 -> 0, CC2: 3 -> 0 [state PORT_RESET, polarity 0, disconnected]
[  154.528564] state change PORT_RESET -> SNK_UNATTACHED

After:
[  151.068814] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS]
[  151.072440] CC1: 3 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected]
[  151.172117] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
[  151.172136] pending state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED @ 870 ms [rev3 NONE_AMS]
[  152.060106] state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED [delayed 870 ms]
[  152.060118] Start toggling

Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20200402215947.176577-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: pi3usb30532: Set switch_ / mux_desc name field to NULL 2020-04-16T12:52:09+00:00 Hans de Goede hdegoede@redhat.com 2020-04-14T13:33:13+00:00 97341ef7070d984305aaefe8b713491e3213d6ab Since commit ef441dd6af91 ("usb: typec: mux: Allow the muxes to be named") the typec_switch_desc and typec_mux_desc structs contain a name field. The pi3usb30532 driver allocates these structs on the stack and so far did not explicitly zero the mem used for the structs. This causes the new name fields to point to a random memory address, which in my test case happens to be a valid address leading to "interesting" mux / switch names: [root@localhost ~]# ls -l /sys/class/typec_mux/ total 0 lrwxrwxrwx. 1 root root 0 Apr 14 12:55 ''$'\r''-switch' -> ... lrwxrwxrwx. 1 root root 0 Apr 14 12:55 ''$'\320\302\006''2'$'... Explicitly initialize the structs to zero when declaring them on the stack so that any unused fields get set to 0, fixing this. Fixes: ef441dd6af91 ("usb: typec: mux: Allow the muxes to be named") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200414133313.131802-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Since commit ef441dd6af91 ("usb: typec: mux: Allow the muxes to be named")
the typec_switch_desc and typec_mux_desc structs contain a name field.

The pi3usb30532 driver allocates these structs on the stack and so far did
not explicitly zero the mem used for the structs. This causes the new name
fields to point to a random memory address, which in my test case happens
to be a valid address leading to "interesting" mux / switch names:

[root@localhost ~]# ls -l /sys/class/typec_mux/
total 0
lrwxrwxrwx. 1 root root 0 Apr 14 12:55 ''$'\r''-switch' -> ...
lrwxrwxrwx. 1 root root 0 Apr 14 12:55 ''$'\320\302\006''2'$'...

Explicitly initialize the structs to zero when declaring them on the stack
so that any unused fields get set to 0, fixing this.

Fixes: ef441dd6af91 ("usb: typec: mux: Allow the muxes to be named")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200414133313.131802-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: Correct the documentation for typec_cable_put() 2020-03-26T14:05:43+00:00 Azhar Shaikh azhar.shaikh@intel.com 2020-03-26T13:46:33+00:00 6e562742a052c93d33c52c2e1e6a24a34d2bf3b1 typec_cable_put() function had typec_cable_get in it's documentation. Change it to reflect the correct name. Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com> Link: https://lore.kernel.org/r/20200326134633.26780-1-azhar.shaikh@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
typec_cable_put() function had typec_cable_get in it's documentation.
Change it to reflect the correct name.

Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com>
Link: https://lore.kernel.org/r/20200326134633.26780-1-azhar.shaikh@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge 5.6-rc7 into usb-next 2020-03-23T07:04:08+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2020-03-23T07:04:08+00:00 d2e971d884e7b7e65162788b8f3b7801cd8bc137 We need the USB fixes in here as well. Signed-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>
usb: typec: ucsi_ccg: workaround for NVIDIA test device 2020-03-12T08:49:28+00:00 Ajay Gupta ajayg@nvidia.com 2020-03-10T12:19:12+00:00 706f4bbf187c68cb360548659be7191e43b3650c NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for VirtualLink DP mode and vdo=0x3 for NVIDIA test mode. NVIDIA test device FTB (Function Test Board) reports altmode list with vdo=0x3 first and then vdo=0x1. The list is: SVID VDO 0xff01 0xc05 0x28de 0x8085 0x955 0x3 0x955 0x1 Current logic to assign mode value is based on order in altmode list. This causes a mismatch of CON and SOP altmodes since NVIDIA GPU connector has order of vdo=0x1 first and then vdo=0x3. Fixing this by changing the order of vdo values reported by NVIDIA test device. the new list will be: SVID VDO 0xff01 0xc05 0x28de 0x8085 0x955 0x1085 0x955 0x3 Also NVIDIA VirtualLink (svid 0x955) uses pin E for display mode. NVIDIA test device reports vdo of 0x1 so make sure vdo values always have pin E assignement. Signed-off-by: Ajay Gupta <ajayg@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200310121912.57879-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for
VirtualLink DP mode and vdo=0x3 for NVIDIA test mode. NVIDIA
test device FTB (Function Test Board) reports altmode list with
vdo=0x3 first and then vdo=0x1. The list is:
 SVID   VDO
0xff01  0xc05
0x28de  0x8085
0x955   0x3
0x955   0x1

Current logic to assign mode value is based on order
in altmode list. This causes a mismatch of CON and SOP altmodes
since NVIDIA GPU connector has order of vdo=0x1 first and then
vdo=0x3. Fixing this by changing the order of vdo values
reported by NVIDIA test device. the new list will be:

 SVID   VDO
0xff01  0xc05
0x28de  0x8085
0x955   0x1085
0x955   0x3

Also NVIDIA VirtualLink (svid 0x955) uses pin E for display mode.
NVIDIA test device reports vdo of 0x1 so make sure vdo values
always have pin E assignement.

Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200310121912.57879-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: displayport: Fix a potential race during registration 2020-03-12T08:34:52+00:00 Heikki Krogerus heikki.krogerus@linux.intel.com 2020-03-11T13:00:06+00:00 081da1325d351ea8804cf74e65263ea120834f33 Locking the connector in ucsi_register_displayport() to make sure that nothing can access the displayport alternate mode before the function has finished and the alternate mode is actually ready. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200311130006.41288-3-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Locking the connector in ucsi_register_displayport() to make
sure that nothing can access the displayport alternate mode
before the function has finished and the alternate mode is
actually ready.

Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode")
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200311130006.41288-3-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: displayport: Fix NULL pointer dereference 2020-03-12T08:34:52+00:00 Heikki Krogerus heikki.krogerus@linux.intel.com 2020-03-11T13:00:05+00:00 d16e7b62c5adcd13832c6b0ba364c3468d21b856 If the registration of the DisplayPort was not successful, or if the port does not support DisplayPort alt mode in the first place, the function ucsi_displayport_remove_partner() will fail with NULL pointer dereference when it attempts to access the driver data. Adding a check to the function to make sure there really is driver data for the device before modifying it. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Reported-by: Andrea Gagliardi La Gala <andrea.lagala@gmail.com> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365 Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200311130006.41288-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
If the registration of the DisplayPort was not successful,
or if the port does not support DisplayPort alt mode in the
first place, the function ucsi_displayport_remove_partner()
will fail with NULL pointer dereference when it attempts to
access the driver data.

Adding a check to the function to make sure there really is
driver data for the device before modifying it.

Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode")
Reported-by: Andrea Gagliardi La Gala <andrea.lagala@gmail.com>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200311130006.41288-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: driver for Intel PMC mux control 2020-03-04T10:13:30+00:00 Heikki Krogerus heikki.krogerus@linux.intel.com 2020-03-02T13:53:53+00:00 6701adfa9693bd20b89f2cce57754ced2c18ed3b The Intel PMC microcontroller on the latest Intel platforms has a new function that allows configuration of the USB Multiplexer/DeMultiplexer switches that are under the control of the PMC. The Intel PMC mux control (aka. mux-agent) can be used for swapping the USB data role and for entering alternate modes, DisplayPort or Thunderbolt3. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200302135353.56659-10-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The Intel PMC microcontroller on the latest Intel platforms
has a new function that allows configuration of the USB
Multiplexer/DeMultiplexer switches that are under the
control of the PMC.

The Intel PMC mux control (aka. mux-agent) can be used for
swapping the USB data role and for entering alternate modes,
DisplayPort or Thunderbolt3.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200302135353.56659-10-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: mux: Allow the mux handles to be requested with fwnode 2020-03-04T10:12:49+00:00 Heikki Krogerus heikki.krogerus@linux.intel.com 2020-03-02T13:53:47+00:00 d1c6a769cdf466053ae211789f2b0671c8a72331 Introducing fwnode_typec_switch_get() and fwnode_typec_mux_get() functions that work just like typec_switch_get() and typec_mux_get() but they take struct fwnode_handle as the first parameter instead of struct device. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200302135353.56659-4-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Introducing fwnode_typec_switch_get() and
fwnode_typec_mux_get() functions that work just like
typec_switch_get() and typec_mux_get() but they take struct
fwnode_handle as the first parameter instead of struct
device.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200302135353.56659-4-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>