USB4 routers must expose their preferred credit (buffer) allocation
information through router operation. This information tells the
connection manager how the router prefers its buffers to be allocated to
get the expected bandwidth for the supported protocols.
Read this information and store it as part of struct tb_switch for each
USB4 router.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB4 Configuration Manager guide suggests that the USB4 port wakes
are configured in a certain way, like that when the port is configured
the wake-on-connect should not be set and so forth, so align the driver
with this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Latest USB4 spec added a new wake bit for DisplayPort so add this to the
driver when runtime suspending. This way wake up the domain when a new
monitor is plugged in to any of the device routers.
Also do the same for pre-USB4 devices through the link controller
registers as documented in chapter 13 of the USB4 spec.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We do this for Thunderbolt 2/3 devices through DMA port, USB4 devices
and retimers pretty much the same way. Only the actual block read/write
is different. For this reason split out the NVM read/write functions
from usb4.c to nvm.c and make USB4 device code call these when needed.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Up to 64 bytes of data can be read from NVM in one go.
Read address must be dword aligned. Data is read into a local buffer.
If caller asks to read data starting at an unaligned address then full
dword is anyway read from NVM into a local buffer. Data is then copied
from the local buffer starting at the unaligned offset to the caller
buffer.
In cases where asked data length + unaligned offset is over 64 bytes
we need to make sure we don't read past the 64 bytes in the local
buffer when copying to caller buffer, and make sure that we don't
skip copying unaligned offset bytes from local buffer anymore after
the first round of 64 byte NVM data read.
Fixes: b04079837b ("thunderbolt: Add initial support for USB4")
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
ACPI 6.4 introduced a new _OSC capability used to negotiate whether the
OS is supposed to use Software (native) or Firmware based Connection
Manager. If the native support is granted then there are set of bits
that enable/disable different tunnel types that the Software Connection
Manager is allowed to tunnel.
This adds support for this new USB4 _OSC accordingly. When PCIe
tunneling is disabled then the driver switches security level to be
"nopcie" following the security level 5 used in Firmware based
Connection Manager.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
This includes following Thunderbolt/USB4 changes for v5.11 merge window:
* DMA traffic test driver
* USB4 router NVM upgrade improvements
* USB4 router operations proxy implementation available in the recent
Intel Connection Manager firmwares
* Support for Intel Maple Ridge discrete Thunderbolt 4 controller
* A couple of cleanups and minor improvements.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAl/PagggHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKD5DQ/+NFsABFQaf1P+
sU4HVOo9cwfvQCFCapfOsOjBsrkuLsjZPQdUqVdTzhrDzRM6uVQXHqWkcInNYxEs
D0o9f8yheYSPuZolHIIydkNZ7VjhXwhVp7FuF+6M3bIhtD9siuBUisCu7QtOjzpF
EAzBZcGHvKXkPmVAQKZS/P4WsgcZDv0/pODjeQawosgJAPOo5begZVBEYcpbOeCT
qvl1vEs+Fr5fcoFcY/58sJX932CcbbO5bZMSc01IIF94FQMsQJg3ATLdxkgc++2M
FnzcHEVQi7h8zwCmMT4deGwLJqvbyVy5SNo6GY4/Adhsf0HQzrvtWdESegoIooJK
dNWhSCuAFbXrFKGH4iBEUldigNXiCGiTwalmJ1+IIDccJQwkKC4GGU+9KEWBtYCn
OIvKkHUWPeeqNBzSeiMbFDXiK6QFe2VpNBg/iRUZwZwxibqgjgJE1rHbY098sPrL
yHRcrz6vih3wgpqZJTGdanIMk6F0MzaoHtj2egXbXaqyGf8dIdvnZJZN9gb5WDyu
ZT/ffh3XiNfBvFtsu9gosnn3m76TQ4jIb4lUesTOVZjHX2yNz3MabYet312lP4PO
qhxb1l2HGWuxnLLSxas6gzEv5arpx88ldSj6PaA86pBL/eezy59Bvn5hYrmCQ269
lVZQ19nC8y13VyCgbqcyTSpGxS+NXV0=
=+RXF
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v5.11 merge window
This includes following Thunderbolt/USB4 changes for v5.11 merge window:
* DMA traffic test driver
* USB4 router NVM upgrade improvements
* USB4 router operations proxy implementation available in the recent
Intel Connection Manager firmwares
* Support for Intel Maple Ridge discrete Thunderbolt 4 controller
* A couple of cleanups and minor improvements.
* tag 'thunderbolt-for-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: (22 commits)
thunderbolt: Add support for Intel Maple Ridge
thunderbolt: Add USB4 router operation proxy for firmware connection manager
thunderbolt: Move constants for USB4 router operations to tb_regs.h
thunderbolt: Add connection manager specific hooks for USB4 router operations
thunderbolt: Pass TX and RX data directly to usb4_switch_op()
thunderbolt: Pass metadata directly to usb4_switch_op()
thunderbolt: Perform USB4 router NVM upgrade in two phases
thunderbolt: Return -ENOTCONN when ERR_CONN is received
thunderbolt: Keep the parent runtime resumed for a while on device disconnect
thunderbolt: Log adapter numbers in decimal in path activation/deactivation
thunderbolt: Log which connection manager implementation is used
thunderbolt: Move max_boot_acl field to correct place in struct icm
MAINTAINERS: Add Isaac as maintainer of Thunderbolt DMA traffic test driver
thunderbolt: Add DMA traffic test driver
thunderbolt: Add support for end-to-end flow control
thunderbolt: Make it possible to allocate one directional DMA tunnel
thunderbolt: Create debugfs directory automatically for services
thunderbolt: Add functions for enabling and disabling lane bonding on XDomain
thunderbolt: Add link_speed and link_width to XDomain
thunderbolt: Create XDomain devices for loops back to the host
...
We are going to use these in subsequent patch so make them available
outside of usb4.c.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Intel USB4 host routers that run the firmware based connection manager
(ICM) may implement a proxy for USB4 router operations. This is to avoid
the firmware to race with the OS driver, as both may need to run these
operations.
This adds two new connection manager specific callbacks which, if
provided, get called instead of the native USB4 router operation.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We are going to make usb4_switch_op() to match better the corresponding
firmware (ICM) USB4 router operation proxy interface, so that we can use
either based on the connection manager implementation.
For this reason rename usb4_switch_op() to __usb4_switch_op() that
provides the most complete interface. Then make usb4_switch_op() and
usb4_switch_op_data() call it with correct set of parameters and update
the callers accordingly.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We are going to make usb4_switch_op() to match better the corresponding
firmware (ICM) USB4 router operation proxy interface, so that we can use
either based on the connection manager implementation. For this reason
pass metadata directly to usb4_switch_op().
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The currect code expects that the router returns back the status of the
NVM authentication immediately. When tested against a real USB4 device
what happens is that the router is reset and only after that the result
is updated in the ROUTER_CS_26 register status field. This also seems to
align better what the spec suggests.
For this reason do the same what we already do with the Thunderbolt 3
devices and perform the NVM upgrade in two phases. First start the
NVM_AUTH router operation and once the router is added back after the
reset read the status in ROUTER_CS_26 and expose it to the userspace
accordingly.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Only USB4 lane 0 adapter has the USB4 port capability for wakes so only
program wakes on such adapters.
Fixes: b2911a593a ("thunderbolt: Enable wakes from system suspend")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In order for the router and the whole domain to wake up from system
suspend states we need to enable wakes for the connected routers. For
device routers we enable wakes from PCIe and USB 3.x. This allows
devices such as keyboards connected to USB 3.x hub that is tunneled to
wake the system up as expected. For all routers we enabled wake on USB4
for each connected ports. This is used to propagate the wake from router
to another.
Do the same for legacy routers through link controller vendor specific
registers as documented in USB4 spec chapter 13.
While there correct kernel-doc of usb4_switch_set_sleep() -- it does not
enable wakes instead there is a separate function (usb4_switch_set_wake())
that does.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
When the port is connected to another host it should be marked as such
in the USB4 port capability. This information is used by the router
during sleep and wakeup.
Also do the same for legacy switches via link controller vendor specific
registers.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Both ends of the link needs to have this set. Otherwise the link is not
re-established properly after sleep. Now since it is possible to have
mixed USB4 and Thunderbolt 1, 2 and 3 devices we need to split the link
configuration functionality to happen per port so we can pick the
correct implementation.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
During testing it was noticed that the link is not properly restored
after the domain exits sleep if the link configured bits are set before
lane bonding is enabled. The USB4 spec does not say in which order these
need to be set but setting link configured afterwards makes the link
restoration work so we do that instead.
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 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>
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>
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>
The function misses checking return value of tb_sw_read() before it
accesses the value that was read. Fix this by checking the return value
first.
Fixes: b04079837b ("thunderbolt: Add initial support for USB4")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Yehezkel Bernat <yehezkelshb@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The code tried to check whether xhci variable has ROUTER_CS_6_HCI bit
set but since xhci type is bool and it already holds true or false based
on that very bit, fix the check to use the variable directly.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: b04079837b ("thunderbolt: Add initial support for USB4")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20200108125317.36444-2-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB4 added a capability to tunnel USB 3.x protocol over the USB4
fabric. USB4 device routers may include integrated SuperSpeed HUB or a
function or both. USB tunneling follows PCIe so that the tunnel is
created between the parent and the child router from USB3 downstream
adapter port to USB3 upstream adapter port over a single USB4 link.
This adds support for USB 3.x tunneling and also capability to discover
existing USB 3.x tunnels (for example created by connection manager in
boot firmware).
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>
Link: https://lore.kernel.org/r/20191217123345.31850-9-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB4 is the public specification based on Thunderbolt 3 protocol. There
are some differences in register layouts and flows. In addition to PCIe
and DP tunneling, USB4 supports tunneling of USB 3.x. USB4 is also
backward compatible with Thunderbolt 3 (and older generations but the
spec only talks about 3rd generation). USB4 compliant devices can be
identified by checking USB4 version field in router configuration space.
This patch adds initial support for USB4 compliant hosts and devices
which enables following features provided by the existing functionality
in the driver:
- PCIe tunneling
- Display Port tunneling
- Host and device NVM firmware upgrade
- P2P networking
This brings the USB4 support to the same level that we already have for
Thunderbolt 1, 2 and 3 devices.
Note the spec talks about host and device "routers" but in the driver we
still use term "switch" in most places. Both can be used interchangeably.
Co-developed-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20191217123345.31850-5-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
