linux-stable.git/drivers/usb/typec, branch v5.7.7 Linux kernel stable tree usb: typec: mux: intel_pmc_mux: Fix DP alternate mode entry 2020-06-30T19:35:56+00:00 Heikki Krogerus heikki.krogerus@linux.intel.com 2020-05-29T13:17:53+00:00 1f5cbe989afa641f2dca4eef2dbdb6b652cb8ffa commit 130206a88683d859f63ed6d4a56ab5c2b4930c8e upstream. 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> 
commit 130206a88683d859f63ed6d4a56ab5c2b4930c8e upstream.

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>
usb: typec: tcpci_rt1711h: avoid screaming irq causing boot hangs 2020-06-30T19:35:55+00:00 Li Jun jun.li@nxp.com 2020-06-04T11:21:18+00:00 745dcedb896a740825160228f98dbb5725a49f85 commit 302c570bf36e997d55ad0d60628a2feec76954a4 upstream. 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> 
commit 302c570bf36e997d55ad0d60628a2feec76954a4 upstream.

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: Fix DP_HPD_LVL bit field 2020-05-13T12:33:51+00:00 Prashant Malani pmalani@chromium.org 2020-05-11T09:18:34+00:00 5c4edcdbcd97fb3fb657898d0463afb84e4fbbb3 According to the PMC Type C Subsystem (TCSS) Mux programming guide rev 0.6, the PMC HPD request LVL bit field is bit 4. Fix the definition here to match the programming guide. Since this bit field is changing, explicitly define a field for the HPD_HIGH mode data bit. Signed-off-by: Prashant Malani <pmalani@chromium.org> Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control") Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200511091837.102508-1-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
0.6, the PMC HPD request LVL bit field is bit 4.
Fix the definition here to match the programming guide.

Since this bit field is changing, explicitly define a field for the
HPD_HIGH mode data bit.

Signed-off-by: Prashant Malani <pmalani@chromium.org>
Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
Reviewed-by: Benson Leung <bleung@chromium.org>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200511091837.102508-1-pmalani@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: mux: intel: Handle alt mode HPD_HIGH 2020-05-05T11:06:46+00:00 Prashant Malani pmalani@chromium.org 2020-04-29T05:44:28+00:00 7990be48ef4d87163940d6c04c349c93f0bd9ae7 According to the PMC Type C Subsystem (TCSS) Mux programming guide rev 0.6, when a device is transitioning to DP Alternate Mode state, if the HPD_STATE (bit 7) field in the status update command VDO is set to HPD_HIGH, the HPD_HIGH field in the Alternate Mode request “mode_data” field (bit 14) should also be set. Ensure the bit is correctly handled while issuing the Alternate Mode request. Signed-off-by: Prashant Malani <pmalani@chromium.org> Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control") Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200429054432.134178-1-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
0.6, when a device is transitioning to DP Alternate Mode state, if the
HPD_STATE (bit 7) field in the status update command VDO is set to
HPD_HIGH, the HPD_HIGH field in the Alternate Mode request “mode_data”
field (bit 14) should also be set. Ensure the bit is correctly handled
while issuing the Alternate Mode request.

Signed-off-by: Prashant Malani <pmalani@chromium.org>
Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200429054432.134178-1-pmalani@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: intel_pmc_mux: Fix the property names 2020-05-05T11:06:46+00:00 Heikki Krogerus heikki.krogerus@linux.intel.com 2020-04-30T13:56:57+00:00 e283f5e89f44a80ca536e4a12903c64e9e9a82e4 The device property names for the port index number are "usb2-port-number" and "usb3-port-number", not "usb2-port" and "usb3-port". Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200430135657.45169-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The device property names for the port index number are
"usb2-port-number" and "usb3-port-number", not "usb2-port"
and "usb3-port".

Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200430135657.45169-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>