| 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
| ||
|
Message-ID: <nj2xtbprctszessuedsxkdvpbjywcruwoo3ioyfrfdbt5lemg3@eri5iorsajo3>
Date: Thu, 15 Jan 2026 18:17:44 +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
On Thu, Jan 15, 2026 at 04:02:16PM +0530, Gokul Praveen wrote:
> Hi Uwe,
>
> Apologies for the delay as it took some time for me to get the trace output
> as well as to get the way I reproduced the issue.
>
>
> On 10/01/26 04:23, Uwe Kleine-König wrote:
> > 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.
> >
>
> PWM EVENT TRACING OUTPUT:
> =========================
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 3/3 #P:8
> #
> # _-----=> irqs-off/BH-disabled
> # / _----=> need-resched
> # | / _---=> hardirq/softirq
> # || / _--=> preempt-depth
> # ||| / _-=> migrate-disable
> # |||| / delay
> # TASK-PID CPU# ||||| TIMESTAMP FUNCTION
> # | | | ||||| | |
> gen_pwm.sh-1039 [000] ..... 88.564669: pwm_apply: pwmchip0.1:
> period=100000000 duty_cycle=0 polarity=0 enabled=0 err=0
> gen_pwm.sh-1039 [000] ..... 88.564728: pwm_apply: pwmchip0.1:
> period=100000000 duty_cycle=30000000 polarity=0 enabled=0 err=0
> gen_pwm.sh-1039 [000] ..... 88.565065: pwm_apply: pwmchip0.1:
> period=100000000 duty_cycle=30000000 polarity=0 enabled=1 err=0
>
> The trace output might mislead us thinking that the duty cycle is set
> properly as the event tracer reads the duty_cycle variable which gets set
> irrespective of whether the value gets reflected in the pwm registers or
> not.
Can you please also enable CONFIG_PWM_DEBUG? That should show the values
actually used as it enables a few calls to .get_state().
Best regards
Uwe
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists