[PATCH v2 1/3] thunderbolt: Do not set up a DisplayPort tunnel when credits are insufficient

[PATCH v2 1/3] thunderbolt: Do not set up a DisplayPort tunnel when credits are insufficient

[Gil Fine]

Currently, an excessive DisplayPort tunnel may be set up, even if no
sufficient credits available. This could lead to malfunctioning
DisplayPort tunnel.

Fix this and bail out early if this is the case.

Fixes: 6ed541c53edc ("thunderbolt: Allocate credits according to router preferences")
Cc: stable@vger.kernel.org
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Assisted-by: LLM
---
 drivers/thunderbolt/tunnel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/tunnel.c b/drivers/thunderbolt/tunnel.c
index c0342b1d6a8a..7a033df7f916 100644
--- a/drivers/thunderbolt/tunnel.c
+++ b/drivers/thunderbolt/tunnel.c
@@ -1582,7 +1582,7 @@ static int tb_dp_init_video_credits(struct tb_path_hop *hop)
 		 */
 		nfc_credits = port->config.nfc_credits &
 				ADP_CS_4_NFC_BUFFERS_MASK;
-		if (nfc_credits / sw->min_dp_main_credits > max_dp_streams)
+		if (nfc_credits / sw->min_dp_main_credits >= max_dp_streams)
 			return -ENOSPC;
 
 		hop->nfc_credits = sw->min_dp_main_credits;
-- 
2.43.0

[PATCH v2 2/3] thunderbolt: Fix DMA credit limit to use host router value

[Gil Fine]

Currently, when allocating credits for a DMA tunnel, we reserve credits
based on the baMaxHI parameter taken from the router that owns the
ingress adapter of the current hop.
In a host-to-host topology with a hub in the middle:

  [Host1] <-> [Hub] <-> [Host2]

this incorrectly uses the hub's value instead of the host router's.
The DMA engine limit is defined by the host router baMaxHI.

Fix this by alway use the baMaxHI of the host router instead.

Fixes: 6ed541c53edc ("thunderbolt: Allocate credits according to router preferences")
Cc: stable@vger.kernel.org
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Assisted-by: LLM
---
 drivers/thunderbolt/tunnel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/tunnel.c b/drivers/thunderbolt/tunnel.c
index 7a033df7f916..0625b1ff3820 100644
--- a/drivers/thunderbolt/tunnel.c
+++ b/drivers/thunderbolt/tunnel.c
@@ -175,7 +175,8 @@ static unsigned int tb_available_credits(const struct tb_port *port,
 	pcie = tb_acpi_may_tunnel_pcie() ? sw->max_pcie_credits : 0;
 
 	if (tb_acpi_is_xdomain_allowed()) {
-		spare = min_not_zero(sw->max_dma_credits, dma_credits);
+		spare = min_not_zero(sw->tb->root_switch->max_dma_credits,
+				     dma_credits);
 		/* Add some credits for potential second DMA tunnel */
 		spare += TB_MIN_DMA_CREDITS;
 	} else {
-- 
2.43.0

[PATCH v2 3/3] thunderbolt: Fix credits reservation logic for DisplayPort tunnels

[Gil Fine]

Currently we reserve lane adapter credits for as many DisplayPort
streams as the leftover credits allow, after USB3, PCIe and the DMA
reserve (which only covers one full DMA tunnel plus a minimal second
one). This is wasteful in practice as no known host router exposes more
than three DP IN adapters.

As multiple DMA tunnels become more common (as is topology below), these
unused DisplayPort credits can be used for additional DMA tunnels.

Take for example the following topology, where the links from the hub to
Host2, Host3, and Host4 are inter-domain links carrying DMA tunnels:

          --- Domain 1 ---
          [Host1: USB4 v1]
                 |
                 |
         [Hub:   USB4 v2]
         /       |        \
        /        |         \
   --Domain2-- --Domain3-- --Domain4--
       |         |            |
   [Host2]     [Host3]      [Host4]
   USB4v1      USB4v1       USB4v1

On the USB4 v2 hub upstream facing lane adapter with credits:
Total 160, control path = 2, USB3 = 20, PCIe = 76, 7 credits per
DisplayPort stream, DMA = 14 + 1, reserving the full six possible
DisplayPort streams is calculated as:
(160 - 2 - 20 - 76 - 14 - 1) / 7 = 47 / 7 = 6 => Six DisplayPort
streams.

This leaves only 20 credits for DMA - one full tunnel (14) plus a
reduced-throughput one (6), which is not optimal.

Fix this by limiting the reservation to TB_DP_RESERVED_STREAMS (3), or
the number of DP IN adapters above the lane adapter, whichever is lower.
Beyond these reserved DisplayPort streams, remaining credits for
DisplayPort and DMA tunnels are allocated on a first-come, first-served
basis.

With the reservation now limited to three streams instead of six, 21
credits are freed, giving DMA 41 credits, enough for three DMA tunnels
(14 + 14 + 13).

Fixes: 6ed541c53edc ("thunderbolt: Allocate credits according to router preferences")
Cc: stable@vger.kernel.org
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Assisted-by: LLM
---
 drivers/thunderbolt/tunnel.c | 41 +++++++++++++++++++++++++++++++++---
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/thunderbolt/tunnel.c b/drivers/thunderbolt/tunnel.c
index 0625b1ff3820..f7e9d58de2f7 100644
--- a/drivers/thunderbolt/tunnel.c
+++ b/drivers/thunderbolt/tunnel.c
@@ -85,6 +85,9 @@
 /* Minimum number of credits for DMA path */
 #define TB_MIN_DMA_CREDITS		1
 
+/* Number of DP tunnels we reserve credits for in advance */
+#define TB_DP_RESERVED_STREAMS		3
+
 #define TB_DMA_PRIORITY			5
 #define TB_DMA_WEIGHT			1
 
@@ -156,6 +159,22 @@ static inline unsigned int tb_usable_credits(const struct tb_port *port)
 	return port->total_credits - port->ctl_credits;
 }
 
+static unsigned int tb_dp_in_count(struct tb_switch *sw)
+{
+	unsigned int count = 0;
+
+	while (sw) {
+		const struct tb_port *p;
+
+		tb_switch_for_each_port(sw, p)
+			if (tb_port_is_dpin(p))
+				count++;
+		sw = tb_switch_parent(sw);
+	}
+
+	return count;
+}
+
 /**
  * tb_available_credits() - Available credits for PCIe and DMA
  * @port: Lane adapter to check
@@ -167,9 +186,9 @@ static inline unsigned int tb_usable_credits(const struct tb_port *port)
 static unsigned int tb_available_credits(const struct tb_port *port,
 					 size_t *max_dp_streams)
 {
-	const struct tb_switch *sw = port->sw;
+	struct tb_switch *sw = port->sw;
 	int credits, usb3, pcie, spare;
-	size_t ndp;
+	size_t ndp, reserved;
 
 	usb3 = tb_acpi_may_tunnel_usb3() ? sw->max_usb3_genx_credits : 0;
 	pcie = tb_acpi_may_tunnel_pcie() ? sw->max_pcie_credits : 0;
@@ -197,7 +216,23 @@ static unsigned int tb_available_credits(const struct tb_port *port,
 	} else {
 		ndp = 0;
 	}
-	credits -= ndp * (sw->min_dp_aux_credits + sw->min_dp_main_credits);
+
+	reserved = min(TB_DP_RESERVED_STREAMS, ndp);
+
+	/*
+	 * The only real use case is a downstream directed DP tunnel, so reserve
+	 * AUX + main video on the upstream facing adapter and only AUX on the
+	 * downstream facing one. Don't reserve more than the number of DP IN
+	 * adapters above the current lane adapter.
+	 */
+	if (tb_is_upstream_port(port)) {
+		reserved = min(reserved, tb_dp_in_count(tb_switch_parent(sw)));
+		credits -= reserved *
+			   (sw->min_dp_aux_credits + sw->min_dp_main_credits);
+	} else {
+		reserved = min(reserved, tb_dp_in_count(sw));
+		credits -= reserved * sw->min_dp_aux_credits;
+	}
 	credits -= usb3;
 
 	if (max_dp_streams)
-- 
2.43.0

Re: [PATCH v2 2/3] thunderbolt: Fix DMA credit limit to use host router value

[Mika Westerberg]

On Thu, Sep 17, 2026 at 01:57:54AM +0300, Gil Fine wrote:
> Currently, when allocating credits for a DMA tunnel, we reserve credits
> based on the baMaxHI parameter taken from the router that owns the
> ingress adapter of the current hop.
> In a host-to-host topology with a hub in the middle:
> 
>   [Host1] <-> [Hub] <-> [Host2]
> 
> this incorrectly uses the hub's value instead of the host router's.
> The DMA engine limit is defined by the host router baMaxHI.
> 
> Fix this by alway use the baMaxHI of the host router instead.
> 
> Fixes: 6ed541c53edc ("thunderbolt: Allocate credits according to router preferences")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
> Assisted-by: LLM
> ---
>  drivers/thunderbolt/tunnel.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thunderbolt/tunnel.c b/drivers/thunderbolt/tunnel.c
> index 7a033df7f916..0625b1ff3820 100644
> --- a/drivers/thunderbolt/tunnel.c
> +++ b/drivers/thunderbolt/tunnel.c
> @@ -175,7 +175,8 @@ static unsigned int tb_available_credits(const struct tb_port *port,
>  	pcie = tb_acpi_may_tunnel_pcie() ? sw->max_pcie_credits : 0;
>  
>  	if (tb_acpi_is_xdomain_allowed()) {
> -		spare = min_not_zero(sw->max_dma_credits, dma_credits);
> +		spare = min_not_zero(sw->tb->root_switch->max_dma_credits,
> +				     dma_credits);

This will make the KUnit tests fail now because sw->tb is NULL.

I think that what we want to do is to make this whole thing a patch series
that adds the shared buffer support so that:

 1. Adds the tb to KUnit tests so that they will pass.
 2. Adds the fixes here these are needed for hosts that do not support
 shared buffers.
 3. Adds shared buffers.

Does that make sense? It means no 7.3 but 7.4 is possible still and you can
always include these in your branch so whoever internal needs can pull them
there. Let me know what you think.