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]
Date:   Fri, 24 Nov 2023 12:07:17 +0000
From:   "Sayyed, Mubin" <mubin.sayyed@....com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
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

Hi,

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> Sent: Friday, November 24, 2023 5:06 PM
> To: Sayyed, Mubin <mubin.sayyed@....com>
> Cc: linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org;
> devicetree@...r.kernel.org; linux-pwm@...r.kernel.org; git (AMD-Xilinx)
> <git@....com>; mubin10@...il.com; krzysztof.kozlowski+dt@...aro.org;
> u.kleine-koenig@...gutronix.de; thierry.reding@...il.com;
> robh+dt@...nel.org; conor+dt@...nel.org; tglx@...utronix.de;
> 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 12:03, Sayyed, Mubin wrote:
> > Hi Krzysztof,
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> >> Sent: Wednesday, November 15, 2023 5:41 PM
> >> To: Sayyed, Mubin <mubin.sayyed@....com>
> >> Cc: linux-arm-kernel@...ts.infradead.org;
> >> linux-kernel@...r.kernel.org; devicetree@...r.kernel.org;
> >> linux-pwm@...r.kernel.org; git (AMD-Xilinx) <git@....com>;
> >> mubin10@...il.com; krzysztof.kozlowski+dt@...aro.org;
> >> u.kleine-koenig@...gutronix.de; thierry.reding@...il.com;
> >> robh+dt@...nel.org; conor+dt@...nel.org; tglx@...utronix.de;
> >> 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 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@...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.

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

Thanks,
Mubin

> 
> Best regards,
> Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ