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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 6B89CC433DF for ; Thu, 18 Jun 2020 20:09:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 414A5207E8 for ; Thu, 18 Jun 2020 20:09:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="R19OomXE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730454AbgFRUJS (ORCPT ); Thu, 18 Jun 2020 16:09:18 -0400 Received: from mail29.static.mailgun.info ([104.130.122.29]:48657 "EHLO mail29.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730006AbgFRUJS (ORCPT ); Thu, 18 Jun 2020 16:09:18 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1592510957; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: MIME-Version: Date: Message-ID: From: References: Cc: To: Subject: Sender; bh=NTUeymUReKpdIsjMtCi8NYeyBb1gfEMgmYaNDWEKN9I=; b=R19OomXEobZ8SHqdm9yaIu1VMxxaxtQ00fjDkU/gyjdfNjawBmxc926cWOum/eJW8zFuLhTE e0xQKqg8l6/BKRoeOC7woyn301W3g0wZS2X5j9DxKu8K6CC4ofEOE4NXfvJza14rQX45Kfv6 9bo+6wsYvYHog9ZaUbyhzDRCqiI= X-Mailgun-Sending-Ip: 104.130.122.29 X-Mailgun-Sid: WyI1YmJiNiIsICJkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZyIsICJiZTllNGEiXQ== Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n01.prod.us-west-2.postgun.com with SMTP id 5eebc9eb6f2ee827da204a1e (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 18 Jun 2020 20:09:15 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 7733BC433A1; Thu, 18 Jun 2020 20:09:15 +0000 (UTC) Received: from [10.110.38.129] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: wcheng) by smtp.codeaurora.org (Postfix) with ESMTPSA id B30D0C433CA; Thu, 18 Jun 2020 20:09:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org B30D0C433CA Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=wcheng@codeaurora.org Subject: Re: [PATCH v3 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding To: Rob Herring 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 References: <20200617180209.5636-1-wcheng@codeaurora.org> <20200617180209.5636-3-wcheng@codeaurora.org> From: Wesley Cheng Message-ID: Date: Thu, 18 Jun 2020 13:09:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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. I looked at the FUSB302 TCPM driver, which doesn't have an integrated SS lane mux, and relies on an external FUSB340 switch to handle the polarity, but seems that in the fusb302.c driver it doesn't implement the polarity handler. They might possibly have a HW output signal which controls the mux directly, but I'm not sure on that. Anyway, if someone wanted to take a SW approach and program an external mux, this model doesn't seem to allow that. This is somewhat unrelated to the DP AUX mode switching, as that probably will only come into the picture after the policy engine has detected there is a DP adapter connected, whereas this is applicable to non DP/alt mode situations. Thanks! >> + type: object >> + >> + properties: >> + remote-endpoint: >> + maxItems: 1 >> + description: Node reference to the type C mux >> + >> + endpoint@1: >> + description: Connection to role switch node > > Again, what's this? > -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project