<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/pwm, branch v6.12.92</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.92</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.92'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-05-23T11:04:50+00:00</updated>
<entry>
<title>pwm: atmel-tcb: Cache clock rates and mark chip as atomic</title>
<updated>2026-05-23T11:04:50+00:00</updated>
<author>
<name>Sangyun Kim</name>
<email>sangyun.kim@snu.ac.kr</email>
</author>
<published>2026-04-19T08:08:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dd60f26fd8a4cd4007dbc976dc71f679d11aa0ec'/>
<id>urn:sha1:dd60f26fd8a4cd4007dbc976dc71f679d11aa0ec</id>
<content type='text'>
[ Upstream commit 68637b68afcc3cb4d56aca14a3a1d1b47b879369 ]

atmel_tcb_pwm_apply() holds tcbpwmc-&gt;lock as a spinlock via
guard(spinlock)() and then calls atmel_tcb_pwm_config(), which calls
clk_get_rate() twice. clk_get_rate() acquires clk_prepare_lock (a
mutex), so this is a sleep-in-atomic-context violation.

On CONFIG_DEBUG_ATOMIC_SLEEP kernels every pwm_apply_state() that
enables or reconfigures the PWM triggers a "BUG: sleeping function
called from invalid context" warning.

Acquire exclusive control over the clock rates with
clk_rate_exclusive_get() at probe time and cache the rates in struct
atmel_tcb_pwm_chip, then read the cached rates from
atmel_tcb_pwm_config(). This keeps the spinlock-based mutual exclusion
introduced in commit 37f7707077f5 ("pwm: atmel-tcb: Fix race condition
and convert to guards") and removes the sleeping calls from the atomic
section.

With no sleeping calls left in .apply() and the regmap-mmio bus already
running with fast_io=true, also mark the chip as atomic so consumers
can use pwm_apply_atomic() from atomic context.

Fixes: 37f7707077f5 ("pwm: atmel-tcb: Fix race condition and convert to guards")
Signed-off-by: Sangyun Kim &lt;sangyun.kim@snu.ac.kr&gt;
Link: https://patch.msgid.link/20260419080838.3192357-1-sangyun.kim@snu.ac.kr
[ukleinek: Ensure .clk is enabled before calling clk_get_rate on it.]
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pwm: imx-tpm: Count the number of enabled channels in probe</title>
<updated>2026-05-07T04:09:35+00:00</updated>
<author>
<name>Viorel Suman (OSS)</name>
<email>viorel.suman@oss.nxp.com</email>
</author>
<published>2026-03-11T12:33:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3eddea5e620c66f90a3e96979e24fea470e20005'/>
<id>urn:sha1:3eddea5e620c66f90a3e96979e24fea470e20005</id>
<content type='text'>
commit 3962c24f2d14e8a7f8a23f56b7ce320523947342 upstream.

On a soft reset TPM PWM IP may preserve its internal state from previous
runtime, therefore on a subsequent OS boot and driver probe
"enable_count" value and TPM PWM IP internal channels "enabled" states
may get unaligned. In consequence on a suspend/resume cycle the call "if
(--tpm-&gt;enable_count == 0)" may lead to "enable_count" overflow the
system being blocked from entering suspend due to:

   if (tpm-&gt;enable_count &gt; 0)
       return -EBUSY;

Fix the problem by counting the enabled channels in probe function.

Signed-off-by: Viorel Suman (OSS) &lt;viorel.suman@oss.nxp.com&gt;
Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support")
Link: https://patch.msgid.link/20260311123309.348904-1-viorel.suman@oss.nxp.com
Cc: stable@vger.kernel.org
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>pwm: stm32: Always program polarity</title>
<updated>2026-01-11T14:25:21+00:00</updated>
<author>
<name>Sean Nyekjaer</name>
<email>sean@geanix.com</email>
</author>
<published>2026-01-08T12:45:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=69f542a54578a2854f6f2b5e87eec2a1504a008d'/>
<id>urn:sha1:69f542a54578a2854f6f2b5e87eec2a1504a008d</id>
<content type='text'>
Commit 7346e7a058a2 ("pwm: stm32: Always do lazy disabling") triggered a
regression where PWM polarity changes could be ignored.

stm32_pwm_set_polarity() was skipped due to a mismatch between the
cached pwm-&gt;state.polarity and the actual hardware state, leaving the
hardware polarity unchanged.

Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm")
Cc: stable@vger.kernel.org # &lt;= 6.12
Signed-off-by: Sean Nyekjaer &lt;sean@geanix.com&gt;
Co-developed-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
</content>
</entry>
<entry>
<title>pwm: bcm2835: Make sure the channel is enabled after pwm_request()</title>
<updated>2025-12-18T12:55:02+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@baylibre.com</email>
</author>
<published>2025-11-18T17:43:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=157cf2b51d74f1934396d7a291c519408ca997f5'/>
<id>urn:sha1:157cf2b51d74f1934396d7a291c519408ca997f5</id>
<content type='text'>
[ Upstream commit cda323dbda76600bf9761970d58517648f0de67d ]

The .free callback cleared among others the enable bit PWENx in the
control register. When the PWM is requested later again this bit isn't
restored but the core assumes the PWM is enabled and thus skips a
request to configure the same state as before.

To fix that don't touch the hardware configuration in .free(). For
symmetry also drop .request() and configure the mode completely in
.apply().

Fixes: e5a06dc5ac1f ("pwm: Add BCM2835 PWM driver")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Link: https://patch.msgid.link/20251118174303.1761577-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pwm: pca9685: Use bulk write to atomicially update registers</title>
<updated>2025-11-13T20:34:05+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@baylibre.com</email>
</author>
<published>2025-07-29T10:36:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b89e25efa2bd13de66eb153097fed60ec08bd72d'/>
<id>urn:sha1:b89e25efa2bd13de66eb153097fed60ec08bd72d</id>
<content type='text'>
[ Upstream commit de5855613263b426ee697dd30224322f2e634dec ]

The output of a PWM channel is configured by four register values. Write
them in a single i2c transaction to ensure glitch free updates.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Link: https://lore.kernel.org/r/bfa8c0267c9ec059d0d77f146998d564654c75ca.1753784092.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pwm: berlin: Fix wrong register in suspend/resume</title>
<updated>2025-10-19T14:33:52+00:00</updated>
<author>
<name>Jisheng Zhang</name>
<email>jszhang@kernel.org</email>
</author>
<published>2025-08-19T11:42:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d9457e6258750692c3b27f80880a613178053c25'/>
<id>urn:sha1:d9457e6258750692c3b27f80880a613178053c25</id>
<content type='text'>
commit 3a4b9d027e4061766f618292df91760ea64a1fcc upstream.

The 'enable' register should be BERLIN_PWM_EN rather than
BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there
will be cpu exception then kernel panic during suspend/resume.

Fixes: bbf0722c1c66 ("pwm: berlin: Add suspend/resume support")
Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Link: https://lore.kernel.org/r/20250819114224.31825-1-jszhang@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>pwm: tiehrpwm: Fix corner case in clock divisor calculation</title>
<updated>2025-10-15T10:00:01+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@baylibre.com</email>
</author>
<published>2025-08-11T16:01:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b38bcdba1107df9c597f0a4124d7e860f8ae6512'/>
<id>urn:sha1:b38bcdba1107df9c597f0a4124d7e860f8ae6512</id>
<content type='text'>
[ Upstream commit 00f83f0e07e44e2f1fb94b223e77ab7b18ee2d7d ]

The function set_prescale_div() is responsible for calculating the clock
divisor settings such that the input clock rate is divided down such that
the required period length is at most 0x10000 clock ticks. If period_cycles
is an integer multiple of 0x10000, the divisor period_cycles / 0x10000 is
good enough. So round up in the calculation of the required divisor and
compare it using &gt;= instead of &gt;.

Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Link: https://lore.kernel.org/r/85488616d7bfcd9c32717651d0be7e330e761b9c.1754927682.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pwm: tiehrpwm: Fix various off-by-one errors in duty-cycle calculation</title>
<updated>2025-10-15T10:00:01+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@baylibre.com</email>
</author>
<published>2025-08-11T16:01:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a048bb2d4f8fa3153d317e6fc5e35cddf9a0f36f'/>
<id>urn:sha1:a048bb2d4f8fa3153d317e6fc5e35cddf9a0f36f</id>
<content type='text'>
[ Upstream commit bc7ce5bfc504eea9eac0eb0215017b9fcfc62c59 ]

In Up-Count Mode the timer is reset to zero one tick after it reaches
TBPRD, so the period length is (TBPRD + 1) * T_TBCLK. This matches both
the documentation and measurements. So the value written to the TBPRD has
to be one less than the calculated period_cycles value.

A complication here is that for a 100% relative duty-cycle the value
written to the CMPx register has to be TBPRD + 1 which might overflow if
TBPRD is 0xffff. To handle that the calculation of the AQCTLx register
has to be moved to ehrpwm_pwm_config() and the edge at CTR = CMPx has to
be skipped.

Additionally the AQCTL_PRD register field has to be 0 because that defines
the hardware's action when the maximal counter value is reached, which is
(as above) one clock tick before the period's end. The period start edge
has to happen when the counter is reset and so is defined in the AQCTL_ZRO
field.

Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Link: https://lore.kernel.org/r/dc818c69b7cf05109ecda9ee6b0043a22de757c1.1754927682.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pwm: tiehrpwm: Make code comment in .free() more useful</title>
<updated>2025-10-15T10:00:01+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@baylibre.com</email>
</author>
<published>2025-08-11T16:01:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6599fff32020d092497f1b109deaa2613edda799'/>
<id>urn:sha1:6599fff32020d092497f1b109deaa2613edda799</id>
<content type='text'>
[ Upstream commit 878dbfc12cc52b17d79d205560c0fafcf5332b13 ]

Instead of explaining trivia to everyone who can read C describe the
higher-level effect of setting pc-&gt;period_cycles[pwm-&gt;hwpwm] to zero.

Fixes: 01b2d4536f02 ("pwm: pwm-tiehrpwm: Fix conflicting channel period setting")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Link: https://lore.kernel.org/r/4c38dd119a77d7017115318a3f2c50bde62a6f21.1754927682.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pwm: tiehrpwm: Don't drop runtime PM reference in .free()</title>
<updated>2025-10-15T10:00:01+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@baylibre.com</email>
</author>
<published>2025-08-11T16:00:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0a953be6e35c67187d8c42cc1427a10e8247ed68'/>
<id>urn:sha1:0a953be6e35c67187d8c42cc1427a10e8247ed68</id>
<content type='text'>
[ Upstream commit 21a5e91fda50fc662ce1a12bd0aae9d103455b43 ]

The pwm driver calls pm_runtime_get_sync() when the hardware becomes
enabled and pm_runtime_put_sync() when it becomes disabled. The PWM's
state is kept when a consumer goes away, so the call to
pm_runtime_put_sync() in the .free() callback is unbalanced resulting in
a non-functional device and a reference underlow for the second consumer.

The easiest fix for that issue is to just not drop the runtime PM
reference in .free(), so do that.

Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Link: https://lore.kernel.org/r/bbb089c4b5650cc1f7b25cf582d817543fd25384.1754927682.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König &lt;ukleinek@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
