Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200617180209.5636-1-wcheng@codeaurora.org> <20200617180209.5636-3-wcheng@codeaurora.org>
 <CAL_Jsq+fhXWGJvYxUDygd6hKs3dc8GKxKCz_Q+_C1AjK0J0N+w@mail.gmail.com> <fb448691-2bda-ada6-799f-ee389e647710@codeaurora.org>
In-Reply-To: <fb448691-2bda-ada6-799f-ee389e647710@codeaurora.org>
From:   Rob Herring <robh+dt@kernel.org>
Date:   Thu, 18 Jun 2020 16:23:42 -0600
Message-ID: <CAL_JsqLGWY_bBUzr6r0czxH32vvDnsR6=MzS=zH4tJ-5PEobZw@mail.gmail.com>
Subject: Re: [PATCH v3 2/6] dt-bindings: usb: Add Qualcomm PMIC type C
 controller dt-binding
To:     Wesley Cheng <wcheng@codeaurora.org>
Cc:     Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Mark Brown <broonie@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Andy Gross <agross@kernel.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        devicetree@vger.kernel.org,
        Linux USB List <linux-usb@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Jack Pham <jackp@codeaurora.org>,
        Randy Dunlap <rdunlap@infradead.org>,
        "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
        Jun Li <lijun.kernel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jun 18, 2020 at 2:09 PM Wesley Cheng <wcheng@codeaurora.org> wrote:
>
>
> On 6/18/2020 11:33 AM, Rob Herring wrote:
> > On Wed, Jun 17, 2020 at 12:02 PM Wesley Cheng <wcheng@codeaurora.org> wrote:
> >
> > You are duplicating everything in usb-connector.yaml. You should have
> > a $ref to it.
> >
>
> Hi Rob,
>
> Sure, I will add a reference to that doc.
>
> >
> > This is wrong. The connector binding says port 0 is the connection the
> > USB HS controller.
> >
> > What's a type C mux node? Is there a binding for that? There's an
> > ongoing discussion with the CrOS folks on how to describe Alt mode
> > mux/switches.
>
> I reviewed the connector binding previously, and couldn't seem to come
> up with a model which fit a design where the type C controller (ie the
> entity which does the CC orientation and role detection) does not have
> the SS lane mux included.  The SS lane mux is the HW which handles the
> selection of the SS lanes to utilize based on cable orientation.

The intent was the controller would be the parent node of the connector.

How the SS lane mux is represented is what needs to be figured out. I
don't know what that looks like, but it needs to be something that
works for multiple designs. Ideally, that's an extension of the
existing 'usb-c-connector' binding, but if there's good reasons to
redesign it that can happen.

Rob