linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Patel, Utkarsh H" <utkarsh.h.patel@intel.com>
To: Prashant Malani <pmalani@chromium.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:USB NETWORKING DRIVERS" <linux-usb@vger.kernel.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	"Mani, Rajmohan" <rajmohan.mani@intel.com>,
	"Shaikh, Azhar" <azhar.shaikh@intel.com>
Subject: RE: [PATCH v2 6/8] platform/chrome: cros_ec_typec: Use Thunderbolt 3 cable discover mode VDO in USB4 mode
Date: Wed, 18 Nov 2020 04:07:13 +0000	[thread overview]
Message-ID: <MWHPR11MB0048EBE0C9E0CCC44E79D7B0A9E10@MWHPR11MB0048.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CACeCKacedkvQDq7pJm7G5qbu__5PerUkTK5DjtWy5StMShSB3w@mail.gmail.com>

Hi Prashant,

Thank you for the review and feedback. 

> On Tue, Nov 17, 2020 at 10:19 AM Prashant Malani <pmalani@chromium.org>
> wrote:
> >
> > Hi Utkarsh,
> >
> > On Fri, Nov 13, 2020 at 12:25:01PM -0800, Utkarsh Patel wrote:
> > > Configure Thunderbolt3/USB4 cable generation value by filing
> > > Thunderbolt 3 cable discover mode VDO to support rounded and
> > > non-rounded Thunderbolt3/
> > > USB4 cables.
> > > While we are here use Thunderbolt 3 cable discover mode VDO to fill
> > > active cable plug link training value.
> > >
> > > Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > > Signed-off-by: Utkarsh Patel <utkarsh.h.patel@intel.com>
> > >
> > > --
> > > Changes in v2:
> > > - No change.
> > > --
> > > ---
> > >  drivers/platform/chrome/cros_ec_typec.c | 14 ++++++++++++--
> > >  1 file changed, 12 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/platform/chrome/cros_ec_typec.c
> > > b/drivers/platform/chrome/cros_ec_typec.c
> > > index 8111ed1fc574..b7416e82c3b3 100644
> > > --- a/drivers/platform/chrome/cros_ec_typec.c
> > > +++ b/drivers/platform/chrome/cros_ec_typec.c
> > > @@ -514,8 +514,18 @@ static int cros_typec_enable_usb4(struct
> cros_typec_data *typec,
> > >       else if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_CABLE)
> > >               data.eudo |= EUDO_CABLE_TYPE_RE_TIMER <<
> > > EUDO_CABLE_TYPE_SHIFT;
> > >
> > > -     data.active_link_training = !!(pd_ctrl->control_flags &
> > > -                                    USB_PD_CTRL_ACTIVE_LINK_UNIDIR);
> > > +     /*
> > > +      * This driver does not have access to the identity information or
> > > +      * capabilities of the cable, so we don't know is it a real USB4 or
> > > +      * TBT3 cable. Therefore pretending that it's always TBT3 cable by
> > > +      * filling the TBT3 Cable VDO.
> > > +      */
> > > +     data.tbt_cable_vdo = TBT_MODE;
> >
> > Is it safe to be making this assumption unconditionally? It might work
> > for Intel Mux agent but is it guaranteed to be safe for any other
> > future mux implementation? In other words, what if a "true" USB4 cable
> > is connected which doesn't have the Thunderbolt SVID alt mode?
> 
> I dug into this a bit more and can maybe articulate my concern better:
> 
> Is there a situation where both of the following are true ? :
> - Cable type = EUDO_CABLE_TYPE_OPTICAL or EUDO_CABLE_TYPE_RE_TIMER
> - No TBT_CABLE_LINK_TRAINING or TBT_CABLE_ROUNDED_SUPPORT defined
> (both
>   these are 0).

No, not in the case of USB4. 

> 
> If both the above are true, then in Patch 7/8, wouldn't we never hit the else
> condition (labeled "Active USB cable") and therefore not set the mode_data
> correctly?
> 
> >
> > (Pre-fetching some alternatives in case the answer is no)
> >
> > You might want to check with the Cros EC team if you can repurpose a
> > bit of the "reserved" field for specifying whether the cable is TBT or not.
> >
> > Either that or see if there is a way to determine from the
> > pd_ctrl->cable_speed whether the cable is actually TBT or not.
> 
> It seems link cable_gen and USB_PD_CTRL_ACTIVE_LINK_UNIDIR are
> reasonable proxies for whether the cable has TBT support, so perhaps we
> should only set tbt_cable_vdo = TBT_MODE if either of those are non-zero?
> 
> WDYT?

Since we do not have these information available with USB4 cables, we can use them to check for TBT support and then set tbt_cable_vdo. 

> 
> Best regards,
> 
> -Prashant

Sincerely,
Utkarsh Patel. 

  reply	other threads:[~2020-11-18  4:07 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 20:24 [PATCH v2 0/8] Thunderbolt3/USB4 cable rounded and active cable plug link training support Utkarsh Patel
2020-11-13 20:24 ` [PATCH v2 1/8] usb: typec: Correct the bit values for the Thunderbolt rounded/non-rounded cable support Utkarsh Patel
2020-11-17 10:43   ` Heikki Krogerus
2020-11-13 20:24 ` [PATCH v2 2/8] platform/chrome: cros_ec_typec: Correct " Utkarsh Patel
2020-11-17 10:44   ` Heikki Krogerus
2020-11-17 10:49   ` Enric Balletbo i Serra
2020-11-13 20:24 ` [PATCH v2 3/8] usb: typec: intel_pmc_mux: Configure Thunderbolt cable generation bits Utkarsh Patel
2020-11-17 10:45   ` Heikki Krogerus
2020-11-13 20:24 ` [PATCH v2 4/8] usb: typec: Remove one bit support for the Thunderbolt rounded/non-rounded cable Utkarsh Patel
2020-11-17 10:46   ` Heikki Krogerus
2020-11-13 20:25 ` [PATCH v2 5/8] usb: typec: Use Thunderbolt 3 cable discover mode VDO in Enter_USB message Utkarsh Patel
2020-11-17 12:09   ` Heikki Krogerus
2020-11-17 23:28     ` Patel, Utkarsh H
2020-11-17 21:16   ` Prashant Malani
2020-11-18  0:44     ` Prashant Malani
2020-11-13 20:25 ` [PATCH v2 6/8] platform/chrome: cros_ec_typec: Use Thunderbolt 3 cable discover mode VDO in USB4 mode Utkarsh Patel
2020-11-17 10:49   ` Enric Balletbo i Serra
2020-11-17 12:10   ` Heikki Krogerus
2020-11-17 18:19   ` Prashant Malani
2020-11-18  1:06     ` Prashant Malani
2020-11-18  4:07       ` Patel, Utkarsh H [this message]
2020-11-13 20:25 ` [PATCH v2 7/8] usb: typec: intel_pmc_mux: Configure active cable properties for USB4 Utkarsh Patel
2020-11-17 12:21   ` Heikki Krogerus
2020-11-17 22:37     ` Patel, Utkarsh H
2020-11-13 20:25 ` [PATCH v2 8/8] usb: typec: Remove active_link_training variable from Enter_USB message Utkarsh Patel
2020-11-17 12:22   ` Heikki Krogerus
2020-11-18 11:54 ` [PATCH v2 0/8] Thunderbolt3/USB4 cable rounded and active cable plug link training support Greg KH
2020-11-18 22:02   ` Patel, Utkarsh H

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=MWHPR11MB0048EBE0C9E0CCC44E79D7B0A9E10@MWHPR11MB0048.namprd11.prod.outlook.com \
    --to=utkarsh.h.patel@intel.com \
    --cc=azhar.shaikh@intel.com \
    --cc=enric.balletbo@collabora.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pmalani@chromium.org \
    --cc=rajmohan.mani@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).