public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Mark Jackson <mpfj@mimc.co.uk>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Alessandro Zummo <alessandro.zummo@towertech.it>,
	rtc-linux@googlegroups.com,
	spi-devel-general@lists.sourceforge.net
Subject: Re: [PATCH v2] Add Dallas DS1390 RTC chip
Date: Mon, 20 Oct 2008 09:59:03 -0700	[thread overview]
Message-ID: <200810200959.03486.david-b@pacbell.net> (raw)
In-Reply-To: <48FC442E.9070206@mimc.co.uk>

On Monday 20 October 2008, Mark Jackson wrote:
> +config RTC_DRV_DS1390
> +       tristate "Dallas/Maxim DS1390"
> +       help
> +         If you say yes here you get support for the DS1390 and probably
> +         other chips connected with SPI.

According to the datasheet at

  http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4359

the DS1390, DS1391, DS1392, DS1393, and DS1394 chips are essentially
all the same except that the control register for the '91 and '92
has different bits.

So it looks like this driver should already support three chips, if
the spi_board_info has the right spi->mode bits set:  SPI_MODE_* and
SPI_3WIRE.  And if there were platform_data defined to hold the
initial control register setting, two more ... configuring that
trickle charger would already justify having platform_data too.

Please strike the "probably" and list at least those three chips.


> +         The first seven registers on these chips hold an RTC, and other
> +         registers may add features such as NVRAM, a trickle charger for
> +         the RTC/NVRAM backup power, and alarms.  This driver may not
> +         expose all those available chip features.

The "these chips" language bothers me.  This looks like cut'n'paste
from the rtc-ds1307 language, but you don't actually describe what
chips the driver handles.

I'd rather see the description say which other chips it expects to
handle, and have the description match.  All of these have alarms
and a trickle charger for backup power, but none have NVRAM.


> +/* drivers/rtc/rtc-ds1390.c

It's a bit of a nit, but the convention is 

	/*
	 * rtc-ds1390.c -- driver for DS1390 and related SPI RTCs
	 *
	 * Copyright (C) ... etc

Maybe with a separate "written by Mark Jackson" next to the copyright.

> + *
> + * Copyright (C) 2008 Mercury IMC Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Driver for DS1390 spi RTC
> + *

And to keep changelogs out of source code; that's what GIT is for!


> + * Changelog:
> + *
> + * 04-Apr-2008: Mark Jackson <mpfj@mimc.co.uk>
> + *             - Initial version based on rtc-max6902
> + *             - No alarm support though !!
> + */

My personal taste is to have the copyright comment cover ONLY the
copyright (and licensing) issues, and have a separate comment
describing open issues with the code.  In this case, that would
be no support for the alarm, any other aspect of the control
register, or (unless it was set up by pre-OS code) the trickle
charger ... 


> +static int ds1390_get_datetime(struct device *dev, struct rtc_time *dt)
> +{
> +       ...
> +       return 0;

Especially since you don't currently have logic to handle the
initialization from first power up (clearing OSF etc), it'd be
good to "return rtc_valid_tm(dt);".


> +       status = spi_sync(spi, &message);
> +       if (status == 0)
> +               return message.status;
> +
> +       return 0;

Nowadays that can just be "return spi_sync(...)".

Although ... you can make this code be a bunch simpler
by using spi_write_then_read().


> +static struct spi_driver ds1390_driver = {
> +       .driver = {
> +               .name   = "rtc-ds1390",
> +               .bus    = &spi_bus_type,

Rule of thumb:  always let the bus code set driver->bus,
never set it yourself.

> +               .owner  = THIS_MODULE,
> +       },
> +       .probe  = ds1390_probe,
> +       .remove = __devexit_p(ds1390_remove),
> +};


      parent reply	other threads:[~2008-10-20 16:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-20  8:41 [PATCH v2] Add Dallas DS1390 RTC chip Mark Jackson
2008-10-20  9:46 ` Alessandro Zummo
2008-10-20 11:44   ` Mark Jackson
2008-10-20 16:59 ` David Brownell [this message]

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=200810200959.03486.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=alessandro.zummo@towertech.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpfj@mimc.co.uk \
    --cc=rtc-linux@googlegroups.com \
    --cc=spi-devel-general@lists.sourceforge.net \
    /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