[PATCH] pwm: stm32: handle polarity change when PWM is enabled

[Sean Nyekjaer]

Hi,
On Thu, Jan 08, 2026 at 12:33:10PM +0100, Uwe Kleine-König wrote:
> On Thu, Jan 08, 2026 at 06:44:06AM +0000, Sean Nyekjaer wrote:
> > I hope that clarifies things :)
> 
> It does. I'm convinced the following patch implements a simpler fix:
> 
> diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
> index eb24054f9729..86e6eb7396f6 100644
> --- a/drivers/pwm/pwm-stm32.c
> +++ b/drivers/pwm/pwm-stm32.c
> @@ -458,8 +458,7 @@ static int stm32_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>  		return 0;
>  	}
>  
> -	if (state->polarity != pwm->state.polarity)
> -		stm32_pwm_set_polarity(priv, pwm->hwpwm, state->polarity);
> +	stm32_pwm_set_polarity(priv, pwm->hwpwm, state->polarity);
>  
>  	ret = stm32_pwm_config(priv, pwm->hwpwm,
>  			       state->duty_cycle, state->period);
> 
> While is isn't optimal as it might write the polarity into hardware when
> it's not necessary, the same holds true for the values for duty_cycle
> and period. Compared to your patch this is simple enough to make me ok
> with applying it to 6.12.x (and older stable kernels) without an
> equivalent commit in mainline. (Backporting the waveform stuff is out of
> the question IMNSHO.)

The above does work, I have also checked that it doesn't write the
polarity if the PWM is active.
Agree, with the backporting part :)

> 
> Also I'm still convinced that 7edf7369205b isn't the correct commit to
> blame. This one changes the preconditions for the problem to occur (and
> thus it's plausible that it's the result of your bisection), but even
> before 7edf7369205b the problem can happen with:
> 
> 	pwm_apply(mypwm, &(struct pwm_state){ .enabled = true, .polarity = PWM_POLARITY_NORMAL, .period = DC, .duty_cycle = DC });
> 	pwm_apply(mypwm, &(struct pwm_state){ .enabled = false, .polarity = PWM_POLARITY_INVERSED, .period = DC, .duty_cycle = DC });
> 	pwm_apply(mypwm, &(struct pwm_state){ .enabled = true, .polarity = PWM_POLARITY_INVERSED, .period = DC, .duty_cycle = DC });
> 
> After the 1st call polarity is configured to normal (unless the bug
> happens already earlier :-), the 2nd disables the hardware without
> configuration of the polarity (before and after 7edf7369205b), and the
> third skips setting of the polarity because state->polarity already
> matches pwm->state.polarity. The original problem exists since 
> 7edf7369205b ("pwm: Add driver for STM32 plaftorm").
> 
I will move the fixes tag.

> Are you able to create an improved patch with these insights in a timely
> manner? (Grab authorship for yourself and honoring my part with a
> Co-developed-by is fine for me.)
I'll do it now and add the Co-developd-by tag

/Sean