From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B106C433E2 for ; Thu, 18 Jun 2020 22:24:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 09C65206FA for ; Thu, 18 Jun 2020 22:24:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592519043; bh=suc9pm53OLkf5+tDTVTkktvXVOKJj7lJ6p6vf0fAzPU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=hL1U/K11RVFfFpQrAxiEmkXp33nxWY+okHOANKRrSZ5woWXd3OnXFV+rIyLEumglO Okgb9ClxDbk1mI5BRK/Ek84U/axp5b3arEeOufwX9LbHSxT8YBqQegvxtm6bAZveSg cgdg24RkgDfMkJT8Q31BLGUOjq+6ubtE9uIVCOL8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732110AbgFRWYB (ORCPT ); Thu, 18 Jun 2020 18:24:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:52648 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725829AbgFRWX7 (ORCPT ); Thu, 18 Jun 2020 18:23:59 -0400 Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 02A9E20732; Thu, 18 Jun 2020 22:23:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592519039; bh=suc9pm53OLkf5+tDTVTkktvXVOKJj7lJ6p6vf0fAzPU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YoqsdiIMkAkW5I7KL3asxk7dZW8YFot/9qO7uTYjFzZYlNMbb11jjIgzofi+vfWSN QCx0PuMoe8ViFXtMUz04+1oUI/FDzn8h+pd4DmLqh3inuLt+lAscX5c2Uzz64ieJPr iELIJNlCKYeczmr4JEPtg6Hoq04HkahOuC/b010Q= Received: by mail-oi1-f181.google.com with SMTP id 25so6580396oiy.13; Thu, 18 Jun 2020 15:23:58 -0700 (PDT) X-Gm-Message-State: AOAM531skErlZ5b0asHZpQCIcxg4oztRK8kWvoMIkcLu2Px+DrS7OeZD 236rAXW37F9Q09CGsM4gTTc6+GjLszNJ5E0RTA== X-Google-Smtp-Source: ABdhPJw1K2OvzxLmNVbzVFc6bTX+uL3GtdpnvRebeJA5Th13K0T4h+C+0pOQ+rfRUWnRUcvWCYUGc3DRbledxdgoUFs= X-Received: by 2002:aca:d454:: with SMTP id l81mr939987oig.152.1592519038311; Thu, 18 Jun 2020 15:23:58 -0700 (PDT) MIME-Version: 1.0 References: <20200617180209.5636-1-wcheng@codeaurora.org> <20200617180209.5636-3-wcheng@codeaurora.org> In-Reply-To: From: Rob Herring Date: Thu, 18 Jun 2020 16:23:42 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding To: Wesley Cheng Cc: Heikki Krogerus , Mark Rutland , Mark Brown , Bjorn Andersson , Greg Kroah-Hartman , Liam Girdwood , Andy Gross , linux-arm-msm , devicetree@vger.kernel.org, Linux USB List , "linux-kernel@vger.kernel.org" , Jack Pham , Randy Dunlap , "Bryan O'Donoghue" , Jun Li Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 18, 2020 at 2:09 PM Wesley Cheng wrote: > > > On 6/18/2020 11:33 AM, Rob Herring wrote: > > On Wed, Jun 17, 2020 at 12:02 PM Wesley Cheng 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