linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alessandro Zummo <alessandro.zummo@towertech.it>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 1/6] RTC subsystem, class
Date: Tue, 20 Dec 2005 22:23:43 +0100	[thread overview]
Message-ID: <20051220222343.71ee6bab@inspiron> (raw)
In-Reply-To: <20051220211344.GA14403@infradead.org>

On Tue, 20 Dec 2005 21:13:45 +0000
Christoph Hellwig <hch@infradead.org> wrote:

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

> > + * 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 :)

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

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

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

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

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

> > +struct rtc_class_ops {
> 
> What about just rtc_ops?

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

 
> > +	int (*proc)(struct device *, char *buf);
> 
> this should be seq_file based.

 ack.

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

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

h

  reply	other threads:[~2005-12-20 21:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-20 20:45 [RFC][PATCH 1/6] RTC subsystem, class Alessandro Zummo
2005-12-20 21:13 ` Christoph Hellwig
2005-12-20 21:23   ` Alessandro Zummo [this message]
2005-12-21  1:50     ` Mitchell Blank Jr
2005-12-21  9:30       ` Alessandro Zummo
2005-12-20 21:30   ` Russell King
2005-12-21  2:01 ` Dmitry Torokhov
2005-12-21  9:50   ` Alessandro Zummo
2005-12-21 19:43     ` Dmitry Torokhov
2005-12-21 23:10       ` Alessandro Zummo
2005-12-22 13:35 ` Pavel Machek
2005-12-26  2:47   ` Alessandro Zummo
2005-12-26 20:16     ` Pavel Machek
2005-12-27  3:16       ` 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=20051220222343.71ee6bab@inspiron \
    --to=alessandro.zummo@towertech.it \
    --cc=hch@infradead.org \
    --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;
as well as URLs for NNTP newsgroup(s).