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