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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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@google.com>
> ---
>  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