Re: [PATCH v1 2/6] usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply

From: Greg Kroah-Hartman
Date: Tue Apr 06 2021 - 10:14:58 EST


On Mon, Apr 05, 2021 at 06:36:39PM -0700, Badhri Jagan Sridharan wrote:
> tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt,
> port->pps_data.max_volt, port->pps_data.max_curr even before
> port partner accepts the requests. This leaves incorrect values
> in current_limit and supply_voltage that get exported by
> "tcpm-source-psy-". Solving this problem by caching the request
> values in req_min_volt, req_max_volt, req_max_curr, req_out_volt,
> req_op_curr. min_volt, max_volt, max_curr gets updated once the
> partner accepts the request. current_limit, supply_voltage gets updated
> once local port's tcpm enters SNK_TRANSITION_SINK when the accepted
> current_limit and supply_voltage is enforced.
>
> Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply")
> Signed-off-by: Badhri Jagan Sridharan <badhri@xxxxxxxxxx>
> ---
> drivers/usb/typec/tcpm/tcpm.c | 84 ++++++++++++++++++++---------------
> 1 file changed, 49 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 03eca5061132..d43774cc2ccf 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -269,11 +269,22 @@ struct pd_mode_data {
> };
>
> struct pd_pps_data {
> + /* Actual min voltage at the local port */
> u32 min_volt;
> + /* Requested min voltage to the port partner */
> + u32 req_min_volt;
> + /* Actual max voltage at the local port */
> u32 max_volt;
> + /* Requested max voltage to the port partner */
> + u32 req_max_volt;
> + /* Actual max current at the local port */
> u32 max_curr;
> - u32 out_volt;
> - u32 op_curr;
> + /* Requested max current of the port partner */
> + u32 req_max_curr;
> + /* Requested output voltage to the port partner */
> + u32 req_out_volt;
> + /* Requested operating current to the port partner */
> + u32 req_op_curr;

Shouldn't you just document this all properly in a kerneldoc header
right above the structure?

thanks,

greg k-h