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: <AM5PR1001MB0994F9594BDDBD97BD9794D380900@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
Date:   Wed, 30 Jan 2019 10:39:01 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     Kyle Tso <kyletso@...gle.com>,
        "linux@...ck-us.net" <linux@...ck-us.net>,
        "heikki.krogerus@...ux.intel.com" <heikki.krogerus@...ux.intel.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     "badhri@...gle.com" <badhri@...gle.com>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] usb: typec: tcpm: Correct the PPS out_volt calculation

On 30 January 2019 03:14, Kyle Tso wrote:

> When Sink negotiates PPS, the voltage range of selected PPS APDO might not
> cover the previous voltage (out_volt). If the previous out_volt is lower than the
> new min_volt, the output voltage in RDO might be set to an invalid value. For
> instance, supposed that the previous voltage is 5V, and the new voltage range in
> the APDO is 7V-12V. Then the output voltage in the RDO should not be set to 5V
> which is lower than the possible min_volt 7V.
> 
> Fix this by choosing the maximal value between the previous voltage and the
> new min_volt first. And ensure that this value will not exceed the new max_volt.
> The new out_volt will fall within the new voltage range while being the closest
> value compared to the previous out_volt.
> 
> Signed-off-by: Kyle Tso <kyletso@...gle.com>

I'd be interested to see how many Sources go off-piste like that with a more
unusual PPS range, especially when the default fixed is 5V, and they're required
to support one of the defined PPS ranges which will start at 3.3V. Not sure what
this might gain you. However, spec says it's possible so:

Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@...semi.com>

> ---
>  drivers/usb/typec/tcpm/tcpm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index f1d3e54210df..8f2af348bda5 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -2297,7 +2297,8 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
> tcpm_port *port)
>  					      pdo_pps_apdo_max_voltage(snk));
>  		port->pps_data.max_curr = min_pps_apdo_current(src, snk);
>  		port->pps_data.out_volt = min(port->pps_data.max_volt,
> -					      port->pps_data.out_volt);
> +					      max(port->pps_data.min_volt,
> +						  port->pps_data.out_volt));
>  		port->pps_data.op_curr = min(port->pps_data.max_curr,
>  					     port->pps_data.op_curr);
>  	}
> --
> 2.20.1.495.gaa96b0ce6b-goog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ