lkml.org 
[lkml]   [2021]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH v2] usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy-
    Date
    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.

    \
     
     \ /
      Last update: 2021-03-19 17:34    [W:3.545 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site