commit e2006140ad2e01a02ed0aff49cc2ae3ceeb11f8d upstream.

I noticed that when we do discrete host router NVM upgrade and it gets
hot-removed from the PCIe side as a result of NVM firmware authentication,
if there is another host connected with enabled paths we hang in tearing
them down. This is due to fact that the Thunderbolt networking driver
also tries to cleanup the paths and ends up blocking in
tb_disconnect_xdomain_paths() waiting for the domain lock.

However, at this point we already cleaned the paths in tb_stop() so
there is really no need for tb_disconnect_xdomain_paths() to do that
anymore. Furthermore it already checks if the XDomain is unplugged and
bails out early so take advantage of that and mark the XDomain as
unplugged when we remove the parent router.

Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The margin debugfs node controls the "Enable Margin Test" field of the
lane margining operations. This field selects between either low or high
voltage margin values for voltage margin test or left or right timing
margin values for timing margin test.

According to the USB4 specification, whether or not the "Enable Margin
Test" control applies, depends on the values of the "Independent
High/Low Voltage Margin" or "Independent Left/Right Timing Margin"
capability fields for voltage and timing margin tests respectively. The
pre-existing condition enabled the debugfs node also in the case where
both low/high or left/right margins are returned, which is incorrect.
This change only enables the debugfs node in question, if the specific
required capability values are met.

Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Fixes: d0f1e0c2a699 ("thunderbolt: Add support for receiver lane margining")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Mika writes:

thunderbolt: Changes for v6.10 merge window

This includes following USB4/Thunderbolt changes for the v6.10 merge
window:

  - Enable NVM firmare upgrade on Intel Maple Ridge Thunderbolt 4
    controller
  - Improve USB3 tunnel bandwidth calculation
  - Improve sideband access
  - Minor cleanups and fixes.

All these have been in linux-next with no reported issues.

* tag 'thunderbolt-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
  thunderbolt: Correct trace output of firmware connection manager packets
  thunderbolt: Fix kernel-doc for tb_tunnel_alloc_dp()
  thunderbolt: Fix uninitialized variable in tb_tunnel_alloc_usb3()
  thunderbolt: There are only 5 basic router registers in pre-USB4 routers
  thunderbolt: No need to loop over all retimers if access fails
  thunderbolt: Increase sideband access polling delay
  thunderbolt: Get rid of TB_CFG_PKG_PREPARE_TO_SLEEP
  thunderbolt: Use correct error code with ERROR_NOT_SUPPORTED
  thunderbolt: Allow USB3 bandwidth to be lower than maximum supported
  thunderbolt: Fix calculation of consumed USB3 bandwidth on a path
  thunderbolt: Enable NVM upgrade support on Intel Maple Ridge

These are special packets that the drivers sends directly to the
firmware connection manager (ICM). These do not have route string
because they are always consumed by the firmware connection manager
running on the host router, so hard-code that in the output accordingly.

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: 25d905d2b819 ("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>

Intel pre-USB4 routers only have ROUTER_CS_0 up to ROUTER_CS_4 and it
immediately follows the TMU router registers. Correct this accordingly.

Reported-by: Rajaram Regupathy <rajaram.regupathy@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

When we read the NVM authentication status or unsetting the inbound SBTX
there is no point to continue the loop after first access to a retimer
fails because there won't be any more retimers after this anyway so bail
out from the loops early.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

The USB4 sideband access is slow compared to the high-speed link and the
access timing parameters are tens of milliseconds according the spec. To
avoid too much unnecessary polling for the sideband pass the wait delay
to usb4_port_wait_for_bit() and use larger (5ms) value compared to the
high-speed access.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

This is not used anywhere in the driver so remove it. No functional
changes.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>