linux-kernel - Re: [PATCH v2] pwm: tiehrpwm: Enable EHRPWM controller before setting configuration

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: <xdj2ceubkss3ingkxdvc64zqrcd3wzz2uxa6wqwgvilu2ykukc@hbn6tt2gnxj5>
Date: Fri, 9 Jan 2026 23:53:22 +0100
From: Uwe Kleine-König <ukleinek@...nel.org>
To: Gokul Praveen <g-praveen@...com>
Cc: "Rafael V. Volkmer" <rafael.v.volkmer@...il.com>, j-keerthy@...com, 
	linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org, n-francis@...com, u-kumar1@...com
Subject: Re: [PATCH v2] pwm: tiehrpwm: Enable EHRPWM controller before
 setting configuration

Hello Gokul,

On Fri, Jan 09, 2026 at 11:21:46AM +0530, Gokul Praveen wrote:
> On 08/01/26 23:40, Uwe Kleine-König wrote:
> > On Thu, Jan 08, 2026 at 12:10:35PM +0530, Gokul Praveen wrote:
> > > On 08/01/26 01:17, Rafael V. Volkmer wrote:
> > > > Thanks for CC'ing me on this thread.
> > > > 
> > > > On 07/01/26 15:21, Uwe Kleine-König wrote:
> > > > > adding Rafael to Cc: who sent a patch series for this driver that I
> > > > > didn't come around to review yet. Given that neither he nor me noticed
> > > > > the problem addressed in this patch I wonder if it applies to all
> > > > > hardware variants.
> > > > > 
> > > > 
> > > > I also didn't observe the issue described here in my testing: duty cycle and
> > > > period changes always appeared to take effect as expected.
> > > > 
> > > > My tests were done on an AM623 EVM.
> > > > 
> > > > One possible explanation is that my test flow mostly exercised configuration
> > > > while the PWM was already enabled/active, which could mask the effect of a
> > > > put_sync/reset happening after configuration.
> > > > 
> > > 
> > > Yes, this is the reason why the configuration was taking effect for you ,
> > > Rafael, as the PWM was already enabled when setting the configuration hence
> > > masking the effect of a put_sync/reset happening after configuration.
> > 
> > Can you provide a list of commands that show the failure? That would
> > result in less guessing for me. My plan is to reproduce the failure
> > tomorrow to better understand it on my boneblack.
> 
> Sure Uwe. These are the commands I have tried for PWM signal generation:
> 
> cd /sys/class/pwm/pwmchip0
> /sys/class/pwm/pwmchip0# echo 0 > export
> /sys/class/pwm/pwmchip0# cd pwm0/
> /sys/class/pwm/pwmchip0/pwm0# echo 10000000 > period
> /sys/class/pwm/pwmchip0/pwm0# echo 3000000 > duty_cycle
> /sys/class/pwm/pwmchip0/pwm0# echo "normal" > polarity
> /sys/class/pwm/pwmchip0/pwm0# echo 1 > enable
> 
> Once these commands were executed, I measured the PWM signal using logic
> analyzer and the duty cycle was 100% even though we had set 30% duty cycle
> through the sysfs nodes.

After that sequence I "see" a 30% relative duty cycle on my boneblack.
(With the follwing patch applied on top of pwm/for-next:

diff --git a/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts b/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts
index b4fdcf9c02b5..a3f4a4bb64e4 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts
@@ -173,3 +173,25 @@ &gpio3 {
 &baseboard_eeprom {
 	vcc-supply = <&ldo4_reg>;
 };
+
+&am33xx_pinmux {
+	ehrpwm0_pins: ehrpwm0-pins {
+		pinctrl-single,pins = <
+			/* P9.21 UART2_TXD -> ehrpwm0B */
+			AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_OUTPUT_PULLDOWN, MUX_MODE3)
+			/* P9.22 UART2_RXD -> ehrpwm0A */
+			AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_OUTPUT_PULLDOWN, MUX_MODE3)
+		>;
+	};
+};
+
+&ehrpwm0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ehrpwm0_pins>;
+
+	status = "okay";
+};
+
+&epwmss0 {
+	status = "okay";
+};

)

That makes me think the problem isn't understood well yet and needs more
research. @Rafael, does the problem reproduce for you with Gokul's
recipe? (Or did you try that already? I understood your reply as "I
didn't encounter the issue but also didn't test specifically for that.")

As I cannot reproduce the issue, can you please check if adding

	pm_runtime_get_sync(pwmchip_parent(chip));

to the probe function makes the problem disappear? Also please boot with

	trace_event=pwm

on the command line and provide the content of
/sys/kernel/debug/tracing/trace after reproducing the problem.

Best regards
Uwe

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