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: <CANFp7mXP=aN8bQi4akKKcoMZE8RaCBuFnwTa5hbp0MZvZe0hYQ@mail.gmail.com>
Date: Wed, 24 Jan 2024 14:57:21 -0800
From: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
To: Prashant Malani <pmalani@...omium.org>
Cc: Abhishek Pandit-Subedi <abhishekpandit@...gle.com>, 
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>, linux-usb@...r.kernel.org, 
	jthies@...gle.com, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Bjorn Andersson <andersson@...nel.org>, Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, 
	Fabrice Gasnier <fabrice.gasnier@...s.st.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Hans de Goede <hdegoede@...hat.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Saranya Gopal <saranya.gopal@...el.com>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 3/3] usb: typec: ucsi: Get PD revision for partner

On Wed, Jan 24, 2024 at 11:34 AM Prashant Malani <pmalani@...omium.org> wrote:
>
> On Wed, Jan 24, 2024 at 11:18 AM Abhishek Pandit-Subedi
> <abhishekpandit@...omium.org> wrote:
> >
> > On Wed, Jan 24, 2024 at 10:49 AM Prashant Malani <pmalani@...omium.org> wrote:
> > >
> > > Hi Abhishek,
> > >
> > > On Tue, Jan 23, 2024 at 2:30 PM Abhishek Pandit-Subedi
> > > <abhishekpandit@...gle.com> wrote:
> > > >
> > > > From: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
> > > >
> > > > PD major revision for the port partner is described in
> > > > GET_CONNECTOR_CAPABILITY and is only valid on UCSI 2.0 and newer. Update
> > > > the pd_revision on the partner if the UCSI version is 2.0 or newer.
> > > >
> > > > Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
> > > > ---
> > > > $ cat /sys/class/typec/port2-partner/usb_power_delivery_revision
> > > > 3.0
> > > >
> > > >  drivers/usb/typec/ucsi/ucsi.c | 25 +++++++++++++++++++++++++
> > > >  drivers/usb/typec/ucsi/ucsi.h |  3 +++
> > > >  2 files changed, 28 insertions(+)
> > > >
> > > > diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> > > > index 4edf785d203b..8e0a512853ba 100644
> > > > --- a/drivers/usb/typec/ucsi/ucsi.c
> > > > +++ b/drivers/usb/typec/ucsi/ucsi.c
> > > > @@ -782,6 +782,8 @@ static int ucsi_register_partner(struct ucsi_connector *con)
> > > >         }
> > > >
> > > >         desc.usb_pd = pwr_opmode == UCSI_CONSTAT_PWR_OPMODE_PD;
> > > > +       desc.pd_revision =
> > > > +               UCSI_CONCAP_FLAG_PARTNER_PD_MAJOR_REV_AS_BCD(con->cap.flags);
> > > >
> > > >         partner = typec_register_partner(con->port, &desc);
> > > >         if (IS_ERR(partner)) {
> > > > @@ -856,6 +858,28 @@ static void ucsi_partner_change(struct ucsi_connector *con)
> > > >                         con->num, u_role);
> > > >  }
> > > >
> > > > +static int ucsi_check_connector_capability(struct ucsi_connector *con)
> > > > +{
> > > > +       u64 command;
> > > > +       int ret;
> > > > +
> > > > +       if (!con->partner && !IS_MIN_VERSION_2_0(con->ucsi))
> > >
> > > (Mentioned side-band but reproducing here for consistency)
> > > This macro is unnecessary. It's just doing a comparison, which can be inlined
> > > without any perceptible change in readability (actually, I'd argue adding the !
> > > to an english idiom makes things *less* readable):
> >
> > I prefer the macro because it makes it easier to search where version
> > checks are being done.
>
> I don't see how searching for "IS_MIN_VERSION_2_0" is easier
> than just searching for "UCSI_VERSION_2_0".
>
> I didn't quite understand what you meant by
>
> >  it keeps the `<` vs `<=` consistent.
>
> Perhaps I'm missing something... (are these comparisons being
> used elsewhere/in some other fashion?).

Let's say someone wants to guard code for UCSI 2.0.
Should they use:

// Guard against older versions.
if (ucsi->version < UCSI_VERSION_2_0) return;

// This also guards since the version jumps from 1.2 to 2.0.
if (ucsi->version <= UCSI_VERSION_1_2) return;

// Only do something on newer versions.
if (ucsi->version >= UCSI_VERSION_2_0) {
  // Fill out something available in newer spec.
}

I'd rather everyone just use a macro that normalizes comparisons. It's
always IS_MIN_VERSION and its inverse !IS_MIN_VERSION.
It's personal preference so deferring to the maintainer is IMO the
right call here.

>
> In any case, I don't want to bike-shed so I'll defer to the
> maintainer's call on this.
>
> BR,
>
> -Prashant

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ