All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kyle Tso <kyletso@google.com>
To: Benson Leung <bleung@chromium.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Rob Herring <robh+dt@kernel.org>,
	Badhri Jagan Sridharan <badhri@google.com>,
	"open list:USB SUBSYSTEM" <linux-usb@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Prashant Malani <pmalani@google.com>
Subject: Re: [PATCH v5 2/8] usb: pd: Update VDO definitions
Date: Thu, 4 Feb 2021 10:24:47 +0800	[thread overview]
Message-ID: <CAGZ6i=3EqLVJn+KE4TV2iq+Z+HKOJQzMOgODvw-Z0z3CpjYCzA@mail.gmail.com> (raw)
In-Reply-To: <CANLzEksFtyYe01F_+MEFdG+KC83FAu00-PAtc95-v2GswMnTvw@mail.gmail.com>

On Thu, Feb 4, 2021 at 12:55 AM Benson Leung <bleung@chromium.org> wrote:
>
> Hey Kyle,
>
> On Tue, Feb 2, 2021 at 8:23 AM Kyle Tso <kyletso@google.com> wrote:
> >
> > "PD Spec Revision 3.0 Version 2.0 + ECNs 2020-12-10" introduces several
> > changes regarding the ID Header VDO and the Product Type VDOs.
> >
> > Signed-off-by: Kyle Tso <kyletso@google.com>
>
> We have to actually be very careful in this change, because the switch
> from PD 2.0 -> PD 3.0 does not mean that a PD 3.0 DFP will never
> encounter a PD 2.0 partner or cable again.
>
> It actually has to be the case that we may have to maintain two sets
> of these object field definitions (and any other PD object decoding we
> do in the kernel) and switch the decoding on pd_revision (which I
> recently added here:
> https://lore.kernel.org/linux-usb/20210129061406.2680146-3-bleung@chromium.org).
>
> Just to put a point on it: PD 2.0's Passive Cable VDO has B4, which is
> "Vbus through cable." PD 3.0, on the other hand, reserves this bit, so
> the field is gone. We can't just delete that bit in the kernel's data
> structures. We have to be able to refer to it if we encounter a PD 2.0
> cable.
>
> I think this change needs to be reworked so that we strictly maintain
> a PD 2.0 object field definitions, and a separate PD 3.0 one too. They
> will operate on the same objects, but whoever's doing the decoding has
> to check the revision (2.0 vs 3.0) first to check applicability of one
> set or the other.
>
> Thanks,
> Benson
>
>
> --
> Benson Leung
> Staff Software Engineer
> Chrome OS Kernel
> Google Inc.
> bleung@google.com
> Chromium OS Project
> bleung@chromium.org

You are correct!
Fix is here: https://patchwork.kernel.org/project/linux-usb/patch/20210204005036.1555294-1-kyletso@google.com/

thanks,
Kyle

  reply	other threads:[~2021-02-04  2:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 16:17 [PATCH v5 0/8] common SVDM version and VDO from dt Kyle Tso
2021-02-02 16:17 ` [PATCH v5 1/8] usb: typec: Manage SVDM version Kyle Tso
2021-02-03 12:47   ` Heikki Krogerus
2021-02-03 13:34     ` Heikki Krogerus
2021-02-03 14:51     ` Guenter Roeck
2021-02-03 15:01       ` Heikki Krogerus
2021-02-03 15:04         ` Heikki Krogerus
2021-02-03 15:42           ` Kyle Tso
2021-02-03 17:07           ` Guenter Roeck
2021-02-02 16:17 ` [PATCH v5 2/8] usb: pd: Update VDO definitions Kyle Tso
2021-02-03 12:48   ` Heikki Krogerus
2021-02-03 13:09     ` Greg KH
2021-02-03 16:54   ` Benson Leung
2021-02-04  2:24     ` Kyle Tso [this message]
2021-02-02 16:17 ` [PATCH v5 3/8] usb: pd: Make SVDM Version configurable in VDM header Kyle Tso
2021-02-02 16:17 ` [PATCH v5 4/8] usb: typec: tcpm: Detemine common SVDM Version Kyle Tso
2021-02-02 16:17 ` [PATCH v5 5/8] usb: typec: ucsi: " Kyle Tso
2021-02-02 16:17 ` [PATCH v5 6/8] usb: typec: displayport: Fill the negotiated SVDM Version in the header Kyle Tso
2021-02-02 16:17 ` [PATCH v5 7/8] dt-bindings: connector: Add SVDM VDO properties Kyle Tso
2021-02-02 16:17 ` [PATCH v5 8/8] usb: typec: tcpm: Get Sink VDO from fwnode Kyle Tso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGZ6i=3EqLVJn+KE4TV2iq+Z+HKOJQzMOgODvw-Z0z3CpjYCzA@mail.gmail.com' \
    --to=kyletso@google.com \
    --cc=badhri@google.com \
    --cc=bleung@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=pmalani@google.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.