Commit graph

7 commits

Author SHA1 Message Date
Linus Torvalds
4c274fff4f Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging
* '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-11 11:23:33 -07:00
Alexey Dobriyan
d43c36dc6b headers: remove sched.h from interrupt.h
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-11 11:20:58 -07:00
Rakib Mullick
cb0f1a1e77 hwmon: (sht15) Fix spurious section mismatch warning
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-10-09 20:35:17 +02:00
Roel Kluin
560a64a2b5 hwmon: fix freeing of gpio_data and irq
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-09-22 07:17:49 -07:00
Joe Perches
24205e0850 hwmon: (sht15) Remove unnecessary semicolon
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2009-07-11 13:42:37 +02:00
Jean Delvare
cd659fd0d7 hwmon: Fix more __devexit_p glitches
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-06-15 18:39:45 +02:00
Jonathan Cameron
251eb40f5c hwmon: sht15 humidity sensor driver
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>
2009-04-13 15:04:29 -07:00