New home for DS1682 driver

New home for DS1682 driver

[Jean Delvare]

Hi Grant,

Driver ds1682 needs a new home, as drivers/i2c/chips will be gone soon.
Do you have a preference for where it should go?

As the device includes an EEPROM, the driver could go in
drivers/misc/eeprom, but OTOH the EEPROM in question is so small that
this can hardly be considered the main feature of the driver. So maybe
just drivers/misc?

-- 
Jean Delvare

Re: New home for DS1682 driver

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On Wed, Oct 07, 2009 at 11:50:17AM +0200, Jean Delvare wrote:
> Hi Grant,
> 
> Driver ds1682 needs a new home, as drivers/i2c/chips will be gone soon.
> Do you have a preference for where it should go?
> 
> As the device includes an EEPROM, the driver could go in
> drivers/misc/eeprom, but OTOH the EEPROM in question is so small that
> this can hardly be considered the main feature of the driver. So maybe
> just drivers/misc?

I would much prefer drivers/misc. What about tsl2550.c? I thought the plan back
then was to wait for IIO becoming mainline? Or shall we also put it to
drivers/misc until then?

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: New home for DS1682 driver

[Jean Delvare]

On Wed, 7 Oct 2009 11:56:10 +0200, Wolfram Sang wrote:
> On Wed, Oct 07, 2009 at 11:50:17AM +0200, Jean Delvare wrote:
> > Hi Grant,
> > 
> > Driver ds1682 needs a new home, as drivers/i2c/chips will be gone soon.
> > Do you have a preference for where it should go?
> > 
> > As the device includes an EEPROM, the driver could go in
> > drivers/misc/eeprom, but OTOH the EEPROM in question is so small that
> > this can hardly be considered the main feature of the driver. So maybe
> > just drivers/misc?
> 
> I would much prefer drivers/misc.

OK, fine with me. Will you send a patch?

> What about tsl2550.c? I thought the plan back
> then was to wait for IIO becoming mainline? Or shall we also put it to
> drivers/misc until then?

For tsl2550, the plan is indeed to wait for iio to become mainline. Or
the alternative ALS subsystem. I hope we won't have to wait too long.

-- 
Jean Delvare

Re: New home for DS1682 driver

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

On Wed, Oct 07, 2009 at 12:07:34PM +0200, Jean Delvare wrote:
> On Wed, 7 Oct 2009 11:56:10 +0200, Wolfram Sang wrote:
> > On Wed, Oct 07, 2009 at 11:50:17AM +0200, Jean Delvare wrote:
> > > Hi Grant,
> > > 
> > > Driver ds1682 needs a new home, as drivers/i2c/chips will be gone soon.
> > > Do you have a preference for where it should go?
> > > 
> > > As the device includes an EEPROM, the driver could go in
> > > drivers/misc/eeprom, but OTOH the EEPROM in question is so small that
> > > this can hardly be considered the main feature of the driver. So maybe
> > > just drivers/misc?
> > 
> > I would much prefer drivers/misc.
> 
> OK, fine with me. Will you send a patch?

Will do if you want one. My idea was to wait for IIO becoming mainline and then
take care of both.

> For tsl2550, the plan is indeed to wait for iio to become mainline. Or
> the alternative ALS subsystem. I hope we won't have to wait too long.

Good you mentioned ALS; I forgot about it. I am afraid it will still take a
while for IIO, but moving drivers twice is also ugly :(

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: New home for DS1682 driver

[Jonathan Cameron]

Wolfram Sang wrote:
> On Wed, Oct 07, 2009 at 12:07:34PM +0200, Jean Delvare wrote:
>> On Wed, 7 Oct 2009 11:56:10 +0200, Wolfram Sang wrote:
>>> On Wed, Oct 07, 2009 at 11:50:17AM +0200, Jean Delvare wrote:
>>>> Hi Grant,
>>>>
>>>> Driver ds1682 needs a new home, as drivers/i2c/chips will be gone soon.
>>>> Do you have a preference for where it should go?
>>>>
>>>> As the device includes an EEPROM, the driver could go in
>>>> drivers/misc/eeprom, but OTOH the EEPROM in question is so small that
>>>> this can hardly be considered the main feature of the driver. So maybe
>>>> just drivers/misc?
>>> I would much prefer drivers/misc.
>> OK, fine with me. Will you send a patch?
> 
> Will do if you want one. My idea was to wait for IIO becoming mainline and then
> take care of both.
> 
>> For tsl2550, the plan is indeed to wait for iio to become mainline. Or
>> the alternative ALS subsystem. I hope we won't have to wait too long.
> 
> Good you mentioned ALS; I forgot about it. I am afraid it will still take a
> while for IIO, but moving drivers twice is also ugly :(
> 
ALS is the right place for this one. I've offered to do the port but haven't had
a chance as yet.

These light sensors are two slow to really require most of IIO. When you can get
all data from a chip by polling at a couple hz life becomes somewhat easy!
Also moving the tsl2561 out of iio and into ALS asap. 

Though I'm guessing ALS won't merge until next merge window opens. To my mind
it's clean enough to merge now as a new 'driver' but I'm guessing as a subsystem
this might not get past Linus. I'm not bothered about ditching the iio based
tsl2561 immediately (as far as I know I'm the only user other than on boards
for which I roll out the images anwyay - please yell if not!),
but moving the tsl2550 will probably involve a few userspace api changes
(to conform to what als expects), not to mention a change in location in sysfs.

I've no idea how heavily used this driver is, so what do people reckon we do about
about deprecating and removing the old driver? (the usual 2 kernel release or
can we speed it up to finally get rid of that chips directory!)

Also I fear you are right about IIO. It's now in staging which is getting some eyes
on the code which is very helpful, but there are a couple of big changes that will probably
be needed before moving out of there.  

Thanks,

Jonathan

Re: New home for DS1682 driver

[Jean Delvare]

On Wed, 07 Oct 2009 13:12:39 +0100, Jonathan Cameron wrote:
> ALS is the right place for this one. I've offered to do the port but haven't had
> a chance as yet.
> 
> These light sensors are two slow to really require most of IIO. When you can get
> all data from a chip by polling at a couple hz life becomes somewhat easy!
> Also moving the tsl2561 out of iio and into ALS asap. 
> 
> Though I'm guessing ALS won't merge until next merge window opens. To my mind
> it's clean enough to merge now as a new 'driver' but I'm guessing as a subsystem
> this might not get past Linus. I'm not bothered about ditching the iio based
> tsl2561 immediately (as far as I know I'm the only user other than on boards
> for which I roll out the images anwyay - please yell if not!),
> but moving the tsl2550 will probably involve a few userspace api changes
> (to conform to what als expects), not to mention a change in location in sysfs.
> 
> I've no idea how heavily used this driver is, so what do people reckon we do about
> about deprecating and removing the old driver? (the usual 2 kernel release or
> can we speed it up to finally get rid of that chips directory!)

I am aware of 3 users for the tsl2550 driver (all Cc'd): Rodolfo
Giometti, who said 3 months ago that his hardware was now out of order,
Michele De Candia, and myself. As far as I am concerned, you can change
pretty much whatever you want as long as there is an easy way to read
the lux value from user-space. I'm using one TSL2550 for my own fun and
that's it. Don't know about Michele.

I think we can simply move the driver and convert it directly, and
document the interface changes. I've always said loudly that the
tsl2550 driver was the first of its kind and as such its interface was
subject to change when other similar drivers would be added. Which is
what's happening right now.

-- 
Jean Delvare

Re: New home for DS1682 driver

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


> I think we can simply move the driver and convert it directly, and
> document the interface changes. I've always said loudly that the
> tsl2550 driver was the first of its kind and as such its interface was
> subject to change when other similar drivers would be added. Which is
> what's happening right now.

ACK. So we move it when ALS is going mainline (probably next merge-window)?
That's foreseeable enough, I think. BTW Jonathan, is there an ALS-tree or so? I
couldn't find any reference...

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: New home for DS1682 driver

[Rodolfo Giometti]

On Wed, Oct 07, 2009 at 02:27:46PM +0200, Jean Delvare wrote:
> On Wed, 07 Oct 2009 13:12:39 +0100, Jonathan Cameron wrote:
> > ALS is the right place for this one. I've offered to do the port but haven't had
> > a chance as yet.
> > 
> > These light sensors are two slow to really require most of IIO. When you can get
> > all data from a chip by polling at a couple hz life becomes somewhat easy!
> > Also moving the tsl2561 out of iio and into ALS asap. 
> > 
> > Though I'm guessing ALS won't merge until next merge window opens. To my mind
> > it's clean enough to merge now as a new 'driver' but I'm guessing as a subsystem
> > this might not get past Linus. I'm not bothered about ditching the iio based
> > tsl2561 immediately (as far as I know I'm the only user other than on boards
> > for which I roll out the images anwyay - please yell if not!),
> > but moving the tsl2550 will probably involve a few userspace api changes
> > (to conform to what als expects), not to mention a change in location in sysfs.
> > 
> > I've no idea how heavily used this driver is, so what do people reckon we do about
> > about deprecating and removing the old driver? (the usual 2 kernel release or
> > can we speed it up to finally get rid of that chips directory!)
> 
> I am aware of 3 users for the tsl2550 driver (all Cc'd): Rodolfo
> Giometti, who said 3 months ago that his hardware was now out of order,
> Michele De Candia, and myself. As far as I am concerned, you can change
> pretty much whatever you want as long as there is an easy way to read
> the lux value from user-space. I'm using one TSL2550 for my own fun and
> that's it. Don't know about Michele.
> 
> I think we can simply move the driver and convert it directly, and
> document the interface changes. I've always said loudly that the
> tsl2550 driver was the first of its kind and as such its interface was
> subject to change when other similar drivers would be added. Which is
> what's happening right now.

I agree for a new userland API. I just proposed the simplest one
currently available but any enhancement is welcomed. :)

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail: giometti-AVVDYK/kqiJWk0Htik3J/w@public.gmane.org
Linux Device Driver                          giometti-k2GhghHVRtY@public.gmane.org
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it

Re: New home for DS1682 driver

[Grant Likely]

On Wed, Oct 7, 2009 at 3:50 AM, Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:
> Hi Grant,
>
> Driver ds1682 needs a new home, as drivers/i2c/chips will be gone soon.
> Do you have a preference for where it should go?
>
> As the device includes an EEPROM, the driver could go in
> drivers/misc/eeprom, but OTOH the EEPROM in question is so small that
> this can hardly be considered the main feature of the driver. So maybe
> just drivers/misc?

drivers/misc works for me.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: New home for DS1682 driver

[Jonathan Cameron]

Wolfram Sang wrote:
>> I think we can simply move the driver and convert it directly, and
>> document the interface changes. I've always said loudly that the
>> tsl2550 driver was the first of its kind and as such its interface was
>> subject to change when other similar drivers would be added. Which is
>> what's happening right now.
> 
> ACK. So we move it when ALS is going mainline (probably next merge-window)?
> That's foreseeable enough, I think. BTW Jonathan, is there an ALS-tree or so? I
> couldn't find any reference...
I think it's just a patch set at the mo - I'll post reply to that tread and ask
what the intentions wrt merge and who is doing it etc.

Jonathan

[PATCH] i2c/chips: move ds1682 to drivers/misc

[Wolfram Sang]

As i2c/chips is deprecated, move ds1682 to a more apropriate location.
Build tested.

Signed-off-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
---
 drivers/i2c/chips/Kconfig  |   10 --
 drivers/i2c/chips/Makefile |    1 -
 drivers/i2c/chips/ds1682.c |  267 --------------------------------------------
 drivers/misc/Kconfig       |   10 ++
 drivers/misc/Makefile      |    1 +
 drivers/misc/ds1682.c      |  267 ++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 278 insertions(+), 278 deletions(-)
 delete mode 100644 drivers/i2c/chips/ds1682.c
 create mode 100644 drivers/misc/ds1682.c

diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index f9618f4..ae4539d 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -6,16 +6,6 @@
 
 menu "Miscellaneous I2C Chip support"
 
-config DS1682
-	tristate "Dallas DS1682 Total Elapsed Time Recorder with Alarm"
-	depends on EXPERIMENTAL
-	help
-	  If you say yes here you get support for Dallas Semiconductor
-	  DS1682 Total Elapsed Time Recorder.
-
-	  This driver can also be built as a module.  If so, the module
-	  will be called ds1682.
-
 config SENSORS_TSL2550
 	tristate "Taos TSL2550 ambient light sensor"
 	depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 749cf36..fe0af0f 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -10,7 +10,6 @@
 # * I/O expander drivers go to drivers/gpio
 #
 
-obj-$(CONFIG_DS1682)		+= ds1682.o
 obj-$(CONFIG_SENSORS_TSL2550)	+= tsl2550.o
 
 ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
diff --git a/drivers/i2c/chips/ds1682.c b/drivers/i2c/chips/ds1682.c
deleted file mode 100644
index f3ee4a1..0000000
--- a/drivers/i2c/chips/ds1682.c
+++ /dev/null
@@ -1,267 +0,0 @@
-/*
- * Dallas Semiconductor DS1682 Elapsed Time Recorder device driver
- *
- * Written by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
- *
- * Copyright (C) 2007 Secret Lab Technologies 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.
- */
-
-/*
- * The DS1682 elapsed timer recorder is a simple device that implements
- * one elapsed time counter, one event counter, an alarm signal and 10
- * bytes of general purpose EEPROM.
- *
- * This driver provides access to the DS1682 counters and user data via
- * the sysfs.  The following attributes are added to the device node:
- *     elapsed_time (u32): Total elapsed event time in ms resolution
- *     alarm_time (u32): When elapsed time exceeds the value in alarm_time,
- *                       then the alarm pin is asserted.
- *     event_count (u16): number of times the event pin has gone low.
- *     eeprom (u8[10]): general purpose EEPROM
- *
- * Counter registers and user data are both read/write unless the device
- * has been write protected.  This driver does not support turning off write
- * protection.  Once write protection is turned on, it is impossible to
- * turn it off again, so I have left the feature out of this driver to avoid
- * accidental enabling, but it is trivial to add write protect support.
- *
- */
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/slab.h>
-#include <linux/i2c.h>
-#include <linux/string.h>
-#include <linux/list.h>
-#include <linux/sysfs.h>
-#include <linux/ctype.h>
-#include <linux/hwmon-sysfs.h>
-
-/* Device registers */
-#define DS1682_REG_CONFIG		0x00
-#define DS1682_REG_ALARM		0x01
-#define DS1682_REG_ELAPSED		0x05
-#define DS1682_REG_EVT_CNTR		0x09
-#define DS1682_REG_EEPROM		0x0b
-#define DS1682_REG_RESET		0x1d
-#define DS1682_REG_WRITE_DISABLE	0x1e
-#define DS1682_REG_WRITE_MEM_DISABLE	0x1f
-
-#define DS1682_EEPROM_SIZE		10
-
-/*
- * Generic counter attributes
- */
-static ssize_t ds1682_show(struct device *dev, struct device_attribute *attr,
-			   char *buf)
-{
-	struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
-	struct i2c_client *client = to_i2c_client(dev);
-	__le32 val = 0;
-	int rc;
-
-	dev_dbg(dev, "ds1682_show() called on %s\n", attr->attr.name);
-
-	/* Read the register */
-	rc = i2c_smbus_read_i2c_block_data(client, sattr->index, sattr->nr,
-					   (u8 *) & val);
-	if (rc < 0)
-		return -EIO;
-
-	/* Special case: the 32 bit regs are time values with 1/4s
-	 * resolution, scale them up to milliseconds */
-	if (sattr->nr == 4)
-		return sprintf(buf, "%llu\n",
-			((unsigned long long)le32_to_cpu(val)) * 250);
-
-	/* Format the output string and return # of bytes */
-	return sprintf(buf, "%li\n", (long)le32_to_cpu(val));
-}
-
-static ssize_t ds1682_store(struct device *dev, struct device_attribute *attr,
-			    const char *buf, size_t count)
-{
-	struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
-	struct i2c_client *client = to_i2c_client(dev);
-	char *endp;
-	u64 val;
-	__le32 val_le;
-	int rc;
-
-	dev_dbg(dev, "ds1682_store() called on %s\n", attr->attr.name);
-
-	/* Decode input */
-	val = simple_strtoull(buf, &endp, 0);
-	if (buf == endp) {
-		dev_dbg(dev, "input string not a number\n");
-		return -EINVAL;
-	}
-
-	/* Special case: the 32 bit regs are time values with 1/4s
-	 * resolution, scale input down to quarter-seconds */
-	if (sattr->nr == 4)
-		do_div(val, 250);
-
-	/* write out the value */
-	val_le = cpu_to_le32(val);
-	rc = i2c_smbus_write_i2c_block_data(client, sattr->index, sattr->nr,
-					    (u8 *) & val_le);
-	if (rc < 0) {
-		dev_err(dev, "register write failed; reg=0x%x, size=%i\n",
-			sattr->index, sattr->nr);
-		return -EIO;
-	}
-
-	return count;
-}
-
-/*
- * Simple register attributes
- */
-static SENSOR_DEVICE_ATTR_2(elapsed_time, S_IRUGO | S_IWUSR, ds1682_show,
-			    ds1682_store, 4, DS1682_REG_ELAPSED);
-static SENSOR_DEVICE_ATTR_2(alarm_time, S_IRUGO | S_IWUSR, ds1682_show,
-			    ds1682_store, 4, DS1682_REG_ALARM);
-static SENSOR_DEVICE_ATTR_2(event_count, S_IRUGO | S_IWUSR, ds1682_show,
-			    ds1682_store, 2, DS1682_REG_EVT_CNTR);
-
-static const struct attribute_group ds1682_group = {
-	.attrs = (struct attribute *[]) {
-		&sensor_dev_attr_elapsed_time.dev_attr.attr,
-		&sensor_dev_attr_alarm_time.dev_attr.attr,
-		&sensor_dev_attr_event_count.dev_attr.attr,
-		NULL,
-	},
-};
-
-/*
- * User data attribute
- */
-static ssize_t ds1682_eeprom_read(struct kobject *kobj, struct bin_attribute *attr,
-				  char *buf, loff_t off, size_t count)
-{
-	struct i2c_client *client = kobj_to_i2c_client(kobj);
-	int rc;
-
-	dev_dbg(&client->dev, "ds1682_eeprom_read(p=%p, off=%lli, c=%zi)\n",
-		buf, off, count);
-
-	if (off >= DS1682_EEPROM_SIZE)
-		return 0;
-
-	if (off + count > DS1682_EEPROM_SIZE)
-		count = DS1682_EEPROM_SIZE - off;
-
-	rc = i2c_smbus_read_i2c_block_data(client, DS1682_REG_EEPROM + off,
-					   count, buf);
-	if (rc < 0)
-		return -EIO;
-
-	return count;
-}
-
-static ssize_t ds1682_eeprom_write(struct kobject *kobj, struct bin_attribute *attr,
-				   char *buf, loff_t off, size_t count)
-{
-	struct i2c_client *client = kobj_to_i2c_client(kobj);
-
-	dev_dbg(&client->dev, "ds1682_eeprom_write(p=%p, off=%lli, c=%zi)\n",
-		buf, off, count);
-
-	if (off >= DS1682_EEPROM_SIZE)
-		return -ENOSPC;
-
-	if (off + count > DS1682_EEPROM_SIZE)
-		count = DS1682_EEPROM_SIZE - off;
-
-	/* Write out to the device */
-	if (i2c_smbus_write_i2c_block_data(client, DS1682_REG_EEPROM + off,
-					   count, buf) < 0)
-		return -EIO;
-
-	return count;
-}
-
-static struct bin_attribute ds1682_eeprom_attr = {
-	.attr = {
-		.name = "eeprom",
-		.mode = S_IRUGO | S_IWUSR,
-	},
-	.size = DS1682_EEPROM_SIZE,
-	.read = ds1682_eeprom_read,
-	.write = ds1682_eeprom_write,
-};
-
-/*
- * Called when a ds1682 device is matched with this driver
- */
-static int ds1682_probe(struct i2c_client *client,
-			const struct i2c_device_id *id)
-{
-	int rc;
-
-	if (!i2c_check_functionality(client->adapter,
-				     I2C_FUNC_SMBUS_I2C_BLOCK)) {
-		dev_err(&client->dev, "i2c bus does not support the ds1682\n");
-		rc = -ENODEV;
-		goto exit;
-	}
-
-	rc = sysfs_create_group(&client->dev.kobj, &ds1682_group);
-	if (rc)
-		goto exit;
-
-	rc = sysfs_create_bin_file(&client->dev.kobj, &ds1682_eeprom_attr);
-	if (rc)
-		goto exit_bin_attr;
-
-	return 0;
-
- exit_bin_attr:
-	sysfs_remove_group(&client->dev.kobj, &ds1682_group);
- exit:
-	return rc;
-}
-
-static int ds1682_remove(struct i2c_client *client)
-{
-	sysfs_remove_bin_file(&client->dev.kobj, &ds1682_eeprom_attr);
-	sysfs_remove_group(&client->dev.kobj, &ds1682_group);
-	return 0;
-}
-
-static const struct i2c_device_id ds1682_id[] = {
-	{ "ds1682", 0 },
-	{ }
-};
-MODULE_DEVICE_TABLE(i2c, ds1682_id);
-
-static struct i2c_driver ds1682_driver = {
-	.driver = {
-		.name = "ds1682",
-	},
-	.probe = ds1682_probe,
-	.remove = ds1682_remove,
-	.id_table = ds1682_id,
-};
-
-static int __init ds1682_init(void)
-{
-	return i2c_add_driver(&ds1682_driver);
-}
-
-static void __exit ds1682_exit(void)
-{
-	i2c_del_driver(&ds1682_driver);
-}
-
-MODULE_AUTHOR("Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>");
-MODULE_DESCRIPTION("DS1682 Elapsed Time Indicator driver");
-MODULE_LICENSE("GPL");
-
-module_init(ds1682_init);
-module_exit(ds1682_exit);
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index df1f86b..ebff36b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -246,6 +246,16 @@ config EP93XX_PWM
 	  To compile this driver as a module, choose M here: the module will
 	  be called ep93xx_pwm.
 
+config DS1682
+	tristate "Dallas DS1682 Total Elapsed Time Recorder with Alarm"
+	depends on EXPERIMENTAL
+	help
+	  If you say yes here you get support for Dallas Semiconductor
+	  DS1682 Total Elapsed Time Recorder.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called ds1682.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f982d2e..b6245e4 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SGI_GRU)		+= sgi-gru/
 obj-$(CONFIG_HP_ILO)		+= hpilo.o
 obj-$(CONFIG_ISL29003)		+= isl29003.o
 obj-$(CONFIG_EP93XX_PWM)	+= ep93xx_pwm.o
+obj-$(CONFIG_DS1682)		+= ds1682.o
 obj-$(CONFIG_C2PORT)		+= c2port/
 obj-y				+= eeprom/
 obj-y				+= cb710/
diff --git a/drivers/misc/ds1682.c b/drivers/misc/ds1682.c
new file mode 100644
index 0000000..f3ee4a1
--- /dev/null
+++ b/drivers/misc/ds1682.c
@@ -0,0 +1,267 @@
+/*
+ * Dallas Semiconductor DS1682 Elapsed Time Recorder device driver
+ *
+ * Written by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
+ *
+ * Copyright (C) 2007 Secret Lab Technologies 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.
+ */
+
+/*
+ * The DS1682 elapsed timer recorder is a simple device that implements
+ * one elapsed time counter, one event counter, an alarm signal and 10
+ * bytes of general purpose EEPROM.
+ *
+ * This driver provides access to the DS1682 counters and user data via
+ * the sysfs.  The following attributes are added to the device node:
+ *     elapsed_time (u32): Total elapsed event time in ms resolution
+ *     alarm_time (u32): When elapsed time exceeds the value in alarm_time,
+ *                       then the alarm pin is asserted.
+ *     event_count (u16): number of times the event pin has gone low.
+ *     eeprom (u8[10]): general purpose EEPROM
+ *
+ * Counter registers and user data are both read/write unless the device
+ * has been write protected.  This driver does not support turning off write
+ * protection.  Once write protection is turned on, it is impossible to
+ * turn it off again, so I have left the feature out of this driver to avoid
+ * accidental enabling, but it is trivial to add write protect support.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/i2c.h>
+#include <linux/string.h>
+#include <linux/list.h>
+#include <linux/sysfs.h>
+#include <linux/ctype.h>
+#include <linux/hwmon-sysfs.h>
+
+/* Device registers */
+#define DS1682_REG_CONFIG		0x00
+#define DS1682_REG_ALARM		0x01
+#define DS1682_REG_ELAPSED		0x05
+#define DS1682_REG_EVT_CNTR		0x09
+#define DS1682_REG_EEPROM		0x0b
+#define DS1682_REG_RESET		0x1d
+#define DS1682_REG_WRITE_DISABLE	0x1e
+#define DS1682_REG_WRITE_MEM_DISABLE	0x1f
+
+#define DS1682_EEPROM_SIZE		10
+
+/*
+ * Generic counter attributes
+ */
+static ssize_t ds1682_show(struct device *dev, struct device_attribute *attr,
+			   char *buf)
+{
+	struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+	struct i2c_client *client = to_i2c_client(dev);
+	__le32 val = 0;
+	int rc;
+
+	dev_dbg(dev, "ds1682_show() called on %s\n", attr->attr.name);
+
+	/* Read the register */
+	rc = i2c_smbus_read_i2c_block_data(client, sattr->index, sattr->nr,
+					   (u8 *) & val);
+	if (rc < 0)
+		return -EIO;
+
+	/* Special case: the 32 bit regs are time values with 1/4s
+	 * resolution, scale them up to milliseconds */
+	if (sattr->nr == 4)
+		return sprintf(buf, "%llu\n",
+			((unsigned long long)le32_to_cpu(val)) * 250);
+
+	/* Format the output string and return # of bytes */
+	return sprintf(buf, "%li\n", (long)le32_to_cpu(val));
+}
+
+static ssize_t ds1682_store(struct device *dev, struct device_attribute *attr,
+			    const char *buf, size_t count)
+{
+	struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+	struct i2c_client *client = to_i2c_client(dev);
+	char *endp;
+	u64 val;
+	__le32 val_le;
+	int rc;
+
+	dev_dbg(dev, "ds1682_store() called on %s\n", attr->attr.name);
+
+	/* Decode input */
+	val = simple_strtoull(buf, &endp, 0);
+	if (buf == endp) {
+		dev_dbg(dev, "input string not a number\n");
+		return -EINVAL;
+	}
+
+	/* Special case: the 32 bit regs are time values with 1/4s
+	 * resolution, scale input down to quarter-seconds */
+	if (sattr->nr == 4)
+		do_div(val, 250);
+
+	/* write out the value */
+	val_le = cpu_to_le32(val);
+	rc = i2c_smbus_write_i2c_block_data(client, sattr->index, sattr->nr,
+					    (u8 *) & val_le);
+	if (rc < 0) {
+		dev_err(dev, "register write failed; reg=0x%x, size=%i\n",
+			sattr->index, sattr->nr);
+		return -EIO;
+	}
+
+	return count;
+}
+
+/*
+ * Simple register attributes
+ */
+static SENSOR_DEVICE_ATTR_2(elapsed_time, S_IRUGO | S_IWUSR, ds1682_show,
+			    ds1682_store, 4, DS1682_REG_ELAPSED);
+static SENSOR_DEVICE_ATTR_2(alarm_time, S_IRUGO | S_IWUSR, ds1682_show,
+			    ds1682_store, 4, DS1682_REG_ALARM);
+static SENSOR_DEVICE_ATTR_2(event_count, S_IRUGO | S_IWUSR, ds1682_show,
+			    ds1682_store, 2, DS1682_REG_EVT_CNTR);
+
+static const struct attribute_group ds1682_group = {
+	.attrs = (struct attribute *[]) {
+		&sensor_dev_attr_elapsed_time.dev_attr.attr,
+		&sensor_dev_attr_alarm_time.dev_attr.attr,
+		&sensor_dev_attr_event_count.dev_attr.attr,
+		NULL,
+	},
+};
+
+/*
+ * User data attribute
+ */
+static ssize_t ds1682_eeprom_read(struct kobject *kobj, struct bin_attribute *attr,
+				  char *buf, loff_t off, size_t count)
+{
+	struct i2c_client *client = kobj_to_i2c_client(kobj);
+	int rc;
+
+	dev_dbg(&client->dev, "ds1682_eeprom_read(p=%p, off=%lli, c=%zi)\n",
+		buf, off, count);
+
+	if (off >= DS1682_EEPROM_SIZE)
+		return 0;
+
+	if (off + count > DS1682_EEPROM_SIZE)
+		count = DS1682_EEPROM_SIZE - off;
+
+	rc = i2c_smbus_read_i2c_block_data(client, DS1682_REG_EEPROM + off,
+					   count, buf);
+	if (rc < 0)
+		return -EIO;
+
+	return count;
+}
+
+static ssize_t ds1682_eeprom_write(struct kobject *kobj, struct bin_attribute *attr,
+				   char *buf, loff_t off, size_t count)
+{
+	struct i2c_client *client = kobj_to_i2c_client(kobj);
+
+	dev_dbg(&client->dev, "ds1682_eeprom_write(p=%p, off=%lli, c=%zi)\n",
+		buf, off, count);
+
+	if (off >= DS1682_EEPROM_SIZE)
+		return -ENOSPC;
+
+	if (off + count > DS1682_EEPROM_SIZE)
+		count = DS1682_EEPROM_SIZE - off;
+
+	/* Write out to the device */
+	if (i2c_smbus_write_i2c_block_data(client, DS1682_REG_EEPROM + off,
+					   count, buf) < 0)
+		return -EIO;
+
+	return count;
+}
+
+static struct bin_attribute ds1682_eeprom_attr = {
+	.attr = {
+		.name = "eeprom",
+		.mode = S_IRUGO | S_IWUSR,
+	},
+	.size = DS1682_EEPROM_SIZE,
+	.read = ds1682_eeprom_read,
+	.write = ds1682_eeprom_write,
+};
+
+/*
+ * Called when a ds1682 device is matched with this driver
+ */
+static int ds1682_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	int rc;
+
+	if (!i2c_check_functionality(client->adapter,
+				     I2C_FUNC_SMBUS_I2C_BLOCK)) {
+		dev_err(&client->dev, "i2c bus does not support the ds1682\n");
+		rc = -ENODEV;
+		goto exit;
+	}
+
+	rc = sysfs_create_group(&client->dev.kobj, &ds1682_group);
+	if (rc)
+		goto exit;
+
+	rc = sysfs_create_bin_file(&client->dev.kobj, &ds1682_eeprom_attr);
+	if (rc)
+		goto exit_bin_attr;
+
+	return 0;
+
+ exit_bin_attr:
+	sysfs_remove_group(&client->dev.kobj, &ds1682_group);
+ exit:
+	return rc;
+}
+
+static int ds1682_remove(struct i2c_client *client)
+{
+	sysfs_remove_bin_file(&client->dev.kobj, &ds1682_eeprom_attr);
+	sysfs_remove_group(&client->dev.kobj, &ds1682_group);
+	return 0;
+}
+
+static const struct i2c_device_id ds1682_id[] = {
+	{ "ds1682", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, ds1682_id);
+
+static struct i2c_driver ds1682_driver = {
+	.driver = {
+		.name = "ds1682",
+	},
+	.probe = ds1682_probe,
+	.remove = ds1682_remove,
+	.id_table = ds1682_id,
+};
+
+static int __init ds1682_init(void)
+{
+	return i2c_add_driver(&ds1682_driver);
+}
+
+static void __exit ds1682_exit(void)
+{
+	i2c_del_driver(&ds1682_driver);
+}
+
+MODULE_AUTHOR("Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>");
+MODULE_DESCRIPTION("DS1682 Elapsed Time Indicator driver");
+MODULE_LICENSE("GPL");
+
+module_init(ds1682_init);
+module_exit(ds1682_exit);
-- 
1.6.3.3

Re: [PATCH] i2c/chips: move ds1682 to drivers/misc

[Grant Likely]

On Wed, Oct 7, 2009 at 4:31 PM, Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> As i2c/chips is deprecated, move ds1682 to a more apropriate location.
> Build tested.
>
> Signed-off-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>

Re: [PATCH] i2c/chips: move ds1682 to drivers/misc

[Jean Delvare]

Hi Wolfram,

On Thu,  8 Oct 2009 00:31:50 +0200, Wolfram Sang wrote:
> As i2c/chips is deprecated, move ds1682 to a more apropriate location.
> Build tested.
> 
> Signed-off-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Cc: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
> ---
>  drivers/i2c/chips/Kconfig  |   10 --
>  drivers/i2c/chips/Makefile |    1 -
>  drivers/i2c/chips/ds1682.c |  267 --------------------------------------------
>  drivers/misc/Kconfig       |   10 ++
>  drivers/misc/Makefile      |    1 +
>  drivers/misc/ds1682.c      |  267 ++++++++++++++++++++++++++++++++++++++++++++
>  6 files changed, 278 insertions(+), 278 deletions(-)
>  delete mode 100644 drivers/i2c/chips/ds1682.c
>  create mode 100644 drivers/misc/ds1682.c

Thanks. Applied with one fix:

> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -246,6 +246,16 @@ config EP93XX_PWM
>  	  To compile this driver as a module, choose M here: the module will
>  	  be called ep93xx_pwm.
>  
> +config DS1682
> +	tristate "Dallas DS1682 Total Elapsed Time Recorder with Alarm"
> +	depends on EXPERIMENTAL

Depends on I2C too.

> +	help
> +	  If you say yes here you get support for Dallas Semiconductor
> +	  DS1682 Total Elapsed Time Recorder.
> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called ds1682.
> +
>  source "drivers/misc/c2port/Kconfig"
>  source "drivers/misc/eeprom/Kconfig"
>  source "drivers/misc/cb710/Kconfig"

-- 
Jean Delvare

Re: [PATCH] i2c/chips: move ds1682 to drivers/misc

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

Hi Jean,

> > +config DS1682
> > +	tristate "Dallas DS1682 Total Elapsed Time Recorder with Alarm"
> > +	depends on EXPERIMENTAL
> 
> Depends on I2C too.

I've got this strange feeling of dejavu... One driver to go, we'll see if I get
it right then :D

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]