aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/hwmon/sht15.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2009-10-11Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/stagingLinus Torvalds1-1/+6
* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: hwmon: (s3c-hwmon) Disable build for S3C64xx MAINTAINERS: Fix Riku Voipio's address hwmon: (asus_atk0110) Enable the EC hwmon: (asus_atk0110) Refactor the code hwmon: (sht15) Fix spurious section mismatch warning
2009-10-11headers: remove sched.h from interrupt.hAlexey Dobriyan1-0/+1
After m68k's task_thread_info() doesn't refer to current, it's possible to remove sched.h from interrupt.h and not break m68k! Many thanks to Heiko Carstens for allowing this. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
2009-10-09hwmon: (sht15) Fix spurious section mismatch warningRakib Mullick1-1/+6
Fix spurious section mismatch warnings, caused due to reference from variable sht_drivers to __devinit/__devexit functions sht15_probe()/remove(). We were warned by the following warnings: LD drivers/hwmon/built-in.o WARNING: drivers/hwmon/built-in.o(.data+0x264a0): Section mismatch in reference from the variable sht_drivers to the function .devinit.text:sht15_probe() The variable sht_drivers references the function __devinit sht15_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/hwmon/built-in.o(.data+0x264a4): Section mismatch in reference from the variable sht_drivers to the function .devexit.text:sht15_remove() The variable sht_drivers references the function __devexit sht15_remove() If the reference is valid then annotate the variable with __exit* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/hwmon/built-in.o(.data+0x264f0): Section mismatch in reference from the variable sht_drivers to the function .devinit.text:sht15_probe() The variable sht_drivers references the function __devinit sht15_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/hwmon/built-in.o(.data+0x264f4): Section mismatch in reference from the variable sht_drivers to the function .devexit.text:sht15_remove() The variable sht_drivers references the function __devexit sht15_remove() If the reference is valid then annotate the variable with __exit* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/hwmon/built-in.o(.data+0x26540): Section mismatch in reference from the variable sht_drivers to the function .devinit.text:sht15_probe() The variable sht_drivers references the function __devinit sht15_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/hwmon/built-in.o(.data+0x26544): Section mismatch in reference from the variable sht_drivers to the function .devexit.text:sht15_remove() The variable sht_drivers references the function __devexit sht15_remove() If the reference is valid then annotate the variable with __exit* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/hwmon/built-in.o(.data+0x26590): Section mismatch in reference from the variable sht_drivers to the function .devinit.text:sht15_probe() The variable sht_drivers references the function __devinit sht15_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com> Cc: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2009-09-22hwmon: fix freeing of gpio_data and irqRoel Kluin1-2/+4
If already requested, gpio_data and irq should be freed in the case of an error. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-07-11hwmon: (sht15) Remove unnecessary semicolonJoe Perches1-1/+1
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2009-06-15hwmon: Fix more __devexit_p glitchesJean Delvare1-5/+5
Make sure __devexit and devexit_p() match in all hwmon drivers. Suggested by a similar fix from Mike Frysinger. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
2009-04-13hwmon: sht15 humidity sensor driverJonathan Cameron1-0/+692
Data sheet at: http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf These sensors communicate over a 2 wire bus running a device specific protocol. The complexity of the driver is mainly due to handling the substantial delays between requesting a reading and the device pulling the data line low to indicate that the data is available. This is handled by an interrupt that is disabled under all other conditions. I wasn't terribly clear on the best way to handle this, so comments on that aspect would be particularly welcome! Interpretation of the temperature depends on knowing the supply voltage. If configured in a board config as a regulator consumer this is obtained from the regulator subsystem. If not it should be provided in the platform data. I've placed this driver in the hwmon subsystem as it is definitely a device that may be used for hardware monitoring and with it's relatively slow response times (up to 120 millisecs to get a reading) a caching strategy certainly seems to make sense! Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>