linux-stable.git/drivers/thunderbolt, branch v6.6.78

thunderbolt: Don't display nvm_version unless upgrade supported

2025-01-09T12:31:49+00:00

[ Upstream commit e34f1717ef0632fcec5cb827e5e0e9f223d70c9b ]

The read will never succeed if NVM wasn't initialized due to an unknown
format.

Add a new callback for visibility to only show when supported.

Cc: stable@vger.kernel.org
Fixes: aef9c693e7e5 ("thunderbolt: Move vendor specific NVM handling into nvm.c")
Reported-by: Richard Hughes 
Closes: https://github.com/fwupd/fwupd/issues/8200
Signed-off-by: Mario Limonciello 
Signed-off-by: Mika Westerberg 
Signed-off-by: Sasha Levin

thunderbolt: Add support for Intel Panther Lake-M/P

2025-01-09T12:31:49+00:00

[ Upstream commit 8644b48714dca8bf2f42a4ff8311de8efc9bd8c3 ]

Intel Panther Lake-M/P has the same integrated Thunderbolt/USB4
controller as Lunar Lake. Add these PCI IDs to the driver list of
supported devices.

Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg 
Signed-off-by: Sasha Levin

thunderbolt: Add support for Intel Lunar Lake

2025-01-09T12:31:48+00:00

[ Upstream commit 2cd3da4e37453019e21a486d9de3144f46b4fdf7 ]

Intel Lunar Lake has similar integrated Thunderbolt/USB4 controller as
Intel Meteor Lake with some small differences in the host router (it has
3 DP IN adapters for instance). Add the Intel Lunar Lake PCI IDs to the
driver list of supported devices.

Tested-by: Pengfei Xu 
Signed-off-by: Mika Westerberg 
Stable-dep-of: 8644b48714dc ("thunderbolt: Add support for Intel Panther Lake-M/P")
Signed-off-by: Sasha Levin

thunderbolt: Improve redrive mode handling

2024-12-27T12:58:51+00:00

commit 24740385cb0d6d22ab7fa7adf36546d5b3cdcf73 upstream.

When USB-C monitor is connected directly to Intel Barlow Ridge host, it
goes into "redrive" mode that basically routes the DisplayPort signals
directly from the GPU to the USB-C monitor without any tunneling needed.
However, the host router must be powered on for this to work. Aaron
reported that there are a couple of cases where this will not work with
the current code:

  - Booting with USB-C monitor plugged in.
  - Plugging in USB-C monitor when the host router is in sleep state
    (runtime suspended).
  - Plugging in USB-C device while the system is in system sleep state.

In all these cases once the host router is runtime suspended the picture
on the connected USB-C display disappears too. This is certainly not
what the user expected.

For this reason improve the redrive mode handling to keep the host
router from runtime suspending when detect that any of the above cases
is happening.

Fixes: a75e0684efe5 ("thunderbolt: Keep the domain powered when USB4 port is in redrive mode")
Reported-by: Aaron Rainbolt 
Closes: https://lore.kernel.org/linux-usb/20241009220118.70bfedd0@kf-ir16/
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Honor TMU requirements in the domain when setting TMU mode

2024-11-08T15:28:24+00:00

commit 3cea8af2d1a9ae5869b47c3dabe3b20f331f3bbd upstream.

Currently, when configuring TMU (Time Management Unit) mode of a given
router, we take into account only its own TMU requirements ignoring
other routers in the domain. This is problematic if the router we are
configuring has lower TMU requirements than what is already configured
in the domain.

In the scenario below, we have a host router with two USB4 ports: A and
B. Port A connected to device router #1 (which supports CL states) and
existing DisplayPort tunnel, thus, the TMU mode is HiFi uni-directional.

1. Initial topology

          [Host]
         A/
         /
 [Device #1]
   /
Monitor

2. Plug in device #2 (that supports CL states) to downstream port B of
   the host router

         [Host]
        A/    B\
        /       \
 [Device #1]    [Device #2]
   /
Monitor

The TMU mode on port B and port A will be configured to LowRes which is
not what we want and will cause monitor to start flickering.

To address this we first scan the domain and search for any router
configured to HiFi uni-directional mode, and if found, configure TMU
mode of the given router to HiFi uni-directional as well.

Cc: stable@vger.kernel.org
Signed-off-by: Gil Fine 
Signed-off-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Fix NULL pointer dereference in tb_port_update_credits()

2024-10-04T14:30:04+00:00

commit d3d17e23d1a0d1f959b4fa55b35f1802d9c584fa upstream.

Olliver reported that his system crashes when plugging in Thunderbolt 1
device:

 BUG: kernel NULL pointer dereference, address: 0000000000000020
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP NOPTI
 RIP: 0010:tb_port_do_update_credits+0x1b/0x130 [thunderbolt]
 Call Trace:
  
  ? __die+0x23/0x70
  ? page_fault_oops+0x171/0x4e0
  ? exc_page_fault+0x7f/0x180
  ? asm_exc_page_fault+0x26/0x30
  ? tb_port_do_update_credits+0x1b/0x130
  ? tb_switch_update_link_attributes+0x83/0xd0
  tb_switch_add+0x7a2/0xfe0
  tb_scan_port+0x236/0x6f0
  tb_handle_hotplug+0x6db/0x900
  process_one_work+0x171/0x340
  worker_thread+0x27b/0x3a0
  ? __pfx_worker_thread+0x10/0x10
  kthread+0xe5/0x120
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x31/0x50
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1b/0x30
  

This is due the fact that some Thunderbolt 1 devices only have one lane
adapter. Fix this by checking for the lane 1 before we read its credits.

Reported-by: Olliver Schinagl 
Closes: https://lore.kernel.org/linux-usb/c24c7882-6254-4e68-8f22-f3e8f65dc84f@schinagl.nl/
Fixes: 81af2952e606 ("thunderbolt: Add support for asymmetric link")
Cc: stable@vger.kernel.org
Cc: Gil Fine 
Signed-off-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Fix minimum allocated USB 3.x and PCIe bandwidth

2024-10-04T14:30:04+00:00

commit f0b94c1c5c7994a74e487f43c91cfc922105a423 upstream.

With the current bandwidth allocation we end up reserving too much for the USB
3.x and PCIe tunnels that leads to reduced capabilities for the second
DisplayPort tunnel.

Fix this by decreasing the USB 3.x allocation to 900 Mb/s which then allows
both tunnels to get the maximum HBR2 bandwidth.  This way, the reserved
bandwidth for USB 3.x and PCIe, would be 1350 Mb/s (taking weights of USB 3.x
and PCIe into account). So bandwidth allocations on a link are:
USB 3.x + PCIe tunnels => 1350 Mb/s
DisplayPort tunnel #1  => 17280 Mb/s
DisplayPort tunnel #2  => 17280 Mb/s

Total consumed bandwidth is 35910 Mb/s. So that all the above can be tunneled
on a Gen 3 link (which allows maximum of 36000 Mb/s).

Fixes: 582e70b0d3a4 ("thunderbolt: Change bandwidth reservations to comply USB4 v2")
Signed-off-by: Gil Fine 
Signed-off-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Send uevent after asymmetric/symmetric switch

2024-10-04T14:30:04+00:00

commit 5391bcfa56c79a891734e4d22aa0ca3217b86491 upstream.

We should send uevent to userspace whenever the link speed or width
changes but tb_switch_asym_enable() and tb_switch_asym_disable() set the
sw->link_width already so tb_switch_update_link_attributes() never
noticed the change.

Fix this so that we let tb_switch_update_link_attributes() update the
fields accordingly.

Fixes: 81af2952e606 ("thunderbolt: Add support for asymmetric link")
Reported-by: Pengfei Xu 
Tested-by: Pengfei Xu 
Signed-off-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Improve DisplayPort tunnel setup process to be more robust

2024-10-04T14:30:01+00:00

[ Upstream commit b4734507ac55cc7ea1380e20e83f60fcd7031955 ]

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 
Signed-off-by: Mika Westerberg 
Signed-off-by: Qin Wan 
Signed-off-by: Alexandru Gagniuc 
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Configure asymmetric link if needed and bandwidth allows

2024-10-04T14:30:01+00:00

[ Upstream commit 3e36528c1127b20492ffaea53930bcc3df46a718 ]

USB4 v2 spec defines a Gen 4 link that can operate as an asymmetric
120/40G. When the link is asymmetric, the USB4 port on one side of the
link operates with three TX lanes and one RX lane, while the USB4 port
on the opposite side of the link operates with three RX lanes and one TX
lane. Using asymmetric link we can get much more bandwidth from one
direction and that allows us to support the new Ultra High Bit Rate
DisplayPort modes (that consume up to 77.37 Gb/s).

Add the basic logic for changing Gen 4 links to asymmetric and back
following the below rules:

  1) The default threshold is 45 Gb/s (tunable by asym_threshold)
  2) When DisplayPort tunnel is established, or when there is bandwidth
     request through bandwidth allocation mode, the links can be
     transitioned to asymmetric or symmetric (depending on the
     required bandwidth).
  3) Only DisplayPort bandwidth on a link, is taken into account when
     deciding whether a link is transitioned to asymmetric or symmetric
  4) If bandwidth on a link is >= asym_threshold transition the link to
     asymmetric
  5) If bandwidth on a link < asym_threshold transition the link to
     symmetric (unless the bandwidth request is above currently
     allocated on a tunnel).
  6) If a USB4 v2 device router with symmetric link is connected,
     transition all the links above it to symmetric if the bandwidth
     allows.

Signed-off-by: Gil Fine 
Co-developed-by: Mika Westerberg 
Signed-off-by: Mika Westerberg 
Signed-off-by: Qin Wan 
Signed-off-by: Alexandru Gagniuc 
Signed-off-by: Greg Kroah-Hartman