linux-kernel - Re: [PATCH v2] Add Dallas DS1390 RTC chip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 20 Oct 2008 09:59:03 -0700
From:	David Brownell <david-b@...bell.net>
To:	Mark Jackson <mpfj@...c.co.uk>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Alessandro Zummo <alessandro.zummo@...ertech.it>,
	rtc-linux@...glegroups.com, spi-devel-general@...ts.sourceforge.net
Subject: Re: [PATCH v2] Add Dallas DS1390 RTC chip

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@...c.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),
> +};

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