linux-kernel - Re: [PATCH] usb: typec: tcpm: Create legacy PDOs for PD2 connection

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] [day] [month] [year] [list]

Message-ID: <20210125092156.GA1720720@kuha.fi.intel.com>
Date:   Mon, 25 Jan 2021 11:21:56 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Kyle Tso <kyletso@...gle.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        Badhri Jagan Sridharan <badhri@...gle.com>,
        USB <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: typec: tcpm: Create legacy PDOs for PD2 connection

Hi,

On Thu, Jan 21, 2021 at 05:48:46PM +0800, Kyle Tso wrote:
> On Thu, Jan 21, 2021 at 4:41 PM Heikki Krogerus
> <heikki.krogerus@...ux.intel.com> wrote:
> >
> > Hi Kyle,
> >
> > On Sat, Jan 16, 2021 at 12:33:11AM +0800, Kyle Tso wrote:
> > > If the port partner is PD2, the PDOs of the local port should follow the
> > > format defined in PD2 Spec. Dynamically modify the pre-defined PD3 PDOs
> > > and transform them into PD2 format before sending them to the PD2 port
> > > partner.
> >
> > I guess it's not possible for the system to supply separate static
> > PDOs for each PD revision?
> >
> We can do that for sure. But a problem is that if there are more PD
> revisions in the future, we will need to add more PDO arrays.
> For backward compatibility, the new revision usually uses the
> previously-reserved bits for the new features.
> >From my perspective, the better way to achieve the backward
> compatibility is to just clear the bits if those are reserved in the
> previous revision.

I was trying to think of something better for this, but I got nothing.
I'm not completely comfortable with this, but never mind. Let's just go
with this.

> I can submit another patch which adds another PDO array for PD2 if you
> think it is more appropriate.

Not necessary.

Reviewed-by: Heikki Krogerus <heikki.krogerus@...ux.intel.com>

> > > Signed-off-by: Kyle Tso <kyletso@...gle.com>
> > > ---
> > >  drivers/usb/typec/tcpm/tcpm.c | 62 +++++++++++++++++++++++++++++------
> > >  include/linux/usb/pd.h        |  1 +
> > >  2 files changed, 53 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> > > index 22a85b396f69..1220ab1ed47d 100644
> > > --- a/drivers/usb/typec/tcpm/tcpm.c
> > > +++ b/drivers/usb/typec/tcpm/tcpm.c
> > > @@ -911,13 +911,47 @@ static int tcpm_set_pwr_role(struct tcpm_port *port, enum typec_role role)
> > >       return 0;
> > >  }
> > >
> > > +/*
> > > + * Transform the PDO to be compliant to PD rev2.0.
> > > + * Return 0 if the PDO type is not defined in PD rev2.0.
> > > + * Otherwise, return the converted PDO.
> > > + */
> > > +static u32 tcpm_forge_legacy_pdo(struct tcpm_port *port, u32 pdo, enum typec_role role)
> > > +{
> > > +     switch (pdo_type(pdo)) {
> > > +     case PDO_TYPE_FIXED:
> > > +             if (role == TYPEC_SINK)
> > > +                     return pdo & ~PDO_FIXED_FRS_CURR_MASK;
> > > +             else
> > > +                     return pdo & ~PDO_FIXED_UNCHUNK_EXT;
> > > +     case PDO_TYPE_VAR:
> > > +     case PDO_TYPE_BATT:
> > > +             return pdo;
> > > +     case PDO_TYPE_APDO:
> > > +     default:
> > > +             return 0;
> > > +     }
> > > +}
> > > +
> > >  static int tcpm_pd_send_source_caps(struct tcpm_port *port)
> > >  {
> > >       struct pd_message msg;
> > > -     int i;
> > > +     u32 pdo;
> > > +     unsigned int i, nr_pdo = 0;
> >
> > Side note. I think this driver uses the "reverse christmas tree"
> > style with the variables.
> 
> I will change the order (if there is a next version)
> 
> thanks,
> Kyle

-- 
heikki