[PATCH 3/3] pwm: Handle .get_state() failures
Thierry Reding
thierry.reding at gmail.com
Wed Sep 28 12:55:49 UTC 2022
On Fri, Sep 16, 2022 at 05:15:06PM +0200, Uwe Kleine-König wrote:
> This suppresses diagnosis for PWM_DEBUG routines and makes sure that
> pwm->state isn't modified in pwm_device_request() if .get_state() fails.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig at pengutronix.de>
> ---
> drivers/pwm/core.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 381db04cfa00..421573590613 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -108,9 +108,14 @@ static int pwm_device_request(struct pwm_device *pwm, const char *label)
> }
>
> if (pwm->chip->ops->get_state) {
> - err = pwm->chip->ops->get_state(pwm->chip, pwm, &pwm->state);
> + struct pwm_state state;
> +
> + err = pwm->chip->ops->get_state(pwm->chip, pwm, &state);
> trace_pwm_get(pwm, &pwm->state, err);
>
> + if (!err)
> + pwm->state = state;
So basically this means that callers of pwm_get_state() will get the
zeroed out pwm->state. This can cause issues with the likes of
pwm_set_relative_duty_cycle() which many drivers would use. Do we
perhaps want to set an internal error in this case so that it can be
propagated to callers in pwm_get_state()? That would allow them to fall
back to some default configuration rather than potentially breaking
altogether.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220928/635616dd/attachment.sig>
More information about the dri-devel
mailing list