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: <9fb984b3-331b-45ce-8f82-03bc476acd3c@linaro.org>
Date:   Fri, 24 Nov 2023 17:24:04 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     "Sayyed, Mubin" <mubin.sayyed@....com>
Cc:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
        "git (AMD-Xilinx)" <git@....com>,
        "mubin10@...il.com" <mubin10@...il.com>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
        "Simek, Michal" <michal.simek@....com>
Subject: Re: [LINUX PATCH v2 1/3] clocksource: timer-cadence-ttc: Do not probe
 TTC device configured as PWM

On 24/11/2023 13:07, Sayyed, Mubin wrote:

>>>>>> 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@...h.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?)?
> Cadence TTC IP can be used as timer(clocksource/clockevent) and PWM device.
> We have drivers/clocksource/timer-cadence-ttc.c for clocksource/clockevent functionality. 
> New driver for PWM functionality will be added to drivers/pwm/pwm-cadence.c (3/3 of this
> Series).  In given SoC,  multiple instances of TTC IP are possible(ZynqMP  Ultrscale SoC has 4
> Instances), few of them could be configured as clocksource/clockevent devices and others
> as PWM ones. So,  cloksource as well as PWM drivers for cadence TTC IP would be enabled in 
> the kernel. 
> 
> Now in this scenario, each TTC device would be matching with 2 drivers, clocksource and PWM, since
> compatible string is same.  If I don’t add #pwm-cells checking in clocksource driver and return 
> -ENODEV based on that, each device would always bind with clocksource driver. PWM driver 
> would never probe since clocksource driver probes ahead of PWM one in probing order.

None of these above explain why you need two drivers.

> 
> I am exploring mfd to deal with said scenario. Do you see any better way to handle this? 

You basically repeated previous sentence about MFD without answering.
Yeah, better way could be to have one driver. Why you cannot have it
that way?


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ