On Friday 16 November 2012, Geert Uytterhoeven wrote: > > config HAVE_GEN_RTC_LEGACY > > def_bool LEGACY_PC_IO && !(ARM || M32R || SPARC) > > # selected by M68K || MN10300 || PARISC || PPC > > That's not correct: GEN_RTC is not a driver for legacy CMOS RTC, but a > driver that provides a clasic /dev/rtc userspace API for systems that do not > have a CMOS RTC, but do provie [gs]et_rtc_time(). Right, I was confusing it with the other symbol I suggested introducing, HAVE_RTC_CMOS_LEGACY, which instead should default to LEGACY_PC_IO && !(...). > So it's a deprecated complementary driver for RTC. > > It's replacement using RTC_CLASS is RTC_DRV_GENERIC, which is also > discouraged for new platforms: > > config RTC_DRV_GENERIC > tristate "Generic RTC support" > # Please consider writing a new RTC driver instead of using the generic > # RTC abstraction > depends on PARISC || M68K || PPC || SUPERH32 > help > Say Y or M here to enable RTC support on systems using the generic > RTC abstraction. If you do not know what you are doing, you should > just say Y. Ah, I wasn't aware of this one. We clearly have too many of those ;-) On a related note, I wonder if it makes sense to move the four non-RTC_LIB drivers out of drivers/char and into drivers/rtc/legacy/ or something like that. We wouldn't change the code of course, but in general I like the idea of grouping code together that does the same thing, even if it doesn't use the same in-kernel interfaces. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
