[PATCH 0/1] thunderbolt: Fix for v4.20-rc5

[PATCH 0/1] thunderbolt: Fix for v4.20-rc5

[Mika Westerberg]

Hi Greg,

Please pull one fix for Thunderbolt that makes NVM upgrade work better on
systems that support runtime PM for the PCIe root port. I've also included
the patch in case you want to apply it directly.

Thanks!

The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:

  Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git tags/thunderbolt-fix-for-v4.20-rc5

for you to fetch changes up to 1f23f28d085d318789596b8616f161350b0ecfc9:

  thunderbolt: Prevent root port runtime suspend during NVM upgrade (2018-11-15 13:28:09 +0300)

----------------------------------------------------------------
thunderbolt: Fix for v4.20-rc5

----------------------------------------------------------------

Mika Westerberg (1):
  thunderbolt: Prevent root port runtime suspend during NVM upgrade

 drivers/thunderbolt/switch.c | 40 ++++++++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

-- 
2.19.1

[PATCH 1/1] thunderbolt: Prevent root port runtime suspend during NVM upgrade

[Mika Westerberg]

During NVM upgrade process the host router is hot-removed for a short
while. During this time it is possible that the root port is moved into
D3cold which would be fine if the root port could trigger PME on itself.
However, many systems actually do not implement it so what happens is
that the root port goes into D3cold and never wakes up unless userspace
does PCI config space access, such as running 'lscpi'.

For this reason we explicitly prevent the root port from runtime
suspending during NVM upgrade.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/thunderbolt/switch.c | 40 ++++++++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 52ff854f0d6c..cd96994dc094 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -863,6 +863,30 @@ static ssize_t key_store(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR(key, 0600, key_show, key_store);
 
+static void nvm_authenticate_start(struct tb_switch *sw)
+{
+	struct pci_dev *root_port;
+
+	/*
+	 * During host router NVM upgrade we should not allow root port to
+	 * go into D3cold because some root ports cannot trigger PME
+	 * itself. To be on the safe side keep the root port in D0 during
+	 * the whole upgrade process.
+	 */
+	root_port = pci_find_pcie_root_port(sw->tb->nhi->pdev);
+	if (root_port)
+		pm_runtime_get_noresume(&root_port->dev);
+}
+
+static void nvm_authenticate_complete(struct tb_switch *sw)
+{
+	struct pci_dev *root_port;
+
+	root_port = pci_find_pcie_root_port(sw->tb->nhi->pdev);
+	if (root_port)
+		pm_runtime_put(&root_port->dev);
+}
+
 static ssize_t nvm_authenticate_show(struct device *dev,
 	struct device_attribute *attr, char *buf)
 {
@@ -912,10 +936,18 @@ static ssize_t nvm_authenticate_store(struct device *dev,
 
 		sw->nvm->authenticating = true;
 
-		if (!tb_route(sw))
+		if (!tb_route(sw)) {
+			/*
+			 * Keep root port from suspending as long as the
+			 * NVM upgrade process is running.
+			 */
+			nvm_authenticate_start(sw);
 			ret = nvm_authenticate_host(sw);
-		else
+			if (ret)
+				nvm_authenticate_complete(sw);
+		} else {
 			ret = nvm_authenticate_device(sw);
+		}
 		pm_runtime_mark_last_busy(&sw->dev);
 		pm_runtime_put_autosuspend(&sw->dev);
 	}
@@ -1334,6 +1366,10 @@ static int tb_switch_add_dma_port(struct tb_switch *sw)
 	if (ret <= 0)
 		return ret;
 
+	/* Now we can allow root port to suspend again */
+	if (!tb_route(sw))
+		nvm_authenticate_complete(sw);
+
 	if (status) {
 		tb_sw_info(sw, "switch flash authentication failed\n");
 		tb_switch_set_uuid(sw);
-- 
2.19.1

Re: [PATCH 1/1] thunderbolt: Prevent root port runtime suspend during NVM upgrade

[Greg Kroah-Hartman]

On Mon, Nov 26, 2018 at 12:47:46PM +0300, Mika Westerberg wrote:
> During NVM upgrade process the host router is hot-removed for a short
> while. During this time it is possible that the root port is moved into
> D3cold which would be fine if the root port could trigger PME on itself.
> However, many systems actually do not implement it so what happens is
> that the root port goes into D3cold and never wakes up unless userspace
> does PCI config space access, such as running 'lscpi'.
> 
> For this reason we explicitly prevent the root port from runtime
> suspending during NVM upgrade.
> 
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
>  drivers/thunderbolt/switch.c | 40 ++++++++++++++++++++++++++++++++++--
>  1 file changed, 38 insertions(+), 2 deletions(-)

Is this a regression?  If so, should it go to stable kernels?

If not, and this never worked, should this just wait until 4.21-rc1?

thanks,

greg k-h

Re: [PATCH 1/1] thunderbolt: Prevent root port runtime suspend during NVM upgrade

[Mika Westerberg]

On Mon, Nov 26, 2018 at 11:46:39AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Nov 26, 2018 at 12:47:46PM +0300, Mika Westerberg wrote:
> > During NVM upgrade process the host router is hot-removed for a short
> > while. During this time it is possible that the root port is moved into
> > D3cold which would be fine if the root port could trigger PME on itself.
> > However, many systems actually do not implement it so what happens is
> > that the root port goes into D3cold and never wakes up unless userspace
> > does PCI config space access, such as running 'lscpi'.
> > 
> > For this reason we explicitly prevent the root port from runtime
> > suspending during NVM upgrade.
> > 
> > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > ---
> >  drivers/thunderbolt/switch.c | 40 ++++++++++++++++++++++++++++++++++--
> >  1 file changed, 38 insertions(+), 2 deletions(-)
> 
> Is this a regression?  If so, should it go to stable kernels?

It is not a regression.

> If not, and this never worked, should this just wait until 4.21-rc1?

Only reason I would like to have it included in v4.20 is that v4.20
started supporting PCI runtime PM for these systems so NVM upgrade would
then not work until v4.21.

But I'm fine either way and can send it to you later for v4.21 inclusion :)