diff mbox series

[1/2] thunderbolt: Start lane initialization after sleep

Message ID 20210105092808.15817-1-mika.westerberg@linux.intel.com
State New
Headers show
Series [1/2] thunderbolt: Start lane initialization after sleep | expand

Commit Message

Mika Westerberg Jan. 5, 2021, 9:28 a.m. UTC
USB4 spec says that for TBT3 compatible device routers the connection
manager needs to set SLI (Start Lane Initialization) to get the lanes
that were not connected back to functional state after sleep. Same needs
to be done if the link was XDomain.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/thunderbolt/lc.c      | 35 +++++++++++++++++++++++++++++++++++
 drivers/thunderbolt/switch.c  | 27 ++++++++++++++++++++++++++-
 drivers/thunderbolt/tb.h      |  1 +
 drivers/thunderbolt/tb_regs.h |  1 +
 4 files changed, 63 insertions(+), 1 deletion(-)

Comments

Yehezkel Bernat Jan. 5, 2021, 1:35 p.m. UTC | #1
On Tue, Jan 5, 2021 at 11:28 AM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> USB4 spec says that for TBT3 compatible device routers the connection
> manager needs to set SLI (Start Lane Initialization) to get the lanes
> that were not connected back to functional state after sleep. Same needs
> to be done if the link was XDomain.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
>  drivers/thunderbolt/lc.c      | 35 +++++++++++++++++++++++++++++++++++
>  drivers/thunderbolt/switch.c  | 27 ++++++++++++++++++++++++++-
>  drivers/thunderbolt/tb.h      |  1 +
>  drivers/thunderbolt/tb_regs.h |  1 +
>  4 files changed, 63 insertions(+), 1 deletion(-)
>

Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Yehezkel Bernat Jan. 5, 2021, 1:53 p.m. UTC | #2
On Tue, Jan 5, 2021 at 11:28 AM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> In some cases it is useful to be able de-authorize devices. For example
> if user logs out the userspace can have a policy that disconnects PCIe
> devices until logged in again. This is only possible for software based
> connection manager as it directly controls the tunnels.
>
> For this reason make the authorized attribute accept writing 0 which
> makes the software connection manager to tear down the corresponding
> PCIe tunnel. Userspace can check if this is supported by reading a new
> domain attribute deauthorization, that holds 1 in that case.

What a great feature! Thanks for implementing it.

BTW, is there any general way to disable the device operations before such a
disconnection? The user has a way to stop removable disks, for example, but
maybe other devices need additional precaution from the user (eGPU?).


>                 Possible values are supported:
>
> -               ==  ===========================================
> +               ==  ===================================================
> +               0   The device will be de-authorized (only supported if
> +                   deauthorization attribute under domain contains 1)
>                 1   The device will be authorized and connected
> -               ==  ===========================================
> +               ==  ===================================================
>
>                 When key attribute contains 32 byte hex string the possible
>                 values are:

As 0 is available for 'secure' security level too, you may want to reflect it in
the documentation here somehow.


> +static int disapprove_switch(struct device *dev, void *data)

Maybe it's better to mark `data` as `__maybe_unused`?

> +{
> +       struct tb_switch *sw;
> +
> +       sw = tb_to_switch(dev);
> +       if (sw && sw->authorized) {
> +               int ret;
> +
> +               /* First children */
> +               ret = device_for_each_child_reverse(&sw->dev, NULL, disapprove_switch);
> +               if (ret)
> +                       return ret;
> +
> +               ret = tb_domain_disapprove_switch(sw->tb, sw);
> +               if (ret)
> +                       return ret;
> +
> +               sw->authorized = 0;
> +               kobject_uevent(&sw->dev.kobj, KOBJ_CHANGE);
> +       }
> +
> +       return 0;
> +}
> +
Mika Westerberg Jan. 5, 2021, 4:36 p.m. UTC | #3
Hi,

On Tue, Jan 05, 2021 at 03:53:33PM +0200, Yehezkel Bernat wrote:
> On Tue, Jan 5, 2021 at 11:28 AM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > In some cases it is useful to be able de-authorize devices. For example
> > if user logs out the userspace can have a policy that disconnects PCIe
> > devices until logged in again. This is only possible for software based
> > connection manager as it directly controls the tunnels.
> >
> > For this reason make the authorized attribute accept writing 0 which
> > makes the software connection manager to tear down the corresponding
> > PCIe tunnel. Userspace can check if this is supported by reading a new
> > domain attribute deauthorization, that holds 1 in that case.
> 
> What a great feature! Thanks for implementing it.
> 
> BTW, is there any general way to disable the device operations before such a
> disconnection? The user has a way to stop removable disks, for example, but
> maybe other devices need additional precaution from the user (eGPU?).

There are ways but it depends on the driver, I guess. For instance eGPUS
at the moment (the ones I've tested) simply crash as their driver does
not support hot-remove ;-)

What ends up happening is essentially PCIe hot-remove so drivers that
are prepared for that should be fine. Of course if you had mounted
filesystem behind the PCIe link that was torn down you end up losing
your data, so the user interface should make sure the user is aware of
that.

> >                 Possible values are supported:
> >
> > -               ==  ===========================================
> > +               ==  ===================================================
> > +               0   The device will be de-authorized (only supported if
> > +                   deauthorization attribute under domain contains 1)
> >                 1   The device will be authorized and connected
> > -               ==  ===========================================
> > +               ==  ===================================================
> >
> >                 When key attribute contains 32 byte hex string the possible
> >                 values are:
> 
> As 0 is available for 'secure' security level too, you may want to reflect it in
> the documentation here somehow.

OK.

> > +static int disapprove_switch(struct device *dev, void *data)
> 
> Maybe it's better to mark `data` as `__maybe_unused`?

Or rename `data` as `unused`? I think in ACPI side we are doing that
but sure, I'll change it.
Limonciello, Mario Jan. 5, 2021, 4:48 p.m. UTC | #4
> -----Original Message-----
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> Sent: Tuesday, January 5, 2021 10:36
> To: Yehezkel Bernat
> Cc: linux-usb@vger.kernel.org; Michael Jamet; Lukas Wunner; Andreas Noever;
> Christian Kellner; Limonciello, Mario
> Subject: Re: [PATCH 2/2] thunderbolt: Add support for de-authorizing devices
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> On Tue, Jan 05, 2021 at 03:53:33PM +0200, Yehezkel Bernat wrote:
> > On Tue, Jan 5, 2021 at 11:28 AM Mika Westerberg
> > <mika.westerberg@linux.intel.com> wrote:
> > >
> > > In some cases it is useful to be able de-authorize devices. For example
> > > if user logs out the userspace can have a policy that disconnects PCIe
> > > devices until logged in again. This is only possible for software based
> > > connection manager as it directly controls the tunnels.
> > >
> > > For this reason make the authorized attribute accept writing 0 which
> > > makes the software connection manager to tear down the corresponding
> > > PCIe tunnel. Userspace can check if this is supported by reading a new
> > > domain attribute deauthorization, that holds 1 in that case.

Just another idea, rather than the value of a new "deauthorize" attribute indicating
whether this is supported how about instead a "connection_manager" attribute?

My thought being userspace can potentially make a judgement call from the information
on how tunnels are going to behave (particularly in long chains from the suspend/resume
cycle coming back differently).

> >
> > What a great feature! Thanks for implementing it.

I agree, this sounds like a great idea.

> >
> > BTW, is there any general way to disable the device operations before such a
> > disconnection? The user has a way to stop removable disks, for example, but
> > maybe other devices need additional precaution from the user (eGPU?).
> 
> There are ways but it depends on the driver, I guess. For instance eGPUS
> at the moment (the ones I've tested) simply crash as their driver does
> not support hot-remove ;-)
> 
> What ends up happening is essentially PCIe hot-remove so drivers that
> are prepared for that should be fine. Of course if you had mounted
> filesystem behind the PCIe link that was torn down you end up losing
> your data, so the user interface should make sure the user is aware of
> that.

I think it's also worth mentioning this risk in the thunderbolt.rst documentation
directly.

> 
> > >                 Possible values are supported:
> > >
> > > -               ==  ===========================================
> > > +               ==  ===================================================
> > > +               0   The device will be de-authorized (only supported if
> > > +                   deauthorization attribute under domain contains 1)
> > >                 1   The device will be authorized and connected
> > > -               ==  ===========================================
> > > +               ==  ===================================================
> > >
> > >                 When key attribute contains 32 byte hex string the
> possible
> > >                 values are:
> >
> > As 0 is available for 'secure' security level too, you may want to reflect
> it in
> > the documentation here somehow.
> 
> OK.
> 
> > > +static int disapprove_switch(struct device *dev, void *data)
> >
> > Maybe it's better to mark `data` as `__maybe_unused`?
> 
> Or rename `data` as `unused`? I think in ACPI side we are doing that
> but sure, I'll change it.
Mika Westerberg Jan. 5, 2021, 5:06 p.m. UTC | #5
On Tue, Jan 05, 2021 at 04:48:23PM +0000, Limonciello, Mario wrote:
> > -----Original Message-----
> > From: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Sent: Tuesday, January 5, 2021 10:36
> > To: Yehezkel Bernat
> > Cc: linux-usb@vger.kernel.org; Michael Jamet; Lukas Wunner; Andreas Noever;
> > Christian Kellner; Limonciello, Mario
> > Subject: Re: [PATCH 2/2] thunderbolt: Add support for de-authorizing devices
> > 
> > 
> > [EXTERNAL EMAIL]
> > 
> > Hi,
> > 
> > On Tue, Jan 05, 2021 at 03:53:33PM +0200, Yehezkel Bernat wrote:
> > > On Tue, Jan 5, 2021 at 11:28 AM Mika Westerberg
> > > <mika.westerberg@linux.intel.com> wrote:
> > > >
> > > > In some cases it is useful to be able de-authorize devices. For example
> > > > if user logs out the userspace can have a policy that disconnects PCIe
> > > > devices until logged in again. This is only possible for software based
> > > > connection manager as it directly controls the tunnels.
> > > >
> > > > For this reason make the authorized attribute accept writing 0 which
> > > > makes the software connection manager to tear down the corresponding
> > > > PCIe tunnel. Userspace can check if this is supported by reading a new
> > > > domain attribute deauthorization, that holds 1 in that case.
> 
> Just another idea, rather than the value of a new "deauthorize" attribute indicating
> whether this is supported how about instead a "connection_manager" attribute?
> 
> My thought being userspace can potentially make a judgement call from the information
> on how tunnels are going to behave (particularly in long chains from the suspend/resume
> cycle coming back differently).

I went for "deauthorization" because that kind of allows this to work on
systems with firmware based connection manager too (yes, Intel Maple
Ridge is using FW CM even if it is USB4 :( ). However, at the moment the
FW CM does not support any if this but nobody knows if something like
this will be implemented there.

That said, I'm fine to change this to whatever you guys think is the
best :) If "connection_manager=sw/fw" or so is better then no problem
changing that.

> > > What a great feature! Thanks for implementing it.
> 
> I agree, this sounds like a great idea.
> 
> > >
> > > BTW, is there any general way to disable the device operations before such a
> > > disconnection? The user has a way to stop removable disks, for example, but
> > > maybe other devices need additional precaution from the user (eGPU?).
> > 
> > There are ways but it depends on the driver, I guess. For instance eGPUS
> > at the moment (the ones I've tested) simply crash as their driver does
> > not support hot-remove ;-)
> > 
> > What ends up happening is essentially PCIe hot-remove so drivers that
> > are prepared for that should be fine. Of course if you had mounted
> > filesystem behind the PCIe link that was torn down you end up losing
> > your data, so the user interface should make sure the user is aware of
> > that.
> 
> I think it's also worth mentioning this risk in the thunderbolt.rst documentation
> directly.

Sure, I'll add there mention about this.
Mika Westerberg Jan. 11, 2021, 2:22 p.m. UTC | #6
On Tue, Jan 05, 2021 at 03:35:27PM +0200, Yehezkel Bernat wrote:
> On Tue, Jan 5, 2021 at 11:28 AM Mika Westerberg

> <mika.westerberg@linux.intel.com> wrote:

> >

> > USB4 spec says that for TBT3 compatible device routers the connection

> > manager needs to set SLI (Start Lane Initialization) to get the lanes

> > that were not connected back to functional state after sleep. Same needs

> > to be done if the link was XDomain.

> >

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

> > ---

> >  drivers/thunderbolt/lc.c      | 35 +++++++++++++++++++++++++++++++++++

> >  drivers/thunderbolt/switch.c  | 27 ++++++++++++++++++++++++++-

> >  drivers/thunderbolt/tb.h      |  1 +

> >  drivers/thunderbolt/tb_regs.h |  1 +

> >  4 files changed, 63 insertions(+), 1 deletion(-)

> >

> 

> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>


Applied to thunderbolt.git/next.
diff mbox series

Patch

diff --git a/drivers/thunderbolt/lc.c b/drivers/thunderbolt/lc.c
index 41e6c738f6c8..bc671730a11f 100644
--- a/drivers/thunderbolt/lc.c
+++ b/drivers/thunderbolt/lc.c
@@ -158,6 +158,41 @@  void tb_lc_unconfigure_xdomain(struct tb_port *port)
 	tb_lc_set_xdomain_configured(port, false);
 }
 
+/**
+ * tb_lc_start_lane_initialization() - Start lane initialization
+ * @port: Device router lane 0 adapter
+ *
+ * Starts lane initialization for @port after the router resumed from
+ * sleep. Should be called for those downstream lane adapters that were
+ * not connected (tb_lc_configure_port() was not called) before sleep.
+ *
+ * Returns %0 in success and negative errno in case of failure.
+ */
+int tb_lc_start_lane_initialization(struct tb_port *port)
+{
+	struct tb_switch *sw = port->sw;
+	int ret, cap;
+	u32 ctrl;
+
+	if (!tb_route(sw))
+		return 0;
+
+	if (sw->generation < 2)
+		return 0;
+
+	cap = find_port_lc_cap(port);
+	if (cap < 0)
+		return cap;
+
+	ret = tb_sw_read(sw, &ctrl, TB_CFG_SWITCH, cap + TB_LC_SX_CTRL, 1);
+	if (ret)
+		return ret;
+
+	ctrl |= TB_LC_SX_CTRL_SLI;
+
+	return tb_sw_write(sw, &ctrl, TB_CFG_SWITCH, cap + TB_LC_SX_CTRL, 1);
+}
+
 static int tb_lc_set_wake_one(struct tb_switch *sw, unsigned int offset,
 			      unsigned int flags)
 {
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index a8572f49d3ad..e7e6726ff5d1 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -1065,6 +1065,17 @@  void tb_port_lane_bonding_disable(struct tb_port *port)
 	tb_port_set_link_width(port, 1);
 }
 
+static int tb_port_start_lane_initialization(struct tb_port *port)
+{
+	int ret;
+
+	if (tb_switch_is_usb4(port->sw))
+		return 0;
+
+	ret = tb_lc_start_lane_initialization(port);
+	return ret == -EINVAL ? 0 : ret;
+}
+
 /**
  * tb_port_is_enabled() - Is the adapter port enabled
  * @port: Port to check
@@ -2694,8 +2705,22 @@  int tb_switch_resume(struct tb_switch *sw)
 
 	/* check for surviving downstream switches */
 	tb_switch_for_each_port(sw, port) {
-		if (!tb_port_has_remote(port) && !port->xdomain)
+		if (!tb_port_has_remote(port) && !port->xdomain) {
+			/*
+			 * For disconnected downstream lane adapters
+			 * start lane initialization now so we detect
+			 * future connects.
+			 */
+			if (!tb_is_upstream_port(port) && tb_port_is_null(port))
+				tb_port_start_lane_initialization(port);
 			continue;
+		} else if (port->xdomain) {
+			/*
+			 * Start lane initialization for XDomain so the
+			 * link gets re-established.
+			 */
+			tb_port_start_lane_initialization(port);
+		}
 
 		if (tb_wait_for_port(port, true) <= 0) {
 			tb_port_warn(port,
diff --git a/drivers/thunderbolt/tb.h b/drivers/thunderbolt/tb.h
index 554feda1e359..34ae83b9e52a 100644
--- a/drivers/thunderbolt/tb.h
+++ b/drivers/thunderbolt/tb.h
@@ -923,6 +923,7 @@  int tb_lc_configure_port(struct tb_port *port);
 void tb_lc_unconfigure_port(struct tb_port *port);
 int tb_lc_configure_xdomain(struct tb_port *port);
 void tb_lc_unconfigure_xdomain(struct tb_port *port);
+int tb_lc_start_lane_initialization(struct tb_port *port);
 int tb_lc_set_wake(struct tb_switch *sw, unsigned int flags);
 int tb_lc_set_sleep(struct tb_switch *sw);
 bool tb_lc_lane_bonding_possible(struct tb_switch *sw);
diff --git a/drivers/thunderbolt/tb_regs.h b/drivers/thunderbolt/tb_regs.h
index ae427a953489..626751e06292 100644
--- a/drivers/thunderbolt/tb_regs.h
+++ b/drivers/thunderbolt/tb_regs.h
@@ -464,6 +464,7 @@  struct tb_regs_hop {
 #define TB_LC_SX_CTRL_L1D		BIT(17)
 #define TB_LC_SX_CTRL_L2C		BIT(20)
 #define TB_LC_SX_CTRL_L2D		BIT(21)
+#define TB_LC_SX_CTRL_SLI		BIT(29)
 #define TB_LC_SX_CTRL_UPSTREAM		BIT(30)
 #define TB_LC_SX_CTRL_SLP		BIT(31)