Re: [RFC][PATCH 1/6] RTC subsystem, class

[Christoph Hellwig <hch@infradead.org>]

On Tue, Dec 20, 2005 at 09:45:11PM +0100, Alessandro Zummo wrote:
> This patch adds the basic RTC subsytem infrastructure
> to the kernel.

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

> 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 <a.zummo@towertech.it>
> --
>  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.

> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ linux-nslu2/drivers/rtc/class.c	2005-12-15 10:22:20.000000000 +0100
> @@ -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 ;-))


> +#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.

> +
> +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)
> +{
> +	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?

> +
> +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.

> +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?

> +#
> +# Makefile for RTC class/drivers.
> +#
> +
> +obj-y				+= utils.o

why is this always built?
> +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

> +struct rtc_class_ops {

What about just rtc_ops?

> +	int (*proc)(struct device *, char *buf);

this should be seq_file based.

> +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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/