This patch adds USB role switch support to the tps6598x.
The setup to initiate or accept a data-role switch is both assumed and
currently required to be baked-into the firmware as described in TI's
document here.
Link: https://www.ti.com/lit/an/slva843a/slva843a.pdf
With this change its possible to use the USB role-switch API to detect and
notify role-switches to downstream consumers.
Tested with a ChipIdea controller on a Qualcomm MSM8939.
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Gustavo A. R. Silva <garsilva@embeddedor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20200511231930.2825183-2-bryan.odonoghue@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The SBU and HSL orientation may be fixed/static from the mux
PoW. Apparently the retimer may take care of the orientation
of these lines. Handling the static SBU (AUX) and HSL
orientation with device properties.
If the SBU orientation is static, a device property
"sbu-orintation" can be used. When the property exists, the
driver always sets the SBU orientation according to the
property value, and when it's not set, the driver uses the
cable plug orientation with SBU.
And with static HSL orientation, "hsl-orientation" device
property can be used in the same way.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200507150900.12102-3-heikki.krogerus@linux.intel.com
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: 6701adfa96 ("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>
The device property names for the port index number are
"usb2-port-number" and "usb3-port-number", not "usb2-port"
and "usb3-port".
Fixes: 6701adfa96 ("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 stub was ucsi_register_port() when it should have been
ucsi_register_port_psy().
Cc: Abhilash K V <abhilash.k.v@intel.com>
Fixes: 992a60ed0d ("usb: typec: ucsi: register with power_supply class")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200427111246.4889-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With this change the UCSI device will show up in
/sys/class/power_supply/. The following values are exported:
- online
- usb_type
- voltage_min
- voltage_max
- voltage_now
- current_max
- current_now
Once a PD-capable type-C power source is connected to the system, GET_PDOS
UCSI command is used to query all source capabilities. Request data object
(RDO) is used to get current values.
Signed-off-by: K V, Abhilash <abhilash.k.v@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200423132058.6972-7-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When connected to a PD-capable power-source, read & save all partner
power data objects (PDOs) by using GET_PDOS UCSI command.
Also, save the current power contract in request data object (RDO)
for that connector.
Signed-off-by: K V, Abhilash <abhilash.k.v@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200423132058.6972-6-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bit 0 is reserved in CCI (Command Status & Connector Change Indicator)
register. So, change bit-mask for connector number field to 7..1
instead of 7..0.
There would be no functional change since we were anyways right-shifing
by 1 bit.
Signed-off-by: K V, Abhilash <abhilash.k.v@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200423132058.6972-5-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
EC firmware on Dell XPS & Latitude series does not set "Power Operation
Mode Change" bit in "Connector Status change" field of MESSAGE IN Data
while transitioning from type-C current to PD mode.
Instead the "Negotiated Power Level Change" bit is set when the "Power
Operation Mode" field shows the correct mode (i.e. PD).
This patch adds a check for this bit also, to trigger an update of
power operation mode in class driver, while handling GET_CONNECTOR_STATUS
command.
Signed-off-by: K V, Abhilash <abhilash.k.v@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200423132058.6972-3-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently UCSI framework doesn't update USB data role when partner type
is reported as power cable or power cable with ufp connected. This
results into no USB host mode functionality. This is valid usecase where
user wants to use legacy type c power cable with type a female connector
to attach different USB devices like mouse, thumb drive etc. Hence update
USB data role as host when partner type is reported as power cable or
power cable with ufp connected.
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200423132058.6972-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch corrects the SPDX License Identifier style in
header file related to USB Type-C support.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used).
Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46.
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Reviewed-by Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20200419133051.GA7154@nishad
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This converts the FUSB302 driver to use GPIO descriptors.
The conversion to descriptors per se is pretty straight-forward.
In the process I discovered that:
1. The driver uses a completely undocumented device tree binding
for the interrupt GPIO line, "fcs,int_n". Ooops.
2. The undocumented binding, presumably since it has not seen
review, is just "fcs,int_n", lacking the compulsory "-gpios"
suffix and also something that is not a good name because
the "_n" implies the line is inverted which is something we
handle with flags in the device tree. Ooops.
3. Possibly the driver should not be requesting the line as a
GPIO and request the corresponding interrupt line by open
coding, the GPIO chip is very likely doubleing as an IRQ
controller and can probably provide an interrupt directly
for this line with interrupts-extended = <&gpio0 ...>;
4. Possibly the IRQ should just be tagged on the I2C client node
in the device tree like apparently ACPI does, as it overrides
this IRQ with client->irq if that exists.
But now it is too late to do much about that and as I can see
this is used like this in the Pinebook which is a shipping product
so let'a just contain the mess and move on.
The property currently appears in:
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
Create a quirk in the GPIO OF library to allow this property
specifically to be specified without the "-gpios" suffix, we have
other such bindings already.
Cc: Tobias Schramm <t.schramm@manjaro.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Yueyao Zhu <yueyao@google.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200415192448.305257-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since commit ef441dd6af ("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: ef441dd6af ("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>
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>
NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for
VirtualLink DP mode and vdo=0x3 for NVIDIA test mode. NVIDIA
test device FTB (Function Test Board) reports altmode list with
vdo=0x3 first and then vdo=0x1. The list is:
SVID VDO
0xff01 0xc05
0x28de 0x8085
0x955 0x3
0x955 0x1
Current logic to assign mode value is based on order
in altmode list. This causes a mismatch of CON and SOP altmodes
since NVIDIA GPU connector has order of vdo=0x1 first and then
vdo=0x3. Fixing this by changing the order of vdo values
reported by NVIDIA test device. the new list will be:
SVID VDO
0xff01 0xc05
0x28de 0x8085
0x955 0x1085
0x955 0x3
Also NVIDIA VirtualLink (svid 0x955) uses pin E for display mode.
NVIDIA test device reports vdo of 0x1 so make sure vdo values
always have pin E assignement.
Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200310121912.57879-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Locking the connector in ucsi_register_displayport() to make
sure that nothing can access the displayport alternate mode
before the function has finished and the alternate mode is
actually ready.
Fixes: af8622f6a5 ("usb: typec: ucsi: Support for DisplayPort alt mode")
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200311130006.41288-3-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the registration of the DisplayPort was not successful,
or if the port does not support DisplayPort alt mode in the
first place, the function ucsi_displayport_remove_partner()
will fail with NULL pointer dereference when it attempts to
access the driver data.
Adding a check to the function to make sure there really is
driver data for the device before modifying it.
Fixes: af8622f6a5 ("usb: typec: ucsi: Support for DisplayPort alt mode")
Reported-by: Andrea Gagliardi La Gala <andrea.lagala@gmail.com>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200311130006.41288-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Intel PMC microcontroller on the latest Intel platforms
has a new function that allows configuration of the USB
Multiplexer/DeMultiplexer switches that are under the
control of the PMC.
The Intel PMC mux control (aka. mux-agent) can be used for
swapping the USB data role and for entering alternate modes,
DisplayPort or Thunderbolt3.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200302135353.56659-10-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Introducing fwnode_typec_switch_get() and
fwnode_typec_mux_get() functions that work just like
typec_switch_get() and typec_mux_get() but they take struct
fwnode_handle as the first parameter instead of struct
device.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200302135353.56659-4-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adding helpers typec_switch_set() and typec_mux_set() that
simply call the ->set callback function of the mux. These
functions make it possible to set the mux states also from
outside the class code.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200302135353.56659-3-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The mux devices have been named by using the name of the
parent device as base until now, but if for example the
parent device has multiple muxes that will not work. This
makes it possible to supply the name for a mux during
registration.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200302135353.56659-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Per typec spec:
Figure 4-15 Connection State Diagram: DRP
Figure 4-16 Connection State Diagram: DRP with Accessory and Try.SRC
Support
Figure 4-17 Connection State Diagram: DRP with Accessory and Try.SNK
Support
DRP port should move to Unattached.SNK instead of Unattached.SRC if
sink removed.
Signed-off-by: Li Jun <jun.li@nxp.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/1582128343-22438-1-git-send-email-jun.li@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ucsi ppm is unregistered during fw flashing so disable
runtime pm also and reenable after fw flashing is completed
and ppm is re-registered.
Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200217144913.55330-3-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for
VirtualLink DP mode and vdo=0x3 for NVIDIA test mode.
Register display altmode driver only for vdo=0x1
Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200217144913.55330-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the typec port data role is separated from power role,
so check the port data capability when setting data role.
Signed-off-by: Li Jun <jun.li@nxp.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/1581666828-2063-1-git-send-email-jun.li@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using the generic notification chain is not reasonable with
the alternate modes because it would require dependencies
between the drivers of the components that need the
notifications, and the typec drivers.
There are no users for the alternate mode notifications, so
removing the chain and the API for it completely.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200211112531.86510-6-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Even though originally the USB Type-C Specification did not
describe the steps for power role swapping without USB PD
contract in place, it did not actually mean power role swap
without USB PD was not allowed. The USB Type-C Specification
did not clearly separate the data and power roles until in
the release 1.2 which is why there also were no clear steps
for the scenario where only the power role was swapped
without USB PD contract before that.
Since in the latest version of the specification the power
role swap without USB PD is now clearly mentioned as allowed
operation, removing the check that prevented power role swap
without USB PD support.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200211112531.86510-4-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The port_type attribute is special. It is meant to allow
changing the capability of the port in runtime. It is purely
Linux kernel specific feature, i.e. the feature is not
described in any of the USB specifications.
Because of the special nature of this attribute, handling it
differently compared to the other writable attributes, and
hiding it when the underlying port interface (or just the
driver) does not support the feature.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200211112531.86510-3-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This affects the read-writable attribute files. Before this
there was no way for the user to know is changing the value
supported or not.
>From now on those attribute files will be made read-only
unless the underlying driver supports changing of the value.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200211112531.86510-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Variable num is being assigned with a value that is never read, it is
assigned a new value later in a for-loop. The assignment is redundant
and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200208165022.30429-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here is the big USB and Thunderbolt and PHY driver updates for 5.6-rc1.
With the advent of USB4, "Thunderbolt" has really become USB4, so the
renaming of the Kconfig option and starting to share subsystem code has
begun, hence both subsystems coming in through the same tree here.
PHY driver updates also touched USB drivers, so that is coming in
through here as well.
Major stuff included in here are:
- USB 4 initial support added (i.e. Thunderbolt)
- musb driver updates
- USB gadget driver updates
- PHY driver updates
- USB PHY driver updates
- lots of USB serial stuff fixed up
- USB typec updates
- USB-IP fixes
- lots of other smaller USB driver updates
All of these have been in linux-next for a while now (the usb-serial
tree is already tested in linux-next on its own before merged into
here), with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXjFTNw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynpKQCgrh2FoobS2x0oFg/OUHdjokQV/BYAoJGWLOmt
8S5cnsCuLq3w5qpCcBva
=PMGd
-----END PGP SIGNATURE-----
Merge tag 'usb-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB/Thunderbolt/PHY driver updates from Greg KH:
"Here is the big USB and Thunderbolt and PHY driver updates for
5.6-rc1.
With the advent of USB4, "Thunderbolt" has really become USB4, so the
renaming of the Kconfig option and starting to share subsystem code
has begun, hence both subsystems coming in through the same tree here.
PHY driver updates also touched USB drivers, so that is coming in
through here as well.
Major stuff included in here are:
- USB 4 initial support added (i.e. Thunderbolt)
- musb driver updates
- USB gadget driver updates
- PHY driver updates
- USB PHY driver updates
- lots of USB serial stuff fixed up
- USB typec updates
- USB-IP fixes
- lots of other smaller USB driver updates
All of these have been in linux-next for a while now (the usb-serial
tree is already tested in linux-next on its own before merged into
here), with no reported issues"
[ Removed an incorrect compile test enablement for PHY_EXYNOS5250_SATA
that causes configuration warnings - Linus ]
* tag 'usb-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (207 commits)
Doc: ABI: add usb charger uevent
usb: phy: show USB charger type for user
usb: cdns3: fix spelling mistake and rework grammar in text
usb: phy: phy-gpio-vbus-usb: Convert to GPIO descriptors
USB: serial: cyberjack: fix spelling mistake "To" -> "Too"
USB: serial: ir-usb: simplify endpoint check
USB: serial: ir-usb: make set_termios synchronous
USB: serial: ir-usb: fix IrLAP framing
USB: serial: ir-usb: fix link-speed handling
USB: serial: ir-usb: add missing endpoint sanity check
usb: typec: fusb302: fix "op-sink-microwatt" default that was in mW
usb: typec: wcove: fix "op-sink-microwatt" default that was in mW
usb: dwc3: pci: add ID for the Intel Comet Lake -V variant
usb: typec: tcpci: mask event interrupts when remove driver
usb: host: xhci-tegra: set MODULE_FIRMWARE for tegra186
usb: chipidea: add inline for ci_hdrc_host_driver_init if host is not defined
usb: chipidea: handle single role for usb role class
usb: musb: fix spelling mistake: "periperal" -> "peripheral"
phy: ti: j721e-wiz: Fix build error without CONFIG_OF_ADDRESS
USB: usbfs: Always unlink URBs in reverse order
...
- remove ioremap_nocache given that is is equivalent to
ioremap everywhere
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAl4vKHwLHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYMPGBAAuVNUZaZfWYHpiVP2oRcUQUguFiD3NTbknsyzV2oH
J9P0GfeENSKwE9OOhZ7XIjnCZAJwQgTK/ppQY5yiQ/KAtYyyXjXEJ6jqqjiTDInr
+3+I3t/LhkgrK7tMrb7ylTGa/d7KhaciljnOXC8+b75iddvM9I1z2pbHDbppZMS9
wT4RXL/cFtRb85AfOyPLybcka3f5P2gGvQz38qyimhJYEzHDXZu9VO1Bd20f8+Xf
eLBKX0o6yWMhcaPLma8tm0M0zaXHEfLHUKLSOkiOk+eHTWBZ3b/w5nsOQZYZ7uQp
25yaClbameAn7k5dHajduLGEJv//ZjLRWcN3HJWJ5vzO111aHhswpE7JgTZJSVWI
ggCVkytD3ESXapvswmACSeCIDMmiJMzvn6JvwuSMVB7a6e5mcqTuGo/FN+DrBF/R
IP+/gY/T7zIIOaljhQVkiEIIwiD/akYo0V9fheHTBnqcKEDTHV4WjKbeF6aCwcO+
b8inHyXZSKSMG//UlDuN84/KH/o1l62oKaB1uDIYrrL8JVyjAxctWt3GOt5KgSFq
wVz1lMw4kIvWtC/Sy2H4oB+RtODLp6yJDqmvmPkeJwKDUcd/1JKf0KsZ8j3FpGei
/rEkBEss0KBKyFAgBSRO2jIpdj2epgcBcsdB/r5mlhcn8L77AS6mHbA173kY4pQ/
Kdg=
=TUCJ
-----END PGP SIGNATURE-----
Merge tag 'ioremap-5.6' of git://git.infradead.org/users/hch/ioremap
Pull ioremap updates from Christoph Hellwig:
"Remove the ioremap_nocache API (plus wrappers) that are always
identical to ioremap"
* tag 'ioremap-5.6' of git://git.infradead.org/users/hch/ioremap:
remove ioremap_nocache and devm_ioremap_nocache
MIPS: define ioremap_nocache to ioremap
commit 8f6244055b ("usb: typec: fusb302: Always provide fwnode for the
port") didn't convert this value from mW to uW when migrating to a new
specification format like it should have.
Fixes: 8f6244055b ("usb: typec: fusb302: Always provide fwnode for the port")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/0da564559af75ec829c6c7e3aa4024f857c91bee.1579529334.git.tommyhebb@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4c912bff46 ("usb: typec: wcove: Provide fwnode for the port")
didn't convert this value from mW to uW when migrating to a new
specification format like it should have.
Fixes: 4c912bff46 ("usb: typec: wcove: Provide fwnode for the port")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/d8be32512efd31995ad7d65b27df9d443131b07c.1579529334.git.tommyhebb@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is to prevent any possible events generated while unregister
tpcm port.
Fixes: 74e656d6b0 ("staging: typec: Type-C Port Controller Interface driver (tcpci)")
Signed-off-by: Li Jun <jun.li@nxp.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/1579502333-4145-1-git-send-email-jun.li@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Passing all the details that the alternate mode drivers
provide to the mux drivers during mode changes.
The mux drivers will in practice need to be able to make
decisions on their own. It is not enough that they get only
the requested port state. With the Thunderbolt 3 alternate
mode for example the mux driver will need to consider also
the capabilities of the cable before configuring the mux.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20191230142611.24921-13-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thunderbolt 3, and probable USB4 too, will need to be able
to get details about the cables. Adding typec_cable_get()
function that the alternate mode drivers can use to gain
access to gain access to the cable.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20191230142611.24921-4-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Originally the port drivers were expected to check does the
connector have the mode enabled or disabled when the alt
mode drivers attempted to enter the mode, but since
typec_altmode_enter() puts the connector into USB Safe
State before calling the port driver, it really has to do
the check on its own, and before changing the state.
Otherwise the connector may be left in USB Safe State if the
port driver does not move it back to normal USB operation
when the mode is disabled.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20191230142611.24921-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bryan O'Donoghue