[<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