[PATCH v9 1/9] clocksource: time-armada-370-xp: Marvell Armada 370/XP SoC timer driver
Nicolas Pitre
nico at fluxnic.net
Wed Jul 18 21:41:06 EDT 2012
On Wed, 18 Jul 2012, John Stultz wrote:
> I'm also not a huge fan of adding clockevent drivers to drivers/clocksource/.
>
> Further, LinusW and I have different opinions on this (and its not that huge
> of an issue), but I'd really prefer to see additions to drivers/clocksource be
> only for clocksources that are likely to be shared *between architectures*.
This is contrary to the push we've made for about 2 years now. We
decided it is more beneficial to gather drivers according to their
purpose and not according to the architecture they belong to. The
reason is that it is far easier to abstract common functionality if
those drivers are close by.
> Similarly, I'd prefer architecture specific clocksources (like TSC on x86,
> timebase on ppc, etc) stay in the arch subdir, just so theirs a clear
> ownership of the driver (ie: if in 10 years specific hw support is dropped
> from the arch directory, we don't end up with zombie drivers that live on
> because generic driver maintainers don't know what hardware they're actually
> connected to).
The same argument was said about cpufreq drivers, and cpuidle drivers,
and IRQ controller drivers, etc. They ended up in a common directory
anyway. In the end this helps generic driver maintainers because you
don't end up with the same infrastructure copied over and over, each
time with slight alteration, making any common API maintenance a
nightmare.
Zombie drivers shouldn't be a huge issue when no one selects their
kconfig symbol. On the other hand, drivers burried under various
architecture directories are hard to maintain and abstract (ask tglx
about his IRQ driver changes).
> (But I'm somewhat flexible on this last point, as long as there really is a
> chance it might be shared at some point)
I think that common purpose is more important a criteria than
sharability. It's hard to say in advance if a piece of code might be
shared or not. On the other hand, its purpose should be rather clear.
Nicolas
More information about the linux-arm-kernel
mailing list