Industrial I/O driver developer's guide

Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932885AbbHDI7l (ORCPT ); Tue, 4 Aug 2015 04:59:41 -0400 Received: from mail-lb0-f169.google.com ([209.85.217.169]:36435 "EHLO mail-lb0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932677AbbHDI7c (ORCPT ); Tue, 4 Aug 2015 04:59:32 -0400 MIME-Version: 1.0 In-Reply-To: References: <1438351461-19948-1-git-send-email-daniel.baluta@intel.com> <1438351461-19948-2-git-send-email-daniel.baluta@intel.com> Date: Tue, 4 Aug 2015 11:59:30 +0300 X-Google-Sender-Auth: qH4Gd7e-dxdIgvnVL-i-YKpJ3SQ Message-ID: Subject: Re: [PATCH v4] DocBook: Add initial documentation for IIO From: Daniel Baluta To: Peter Meerwald Cc: Daniel Baluta , Jonathan Cameron , Jonathan Corbet , Hartmut Knaack , Lars-Peter Clausen , Linux Kernel Mailing List , "linux-iio@vger.kernel.org" , linux-doc@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 33821 Lines: 879 On Mon, Aug 3, 2015 at 12:24 PM, Peter Meerwald wrote: > On Fri, 31 Jul 2015, Daniel Baluta wrote: > >> This is intended to help developers faster find their way >> inside the Industrial I/O core and reduce time spent on IIO >> drivers development. > > comments inline below Hi Peter, thanks a lot for your review. I've addressed most of your comments and will send asap v5. > >> Signed-off-by: Daniel Baluta >> --- >> Documentation/DocBook/Makefile | 2 +- >> Documentation/DocBook/iio.tmpl | 702 +++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 703 insertions(+), 1 deletion(-) >> create mode 100644 Documentation/DocBook/iio.tmpl >> >> diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile >> index b6a6a2e..9e08606 100644 >> --- a/Documentation/DocBook/Makefile >> +++ b/Documentation/DocBook/Makefile >> @@ -15,7 +15,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ >> 80211.xml debugobjects.xml sh.xml regulator.xml \ >> alsa-driver-api.xml writing-an-alsa-driver.xml \ >> tracepoint.xml drm.xml media_api.xml w1.xml \ >> - writing_musb_glue_layer.xml crypto-API.xml >> + writing_musb_glue_layer.xml crypto-API.xml iio.xml >> >> include Documentation/DocBook/media/Makefile >> >> diff --git a/Documentation/DocBook/iio.tmpl b/Documentation/DocBook/iio.tmpl >> new file mode 100644 >> index 0000000..b39b3e9 >> --- /dev/null >> +++ b/Documentation/DocBook/iio.tmpl >> @@ -0,0 +1,702 @@ >> + >> +> + "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> >> + >> + >> + >> + Industrial I/O driver developer's guide >> + >> + >> + >> + Daniel >> + Baluta >> + >> +

>> + daniel.baluta@intel.com >> +

>> + >> + >> + >> + >> + >> + 2015 >> + Intel Corporation >> + >> + >> + >> + >> + This documentation is free software; you can redistribute >> + it and/or modify it under the terms of the GNU General Public >> + License version 2. >> + >> + >> + >> + >> + >> + >> + >> + Introduction >> + >> + The main purpose of the Industrial I/O subsystem (IIO) is to provide >> + support for devices that in some sense perform either analog-to-digital >> + conversion (ADC) or digital-to-analog conversion (DAC) or both. The aim >> + is to fill the gap between the somewhat similar hwmon and input >> + subsystems. >> + Hwmon is directed at low sample rate sensors used to monitor and >> + control the system itself, like fan speed control or temperature >> + measurement. Input is, as its name suggests, focused on human interaction >> + input devices (keyboard, mouse, touchscreen). In some cases there is >> + considerable overlap between these and IIO. >> + >> + >> + Devices that fall into this category include: >> + >> + >> + analog to digital converters (ADCs) >> + >> + >> + accelerometers >> + >> + >> + capacitance to digital converters (CDCs) >> + >> + >> + digital to analog converters (DACs) >> + >> + >> + gyroscopes >> + >> + >> + inertial measurement units (IMUs) >> + >> + >> + color and light sensors >> + >> + >> + magnetometers >> + >> + >> + pressure sensors >> + >> + >> + proximity sensors >> + >> + >> + temperature sensors >> + >> + >> + Usually these sensors are connected via SPI or I2C. A common use case of the >> + sensors devices is to have combined functionality (e.g. light plus proximity > > sorsor devices :), sensor devices. Got it :). > >> + sensor). >> + >> + >> + >> + Industrial I/O core >> + >> + The Industrial I/O core offers: >> + >> + >> + a unified framework for writing drivers for many different types of >> + embedded sensors. >> + >> + >> + a standard interface to user space applications manipulating sensors. >> + >> + >> + The implementation can be found under >> + drivers/iio/industrialio-* >> + >> + >> + Industrial I/O devices > > extra spaces after/before tag, here and elsewhere Nice catch. Fixed. > >> + >> +!Finclude/linux/iio/iio.h iio_dev >> +!Fdrivers/iio/industrialio-core.c iio_device_alloc >> +!Fdrivers/iio/industrialio-core.c iio_device_free >> +!Fdrivers/iio/industrialio-core.c iio_device_register >> +!Fdrivers/iio/industrialio-core.c iio_device_unregister >> + >> + >> + An IIO device usually corresponds to a single hardware sensor and it >> + provides all the information needed by a driver handling a device. >> + Let's first have a look at the functionality embedded in an IIO >> + device then we will show how a device driver makes use of an IIO >> + device. >> + >> + >> + There are two ways for a user space application to interact >> + with an IIO driver. >> + >> + >> + /sys/bus/iio/iio:deviceX/, this >> + represents a hardware sensor and groups together the data >> + channels of the same chip. >> + >> + >> + /dev/iio:deviceX, character device node >> + interface used for faster data transfer and for events information > > maybe refer to buffered data transfer? ok. > >> + retrieval. >> + >> + >> + >> + A typical IIO driver will register itself as an I2C or SPI driver and will >> + create two routines, probe and remove >> + . At probe: >> + >> + call iio_device_alloc, which allocates memory >> + for an IIO device. >> + >> + initialize IIO device fields with driver specific information >> + (e.g. device name, device channels). >> + >> + call iio_device_register, this registers the >> + device with the IIO core. After this call the device is ready to accept >> + requests from user space applications. >> + >> + >> + At remove, we free the resources allocated in >> + probe in reverse order: >> + >> + iio_device_unregister, unregister the device >> + from the IIO core. >> + >> + iio_device_free, free the memory allocated >> + for the IIO device. >> + >> + >> + >> + IIO device sysfs interface >> + >> + Attributes are sysfs files used to expose chip info and also allowing >> + applications to set various configuration parameters. For device >> + with index X, attributes can be found under >> + /sys/bus/iio/iio:deviceX/ directory. >> + Common attributes are: >> + >> + name, description of the physical >> + chip. >> + >> + dev, shows the major:minor pair >> + associated with /dev/iio:deviceX node. >> + >> + sampling_frequency_available, >> + available discrete set of sampling frequency values for > > sampling_frequency is rather specific and not found for all devices; > it may also appear under events/ Most of the devices I use have a configurable sampling_frequency (e.g gyro, accels, magnetometers). I think it's not far from true that sampling_frequency is a common attribute. Or I could change 'common' to something else? > >> + device. >> + >> + >> + Available standard attributes for IIO devices are described in the >> + Documentation/ABI/testing/sysfs-bus-iio file >> + in the Linux kernel sources. >> + >> + >> + IIO device channels >> +!Finclude/linux/iio/iio.h iio_chan_spec structure. >> + >> + An IIO device channel is a representation of a data channel. An >> + IIO device can have one or multiple channels. For example: >> + >> + >> + a thermometer sensor has one channel representing the >> + temperature measurement. >> + >> + >> + a light sensor with two channels indicating the measurements in >> + the visible and infrared spectrum. >> + >> + >> + an accelerometer can have up to 3 channels representing >> + acceleration on X, Y and Z axes. >> + >> + >> + An IIO channel is described by the struct iio_chan_spec >> + . A thermometer driver for the temperature sensor in the >> + example above would have to describe its channel as follows: >> + >> + static const struct iio_chan_spec temp_channel[] = { >> + { >> + .type = IIO_TEMP, >> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), > > _RAW vs. _PROCESSED? Not sure I understand this. PROCESSED because I want to avoid exposing now scale and offset. Also, it's just an example. > >> + }, >> + }; >> + >> + >> + Channel sysfs attributes exposed to userspace are specified in >> + the form of bitmasks. Depending on their >> + shared info, attributes can be set in one of the following masks: >> + >> + info_mask_separate, attributes will >> + be specific to this channel >> + info_mask_shared_by_type, >> + attributes are shared by all channels of the same type >> + info_mask_shared_by_dir, attributes >> + are shared by all channels of the same direction >> + info_mask_shared_by_all, >> + attributes are shared by all channels >> + >> + When there are multiple data channels per sensor type there are two > > per channel type? Ok. > >> + ways to distinguish between them: >> + >> + set .modified field of >> + iio_chan_spec to 1. Modifiers are specified using >> + .channel2 field of the same >> + iio_chan_spec structure and are used to indicate a >> + physically unique characteristic of the channel such as its direction >> + or spectral response. For example, a light sensor can have two channels, >> + one for infrared light and one for both infrared and visible light. >> + >> + set .indexed field of >> + iio_chan_spec to 1. In this case the channel is >> + simply another instance with an index specified by the >> + .channel field. >> + >> + >> + Here is how we can make use of the channel's modifiers: >> + >> + static const struct iio_chan_spec light_channels[] = { >> + { >> + .type = IIO_INTENSITY, >> + .modified = 1, >> + .channel2 = IIO_MOD_LIGHT_IR, >> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), >> + .info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ), >> + }, >> + { >> + .type = IIO_INTENSITY, >> + .modified = 1, >> + .channel2 = IIO_MOD_LIGHT_BOTH, >> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), >> + .info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ), >> + }, >> + { >> + .type = IIO_LIGHT, >> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), >> + .info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ), >> + }, >> + >> + } >> + >> + This channel's definition will generate two separate sysfs files >> + for raw data retrieval: >> + >> + >> + /sys/bus/iio/iio:deviceX/in_intensity_ir_raw >> + >> + >> + /sys/bus/iio/iio:deviceX/in_intensity_both_raw >> + >> + >> + one file for processed data: >> + >> + >> + /sys/bus/iio/iio:deviceX/in_illuminance_input >> + >> + >> + >> + and one shared sysfs file for sampling frequency: > > this is a bit of a corner case: why is there just one _sampling_frequency > channel? it could also have been named in_illuminance_sampling_frequency In fact, the attribute will be called sampling frequency, the field name is wrong it should by info_mask_shared_by_all :). > >> + >> + >> + /sys/bus/iio/iio:deviceX/in_intensity_sampling_frequency. >> + >> + >> + >> + >> + >> + Here is how we can make use of the channel's indexing: >> + >> + static const struct iio_chan_spec light_channels[] = { >> + { >> + .type = IIO_VOLTAGE, >> + .indexed = 1, >> + .channel = 0, >> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), >> + }, >> + { >> + .type = IIO_VOLTAGE, >> + .indexed = 1, >> + .channel = 1, >> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), >> + }, >> + } >> + >> + This will generate two separate attributes files for raw data >> + retrieval: >> + >> + >> + /sys/bus/iio/devices/iio:deviceX/in_voltage0_raw, >> + representing voltage measurement for channel 0. >> + >> + >> + /sys/bus/iio/devices/iio:deviceX/in_voltage1_raw, >> + representing voltage measurement for channel 1. >> + >> + >> + >> + >> + >> + >> + Industrial I/O buffers >> +!Finclude/linux/iio/buffer.h iio_buffer >> +!Edrivers/iio/industrialio-buffer.c >> + >> + >> + The Industrial I/O core offers a way for continuous data capture >> + based on a trigger source. Multiple data channels can be read at once >> + from /dev/iio:deviceX character device node, >> + thus reducing the CPU load. >> + >> + >> + >> + IIO buffer sysfs interface >> + >> + An IIO buffer has an associated attributes directory under >> + /sys/bus/iio/iio:deviceX/buffer/. Here are the existing >> + attributes: >> + >> + >> + length, number of data samples contained by the >> + buffer. > > wording is not very clean; length is is the buffer length/capacity, not > the number of samples currently in the buffer Oh, I see. The same wording is in the ABI file: > >> + >> + >> + enable, activate buffer capture. >> + >> + >> + >> + >> + IIO buffer setup >> + The meta information associated with a channel reading >> + placed in a buffer is called a scan element . >> + The important bits configuring scan elements are exposed to >> + userspace applications via the >> + /sys/bus/iio/iio:deviceX/scan_elements/ directory. This >> + file contains attributes of the following form: >> + >> + enable, used for enabling a channel. >> + If and only if its attribute is non zero, then a triggered capture >> + will contain data samples for this channel. >> + >> + type, description of the scan element >> + data storage within the buffer and hence the form in which it is >> + read from user space. Format is >> + [be|le]:[s|u]bits/storagebitsXrepeat[>>shift] . >> + >> + be or le specifies >> + big or little endian. >> + >> + >> + s or u specifies if >> + signed (2's complement) or unsigned. >> + >> + bits is the number of bits of data > > number of data bits > >> + >> + storagebits is the space (after padding) >> + that it occupies in the buffer. > > is the number of bits (after padding) that... > >> + >> + >> + shift if specified, is the shift that needs >> + to be a applied prior to masking out unused bits > > that needs to be applied -- delete a > >> + >> + >> + repeat, specifies the number of real/storage bits > > what is real? -- undefined at this point; > "real/storage" doesn't make it clear if the padded or unpadded data bits > are repeated -- I think the later > maybe: "specifies the number of unpadded data repetitions" > >> + repetitions. When the repeat element is 0 or 1, then the repeat >> + value is omitted. >> + >> + >> + >> + >> + For example, a driver for a 3-axis accelerometer with 12 bit >> + resolution where data is stored in two 8-bits registers as >> + follows: >> + >> + 7 6 5 4 3 2 1 0 >> + +---+---+---+---+---+---+---+---+ >> + |D3 |D2 |D1 |D0 | X | X | X | X | (LOW byte, address 0x06) >> + +---+---+---+---+---+---+---+---+ >> + >> + 7 6 5 4 3 2 1 0 >> + +---+---+---+---+---+---+---+---+ >> + |D11|D10|D9 |D8 |D7 |D6 |D5 |D4 | (HIGH byte, address 0x07) >> + +---+---+---+---+---+---+---+---+ >> + >> + >> + will have the following scan element type for each axis: >> + >> + $ cat /sys/bus/iio/devices/iio:device0/scan_elements/in_accel_y_type >> + le:s12/16>>4 >> + >> + The userspace applications will interpret data samples read from buffer > > user space -- inconsistent > maybe "A user space application will..." > the buffer -- the > >> + as two byte little endian signed data, that needs a 4 bits right >> + shift before masking out the only 12 valid bits of real data. > > masking out the 12 valid bits of data > >> + >> + >> + For implementing buffer support a driver should initialize the following >> + fields in iio_chan_spec definition: >> + >> + struct iio_chan_spec { >> + /* other members */ >> + int scan_index >> + struct { >> + char sign; >> + u8 realbits; >> + u8 storagebits; >> + u8 shift; >> + u8 repeat; >> + enum iio_endian endianness; >> + } scan_type; >> + }; >> + >> + The driver implementing the accelerometer described above will >> + have the following channel definition: >> + >> + struct struct iio_chan_spec accel_channels[] = { >> + { >> + .type = IIO_ACCEL, >> + .modified = 1, >> + .channel2 = IIO_MOD_X, >> + /* other stuff here */ >> + .scan_index = 0, >> + .scan_type = { >> + .sign = 's', >> + .realbits = 12, >> + .storgebits = 16, >> + .shift = 4, >> + .endianness = IIO_LE, >> + }, >> + } >> + /* similar for Y and Z axis */ > > two spaces before Z > maybe: "similar for Y (with channel2 = IIO_MOD_Y, scan_index = 1) and Z > (with channel2 = IIO_MOD_Z, scan_index=2) axis" > >> + } >> + >> + >> + >> + Here scan_index defines the relative order in which > > why relative? > it is simply the order > >> + the enabled channels are placed inside the buffer. Channels with a lower >> + scan_index will be placed before channels with a higher index. Each >> + channel needs to have a unique scan_index. >> + >> + >> + It is important to realize that the scan_index does not define the >> + absolute position in the buffer. E.g. a channel with the scan_index = 3 >> + will not be at offset 3 bytes or 3 words, but rather will be placed in the >> + buffer after any channel with a scan_index lower than 3 and before >> + any channel with a scan_index larger than 3. > > I'd drop the paragraph above, this is just confusing; better mention that > there are padding rules (e.g. for the timestamp channel) and it follows > that the scan_index is not a byte offset into the buffer > >> + Furthermore the scan indices do not have to be consecutive. E.g. A >> + channel spec array that defines 3 channels with the indices 1, 2 and 3 is >> + just as valid as a channel spec that uses the indices 100, 200, 300. The >> + relative order of the channels will be the same. >> + >> + >> + Setting scan_index to -1 can be used to indicate that the specific >> + channel does not support buffered capture. In this case no entries will >> + be created for the channel in the scan_elements directory. >> + >> + >> + >> + >> + Industrial I/O triggers >> +!Finclude/linux/iio/trigger.h iio_trigger >> +!Edrivers/iio/industrialio-trigger.c >> + >> + In many situations it is useful for a driver to be able to >> + capture data based on some external event (trigger) as opposed >> + to periodically polling for data. An IIO trigger can be provided >> + by a device driver that also has an IIO device based on hardware >> + generated events (e.g. data ready or threshold exceeded) or >> + provided by a separate driver from an independent interrupt >> + source (e.g. GPIO line connected to some external system, timer >> + interrupt or user space reading a specific file in sysfs). A > > writing a specific file > >> + trigger may initialize data capture for a number of sensors and > > initiate -- not initialize > >> + also it may be completely unrelated to the sensor itself. >> + >> + >> + IIO trigger sysfs interface >> + There are two locations in sysfs related to triggers: >> + >> + /sys/bus/iio/devices/triggerY, >> + this file is created once an IIO triggered is registered with > > an IIO trigger > >> + the IIO core and corresponds to trigger with index Y. Because >> + triggers can be very different depending on type there are few >> + standard attributes that we can describe here: >> + >> + >> + name, trigger name that can be later >> + used to for association with a device. > > used for association > >> + >> + >> + sampling_frequency, some timer based >> + triggers use this attribute to specify the frequency for >> + trigger calls. >> + >> + >> + >> + >> + /sys/bus/iio/devices/iio:deviceX/trigger/, this >> + directory is created once the device supports a triggered >> + buffer. We can associate a trigger with our device by writing >> + trigger's name in thecurrent_trigger file. > > the trigger's name -- the > the -- add space before tag > >> + >> + >> + >> + >> + IIO trigger setup >> + >> + >> + Let's see a simple example of how to setup a trigger to be used >> + by a driver. >> + >> + >> + struct iio_trigger_ops trigger_ops = { >> + .set_trigger_state = sample_trigger_state, >> + .validate_device = sample_validate_device, >> + } >> + >> + struct iio_trigger *trig; >> + >> + /* first, allocate memory for our trigger */ >> + trig = iio_trigger_alloc(dev, "trig-%s-%d", name, idx); >> + >> + /* setup trigger operations field */ >> + trig->ops = &trigger_ops; >> + >> + /* now register the trigger with the IIO core */ >> + iio_trigger_register(trig); >> + >> + >> + >> + >> + IIO trigger ops >> +!Finclude/linux/iio/trigger.h iio_trigger_ops >> + >> + Notice that a trigger has a set of operations attached: >> + >> + >> + set_trigger_state, switch the trigger on/off >> + on demand. >> + >> + >> + validate_device, function to validate the >> + device when the current trigger gets changed. >> + >> + >> + >> + >> + >> + >> + Industrial I/O triggered buffers >> + >> + Now that we know what buffers and triggers are let's see how they >> + work together. >> + >> + IIO triggered buffer setup >> +!Edrivers/iio/industrialio-triggered-buffer.c >> +!Finclude/linux/iio/iio.h iio_buffer_setup_ops >> + >> + >> + >> + A typical triggered buffer setup looks like this: >> + >> + const struct iio_buffer_setup_ops sensor_buffer_setup_ops = { >> + .preenable = sensor_buffer_preenable, >> + .postenable = sensor_buffer_postenable, >> + .postdisable = sensor_buffer_postdisable, >> + .predisable = sensor_buffer_predisable, >> + }; >> + >> + irqreturn_t sensor_iio_pollfunc(int irq, void *p) >> + { >> + pf->timestamp = iio_get_time_ns(); >> + return IRQ_WAKE_THREAD; >> + } >> + >> + irqreturn_t sensor_trigger_handler(int irq, void *p) >> + { >> + u16 buf[8]; > > int i = 0; > >> + >> + /* read data for each active channel */ >> + for_each_set_bit(bit, active_scan_mask, masklength) >> + buf[i++] = sensor_get_data(bit) >> + >> + iio_push_to_buffers_with_timestamp(indio_dev, buffer, timestamp); > > buf -- not buffer > >> + >> + iio_trigger_notify_done(trigger); > > return IRQ_HANDLED; > >> + } >> + >> + /* setup triggered buffer, usually in probe function */ >> + iio_triggered_buffer_setup(indio_dev, sensor_iio_polfunc, >> + sensor_trigger_handler, >> + sensor_buffer_setup_ops); >> + >> + >> + The important things to notice here are: >> + >> + iio_buffer_setup_ops, the buffer setup >> + functions to be called at predefined points in buffer configuration > > the buffer configuration -- the > >> + sequence (e.g. before enable, after disable). If not specified, the >> + IIO core uses the default iio_triggered_buffer_setup_ops. >> + >> + sensor_iio_pollfunc, the function that >> + will be used as top half of poll function. It should do as little >> + processing as possible, because it runs in interrupt context. The most >> + common operation is recording of the current timestamp and for this reason >> + one can use the IIO core defined iio_pollfunc_store_time >> + function. >> + >> + sensor_trigger_handler, the function that >> + will be used as bottom half of the poll function. This runs in the >> + context of a kernel thread and all the processing takes place here. >> + It usually reads data from the device and stores it in the internal >> + buffer together with the timestamp recorded in the top half. >> + >> + >> + >> + >> + >> + >> + Resources >> + IIO core may change during time so the best documentation to read is the >> + source code. There are several locations where you should look: >> + >> + >> + drivers/iio/, contains the IIO core plus >> + and directories for each sensor type (e.g. accel, magnetometer, >> + etc.) >> + >> + >> + include/linux/iio/, contains the header >> + files, nice to read for the internal kernel interfaces. >> + >> + >> + include/uapi/linux/iio/, contains files to be >> + used by user space applications. >> + >> + >> + tools/iio/, contains tools for rapidly >> + testing buffers, events and device creation. >> + >> + >> + drivers/staging/iio/, contains code for some >> + drivers or experimental features that are not yet mature enough >> + to be moved out. >> + >> + >> + >> + Besides the code, there are some good online documentation sources: >> + >> + >> + Industrial I/O mailing >> + list >> + >> + >> + >> + Analog Device IIO wiki page >> + >> + >> + >> + Using the Linux IIO framework for SDR, Lars-Peter Clausen's >> + presentation at FOSDEM >> + >> + >> + >> + >> + >> + >> + >> > > -- > > Peter Meerwald > +43-664-2444418 (mobile) > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/