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] [thread-next>] [day] [month] [year] [list]

Message-ID: <741ec8db-7804-4f31-969b-10724ec06823@ti.com>
Date: Mon, 12 Jan 2026 11:21:50 +0530
From: Gokul Praveen <g-praveen@...com>
To: Uwe Kleine-König <ukleinek@...nel.org>
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>, Gokul Praveen <g-praveen@...com>
Subject: Re: [PATCH v2] pwm: tiehrpwm: Enable EHRPWM controller before setting
 configuration

Hi Uwe,


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.

sure Uwe, I will try this from my side.

In the meantime, will you able to test the same on TI J784S4 EVM as the 
issue was reproduced on this board.

> 
> Best regards
> Uwe