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

usb: typec: tcpm: Fix sink PDO starting index for PPS APDO selection

2018-07-20T14:40:04+00:00

There is a bug in the sink PDO search code when trying to select
a PPS APDO. The current code actually sets the starting index for
searching to whatever value 'i' is, rather than choosing index 1
to avoid the first PDO (always 5V fixed). As a result, for sources
which support PPS but whose PPS APDO index does not match with the
supporting sink PPS APDO index for the platform, no valid PPS APDO
will be found so this feature will not be permitted.

Sadly in testing, both Source and Sink capabilities matched up and
this was missed. Code is now updated to correctly set the start
index to 1, and testing with additional PPS capable sources show
this to work as expected.

Signed-off-by: Adam Thomson 
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS")
Reviewed-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

typec: tcpm: Correctly report power_supply current and voltage for non pd supply

2018-07-02T15:38:07+00:00

Commit f2a8aa053c17 ("typec: tcpm: Represent source supply through
power_supply") moved the code to register a power_supply representing
the device supplying power to the type-C connector, from the fusb302
code to the generic tcpm code so that we have a psy reporting the
supply voltage and current for all tcpm devices.

This broke the reporting of current and voltage through the psy interface
when supplied by a a non pd supply (5V, current as reported by
get_current_limit). The cause of this breakage is port->supply_voltage
and port->current_limit not being set in that case.

This commit fixes this by setting port->supply_voltage and
port->current_limit from tcpm_set_current_limit().

This commit also removes setting supply_voltage and current_limit
from tcpm_reset_port() as that calls tcpm_set_current_limit(0, 0)
which now already sets these to 0.

Fixes: f2a8aa053c17 ("typec: tcpm: Represent source supply through...")
Signed-off-by: Hans de Goede 
Reviewed-by: Guenter Roeck 
Reviewed-by: Adam Thomson 
Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpm: fix logbuffer index is wrong if _tcpm_log is re-entered

2018-06-25T13:43:35+00:00

The port->logbuffer_head may be wrong if the two processes enters
_tcpm_log at the mostly same time. The 2nd process enters _tcpm_log
before the 1st process update the index, then the 2nd process will
not allocate logbuffer, when the 2nd process tries to use log buffer,
the index has already updated by the 1st process, so it will get
NULL pointer for updated logbuffer, the error message like below:

	tcpci 0-0050: Log buffer index 6 is NULL

Cc: Heikki Krogerus 
Cc: Guenter Roeck 
Cc: Jun Li 
Signed-off-by: Peter Chen 
Reviewed-by: Heikki Krogerus 
Cc: stable 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

typec: tcpm: Fix a msecs vs jiffies bug

2018-06-25T13:39:12+00:00

The tcpm_set_state() function take msecs not jiffies.

Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
Signed-off-by: Dan Carpenter 
Acked-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Fix for incorrect status data issue

2018-06-25T13:30:12+00:00

According to UCSI Specification, Connector Change Event only
means a change in the Connector Status and Operation Mode
fields of the STATUS data structure. So any other change
should create another event.

Unfortunately on some platforms the firmware acting as PPM
(platform policy manager - usually embedded controller
firmware) still does not report any other status changes if
there is a connector change event. So if the connector power
or data role was changed when a device was plugged to the
connector, the driver does not get any indication about
that. The port will show wrong roles if that happens.

To fix the issue, always checking the data and power role
together with a connector change event.

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

usb: typec: ucsi: acpi: Workaround for cache mode issue

2018-06-25T13:30:12+00:00

This fixes an issue where the driver fails with an error:

	ioremap error for 0x3f799000-0x3f79a000, requested 0x2, got 0x0

On some platforms the UCSI ACPI mailbox SystemMemory
Operation Region may be setup before the driver has been
loaded. That will lead into the driver failing to map the
mailbox region, as it has been already marked as write-back
memory. acpi_os_ioremap() for x86 uses ioremap_cache()
unconditionally.

When the issue happens, the embedded controller has a
pending query event for the UCSI notification right after
boot-up which causes the operation region to be setup before
UCSI driver has been loaded.

The fix is to notify acpi core that the driver is about to
access memory region which potentially overlaps with an
operation region right before mapping it.
acpi_release_memory() will check if the memory has already
been setup (mapped) by acpi core, and deactivate it (unmap)
if it has. The driver is then able to map the memory with
ioremap_nocache() and set the memtype to uncached for the
region.

Reported-by: Paul Menzel 
Fixes: 8243edf44152 ("usb: typec: ucsi: Add ACPI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

USB: typec: fsusb302: no need to check return value of debugfs_create_dir()

2018-05-31T14:03:59+00:00

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Clean up the fsusb302 driver to not care if the root directory was
created, as the code should work properly either way.

Cc: Heikki Krogerus 
Cc: Hans de Goede 
Cc: Andy Shevchenko 
Cc: Adam Thomson 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

USB: typec: tcpm: no need to check return value of debugfs_create_dir()

2018-05-31T10:54:21+00:00

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Clean up the tcpm.c code to not care about this, turns out no one was
even checking the return value of this function, so it didn't matter.

Note, I do not think this code can be removed in a running system, as
the debugfs root directory will stick around, that should be fixed
someday...

Revieved-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

usb: typec: wcove: Remove dependency on HW FSM

2018-05-24T16:17:00+00:00

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: fusb302: Fix debugfs issue

2018-05-24T16:17:00+00:00

Removing the "fusb302" debugfs directory when unloading
the driver. That allows the driver to be loaded more then
one time. The directory will not get actually removed until
it is empty, so only after the last instance has been
removed.

This fixes an issue where the driver can't be re-loaded if
it has been unloaded as the "fusb302" debugfs directory
already exists.

Fixes: 76f0c53d08b9 ("usb: typec: fusb302: Move out of staging")
Signed-off-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman