Johan writes:
USB-serial updates for 5.11-rc1
Here are the USB-serial updates for 5.11-rc1, including:
- keyspan_pda write-implementation fixes
- digi_acceleport write-wakeup fix
- mos7720 parport-restore fix
- mos7720 parport-tasklet removal
- cp210x termios-handling cleanups
- option device-flag fix
- ftdi_sio GPIO CBUS-configuration improvements
- removal of in_interrupt() uses
Included are also various clean ups.
All have been in linux-next with no reported issues.
* tag 'usb-serial-5.11-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (30 commits)
USB: serial: ftdi_sio: log the CBUS GPIO validity
USB: serial: ftdi_sio: drop GPIO line checking dead code
USB: serial: ftdi_sio: report the valid GPIO lines to gpiolib
USB: serial: option: add interface-number sanity check to flag handling
USB: serial: cp210x: clean up dtr_rts()
USB: serial: cp210x: refactor flow-control handling
USB: serial: cp210x: drop flow-control debugging
USB: serial: cp210x: set terminal settings on open
USB: serial: cp210x: clean up line-control handling
USB: serial: cp210x: return early on unchanged termios
USB: serial: mos7720: defer state restore to a workqueue
USB: serial: mos7720: fix parallel-port state restore
USB: serial: remove write wait queue
USB: serial: digi_acceleport: fix write-wakeup deadlocks
USB: serial: keyspan_pda: drop redundant usb-serial pointer
USB: serial: keyspan_pda: use BIT() macro
USB: serial: keyspan_pda: clean up comments and whitespace
USB: serial: keyspan_pda: clean up xircom/entrega support
USB: serial: keyspan_pda: add write-fifo support
USB: serial: keyspan_pda: increase transmitter threshold
...
During init, vbus_vsafe0v does not get updated till the first
connect as a sink. This causes TCPM to be stuck in SRC_ATTACH_WAIT
state while booting with a sink (For instance: a headset) connected.
[ 1.429168] Start toggling
[ 1.439907] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected]
[ 1.445242] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected]
[ 53.358528] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected]
[ 53.358564] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS]
Fix this by updating vbus_vsafe0v based on vbus_present status
on boot.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201211071911.2205197-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In many cases a function that supports SuperSpeed can very well
operate in SuperSpeedPlus, if a gadget controller supports it,
as the endpoint descriptors (and companion descriptors) are
generally identical and can be re-used. This is true for two
commonly used functions: Android's ADB and MTP. So we can simply
assign the usb_function's ssp_descriptors array to point to its
ss_descriptors, if available. Similarly, we need to allow an
epfile's ioctl for FUNCTIONFS_ENDPOINT_DESC to correctly
return the corresponding SuperSpeed endpoint descriptor in case
the connected speed is SuperSpeedPlus as well.
The only exception is if a function wants to implement an
Isochronous endpoint capable of transferring more than 48KB per
service interval when operating at greater than USB 3.1 Gen1
speed, in which case it would require an additional SuperSpeedPlus
Isochronous Endpoint Companion descriptor to be returned as part
of the Configuration Descriptor. Support for that would need
to be separately added to the userspace-facing FunctionFS API
which may not be a trivial task--likely a new descriptor format
(v3?) may need to be devised to allow for separate SS and SSP
descriptors to be supplied.
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201027230731.9073-1-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter writes:
Below are main changes for v5.11-rc1:
For Chipidea USB2:
- Add tracepoint support for UDC
- Some tiny improvements
For Cadence USB3
- Add some quirks for host mode, and let host work well at more use cases
* SKIP_PHY_INIT
* Disable BEI
* Enable runtime PM default for i.mx platform
- Some tiny improvements
* tag 'usb-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb:
MAINTAINERS: Add myself as a reviewer for CADENCE USB3 DRD IP DRIVER
usb: chipidea: ci_hdrc_imx: Use of_device_get_match_data()
usb: chipidea: usbmisc_imx: Use of_device_get_match_data()
usb: cdns3: fix NULL pointer dereference on no platform data
usb: chipidea: trace: fix the endian issue
usb: chipidea: add tracepoint support for udc
doc: dt-binding: cdns,usb3: add wakeup-irq
usb: cdns3: imx: enable runtime pm by default
usb: cdns3: add quirk for enable runtime pm by default
usb: cdns3: host: disable BEI support
usb: cdns3: host: add xhci_plat_priv quirk XHCI_SKIP_PHY_INIT
usb: cdns3: host: add .suspend_quirk for xhci-plat.c
usb: cdns3: Rids of duplicate error message
usb: cdns3: Add static to cdns3_gadget_exit function
I would like to help in reviewing CADENCE USB3 DRD IP DRIVER patches
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
The retrieval of driver data via of_device_get_match_data() can make
the code simpler.
Use of_device_get_match_data() to simplify the code.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
The retrieval of driver data via of_device_get_match_data() can make
the code simpler.
Use of_device_get_match_data() to simplify the code.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Some platforms (e.g. TI) will not have any platform data which will
lead to NULL pointer dereference if we don't check for NULL pdata.
Fixes: 7cea965775 ("usb: cdns3: add quirk for enable runtime pm by default")
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
To support low power mode for controller, the driver needs wakeup-irq
to reflect the signal changing after controller is stopped, and waking
the controller up accordingly.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Some vendors (eg: NXP) may want to enable runtime pm by default for
power saving, add one quirk for it.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
The Cadence xHCI doesn't support BEI well, it causes the disconnection
of ISOC devices can't be detected, so we disable it.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
cdns3 manages PHY by own DRD driver, so skip the management by
HCD core.
Reviewed-by: Jun Li <jun.li@nxp.com>
Reviewed-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
cdns3 has some special PM sequence between xhci_bus_suspend and
xhci_suspend, add quirk to implement it.
Reviewed-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
On failure, the platform_get_irq_byname prints an error message,
so patch removes error message related to this function from
core.c file.
A change was suggested during reviewing CDNSP driver by Chunfeng Yun.
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Acked-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Function cdns3_gadget_exit is used only in gadget.c file.
This patch removes declaration and definition of this
function from gadget-export.h file and makes it static.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
TCPM at present lacks the notion of VSAFE0V. There
are three vbus threshold levels that are critical to track:
a. vSafe5V - VBUS “5 volts” as defined by the USB
PD specification.
b. vSinkDisconnect - Threshold used for transition from
Attached.SNK to Unattached.SNK.
c. vSafe0V - VBUS “0 volts” as defined by the USB
PD specification.
Tracking vSafe0V is crucial for entry into Try.SNK and
Attached.SRC and turning vbus back on by the source in
response to hard reset.
>From "4.5.2.2.8.2 Exiting from AttachWait.SRC State" section
in the Type-C spec:
"The port shall transition to Attached.SRC when VBUS is at
vSafe0V and the SRC.Rd state is detected on exactly one of
the CC1 or CC2 pins for at least tCCDebounce."
"A DRP that strongly prefers the Sink role may optionally
transition to Try.SNK instead of Attached.SRC when VBUS
is at vSafe0V and the SRC.Rd state is detected on exactly
one of the CC1 or CC2 pins for at least tCCDebounce."
>From "7.1.5 Response to Hard Resets" section in the PD spec:
"After establishing the vSafe0V voltage condition on VBUS,
the Source Shall wait tSrcRecover before re-applying VCONN
and restoring VBUS to vSafe5V."
vbus_present in the TCPM code tracks vSafe5V(vbus_present is true)
and vSinkDisconnect(vbus_present is false).
This change adds is_vbus_vsafe0v callback which when set makes
TCPM query for vSafe0V voltage level when needed.
Since not all TCPC controllers might have the capability
to report vSafe0V, TCPM assumes that vSafe0V is same as
vSinkDisconnect when is_vbus_vsafe0v callback is not set.
This allows TCPM to continue to support controllers which don't
have the support for reporting vSafe0V.
Introducing vSafe0V helps fix the failure reported at
"Step 15. CVS verifies PUT remains in AttachWait.SRC for 500ms"
of "TD 4.7.2 Try. SNK DRP Connect DRP Test" of
"Universal Serial Bus Type-C (USB Type-C) Functional Test
Specification Chapters 4 and 5". Here the compliance tester
intentionally maintains vbus at greater than vSafe0V and expects
the Product under test to stay in AttachWait.SRC till vbus drops
to vSafe0V.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201202040840.663578-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tcpm_check_send_discover does not clear the send_discover flag
when any of the following conditions are not met.
1. data_role is TYPEC_HOST
2. link is pd_capable
Discovery indentity would anyways not be attempted during
the current session anymore when the above conditions are not
met. Hence clear the send_discover flag here to prevent
tcpm_enable_frs_work from rescheduling indefinetly.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201203031908.1491542-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nRetryCount was updated from 3 to 2 between PD2.0 and PD3.0 spec.
nRetryCount in "Table 6-34 Counter parameters" of the PD 2.0
spec is set to 3, whereas, nRetryCount in "Table 6-59 Counter
parameters" is set to 2.
Pass down negotiated rev in pd_transmit so that low level chip
drivers can update the retry count accordingly before attempting
packet transmission.
This helps in passing "TEST.PD.PORT.ALL.02" of the
"Power Delivery Merged" test suite which was initially failing
with "The UUT did not retransmit the message nReryCount times"
In fusb302 & tcpci drivers, by default the driver sets the retry
count to 3 (Default for PD 2.0). Update this to 2,
if the negotiated rev is PD 3.0.
In wcove, since the retry count is intentionally set to max, leaving
it as is.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201202031733.647808-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
