linux-kernel - RE: [PATCH v2 6/8] platform/chrome: cros_ec_typec: Use Thunderbolt 3 cable discover mode VDO in USB4 mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 Nov 2020 04:07:13 +0000
From:   "Patel, Utkarsh H" <utkarsh.h.patel@...el.com>
To:     Prashant Malani <pmalani@...omium.org>
CC:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:USB NETWORKING DRIVERS" <linux-usb@...r.kernel.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        "Mani, Rajmohan" <rajmohan.mani@...el.com>,
        "Shaikh, Azhar" <azhar.shaikh@...el.com>
Subject: RE: [PATCH v2 6/8] platform/chrome: cros_ec_typec: Use Thunderbolt 3
 cable discover mode VDO in USB4 mode

Hi Prashant,

Thank you for the review and feedback. 

> On Tue, Nov 17, 2020 at 10:19 AM Prashant Malani <pmalani@...omium.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@...ux.intel.com>
> > > Signed-off-by: Utkarsh Patel <utkarsh.h.patel@...el.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.