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] [thread-next>] [day] [month] [year] [list]
Message-ID: <r2jq72u3hfxrl4slgvuei2eobke37apebf67naxrvuabtcvaxe@pamwe3nejqge>
Date: Thu, 8 Jan 2026 12:33:10 +0100
From: Uwe Kleine-König <ukleinek@...nel.org>
To: Sean Nyekjaer <sean@...nix.com>
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

Hello Sean,

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.)

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").

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.)

Best regards
Uwe

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ