Skip to contentSkip to conversation

RTC subsystem, class

RFC PATCH In review Alessandro Zummo 7 participants 14 messages Dec 20, 2005 – Dec 27, 2005 Real time clock (RTC)

lore
Share & tools
lore

Alessandro Zummo

author
#0 lore raw

RFC PATCH 1/6 RTC subsystem, class

This patch adds the basic RTC subsytem infrastructure to the kernel.

rtc/class.c - registration facilities for RTC drivers rtc/intf.c - kernel/rtc interface functions rtc/utils.c - misc rtc-related utility functions

Signed-off-by Alessandro Zummo <[email protected]>

--

 drivers/Kconfig      |    2 
 drivers/Makefile     |    2 
 drivers/rtc/Kconfig  |   25 +++++++++++
 drivers/rtc/Makefile |    8 +++
 drivers/rtc/class.c  |  110 +++++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/rtc/intf.c   |   67 +++++++++++++++++++++++++++++++
 drivers/rtc/utils.c  |   99 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/rtc.h  |   30 +++++++++++++
 8 files changed, 343 insertions(+)
drivers/rtc/class.c new file +110 -0
@@ -0,0 +1,110 @@
+/*
+ * rtc-class.c - rtc subsystem, base class
+ *
+ * Copyright (C) 2005 Tower Technologies
+ * Author: Alessandro Zummo <[email protected]>
+ *
+ * class skeleton from drivers/hwmon/hwmon.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+*/
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/kdev_t.h>
+#include <linux/idr.h>
+#include <linux/rtc.h>
+
+#define RTC_ID_PREFIX "rtc"
+#define RTC_ID_FORMAT RTC_ID_PREFIX "%d"
+
+static struct class *rtc_class;
+
+static DEFINE_IDR(rtc_idr);
+
+/**
+ * rtc_device_register - register w/ hwmon sysfs class
+ * @dev: the device to register
+ *
+ * rtc_device_unregister() must be called when the class device is no
+ * longer needed.
+ *
+ * Returns the pointer to the new struct class device.
+ */
+struct class_device *rtc_device_register(struct device *dev,
+					struct rtc_class_ops *ops)
+{
+	struct class_device *cdev;
+	int id;
+
+	if (idr_pre_get(&rtc_idr, GFP_KERNEL) == 0)
+		return ERR_PTR(-ENOMEM);
+
+	if (idr_get_new(&rtc_idr, NULL, &id) < 0)
+		return ERR_PTR(-ENOMEM);
+
+	id = id & MAX_ID_MASK;
+	cdev = class_device_create(rtc_class, NULL, MKDEV(0,0), dev,
+					RTC_ID_FORMAT, id);
+
+	if (IS_ERR(cdev))
+		idr_remove(&rtc_idr, id);
+	else
+		dev_info(dev, "rtc core: registered\n");
+
+	class_set_devdata(cdev, ops);
+
+	return cdev;
+}
+
+/**
+ * rtc_device_unregister - removes the previously registered class device
+ *
+ * @cdev: the class device to destroy
+ */
+void rtc_device_unregister(struct class_device *cdev)
+{
+	int id;
+
+	if (sscanf(cdev->class_id, RTC_ID_FORMAT, &id) == 1) {
+		class_device_unregister(cdev);
+		idr_remove(&rtc_idr, id);
+	} else
+		dev_dbg(cdev->dev,
+			"rtc_device_unregister() failed: bad class ID!\n");
+}
+
+int rtc_interface_register(struct class_interface *intf)
+{
+	intf->class = rtc_class;
+        return class_interface_register(intf);
+}
+EXPORT_SYMBOL(rtc_interface_register);
+
+static int __init rtc_init(void)
+{
+	rtc_class = class_create(THIS_MODULE, "rtc");
+	if (IS_ERR(rtc_class)) {
+		printk(KERN_ERR "rtc-class.c: couldn't create class\n");
+		return PTR_ERR(rtc_class);
+	}
+	return 0;
+}
+
+static void __exit rtc_exit(void)
+{
+	class_destroy(rtc_class);
+}
+
+module_init(rtc_init);
+module_exit(rtc_exit);
+
+EXPORT_SYMBOL_GPL(rtc_device_register);
+EXPORT_SYMBOL_GPL(rtc_device_unregister);
+
+MODULE_AUTHOR("Alessandro Zummo <[email protected]>");
+MODULE_DESCRIPTION("RTC class support");
+MODULE_LICENSE("GPL");
drivers/rtc/intf.c new file +67 -0

67 lines not on this page · raw message

drivers/rtc/Kconfig new file +25 -0
@@ -0,0 +1,25 @@
+#
+# RTC class/drivers configuration
+#
+
+menu "Real Time Clock"
+
+config RTC_CLASS
+	tristate "RTC class"
+	depends on EXPERIMENTAL
+	default y
+	help
+	  Generic RTC class support. If you say yes here, you will
+ 	  be allowed to plug one or more RTCs to your system. You will
+	  probably want to enable one of more of the interfaces below.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called rtc-class.
+
+comment "RTC interfaces"
+	depends on RTC_CLASS
+
+comment "RTC drivers"
+	depends on RTC_CLASS
+
+endmenu
drivers/rtc/Makefile new file +8 -0
@@ -0,0 +1,8 @@
+#
+# Makefile for RTC class/drivers.
+#
+
+obj-y				+= utils.o
+obj-$(CONFIG_RTC_CLASS)		+= rtc-core.o
+rtc-core-y			:= class.o intf.o
+rtc-core-objs			:= $(rtc-core-y)
include/linux/rtc.h +30 -0
@@ -93,6 +93,36 @@ struct rtc_pll_info {
 
 #ifdef __KERNEL__
 
+#include <linux/device.h>
+
+struct rtc_class_ops {
+	struct module *owner;
+	int (*open)(struct device *);
+	void (*release)(struct device *);
+	int (*ioctl)(struct device *, unsigned int, unsigned long);
+	int (*read_time)(struct device *, struct rtc_time *);
+	int (*set_time)(struct device *, struct rtc_time *);
+	int (*read_alarm)(struct device *, struct rtc_wkalrm *);
+	int (*set_alarm)(struct device *, struct rtc_wkalrm *);
+	int (*proc)(struct device *, char *buf);
+	int (*set_mmss)(struct device *, unsigned long secs);
+};
+
+extern int rtc_interface_register(struct class_interface *intf);
+extern struct class_device *rtc_device_register(struct device *dev,
+					struct rtc_class_ops *ops);
+extern void rtc_device_unregister(struct class_device *cdev);
+
+
+extern int rtc_month_days(unsigned int month, unsigned int year);
+extern int rtc_valid_tm(struct rtc_time *tm);
+extern int rtc_tm_to_time(struct rtc_time *tm, unsigned long *time);
+
+extern int rtc_read_time(struct class_device *class_dev, struct rtc_time *tm);
+extern int rtc_set_time(struct class_device *class_dev, struct rtc_time *tm);
+extern int rtc_read_alarm(struct class_device *class_dev, struct rtc_wkalrm *alrm);
+extern int rtc_set_alarm(struct class_device *class_dev, struct rtc_wkalrm *alrm);
+
 typedef struct rtc_task {
 	void (*func)(void *private_data);
 	void *private_data;
drivers/rtc/utils.c new file +99 -0

99 lines not on this page · raw message

drivers/Kconfig +2 -0
@@ -66,4 +66,6 @@ source "drivers/infiniband/Kconfig"
 
 source "drivers/sn/Kconfig"
 
+source "drivers/rtc/Kconfig"
+
 endmenu
drivers/Makefile +2 -0
@@ -54,6 +54,8 @@ obj-$(CONFIG_USB_GADGET)	+= usb/gadget/
 obj-$(CONFIG_GAMEPORT)		+= input/gameport/
 obj-$(CONFIG_INPUT)		+= input/
 obj-$(CONFIG_I2O)		+= message/
+# rtc should be before i2c for now.
+obj-y				+= rtc/
 obj-$(CONFIG_I2C)		+= i2c/
 obj-$(CONFIG_W1)		+= w1/
 obj-$(CONFIG_HWMON)		+= hwmon/
#1 lore raw
Quoted 2 lines · Alessandro Zummo

This patch adds the basic RTC subsytem infrastructure to the kernel.

Whee, very cool. We've needed something like that for a long time.

Quoted 5 lines

rtc/class.c - registration facilities for RTC drivers rtc/intf.c - kernel/rtc interface functions rtc/utils.c - misc rtc-related utility functions

Signed-off-by Alessandro Zummo <[email protected]>
Quoted 8 lines

--

 drivers/Kconfig      |    2 
 drivers/Makefile     |    2 
 drivers/rtc/Kconfig  |   25 +++++++++++
 drivers/rtc/Makefile |    8 +++
 drivers/rtc/class.c  |  110 +++++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/rtc/intf.c   |   67 +++++++++++++++++++++++++++++++
 drivers/rtc/utils.c  |   99 +++++++++++++++++++++++++++++++++++++++++++++

Given that the files are really tiny I'd suggest to put everything into a single file (driver/char/rtc.c) instead of some arbitrary split.

drivers/rtc/class.c line 2

Quoted 5 lines
drivers/rtc/class.c new file +2 -0
@@ -0,0 +1,110 @@
+/*
+ * rtc-class.c - rtc subsystem, base class

no need to put the file name into a comment. it gets out of date far too easily (it already is in this case ;-))

drivers/rtc/class.c line 22

Quoted 2 lines
drivers/rtc/class.c new file +2 -0
+#define RTC_ID_PREFIX "rtc"
+#define RTC_ID_FORMAT RTC_ID_PREFIX "%d"

Having a format specifier hidden in a macro makes reading code very difficult, please just remove this.

Quoted 41 lines
drivers/rtc/class.c new file +40 -0
+
+static struct class *rtc_class;
+
+static DEFINE_IDR(rtc_idr);
+
+/**
+ * rtc_device_register - register w/ hwmon sysfs class
+ * @dev: the device to register
+ *
+ * rtc_device_unregister() must be called when the class device is no
+ * longer needed.
+ *
+ * Returns the pointer to the new struct class device.
+ */
+struct class_device *rtc_device_register(struct device *dev,
+					struct rtc_class_ops *ops)
+{
+	struct class_device *cdev;
+	int id;
+
+	if (idr_pre_get(&rtc_idr, GFP_KERNEL) == 0)
+		return ERR_PTR(-ENOMEM);
+
+	if (idr_get_new(&rtc_idr, NULL, &id) < 0)
+		return ERR_PTR(-ENOMEM);
+
+	id = id & MAX_ID_MASK;
+	cdev = class_device_create(rtc_class, NULL, MKDEV(0,0), dev,
+					RTC_ID_FORMAT, id);
+
+	if (IS_ERR(cdev))
+		idr_remove(&rtc_idr, id);
+	else
+		dev_info(dev, "rtc core: registered\n");
+
+	class_set_devdata(cdev, ops);
+
+	return cdev;
+}
 
+void rtc_device_unregister(struct class_device *cdev)

drivers/rtc/class.c line 78

Quoted 10 lines
drivers/rtc/class.c new file +10 -0
+{
+	int id;
+
+	if (sscanf(cdev->class_id, RTC_ID_FORMAT, &id) == 1) {
+		class_device_unregister(cdev);
+		idr_remove(&rtc_idr, id);
+	} else
+		dev_dbg(cdev->dev,
+			"rtc_device_unregister() failed: bad class ID!\n");
+}

The scanf looks really fragile. Can't you just have a rtc_device structure that the cdev and id are embedded into that can be passed to the unregistration function?

drivers/rtc/class.c line 83

Quoted 5 lines
drivers/rtc/class.c new file +5 -0
+
+int rtc_interface_register(struct class_interface *intf)
+{
+	intf->class = rtc_class;
+        return class_interface_register(intf);

spaces instead of a tab for indentation here.

drivers/rtc/class.c

Quoted 7 lines
drivers/rtc/class.c new file +7 -0
+int rtc_read_time(struct class_device *class_dev, struct rtc_time *tm)
+{
+	int err = -EINVAL;
+	struct rtc_class_ops *ops = class_get_devdata(class_dev);
+
+	if (ops->read_time) {
+		memset(tm, 0, sizeof(struct rtc_time));

do we really need the memset?

drivers/rtc/class.c

Quoted 5 lines
drivers/rtc/class.c new file +5 -0
+#
+# Makefile for RTC class/drivers.
+#
+
+obj-y				+= utils.o

why is this always built?

drivers/rtc/class.c

Quoted 3 lines
drivers/rtc/class.c new file +3 -0
+obj-$(CONFIG_RTC_CLASS)		+= rtc-core.o
+rtc-core-y			:= class.o intf.o
+rtc-core-objs			:= $(rtc-core-y)

no need for this last line

Quoted 1 line

+struct rtc_class_ops {

What about just rtc_ops?

drivers/rtc/class.c

Quoted 1 line
drivers/rtc/class.c new file +1 -0
+	int (*proc)(struct device *, char *buf);

this should be seq_file based.

drivers/rtc/class.c

Quoted 4 lines
drivers/rtc/class.c new file +4 -0
+static const unsigned char rtc_days_in_month[] = {
+	31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
+};
+EXPORT_SYMBOL(rtc_days_in_month);

exporting static symbols is pretty wrong. Exporting tables is pretty bad style aswell.

author
#2 lore raw
Quoted 7 lines · On Tue, 20 Dec 2005 21:13:45 +0000 Christoph Hellwig <[email protected]> wrote:
Quoted 3 lines
 drivers/rtc/class.c  |  110 +++++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/rtc/intf.c   |   67 +++++++++++++++++++++++++++++++
 drivers/rtc/utils.c  |   99 +++++++++++++++++++++++++++++++++++++++++++++

Given that the files are really tiny I'd suggest to put everything into a single file (driver/char/rtc.c) instead of some arbitrary split.

I can merge. It was easier to develop them this way.

Quoted 4 lines
Quoted 1 line

+ * rtc-class.c - rtc subsystem, base class

no need to put the file name into a comment. it gets out of date far too easily (it already is in this case ;-))

oooooops :)

Quoted 5 lines

drivers/rtc/class.c line 22

Quoted 2 lines
drivers/rtc/class.c new file +2 -0
+#define RTC_ID_PREFIX "rtc"
+#define RTC_ID_FORMAT RTC_ID_PREFIX "%d"

Having a format specifier hidden in a macro makes reading code very difficult, please just remove this.

ack.

Quoted 11 lines

drivers/rtc/class.c line 78

Quoted 7 lines
drivers/rtc/class.c new file +7 -0
+	if (sscanf(cdev->class_id, RTC_ID_FORMAT, &id) == 1) {
+		class_device_unregister(cdev);
+		idr_remove(&rtc_idr, id);
+	} else
+		dev_dbg(cdev->dev,
+			"rtc_device_unregister() failed: bad class ID!\n");
+}

The scanf looks really fragile. Can't you just have a rtc_device structure that the cdev and id are embedded into that can be passed to the unregistration function?

I admit I copied from hwmon here :) I'll check into that.

Quoted 4 lines

drivers/rtc/intf.c line 24

Quoted 2 lines
drivers/rtc/intf.c new file +2 -0
+	if (ops->read_time) {
+		memset(tm, 0, sizeof(struct rtc_time));

do we really need the memset?

It's a kind of protection in case something goes wrong in the driver. can be probably removed.

Quoted 3 lines
Quoted 1 line

+obj-y += utils.o

why is this always built?

because it exports utility functions used elsewhere in the kernel, some of them have been removed from the ARM part. Until everything gets cleaned up, it's better to always build those few funcs.

Quoted 5 lines

drivers/rtc/Makefile line 8

Quoted 3 lines
drivers/rtc/Makefile new file +3 -0
+obj-$(CONFIG_RTC_CLASS)		+= rtc-core.o
+rtc-core-y			:= class.o intf.o
+rtc-core-objs			:= $(rtc-core-y)

no need for this last line

I remember I had compilation problems without it, I'll check again.

Quoted 3 lines
Quoted 1 line

+struct rtc_class_ops {

What about just rtc_ops?

it's already used under ARM and i didn't wanted
to break it.

Quoted 3 lines

include/linux/rtc.h struct rtc_pll_info { · line 107

Quoted 1 line
include/linux/rtc.h +1 -0
+	int (*proc)(struct device *, char *buf);

this should be seq_file based.

ack.

Quoted 7 lines

drivers/rtc/utils.c line 19

Quoted 4 lines
drivers/rtc/utils.c new file +4 -0
+static const unsigned char rtc_days_in_month[] = {
+	31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
+};
+EXPORT_SYMBOL(rtc_days_in_month);

exporting static symbols is pretty wrong. Exporting tables is pretty bad style aswell.

Tables like this one are often used in rtc drivers. What can I use instead?

Signature · 8 lines
 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

h
#3 lore raw
Quoted 10 lines · Alessandro Zummo
Quoted 7 lines

drivers/rtc/utils.c line 19

Quoted 4 lines
drivers/rtc/utils.c new file +4 -0
+static const unsigned char rtc_days_in_month[] = {
+	31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
+};
+EXPORT_SYMBOL(rtc_days_in_month);

exporting static symbols is pretty wrong. Exporting tables is pretty bad style aswell.

Tables like this one are often used in rtc drivers. What can I use instead?

Why not just provide a macro in a .h file? Something like:

/* Days in month -- month is in the range (0..11), no leap year */
#define rtc_days_in_month(mon) (28 + ((0xEEFBB3 >> ((mon) * 2)) & 3))

-Mitch

author
#4 lore raw
Quoted 10 lines · On Tue, 20 Dec 2005 17:50:12 -0800 Mitchell Blank Jr <[email protected]> wrote:
Quoted 5 lines
Quoted 2 lines

exporting static symbols is pretty wrong. Exporting tables is pretty bad style aswell.

Tables like this one are often used in rtc drivers. What can I use instead?

Why not just provide a macro in a .h file? Something like:

/* Days in month -- month is in the range (0..11), no leap year */
#define rtc_days_in_month(mon) (28 + ((0xEEFBB3 >> ((mon) * 2)) & 3))

I just noticed i was exporting a similar functions, so
the table export can be removed.

Signature · 6 lines
 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it
#5 lore raw
In reply to Christoph Hellwig
Quoted 9 lines · Christoph Hellwig

drivers/rtc/intf.c line 24

Quoted 7 lines
drivers/rtc/intf.c new file +7 -0
+int rtc_read_time(struct class_device *class_dev, struct rtc_time *tm)
+{
+	int err = -EINVAL;
+	struct rtc_class_ops *ops = class_get_devdata(class_dev);
+
+	if (ops->read_time) {
+		memset(tm, 0, sizeof(struct rtc_time));

do we really need the memset?

Absolutely yes, otherwise if 'tm' is on the stack and it ultimately gets copied to userspace, it will leak kernel memory. Why? Unfortunately, not all elements of 'tm' are written to by RTC drivers.

You can argue that the RTC drivers need fixing, but since this bug has gone completely unnoticed in _all_ kernels which have an RTC driver up until I discovered it and reported it to vendor-sec during the 2.5 cycle, I think a little bit of cheap protection against buggy drivers when security leaks are concerned is not unreasonable. Especially when they don't get found in the normal run of things.

(you could make a case for eliminating it _if_ there was a RTC subsystem maintainer who knew the code and therefore knew what to look out for.)

Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
#6 lore raw
In reply to Alessandro Zummo

Hi,

drivers/rtc/intf.c line 24

Quoted 8 lines · Alessandro Zummo
drivers/rtc/intf.c new file +7 -0
+int rtc_read_time(struct class_device *class_dev, struct rtc_time *tm)
+{
+       int err = -EINVAL;
+       struct rtc_class_ops *ops = class_get_devdata(class_dev);
+
+       if (ops->read_time) {
+               memset(tm, 0, sizeof(struct rtc_time));

What guarantees that ops is not NULL here? Userspace can keep the attribute (file) open and issue read after class_device was unregistered and devdata set to NULL.

Signature · 1 line
Dmitry
author
#7 lore raw
Quoted 7 lines · On Tue, 20 Dec 2005 21:01:39 -0500 Dmitry Torokhov <[email protected]>…
Quoted 3 lines

+       if (ops->read_time) {
+               memset(tm, 0, sizeof(struct rtc_time));

What guarantees that ops is not NULL here? Userspace can keep the attribute (file) open and issue read after class_device was unregistered and devdata set to NULL.

Right. For /proc and /dev there's a try_module_get(ops->owner) in place.

Should I add it to every rtc_sysfs_show_xxx or there's a better way to do it?

Signature · 6 lines
 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it
#8 lore raw
Quoted 12 lines · Alessandro Zummo
Quoted 7 lines · On Tue, 20 Dec 2005 21:01:39 -0500 Dmitry Torokhov <[email protected]>…

drivers/rtc/intf.c line 24

Quoted 3 lines
drivers/rtc/intf.c new file +2 -0
+if (ops->read_time) {
+memset(tm, 0, sizeof(struct rtc_time));

What guarantees that ops is not NULL here? Userspace can keep the attribute (file) open and issue read after class_device was unregistered and devdata set to NULL.

Quoted 5 lines

Right. For /proc and /dev there's a try_module_get(ops->owner) in place.

Should I add it to every rtc_sysfs_show_xxx or there's a better way to do it?

Well, I don't know what will it buy you: if ops is NULL try_module_get(ops->owner) will OOPS just as happily as original code.

Your class_device has to hold on to all data structures that are referenced from sysfs attributes untils its ->release() function is called. Alternatively you could stuck a mutex and a flag somewhere in driver data and take it when unregistering class device and also in all attributes (and chech the flag there).

--
Dmitry

author
#9 lore raw
Quoted 8 lines · On Wed, 21 Dec 2005 14:43:01 -0500 Dmitry Torokhov <[email protected]>…

Well, I don't know what will it buy you: if ops is NULL try_module_get(ops->owner) will OOPS just as happily as original code.

Your class_device has to hold on to all data structures that are referenced from sysfs attributes untils its ->release() function is called. Alternatively you could stuck a mutex and a flag somewhere in driver data and take it when unregistering class device and also in all attributes (and chech the flag there).

Thanks for your help.. I will try to implement a solution ans post it as soon as possible.

Signature · 6 lines
 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it
#10 lore raw
In reply to Alessandro Zummo

Hi!

drivers/rtc/intf.c

Quoted 7 lines

rtc/class.c - registration facilities for RTC drivers rtc/intf.c - kernel/rtc interface functions rtc/utils.c - misc rtc-related utility functions

drivers/rtc/intf.c new file +0 -0
@@ -0,0 +1,67 @@

interface.c, please.

drivers/rtc/intf.c line 2

Quoted 2 lines
drivers/rtc/intf.c new file +2 -0
+/*
+ * rtc-intf.c - rtc subsystem, interface functions

Wrong filename.

drivers/rtc/intf.c line 3

Quoted 1 line
drivers/rtc/intf.c new file +1 -0
+int rtc_set_alarm(struct class_device *class_dev, struct rtc_wkalrm*alrm)

Struct rtc_wake_alarm *alarm, those wovels are there for readability.

Signature · 1 line
Thanks, Sharp!
author
#11 lore raw
Quoted 5 lines · On Thu, 22 Dec 2005 14:35:07 +0100 Pavel Machek <[email protected]> wrote:

drivers/rtc/intf.c

Quoted 3 lines
drivers/rtc/intf.c new file +0 -0
@@ -0,0 +1,67 @@

interface.c, please.

ack.

Quoted 4 lines

drivers/rtc/intf.c line 2

Quoted 2 lines
drivers/rtc/intf.c new file +2 -0
+/*
+ * rtc-intf.c - rtc subsystem, interface functions

Wrong filename.

ok, I removed all filenames :)

Quoted 3 lines

drivers/rtc/intf.c line 3

Quoted 1 line
drivers/rtc/intf.c new file +1 -0
+int rtc_set_alarm(struct class_device *class_dev, struct rtc_wkalrm*alrm)

Struct rtc_wake_alarm *alarm, those wovels are there for readability.

I'm not the one who created this structure. It's defined in linux/rtc.h since a long time. I can only change alrm to alarm.

thanks!

Signature · 6 lines
 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it
#12 lore raw

Hi!

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

+int rtc_set_alarm(struct class_device *class_dev, struct rtc_wkalrm*alrm)

Struct rtc_wake_alarm *alarm, those wovels are there for readability.

I'm not the one who created this structure. It's defined in linux/rtc.h since a long time. I can only change alrm to alarm.

Sorry if you are not responsible... Yes, alarm would be better.

How does this relate to /proc/acpi/alarm, btw? Do they use same RTC alarm?

Pavel

Signature · 1 line
Thanks, Sharp!
author
#13 lore raw
Quoted 4 lines · On Mon, 26 Dec 2005 21:16:57 +0100 Pavel Machek <[email protected]> wrote:
Quoted 4 lines
Quoted 3 lines
Quoted 1 line

+int rtc_set_alarm(struct class_device *class_dev, struct rtc_wkalrm*alrm)

Struct rtc_wake_alarm *alarm, those wovels are there for readability.

Quoted 8 lines
Quoted 3 lines

I'm not the one who created this structure. It's defined in linux/rtc.h since a long time. I can only change alrm to alarm.

Sorry if you are not responsible... Yes, alarm would be better.

How does this relate to /proc/acpi/alarm, btw? Do they use same RTC alarm?

Yes, they do. The ACPI subsystem does direct I/O on the cmos clock.

Given the complexity of the ACPI code, when/if the x86 rtc driver will be ported to the RTC subsystem, it would be wise to disable the alarm part if ACPI is compiled in.

Signature · 6 lines
 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it