diff options
author | 2025-07-31 13:27:00 -0700 | |
---|---|---|
committer | 2025-07-31 13:27:00 -0700 | |
commit | 602a0672869499fefa31b7f1e22f9d32c35fc7fe (patch) | |
tree | 12d84c5fb872dd8054df7be75a44fe4dabd6a396 /drivers/net/wireless/intel/iwlwifi/mld/tests/utils.c | |
parent | gpu: nova-core: fix up formatting after merge (diff) | |
parent | pwm: imx-tpm: Reset counter if CMOD is 0 (diff) | |
download | wireguard-linux-602a0672869499fefa31b7f1e22f9d32c35fc7fe.tar.xz wireguard-linux-602a0672869499fefa31b7f1e22f9d32c35fc7fe.zip |
Merge tag 'pwm/for-6.17-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux
Pull pwm fixes from Uwe Kleine-König:
"Two fixes for the mediatek and the imx-tpm driver. Both are old
(v4.12-rc1 and v5.2-rc1 respectively).
The mediatek issue is that both period and duty_cycle were configured
to higher values than requested. For most applications the period part
is no tragedy, but a PWM that is configured for duty_cycle = 0 should
really emit a constant inactive signal. That was noticed by an LED not
being completely off in this case (two commits for one fix: a
preparatory one and the actual fix in the second one).
For the imx-tpm PWM driver the fixed issue is that the first period is
quite a bit too long under some circumstances. So it might take up to
UINT32_MAX << 7 clock ticks until the PWM starts toggling. With an
assumed input clock rate of 166 MHz (completely made up) that's 55
minutes"
* tag 'pwm/for-6.17-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux:
pwm: imx-tpm: Reset counter if CMOD is 0
pwm: mediatek: Fix duty and period setting
pwm: mediatek: Handle hardware enable and clock enable separately
Diffstat (limited to 'drivers/net/wireless/intel/iwlwifi/mld/tests/utils.c')
0 files changed, 0 insertions, 0 deletions