Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8 |
|
#
06cbcbfa |
| 18-Jan-2023 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Add missing kernel-doc comment to tb_tunnel_maximum_bandwidth()
These were missing from the original commit so add them now. No functional changes.
Signed-off-by: Mika Westerberg <mika
thunderbolt: Add missing kernel-doc comment to tb_tunnel_maximum_bandwidth()
These were missing from the original commit so add them now. No functional changes.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
Revision tags: v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32 |
|
#
6ce35635 |
| 23-Mar-2022 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Add support for DisplayPort bandwidth allocation mode
The USB4 spec defines an optional feature that allows the connection manager to negotiate with the graphics through DPCD registers
thunderbolt: Add support for DisplayPort bandwidth allocation mode
The USB4 spec defines an optional feature that allows the connection manager to negotiate with the graphics through DPCD registers changes in the bandwidth allocation dynamically. This is referred as "bandwidth allocation mode" in the spec. The connection manager uses DP IN adapters registers to communicate with the graphics, and also gets notifications from these adapters when the graphics wants to change the bandwidth allocation. Both the connection manager and the graphics driver needs to support this.
We check if the DP IN adapter supports this and if it does enable it before establishing a DP tunnel. Then we react on DP_BW notifications coming from the DP IN adapter and update the bandwidth allocation accordingly (within the maximum common capabilities the DP IN/OUT support).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
9d2d0a5c |
| 01-Apr-2022 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Use different lane for second DisplayPort tunnel
Brad reported that on Apple hardware with Light Ridge or Falcon Ridge controller, plugging in a chain of Thunderbolt displays (Light Rid
thunderbolt: Use different lane for second DisplayPort tunnel
Brad reported that on Apple hardware with Light Ridge or Falcon Ridge controller, plugging in a chain of Thunderbolt displays (Light Ridge based controllers) causes all kinds of tearing and flickering. The reason for this is that on Thunderbolt 1 hardware there is no lane bonding so we have two independent 10 Gb/s lanes, and currently Linux tunnels both displays through the lane 1. This makes the displays to share the 10 Gb/s bandwidth which may not be enough for higher resolutions.
For this reason make the second tunnel go through the lane 0 instead. This seems to match what the macOS connection manager is also doing.
Reported-by: Brad Campbell <lists2009@fnarfbargle.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Brad Campbell <lists2009@fnarfbargle.com>
show more ...
|
Revision tags: v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3 |
|
#
43bddb26 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For exa
thunderbolt: Tear down existing tunnels when resuming from hibernate
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
47dbf249 |
| 14-Nov-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may n
thunderbolt: Tear down existing tunnels when resuming from hibernate
commit 43bddb26e20af916249b5318200cfe1734c1700c upstream.
If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|