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]
Message-ID: <CACeCKacWhrZE6LFFwF=vDO8362u9feN71pPO8Qr8XoaRgwj5uw@mail.gmail.com>
Date:   Mon, 21 Aug 2023 16:30:36 -0700
From:   Prashant Malani <pmalani@...omium.org>
To:     "Patel, Utkarsh H" <utkarsh.h.patel@...el.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "heikki.krogerus@...ux.intel.com" <heikki.krogerus@...ux.intel.com>,
        "bleung@...omium.org" <bleung@...omium.org>
Subject: Re: [PATCH v4 1/2] platform/chrome: cros_ec_typec: Configure Retimer
 cable type

On Mon, Aug 21, 2023 at 10:18 AM Patel, Utkarsh H
<utkarsh.h.patel@...el.com> wrote:
>
> Hi Prashant,
>
> Thank you for the review.
>
> > -----Original Message-----
> > From: Prashant Malani <pmalani@...omium.org>
> > Sent: Friday, August 18, 2023 10:02 AM
> > To: Patel, Utkarsh H <utkarsh.h.patel@...el.com>
> > Cc: linux-kernel@...r.kernel.org; linux-usb@...r.kernel.org;
> > heikki.krogerus@...ux.intel.com; bleung@...omium.org
> > Subject: Re: [PATCH v4 1/2] platform/chrome: cros_ec_typec: Configure
> > Retimer cable type
> >
> > >  /*
> > >   * Spoof the VDOs that were likely communicated by the partner for TBT alt
> > >   * mode.
> > > @@ -432,6 +453,9 @@ static int cros_typec_enable_tbt(struct
> > > cros_typec_data *typec,
> > >
> > >     /* Cable Discover Mode VDO */
> > >     data.cable_mode = TBT_MODE;
> > > +
> > > +   data.cable_mode |= cros_typec_get_cable_vdo(port,
> > > +USB_TYPEC_TBT_SID);
> > > +

Here is the first call to cros_typec_get_cable_vdo(port, TBT)....

> > >     data.cable_mode |= TBT_SET_CABLE_SPEED(pd_ctrl->cable_speed);
> > >
> > >     if (pd_ctrl->control_flags & USB_PD_CTRL_OPTICAL_CABLE) @@ -
> > 522,8
> > > +546,10 @@ static int cros_typec_enable_usb4(struct cros_typec_data
> > *typec,
> > >     /* Cable Type */
> > >     if (pd_ctrl->control_flags & USB_PD_CTRL_OPTICAL_CABLE)
> > >             data.eudo |= EUDO_CABLE_TYPE_OPTICAL <<
> > EUDO_CABLE_TYPE_SHIFT;
> > > -   else if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_CABLE)
> > > +   else if (cros_typec_get_cable_vdo(port, USB_TYPEC_TBT_SID) &
> > > +TBT_CABLE_RETIMER)

And here is the 2nd.

> > >             data.eudo |= EUDO_CABLE_TYPE_RE_TIMER <<
> > EUDO_CABLE_TYPE_SHIFT;
> > We shouldn't need to call cros_typec_get_cable_vdo more than once. Either
> > call it once earlier when you are crafting the data.cable_mode member and
> > then re-use that variable here. Or don't call it there and just call it here.
>
> We are only calling it once depending upon which mode we enter TBT Alt or USB4.

There should only be 1 "call site" and that should be sufficient to
grab the VDO from the
framework for all circumstances. Whether the other invocation doesn't get called
under certain circumstances isn't as relevant.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ