linux-kernel - Re: [PATCH] pwm: stm32: handle polarity change when PWM is enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <scu6yj7say5bnhbgyns4xrjbrzdayckk2ghn2a4xsgg4dswakv@6ushlcfw4dju>
Date: Thu, 08 Jan 2026 12:10:22 +0000
From: Sean Nyekjaer <sean@...nix.com>
To: Uwe Kleine-König <ukleinek@...nel.org>
Cc: Fabrice Gasnier <fabrice.gasnier@...s.st.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>, Alexandre Torgue <alexandre.torgue@...s.st.com>, linux-pwm@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] pwm: stm32: handle polarity change when PWM is enabled

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