- 12 10月, 2009 1 次提交
-
-
由 Alexey Dobriyan 提交于
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: NAlexey Dobriyan <adobriyan@gmail.com>
-
- 22 9月, 2009 1 次提交
-
-
由 Roel Kluin 提交于
If already requested, gpio_data and irq should be freed in the case of an error. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Acked-by: NJonathan Cameron <jic23@cam.ac.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 11 7月, 2009 1 次提交
-
-
由 Joe Perches 提交于
Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
- 16 6月, 2009 1 次提交
-
-
由 Jean Delvare 提交于
Make sure __devexit and devexit_p() match in all hwmon drivers. Suggested by a similar fix from Mike Frysinger. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
-
- 14 4月, 2009 1 次提交
-
-
由 Jonathan Cameron 提交于
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: NJonathan Cameron <jic23@cam.ac.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-