2018-02-18 08:36:46 +03:00
// SPDX-License-Identifier: GPL-2.0+
2016-07-05 04:54:04 +03:00
/*
* maxim_thermocouple . c - Support for Maxim thermocouple chips
*
2018-02-18 08:36:46 +03:00
* Copyright ( C ) 2016 - 2018 Matt Ranostay
* Author : < matt . ranostay @ konsulko . com >
2016-07-05 04:54:04 +03:00
*/
# include <linux/init.h>
2022-02-02 23:53:28 +03:00
# include <linux/mod_devicetable.h>
# include <linux/module.h>
2016-07-05 04:54:04 +03:00
# include <linux/mutex.h>
# include <linux/err.h>
# include <linux/spi/spi.h>
# include <linux/iio/iio.h>
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
# include <linux/iio/sysfs.h>
2016-07-05 04:54:04 +03:00
# include <linux/iio/trigger.h>
# include <linux/iio/buffer.h>
# include <linux/iio/triggered_buffer.h>
# include <linux/iio/trigger_consumer.h>
# define MAXIM_THERMOCOUPLE_DRV_NAME "maxim_thermocouple"
enum {
MAX6675 ,
MAX31855 ,
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
MAX31855K ,
MAX31855J ,
MAX31855N ,
MAX31855S ,
MAX31855T ,
MAX31855E ,
MAX31855R ,
} ;
static const char maxim_tc_types [ ] = {
' K ' , ' ? ' , ' K ' , ' J ' , ' N ' , ' S ' , ' T ' , ' E ' , ' R '
2016-07-05 04:54:04 +03:00
} ;
2016-08-26 17:33:20 +03:00
static const struct iio_chan_spec max6675_channels [ ] = {
2016-07-05 04:54:04 +03:00
{ /* thermocouple temperature */
. type = IIO_TEMP ,
. info_mask_separate =
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
BIT ( IIO_CHAN_INFO_RAW ) | BIT ( IIO_CHAN_INFO_SCALE ) |
BIT ( IIO_CHAN_INFO_THERMOCOUPLE_TYPE ) ,
2016-07-05 04:54:04 +03:00
. scan_index = 0 ,
. scan_type = {
. sign = ' s ' ,
. realbits = 13 ,
. storagebits = 16 ,
. shift = 3 ,
. endianness = IIO_BE ,
} ,
} ,
IIO_CHAN_SOFT_TIMESTAMP ( 1 ) ,
} ;
2016-08-26 17:33:20 +03:00
static const struct iio_chan_spec max31855_channels [ ] = {
2016-07-05 04:54:04 +03:00
{ /* thermocouple temperature */
. type = IIO_TEMP ,
. address = 2 ,
. info_mask_separate =
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
BIT ( IIO_CHAN_INFO_RAW ) | BIT ( IIO_CHAN_INFO_SCALE ) |
BIT ( IIO_CHAN_INFO_THERMOCOUPLE_TYPE ) ,
2016-07-05 04:54:04 +03:00
. scan_index = 0 ,
. scan_type = {
. sign = ' s ' ,
. realbits = 14 ,
. storagebits = 16 ,
. shift = 2 ,
. endianness = IIO_BE ,
} ,
} ,
{ /* cold junction temperature */
. type = IIO_TEMP ,
. address = 0 ,
. channel2 = IIO_MOD_TEMP_AMBIENT ,
. modified = 1 ,
. info_mask_separate =
BIT ( IIO_CHAN_INFO_RAW ) | BIT ( IIO_CHAN_INFO_SCALE ) ,
. scan_index = 1 ,
. scan_type = {
. sign = ' s ' ,
. realbits = 12 ,
. storagebits = 16 ,
. shift = 4 ,
. endianness = IIO_BE ,
} ,
} ,
IIO_CHAN_SOFT_TIMESTAMP ( 2 ) ,
} ;
static const unsigned long max31855_scan_masks [ ] = { 0x3 , 0 } ;
struct maxim_thermocouple_chip {
const struct iio_chan_spec * channels ;
const unsigned long * scan_masks ;
u8 num_channels ;
u8 read_size ;
/* bit-check for valid input */
u32 status_bit ;
} ;
2016-08-26 17:33:20 +03:00
static const struct maxim_thermocouple_chip maxim_thermocouple_chips [ ] = {
2016-07-05 04:54:04 +03:00
[ MAX6675 ] = {
. channels = max6675_channels ,
. num_channels = ARRAY_SIZE ( max6675_channels ) ,
. read_size = 2 ,
. status_bit = BIT ( 2 ) ,
} ,
[ MAX31855 ] = {
. channels = max31855_channels ,
. num_channels = ARRAY_SIZE ( max31855_channels ) ,
. read_size = 4 ,
. scan_masks = max31855_scan_masks ,
. status_bit = BIT ( 16 ) ,
} ,
} ;
struct maxim_thermocouple_data {
struct spi_device * spi ;
const struct maxim_thermocouple_chip * chip ;
2022-05-08 20:57:12 +03:00
u8 buffer [ 16 ] __aligned ( IIO_DMA_MINALIGN ) ;
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
char tc_type ;
2016-07-05 04:54:04 +03:00
} ;
static int maxim_thermocouple_read ( struct maxim_thermocouple_data * data ,
struct iio_chan_spec const * chan , int * val )
{
unsigned int storage_bytes = data - > chip - > read_size ;
unsigned int shift = chan - > scan_type . shift + ( chan - > address * 8 ) ;
2016-09-28 19:16:51 +03:00
__be16 buf16 ;
__be32 buf32 ;
2016-07-05 04:54:04 +03:00
int ret ;
switch ( storage_bytes ) {
case 2 :
2016-09-28 19:16:51 +03:00
ret = spi_read ( data - > spi , ( void * ) & buf16 , storage_bytes ) ;
* val = be16_to_cpu ( buf16 ) ;
2016-07-05 04:54:04 +03:00
break ;
case 4 :
2016-09-28 19:16:51 +03:00
ret = spi_read ( data - > spi , ( void * ) & buf32 , storage_bytes ) ;
* val = be32_to_cpu ( buf32 ) ;
2016-07-05 04:54:04 +03:00
break ;
2016-10-25 18:55:04 +03:00
default :
ret = - EINVAL ;
2016-07-05 04:54:04 +03:00
}
2016-09-28 19:16:51 +03:00
if ( ret )
return ret ;
2016-07-05 04:54:04 +03:00
/* check to be sure this is a valid reading */
if ( * val & data - > chip - > status_bit )
return - EINVAL ;
* val = sign_extend32 ( * val > > shift , chan - > scan_type . realbits - 1 ) ;
return 0 ;
}
static irqreturn_t maxim_thermocouple_trigger_handler ( int irq , void * private )
{
struct iio_poll_func * pf = private ;
struct iio_dev * indio_dev = pf - > indio_dev ;
struct maxim_thermocouple_data * data = iio_priv ( indio_dev ) ;
int ret ;
ret = spi_read ( data - > spi , data - > buffer , data - > chip - > read_size ) ;
if ( ! ret ) {
iio_push_to_buffers_with_timestamp ( indio_dev , data - > buffer ,
iio_get_time_ns ( indio_dev ) ) ;
}
iio_trigger_notify_done ( indio_dev - > trig ) ;
return IRQ_HANDLED ;
}
static int maxim_thermocouple_read_raw ( struct iio_dev * indio_dev ,
struct iio_chan_spec const * chan ,
int * val , int * val2 , long mask )
{
struct maxim_thermocouple_data * data = iio_priv ( indio_dev ) ;
int ret = - EINVAL ;
switch ( mask ) {
case IIO_CHAN_INFO_RAW :
ret = iio_device_claim_direct_mode ( indio_dev ) ;
if ( ret )
return ret ;
ret = maxim_thermocouple_read ( data , chan , val ) ;
iio_device_release_direct_mode ( indio_dev ) ;
if ( ! ret )
return IIO_VAL_INT ;
break ;
case IIO_CHAN_INFO_SCALE :
switch ( chan - > channel2 ) {
case IIO_MOD_TEMP_AMBIENT :
* val = 62 ;
* val2 = 500000 ; /* 1000 * 0.0625 */
ret = IIO_VAL_INT_PLUS_MICRO ;
break ;
default :
* val = 250 ; /* 1000 * 0.25 */
ret = IIO_VAL_INT ;
2019-10-13 21:10:13 +03:00
}
2016-07-05 04:54:04 +03:00
break ;
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
case IIO_CHAN_INFO_THERMOCOUPLE_TYPE :
* val = data - > tc_type ;
ret = IIO_VAL_CHAR ;
break ;
2016-07-05 04:54:04 +03:00
}
return ret ;
}
static const struct iio_info maxim_thermocouple_info = {
. read_raw = maxim_thermocouple_read_raw ,
} ;
static int maxim_thermocouple_probe ( struct spi_device * spi )
{
const struct spi_device_id * id = spi_get_device_id ( spi ) ;
struct iio_dev * indio_dev ;
struct maxim_thermocouple_data * data ;
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
const int chip_type = ( id - > driver_data = = MAX6675 ) ? MAX6675 : MAX31855 ;
2016-07-05 04:54:04 +03:00
const struct maxim_thermocouple_chip * chip =
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
& maxim_thermocouple_chips [ chip_type ] ;
2016-07-05 04:54:04 +03:00
int ret ;
indio_dev = devm_iio_device_alloc ( & spi - > dev , sizeof ( * data ) ) ;
if ( ! indio_dev )
return - ENOMEM ;
indio_dev - > info = & maxim_thermocouple_info ;
indio_dev - > name = MAXIM_THERMOCOUPLE_DRV_NAME ;
indio_dev - > channels = chip - > channels ;
indio_dev - > available_scan_masks = chip - > scan_masks ;
indio_dev - > num_channels = chip - > num_channels ;
indio_dev - > modes = INDIO_DIRECT_MODE ;
data = iio_priv ( indio_dev ) ;
data - > spi = spi ;
data - > chip = chip ;
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
data - > tc_type = maxim_tc_types [ id - > driver_data ] ;
2016-07-05 04:54:04 +03:00
2019-07-26 13:49:50 +03:00
ret = devm_iio_triggered_buffer_setup ( & spi - > dev ,
indio_dev , NULL ,
2016-07-05 04:54:04 +03:00
maxim_thermocouple_trigger_handler , NULL ) ;
if ( ret )
return ret ;
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
if ( id - > driver_data = = MAX31855 )
dev_warn ( & spi - > dev , " generic max31855 ID is deprecated \n please use more specific part type " ) ;
2019-07-26 13:49:50 +03:00
return devm_iio_device_register ( & spi - > dev , indio_dev ) ;
2016-07-05 04:54:04 +03:00
}
static const struct spi_device_id maxim_thermocouple_id [ ] = {
{ " max6675 " , MAX6675 } ,
{ " max31855 " , MAX31855 } ,
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
{ " max31855k " , MAX31855K } ,
{ " max31855j " , MAX31855J } ,
{ " max31855n " , MAX31855N } ,
{ " max31855s " , MAX31855S } ,
{ " max31855t " , MAX31855T } ,
{ " max31855e " , MAX31855E } ,
{ " max31855r " , MAX31855R } ,
2016-07-05 04:54:04 +03:00
{ } ,
} ;
MODULE_DEVICE_TABLE ( spi , maxim_thermocouple_id ) ;
2019-04-24 00:42:18 +03:00
static const struct of_device_id maxim_thermocouple_of_match [ ] = {
{ . compatible = " maxim,max6675 " } ,
{ . compatible = " maxim,max31855 " } ,
iio: maxim_thermocouple: add thermocouple_type sysfs attribute
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-20 17:47:55 +03:00
{ . compatible = " maxim,max31855k " } ,
{ . compatible = " maxim,max31855j " } ,
{ . compatible = " maxim,max31855n " } ,
{ . compatible = " maxim,max31855s " } ,
{ . compatible = " maxim,max31855t " } ,
{ . compatible = " maxim,max31855e " } ,
{ . compatible = " maxim,max31855r " } ,
2019-04-24 00:42:18 +03:00
{ } ,
} ;
MODULE_DEVICE_TABLE ( of , maxim_thermocouple_of_match ) ;
2016-07-05 04:54:04 +03:00
static struct spi_driver maxim_thermocouple_driver = {
. driver = {
. name = MAXIM_THERMOCOUPLE_DRV_NAME ,
2019-04-24 00:42:18 +03:00
. of_match_table = maxim_thermocouple_of_match ,
2016-07-05 04:54:04 +03:00
} ,
. probe = maxim_thermocouple_probe ,
. id_table = maxim_thermocouple_id ,
} ;
module_spi_driver ( maxim_thermocouple_driver ) ;
2018-02-18 08:36:46 +03:00
MODULE_AUTHOR ( " Matt Ranostay <matt.ranostay@konsulko.com> " ) ;
2016-07-05 04:54:04 +03:00
MODULE_DESCRIPTION ( " Maxim thermocouple sensors " ) ;
MODULE_LICENSE ( " GPL " ) ;