New home for DS1682 driver

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?

Quoted 5 lines · 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?

Quoted 4 lines

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?

Quoted 6 lines · Wolfram Sang

Quoted 5 lines · 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?

Quoted 6 lines

Quoted 4 lines

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?

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.

Quoted 7 lines · Jean Delvare

Quoted 6 lines · Wolfram Sang

Quoted 5 lines · 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?

Quoted 6 lines

Quoted 5 lines

Quoted 4 lines

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.

Quoted 2 lines

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!)

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.

Quoted 5 lines

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

Quoted 15 lines · Jonathan Cameron

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.

Quoted 3 lines

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.

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?

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

Signed-off-by Wolfram Sang <[email protected]>

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

Signed-off-by Wolfram Sang <[email protected]>

Cc Grant Likely <grant.likely-s3s/[email protected]>

Cc Jean Delvare <[email protected]>

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

drivers/misc/Kconfig +7 -0

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

drivers/misc/Kconfig config EP93XX_PWM · line 251

Quoted 3 lines

drivers/misc/Kconfig +3 -0

+config DS1682
+	tristate "Dallas DS1682 Total Elapsed Time Recorder with Alarm"
+	depends on EXPERIMENTAL

Depends on I2C too.