linux.git/drivers/iio/dac, branch v4.14.82

iio: ad5064: Fix regulator handling

2018-11-13T19:15:08+00:00

commit 8911a43bc198877fad9f4b0246a866b26bb547ab upstream.

The correct way to handle errors returned by regualtor_get() and friends is
to propagate the error since that means that an regulator was specified,
but something went wrong when requesting it.

For handling optional regulators, e.g. when the device has an internal
vref, regulator_get_optional() should be used to avoid getting the dummy
regulator that the regulator core otherwise provides.

Signed-off-by: Lars-Peter Clausen 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

2017-11-02T10:10:55+00:00

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart 
Reviewed-by: Philippe Ombredanne 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

iio: dac: stm32-dac-core: explicitly request exclusive reset control

2017-08-20T14:41:18+00:00

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.

No functional changes.

Cc: Jonathan Cameron 
Cc: Hartmut Knaack 
Cc: Lars-Peter Clausen 
Cc: Peter Meerwald-Stadler 
Cc: Maxime Coquelin 
Cc: Alexandre Torgue 
Cc: linux-iio@vger.kernel.org
Signed-off-by: Philipp Zabel 
Signed-off-by: Jonathan Cameron

iio: dac: stm32: add support for stm32f4

2017-07-15T11:26:26+00:00

This adds support for STM32F4 Digital-To-Analog converter.
Add compatible configuration data to handle hfsel (not present
in stm32f4).

Signed-off-by: Fabrice Gasnier 
Signed-off-by: Jonathan Cameron

iio: dac: stm32: fix error message

2017-07-15T11:26:23+00:00

Fix error message, there's no 'st,dac-channel' property, but 'reg'
(see https://lkml.org/lkml/2017/4/3/567).

Signed-off-by: Fabrice Gasnier 
Signed-off-by: Jonathan Cameron

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

2017-05-29T13:53:42+00:00

Jonathan writes:

First set of new device support, features and cleanups for IIO in the 4.13 cycle

Two entirely new drivers in here plus the usual range of cleanups and features.

New device support
* ad5064
  - add ltc2631, ltc2633 and ltc2635 support.
* bma180
  - trivial support for bma250e (new id)
* hid-sensor-rotation
  - add relative orientation and geometric orientation support.
* isl29028
  - add isl29030 support (its effectively the same part from a driver point of
  view)
* maxim_thermocouple
  - add max31856 id.
* meson-saradc
  - add meson8b SoC adc support.
* ti-adc084s021
  - new driver and bindings.
* ti-adc108s102
  - new driver and bindings.

Staging graduations
* isl29028

Features
* bma180
  - ACPI enumeration for BMA250E which is used in various x86 tablets.
* hi8453
  - add raw access rather than only events.
* hid-sensor-hub
  - Implement batch mode in which we can set a threshold on the amount of time
  between data coming from the fifos.  This is the first device to do this
  rather than use a watershed on the number of samples.
* hts221
  - power management support
* lsm6dsx
  - add system power management support.
* rpr0521
  - sampling frequency read / write
* stm32-trigger
  - add support for TRG02 triggers.
* tsl2583
  - runtime power management support.

Cleanups
* core
  - inkern: fix a double unlock in iio_read_available_channel_raw when raw
  value doesn't appear to be raw (error path).
  - fixup accidental sizeof pointer in iio_device_add_mask_type.
* docs
  - fix an accidental duplicated line in sysfs-bus-iio-meas-spec.
* tools
  - use local include/uapi headers to ensure always up to date.
  - increase length of allowed trigger names.
* ad9834
  - symbolic to octal permissions.
* ade7753
  - symbolic to octal permissions.
  - fix indentation
* ade7754
  - symbolic to octal permissions.
* ade7758
  - symbolic to octal permissions.
- ade7854
  - symbolic to octal permissions.
* as3935
  - move out of storm check to given consistent results for raw and processed
  values.
* bmp280
  - fix bme280 naming in Kconfig help.
* hi8435
  - avoid garbage on event after enable.
  - add missing in_voltage_sensing_mode_available to list possible enum options.
  - handle the reset gpio with the obvious polarity rather than relying on
  DT to provide it correctly.
* hid-sensors
  - fix a wrong error path scrubbing of return values.
* hid-sensors-accel
  - drop static on a local variable
* hid-sensors-rotation
  - Add missing scale and offset property parsing support.
* ina2xx
  - Fix a bad use of GENMASK and some typos and whitespace issues.
* isl29018
  - only declare the ACPI table when ACPI is enabled.
* isl29028
  - fix proximity sleep times.
* lsm6dsx
  - replace ifdef CONFIG_PM with __maybe_unused to avoid the complexity of
  dealing with the various PM config variables.
* meson-saradc
  - mark meson_sar_adc_data static and const.
* rcar-gyroadc
  - derive the interface clock speed from the fck clock on the basis they are
  the same actual clock.
  - drop the now unused if clock from the bindings.
* rpr0521
  - disable sensor when marked as such rather than always enabling it.
  - poweroff if probe fails and we can talk to device.
  - make sure device powered off when it doesn't need to be on.
  - use sizeof rather than hardcoded size on value read.
  - whitespace fixup.
  - reorder channel numbers ready for buffered support which didn't quite
  make this pull request.
* st-accel
  - fix platform data initialization to allow remove and reprobe.
* st-pressure
  - fix platform data initialization to allow remove and reprobe.
* tsl2x7x
  - S_IRUGO, S_IWUSR to octal values
  - rename driver for consistency with more recent drivers
  - drop FSF mailing address
  - replace DEVICE_ATTR macros with the shorter DEVICE_ATTR_RW form and
  relevant function renames.
* zpa2326
  - report an error for consistency with other error paths.

iio:ad5064: Add support for ltc2633 and similar devices

2017-05-14T15:16:57+00:00

The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar
to the AD5064 device, in particular the LTC2627.

This patch adds support for those devices. Only the LTC2633 has been
tested, which is the 2-channel variant. The LTC2631 is the 1-channel,
and the LTC2635 the 4-channel version. The actual DAC resolution depends
on the exact chip type and can be 12, 10 or 8 bits, using the upper bits
so this has no effect on the register map. The internal reference is set
to 2.5V on "L" versions, and it's 4.096V for "H" versions.

Datasheets:
    LTC2631: http://www.linear.com/docs/26553
    LTC2633: http://www.linear.com/docs/39529
    LTC2635: http://www.linear.com/docs/28754

Signed-off-by: Mike Looijmans 
Reviewed-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron

Merge tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs

2017-05-11T02:13:03+00:00

Pull hw lockdown support from David Howells:
 "Annotation of module parameters that configure hardware resources
  including ioports, iomem addresses, irq lines and dma channels.

  This allows a future patch to prohibit the use of such module
  parameters to prevent that hardware from being abused to gain access
  to the running kernel image as part of locking the kernel down under
  UEFI secure boot conditions.

  Annotations are made by changing:

        module_param(n, t, p)
        module_param_named(n, v, t, p)
        module_param_array(n, t, m, p)

  to:

        module_param_hw(n, t, hwtype, p)
        module_param_hw_named(n, v, t, hwtype, p)
        module_param_hw_array(n, t, hwtype, m, p)

  where the module parameter refers to a hardware setting

  hwtype specifies the type of the resource being configured. This can
  be one of:

        ioport          Module parameter configures an I/O port
        iomem           Module parameter configures an I/O mem address
        ioport_or_iomem Module parameter could be either (runtime set)
        irq             Module parameter configures an I/O port
        dma             Module parameter configures a DMA channel
        dma_addr        Module parameter configures a DMA buffer address
        other           Module parameter configures some other value

  Note that the hwtype is compile checked, but not currently stored (the
  lockdown code probably won't require it). It is, however, there for
  future use.

  A bonus is that the hwtype can also be used for grepping.

  The intention is for the kernel to ignore or reject attempts to set
  annotated module parameters if lockdown is enabled. This applies to
  options passed on the boot command line, passed to insmod/modprobe or
  direct twiddling in /sys/module/ parameter files.

  The module initialisation then needs to handle the parameter not being
  set, by (1) giving an error, (2) probing for a value or (3) using a
  reasonable default.

  What I can't do is just reject a module out of hand because it may
  take a hardware setting in the module parameters. Some important
  modules, some ipmi stuff for instance, both probe for hardware and
  allow hardware to be manually specified; if the driver is aborts with
  any error, you don't get any ipmi hardware.

  Further, trying to do this entirely in the module initialisation code
  doesn't protect against sysfs twiddling.

  [!] Note that in and of itself, this series of patches should have no
      effect on the the size of the kernel or code execution - that is
      left to a patch in the next series to effect. It does mark
      annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in
      an already existing field"

* tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits)
  Annotate hardware config module parameters in sound/pci/
  Annotate hardware config module parameters in sound/oss/
  Annotate hardware config module parameters in sound/isa/
  Annotate hardware config module parameters in sound/drivers/
  Annotate hardware config module parameters in fs/pstore/
  Annotate hardware config module parameters in drivers/watchdog/
  Annotate hardware config module parameters in drivers/video/
  Annotate hardware config module parameters in drivers/tty/
  Annotate hardware config module parameters in drivers/staging/vme/
  Annotate hardware config module parameters in drivers/staging/speakup/
  Annotate hardware config module parameters in drivers/staging/media/
  Annotate hardware config module parameters in drivers/scsi/
  Annotate hardware config module parameters in drivers/pcmcia/
  Annotate hardware config module parameters in drivers/pci/hotplug/
  Annotate hardware config module parameters in drivers/parport/
  Annotate hardware config module parameters in drivers/net/wireless/
  Annotate hardware config module parameters in drivers/net/wan/
  Annotate hardware config module parameters in drivers/net/irda/
  Annotate hardware config module parameters in drivers/net/hamradio/
  Annotate hardware config module parameters in drivers/net/ethernet/
  ...

Annotate hardware config module parameters in drivers/iio/

2017-04-20T11:02:32+00:00

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/iio/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
Acked-by: William Breathitt Gray 
Acked-by: Jonathan Cameron 
cc: linux-iio@vger.kernel.org

Merge tag 'iio-fixes-for-4.11e' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next

2017-04-18T17:38:38+00:00

Jonathan writes:

Fifth set of IIO fixes for the 4.11 cycle.

As these are rather late in the cycle, they may sneak over into 4.12.
There is a fix for a regression caused by another fix (hid sensors
hardware seems to vary a lot in how various corner cases are handled).

* ad7303
  - fix channel description. Numeric values were being passed as characters
  presumably leading to garbage from the userspace interface.
* as3935
  - the write data macro was wrong so fix it.
* bmp280
  - incorrect handling of negative values as being unsigned broke humidity
  calculation.
* hid-sensor
  - Restore the poll and hysteresis values after resume as some hardware
  doesn't do it.
* stm32-trigger
  - buglet in reading the sampling frequency