[LINUX PATCH v2 1/3] clocksource: timer-cadence-ttc: Do not probe TTC device configured as PWM

Krzysztof Kozlowski krzysztof.kozlowski at linaro.org
Fri Nov 24 03:35:44 PST 2023


On 24/11/2023 12:03, Sayyed, Mubin wrote:
> Hi Krzysztof,
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>> Sent: Wednesday, November 15, 2023 5:41 PM
>> To: Sayyed, Mubin <mubin.sayyed at amd.com>
>> Cc: linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
>> devicetree at vger.kernel.org; linux-pwm at vger.kernel.org; git (AMD-Xilinx)
>> <git at amd.com>; mubin10 at gmail.com; krzysztof.kozlowski+dt at linaro.org;
>> u.kleine-koenig at pengutronix.de; thierry.reding at gmail.com;
>> robh+dt at kernel.org; conor+dt at kernel.org; tglx at linutronix.de;
>> daniel.lezcano at linaro.org; Simek, Michal <michal.simek at amd.com>
>> Subject: Re: [LINUX PATCH v2 1/3] clocksource: timer-cadence-ttc: Do not probe
>> TTC device configured as PWM
>>
>> On 15/11/2023 06:55, Sayyed, Mubin wrote:
>>>>> +	/*
>>>>> +	 * If pwm-cells property is present in TTC node,
>>>>> +	 * it would be treated as PWM device.
>>>>> +	 */
>>>>> +	if (of_property_read_bool(timer, "#pwm-cells"))
>>>>> +		return -ENODEV;
>>>>
>>>> You will introduce dmesg errors, so regressions.
>>>>
>>> [Mubin]: I will change it to "return 0" to avoid dmesg errors.
>>
>> No, because solution is wrong.
>>
>>>
>>>> This does not look right. What you want is to bind one device driver
>>>> and choose different functionality based on properties.
>>> [Mubin]:  I am doing it based on earlier discussion related to AXI Timer PWM
>> driver.  It was suggested to use #pwm-cells property for identifying role of
>> device(PWM/clocksource) https://lore.kernel.org/linux-
>> devicetree/20210513021631.GA878860 at robh.at.kernel.org/.
>>
>> You are mixing bindings with driver. I said here about driver and yes - you must
>> use pwm-cells to differentiate that. It's obvious.
>>
>> So again, one driver binding.
> [Mubin]: I will explore whether mfd framework can be used to handle this.

You do not need MFD for this, because you do not have a really MFD. This
is just one device, so I expect here one driver. Why do you need
multiple drivers (which also would solve that problem but why?)?

Best regards,
Krzysztof




More information about the linux-arm-kernel mailing list