lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 30 Oct 2020 16:27:14 +0100
From:   Amelie DELAUNAY <amelie.delaunay@...com>
To:     Rob Herring <robh@...nel.org>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Russell King <linux@...linux.org.uk>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux USB List <linux-usb@...r.kernel.org>,
        "moderated list:ARM/STM32 ARCHITECTURE" 
        <linux-stm32@...md-mailman.stormreply.com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Fabrice Gasnier <fabrice.gasnier@...com>
Subject: Re: [RESEND PATCH v3 1/4] dt-bindings: connector: add power-opmode
 optional property to usb-connector



On 10/30/20 3:29 PM, Rob Herring wrote:
> On Thu, Oct 29, 2020 at 11:49 AM Amelie DELAUNAY <amelie.delaunay@...com> 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 <amelie.delaunay@...com>
>>>> ---
>>>>    .../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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ