AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071204164035.751d808d@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<akpm@linux-foundation.org>,<p_gortmaker@yahoo.com>,<anemo@mba.ocn.ne.jp>,<a.zummo@towertech.it>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 4 Dec 2007 16:41:33 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: p_gortmaker@yahoo.com, anemo@mba.ocn.ne.jp, Alessandro Zummo
 <a.zummo@towertech.it>
Subject: Re: [PATCH] Platform real time clock driver for Dallas 1511 chip.
Message-ID: <20071204164133.7604cd4d@ripper.onstor.net>
In-Reply-To: <20071204130458.75f5c90a.akpm@linux-foundation.org>
References: <20071204195958.GA14859@onstor.com>
 <20071204130458.75f5c90a.akpm@linux-foundation.org>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 4 Dec 2007 13:04:58 -0800 Andrew Morton
<akpm@linux-foundation.org> wrote:

> On Tue, 4 Dec 2007 12:00:05 -0800
> Andrew Sharp <andy.sharp@onstor.com> wrote:
> 
> > 
> > Add RTC support for DS1511 RTC/WDT chip.
> > 
> > ...
> >
> > +typedef enum ds1511reg {
> > +	DS1511_SEC = 0x0,
> > +	DS1511_MIN = 0x1,
> > +	DS1511_HOUR = 0x2,
> > +	DS1511_DOW = 0x3,
> > +	DS1511_DOM = 0x4,
> > +	DS1511_MONTH = 0x5,
> > +	DS1511_YEAR = 0x6,
> > +	DS1511_CENTURY = 0x7,
> > +	DS1511_AM1_SEC = 0x8,
> > +	DS1511_AM2_MIN = 0x9,
> > +	DS1511_AM3_HOUR = 0xa,
> > +	DS1511_AM4_DATE = 0xb,
> > +	DS1511_WD_MSEC = 0xc,
> > +	DS1511_WD_SEC = 0xd,
> > +	DS1511_CONTROL_A = 0xe,
> > +	DS1511_CONTROL_B = 0xf,
> > +	DS1511_RAMADDR_LSB = 0x10,
> > +	DS1511_RAMDATA = 0x13
> > +} ds1511reg_t;
> 
> Please remove the typedef and just use `enum ds1511reg' everywhere.

I generally loathe enum's; this must have been cut-paste-o-mania ...
that's my excuse.

> > + static noinline void
> > +rtc_write(uint8_t val, uint32_t reg)
> 
> It's unusual (unique) to indent the function declaration by a single
> space in this way.  Maybe an editor option which needs fixing?

Besides unusual and unique, don't forget superior ~:^)  I was forced to
use this style many years ago and after a while became impressed with
the significant increase in readability as well as intra-file
navagation optimizations.  Feel free to demolish it, of course.

> Also, although there are good reasons to always put a newline after
> the declaration of the return type, kernel code generally doesn't do
> that except as a way of avoiding 80-col wraparound sometimes.

Hm, perhaps the convention could use some fixin'.  I'm just sayin'.

> IOW, please use
> 
> static noinline void rtc_write(uint8_t val, uint32_t reg)
> {
> 
> 
> Why was this function declared noinline?

Debugging detritus.

[snippage]

> > +
> > +//#define DS1511_WDOG_RESET_SUPPORT
> > +//#undef DS1511_WDOG_RESET_SUPPORT
> 
> c99-style comments will generate checkpatch warnings.

I fixed this up with a wordy comment.  I'm not totally sure what to do
with this code.

> Please run checkpatch.  It detects a lot of coding-style breakage in
> this patch.

Besides the braces which I think are perfectly acceptable, it whines
only about 80 chars, which I think I've taken care of.

> > +#ifdef DS1511_WDOG_RESET_SUPPORT
> > +/*
> > + * just enough code to set the watchdog timer so that it
> > + * will reboot the system
> > + */
> > + void
> > +ds1511_wdog_set(unsigned long deciseconds)
> > +{
> > +	/*
> > +	 * the wdog timer can take 99.99 seconds
> > +	 */
> > +	deciseconds %= 10000;
> > +	/*
> > +	 * set the wdog values in the wdog registers
> > +	 */
> > +	rtc_write(BIN2BCD(deciseconds % 100), DS1511_WD_MSEC);
> > +	rtc_write(BIN2BCD(deciseconds / 100), DS1511_WD_SEC);
> > +	/*
> > +	 * set wdog enable and wdog 'steering' bit to issue a reset
> > +	 */
> > +	rtc_write(DS1511_WDE | DS1511_WDS, RTC_CMD);
> > +}
> > +
> > + void
> > +ds1511_wdog_disable(void)
> > +{
> > +	/*
> > +	 * clear wdog enable and wdog 'steering' bits
> > +	 */
> > +	rtc_write(rtc_read(RTC_CMD) & ~(DS1511_WDE | DS1511_WDS),
> > RTC_CMD);
> > +	/*
> > +	 * clear the wdog counter
> > +	 */
> > +	rtc_write(0, DS1511_WD_MSEC);
> > +	rtc_write(0, DS1511_WD_SEC);
> > +}
> > +#endif
> 
> What's the story here?  This code is permanently disabled?

This chip includes a watchdog timer as well, but I couldn't think of a
non-akward way to implement that either as a separate file or in this
file.  Not to mention that I'm not terribly motivated since I don't
need more than this bit of code; hence I left it ifdef'd out but
included in case someone might want to make something more of it or
use it in their platform code.  Perhaps there is a conventional way of
handling such code?

> > + int
> > +ds1511_rtc_read_time(struct device *dev, struct rtc_time *rtc_tm)
> > +{
> > +	struct platform_device *pdev = to_platform_device(dev);
> > +	struct rtc_plat_data *pdata = platform_get_drvdata(pdev);
> > +	unsigned int century;
> > +	unsigned int flags;
> > +
> > +	/*
> > +	 * give enough time to update RTC in case of continuous
> > read
> > +	 */
> > +	if (pdata->last_jiffies == jiffies) {
> > +		msleep(1);
> > +	}
> 
> hm, that could be pretty obnoxious for some applications, I expect. 
> They'll run veeeery sloooowly, and inconsistently slowly across
> different values of CONFIG_HZ.  And the uninterruptible sleep will
> contribute to system load average.
> 
> What's going on here?
> 
> Do other RTC drivers do things like this?

Does look dodgy.  Cut-paste-o-mania from rtc-ds1553.  Removed from
updated patch in a coming-soon email.

> > +	pdata->last_jiffies = jiffies;
> > +

[snippage]

> > + static void
> > +ds1511_rtc_update_alarm(struct rtc_plat_data *pdata)
> > +{
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&pdata->rtc->irq_lock, flags);
> > +	rtc_write(pdata->alrm_mday < 0 || (pdata->irqen & RTC_UF) ?
> > +	       0x80 : BIN2BCD(pdata->alrm_mday) & 0x3f,
> > +	       RTC_ALARM_DATE);
> 
> hm.  You appear to be a C precedence whizz ;)

Not me; Nemoto-san perhaps.  More c-p-o-m from ds1553.  Frankly I'm
scared to touch it. ~:^)

I'll send an updated patch in another email.
