Messages in this thread | | | Date | Wed, 02 Jan 2008 09:26:25 -0800 | From | David Brownell <> | Subject | Re: [PATCH 0/4] PM: Do not destroy/create devices while suspended (rev. 2) |
| |
(Alessandro Zummo Cc:-ed too -- RTC subsystem maintainer)
> * Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > Well, we have the following test script in the userland suspend > > package that is supposed to work right now: > > > > #!/bin/bash > > date > > cd /sys/class/rtc/rtc0 > > echo $(( $(cat since_epoch) + 20 )) > wakealarm > > s2ram > > date > > > > provided that the new rtc driver code is compiled (and the old one is not).
Eventually, swapping driver modules ought to work too. The legacy /proc/acpi/wakeup files would ISTR cause problems in current code.
Of course, one reason to want to use the RTC framework code is to stop depending on x86-isms like ACPI or "s2ram", and thus to work on more Linux platforms. ;)
> ok, will try that. A stupid question. The old RTC driver is in > drivers/char/rtc.c, and maps to: > > crw-r--r-- 1 root root 10, 135 Oct 25 18:02 /dev/rtc > > the new driver is in drivers/rtc/*, and maps to: > > crw-r--r-- 1 root root 254, 0 Dec 12 02:30 /dev/rtc0 > > but all the x86 distro boxes i have access to make use of /dev/rtc. > There's no symlink set up from /dev/rtc to /dev/rtc0 either.
Current util-linux-ng code uses either RTC device file; and udev sets up /dev/rtc0 as needed. (But not /dev/rtc, as I recall...) Have distros switched away from the old unmaintained util-linux?
> So it > appears to me that the new RTC driver isnt actually utilized on most > distributions.
That might be so. There are some HPET issues, but those show up with both drivers.
The main other issue I know about which would seem to argue for using the legacy driver, instead of the RTC framework, is that some BIOSes don't seem to provide PNPACPI entries for their RTCs. I got one report of a newish HP Opteron system that doesn't. I have no idea how common that is. The drivers/acpi/glue.c code could detect that, but maybe a better place to address that would be in PNP code; in that case, ISTR that PNP0c01 claimed the RTC ioports, and so would be the natural place to make provide a real driver model node for that hardware.
> shouldnt we provide a Kconfig way of replacing dev 10:135 with the new > driver's 254:0 device? (while keeping all the current modes of operation > as well, of course.)
The major number 254 is not statically allocated, ISTR; that should be managed only by udev.
> It's all supposed to be 100% ioctl ABI compatible > with the old driver, right? That way distros could start migrating to it > as well, without depending on any udev hackery.
I don't know of any ioctl differences userspace would care about.
- Dave
| |