linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
To: Badhri Jagan Sridharan <badhri@google.com>,
	Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH v2] usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy-
Date: Fri, 19 Mar 2021 16:32:44 +0000	[thread overview]
Message-ID: <PR3PR10MB4142450638A8E07A33E475B080689@PR3PR10MB4142.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CAPTae5J_GdHsGQvNxgpffk5otyGhY8D48vddvin3A4fkz3KWUA@mail.gmail.com>

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.


  reply	other threads:[~2021-03-19 16:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 18:12 [PATCH v2] usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy- Badhri Jagan Sridharan
2021-03-18 15:26 ` Adam Thomson
2021-03-18 20:40   ` Badhri Jagan Sridharan
2021-03-19 16:32     ` Adam Thomson [this message]
     [not found]       ` <CAPTae5KX_+_4TN3DAptP-ra=Lzxnf7LgBDwxsv5JWxg4y4hQqQ@mail.gmail.com>
2021-04-06  1:43         ` Badhri Jagan Sridharan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PR3PR10MB4142450638A8E07A33E475B080689@PR3PR10MB4142.EURPRD10.PROD.OUTLOOK.COM \
    --to=adam.thomson.opensource@diasemi.com \
    --cc=badhri@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).