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: <2ebce2e1-48d1-4d14-9772-b01d7f388641@ti.com>
Date: Thu, 15 Jan 2026 13:16:46 +0530
From: "Kumar, Udit" <u-kumar1@...com>
To: Gokul Praveen <g-praveen@...com>, 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>
Subject: Re: [PATCH v2] pwm: tiehrpwm: Enable EHRPWM controller before setting
 configuration


On 1/15/2026 11:44 AM, Gokul Praveen wrote:
> Hi Udit,
>
> On 15/01/26 10:50, Kumar, Udit wrote:
>> Hello Gokul,
>>
>> On 1/9/2026 11:21 AM, Gokul Praveen wrote:
>>> Hi Uwe,
>>>
>>>
>>> On 08/01/26 23:40, Uwe Kleine-König wrote:
>>>> Hello Gokul,
>>>>
>>>> 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.
>>>>
>>>> Best regards
>>>> Uwe
>>>
>>> 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.
>>>
>>> However, with the below command sequence, the duty cycle was getting 
>>> set properly
>>>
>>> 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
>>> /sys/class/pwm/pwmchip0/pwm0# echo 3000000 > duty_cycle
>>
>>
>> I don't think , this last call of setting duty_cycle , even will land 
>> in driver code .
>>
>>
>>
>
> Can you change the last command to the following. Ideally , it should 
> be a different duty cycle set to enter into the driver code.
>
> >> /sys/class/pwm/pwmchip0/pwm0# echo 6000000 > duty_cycle


Yes it will leads to entry into driver code.

But between below calls, (enable and set duty cycle again)

/sys/class/pwm/pwmchip0/pwm0# echo 1 > enable
/sys/class/pwm/pwmchip0/pwm0# echo 3000000 > duty_cycle

I don't see ehrpwm_pwm_disable will be called.


>
> Best Regards
> Gokul Praveen
>>>
>>>
>>> PWM is working only if we re-update the duty cycle after enabling 
>>> the module.
>>>
>>> If we do not re-update the duty cycle after enabling the module then 
>>> PWM signal line is being high(100 % duty) always.
>>>
>>> Test Environment: TI J784S4 EVM board.
>>>
>>> Best Regards
>>> Gokul Praveen
>>>
>>>
>>>
>