1. 29 Dec, 2019 5 commits
  2. 15 Dec, 2019 26 commits
  3. 01 Dec, 2019 4 commits
  4. 23 Nov, 2019 5 commits
    • Andreas Klinger's avatar
      dt-bindings: add parallax ping sensors · b7f35e7d
      Andreas Klinger authored
      Add dt-bindings for parallax PING))) and LaserPING iio sensors, which
      are used for measuring distances.
      Signed-off-by: default avatarAndreas Klinger <ak@it-klinger.de>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      b7f35e7d
    • Andreas Klinger's avatar
      dt-bindings: add vendor prefix parallax · 3e976962
      Andreas Klinger authored
      Add new vendor prefix parallax for newly created ping iio sensors.
      Signed-off-by: default avatarAndreas Klinger <ak@it-klinger.de>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      3e976962
    • Alexandru Tachici's avatar
      iio: dac: ad7303: use regulator get optional to check for ext supply · a8b26c2d
      Alexandru Tachici authored
      Previously, the code was using the of_read_property_bool() to check if
      an external regulator was provided. However, this is redundant, as it's
      more simple/direct to just ask the regulator is provided, via a
      `devm_regulator_get_optional()` call.
      Signed-off-by: default avatarAlexandru Tachici <alexandru.tachici@analog.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      a8b26c2d
    • Andrea Merello's avatar
      dt-bindings: iio: maxim_thermocouple: document new 'compatible' strings · 3922f930
      Andrea Merello authored
      Now the maxim_thermocouple has new, more specific, 'compatible' strings for
      better distinguish the various supported chips.
      
      This patch updates the DT bindings documentation accordingly
      
      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: default avatarAndrea Merello <andrea.merello@gmail.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      3922f930
    • Andrea Merello's avatar
      iio: maxim_thermocouple: add thermocouple_type sysfs attribute · d7f6a749
      Andrea Merello authored
      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: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      d7f6a749