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
| ||
|
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; >>>>> } >>>> >> >>
Powered by blists - more mailing lists