linux-kernel - RE: [PATCH v2] usb: typec: tcpm: Invoke power_supply

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] [day] [month] [year] [list]

Date:   Fri, 19 Mar 2021 16:32:44 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     Badhri Jagan Sridharan <badhri@...gle.com>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>
CC:     Guenter Roeck <linux@...ck-us.net>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH v2] usb: typec: tcpm: Invoke power_supply_changed for
 tcpm-source-psy-

On 18 March 2021 20:40, Badhri Jagan Sridharan wrote:

> > Regarding selecting PDOs or PPS APDOs, surely we should only notify of a
> change
> > when we reach SNK_READY which means a new contract has been established?
> Until
> > that point it's possible any requested change could be rejected so why inform
> > clients before we know the settings have taken effect? I could be missing
> > something here as it's been a little while since I delved into this, but this
> > doesn't seem to make sense to me.
> 
> I was trying to keep the power_supply_changed call close to the
> variables which are used to infer the power supply property values.
> Since port->pps_data.max_curr is already updated here and that's used
> to infer the CURRENT_MAX a client could still read this before the
> request goes through right ?

Actually that's fair but I think the problem here relates to 'max_curr' not
being reset if the SRC rejects our request when we're swapping between one PPS
APDO and another PPS APDO. I think the 'max_curr' value should be reverted back
to the value for the existing PPS APDO we were already using. I suspect the same
might be true of 'min_volt' and 'max_volt' as well, now I look at it. It might
actually be prudent to have pending PPS data based on a request, which is only
committed as active once ACCEPT has been received.

Regarding power_supply_changed() though, I still think we should only notify of
a change when the requested change has been accepted by the source, in relation
to these values as they should reflect the real, in-use voltage and current
values.