<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/iio/dac, branch linux-4.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-05-29T13:53:42Z</updated>
<entry>
<title>Merge tag 'iio-for-4.13a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next</title>
<updated>2017-05-29T13:53:42Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
</author>
<published>2017-05-29T13:53:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ca9280d1f82a7a0165a683dc09f182329ebec352'/>
<id>urn:sha1:ca9280d1f82a7a0165a683dc09f182329ebec352</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>iio:ad5064: Add support for ltc2633 and similar devices</title>
<updated>2017-05-14T15:16:57Z</updated>
<author>
<name>Mike Looijmans</name>
</author>
<published>2017-05-08T07:26:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b2d2d2bfca6832ae61f80c5fbc9e7cdc566d04b4'/>
<id>urn:sha1:b2d2d2bfca6832ae61f80c5fbc9e7cdc566d04b4</id>
<content type='text'>
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 &lt;mike.looijmans@topic.nl&gt;
Reviewed-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs</title>
<updated>2017-05-11T02:13:03Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2017-05-11T02:13:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=291b38a7565b41676cafd1b4052315a94d9c8977'/>
<id>urn:sha1:291b38a7565b41676cafd1b4052315a94d9c8977</id>
<content type='text'>
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/
  ...
</content>
</entry>
<entry>
<title>Annotate hardware config module parameters in drivers/iio/</title>
<updated>2017-04-20T11:02:32Z</updated>
<author>
<name>David Howells</name>
</author>
<published>2017-04-04T15:54:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8863b3e785b8054b981760e26e63a25897467c42'/>
<id>urn:sha1:8863b3e785b8054b981760e26e63a25897467c42</id>
<content type='text'>
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 &lt;gnomes@lxorguk.ukuu.org.uk&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Acked-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
cc: linux-iio@vger.kernel.org
</content>
</entry>
<entry>
<title>Merge tag 'iio-fixes-for-4.11e' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next</title>
<updated>2017-04-18T17:38:38Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
</author>
<published>2017-04-18T17:38:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=df47c0a638b07dab18b202b307506e4b86b02e9a'/>
<id>urn:sha1:df47c0a638b07dab18b202b307506e4b86b02e9a</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>iio: dac: add support for stm32 DAC</title>
<updated>2017-04-14T15:36:16Z</updated>
<author>
<name>Fabrice Gasnier</name>
</author>
<published>2017-04-10T15:49:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4d4b30526eb88c4528ddfa8c113961c1ac178479'/>
<id>urn:sha1:4d4b30526eb88c4528ddfa8c113961c1ac178479</id>
<content type='text'>
Add support for STMicroelectronics STM32 DAC. It's a 12-bit, voltage
output digital-to-analog converter. It has two output channels, each
with its own converter.
It supports 8 bits or 12bits left/right aligned data format. Only
12bits right-aligned is used here. It has built-in noise or
triangle waveform generator, and supports external triggers for
conversions.
Each channel can be used independently, with separate trigger, then
separate IIO devices are used to handle this. Core driver is intended
to share common resources such as clock, reset, reference voltage and
registers.

Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@st.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: dac: ad7303: fix channel description</title>
<updated>2017-04-14T13:44:29Z</updated>
<author>
<name>Pavel Roskin</name>
</author>
<published>2017-04-13T21:54:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ce420fd4251809b4c3119b3b20c8b13bd8eba150'/>
<id>urn:sha1:ce420fd4251809b4c3119b3b20c8b13bd8eba150</id>
<content type='text'>
realbits, storagebits and shift should be numbers, not ASCII characters.

Signed-off-by: Pavel Roskin &lt;plroskin@gmail.com&gt;
Reviewed-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: dac: ad5504: Remove unnecessary cast on void pointer</title>
<updated>2017-04-02T08:48:50Z</updated>
<author>
<name>simran singhal</name>
</author>
<published>2017-04-01T14:11:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4d925083e8f9f0c619fe212cfd0729c3dc1442b2'/>
<id>urn:sha1:4d925083e8f9f0c619fe212cfd0729c3dc1442b2</id>
<content type='text'>
The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)-&gt;f
|
- (T*)
  e
)

Signed-off-by: simran singhal &lt;singhalsimran0@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: dac: ad5504: constify attribute_group structures</title>
<updated>2017-03-29T21:08:51Z</updated>
<author>
<name>simran singhal</name>
</author>
<published>2017-03-28T20:21:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e36020fd69952bf42554bbeb2c0e98927a0c656b'/>
<id>urn:sha1:e36020fd69952bf42554bbeb2c0e98927a0c656b</id>
<content type='text'>
Check for attribute_group structures that are only stored in the
event_attrs filed of iio_info structure. As the event_attrs field of
iio_info structures is constant, so these attribute_group structures can
also be declared constant. Done using coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct attribute_group i@p = {...};

@ok1@
identifier r1.i;
position p;
struct iio_info x;
@@
x.event_attrs=&amp;i@p;

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct attribute_group i={...};

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct attribute_group i;

File size before:
   text    data     bss     dec     hex filename
   3046     360       0    3406     d4e drivers/iio/dac/ad5504.o

File size after:
   text	   data	    bss	    dec	    hex	filename
   3110	    296	      0	   3406	    d4e	drivers/iio/dac/ad5504.o

Signed-off-by: simran singhal &lt;singhalsimran0@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: dac: Add support for ltc2632 DACs</title>
<updated>2017-03-21T18:43:56Z</updated>
<author>
<name>Maxime Roussin-Belanger</name>
</author>
<published>2017-03-17T18:04:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=02b829f9e11fd9e6eeebc1e85e4d5ae641706c70'/>
<id>urn:sha1:02b829f9e11fd9e6eeebc1e85e4d5ae641706c70</id>
<content type='text'>
Add support for Linear Technology LTC2632 (SPI) family of·
dual 12- 10-, and 8-bits output DACs.

Signed-off-by: Maxime Roussin-Belanger &lt;maxime.roussinbelanger@gmail.com&gt;
Signed-off-by: Jean-Francois Dagenais &lt;jeff.dagenais@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
</entry>
</feed>
