From: Yehezkel Bernat <yehezkelshb@gmail.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: linux-usb@vger.kernel.org,
Michael Jamet <michael.jamet@intel.com>,
Lukas Wunner <lukas@wunner.de>,
Andreas Noever <andreas.noever@gmail.com>,
Utkarsh H Patel <utkarsh.h.patel@intel.com>
Subject: Re: [PATCH 3/3] thunderbolt: Enable/disable sideband depending on USB4 port offline mode
Date: Sun, 4 Jun 2023 12:16:18 +0300 [thread overview]
Message-ID: <CA+CmpXtNgVRrOdJyTvcyPSxa9jxkNjQvPbGtmbSickL7QFwYPA@mail.gmail.com> (raw)
In-Reply-To: <20230604051136.GQ45886@black.fi.intel.com>
On Sun, Jun 4, 2023 at 8:11 AM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> Hi,
>
> On Sat, Jun 03, 2023 at 10:24:38PM +0300, Yehezkel Bernat wrote:
> > On Fri, Jun 2, 2023 at 12:11 PM Mika Westerberg
> > <mika.westerberg@linux.intel.com> wrote:
> > >
> > > When USB4 port is in offline mode (this mean there is no device
> > > attached) we want to keep the sideband up to make it possible to
> > > communicate with the retimers. In the same way there is no need to
> > > enable sideband transactions when the USB4 port is not offline as they
> > > are already up.
> > >
> > > For this reason make the enabling/disabling depend on the USB4 port
> > > offline status.
> >
> > I'm probably missing something here, but if we don't allow disabling it when the
> > port is offline, and when the port is online the sideband is enabled, when can
> > it be disabled? If we can manually disable it when the port is online, on
> > enablement we can't assume that it's already enabled just because the port
> > is online, as we might have manually disabled it earlier.
>
> We allow disabling them when the port is online. This all basically
> separates how the device attached and non-device attached handle the
> sideband communications.
OK, but then we don't enable it back, as we assume it's enabled because the
port is online, even while the user might have disabled it earlier?
next prev parent reply other threads:[~2023-06-04 9:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 9:10 [PATCH 0/3] thunderbolt: Few improvements for retimer access Mika Westerberg
2023-06-02 9:10 ` [PATCH 1/3] thunderbolt: Read retimer NVM authentication status prior tb_retimer_set_inbound_sbtx() Mika Westerberg
2023-06-02 9:10 ` [PATCH 2/3] thunderbolt: Do not send UNSET_INBOUND_SBTX when retimer NVM authentication started Mika Westerberg
2023-06-02 9:10 ` [PATCH 3/3] thunderbolt: Enable/disable sideband depending on USB4 port offline mode Mika Westerberg
2023-06-03 19:24 ` Yehezkel Bernat
2023-06-04 5:11 ` Mika Westerberg
2023-06-04 9:16 ` Yehezkel Bernat [this message]
2023-06-05 6:19 ` Mika Westerberg
2023-06-12 5:42 ` [PATCH 0/3] thunderbolt: Few improvements for retimer access 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+CmpXtNgVRrOdJyTvcyPSxa9jxkNjQvPbGtmbSickL7QFwYPA@mail.gmail.com \
--to=yehezkelshb@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=michael.jamet@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=utkarsh.h.patel@intel.com \
/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.