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>
Showing
Please register or sign in to comment