mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Alessandro Zummo <a.zummo@towertech.it>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/11] RTC subsystem, class
Date: Wed, 22 Feb 2006 14:15:54 -0800	[thread overview]
Message-ID: <20060222141554.0f5e2aa3.akpm@osdl.org> (raw)
In-Reply-To: <20060219232211.628944000@towertech.it>

Alessandro Zummo <a.zummo@towertech.it> wrote:
>
> This patch adds the basic RTC subsytem infrastructure
> to the kernel.
> 
> rtc/class.c - registration facilities for RTC drivers
> rtc/interface.c - kernel/rtc interface functions 
> rtc/utils.c - misc rtc-related utility functions
> rtc/hctosys.c - snippet of code that copies hw clock to sw clock
> 		at bootup, if configured to do so.

Couple of questions.

a) Is all this code 100% compatible with existing kernel interfaces?  No
   userspace-visible breakage?  Right down the all the same -EFOO return
   codes for all the same errors?

b) Will the kernel compile and run at each stage of your patch series? 
   I hit a nasty no-compile half an hour through a git-bisect session
   yesterday and it's still smarting.

Code looks nice and clean.

> +	if (idr_pre_get(&rtc_idr, GFP_KERNEL) == 0) {
> +		err = -ENOMEM;
> +		goto exit;
> +	}
> +
> +
> +	mutex_lock(&idr_lock);
> +	err = idr_get_new(&rtc_idr, NULL, &id);
> +	mutex_unlock(&idr_lock);

Oh the IDR API does suck.  Not your fault though.

> +	if ((rtc = kzalloc(sizeof(struct rtc_device), GFP_KERNEL)) == NULL) {

You do a lot of

	if ((lhs = rhs) == something)

But preferred kernel style is

	lhs = rhs;
	if (lhs == something)

Generally, kernel style is to keep things as utterly simple as they can be.

+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.
> +
> +config RTC_HCTOSYS
> +	bool "Set system time from RTC on startup"
> +	depends on RTC_CLASS = y
> +	default y
> +	help
> +	  If you say yes here, the system time will be set using
> +	  the value read from the specified RTC device. This is useful
> +	  in order to avoid unnecessary fschk runs.
> +
> +config RTC_HCTOSYS_DEVICE
> +	string "The RTC to read the time from"
> +	depends on RTC_HCTOSYS = y
> +	default "rtc0"
> +	help
> +	  The RTC device that will be used as the source for
> +	  the system time, usually rtc0.

hm.  Doesn't the above disable RTC_HCTOSYS and RTC_HCTOSYS_DEVICE if
RTC_CLASS=m?

> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ linux-rtc/drivers/rtc/interface.c	2006-02-15 04:13:37.000000000 +0100
> @@ -0,0 +1,274 @@
> +/*
> + * RTC subsystem, interface functions
> + *
> + * Copyright (C) 2005 Tower Technologies
> + * Author: Alessandro Zummo <a.zummo@towertech.it>
> + *
> + * based on arch/arm/common/rtctime.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/rtc.h>
> +
> +extern struct class *rtc_class;

Please always put extern declarations in a header file.

> +}
> +EXPORT_SYMBOL(rtc_set_alarm);
> +
> +void rtc_update_irq(struct class_device *class_dev,
> +		unsigned long num, unsigned long events)
> +{
> +	struct rtc_device *rtc = to_rtc_device(class_dev);
> +
> +	spin_lock(&rtc->irq_lock);
> +	rtc->irq_data = (rtc->irq_data + (num << 8)) | events;
> +	spin_unlock(&rtc->irq_lock);
> +
> +	spin_lock(&rtc->irq_task_lock);
> +	if (rtc->irq_task)
> +		rtc->irq_task->func(rtc->irq_task->private_data);
> +	spin_unlock(&rtc->irq_task_lock);
> +
> +	wake_up_interruptible(&rtc->irq_queue);
> +	kill_fasync(&rtc->async_queue, SIGIO, POLL_IN);
> +}
> +EXPORT_SYMBOL(rtc_update_irq);

I don't know what this does.

Please document all non-static functions.  Preferably with kernel-doc
format.  Feel free to document static functions too..

> +int rtc_irq_set_freq(struct class_device *class_dev, struct rtc_task *task, int freq)
> +{
> +	int err = 0, tmp = 0;
> +	unsigned long flags;
> +	struct rtc_device *rtc = to_rtc_device(class_dev);
> +
> +	/* allowed range is 2-8192 */
> +	if (freq < 2 || freq > 8192)
> +		return -EINVAL;
> +
> +/*	if ((freq > rtc_max_user_freq) && (!capable(CAP_SYS_RESOURCE)))
> +		return -EACCES;
> +*/

What happened to rtc_max_user_freq?


  reply	other threads:[~2006-02-22 22:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-19 23:22 [PATCH 00/11] RTC subsystem Alessandro Zummo
2006-02-19 23:22 ` [PATCH 01/11] RTC subsystem, class Alessandro Zummo
2006-02-22 22:15   ` Andrew Morton [this message]
2006-02-23  1:09     ` Alessandro Zummo
2006-02-23  1:31       ` Andrew Morton
2006-02-19 23:22 ` [PATCH 02/11] RTC subsystem, ARM cleanup Alessandro Zummo
2006-02-19 23:22 ` [PATCH 03/11] RTC subsystem, I2C cleanup Alessandro Zummo
2006-02-19 23:22 ` [PATCH 04/11] RTC subsystem, sysfs interface Alessandro Zummo
2006-02-19 23:22 ` [PATCH 05/11] RTC subsystem, proc interface Alessandro Zummo
2006-02-19 23:22 ` [PATCH 06/11] RTC subsystem, dev interface Alessandro Zummo
2006-02-19 23:22 ` [PATCH 07/11] RTC subsystem, X1205 driver Alessandro Zummo
2006-02-19 23:22 ` [PATCH 08/11] RTC subsystem, test device/driver Alessandro Zummo
2006-02-19 23:22 ` [PATCH 09/11] RTC subsystem, DS1672 driver Alessandro Zummo
2006-02-19 23:22 ` [PATCH 10/11] RTC subsystem, PCF8563 driver Alessandro Zummo
2006-02-19 23:22 ` [PATCH 11/11] RTC subsystem, RS5C372 driver Alessandro Zummo
2006-02-20  0:58 ` [PATCH 00/11] RTC subsystem Andrew Morton
2006-02-20  1:10   ` Alessandro Zummo
     [not found] <5FUPV-4r4-3@gated-at.bofh.it>
     [not found] ` <5FUZC-4Rr-17@gated-at.bofh.it>
2006-02-14  8:08   ` [PATCH 01/11] RTC subsystem, class Thomas Petazzoni
  -- strict thread matches above, loose matches on Subject: below --
2006-02-13 22:54 [PATCH 00/11] RTC subsystem Alessandro Zummo
2006-02-13 22:54 ` [PATCH 01/11] RTC subsystem, class Alessandro Zummo
2006-02-14  3:49   ` Dmitry Torokhov
2006-02-15  0:24     ` Alessandro Zummo
2006-02-14  9:02   ` Paul Mundt
2006-02-14 10:07     ` Alessandro Zummo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060222141554.0f5e2aa3.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=a.zummo@towertech.it \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome