linux-kernel - Re: [PATCH 2/5] clocksource/drivers/timer-microchip-pit64b: add Microchip PIT64B support

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: <7267f37b-4f80-97e3-7a8e-bc1a9a28b995@linaro.org>
Date:   Fri, 31 May 2019 12:41:30 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Claudiu.Beznea@...rochip.com, alexandre.belloni@...tlin.com
Cc:     mark.rutland@....com, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Ludovic.Desroches@...rochip.com,
        robh+dt@...nel.org, tglx@...utronix.de,
        linux-arm-kernel@...ts.infradead.org,
        Arnd Bergmann <arnd.bergmann@...aro.org>
Subject: Re: [PATCH 2/5] clocksource/drivers/timer-microchip-pit64b: add
 Microchip PIT64B support


Hi Claudiu,


On 30/05/2019 09:46, Claudiu.Beznea@...rochip.com wrote:
> Hi Daniel,
> 
> Taking into account the discussion on this tread and the fact that we have
> no answer from Rob on this topic (I'm talking about [1]), what do you think
> it would be best for this driver to be accepted the soonest? Would it be OK
> for you to mimic the approach done by:
> 
> drivers/clocksource/timer-integrator-ap.c
> 
> with the following bindings in DT:
> 
> aliases {
> 	arm,timer-primary = &timer2;
> 	arm,timer-secondary = &timer1;
> };
> 
> also in PIT64B driver?
> 
> Or do you think re-spinning the Alexandre's patches at [2] (which seems to
> me like the generic way to do it) would be better?

This hardware / OS connection problem is getting really annoying for
everyone and this pattern is repeating itself since several years. It is
time we fix it properly.

The first solution looks hackish from my POV. The second approach looks
nicer and generic as you say. So I would vote for [2] but with the
flagging approach proposed by Mark [3].

I added Arnd in Cc in order to have its opinion.

[3]
https://lore.kernel.org/lkml/20171215113242.skmh5nzr7wqdmvnw@lakrids.cambridge.arm.com/

> [1]
> https://lore.kernel.org/lkml/20190408151155.20279-1-alexandre.belloni@bootlin.com/#t
> [2]
> https://lore.kernel.org/lkml/20171213185313.20017-1-alexandre.belloni@free-electrons.com/
> 






-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog