This adds notification whenever software connection manager activates,
changes or deactivates a tunnel, and also if there is limitation in
bandwidth.
The notification looks like below:
TUNNEL_EVENT=activated|changed|deactivated|low bandwidth|
insufficient bandwidth
TUNNEL_DETAILS=0:12 <-> 1:20 (USB3)
Userspace can then listen these and inform user if needed. For example
if there is not enough bandwidth, it can show warning dialog to the user.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Here is the big set of USB and Thunderbolt driver updates for 6.15-rc1.
Included in here are:
- Thunderbolt driver and core api updates for new hardware and
features
- usb-storage const array cleanups
- typec driver updates
- dwc3 driver updates
- xhci driver updates and bugfixes
- small USB documentation updates
- usb cdns3 driver updates
- usb gadget driver updates
- other small driver updates and fixes
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-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZ+2Zaw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynIgQCaAyMozdrZtTiOs1OcZEuTkoCtKrEAniqe0OiL
s7R6j2NoOIwo9d6hBsjh
=IH7I
-----END PGP SIGNATURE-----
Merge tag 'usb-6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt updates from Greg KH:
"Here is the big set of USB and Thunderbolt driver updates for
6.15-rc1. Included in here are:
- Thunderbolt driver and core api updates for new hardware and
features
- usb-storage const array cleanups
- typec driver updates
- dwc3 driver updates
- xhci driver updates and bugfixes
- small USB documentation updates
- usb cdns3 driver updates
- usb gadget driver updates
- other small driver updates and fixes
All of these have been in linux-next for a while with no reported
issues"
* tag 'usb-6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (92 commits)
thunderbolt: Do not add non-active NVM if NVM upgrade is disabled for retimer
thunderbolt: Scan retimers after device router has been enumerated
usb: host: cdns3: forward lost power information to xhci
usb: host: xhci-plat: allow upper layers to signal power loss
usb: xhci: change xhci_resume() parameters to explicit the desired info
usb: cdns3-ti: run HW init at resume() if HW was reset
usb: cdns3-ti: move reg writes to separate function
usb: cdns3: call cdns_power_is_lost() only once in cdns_resume()
usb: cdns3: rename hibernated argument of role->resume() to lost_power
usb: xhci: tegra: rename `runtime` boolean to `is_auto_runtime`
usb: host: xhci-plat: mvebu: use ->quirks instead of ->init_quirk() func
usb: dwc3: Don't use %pK through printk
usb: core: Don't use %pK through printk
usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()
dt-bindings: usb: qcom,dwc3: Synchronize minItems for interrupts and -names
usb: common: usb-conn-gpio: switch psy_cfg from of_node to fwnode
usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running
usb: xhci: Don't change the status of stalled TDs on failed Stop EP
xhci: Avoid queuing redundant Stop Endpoint command for stalled endpoint
xhci: Handle spurious events on Etron host isoc enpoints
...
Kenneth noticed that his laptop crashes randomly when resuming from
hibernate if there is device connected and display tunneled. I was able
to reproduce this as well with the following steps:
1. Boot the system up, nothing connected.
2. Connect Thunderbolt 4 dock to the host.
3. Connect monitor to the Thunderbolt 4 dock.
4. Verify that there is picture on the screen.
5. Enter hibernate.
6. Exit hibernate.
7. Wait for the system to resume.
Expectation: System resumes just fine, the connected monitor still
shows screen.
Actual result: There is crash during resume, screen is blank.
What happens is that during resume from hibernate we tear down any
existing tunnels created by the boot kernel and this ends up calling
tb_dp_dprx_stop() which calls tb_tunnel_put() dropping the reference
count to zero even though we never called tb_dp_dprx_start() for it (we
never do that for discovery). This makes the discovered DP tunnel memory
to be released and any access after that causes use-after-free and
possible crash.
Fix this so that we only stop DPRX flow if it has been started in the
first place.
Reported-by: Kenneth Crudup <kenny@panix.com>
Closes: https://lore.kernel.org/linux-usb/8e175721-806f-45d6-892a-bd3356af80c9@panix.com/
Cc: stable@vger.kernel.org
Fixes: d6d458d42e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously")
Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Make the tb_tunnel_alloc_usb3() error codepaths consistent with the
DisplayPort and PCIe counterparts.
No functional changes.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Sometimes setting up a DisplayPort tunnel may take quite long time. The
reason is that the graphics driver (DPRX) is expected to issue read of
certain monitor capabilities over the AUX channel and the "suggested"
timeout from VESA is 5 seconds. If there is no graphics driver loaded
this does not happen and currently we timeout and tear the tunnel down.
The reason for this is that at least Intel discrete USB4 controllers do
not send plug/unplug events about whether the DisplayPort cable from the
GPU to the controller is connected or not, so in order to "release" the
DisplayPort OUT adapter (the one that has monitor connected) we must
tear the tunnel down after this timeout has been elapsed.
In typical cases there is always graphics driver loaded, and also all
the cables are connected but for instance in Intel graphics CI they only
load the graphics driver after the system is fully booted up. This
makes the driver to tear down the DisplayPort tunnel. To help this case
we allow passing bigger or indefinite timeout through a new module
parameter (dprx_timeout). To keep the driver bit more responsive during
that time we change the way DisplayPort tunnels get activated. We first
do the normal tunnel setup and then run the polling of DPRX capabilities
read completion in a separate worker. This also makes the driver to
accept bandwidth requests to already established DisplayPort tunnels
more responsive.
If the tunnel still fails to establish we will tear it down and remove
the DisplayPort IN adapter from the dp_resource list to avoid using it
again (unless we get hotplug to that adapter).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Rework to avoid the goto as it only makes it confusing. Move logging to
happen at the end so we can see all the tunnels this is being called.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
It is pretty much the same as tb_tunnel_activate() excepts does check
for already activated paths. This is not needed anymore and makes it
more streamlined so drop tb_tunnel_restart() in favour of
tb_tunnel_activate().
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The way these are called is not exactly symmetric as it is supposed to
be: the former is called when tunnel is being activated and the latter
is called when it is being released (not when it is being de-activated).
Furthermore host-to-host (DMA) tunnels are abusing the ->deinit hook to
clear out the credits. This makes it quite hard to follow what is being
called and when.
For these reasons rework the two "init" hooks to be called symmetrically
and rename them accordingly. For the DMA one, add a new hook that is
specifically used to run clean up for the tunnel when its memory is
being released.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Some graphics drivers such as i915 support runtime power management and
if there is nothing connected at the moment they will runtime suspend to
save power. At least i915 is polling for new connections every 10
seconds if the hardware does support sending PME. To allow i915 and
other graphics from detect the just established DisplayPort tunnel allow
the DPRX capabilities read to take up to 12 seconds.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In case of no bandwidth available for DP tunnel, the function get the arguments
@max_up and @max_down set to zero. Fix the kernel-doc to describe more
accurately the purpose of the function.
No functional changes.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently in case of no bandwidth available for USB3 tunnel, we are left
with uninitialized variable that can lead to huge negative allocated
bandwidth.
Fix this by initializing the variable to zero. While there, fix the
kernel-doc to describe more accurately the purpose of the function
tb_tunnel_alloc_usb3().
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-usb/6289898b-cd63-4fb8-906a-1b6977321af9@moroto.mountain/
Fixes: 25d905d2b8 ("thunderbolt: Allow USB3 bandwidth to be lower than maximum supported")
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently USB3 tunnel setup fails if USB4 link available bandwidth is too low
to allow USB3 Maximum Supported Link Rate. In reality, this limitation is not
needed, and may cause failure of USB3 tunnel establishment, if USB4 link
available bandwidth is lower than USB3 Maximum Supported Link Rate. E.g. if we
connect to USB4 v1 host router, a USB4 v1 device router, via 10 Gb/s cable.
Hence, here we discard this limitation, and now we only limit USB3 bandwidth
allocation to be not higher than 90% of USB3 Max Supported Link Rate (for first
USB3 tunnel only).
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
According to USB4 Connection Manager guide, after DisplayPort tunnel was
setup, the DPRX capabilities read is performed by the DPTX. According to
VESA spec, this shall be completed within 5 seconds after the DisplayPort
tunnel was setup. Hence, if the bit: DPRX Capabilities Read Done, was
not set to '1' by this time, we timeout and fail calculating DisplayPort
tunnel consumed bandwidth.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This helper takes tunnel as parameter. Convert existing code to call
this where possible.
No functional changes.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The DisplayPort IN adapter DP_LOCAL_CAP holds the aggregated
capabilities and gets updated after graphics side does the DPRX
capabilities read so we should use this to figure out the maximum
possible bandwidth for the DisplayPort tunnel.
While there make the variable name to match better what it is used for
and add kernel-doc comment to the function.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In case of PCIe tunnel teardown (including if caused by router unplug),
PCIe extended encapsulation bit should be cleared in downstream and
upstream routers accordingly.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB4 Connection Manager guide suggests that the PCIe paths are
enabled from the upstream adapter to the downstream adapter and vice
versa on disable so make the driver follows this sequence.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
There is no point doing this separately as the register layout is the
same. For this reason rename tb_dp_read_dprx() to tb_dp_wait_dprx() and
call tb_dp_read_cap() instead.
While there add debug log if the DPRX capability read times out.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The pointer 'out' is initialized and then a few statements later being
re-assigned the same value. The second re-assignment is redundant and
can be removed.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Introduce tb_port_path_direction_downstream() to check if path from
source adapter to destination adapter is directed towards downstream.
Convert existing users to call this helper instead of open-coding.
No functional changes.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 v2 spec allows USB4 links that are part of a pass through tunnel
(such as DisplayPort and USB 3.x Gen T) to enter lower CL states, which
provide better power management. For this USB4 v2 routers in their path
config space of lane 0 adapter include a new bit PMPS (PM packet
support) that needs to be set.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 v2 Connection Manager guide (section 6.1.2.3) suggests to reserve
bandwidth in a sligthly different manner. It suggests to keep minimum of
1500 Mb/s for each path that carry a bulk traffic. Here we change the
bandwidth reservations to comply to the above for USB 3.x and PCIe
protocols over Gen 4 link, taking weights into account (that's 1500 Mb/s
for PCIe and 3000 Mb/s for USB 3.x).
For Gen 3 and below we use the existing reservation.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Instead of magic numbers use the constants we introduced in the previous
commit to make the code more readable. No functional changes.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In order to allow more consistent logging of tunnel related information
make these logging macros available to the rest of the driver.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This makes it easier to find out the tunnel in question. Also drop a
couple of lines that generate duplicate information.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
It turns out there is no need to use the actual link rate when
reclaiming bandwidth for USB 3.x. The reason is that we use consumed
bandwidth which is coming from xHCI when releasing bandwidth (for
example for DisplayPort tunneling) and this can be anything between
1000 Mb/s to maximum, so when reclaiming we can just bump it up back to
maximum instead of actual link rate (which is always <= maximum).
This allows us to get rid of couple of unnecessary lines of code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This adds support for the UHBR (Ultra High Bit Rate) bandwidths
introduced with DisplayPort 2.0 (and refined in 2.1). These can go up to
80 Gbit/s and their support is represent in additional bits in the DP IN
capability.
This updates the DisplayPort tunneling to support these new rates too.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Make sure the DisplayPort bandwidth allocation mode function names are
consistent with the existing ones, such as USB3.
No functional changes.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 v2 spec introduces modified encapsulation of PCIe TLP and DLLP
packets. This improves the PCIe tunneled traffic usage by reducing
overhead. Enable this if both sides of the link support it.
Signed-off-by: Gil Fine <gil.fine@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
It turns out that when plugging in VGA cable through USB-C to VGA/DVI
dongle the Connection Manager handshake can take longer time, at least
on Intel Titan Ridge based docks such as Dell WD91TB. This leads to
following error in the dmesg:
thunderbolt 0000:00:0d.3: 3:10: DP tunnel activation failed, aborting
and the display stays blank (because we failed to establish the tunnel).
For this reason increase the timeout to 3s.
Reported-by: Koba Ko <koba.ko@canonical.com>
Cc: stable@vger.kernel.org
Acked-By: Yehezkel Bernat <YehezkelShB@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The default ones should be find but this allows the user to tweak the
credits to get more performance out of the P2P connection.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Ring 0 cannot be used for anything else than control channel messages.
For this reason add a check to tb_tunnel_alloc_dma() and fail if someone
tries to do that.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This includes following Thunderbolt/USB4 changes for the v6.3 merge
window:
- Add support for DisplayPort bandwidth allocation mode
- Debug logging improvements
- Minor cleanups.
All these have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmPjS/4gHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKD7xhAAiye8RAaV2KkV
u5ZxF14fY4mIholmBeq5da7wgERcsQlsbKJRBlNHwJAEWzJRYU1ujPERLYOob0zV
rx/yopbg8x7VtiHHnnQ7FooZOL2oCOTsSMgQldmcHG7U3oVc/vNVB/YDlGresE5F
TvllRtvCOQWanUfv021G7nVPHdubospkjaS6inK3l/wp6RCpO7Kdyg0JOkeYiRLb
MkuO9Eb7E/Ppg8Zq1d8eOtTddKqb9v7AmsejyuBWZcJfuTHBIOM017T06URYtUJz
VN5zS3mM3LVSVxtHotlPHsuQtGBXzSZxKZx46BsrEZ3EWquDeE0F7s8L9FhRkB5y
K2H7B8k/TKVUGiHSBmYa0u0hX1dRY5EOvgIngIXy+LWAEGjdpAmKgyokgDaP4W0c
Ms/bm4FhakNX8/UkgBcy/1TWW4yk7dlvdZzBI8xTdzgcFuOxiOf2OnAy1nnkCQG2
g8p0c8JasIXPgYtZ+mWMKfdKeUB+GzKD/h18M3rLxcEP+i+pVUXr27EeYzR6yLZ5
7oVxbJK0pZbPitaYBIKZV39MW47i6JWyl4ubkccp2R1rLqaCCqaESlcc2Qb67Z3i
aBsUdviH70jIoi27CBhOnMb0vELlr/ZUNe4znMjW/kPoZOquR4EilBmrV254LOOK
VJcEaXVnV59e7hPzbdT+FXH96UBRf/Y=
=Kegw
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v6.3 merge window
This includes following Thunderbolt/USB4 changes for the v6.3 merge
window:
- Add support for DisplayPort bandwidth allocation mode
- Debug logging improvements
- Minor cleanups.
All these have been in linux-next with no reported issues.
* tag 'thunderbolt-for-v6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
thunderbolt: Add missing kernel-doc comment to tb_tunnel_maximum_bandwidth()
thunderbolt: Handle bandwidth allocation mode enablement notification
thunderbolt: Add support for DisplayPort bandwidth allocation mode
thunderbolt: Include the additional DP IN double word in debugfs dump
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode
thunderbolt: Increase timeout of DP OUT adapter handshake
thunderbolt: Take CL states into account when waiting for link to come up
thunderbolt: Improve debug logging in tb_available_bandwidth()
thunderbolt: Log DP adapter type
thunderbolt: Use decimal port number in control and tunnel logs too
thunderbolt: Refactor tb_acpi_add_link()
thunderbolt: Use correct type in tb_port_is_clx_enabled() prototype
The USB4 spec defines an optional feature that allows the connection
manager to negotiate with the graphics through DPCD registers changes in
the bandwidth allocation dynamically. This is referred as "bandwidth
allocation mode" in the spec. The connection manager uses DP IN adapters
registers to communicate with the graphics, and also gets notifications
from these adapters when the graphics wants to change the bandwidth
allocation. Both the connection manager and the graphics driver needs to
support this.
We check if the DP IN adapter supports this and if it does enable it
before establishing a DP tunnel. Then we react on DP_BW notifications
coming from the DP IN adapter and update the bandwidth allocation
accordingly (within the maximum common capabilities the DP IN/OUT
support).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Sometimes the current timeout is not enough so increase it to 1500 ms
and while there make the loop use ktime instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Use decimal number instead of hex in port numbers as we have been doing
with other logging functions too. This makes the output more consistent.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We need to take minimum of both sides of the USB3 link into consideration,
not just the downstream port. Fix this by calling tb_usb3_max_link_rate()
instead.
Fixes: 0bd680cd90 ("thunderbolt: Add USB3 bandwidth management")
Cc: stable@vger.kernel.org
Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
For the case of a device without DisplayPort adapters we calculate
incorrectly the amount of buffers. Fix the calculation for this case.
Signed-off-by: Gil Fine <gil.fine@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Brad reported that on Apple hardware with Light Ridge or Falcon Ridge
controller, plugging in a chain of Thunderbolt displays (Light Ridge
based controllers) causes all kinds of tearing and flickering. The
reason for this is that on Thunderbolt 1 hardware there is no lane
bonding so we have two independent 10 Gb/s lanes, and currently Linux
tunnels both displays through the lane 1. This makes the displays to
share the 10 Gb/s bandwidth which may not be enough for higher
resolutions.
For this reason make the second tunnel go through the lane 0 instead.
This seems to match what the macOS connection manager is also doing.
Reported-by: Brad Campbell <lists2009@fnarfbargle.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Brad Campbell <lists2009@fnarfbargle.com>
Intel Titan Ridge does not disable AUX timers when it gets SET_CONFIG
with SET_LTTPR_MODE set which makes DP tunneling to fail. For this
reason disable LTTPR on Titan Ridge device side.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
If the boot firmware implements connection manager of its own it may not
create the paths in the same way or order we do. For example it may
create first PCIe tunnel and then USB3 tunnel. When we restore our
tunnels (first de-activating them) we may be doing that over completely
different tunnels and that leaves them possibly non-functional. For this
reason we re-use the tunnel discovery functionality and find out all the
existing tunnels, and tear them down. Once that is done we can restore
our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB4 Connection Manager guide provides detailed information how the
USB4 router buffer (credit) allocation information should be used by the
connection manager when it allocates buffers for different paths. This
patch implements it for Linux. For USB 3.x and DisplayPort we use
directly the router preferences. The rest of the buffer space is then
used for PCIe and DMA (peer-to-peer, XDomain) traffic. DMA tunnels
require at least one buffer and PCIe six, so if there is not enough
buffers we fail the tunnel creation.
For the legacy Thunderbolt 1-3 devices we use the existing hard-coded
scheme except for DMA where we use the values suggested by the USB4 spec
chapter 13.
Co-developed-by: Gil Fine <gil.fine@intel.com>
Signed-off-by: Gil Fine <gil.fine@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
With the USB4 buffer allocation the number of credits (and non-flow
credits) may be different depending on the router buffer allocation
preferences. To allow this move the nfc_credits field to struct
tb_path_hop.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently we have had an artificial limitation of a single DMA tunnel
per XDomain connection. However, hardware wise there is no such limit
and software based connection manager can take advantage of all the DMA
rings available on the host to establish tunnels.
For this reason make the tb_xdomain_[enable|disable]_paths() to take the
DMA ring and HopID as parameter instead of storing them in the struct
tb_xdomain. We also add API functions to allocate input and output
HopIDs of the XDomain connection that the service drivers can use
instead of hard-coding.
Also convert the two existing service drivers over to this API.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB4 inter-domain service spec recommends using dedicated flow
control scheme so update the driver accordingly.
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>
