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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |