linux-stable.git/drivers/usb/typec, branch linux-4.16.y

usb: typec: tps6598x: handle block reads separately with plain-I2C adapters

2018-06-20T19:01:34+00:00

[ Upstream commit 1a2f474d328f292ee706414824ec4ca690cdf5ba ]

If the I2C adapter that the PD controller is attached to
does not support SMBus protocol, the driver needs to handle
block reads separately. The first byte returned in block
read protocol will show the total number of bytes. It needs
to be stripped away.

This is handled separately in the driver only because right
now we have no way of requesting the used protocol with
regmap-i2c. This is in practice a workaround for what is
really a problem in regmap-i2c. The other option would have
been to register custom regmap, or not use regmap at all,
however, since the solution is very simple, I choose to use
it in this case for convenience. It is easy to remove once
we figure out how to handle this kind of cases in
regmap-i2c.

Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
Reviewed-by: Guenter Roeck 
Signed-off-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: fix tracepoint related build error

2018-06-20T19:01:22+00:00

[ Upstream commit 2f860691c2d2e3af1404ffeb2d22dd5c3dbca811 ]

There is the following build error with CONFIG_TYPEC_UCSI=m, CONFIG_FTRACE=y
and CONFIG_TRACING=n:

ERROR: "__tracepoint_ucsi_command" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_register_port" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_notify" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_reset_ppm" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_run_command" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_ack" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_connector_change" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!

This compination is quite hard to create because CONFIG_TRACING gets selected
only in rare cases without CONFIG_FTRACE.

The build failure is caused by conditionally compiling trace.c depending on
the wrong option CONFIG_FTRACE. Change this to depend on CONFIG_TRACING like
other users of tracepoints do.

Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
Signed-off-by: Tobias Regnery 
Acked-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: typec: wcove: Remove dependency on HW FSM

2018-06-16T07:43:43+00:00

commit 05826ff135ee083d28c006fbde6e810f17437166 upstream.

The USB Type-C PHY in Intel WhiskeyCove PMIC has build-in
USB Type-C state machine which we were relying on to
configure the CC lines correctly. This patch removes that
dependency and configures the CC line according to commands
from the port manager (tcpm.c) in wcove_set_cc().

This fixes an issue where USB devices attached to the USB
Type-C port do not get enumerated. When acting as
source/host, the HW FSM sometimes fails to configure the PHY
correctly.

Fixes: 3c4fb9f16921 ("usb: typec: wcove: start using tcpm for USB PD support")
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Increase command completion timeout value

2018-05-01T19:47:20+00:00

commit b1b59e16075f5e5da2943ce8de724ab96bc3c6c2 upstream.

On some boards, under heavy load, the EC firmware is
unable to complete commands even in one second. Increasing
the command completion timeout value to five seconds.

Reported-by: Quanxian Wang 
Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
Cc: 
Signed-off-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpm: fusb302: Do not log an error on -EPROBE_DEFER

2018-03-09T19:19:22+00:00

Do not log an error if tcpm_register_port() fails with -EPROBE_DEFER.

Fixes: cf140a356971 ("typec: fusb302: Use dev_err during probe")
Signed-off-by: Hans de Goede 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

Revert "typec: tcpm: Only request matching pdos"

2018-03-06T17:17:34+00:00

Commit 57e6f0d7b804 ("typec: tcpm: Only request matching pdos") is causing
a regression, before this commit e.g. the GPD win and GPD pocket devices
were charging at 9V 3A with a PD charger, now they are instead slowly
discharging  at 5V 0.4A, as this commit causes the ports max_snk_mv/ma/mw
settings to be completely ignored.

Arguably the way to fix this would be to add a PDO_VAR() describing the
voltage range to the snk_caps of boards which can handle any voltage in
their range, but the "typec: tcpm: Only request matching pdos" commit
looks at the type of PDO advertised by the source/charger and if that
is fixed (as it typically is) only compairs against PDO_FIXED entries
in the snk_caps so supporting a range of voltage would require adding a
PDO_FIXED entry for *every possible* voltage to snk_caps.

AFAICT there is no reason why a fixed source_cap cannot be matched against
a variable snk_cap, so at a minimum the commit should be rewritten to
support that.

For now lets revert the "typec: tcpm: Only request matching pdos" commit,
fixing the regression.

Fixes: 57e6f0d7b804 ("typec: tcpm: Only request matching pdos")
Cc: Badhri Jagan Sridharan 
Signed-off-by: Hans de Goede 
Acked-by: Heikki Krogerus 
Acked-by: Adam Thomson 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

Merge 4.15-rc4 into usb-next

2017-12-18T08:08:05+00:00

We want the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

usb: typec: wcove: fix the sink capabilities

2017-12-12T12:16:07+00:00

USB Power Delivery Specification (v3.0) dictates in ch.
6.4.1 - Capabilities Message - that the vSafe5V Fixed Supply
Object shall always be the first object. tcpm.c now checks
that this rule is obeyed (commit 5007e1b5db73 "typec: tcpm
Validate source and sink caps"), and that makes the
typec_wcove.c fail to probe. The voltage is higher then what
is permitted for the vSafe5V parameter.

Dropping the voltage in the first Fixed Supply object of the
sink capabilities down to 5V, and maximum current down to
500mA, making the driver probe successfully again.

Also, removing the Battery and Variable Supply objects, as
there is no need for them.

Signed-off-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

typec: tcpm: Only request matching pdos

2017-12-07T15:03:15+00:00

At present, TCPM code assumes that local device supports
variable/batt pdos and always selects the pdo with highest
possible power within the board limit. This assumption
might not hold good for all devices. To overcome this,
this patch makes TCPM only accept a source_pdo when there is
a matching sink pdo.

For Fixed pdos: The voltage should match between the
incoming source_cap and the registered snk_pdo
For Variable/Batt pdos: The incoming source_cap voltage
range should fall within the registered snk_pdo's voltage
range.

Also, when the cap_mismatch bit is set, the max_power/current
should be set to the max_current/power of the sink_pdo.
This is according to:

"If the Capability Mismatch bit is set to one
The Maximum Operating Current/Power field may contain a value
larger than the maximum current/power offered in the Source
Capabilities message’s PDO as referenced by the Object position field.
This enables the Sink to indicate that it requires more current/power
than is being offered. If the Sink requires a different voltage this
will be indicated by its Sink Capabilities message.

Signed-off-by: Badhri Jagan Sridharan 
Acked-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

typec: tcpm: Validate source and sink caps

2017-12-07T15:03:15+00:00

The source and sink caps should follow the following rules.
This patch validates whether the src_caps/snk_caps adheres
to it.

6.4.1 Capabilities Message
A Capabilities message (Source Capabilities message or Sink
Capabilities message) shall have at least one Power
Data Object for vSafe5V. The Capabilities message shall also
contain the sending Port’s information followed by up to
6 additional Power Data Objects. Power Data Objects in a
Capabilities message shall be sent in the following order:

1. The vSafe5V Fixed Supply Object shall always be the first object.
2. The remaining Fixed Supply Objects, if present, shall be sent
   in voltage order; lowest to highest.
3. The Battery Supply Objects, if present shall be sent in Minimum
   Voltage order; lowest to highest.
4. The Variable Supply (non-battery) Objects, if present, shall be
   sent in Minimum Voltage order; lowest to highest.

Errors in source/sink_caps of the local port will prevent
the port registration. Whereas, errors in source caps of partner
device would only log them.

Signed-off-by: Badhri Jagan Sridharan 
Acked-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman