linux-kernel - RE: [PATCH v4 1/2] platform/chrome: cros_ec

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: <MWHPR11MB0048018BB93C531401D00EF9A91FA@MWHPR11MB0048.namprd11.prod.outlook.com>
Date:   Tue, 22 Aug 2023 21:21:55 +0000
From:   "Patel, Utkarsh H" <utkarsh.h.patel@...el.com>
To:     Prashant Malani <pmalani@...omium.org>
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

Hi Prashant,

> -----Original Message-----
> From: Prashant Malani <pmalani@...omium.org>
> Sent: Monday, August 21, 2023 4:31 PM
> 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
> 
> On Mon, Aug 21, 2023 at 10:18 AM Patel, Utkarsh H
> <utkarsh.h.patel@...el.com> wrote:
> > > >  /*
> > > >   * 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.

Are you suggesting something like this?

static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,)...

	if (port->mux_flags & USB_PD_MUX_USB4_ENABLED ||
		port->mux_flags & USB_PD_MUX_TBT_COMPAT_ENABLED)
		cable_tbt_vdo = cros_typec_get_cable_vdo(port, USB_TYPEC_TBT_SID);

Sincerely,
Utkarsh Patel.