All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yehezkel Bernat <yehezkelshb@gmail.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Lukas Wunner <lukas@wunner.de>,
	USB list <linux-usb@vger.kernel.org>,
	Michael Jamet <michael.jamet@intel.com>,
	Gil Fine <gil.fine@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Andreas Noever <andreas.noever@gmail.com>
Subject: Re: [PATCH 2/6] thunderbolt: Tear down existing tunnels when resuming from hibernate
Date: Fri, 3 Dec 2021 13:39:49 +0200	[thread overview]
Message-ID: <CA+CmpXsCWknnXfxXo8cnVdk-1rrtbVmJ0J0tVbV2O6+YdWbtEA@mail.gmail.com> (raw)
In-Reply-To: <YacaZaTWr3Tyivu8@lahna>

On Wed, Dec 1, 2021 at 8:47 AM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> Hi,
>
> > > > > 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.
> > > >
> > > > Hm, what if the system is running from a Thunderbolt-attached drive?
> > > > Will the mount points survive tearing down and re-establishing the
> > > > tunnels to that drive?
> > >
> > > Yes, they should. PCI is waiting for the TBT to resume so it should not
> > > notice this, and all the data is at point still synced out to the disks.
> >
> > But the user will notice the screen flashing, probably?
>
> They will notice flashing anyway because we jump from one kernel to
> another (as this is suspend-to-disk which involves shutting down the
> machine and booting to "fresh" resume kernel first). We actually tear
> down all the DP tunnels before we even enter suspend-to-disk (see
> 81a2e3e49f1f ("thunderbolt: Tear down DP tunnels when suspending")).
>

Ah, thanks.

> > Is this because the FW might not support the same set of functionality?
>
> Yes, that too.

OK

> > Maybe we can continue using the already established tunnels after
> > discovering them?
>
> Yes we could but that would require us to map the existing tunnels with
> the ones we had prior, and also indentify any new tunnels or missing
> ones. This makes it more complex, and the approach here seem to work
> according to my testing :) I can look for that solution too if you think
> it is necessary.

Following the previous points, I don't see any value in trying the
more complex solution.
Thanks!

  reply	other threads:[~2021-12-03 11:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-25  7:37 [PATCH 0/6] thunderbolt: Improvements for PM and USB4 compatibility Mika Westerberg
2021-11-25  7:37 ` [PATCH 1/6] thunderbolt: Runtime PM activate both ends of the device link Mika Westerberg
2021-11-26 18:03   ` Rafael J. Wysocki
2021-11-25  7:37 ` [PATCH 2/6] thunderbolt: Tear down existing tunnels when resuming from hibernate Mika Westerberg
2021-11-26 20:01   ` Lukas Wunner
2021-11-29  6:27     ` Mika Westerberg
2021-11-30 18:25       ` Yehezkel Bernat
2021-12-01  6:47         ` Mika Westerberg
2021-12-03 11:39           ` Yehezkel Bernat [this message]
2021-11-25  7:37 ` [PATCH 3/6] thunderbolt: Runtime resume USB4 port when retimers are scanned Mika Westerberg
2021-11-25  7:37 ` [PATCH 4/6] thunderbolt: Do not allow subtracting more NFC credits than configured Mika Westerberg
2021-11-25  7:37 ` [PATCH 5/6] thunderbolt: Do not program path HopIDs for USB4 routers Mika Westerberg
2021-11-25  7:37 ` [PATCH 6/6] thunderbolt: Add debug logging of DisplayPort resource allocation Mika Westerberg
2021-12-07 12:22 ` [PATCH 0/6] thunderbolt: Improvements for PM and USB4 compatibility Mika Westerberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+CmpXsCWknnXfxXo8cnVdk-1rrtbVmJ0J0tVbV2O6+YdWbtEA@mail.gmail.com \
    --to=yehezkelshb@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=gil.fine@intel.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=michael.jamet@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.