linux-kernel - Re: [PATCH] usb: typec: don't disable sink or source on initialization

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]

Message-ID: <363bd1128780d8de8e560b1b82ce361a@www.akkea.ca>
Date:   Sun, 09 Sep 2018 08:36:46 -0600
From:   Angus Ainslie <angus@...ea.ca>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        Guenter Roeck <groeck7@...il.com>
Subject: Re: [PATCH] usb: typec: don't disable sink or source on  initialization

On 2018-09-09 08:20, Guenter Roeck wrote:
> On 09/09/2018 07:08 AM, Angus Ainslie wrote:
>> Hi Guenter
>> 
>> On 2018-09-07 06:55, Guenter Roeck wrote:
>>> On 09/07/2018 03:34 AM, Heikki Krogerus wrote:
>>>> +Guenter
>>>> 
>>>> On Thu, Sep 06, 2018 at 01:26:44PM -0600, Angus Ainslie (Purism) 
>>>> wrote:
>>>>> If the board is being powered by USB disabling the source and sink
>>>>> can remove power from the board. Default to source and sink 
>>>>> enabled.
>>>>> 
>>> 
>>> Seems to me that might violate the specification, and cause trouble 
>>> for systems
>>> where vbus has to be off initially. It may be better to provide this 
>>> kind of
>>> information as configuration parameter instead of imposing it on 
>>> everyone.
>>> 
>> 
>> It felt like it would not be the correct thing to do either. I've 
>> tried re-arranging the code in tcpci.c to enable the sink before 
>> disabling the source but the only way I found to not disable the power 
>> was by setting both of those to true.
>> 
>> What about adding some device tree entries for the initial vbus state 
>> and default to false if they are not present ?
>> 
>> init-vbus-source and init-vbus-charge ?
>> 
> 
> Yes, I think we should do something along that line. Another question 
> is
> if we could or should optionally pull the current state from the low 
> level
> driver, but that may be secondary.
> 

I thought of trying to do that but from reading the "PTN5110N PD PHY 
application programming guide" there didn't seem to be a direct way to 
read those parameters.

> Thanks,
> Guenter
> 
>> Angus
>> 
>>> Guenter
>>> 
>>>>> Signed-off-by: Angus Ainslie (Purism) <angus@...ea.ca>
>>>>> ---
>>>>>   drivers/usb/typec/tcpm.c | 8 +++++---
>>>>>   1 file changed, 5 insertions(+), 3 deletions(-)
>>>>> 
>>>>> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
>>>>> index ca7bedb46f7f..a1b819cf31da 100644
>>>>> --- a/drivers/usb/typec/tcpm.c
>>>>> +++ b/drivers/usb/typec/tcpm.c
>>>>> @@ -2462,9 +2462,11 @@ static int tcpm_init_vbus(struct tcpm_port 
>>>>> *port)
>>>>>   {
>>>>>       int ret;
>>>>>   -    ret = port->tcpc->set_vbus(port->tcpc, false, false);
>>>>> -    port->vbus_source = false;
>>>>> -    port->vbus_charge = false;
>>>>> +    /* default to source and sink enabled in case USB is our only 
>>>>> power
>>>>> +     * source */
>>> 
>>> I am personally in favor of standard multi-line comments.
>>> 
>>>>> +    ret = port->tcpc->set_vbus(port->tcpc, true, true);
>>>>> +    port->vbus_source = true;
>>>>> +    port->vbus_charge = true;
>>>>>       return ret;
>>>>>   }
>>>> 
>> 
>>