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: Andrea Merello <andrea.merello@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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>

The sensor support various thermocouple types (e.g. J, K, N, ...). The
driver allows to configure this parameter using a DT property.

This is useful when i.e. the thermocouple is physically tied to the sensor
and it is usually not removed, or when it is at least known in advance
which sensor will be connected to the circuit.

However, if the user can randomly connect any kind of thermocouples (i.e.
the device exposes a connector, and the user is free to connect its own
sensors), it would be more appropriate to provide a mechanism to
dynamically switch from one thermocouple type to another. This can be i.e.
handled in userspace by a GUI, a configuration file or a program that
detects the thermocouple type by reading a GPIO, or a eeprom on the probe,
or whatever.

This patch adds a IIO attribute that can be used to override, at run-time,
the DT-provided setting (which serves as default).

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
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

IIO core layer gained a new sysfs standard attribute "thermocouple_type".
This patch adds it to the list of documented ABI for sysfs-bus-iio

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
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

We have a couple of thermocouple IIO drivers, supporting several chips.
Some of them support only one specific thermocouple type (e.g. "K", "J"),
one of them can be configured to work with several different thermocouple
types.

In certain applications thermocouples could be externally connected to the
chip by the user.

This patch introduces a new IIO standard attribute to report the supported
thermocouple type and, where applicable, to allow it to be dynamically set
using sysfs.

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
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This patch introduces IIO_VAL_CHAR type for standard IIO attributes to
allow for attributes that needs to be represented by character rather
than a number. This is preparatory for introducing a new attribute whose
purpose is to describe thermocouple type, that can be i.e. "J", "K", etc..

The char-type value is stored in the first "value" integer that is passed
to the .[read/write]_raw() callbacks.

Note that in order to make it possible for the IIO core to correctly parse
this type (actually, to avoid integer parsing), it became mandatory for
any driver that wish to use IIO_VAL_CHAR on a writable attribute to
implement .write_raw_get_fmt().

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
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This sensor can perform samples averaging in hardware, but currently the
driver leaves this setting alone (default is no averaging).

This patch binds this HW setting to the "oversampling_ratio" IIO attribute
and allows the user to set the averaging as desired (the HW supports
averaging of 2, 5, 8 or 16 samples; in-between values are rounded up).

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
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

max31856 IIO driver introduced a new attribute
"in_temp_filter_notch_center_frequency".
This patch adds it to the list of documented ABI for sysfs-bus-iio

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
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This sensor has an embedded notch filter for reducing interferences caused
by the power mains. This filter can be tuned to reject either 50Hz or 60Hz
(and harmonics).

Currently the said setting is left alone (the sensor defaults to 60Hz).
This patch introduces a IIO attribute that allows the user to set the said
filter to the desired frequency.

NOTE: this has been intentionally not tied to any DT property to allow
the configuration of this setting from userspace, e.g. with a GUI or by
reading a configuration file, or maybe reading a GPIO tied to a physical
switch or accessing some device that can autodetect the line frequency.

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
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This change uses the ADIS library's state_lock to protect the state of the
`max_speed_hz` change that is done during the set of the sampling
frequency.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

It's the only operation that does 2 operations (a read & a write), so the
unlocked functions can be used under a single state lock.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This replaces indio_dev's mlock with the state lock/mutex from the ADIS
library.

The __adis16136_get_freq() function has been prefixed to mark it as
unlocked. The adis16136_{set,get}_filter() functions now hold the state
lock for all the ops that they do.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This change removes the use of indio_dev's mlock in favor using the state
lock from the ADIS library.

The set_freq() & get_freq() hooks are unlocked, so they require specific
locking. That is because in some cases the get_freq() hook is used in
combination with adis16400_set_filter().

In cases where only one read/write is done, the functions that hold the
state lock are used.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The single conversion function does a series of reads + writes. This change
extends the use of the state_lock for the entire set of operations.
Previously, indio_dev's mlock was used. This change also removes the use of
this lock.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The initial startup routine is called by some ADIS drivers during probe,
and before registering with IIO. Normally, userspace should not be able to
do any access to the device (as there shouldn't be any available).

This change extends the state lock to the entire initial-startup routine.
Behaviourally nothing should change, but this should make the library
function a bit more robust.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The reset routine may also be important to be protected by the state-lock
and grouped with other operations, so create an unlocked version, so that
this can be done.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This one also gets re-used in certain operations, so it makes sense to
have an unlocked version of this to group it with other
reads/writes/operations to have a single lock for the whole state change.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The adis_enable_irq() does a read & a write. This change keeps a lock for
the duration of both operations vs for each op.

The change is also needed in adis16480, since that has it's own
implementation for adis_enable_irq().
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This will allow more flexible control to group reads & writes into a single
lock (particularly the state_lock).

The end-goal is to remove the indio_dev->mlock usage, and the simplest fix
would have been to just add another lock, which would not be a good idea on
the long-run.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The lock can be extended a bit to protect other elements that are not
particular to just TX/RX. Another idea would have been to just add a new
`state_lock`, but that would mean 2 locks which would be redundant, and
probably cause more potential for dead-locks.

What will be done in the next patches, will be to add some unlocked
versions for read/write_reg functions.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The relations between enum values and array indices values are currently
not enforced by the code, which makes them fragile w.r.t. future
changes.

Fix this by:
  1. Using designated array initializers, to make sure array indices and
     enums values match,
  2. Linking max9611_csa_gain enum values to the corresponding
     max9611_conf_ids enum values, as the latter is cast to the former
     in max9611_read_csa_voltage().

No change in generated code.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Add support for driving MPU9150 magnetometer (AK8975) from mpu.
Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

MPU9150 is i2c only.
Update Kconfig to delete in description chips that are i2c or
spi only.
Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Add Beniamin Bia as a maintainer for AD7091R5 ADC.
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Documentation for AD7091R5 ADC was added.
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The scale can now be obtained with the "in_voltage_scale" file.
By default, the scale returned corresponds to the internal VREF of 2.5V.

It is possible to use an external VREF (through the REFIN/REFOUT pin of
the chip), by passing a regulator to the driver. The scale will then be
calculated according to the voltage reported by the regulator.
Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Co-developed-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

AD7091R5 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC.

This driver will also support AD7091R2/4/8 in the future.

Datasheet:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdfSigned-off-by: Paul Cercueil <paul.cercueil@analog.com>
Co-developed-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dma_request_slave_channel_reason() is:
	dma_request_chan(dev, name)
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reducing the indentation level helps a bit with
the readability of this function. There's also a checkpatch
fix here, moving the first argument to kthread_create() onto
the same line, as well as a relocation of the statement
"char threadname[16];" to the top of the function to avoid
a declaration in the middle of code.
Signed-off-by: Marcelo Diop-Gonzalez <marcgonzalez@google.com>
Link: https://lore.kernel.org/r/20191114232801.71458-1-marcgonzalez@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a spelling mistake in a kernel info message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20191114221509.10728-1-colin.king@canonical.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix sparse warnings:

drivers/staging/exfat/exfat_core.c:2045:4: warning: symbol 'calc_checksum_1byte' was not declared. Should it be static?
drivers/staging/exfat/exfat_core.c:2080:5: warning: symbol 'calc_checksum_4byte' was not declared. Should it be static?

The two functions has no caller in tree, so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20191114140348.46088-1-yuehaibing@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a block of statements that are indented
too deeply, remove the extraneous tabs.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20191114095747.132407-1-colin.king@canonical.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a block of statements that are indented
too deeply, remove the extraneous tabs.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20191114095430.132120-1-colin.king@canonical.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some versions of SoC MT7621 have three PCI express hosts. Some boards
make use of those PCI through the staging driver mt7621-pci. Recently
PCI support has been removed from MT7621 Soc kernel configuration due
to a build error. This makes imposible to compile staging driver and
produces a regression for gnubee based boards. Enable support for PCI
again but enable it only if staging mt7621-pci driver is selected.

Fixes: c4d48cf5 ("MIPS: ralink: deactivate PCI support for SOC_MT7621")
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: ralf@linux-mips.org
Cc: jhogan@kernel.org
Cc: john@phrozen.org
Cc: NeilBrown <neil@brown.name>
Cc: linux-mips@vger.kernel.org
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20191019081233.7337-1-sergio.paracuellos@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Align to fix multiple warnings of line over 80 characters.
Issue detected by checkpatch tool.
Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Link: https://lore.kernel.org/r/20191113110052.14855-1-jbi.octave@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a declaration that requires indentation. Add in
the missing tab.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20191113164210.103586-1-colin.king@canonical.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'iio-for-5.5c' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next

Jonathan writes:

Third set of IIO new device support cleanups and fixes for the 5.5 cycle.

New device support
* ad5446
  - Support the ad5600 DAC (id only needed).
* ad7292 ADC DAC etc
  - New driver plus dt-bindings.
* veml6030 ambient light sensor
  - New driver plus dt-bindings and sysfs docs.

Features
* mpu6050
  - Explicit VDD control.
* stm32-adc
  - Allow limiting of max clock frequency from devicetree to ensure it's
    suitable for external circuitry.

yaml binding conversions
* ltc1660
* mcp3911

Fixes
* adis16480
  - Fix wrong scale factors.
  - Fix debugfs reg access by providing the callback.
* cros_ec_baro
  - Fixing missing mask entry to make available sample frequencies visible
    in sysfs.
* st_lsm6dsx
  - Explicitly handle different ODR table sizes.
  - Handle restrictions between slave ODR and accel ODR when
    both are enabled.
  - Allow ODR to be expressed more accurately by using miliHz.
* tools
  - Fix an issue with parallel builds.

Cleanups and warning fixes
* adis16136, adis16400, adis16460, adis-lib
  - Change some checks on return values to be for 0 rather than strictly
    negative. Avoids some fiddly issues with the compiler concluding some
    variables are initialized due to a mixture of error checks.
  - Assign values only on success of 'read' operations - avoiding any
    chance the compiler will falsly suggest they might be used uninitialized.
  - Whitespace and simlar cleanups.
* aspeed adc
  - devm_platfom_ioremap_resource to reduce boilerplate.
* bcm-iproc-adc
  - Stray semicolon removal.
* cc10001
  - devm_platfom_ioremap_resource to reduce boilerplate.
* dln2-adc
  - Reorganise the buffered mode setup and tear down. Part of moving towards
    being able to refactor this area of the IIO core.
* hdc100x
  - Reorganise the buffered mode setup and tear down.
* ingenic-adc
  - devm_platfom_ioremap_resource to reduce boilerplate.
* lpc18xx-adc
  - devm_platfom_ioremap_resource to reduce boilerplate.
* lpc18xx-dac
  - devm_platfom_ioremap_resource to reduce boilerplate.
* mt6577
  - devm_platfom_ioremap_resource to reduce boilerplate.
* npcm
  - devm_platfom_ioremap_resource to reduce boilerplate.
* rcar-gyroadc
  - devm_platfom_ioremap_resource to reduce boilerplate.
* spear-adc
  - devm_platfom_ioremap_resource to reduce boilerplate.
* vf610-adc
  - devm_platfom_ioremap_resource to reduce boilerplate.
* vf610-dac
  - devm_platfom_ioremap_resource to reduce boilerplate.

* tag 'iio-for-5.5c' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (43 commits)
  iio: adis16480: Add debugfs_reg_access entry
  iio: adis16480: Fix scales factors
  tools: iio: Correctly add make dependency for iio_utils
  iio: adc: Add driver support for AD7292
  dt-bindings: iio: adc: Add dt-schema for AD7292
  dt-bindings: iio: adc: Migrate MCP3911 documentation to yaml
  iio: imu: mpu6050: Add support for vdd-supply regulator
  dt-bindings: iio: imu: mpu6050: add vdd-supply
  iio: cros_ec_baro: set info_mask_shared_by_all_available field
  iio: dac: ad5446: Add support for new AD5600 DAC
  dt-bindings: iio: dac: Migrate LTC1660 documentation to yaml
  iio: documentation: light: Add veml6030 sysfs documentation
  dt-bindings: iio: light: add veml6030 ALS bindings
  iio: light: add driver for veml6030 ambient light sensor
  iio: imu: st_lsm6dsx: express odr in mHZ
  iio: imu: st_lsm6dsx: fix ODR check in st_lsm6dsx_write_raw
  iio: imu: st_lsm6dsx: explicitly define odr table size
  iio: adc: stm32: allow to tune analog clock
  dt-bindings: iio: stm32-adc: add max clock rate property
  iio: dac: vf610: Use devm_platform_ioremap_resource
  ...

Updating with the current laundry list of things that need attention.
Signed-off-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Link: https://lore.kernel.org/r/20191112223609.163501-1-Valdis.Kletnieks@vt.eduSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Rename all the FAT_* functions to exfat_fat_*.
Signed-off-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Link: https://lore.kernel.org/r/20191112211238.156490-13-Valdis.Kletnieks@vt.eduSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Global functions called 'buf*' are a linkage editor disaster waiting to
happen.  Rename our buf_* functions to exfat_buf_*
Signed-off-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Link: https://lore.kernel.org/r/20191112211238.156490-12-Valdis.Kletnieks@vt.eduSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>