thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create a DisplayPort tunnel and will be handed off to Linux connection
manager, but the DP OUT resource is not saved in the dp_resource list.

This patch adds tunnelled DP OUT port to the dp_resource list once the
DP tunnel is discovered.

Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com>
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 ...

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

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create a DisplayPort tunnel and will be handed off to Linux connection
manager, but the DP OUT resource is not saved in the dp_resource list.

This patch adds tunnelled DP OUT port to the dp_resource list once the
DP tunnel is discovered.

Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com>
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 ...

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

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create a DisplayPort tunnel and will be handed off to Linux connection
manager, but the DP OUT resource is not saved in the dp_resource list.

This patch adds tunnelled DP OUT port to the dp_resource list once the
DP tunnel is discovered.

Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com>
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 ...

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

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create a DisplayPort tunnel and will be handed off to Linux connection
manager, but the DP OUT resource is not saved in the dp_resource list.

This patch adds tunnelled DP OUT port to the dp_resource list once the
DP tunnel is discovered.

Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com>
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 ...

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

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create a DisplayPort tunnel and will be handed off to Linux connection
manager, but the DP OUT resource is not saved in the dp_resource list.

This patch adds tunnelled DP OUT port to the dp_resource list once the
DP tunnel is discovered.

Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com>
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 ...

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

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create a DisplayPort tunnel and will be handed off to Linux connection
manager, but the DP OUT resource is not saved in the dp_resource list.

This patch adds tunnelled DP OUT port to the dp_resource list once the
DP tunnel is discovered.

Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com>
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 ...

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

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create a DisplayPort tunnel and will be handed off to Linux connection
manager, but the DP OUT resource is not saved in the dp_resource list.

This patch adds tunnelled DP OUT port to the dp_resource list once the
DP tunnel is discovered.

Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com>
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 ...

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

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create a DisplayPort tunnel and will be handed off to Linux connection
manager, but the DP OUT resource is not saved in the dp_resource list.

This patch adds tunnelled DP OUT port to the dp_resource list once the
DP tunnel is discovered.

Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com>
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 ...

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

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create

thunderbolt: Add DP OUT resource when DP tunnel is discovered

commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.

If the boot firmware implements a connection manager of its own it may
create a DisplayPort tunnel and will be handed off to Linux connection
manager, but the DP OUT resource is not saved in the dp_resource list.

This patch adds tunnelled DP OUT port to the dp_resource list once the
DP tunnel is discovered.

Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com>
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 ...

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

thunderbolt: Use different lane for second DisplayPort tunnel

[ Upstream commit 9d2d0a5cf0ca063f417681cc33e767ce52615286 ]

Brad reported that on Apple hardware with Light Ridge or Falcon Ridge
cont

thunderbolt: Use different lane for second DisplayPort tunnel

[ Upstream commit 9d2d0a5cf0ca063f417681cc33e767ce52615286 ]

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

thunderbolt: Use different lane for second DisplayPort tunnel

[ Upstream commit 9d2d0a5cf0ca063f417681cc33e767ce52615286 ]

Brad reported that on Apple hardware with Light Ridge or Falcon Ridge
cont

thunderbolt: Use different lane for second DisplayPort tunnel

[ Upstream commit 9d2d0a5cf0ca063f417681cc33e767ce52615286 ]

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

thunderbolt: Add device links only when software connection manager is used

We only need to set up the device links when software connection manager
path is used. The firmware connection manager doe

thunderbolt: Add device links only when software connection manager is used

We only need to set up the device links when software connection manager
path is used. The firmware connection manager does not need them and if
they are present they may even cause problems.

Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

show more ...

thunderbolt: Add support for retimer NVM upgrade when there is no link

With help from platform firmware (ACPI) it is possible to power on
retimers even when there is no USB4 link (e.g nothing is con

thunderbolt: Add support for retimer NVM upgrade when there is no link

With help from platform firmware (ACPI) it is possible to power on
retimers even when there is no USB4 link (e.g nothing is connected to
the USB4 ports). This allows us to bring the USB4 sideband up so that we
can access retimers and upgrade their NVM firmware.

If the platform has support for this, we expose two additional
attributes under USB4 ports: offline and rescan. These can be used to
bring the port offline, rescan for the retimers and put the port online
again. The retimer NVM upgrade itself works the same way than with cable
connected.

Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

thunderbolt: Allow multiple DMA tunnels over a single XDomain connection

Currently we have had an artificial limitation of a single DMA tunnel
per XDomain connection. However, hardware wise there is

thunderbolt: Allow multiple DMA tunnels over a single XDomain connection

Currently we have had an artificial limitation of a single DMA tunnel
per XDomain connection. However, hardware wise there is no such limit
and software based connection manager can take advantage of all the DMA
rings available on the host to establish tunnels.

For this reason make the tb_xdomain_[enable|disable]_paths() to take the
DMA ring and HopID as parameter instead of storing them in the struct
tb_xdomain. We also add API functions to allocate input and output
HopIDs of the XDomain connection that the service drivers can use
instead of hard-coding.

Also convert the two existing service drivers over to this API.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

show more ...

thunderbolt: Decrease control channel timeout for software connection manager

When the firmware connection manager is not proxying between the
software and the hardware we can decrease the timeout f

thunderbolt: Decrease control channel timeout for software connection manager

When the firmware connection manager is not proxying between the
software and the hardware we can decrease the timeout for control
packets significantly. The USB4 spec recommends 10 ms +- 1 ms but we use
slightly larger value (100 ms) which is recommendation from Intel
Thunderbolt firmware folks. When firmware connection manager is running
then we keep using the existing 5000 ms.

To implement this we move the control channel allocation to
tb_domain_alloc(), and pass the timeout from that function to the
tb_ctl_alloc(). Then make both connection manager implementations pass
the timeout when they alloc the domain structure.

While there update kernel-doc of struct tb_ctl to match the reality.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

show more ...

thunderbolt: Increase runtime PM reference count on DP tunnel discovery

If the driver is unbound and then bound back it goes over the topology
and figure out the existing tunnels. However, if it fin

thunderbolt: Increase runtime PM reference count on DP tunnel discovery

If the driver is unbound and then bound back it goes over the topology
and figure out the existing tunnels. However, if it finds DP tunnel it
should make sure the domain does not runtime suspend as otherwise it
will tear down the DP tunnel unexpectedly.

Fixes: 6ac6faee5d7d ("thunderbolt: Add runtime PM for Software CM")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

show more ...