| #
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 ...
|
| #
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 ...
|