linux-stable.git/drivers/net/thunderbolt, branch v7.2 Linux kernel stable tree net: thunderbolt: Tear down DMA paths before stopping the rings 2026-08-06T15:19:53+00:00 Fan XinRan shinjiangjiang@gmail.com 2026-08-03T14:38:50+00:00 68bf02b6b4ad3f748c6db71fd77b6c0402d252f4 tbnet_tear_down() stops both rings and frees their frame buffers before calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's descriptor base and tbnet_free_buffers() unmaps and frees the pages the frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's 'pending' bit, anything still in flight has nowhere to drain to. The teardown sequence has been in this order since the driver was added. The setup path has not: commit ff7cd07f3064 ("net: thunderbolt: Enable DMA paths only after rings are enabled") moved the path enable to the end of tbnet_connected_work() and documented why: /* Both logins successful so enable the rings, high-speed DMA * paths and start the network device queue. * * Note we enable the DMA paths last to make sure we have primed * the Rx ring before any incoming packets are allowed to * arrive. */ Teardown was never updated to match, so the rings and the paths now come down in the same order they go up instead of in reverse. On an ASMedia ASM4242 host router the 'pending' bit then never clears: every teardown burns the full 500 ms timeout and __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to 5 s does not help, so the hop is not slow to drain, it never drains at all. The failure is invisible above the thunderbolt core. __tb_path_deactivate_hops() is void and only calls tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() and __tb_disconnect_xdomain_paths() are void as well, and tb_disconnect_xdomain_paths() ends in an unconditional "return 0". So tb_xdomain_disable_paths() reports success and the netdev_warn() below it never fires. Repeated teardowns eventually take the XDomain control channel down, after which the peer node is gone and only a power cycle brings the controller back. Deactivating the paths first fixes it. Measured with kretprobes on a stock v6.17 tree with no other patches applied, on a link that was up and had just carried traffic: before: __tb_path_deactivate_hop() returns 0 for the first hop, then -ETIMEDOUT for the second 500335 us later after: 0 for both, 525 us apart Alternating the two orderings ABBA over three load levels, four teardowns per arm: every teardown failed before the change (21 of 21 that ran), none failed after (0 of 24). The before arms ran short because the link died partway through. The same split shows up when the interface is enslaved to a bond instead of just brought down, which is how I ran into this in the first place. Throughput and latency after the change are unchanged. Hosts whose routers drain the hop despite the stale descriptor base see no functional difference, since the paths end up deactivated either way. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Fan XinRan <shinjiangjiang@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20260803-b4-tbnet-teardown-v2-1-27de6a13ca2d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
tbnet_tear_down() stops both rings and frees their frame buffers before
calling tb_xdomain_disable_paths().  tb_ring_stop() zeroes the ring's
descriptor base and tbnet_free_buffers() unmaps and frees the pages the
frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's
'pending' bit, anything still in flight has nowhere to drain to.

The teardown sequence has been in this order since the driver was added.
The setup path has not: commit ff7cd07f3064 ("net: thunderbolt: Enable
DMA paths only after rings are enabled") moved the path enable to the end
of tbnet_connected_work() and documented why:

	/* Both logins successful so enable the rings, high-speed DMA
	 * paths and start the network device queue.
	 *
	 * Note we enable the DMA paths last to make sure we have primed
	 * the Rx ring before any incoming packets are allowed to
	 * arrive.
	 */

Teardown was never updated to match, so the rings and the paths now come
down in the same order they go up instead of in reverse.

On an ASMedia ASM4242 host router the 'pending' bit then never clears:
every teardown burns the full 500 ms timeout and
__tb_path_deactivate_hop() returns -ETIMEDOUT.  Raising the timeout to
5 s does not help, so the hop is not slow to drain, it never drains
at all.

The failure is invisible above the thunderbolt core.
__tb_path_deactivate_hops() is void and only calls tb_port_warn();
tb_path_deactivate(), tb_tunnel_deactivate() and
__tb_disconnect_xdomain_paths() are void as well, and
tb_disconnect_xdomain_paths() ends in an unconditional "return 0".  So
tb_xdomain_disable_paths() reports success and the netdev_warn() below
it never fires.  Repeated teardowns eventually take the XDomain control
channel down, after which the peer node is gone and only a power cycle
brings the controller back.

Deactivating the paths first fixes it.  Measured with kretprobes on a
stock v6.17 tree with no other patches applied, on a link that was up
and had just carried traffic:

  before: __tb_path_deactivate_hop() returns 0 for the first hop, then
          -ETIMEDOUT for the second 500335 us later
  after:  0 for both, 525 us apart

Alternating the two orderings ABBA over three load levels, four
teardowns per arm: every teardown failed before the change (21 of 21
that ran), none failed after (0 of 24).  The before arms ran short
because the link died partway through.  The same split shows up when
the interface is enslaved to a bond instead of just brought down, which
is how I ran into this in the first place.  Throughput and latency after
the change are unchanged.

Hosts whose routers drain the hop despite the stale descriptor base see
no functional difference, since the paths end up deactivated either way.

Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
Signed-off-by: Fan XinRan <shinjiangjiang@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://patch.msgid.link/20260803-b4-tbnet-teardown-v2-1-27de6a13ca2d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Revert "net: thunderbolt: Enable end-to-end flow control also in transmit" 2026-07-30T23:10:24+00:00 Fan Ye fy15309206903@gmail.com 2026-07-27T12:29:48+00:00 1881f2efbf7f78dc0a79a387b29fde6ff56d3731 This reverts commit a8065af3346ebd7c76ebc113451fb3ba94cf7769. Per the USB4 spec, a Transmit Descriptor Ring with E2E flow control disabled does not require any credits to be available before the Host Interface Adapter Layer transmits a tunneled packet from it. Once E2E is enabled on that ring the controller must first obtain end-to-end credits. The ASMedia ASM4242 USB4 host router (PCI 1b21:2425) never delivers those credits. The controller does accept the configuration: reading the ring OPTIONS register back right after tb_ring_start() returns exactly what was written, including RING_FLAG_E2E_FLOW_CONTROL (bit 28) and the E2E HopID field. No credit ever arrives though, so the Tx ring's hardware consumer index never advances and the link carries no traffic at all. Measured on two hosts connected point to point, onboard ASM4242 on MSI X870E and X870, v6.17, stock drivers/net/thunderbolt/main.c with only this revert applied on top: before: 100% packet loss to the peer; thunderbolt0 is up and the XDomain handshake completes ("new host found"), but iperf3 fails with "No route to host" once the neighbour entry expires after: 0% packet loss, 0.28 ms RTT; iperf3 4.21 Gb/s one way and 5.17 Gb/s the other (5 runs each, stddev <= 0.02), 1 retransmit in 10 s An instrumented build additionally showed a frozen-Tx-consumer watchdog firing ~30k times in a 10 s window before this change. Rx-side E2E is not touched by this revert, so peers that do return credits keep receive-side flow control. ASMedia does not look like an isolated case. The out-of-tree thunderbolt-ibverbs project disables native E2E on AMD NHI by default, noting that "Strix Halo has reproduced TX completion wedges with multiple native E2E rings active" -- the same failure mode, on a different vendor. Since the driver has no way to tell in advance which host router returns the credits, going back to the previous behaviour looks safer than adding a quirk per affected part; Tx-side E2E can be reintroduced as an opt-in for controllers that are known to implement the credit return. Note that the reverted commit was not fixing a reported problem, it was derived from the spec wording alone, so this revert is not expected to regress a known workload. Cc'ing the original author in case there was one. Fixes: a8065af3346e ("net: thunderbolt: Enable end-to-end flow control also in transmit") Cc: zhangjianrong <zhangjianrong5@huawei.com> Signed-off-by: Fan Ye <fy15309206903@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20260727123002.25225-1-fy15309206903@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
This reverts commit a8065af3346ebd7c76ebc113451fb3ba94cf7769.

Per the USB4 spec, a Transmit Descriptor Ring with E2E flow control
disabled does not require any credits to be available before the Host
Interface Adapter Layer transmits a tunneled packet from it. Once E2E is
enabled on that ring the controller must first obtain end-to-end
credits.

The ASMedia ASM4242 USB4 host router (PCI 1b21:2425) never delivers
those credits. The controller does accept the configuration: reading the
ring OPTIONS register back right after tb_ring_start() returns exactly
what was written, including RING_FLAG_E2E_FLOW_CONTROL (bit 28) and the
E2E HopID field. No credit ever arrives though, so the Tx ring's
hardware consumer index never advances and the link carries no traffic
at all.

Measured on two hosts connected point to point, onboard ASM4242 on MSI
X870E and X870, v6.17, stock drivers/net/thunderbolt/main.c with only
this revert applied on top:

  before: 100% packet loss to the peer; thunderbolt0 is up and the
          XDomain handshake completes ("new host found"), but iperf3
          fails with "No route to host" once the neighbour entry
          expires
  after:  0% packet loss, 0.28 ms RTT; iperf3 4.21 Gb/s one way and
          5.17 Gb/s the other (5 runs each, stddev <= 0.02), 1
          retransmit in 10 s

An instrumented build additionally showed a frozen-Tx-consumer watchdog
firing ~30k times in a 10 s window before this change.

Rx-side E2E is not touched by this revert, so peers that do return
credits keep receive-side flow control.

ASMedia does not look like an isolated case. The out-of-tree
thunderbolt-ibverbs project disables native E2E on AMD NHI by default,
noting that "Strix Halo has reproduced TX completion wedges with
multiple native E2E rings active" -- the same failure mode, on a
different vendor. Since the driver has no way to tell in advance which
host router returns the credits, going back to the previous behaviour
looks safer than adding a quirk per affected part; Tx-side E2E can be
reintroduced as an opt-in for controllers that are known to implement
the credit return.

Note that the reverted commit was not fixing a reported problem, it was
derived from the spec wording alone, so this revert is not expected to
regress a known workload. Cc'ing the original author in case there was
one.

Fixes: a8065af3346e ("net: thunderbolt: Enable end-to-end flow control also in transmit")
Cc: zhangjianrong <zhangjianrong5@huawei.com>
Signed-off-by: Fan Ye <fy15309206903@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://patch.msgid.link/20260727123002.25225-1-fy15309206903@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Merge tag 'net-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net 2026-06-25T19:25:36+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-06-25T19:25:36+00:00 805185b7c7a1069e407b6f7b3bc98e44d415f484 Pull networking fixes from Jakub Kicinski: "Including fixes from netfilter and IPsec. Current release - regressions: - do not acquire dev->tx_global_lock in netdev_watchdog_up() - ethtool: keep rtnl_lock for ops using ethtool_op_get_link() - fix deadlock in nested UP notifier events Current release - new code bugs: - eth: - cn20k: fix subbank free list indexing for search order - airoha: fix BQL underflow in shared QDMA TX ring Previous releases - regressions: - netfilter: - flowtable: fix offloaded ct timeout never being extended - nf_conncount: prevent connlimit drops for early confirmed ct Previous releases - always broken: - require CAP_NET_ADMIN in the originating netns when modifying cross-netns devices - report NAPI thread PID in the caller's pid namespace - mac802154: fix dirty frag in in-place crypto for IOT radios - sctp: hold socket lock when dumping endpoints in sctp_diag, avoid an overflow - eth: gve: fix header buffer corruption with header-split and HW-GRO - af_key: initialize alg_key_len for IPComp states, prevent OOB read" * tag 'net-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (213 commits) selftests: bonding: add a test for VLAN propagation over a bonded real device vlan: defer real device state propagation to netdev_work net: add the driver-facing netdev_work scheduling API net: turn the rx_mode work into a generic netdev_work facility net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link() rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate rxrpc: Fix leak of released call in recvmsg(MSG_PEEK) rxrpc: Fix socket notification race rxrpc: Fix potential infinite loop in rxrpc_recvmsg() rxrpc: Fix oob challenge leak in cleanup after notification failure rxrpc: Fix the reception of a reply packet before data transmission afs: Fix uncancelled rxrpc OOB message handler afs: Fix further netns teardown to cancel the preallocation charger rxrpc: Fix double unlock in rxrpc_recvmsg() rxrpc: Fix leak of connection from OOB challenge rxrpc: Fix ACKALL packet handling net: hns3: differentiate autoneg default values between copper and fiber net: hns3: fix permanent link down deadlock after reset net: hns3: refactor MAC autoneg and speed configuration net: hns3: unify copper port ksettings configuration path ... 
Pull networking fixes from Jakub Kicinski:
 "Including fixes from netfilter and IPsec.

  Current release - regressions:

   - do not acquire dev->tx_global_lock in netdev_watchdog_up()

   - ethtool: keep rtnl_lock for ops using ethtool_op_get_link()

   - fix deadlock in nested UP notifier events

  Current release - new code bugs:

   - eth:
      - cn20k: fix subbank free list indexing for search order
      - airoha: fix BQL underflow in shared QDMA TX ring

  Previous releases - regressions:

   - netfilter:
     - flowtable: fix offloaded ct timeout never being extended
     - nf_conncount: prevent connlimit drops for early confirmed ct

  Previous releases - always broken:

   - require CAP_NET_ADMIN in the originating netns when modifying
     cross-netns devices

   - report NAPI thread PID in the caller's pid namespace

   - mac802154: fix dirty frag in in-place crypto for IOT radios

   - sctp: hold socket lock when dumping endpoints in sctp_diag, avoid
     an overflow

   - eth: gve: fix header buffer corruption with header-split and HW-GRO

   - af_key: initialize alg_key_len for IPComp states, prevent OOB read"

* tag 'net-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (213 commits)
  selftests: bonding: add a test for VLAN propagation over a bonded real device
  vlan: defer real device state propagation to netdev_work
  net: add the driver-facing netdev_work scheduling API
  net: turn the rx_mode work into a generic netdev_work facility
  net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()
  rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate
  rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)
  rxrpc: Fix socket notification race
  rxrpc: Fix potential infinite loop in rxrpc_recvmsg()
  rxrpc: Fix oob challenge leak in cleanup after notification failure
  rxrpc: Fix the reception of a reply packet before data transmission
  afs: Fix uncancelled rxrpc OOB message handler
  afs: Fix further netns teardown to cancel the preallocation charger
  rxrpc: Fix double unlock in rxrpc_recvmsg()
  rxrpc: Fix leak of connection from OOB challenge
  rxrpc: Fix ACKALL packet handling
  net: hns3: differentiate autoneg default values between copper and fiber
  net: hns3: fix permanent link down deadlock after reset
  net: hns3: refactor MAC autoneg and speed configuration
  net: hns3: unify copper port ksettings configuration path
  ...
net: thunderbolt: Fix frags[] overflow by bounding frame_count 2026-06-19T01:09:36+00:00 Maoyi Xie maoyixie.tju@gmail.com 2026-06-16T17:38:41+00:00 55d9895f89970501fe126d1026b586b04a224c27 tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, hdr_size, frame_size, TBNET_RX_PAGE_SIZE - hdr_size); A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info. Tighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never produce more fragments than frags[] can hold. This matches the recent skb frags overflow fixes in other receive paths, for example f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path") and 600dc40554dc ("net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()"). Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/178163152194.2486768.14724194232649760778@maoyixie.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The
first frame goes into the skb linear area and every further frame is added as
a page fragment.

	skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
			page, hdr_size, frame_size,
			TBNET_RX_PAGE_SIZE - hdr_size);

A packet of frame_count frames therefore ends up with frame_count - 1
fragments. tbnet_check_frame() only bounds the peer supplied frame_count to
TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A
peer that sends a packet of 19 or more small frames pushes nr_frags past
MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and
corrupts memory after the shared info.

Tighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never
produce more fragments than frags[] can hold. This matches the recent skb
frags overflow fixes in other receive paths, for example f0813bcd2d9d ("net:
wwan: t7xx: fix potential skb->frags overflow in RX path") and 600dc40554dc
("net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()").

Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
Cc: stable@vger.kernel.org
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://patch.msgid.link/178163152194.2486768.14724194232649760778@maoyixie.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
thunderbolt / net: Let the service drivers configure interrupt throttling 2026-05-19T12:20:18+00:00 Mika Westerberg mika.westerberg@linux.intel.com 2026-02-27T17:51:45+00:00 c51777370ac2ef435401340e205ef1d0c778df28 Instead of the core driver programming fixed value for throttling let the service drivers to specify the interval if they need this. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> 
Instead of the core driver programming fixed value for throttling let
the service drivers to specify the interval if they need this.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
thunderbolt / net: Move ring_frame_size() to thunderbolt.h 2026-05-19T12:20:18+00:00 Mika Westerberg mika.westerberg@linux.intel.com 2025-11-10T11:16:53+00:00 5140737c592d23b4de0f98c47dd347684a0c8de3 This function can be used outside of thunderbolt networking driver so move it to the common header. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> 
This function can be used outside of thunderbolt networking driver so
move it to the common header.

No functional changes.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
net: thunderbolt: Allow reading link settings 2026-01-19T20:09:58+00:00 Ian MacDonald ian@netstatz.com 2026-01-15T11:56:46+00:00 7a3d3279a566813b453f9ac4cf01e6f48e4e40e4 In order to use Thunderbolt networking as part of bonding device it needs to support ->get_link_ksettings() ethtool operation, so that the bonding driver can read the link speed and the related attributes. Add support for this to the driver. Signed-off-by: Ian MacDonald <ian@netstatz.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20260115115646.328898-5-mika.westerberg@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
In order to use Thunderbolt networking as part of bonding device it
needs to support ->get_link_ksettings() ethtool operation, so that the
bonding driver can read the link speed and the related attributes. Add
support for this to the driver.

Signed-off-by: Ian MacDonald <ian@netstatz.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://patch.msgid.link/20260115115646.328898-5-mika.westerberg@linux.intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: thunderbolt: Allow changing MAC address of the device 2026-01-19T20:09:57+00:00 Mika Westerberg mika.westerberg@linux.intel.com 2026-01-15T11:56:43+00:00 8411d7286bcbda9c3d6bbe5c1427fe895c216628 The MAC address we use is based on a suggestion in the USB4 Inter-domain spec but it is not really used in the USB4NET protocol. It is more targeted for the upper layers of the network stack. There is no reason why it should not be changed by the userspace for example if needed for bonding. Reported-by: Ian MacDonald <ian@netstatz.com> Closes: https://lore.kernel.org/netdev/CAFJzfF9N4Hak23sc-zh0jMobbkjK7rg4odhic1DQ1cC+=MoQoA@mail.gmail.com/ Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20260115115646.328898-2-mika.westerberg@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
The MAC address we use is based on a suggestion in the USB4 Inter-domain
spec but it is not really used in the USB4NET protocol. It is more
targeted for the upper layers of the network stack. There is no reason
why it should not be changed by the userspace for example if needed for
bonding.

Reported-by: Ian MacDonald <ian@netstatz.com>
Closes: https://lore.kernel.org/netdev/CAFJzfF9N4Hak23sc-zh0jMobbkjK7rg4odhic1DQ1cC+=MoQoA@mail.gmail.com/
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://patch.msgid.link/20260115115646.328898-2-mika.westerberg@linux.intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: thunderbolt: Enable end-to-end flow control also in transmit 2025-07-02T21:17:43+00:00 zhangjianrong zhangjianrong5@huawei.com 2025-06-28T09:38:13+00:00 a8065af3346ebd7c76ebc113451fb3ba94cf7769 According to USB4 specification, if E2E flow control is disabled for the Transmit Descriptor Ring, the Host Interface Adapter Layer shall not require any credits to be available before transmitting a Tunneled Packet from this Transmit Descriptor Ring, so e2e flow control should be enabled in both directions. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/20250624153805.GC2824380@black.fi.intel.com Signed-off-by: zhangjianrong <zhangjianrong5@huawei.com> Link: https://patch.msgid.link/20250628093813.647005-1-zhangjianrong5@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
According to USB4 specification, if E2E flow control is disabled for
the Transmit Descriptor Ring, the Host Interface Adapter Layer shall
not require any credits to be available before transmitting a Tunneled
Packet from this Transmit Descriptor Ring, so e2e flow control should
be enabled in both directions.

Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/20250624153805.GC2824380@black.fi.intel.com
Signed-off-by: zhangjianrong <zhangjianrong5@huawei.com>
Link: https://patch.msgid.link/20250628093813.647005-1-zhangjianrong5@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: thunderbolt: Fix the parameter passing of tb_xdomain_enable_paths()/tb_xdomain_disable_paths() 2025-07-02T21:15:09+00:00 zhangjianrong zhangjianrong5@huawei.com 2025-06-28T09:49:20+00:00 8ec31cb17cd355cea25cdb8496d9b3fbf1321647 According to the description of tb_xdomain_enable_paths(), the third parameter represents the transmit ring and the fifth parameter represents the receive ring. tb_xdomain_disable_paths() is the same case. [Jakub] Mika says: it works now because both rings ->hop is the same Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/20250625051149.GD2824380@black.fi.intel.com Signed-off-by: zhangjianrong <zhangjianrong5@huawei.com> Link: https://patch.msgid.link/20250628094920.656658-1-zhangjianrong5@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
According to the description of tb_xdomain_enable_paths(), the third
parameter represents the transmit ring and the fifth parameter represents
the receive ring. tb_xdomain_disable_paths() is the same case.

[Jakub] Mika says: it works now because both rings ->hop is the same

Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/20250625051149.GD2824380@black.fi.intel.com
Signed-off-by: zhangjianrong <zhangjianrong5@huawei.com>
Link: https://patch.msgid.link/20250628094920.656658-1-zhangjianrong5@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>