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: <690375f9-b721-51d5-7292-59acff44af7c@roeck-us.net>
Date:   Sun, 9 Sep 2018 07:20:17 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Angus Ainslie <angus@...ea.ca>
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 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.

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;
>>>>   }
>>>
> 
>