linux-stable.git/drivers/usb/typec, branch v4.16.2

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

usb: typec: remove duplicate includes

2017-12-06T08:21:17+00:00

These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.

Signed-off-by: Pravin Shedge 
Reviewed-by: Guenter Roeck 
Acked-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

usb: add user selectable option for the whole USB Type-C Support

2017-11-28T14:15:01+00:00

It is more clear from user perspective to wrap the whole USB
Type-C support under a single option that the user can
select, then it is to always ask the user for every USB
Type-C and USB Power Delivery driver separately.

Reported-by: Linus Torvalds 
Signed-off-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

typec: tcpm: fusb302: Resolve out of order messaging events

2017-11-28T14:08:43+00:00

The expectation in the FUSB302 driver is that a TX_SUCCESS event
should occur after a message has been sent, but before a GCRCSENT
event is raised to indicate successful receipt of a message from
the partner. However in some circumstances it is possible to see
the hardware raise a GCRCSENT event before a TX_SUCCESS event
is raised. The upshot of this is that the GCRCSENT handling portion
of code ends up reporting the GoodCRC message to TCPM because the
TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
When TX_SUCCESS is then raised by the chip it ends up consuming the
actual message that was meant for TCPM, and this incorrect sequence
results in a hard reset from TCPM.

To avoid this problem, this commit updates the message reading
code to check whether a GoodCRC message was received or not. Based
on this check it will either report that the previous transmission
has completed or it will pass the msg data to TCPM for futher
processing. This way the incorrect ordering of the events no longer
matters.

Signed-off-by: Adam Thomson 
Reviewed-by: Guenter Roeck 
Acked-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

typec: fusb302: Use dev_err during probe

2017-11-28T14:08:43+00:00

If probe fails, fusb302_debugfs_exit is called making it impossible
to view any logs so use normal dev_err for any error messages during
probe.

Signed-off-by: Mats Karrman 
Reviewed-by: Guenter Roeck 
Acked-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman