We have #defines for all the individual sensor registers and
value/mask pairs #defined at the top of the file and used at
exactly one spot.

This is usually good if the #defines give a meaning to the
opaque magic numbers.

However in this case, the semantic meaning is inherent in the
name of the C99-addressable fields, and that means duplication
of information, and only makes the code hard to maintain since
you every time have to add a new #define AND update the site
where it is to be used.

Get rid of the #defines and just open code the values into the
appropriate struct elements. Make sure to explicitly address
the .hz and .value fields in the st_sensor_odr_avl struct
so that the meaning of all values is clear.

This patch is purely syntactic should have no semantic effect.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Jonathan writes:

First round of IIO new device support, features and cleanups for the 4.10 cycle.

Fair number of outreachy related patches in here. Some of these may well
have already been picked up by Greg but git will sort that out for us.

Also some good staging cleanup work from other sources. Thanks Brian and Lars
in particular for this.

New device support
* ACCES 104-quad-8
  - New driver for this 8 channel encoder input board. Lots of new ABI with
    this one.
* AD7766
  - New driver supporting AD7766, AD7766-1, AD7766-2, AD7767, AD7767-1 and
    AD7767-2 24 bit ADCs.
* dmard 10
  - New driver for this 3 axis accelerometer.
* Honeywell ABP pressure sensors.
  - New driver covering 56 parts in this series (too many to list here!)
* HTS221
  - New driver to support this relative humidiy and temperature device.
* LMP91000
  - New driver for this potentiostat (form of chemical sensor). Nice example
    of use of the buffered consumer interfaces and the use of a consumer
    provided trigger.
* MiraMEMS DA311
  - New driver for this 3 axis accelerometer.
* MiraMEMS DA280
  - New driver for this 3 axis accelerometer. Follow up caught up with
  vendor prefixes for these.

Staging graduations
* isl29018 light sensor
  - Fixes and cleanups listed below (thanks for your hard work on this Brian!)
* sca3000
  - Fixes and cleanups listed below.  This was one of the small set of drivers
  that went into staging when IIO was first added.  Turns out it had a few
  bugs and needed to be brought into the modern era!  Not clear if I am
  the only person who actually has one of these still wired to a board.

New features (Core)
 - Add an iio_trigger_validate_own_device helper which relies on the device
   and trigger having the same parent.  Convenient to have this for some
   of the more complex trigger / device interactions. Was hand rolled in
   a few drivers already so good to bring it into the core.
 - Add an iio_read_channel_offset in kernel access helper (similar to
   the existing one for scale).
 - IIO_ATTR_{RO, WO, RW} and IIO_DEVICE_ATTR_{RO, WO, RW} macros.  These
   lead some rather contrived function naming, but there is no denying they
   do reduced boilerplate.  I'm going to resist their introduction in
   drivers 'unless' they form part of a larger set of cleanups.
 - Counter channel type and index type.

New features (Drivers)
* hdc100x
  - Triggered buffer support.
* mcp4725
  - Device tree bindings and support.
  - Voltage reference selection.
* ti-adc0832
  - Triggered buffer support.
* ti-adc161s626
  - Add regulator support allowing _scale and _offset values to be established
  and exported.

New features (Tools)
* iio_generic_buffer
  - -A option to force enable all channels rather than faulting if some are
  already enabled (like -a does).  Followup patches tidied this support up.

Cleanups (Core)
 - Use kmalloc_array in iio_scan_mask_set.
 - Take event_attrs field of iio_info structure constant
 - Staging todo list updates. Most of it was long done.
 - MAINTAINERS had a wrong directory listing.

Cleanups (Drivers)
* Missing i2c trivial devices entries.
* ad5592r
  - Fix an endian type related sparse warnings.
* ad7150
  - Constify the event attribute_group structures.
* ad7152
  - Add some blank lines to improve readability.
  - Sampling frequency control via chan-info element rather than hand rolled
  attributes.
  - add a new lock to avoid use of mlock for non state change related locking.
* ad7280
  - Constify atrribute_group structure (second patch covers the event ones)
* ad7606 (Lars is driving most of the cleanup on this with some additions from
  Eva)
  - Fix improper setting of oversampling pins.  This has been broken a very
  long time in this staging driver, so not going to push this back to stable.
  - Implement oversampling configuration via the chan_info mask element.
  - Remove an unused int_vref_mv field.
  - Remove a reundant name field from ad7606_chip_info.
  - Remove default device configuration from platform_data in favour of
  whatever the power on defaults are.
  - Remove out of band error reporting in the kernel log as not providing
  much information.
  - Fix oversampling ratio by having 1 be the value for no oversampling.
  - Avoid allocating buffer for each data capture.
  - Factor out common code between periodic and one-shot capture.
  - Move set_drvdat into common code.
  - Let the common probe function return int rather than jumping through
  an ERR_PTR.
  - Pass struct device * into common remove to simplify code.
  - Always run trigger handler only once per event (no one can remember why
  it was being possibly done twice).
  - Move over to the GPIO descriptor API to shorten and clarify code.
  - Move the buffer code into the main file as it's not optional and is
  now rather short in this driver.
  - Fix the naming of the supply regulator.
  - Rework regulator handling to handle errors including deferred probing.
  - Tidy up a ptr_err or 0 return.
* ad7746
  - Sampling frequency control via info_mask element rather than hand rolled
* ad7758
  - Sampling frequency control via info_mask element rather than hand rolled
  attributes.
* ad7816
  - Constify the event attribute_group structure.
* adt7316
  - Constify the event attribute group structures.
* ak8974
  - Cleanup some sparse warnings about endian types.
* ak8975
  - Cleanup some sparse warnings about endian types.
* bmi160
  - Spare endian warning cleanups.
* isl29018 (towards staging graduation)
  - Remove unusedvariables and defines.
  - Improve consistency of error handling.
  - Signed / unsigned comparison fixes.
  - Use the IIO_DEVICE_ATTR_{RO, RW} macros
  - Fix a race in in_illuminance_scale_available_show.
  - Cleanup exit points of _read_raw
  - Sanity check if in suspended state during a write_raw call as was already
    done for read_raw.
  - Document device tree bidnings.
  - Document infrared supression controls.
  - Add some newlines to improve readability and drop one that shouldn't be
    there.
  - Fix a poorly named functions name.
  - Fix multiline coment syntax.
  - Tidy up a pair or return statements by unifying them.
  - Rename description in Kconfig for consistency with similar drivers.
* lidar
  - cleanup power management by dropping unnecessary call.
* ltr501
  - Use the claim_direct_mode helpers. Fix a race condition along the way.
* max1027
  - Fix a dubious x | !y sparse warning.
  - Use the new iio_trigger_validate_own_device helper.
* max440000
  - Clean up some sparse warnings about endian types.
* mcp4725
  - Use the regulator framework to establish the reference voltage rather than
    getting it from platform data.
  - Tidy up a comment typo.
  - Fix a wrong PTR_ERR query (wrong regulator).
* mma7660
  - Take a mma7660_nscale static.
* mma8452
  - Use the new iio_trigger_validate_own_device helper.
  - Use claim_direct_mode helpers - fix a race condition along the way.
* mpl3115
  - Use claim_direct_mode helpers - fix a race condition along the way.
* ms65611
  - Tidy up regulator error handling and clean out a static warning in the mix.
* sca3000
  - Avoid a potential unitialized variable if a hardware read returns a value
  that isn't actually supported (mostly warning supression).
  - Fix a use before setting of the indio_dev->buffer pointer. Broken for
  a very long time so not going to rush this into stable.
  - Merge buffer file with core file.  We used to always split these.
  Sometimes it's just not worth the hassle. In this case the device's main
  feature is it's hardware fifos so unlikely anyone would want to run it
  without.
  - Drop the sca3000_register_ring_funcs function as it's a pointless wrapper
  once we have only one file.
  - Fix cleaning of flag + setting of size of scan. Without this you can't
  start the buffer twice and expect sensible (or any) results.  Again,
  broken for a long time so not heading for stable.
  - Drop the custom watershed setting ABI - for now we'll just support one
  value.
  - Move to a hybrid hard / soft buffer design (how we've been doing it
  for similar devices for a while now!)
  - Cleanup some unusued variables.
  - Use a fake channel to support core handling of freefall event registration.
  - Cleanup the register defines.
  - Fix an off by one error in axis due to IIO_NO_MOD taking up the 0 value.
  Been broken since first admission of IIO to the staging tree.
  - Add readback of the 3db low pass filter frequency and later writing
    allowing droppign of custom measurement mode attributes as they can
    be represented by the filter choices that is their main characteristic.
  - Drop non standard revision attr and replace with dev_info on probe.
  - Avoid a race in probe.
  - Various formatting fixes.
  - Kernel-docify docs that were very nearly in the write format.
* tsl2583
  - Constify attribute_group structure.
* zpa2326
  - Drop a redundant DEBUG ifdef.

Cleanups (Tools)
* iio_generic_buffer
  - Fix the ? arguement. Previously it sort of worked as you got the help
    message as a result of it not recognising the arguement.

Driver was checking for direct mode but not locking it.  Use
claim/release helper functions to guarantee the device stays
in direct mode during raw reads.

Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Change in handling of the regulator description means that static
checkers correctly assume we could be using dereferenced pointer to the
regulator. In reality we will never get the -ENODEV error, as current
behavior flow does not predict it, because:
If the device tree or board file does not define suitable regulators for
the component, it will be substituted by a dummy regulator, or, if
regulators are disabled altogether, by stubs.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Suggested-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Crt Mori <cmo@melexis.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Pull staging and IIO updates from Greg KH:
 "Here is the big staging and IIO driver pull request for 4.9-rc1.

  There are a lot of patches in here, the majority due to the
  drivers/staging/greybus/ subsystem being merged in with full
  development history that went back a few years, in order to preserve
  the work that those developers did over time.

  Lots and lots of tiny cleanups happened in the tree as well, due to
  the Outreachy application process and lots of other developers showing
  up for the first time to clean code up.  Along with those changes, we
  deleted a wireless driver, and added a raspberrypi driver (currently
  marked broken), and lots of new iio drivers.

  Overall the tree still shrunk with more lines removed than added,
  about 10 thousand lines removed in total. Full details are in the very
  long shortlog below.

  All of this has been in the linux-next tree with no issues. There will
  be some merge problems with other subsystem trees, but those are all
  minor problems and shouldn't be hard to work out when they happen
  (MAINTAINERS and some lustre build problems with the IB tree)"

And furter from me asking for clarification about greybus:
 "Right now there is a phone from Motorola shipping with this code (a
  slightly older version, but the same tree), so even though Ara is not
  alive in the same form, the functionality is happening. We are working
  with the developers of that phone to merge the newer stuff in with
  their fork so they can use the upstream version in future versions of
  their phone product line.

  Toshiba has at least one chip shipping in their catalog that
  needs/uses this protocol over a Unipro link, and rumor has it that
  there might be more in the future.

  There are also other users of the greybus protocols, there is a talk
  next week at ELC that shows how it is being used across a network
  connection to control a device, and previous ELC talks have showed the
  protocol stack being used over USB to drive embedded Linux boards.
  I've also talked to some people who are starting to work to add a host
  controller driver to control arduinos as the greybus PHY protocols are
  very useful to control a serial/i2c/spio/whatever device across a
  random physical link, as it is a way to have a self-describing device
  be attached to a host without needing manual configuration.

  So yes, people are using it, and there is still the chance that it
  will show up in a phone/laptop/tablet/whatever from Google in the
  future as well, the tech isn't dead, even if the original large phone
  project happens to be"

* tag 'staging-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (3703 commits)
  Staging: fbtft: Fix bug in fbtft-core
  staging: rtl8188eu: fix double unlock error in rtw_resume_process()
  staging:r8188eu: remove GEN_MLME_EXT_HANDLER macro
  staging:r8188eu: remove GEN_DRV_CMD_HANDLER macro
  staging:r8188eu: remove GEN_EVT_CODE macro
  staging:r8188eu: remove GEN_CMD_CODE macro
  staging:r8188eu: remove pkt_newalloc member of the recv_buf structure
  staging:r8188eu: remove rtw_handle_dualmac declaration
  staging:r8188eu: remove (RGTRY|BSSID)_(OFT|SZ) macros
  staging:r8188eu: change rtl8188e_process_phy_info function argument type
  Staging: fsl-mc: Remove blank lines
  Staging: fsl-mc: Fix unaligned * in block comments
  Staging: comedi: Align the * in block comments
  Staging : ks7010 : Fix block comments warninig
  Staging: vt6655: Remove explicit NULL comparison using Coccinelle
  staging: rtl8188eu: core: rtw_xmit: Use macros instead of constants
  staging: rtl8188eu: core: rtw_xmit: Move constant of the right side
  staging: dgnc: Fix lines longer than 80 characters
  Staging: dgnc: constify attribute_group structures
  Staging: most: hdm-dim2: constify attribute_group structures
  ...

This patch adds minimal driver for the Honeywell Amplified Basic
Pressure sensors series. Sensors are pretty simple but are
available in many variants:
- psi/mbar/kPa output,
- analog/i2c/spi,
- gage/differential measurement,
- different measure ranges etc.

Refer to datasheets for more details:
http://sensing.honeywell.com/honeywell-sensing-basic-board-mount-pressure-sensors-abp-series-datasheet-323005128-c-en.pdf
http://sensing.honeywell.com/index.php%3Fci_id%3D45841

Driver internals:
- i2c only. measure request is done by the SMBUS QUICK cmd, so if the i2c
  bus doesn't support it, it is required to send a dummy byte to trigger
  measurement,
- since iio sysfs expects kilopascals, mbar-variants are treated as their
  respective kPa-s, hence i2c id-table has doubled entries in one line:
	{ "abp060mg", ABP006KG }, { "abp006kg", ABP006KG },
- psi-variants have prescaled values in config,
- no temperature reads yet.

Work remained:
- optional temperature channel,
- SPI support,
- DT binding.

Changes since v1:
- mutex is now locked in read_raw(),
- corrected error codes,
- fixed coding style issues,
- renamed few defines and functions abp -> abp060mg
(some structs left as they were to keep the sensible meaning).

Signed-off-by: Marcin Malagowski <mrc@bourne.st>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

The -Wempty-body gcc warning triggers in the newly added zpa2326 driver:

drivers/iio/pressure/zpa2326.c: In function 'zpa2326_dequeue_pressure':
drivers/iio/pressure/zpa2326.c:578:3: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]

The use of an empty statement behind 'if (...)' is harmless here, but
it shows that the dev_dbg() macro is not used correctly: when the "DEBUG"
macro is not set, dev_dbg() already defaults to a no-operation, though
one that lets the compiler know that the arguments are used, and lets
it check the format string.

Fixing this also simplifies the driver.

Fixes: 03b262f2bbf4 ("iio:pressure: initial zpa2326 barometer support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Introduce driver for Murata ZPA2326 pressure and temperature sensor:
http://www.murata.com/en-us/products/productdetail?partno=ZPA2326-0311A-R

Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Jonathan writes:

Second set of iio new device support, features and cleanups for the 4.9 cycle.

New device support
* ad8801 dac
  - new driver supporting ad8801 and ad8803 DACs.
* adc12138
  - new driver supporting TI adc12130/adc12132 and adc12138 ADCs.
* ltc2485 adc
  - new driver
* mxc6255
  - add support for the mxc6225 part name and fixup the ID check so it works.
* vz89x VOC sensor
  - add support for the vz89te part which drops the voc_short channel and adds
    CRCs compared to other supported parts.

New features
* core
  - immutable triggers.  These effectively grant exclusive control over a
    trigger. The typical usecase is a device representing an analog part
    (perhaps a MUX) that needs to control the sampling of a downstream
    ADC.
  - resource managed trigger registration and triggered_buffer_init.
  - iio_push_event now protected against case of the event interface
    registration not having yet occured.  Only matters if an interrupt
    can occur during this window - might happen on shared interrupt lines.
  - helper to let a driver query if the trigger it is using is provided by
    itself (using the convention of both device and trigger having the same
    parent).
* tools
  - iio-utils. Used channel modifier scaling in preference to generic scaling
    when both exist.
* at91-adc
  - Add support for touchscreen switches closure time needed by some newer
    parts.
* stx104
  - support the ADC channels on this ADC/DAC board. As these are the primary
    feature of the board also move the driver to the iio/adc directory.
* sx9500
  - device tree bindings.

Cleanups / Fixes
* ad5755
  - fix an off-by-one on devnr limit check (introduced earlier this cycle)
* ad7266
  - drop NULL check on devm_regulator_get_optional as it can't return NULL.
* ak8974
  - avoid an unused functional warning due to rework in PM core code.
  - remove .owner field setting as done by i2c_core.
* ina2xx
  - clear out a left over debug field from chip global data.
* hid-sensors
  - avoid an unused functional warning due to rework in PM core code.
* maxim-thermocouple
  - fix non static symbol warnings.
* ms5611
  - fetch and enable regulators unconditionally when they aren't optional.
* sca3000
  - whitespace cleanup.
* st_sensors
  - fetch and enable regulators unconditionally rather than having them
    supported as optional regulators (missunderstanding on my part amongst
    others a while back)
  - followup to previous patch fixes error checking on the regulators.
  - mark symbols static where possible.
  - use the 'is it my trigger' help function.  This prevents the odd case
    of another device triggering from the st-sensors trigger whilst the
    st-sensors trigger is itself not using it but rather using say an hrtimer.
* ti-ads1015
  - add missing of_node_put.
* vz89x
  - rework to all support of new devices.
  - prevent reading of a corrupted buffer.
  - fixup a return value of 0/1 in a bool returning function.

Address updates
- Vlad Dogaru email address change.

This patch is inspired by a comment of Jonathan Cameron on patch of
Linus Walleij commit aeb55fff3891834e07a3144159a7298a19696af8 ("iio: st_sensors: fetch and enable regulators unconditionally").

The explanation for this change is same as in that patch:
"Supplies are *not* optional (optional means that the supply is
optional in the electrical sense, not the software sense) so we need to
get the and enable them at all times.

If the device tree or board file does not define suitable regulators for
the component, it will be substituted by a dummy regulator, or, if
regulators are disabled altogether, by stubs. There is no need to use the
IS_ERR_OR_NULL() check that is considered harmful.

Reported-by: Linus Wallerij <linus.walleij@linaro.org>
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Crt Mori <cmo@melexis.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>