linux-kernel - Re: [PATCH 1/2] dt-bindings: counter: Add new ti,omap-dmtimer-cap compatible

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: <ea4f6245-631b-45b7-a432-a5c417c5a9ae@kernel.org>
Date: Tue, 7 Oct 2025 23:32:23 +0900
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Gokul Praveen <g-praveen@...com>, j-keerthy@...com, vigneshr@...com,
 wbg@...nel.org, linux-kernel@...r.kernel.org, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org
Cc: u-kumar1@...com, n-francis@...com
Subject: Re: [PATCH 1/2] dt-bindings: counter: Add new ti,omap-dmtimer-cap
 compatible

On 07/10/2025 18:49, Gokul Praveen wrote:
> Hi Krzysztof,
> 
> On 07/10/25 15:09, Krzysztof Kozlowski wrote:
>> On 07/10/2025 18:23, Gokul Praveen wrote:
>>> Hi Krzysztof,
>>>
>>>
>>> On 07/10/25 12:05, Krzysztof Kozlowski wrote:
>>>> On 26/09/2025 18:06, Gokul Praveen wrote:
>>>>>>
>>>>>>> +
>>>>>>> +  ti,timers:
>>>>>>> +    description: Timer instance phandle for the Capture
>>>>>>
>>>>>> So the only resource is phandle? That's completely fake device then. NAK.
>>>>>>
>>>>>
>>>>>
>>>>> The OMAP Timer IP can operate in 3 modes: Timer, PWM mode or capture
>>>>> (mutually exclusive).
>>>>> The timer/ti,timer-dm.yaml file describes the timer mode of operation.
>>>>> It encapsulates base IP block and reg property is also part the same
>>>>> binding.
>>>>>
>>>>> This node represents the capture mode with phandle reference to the
>>>>> timer DT node. This is modeled all the same lines as how PWM
>>>>> functionality is implemented in pwm/ti,omap-dmtimer-pwm.yaml
>>>>
>>>> Different modes do not have their own device nodes. It is still one
>>>> device, so one device node.
>>>>
>>>>>
>>>>> Now, if this needs to change, please suggest alternate.
>>>>>
>>>>> One solution is perhaps to add a new property to ti,timer-dm.yaml itself
>>>>> to indicate the mode of IP?
>>>>
>>>> Not sure, depends what this really is and how it is used. I can also
>>>> imagine that consumer defines the mod of operation.
>>>>
>>>
>>> For a timer operating in capture mode, there are no consumers actually
>>> and the only way we use it is through sysfs.
>>>
>>> Would it be good enough if I have a separate "mode" property for the
>>> dmtimer device node just like how it is done for USB as follows where
>>> the usb device node has a "dr_mode" property to decide on whether the
>>> usb should act in host, device or otg mode.
>>
>>
>> No, because of all my other comments in previous email.
>>
>>
> Will having a separate sysfs property for enabling capture mode in 
> dmtimer be a viable solution, which will then eliminate the need for a 
> device tree property?
> 
> It would be great to hear your feedback on this, krzysztof.

Could be, if this can be a runtime property. My questions and doubts are
indeed not a very clear guidance, partially because I don't know all use
cases for this hardware.

Lack of PWM consumer is already an indication for the driver to
configure it in other mode, for example.

But think rather why choice of mode would be board-level static
configuration. If you cannot answer that, then it should not be a DT
property most likely.

Best regards,
Krzysztof