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

Currently, when setup a new USB3 tunnel that is starting from downstream USB3
adapter of first depth router (or deeper), to upstream USB3 adapter of a second
depth router (or deeper), we calculate consumed bandwidth. For this calculation
we take into account first USB3 tunnel consumed bandwidth while we shouldn't,
because we just recalculating the first USB3 tunnel allocated bandwidth.

Fix that, so that more bandwidth is available for the new USB3 tunnel being
setup.

While there, fix the kernel-doc to decribe more accurately the purpose of the
function.

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

Currently we notify PM core about occurred wakes after any resume. This
is not actually needed after resume from runtime suspend. Hence, notify
PM core about occurred wakes only after resume from system sleep. Also,
if the wake occurred in USB4 router upstream port, we don't notify the
PM core about it since it is not actually needed and can cause
unexpected autowake (e.g. if /sys/power/wakeup_count is used).

While there add the missing kernel-doc for tb_switch_resume().

Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Probably due to a firmware bug Dell TB16 dock announces that one of its
DisplayPort adapters is actually DP IN. Now this is possible and used
with some external GPUs but not likely in this case as we are dealing
with a dock. Anyways the problem is that the driver tries to create a
DisplayPort tunnel between adapters of the same router which then shows
to user that there is no picture on the display (because there are no
available DP OUT adapters on the dock anymore).

Fix this by not creating DisplayPort tunnels between adapters that are
on the same router.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10265
Fixes: 274baf695b08 ("thunderbolt: Add DP IN added last in the head of the list of DP resources")
Cc: Gil Fine <gil.fine@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

If a DiplayPort cable is directly connected to the host routers USB4
port, there is no tunnel involved but the port is in "redrive" mode
meaning that it is re-driving the DisplayPort signals from its
DisplayPort source. In this case we need to keep the domain powered on
otherwise once the domain enters D3cold the connected monitor blanks
too.

Since this happens only on Intel Barlow Ridge add a quirk that takes
runtime PM reference if we detect that the USB4 port entered redrive
mode (and release it once it exits the mode).

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

After DisplayPort tunnel setup, we add verification that the DPRX
capabilities read process completed. Otherwise, we bail out, teardown
the tunnel, and try setup another DisplayPort tunnel using next
available DP IN adapter. We do so till all DP IN adapters tried. This
way, we avoid allocating DP IN adapter and (bandwidth for it) for
unusable tunnel.

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

The USB4 spec says that the Connection Manager should reserve the
bandwidth that is released in the same group for 10 seconds before it
can be shared with other groups. Add support for this. We also delay the
symmetric transition by that same 10 seconds to avoid any unnecessary
transitions (i.e if the released bandwidth is used by another
DisplayPort tunnel in the same group the link can stay asymmetric the
whole time).

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>

This is needed by the following patches so that we do not have to add
forward declaratations for any of these. Separating the move and the
actual changes also makes it easier to review the code.

No functional changes.

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

The USB4 spec says that if the Connection Manager writes Allocated_BW
that is smaller than Requested_BW, the DisplayPort IN adapter signals
this failure back to the DPTX (graphics driver). Implement this by
rewriting the same allocated bandwidth values back.

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