On Tue, 6 Sep 2005 [EMAIL PROTECTED] wrote: > >From my reading of that code, GEN_RTC should've been called FAKE_RTC...
Yep, it's an excuse for platform maintainers not to write proper drivers. > AFAICS, more or less clean solution would be to split the damn thing > into frontend (parsing of ioctls, hopefully very few API variants) and > backend (set of methods for talking to real hardware, or, in this case, > fake of a hardware). With at most one backend selectable (i.e. select > in Kconfig) and frontend available if backend is selected. With any > luck we could eventually get frontends down to one; in any case, their > APIs have no place in include/asm-* > > Note that e.g. fsckloads of MIPS RTC drivers would simply become backends > in that scheme; lots of duplicated glue would disappear from them... Note that a few of MIPS RTC drivers are actually I2C devices that the fake code accesses directly bypassing the relevant I2C driver. That may be a justified fallback for the one-off boot-time system clock setup when no suitable I2C driver has been built in, but for normal operation that's rather miserable. As I happen to have a suitable system for testing, I may have a look at how to interface such drivers to a generic frontend. I'm not sure whether in this particular system the RTC chip's interrupt is wired though -- probably not -- so I may only leave this part of code to be tested by others. Maciej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
