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=-5.4 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 AE804C04AAD for ; Tue, 7 May 2019 14:13:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 890782087F for ; Tue, 7 May 2019 14:13:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726764AbfEGONM (ORCPT ); Tue, 7 May 2019 10:13:12 -0400 Received: from mga09.intel.com ([134.134.136.24]:22015 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726063AbfEGONM (ORCPT ); Tue, 7 May 2019 10:13:12 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 May 2019 07:13:11 -0700 X-ExtLoop1: 1 Received: from kuha.fi.intel.com ([10.237.72.189]) by fmsmga001.fm.intel.com with SMTP; 07 May 2019 07:13:06 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Tue, 07 May 2019 17:13:05 +0300 Date: Tue, 7 May 2019 17:13:05 +0300 From: Heikki Krogerus To: Chunfeng Yun Cc: Rob Herring , Greg Kroah-Hartman , Mark Rutland , Matthias Brugger , linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Biju Das , Yu Chen , Min Guo , Felipe Balbi Subject: Re: [v2 PATCH] dt-binding: usb: add usb-role-switch property Message-ID: <20190507141305.GA19816@kuha.fi.intel.com> References: <38ff51264e971d5c58940c8435b9d8d274662d50.1557195204.git.chunfeng.yun@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38ff51264e971d5c58940c8435b9d8d274662d50.1557195204.git.chunfeng.yun@mediatek.com> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 07, 2019 at 10:22:58AM +0800, Chunfeng Yun wrote: > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt > index 0a74ab8dfdc2..f5a6ad053ecc 100644 > --- a/Documentation/devicetree/bindings/usb/generic.txt > +++ b/Documentation/devicetree/bindings/usb/generic.txt > @@ -30,6 +30,11 @@ Optional properties: > optional for OTG device. > - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is > optional for OTG device. > + - usb-role-switch: tells Dual-Role USB controllers we want to handle the role > + switch between host and device according to the state > + detected by the USB connector, typically for Type-C, > + Type-B(micro). > + see connector/usb-connector.txt. That does not look correct to me. Firstly, USB role switches are not always dual-role USB controllers. Secondly, stating what determines the role irrelevant IMO. Since this is a boolean property, the description for it should simply explain what does it tell about the capabilities of the device that has it. The description should not make any assumptions about the users of the property, and since the property is a "generic" USB property, I'm not sure it should make any assumptions about the type of the device that has the property either. Also, I would really like the description to show the type of the property. Why not just say something like this: "Boolean property informing that the device is capable of assigning the USB data role (USB host or USB device) for a given USB connector." thanks, -- heikki