Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp1371838pxx; Fri, 30 Oct 2020 08:30:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLRw3mh6Ht+Xvv+rG1IllebQbO84fZhaBJxHD0N4qrHql3nsa2sHpKS0EEKysF3u7ohaSp X-Received: by 2002:a05:6402:17ac:: with SMTP id j12mr2945262edy.31.1604071858242; Fri, 30 Oct 2020 08:30:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1604071858; cv=none; d=google.com; s=arc-20160816; b=UaVYN0T9evImZXzd5z+lIyD5HGyldu7RQGOopztiL8M54ywZdVfl4gh+IvvdnIc2mC bb2y6u4B+1vFrCzSxd6eUsEHpoZ0x6Vb3Z7X1KbXpWUkiCvnUWNBdGE4Kbx1u9Vs8XtG 049qxvueWiM7mP1vWeiFdSaANpVGvcjKbhXcFlV8bOzE+NkBZnox+/W1EBGS8goX6VDc Wb+WUkqfeHZMJ6JT6mzCs9EIjFEfeuhAIGenIIQyT+4/c/u0n53fk+kHDhVs58MCKZO1 9/f2l8ixcPTO583GbXHRUhspayLWqBhuZgNbeRwPUAtkdirUJt+UirbSDDZTPJHhuROL NVuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=4QYEGEv6Dx43DkeQaT74KojLLBRyD+ORt/fhCMzqZTs=; b=dCqyzMgssQg4cW7J6I5NlVdHhDtszxahdGJsIvhzyhB25mFZ5fAP6pSDwbZQvId3YX 3HaP/sHhvTs3C2I0pWEZFMOal4eo/nAXd3HlNtTpMEGUIbLsPxVNtKr3LeAt1cMK6TJg XpDHQZwpPgyeHLKppWXqvDYUulT9VhX4b2J0H7fE5x79qeGmQLRsy+OkwMw1YtbtOrKS t/YxdGiogfXhCNeCCXAI6oWwK2MMwM/IqIOM3qXKij8YdYgXxmbQDs9c1YuLKkj8Yhky Dbb5xQQpDudf0qTLOignkJY1rrkjPby1yTfB+DkucSdm7CM1lduEglSwhSbErteSGbzP Zxyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@st.com header.s=STMicroelectronics header.b=iRE+Mcwq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=st.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l13si5101868ejg.519.2020.10.30.08.30.34; Fri, 30 Oct 2020 08:30:58 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@st.com header.s=STMicroelectronics header.b=iRE+Mcwq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727205AbgJ3P1o (ORCPT + 99 others); Fri, 30 Oct 2020 11:27:44 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:8338 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726307AbgJ3P1n (ORCPT ); Fri, 30 Oct 2020 11:27:43 -0400 Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09UF8LL1003715; Fri, 30 Oct 2020 16:27:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=STMicroelectronics; bh=4QYEGEv6Dx43DkeQaT74KojLLBRyD+ORt/fhCMzqZTs=; b=iRE+Mcwq8+6u5wET2e5Rw2WxAMM2pJcHvtToopcqvUS1o63ME83HPr+7HCScDjg/MmRn oDz1b+FvQ6it4MNNkwAmMLl+zozfkufzi4UvSnWoD1QDQF2jgHm+EPHw5dJUn5/jDSGs mbffz9lPaLDR10C1y2/k0zUzFfPApKuZfctIej5UTLXe+ZaXf2xYRRwXEC1oDYch0n+T dfNE/SZ0BUbrHkYRPdgoCU0ogRajgN5NMdbkNtlotXRtbbdlboP/CocYT4UqcHVIxqdg +geGqafFj6b3KZN8TYAP9J7R6dtOaN6UBg+rl/qfd11PlFQp4HEKFnVHyCUHDKejdzYF XQ== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 34ccmrhjg6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Oct 2020 16:27:17 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9B09F100034; Fri, 30 Oct 2020 16:27:16 +0100 (CET) Received: from Webmail-eu.st.com (sfhdag3node2.st.com [10.75.127.8]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 7F5D22257DC; Fri, 30 Oct 2020 16:27:16 +0100 (CET) Received: from lmecxl0995.lme.st.com (10.75.127.45) by SFHDAG3NODE2.st.com (10.75.127.8) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Oct 2020 16:27:15 +0100 Subject: Re: [RESEND PATCH v3 1/4] dt-bindings: connector: add power-opmode optional property to usb-connector To: Rob Herring CC: Greg Kroah-Hartman , Maxime Coquelin , Alexandre Torgue , Russell King , Heikki Krogerus , , "linux-kernel@vger.kernel.org" , Linux USB List , "moderated list:ARM/STM32 ARCHITECTURE" , linux-arm-kernel , Fabrice Gasnier References: <20201029095806.10648-1-amelie.delaunay@st.com> <20201029095806.10648-2-amelie.delaunay@st.com> <20201029154016.GA1917373@bogus> <860d5620-4fdf-6e01-9a04-3967d6fcfd6b@st.com> From: Amelie DELAUNAY Message-ID: Date: Fri, 30 Oct 2020 16:27:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.45] X-ClientProxiedBy: SFHDAG4NODE2.st.com (10.75.127.11) To SFHDAG3NODE2.st.com (10.75.127.8) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312,18.0.737 definitions=2020-10-30_07:2020-10-30,2020-10-30 signatures=0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/30/20 3:29 PM, Rob Herring wrote: > On Thu, Oct 29, 2020 at 11:49 AM Amelie DELAUNAY wrote: >> >> >> >> On 10/29/20 4:40 PM, Rob Herring wrote: >>> On Thu, Oct 29, 2020 at 10:58:03AM +0100, Amelie Delaunay wrote: >>>> Power operation mode may depends on hardware design, so, add the optional >>>> property power-opmode for usb-c connector to select the power operation >>>> mode capability. >>>> >>>> Signed-off-by: Amelie Delaunay >>>> --- >>>> .../bindings/connector/usb-connector.yaml | 18 ++++++++++++++++++ >>>> 1 file changed, 18 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml >>>> index 728f82db073d..200d19c60fd5 100644 >>>> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml >>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml >>>> @@ -93,6 +93,24 @@ properties: >>>> - device >>>> - dual >>>> >>>> + power-opmode: >>> >>> I've acked this version: >>> >>> https://lore.kernel.org/r/20201020093627.256885-2-badhri@google.com >>> >> >> frs is used for Fast Role Swap defined in USB PD spec. >> I understand it allows to get the same information but I'm wondering why >> the property name is limited to -frs- in this case. What about a >> non-power delivery USB-C connector ? > > I've got no idea. The folks that know USB-C and PD details need to get > together and work all this out. To me, it looks like the same thing... > It looks but... The purpose of power-opmode property is to configure the USB-C controllers, especially the non-PD USB-C controllers to determine the power operation mode that the Type C connector will support and will advertise through CC pins when it has no power delivery support, whatever the power role: Sink, Source or Dual The management of the property is the same that data-role and power-role properties, and done by USB Type-C Connector Class. new-source-frs-typec-current specifies initial current capability of the new source when vSafe5V is applied during PD3.0 Fast Role Swap. So here, this property is not applied at usb-c controller configuration level, but during PD Fast Role Swap, so when the Sink become the Source. Moreover, the related driver code says FRS can only be supported by DRP ports. So new-source-frs-typec-current property, in addition to being specific to PD, is also dedicated to DRP usb-c controller. The property is managed by Type-C Port Controller Manager for PD. > And it's not just this, but the stream of USB-C additions that trickle in. > >> Moreover, power-opmode property support is already merged in typec class: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/typec/class.c?h=v5.10-rc1&id=12f3467b0d28369d3add7a0deb65fdac9b503c90 >> and stusb160x driver uses it :( >> >> So, do I need to modify stusb160x driver (and bindings) to take into >> account this USB PD specific property? > > If not documented, then it's not an ABI, so yes. I have tried to document it since months ago v1: https://lkml.org/lkml/2020/6/15/927 v2: https://lkml.org/lkml/2020/7/23/445 integrating your remarks v2 RESENT: https://lkml.org/lkml/2020/9/2/174 v3: https://lkml.org/lkml/2020/9/24/306 integrated Li Jun remarks Regards, Amelie