diff mbox series

[v2] usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy-

Message ID 20210317181249.1062995-1-badhri@google.com (mailing list archive)
State Accepted
Commit 86629e098a077922438efa98dc80917604dfd317
Headers show
Series [v2] usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy- | expand

Commit Message

Badhri Jagan Sridharan March 17, 2021, 6:12 p.m. UTC
tcpm-source-psy- does not invoke power_supply_changed API when
one of the published power supply properties is changed.
power_supply_changed needs to be called to notify
userspace clients(uevents) and kernel clients.

Fixes: f2a8aa053c176("typec: tcpm: Represent source supply through power_supply")
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
Changes since V1:
- Fixed commit message as per Guenter's suggestion
- Added Reviewed-by tags
- cc'ed stable
---
 drivers/usb/typec/tcpm/tcpm.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Comments

Adam Thomson March 18, 2021, 3:26 p.m. UTC | #1
On 17 March 2021 18:13, Badhri Jagan Sridharan wrote:

> tcpm-source-psy- does not invoke power_supply_changed API when
> one of the published power supply properties is changed.
> power_supply_changed needs to be called to notify
> userspace clients(uevents) and kernel clients.
> 
> Fixes: f2a8aa053c176("typec: tcpm: Represent source supply through
> power_supply")
> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> Changes since V1:
> - Fixed commit message as per Guenter's suggestion
> - Added Reviewed-by tags
> - cc'ed stable
> ---
>  drivers/usb/typec/tcpm/tcpm.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 11d0c40bc47d..e8936ea17f80 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -945,6 +945,7 @@ static int tcpm_set_current_limit(struct tcpm_port *port,
> u32 max_ma, u32 mv)
> 
>  	port->supply_voltage = mv;
>  	port->current_limit = max_ma;
> +	power_supply_changed(port->psy);
> 
>  	if (port->tcpc->set_current_limit)
>  		ret = port->tcpc->set_current_limit(port->tcpc, max_ma, mv);
> @@ -2931,6 +2932,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port,
> int *sink_pdo,
> 
>  	port->pps_data.supported = false;
>  	port->usb_type = POWER_SUPPLY_USB_TYPE_PD;
> +	power_supply_changed(port->psy);
> 
>  	/*
>  	 * Select the source PDO providing the most power which has a
> @@ -2955,6 +2957,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port,
> int *sink_pdo,
>  				port->pps_data.supported = true;
>  				port->usb_type =
>  					POWER_SUPPLY_USB_TYPE_PD_PPS;
> +				power_supply_changed(port->psy);
>  			}
>  			continue;
>  		default:
> @@ -3112,6 +3115,7 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
> tcpm_port *port)
>  						  port->pps_data.out_volt));
>  		port->pps_data.op_curr = min(port->pps_data.max_curr,
>  					     port->pps_data.op_curr);
> +		power_supply_changed(port->psy);
>  	}
> 
>  	return src_pdo;

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.

> @@ -3347,6 +3351,7 @@ static int tcpm_set_charge(struct tcpm_port *port, bool
> charge)
>  			return ret;
>  	}
>  	port->vbus_charge = charge;
> +	power_supply_changed(port->psy);
>  	return 0;
>  }
> 
> @@ -3530,6 +3535,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
>  	port->try_src_count = 0;
>  	port->try_snk_count = 0;
>  	port->usb_type = POWER_SUPPLY_USB_TYPE_C;
> +	power_supply_changed(port->psy);

This is already taken care of at the end of this function, isn't it?

>  	port->nr_sink_caps = 0;
>  	port->sink_cap_done = false;
>  	if (port->tcpc->enable_frs)
> @@ -5957,7 +5963,7 @@ static int tcpm_psy_set_prop(struct power_supply
> *psy,
>  		ret = -EINVAL;
>  		break;
>  	}
> -
> +	power_supply_changed(port->psy);
>  	return ret;
>  }
> 
> @@ -6110,6 +6116,7 @@ struct tcpm_port *tcpm_register_port(struct device
> *dev, struct tcpc_dev *tcpc)
>  	err = devm_tcpm_psy_register(port);
>  	if (err)
>  		goto out_role_sw_put;
> +	power_supply_changed(port->psy);
> 
>  	port->typec_port = typec_register_port(port->dev, &port->typec_caps);
>  	if (IS_ERR(port->typec_port)) {
> --
> 2.31.0.rc2.261.g7f71774620-goog
Badhri Jagan Sridharan March 18, 2021, 8:40 p.m. UTC | #2
On Thu, Mar 18, 2021 at 8:26 AM Adam Thomson
<Adam.Thomson.Opensource@diasemi.com> wrote:
>
> On 17 March 2021 18:13, Badhri Jagan Sridharan wrote:
>
> > tcpm-source-psy- does not invoke power_supply_changed API when
> > one of the published power supply properties is changed.
> > power_supply_changed needs to be called to notify
> > userspace clients(uevents) and kernel clients.
> >
> > Fixes: f2a8aa053c176("typec: tcpm: Represent source supply through
> > power_supply")
> > Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
> > Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> > Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > ---
> > Changes since V1:
> > - Fixed commit message as per Guenter's suggestion
> > - Added Reviewed-by tags
> > - cc'ed stable
> > ---
> >  drivers/usb/typec/tcpm/tcpm.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> > index 11d0c40bc47d..e8936ea17f80 100644
> > --- a/drivers/usb/typec/tcpm/tcpm.c
> > +++ b/drivers/usb/typec/tcpm/tcpm.c
> > @@ -945,6 +945,7 @@ static int tcpm_set_current_limit(struct tcpm_port *port,
> > u32 max_ma, u32 mv)
> >
> >       port->supply_voltage = mv;
> >       port->current_limit = max_ma;
> > +     power_supply_changed(port->psy);
> >
> >       if (port->tcpc->set_current_limit)
> >               ret = port->tcpc->set_current_limit(port->tcpc, max_ma, mv);
> > @@ -2931,6 +2932,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port,
> > int *sink_pdo,
> >
> >       port->pps_data.supported = false;
> >       port->usb_type = POWER_SUPPLY_USB_TYPE_PD;
> > +     power_supply_changed(port->psy);
> >
> >       /*
> >        * Select the source PDO providing the most power which has a
> > @@ -2955,6 +2957,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port,
> > int *sink_pdo,
> >                               port->pps_data.supported = true;
> >                               port->usb_type =
> >                                       POWER_SUPPLY_USB_TYPE_PD_PPS;
> > +                             power_supply_changed(port->psy);
> >                       }
> >                       continue;
> >               default:
> > @@ -3112,6 +3115,7 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
> > tcpm_port *port)
> >                                                 port->pps_data.out_volt));
> >               port->pps_data.op_curr = min(port->pps_data.max_curr,
> >                                            port->pps_data.op_curr);
> > +             power_supply_changed(port->psy);
> >       }
> >
> >       return src_pdo;
>
> 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 ?
>
> > @@ -3347,6 +3351,7 @@ static int tcpm_set_charge(struct tcpm_port *port, bool
> > charge)
> >                       return ret;
> >       }
> >       port->vbus_charge = charge;
> > +     power_supply_changed(port->psy);
> >       return 0;
> >  }
> >
> > @@ -3530,6 +3535,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
> >       port->try_src_count = 0;
> >       port->try_snk_count = 0;
> >       port->usb_type = POWER_SUPPLY_USB_TYPE_C;
> > +     power_supply_changed(port->psy);
>
> This is already taken care of at the end of this function, isn't it?
I thought I deleted that. Looks like I didn't. Will send in a patch to
remove that.
Will wait for what we decide for the PPS case so that I can send in
both in the same patch.

Thanks,
Badhri

>
> >       port->nr_sink_caps = 0;
> >       port->sink_cap_done = false;
> >       if (port->tcpc->enable_frs)
> > @@ -5957,7 +5963,7 @@ static int tcpm_psy_set_prop(struct power_supply
> > *psy,
> >               ret = -EINVAL;
> >               break;
> >       }
> > -
> > +     power_supply_changed(port->psy);
> >       return ret;
> >  }
> >
> > @@ -6110,6 +6116,7 @@ struct tcpm_port *tcpm_register_port(struct device
> > *dev, struct tcpc_dev *tcpc)
> >       err = devm_tcpm_psy_register(port);
> >       if (err)
> >               goto out_role_sw_put;
> > +     power_supply_changed(port->psy);
> >
> >       port->typec_port = typec_register_port(port->dev, &port->typec_caps);
> >       if (IS_ERR(port->typec_port)) {
> > --
> > 2.31.0.rc2.261.g7f71774620-goog
>
Adam Thomson March 19, 2021, 4:32 p.m. UTC | #3
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.
Badhri Jagan Sridharan April 6, 2021, 1:43 a.m. UTC | #4
Hi Adam,

Just sent out a patch stack
https://patchwork.kernel.org/project/linux-usb/list/?series=461087
to address the issue that you mentioned here.

Thanks,
Badhri


On Mon, Apr 5, 2021 at 6:43 PM Badhri Jagan Sridharan <badhri@google.com> wrote:
>
> Hi Adam,
>
> Just sent out a patch stack https://patchwork.kernel.org/project/linux-usb/list/?series=461087
> to address the issue that you mentioned here.
>
> Thanks,
> Badhri
>
> On Fri, Mar 19, 2021 at 9:32 AM Adam Thomson <Adam.Thomson.Opensource@diasemi.com> wrote:
>>
>> 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.
>>
diff mbox series

Patch

diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 11d0c40bc47d..e8936ea17f80 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -945,6 +945,7 @@  static int tcpm_set_current_limit(struct tcpm_port *port, u32 max_ma, u32 mv)
 
 	port->supply_voltage = mv;
 	port->current_limit = max_ma;
+	power_supply_changed(port->psy);
 
 	if (port->tcpc->set_current_limit)
 		ret = port->tcpc->set_current_limit(port->tcpc, max_ma, mv);
@@ -2931,6 +2932,7 @@  static int tcpm_pd_select_pdo(struct tcpm_port *port, int *sink_pdo,
 
 	port->pps_data.supported = false;
 	port->usb_type = POWER_SUPPLY_USB_TYPE_PD;
+	power_supply_changed(port->psy);
 
 	/*
 	 * Select the source PDO providing the most power which has a
@@ -2955,6 +2957,7 @@  static int tcpm_pd_select_pdo(struct tcpm_port *port, int *sink_pdo,
 				port->pps_data.supported = true;
 				port->usb_type =
 					POWER_SUPPLY_USB_TYPE_PD_PPS;
+				power_supply_changed(port->psy);
 			}
 			continue;
 		default:
@@ -3112,6 +3115,7 @@  static unsigned int tcpm_pd_select_pps_apdo(struct tcpm_port *port)
 						  port->pps_data.out_volt));
 		port->pps_data.op_curr = min(port->pps_data.max_curr,
 					     port->pps_data.op_curr);
+		power_supply_changed(port->psy);
 	}
 
 	return src_pdo;
@@ -3347,6 +3351,7 @@  static int tcpm_set_charge(struct tcpm_port *port, bool charge)
 			return ret;
 	}
 	port->vbus_charge = charge;
+	power_supply_changed(port->psy);
 	return 0;
 }
 
@@ -3530,6 +3535,7 @@  static void tcpm_reset_port(struct tcpm_port *port)
 	port->try_src_count = 0;
 	port->try_snk_count = 0;
 	port->usb_type = POWER_SUPPLY_USB_TYPE_C;
+	power_supply_changed(port->psy);
 	port->nr_sink_caps = 0;
 	port->sink_cap_done = false;
 	if (port->tcpc->enable_frs)
@@ -5957,7 +5963,7 @@  static int tcpm_psy_set_prop(struct power_supply *psy,
 		ret = -EINVAL;
 		break;
 	}
-
+	power_supply_changed(port->psy);
 	return ret;
 }
 
@@ -6110,6 +6116,7 @@  struct tcpm_port *tcpm_register_port(struct device *dev, struct tcpc_dev *tcpc)
 	err = devm_tcpm_psy_register(port);
 	if (err)
 		goto out_role_sw_put;
+	power_supply_changed(port->psy);
 
 	port->typec_port = typec_register_port(port->dev, &port->typec_caps);
 	if (IS_ERR(port->typec_port)) {