Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
dc32d754 |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for o
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for other files in this driver.
Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
dc32d754 |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for o
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for other files in this driver.
Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
dc32d754 |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for o
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for other files in this driver.
Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
dc32d754 |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for o
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for other files in this driver.
Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
dc32d754 |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for o
thunderbolt: Introduce tb_path_deactivate_hop()
commit b35c1d7b11da8c08b14147bbe87c2c92f7a83f8b upstream.
This function can be used to clear path config space of an adapter. Make it available for other files in this driver.
Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: 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, 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 |
|
#
259e0c71 |
| 31-Mar-2022 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Dump path config space entries during discovery
This is useful when debugging possible issues during tunnel discovery.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
thunderbolt: Dump path config space entries during discovery
This is useful when debugging possible issues during tunnel discovery.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Brad Campbell <lists2009@fnarfbargle.com>
show more ...
|
Revision tags: v5.15.32, 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 ...
|