The TMU will be reset after router exits sleep so in order to
re-configure it upon resume make sure the structure is initialized again
based on the current hardware state.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
DP tunnels do not need the same kind of treatment as others because they
are created based on hot-plug events on DP adapter ports, and the
display stack does not need the tunnels to be enabled when resuming from
suspend. Also Tiger Lake Thunderbolt controller sends unplug event on D3
exit so this avoids that as well.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
First generation routers may need the reset command upon resume but it
is not supported by newer generations.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 spec says that NFC buffers field is not used for protocol adapters,
only for lane adapters so make tb_port_add_nfc_credits() skip non-lane
adapters in order to follow the spec.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In Tiger Lake the Firmware CM is always enabled (so bit 0 is always set)
but it may be in "pass through" mode which means it requires Software CM
instead. This can be determined by checking bit 31 instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
When Software CM is running it should not send any NHI mailbox command
during PM flows. Only force power bit needs to be set and cleared so
change Tiger Lake (well and Ice Lake) nhi_ops to take this into account.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently the Ice Lake and Tiger Lake NHI (host controller) LC (link
controller) mailbox command processing checks for the completion of
command every 100 msecs. These controllers are found to complete this in
the order of 1 ms or so. Since this delay is in suspend path, surplus
delay is effectively affecting runtime PM suspend flows.
Optimize this so that we do the wait for 1 ms after reading the mailbox
register. This should make Ice Lake and Tiger Lake runtime suspend take
less time to complete.
Reported-by: Dana Alkattan <dana.alkattan@intel.com>
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently the "Force Power" logic uses 10 retries, each with a delay of
250 ms. Thunderbolt controllers in Ice Lake and Tiger Lake platforms are
found to complete this in the order of 3 ms or so. Since this delay
is in resume path, surplus delay is effectively affecting runtime PM
resume flows.
Decrease the granularity of the delay to 3 ms and increase the number of
retries so we wait maximum of ~1 s which is the recommended timeout.
This should make runtime resume a bit faster.
Reported-by: Dana Alkattan <dana.alkattan@intel.com>
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Doesn't really matter for an individual driver, but it may
get coppied to lots more. I consider it's a little tidy up.
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Some external devices can support completing thunderbolt authentication
when they are unplugged. For this to work though, the link controller must
remain operational.
The only device known to support this right now is the Dell WD19TB, so add
a quirk for this.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This allows userspace to have a shorter period of time that the device
is unusable and to call it at a more convenient time.
For example flushing the image may happen while the user is using the
machine and authenticating/rebooting may happen while logging out.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The 32 bit int value 512 is being left shifted and then used in a context
that expects the expression to be a larger unsigned long. There may be
a potential integer overflow, so make 512 a UL before shift to avoid
any such issues.
Addresses-Coverity: ("Uninintentional integer overflow")
Fixes: 3b1d8d577c ("thunderbolt: Implement USB3 bandwidth negotiation routines")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 spec specifies standard access to retimers (both on-board and
cable) through USB4 port sideband access. This makes it possible to
upgrade their firmware in the same way than we already do with the
routers.
This enumerates on-board retimers under each USB4 port when the link
comes up and adds them to the bus under the router the retimer belongs
to. Retimers are exposed in sysfs with name like <device>:<port>.<index>
where device is the router the retimer belongs to, port is the USB4 port
the retimer is connected to and index is the retimer index under that
port (starting from 1). This applies to the upstream USB4 port as well
so if there is on-board retimer between the port and the router it is
also added accordingly.
At this time we do not add cable retimers but there is no techincal
restriction to do so in the future if needed. It is not clear whether it
makes sense to upgrade their firmwares and at least Thunderbolt 3 cables
it has not been done outside of lab environments.
The sysfs interface is made to follow the router NVM upgrade to make it
easy to extend the existing userspace (fwupd) to handle these as well.
Signed-off-by: Kranthi Kuntala <kranthi.kuntala@intel.com>
Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 spec specifies standard set of sideband operations that are send
over the low speed link to access either retimers on the link or the
link parter (the other router). The USB4 retimer spec extends these and
adds operations for retimer NVM upgrade.
This implements the retimer access and NVM upgrade USB4 port sideband
operations which we need for retimer support in the patch that follows.
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Especially when accessing retimers over USB4 sideband operations the
possibility to get read errors seems to be higher so make the
usb4_do_read_data() retry a couple of times if it sees any other error
than -ENODEV (device is gone). We can only do this for read side because
it carries the offset as part of metadata (as opposed to writes).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently these functions operate on struct tb_switch but we are going
to need the same functionality with retimers as well so make the two
functions work with an arbitrary object that gets passed as parameter to
the callbacks.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We are going to reuse some of this functionality to implement retimer
NVM upgrade so move common NVM functionality into its own file. We also
rename the structure from tb_switch_nvm to tb_nvm to make it clear that
it is not just for switches.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
With USB4 Intel is also using its USB-IF ID (0x8087) with the new
devices. The NVM format is the same. Add this to the driver so NVM
upgrade is possible with these devices as well.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We can test some parts of tunneling, like path allocation without access
to test hardware so add KUnit tests for PCIe, DP and USB3 tunneling.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB3 supports both isochronous and non-isochronous traffic. The former
requires guaranteed bandwidth and can take up to 90% of the total
bandwidth. With USB4 USB3 is tunneled over USB4 fabric which means that
we need to make sure there is enough bandwidth allocated for the USB3
tunnels in addition to DisplayPort tunnels.
Whereas DisplayPort bandwidth management is static and done before the
DP tunnel is established, the USB3 bandwidth management is dynamic and
allows increasing and decreasing the allocated bandwidth according to
what is currently consumed. This is done through host router USB3
downstream adapter registers.
This adds USB3 bandwidth management to the software connection manager
so that we always try to allocate maximum bandwidth for DP tunnels and
what is left is allocated for USB3.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We need to call this from tb.c when we improve the bandwidth management
to take USB3 into account.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Each host router USB3 downstream adapter has a set of registers that are
used to negotiate bandwidth between the connection manager and the
internal xHCI controller. These registers allow dynamic bandwidth
management for USB3 isochronous traffic based on what is actually
consumed vs. allocated at any given time.
Implement these USB3 bandwidth negotiation routines to allow the
software connection manager take advantage of these.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Sometimes it takes longer for DPRX to be set so increase the timeout to
cope with this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Whereas DisplayPort bandwidth is consumed only in one direction (from DP
IN adapter to DP OUT adapter), USB3 adds separate bandwidth for both
upstream and downstream directions.
For this reason extend the tunnel consumed bandwidth routines to support
both directions and implement this for DP.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Just for symmetry with the usb4_switch_map_usb3_down() make this one
also return ports that are enabled.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We need to call this on enabled ports in order to find the mapping from
host router USB4 port to a USB 3.x downstream adapter, so make the
function return enabled ports as well.
While there fix parameter alignment in tb_find_usb3_down().
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB3 tunneling is possible only over USB4 link so don't create USB3
tunnels if that's not the case.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 spec allows DP tunneling from any router that has DP IN adapter,
not just from host router. The driver currently only added the DP IN
resources for the host router because Thunderbolt 1, 2 and 3 devices do
not have DP IN adapters. However, USB4 allows device routers to have DP
IN adapter as well so update the driver to add DP IN resources for each
device that has one. One example would be an eGPU enclosure where the
eGPU output is forwarded to DP IN port and then tunneled over the USB4
fabric.
Only limitation we add now is that the DP IN and DP OUT that gets paired
for tunnel creation should both be under the same topology starting from
host router downstream port. In other words we do not create DP tunnels
across host router at this time even though that is possible as well but
it complicates the bandwidth management and there is no real use-case
for this anyway.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This adds KUnit tests for path walking which is only dependent on
software structures, so no hardware is needed to run these.
We make these available only when both KUnit and the driver itself are
built into the kernel image. The reason for this is that KUnit adds its
own module_init() call in kunit_test_suite() which generates linker
error because the driver does the same in nhi.c. This should be fine for
now because these tests are only meant to run by developers anyway.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently we have only supported paths that follow daisy-chain topology
but USB4 also allows to build trees of devices. For this reason increase
maximum path length we use for discovery to be from the lowest level to
the host router and back to the same level.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
If the path is not complete when we do discovery the number of hops may
be less than with the full path. As an example when this can happen is
that user unloads the driver, disconnects the topology, and loads the
driver back. If there is PCIe or USB3 tunnel involved this may happen.
Take this into account in tb_pcie_init_path() and tb_usb3_init_path()
and prevent potential access over array limits.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Add sanity check that given src and dst ports are reachable through path
walk before allocating a path. If they are not then bail out early.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
With USB4, topologies are not limited to daisy-chains anymore so when
calculating how many hops are between two ports we need to walk the
whole path instead.
Add helper function tb_for_each_port_on_path() that can be used to walk
over each port on a path and make tb_path_alloc() to use it.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 makes it possible to have tree topology of devices connected in the
same way than USB3. This was actually possible in Thunderbolt 1, 2 and 3
as well but all the available devices only had two ports which allows
building only daisy-chains of devices.
With USB4 it is possible for example that there is DP IN adapter as part
of eGPU device router and that should be tunneled over the tree topology
to a DP OUT adapter. This updates the tb_next_port_on_path() to support
such topologies.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB3 discovery used wrong indices when tunnel is discovered. It
should use TB_USB3_PATH_DOWN for path that flows downstream and
TB_USB3_PATH_UP when it flows upstream. This should not affect the
functionality but better to fix it.
Fixes: e6f8185857 ("thunderbolt: Add support for USB 3.x tunnels")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org # v5.6+
The end-to-end (E2E) workaround is needed for Falcon Ridge (TBT 2)
controller when E2E is enabled for both ends of the host-to-host
connection. However, we never supported full E2E in the first place so
this code is not necessary at the moment. Further this allows us to use
all available rings for data except ring 0 which is reserved for the
control path.
The complete E2E flow control is explained in the USB4 spec so we may
add it back later if needed but at least the networking driver seems to
work fine without, and the higher level stack, like TCP will retransmit
lost packets anyway.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
NHI (The host interface adapter) is allowed to use HopIDs 1-7 as well so
relax the restriction in tb_port_alloc_hopid() to support this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
While Intel hardware typically has hop_count (Total Paths in the spec)
12 the USB4 spec allows this to be anything between 1 and 21 so no need
to warn about this. Simply log number of paths at debug level.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
On a systems where the Thunderbolt controller is present all the time
the kernel nodename may not yet set by the userspace when the driver is
loaded. This means when another host is connected it may see the default
"(none)" hostname instead of the system real hostname.
For this reason build the initial XDomain property block only upon first
connect. This should make sure the userspace has had chance to set it up.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Fix the spelling of "specification", and add a missing "the" article.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Here are the large set of USB and PHY driver updates for 5.8-rc1.
Nothing huge, just lots of little things:
- USB gadget fixes and additions all over the place
- new PHY drivers
- PHY driver fixes and updates
- XHCI driver updates
- musb driver updates
- more USB-serial driver ids added
- various USB quirks added
- thunderbolt minor updates and fixes
- typec updates and additions
Full details are in the shortlog.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXtzqVA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynftwCfeanyI6TR5AdfJVZN50B6/ySvVwcAn07i9VRX
tnt2kz0UqReYpLt0wyJ7
=YP7o
-----END PGP SIGNATURE-----
Merge tag 'usb-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB/PHY driver updates from Greg KH:
"Here are the large set of USB and PHY driver updates for 5.8-rc1.
Nothing huge, just lots of little things:
- USB gadget fixes and additions all over the place
- new PHY drivers
- PHY driver fixes and updates
- XHCI driver updates
- musb driver updates
- more USB-serial driver ids added
- various USB quirks added
- thunderbolt minor updates and fixes
- typec updates and additions
All of these have been in linux-next for a while with no reported
issues"
* tag 'usb-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (245 commits)
usb: dwc3: meson-g12a: fix USB2 PHY initialization on G12A and A1 SoCs
usb: dwc3: meson-g12a: fix error path when fetching the reset line fails
Revert "dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings"
Revert "dt-bindings: usb: qcom,dwc3: Add compatible for SC7180"
Revert "dt-bindings: usb: qcom,dwc3: Introduce interconnect properties for Qualcomm DWC3 driver"
USB: serial: ch341: fix lockup of devices with limited prescaler
USB: serial: ch341: add basis for quirk detection
CDC-ACM: heed quirk also in error handling
USB: serial: option: add Telit LE910C1-EUX compositions
usb: musb: Fix runtime PM imbalance on error
usb: musb: jz4740: Prevent lockup when CONFIG_SMP is set
usb: musb: mediatek: add reset FADDR to zero in reset interrupt handle
usb: musb: use true for 'use_dma'
usb: musb: start session in resume for host port
usb: musb: return -ESHUTDOWN in urb when three-strikes error happened
USB: serial: qcserial: add DW5816e QDL support
thunderbolt: Add trivial .shutdown
usb: dwc3: keystone: Turn on USB3 PHY before controller
dt-bindings: usb: ti,keystone-dwc3.yaml: Add USB3.0 PHY property
dt-bindings: usb: convert keystone-usb.txt to YAML
...
This adds support for Intel Tiger Lake Thunderbolt controller using
firmware based connection manager. In addition the driver can now be
built on non-x86 architectures as well. Then there are a couple of
commits that make the driver work across kexec, replace a zero length
array with flexible one, and revert one change that is not needed
anymore because of NVMem subsystem improvements.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAl7M2XogHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKBo4A/9Fcw0uH2nKRZu
iVSyrqrb9qrFU9Zb+pf8WeZWf7N3g22GfTRsQkTRtloyQdRIgipSuIhZmR4rsJ4x
RZhMJabdvswDBpqDxnZ3abn4UMuqnLIs9u2tUOhUP19e/SSh98XeNsvTcdQ28LRM
fpF+h4DDW8P7sJ/jkmw7VZ23BGhDPJwiZJaMsegHujFnFgCLYZjkzw/MLIBZTR+a
xLJfGPXeQxvNbjISDlNMy5Skbt+tvMew+yaFhqg1F9rkDJBuQmUvuib5FfiGg1V9
ggxnO5fdnv2TFow7QqGSMQbRHX01uoDMQkAAq/VznJpJiBFotCb2wNQMLY+dQmZK
QzkkYM9LpacZq27KTeo1uRiAl+TfWodmBhvtqX0ogIUqLlJWZrlDRnONt/T8ZVvU
R6Uy8cj8gmO5ol7UcUJ4QIIsME0yRwKd6TcLIvpzTXagsJ10H3lluxyLFn1V5T+F
7wc1MBUTMX3L58c2zxvH74NdhIF3q59Y35NJ4hYLVvKspKkJE0umzWNegpoF+ZNw
r3aVSLOAJTl2z7iE0Ssl3VhQ+WRuj2EVb1g0bdQr3soDdPgT0gzK2FqnzkVgHk2u
xVDBDn5aAKo0bkUKrcBg4Dz5ECl/0QvSU12Nzy9GIvQNhRTzpgAEqzweEoZ6VyRw
tnple/EiLHE0G8BGiSRfd66YDjk52xc=
=qZRi
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v5.8 merge window
This adds support for Intel Tiger Lake Thunderbolt controller using
firmware based connection manager. In addition the driver can now be
built on non-x86 architectures as well. Then there are a couple of
commits that make the driver work across kexec, replace a zero length
array with flexible one, and revert one change that is not needed
anymore because of NVMem subsystem improvements.
* tag 'thunderbolt-for-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
thunderbolt: Add trivial .shutdown
thunderbolt: Update Kconfig to allow building on other architectures.
thunderbolt: Replace zero-length array with flexible-array
thunderbolt: Add support for Intel Tiger Lake
Revert "thunderbolt: Prevent crash if non-active NVMem file is read"
On my machine, a kexec with this driver loaded in the old kernel causes
a very long delay on boot in the kexec'ed kernel, most likely due to
unclean shutdown prior to that.
Unloading thunderbolt driver prior to kexec allows kexec to work as fast
as regular kernel boot, as well as adding this .shutdown pointer.
Shutting a device prior to the shutdown completely is always a good idea
IMHO to help with kexec, and this one-liner patch implements it.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Previously we used pcie_find_root_port() to find a Root Port from a PCIe
device and pci_find_pcie_root_port() to find a Root Port from a
Conventional PCI device.
Unify the two functions and use pcie_find_root_port() to find a Root Port
from either a Conventional PCI device or a PCIe device. Then there is no
need to distinguish the type of the device.
Link: https://lore.kernel.org/r/1589019568-5216-1-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> # thunderbolt
Thunderbolt 3 and USB4 shouldn't be x86 only.
Tested on a SolidRun HoneyComb (ARM Cortex-A72) with a
Gigabyte Titan Ridge Thunderbolt 3 PCIe card (JHL7540).
Signed-off-by: David Manouchehri <david.manouchehri@riseup.net>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg