rtc-cmos driver and support
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 12 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | rtc-cmos driverdrivers/ drivers/ drivers/ +1 more | +742 | 11 replies | |
| 2/3 | create rtc-cmos platform device on x86_pcarch/ arch/ | +98 | 0 replies | |
| 3/3 | export ACPI info to rtc_cmos platform datadrivers/ | +89 | 1 reply |
Reviews trailers per patch
1 of 3 patches has a Reviewed-by or Acked-by.
| Patch | Len Brown |
|---|---|
| 1/3 | |
| 2/3 | |
| 3/3 | A-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [patch 2.6.20-rc3 0/3] rtc-cmos driver and support
Here's the latest version of an "rtc-cmos" driver, which lets PCs (and other systems now using drivers/char/rtc.c) use the same RTC class framework that other Linuxes use.
- Patch #1 is the rtc-cmos driver itself. Configure PNPACPI and up it comes ... in vanilla mode.
- Patch #2 adds platform_device support for x86 PCs, so you can get that same vanilla functionality without PNPACPI.
- Patch #3 adds the first non-vanilla functionality, exporting some extensions (notably, longer alarms) that ACPI knows about.
This is all pretty clean, and AFAICT ready to merge. On hardware I have handy, it's a clean replacement for drivers/char/rtc.c code.
This particular version doesn't supplant the /proc/acpi/alarm mechanism, since I ripped that logic out for now. Eventually that can (and should!!) vanish(*), in favor of the portable userspace interfaces supported by earlier patch versions, but I figure there's no rush for that just now.
- Dave
(*) I'd be interested in hearing from anyone who actually uses
that interface ... if there is anyone. What do you do with it, and how.