linux-kernel - RE: [PATCH] usb: typec: tcpm: Correct the PPS out

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:   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