On Tue, Sep 10, 2019 at 4:11 PM Alexandre Belloni <alexa****@bootl*****> wrote: > On 10/09/2019 16:08:26+0100, Sudeep Holla wrote: > > On Tue, Sep 10, 2019 at 02:51:50PM +0000, Claud****@micro***** wrote: > > In that case, why can't we identify capability that with the compatibles > > for this timer IP ? > > > > IOW, I don't like the proposal as it's hardware limitation. > > To be clear, bot timers are exactly the same but can't be clocksource > and clockevent at the same time. Why would we have different compatibles > for the exact same IP? In that case why not just pick the first one you find as clocksource and the second one as clock event? As they all come to the same timer of init function two simple local state variables can solve that: static bool registered_clocksource; static bool registered_clockevent; probe(timer) { if (!registered_clocksource) { register_clocksource(timer); registrered_clocksource = true; return; } if (!registered_clockevent) { register_clockevent(timer); registered_clockevent = true; return; } pr_info("surplus timer %p\n", timer); } Clocksource and clockevent are natural singletons so there is no need to handle more than one of each in a driver for identical hardware. With the Integrator AP timer there is a real reason to select one over the other but as I replied to that patch it is pretty easy to just identify which block has this limitation by simply commenting out the IRQ line for it from the device tree. Maybe there is something about this I don't understand. Yours, Linus Walleij
Fork