12 Jan, 2017
2 commits
-
commit 65e4345c8ef8811bbb4860fe5f2df10646b7f2e1 upstream.
The LIS3LV02 has a special bit that need to be set to get the
read values left aligned. Before this patch we get gibberish
like this:iio_generic_buffer -a -c10 -n lis3lv02dl_accel
(...)
0.000000 -0.010042 -0.642688 19155832931907
0.000000 -0.010042 -0.642688 19155858751073Which is because we read a raw value for 1g as 64 which is
the nominal 1024 for 1g shifted 4 bits to the left by being
right-aligned rather than left aligned.Since all other sensors are left aligned, add some code to
set the special DAS (data alignment setting) bit to 1 so that
the right value is now read like this:iio_generic_buffer -a -c10 -n lis3lv02dl_accel
(...)
0.000000 -0.147095 -10.120135 24761614364956
-0.029419 -0.176514 -10.120135 24761631624540The scaling was weird as well: we have a gain of 1000 for 1g
and 3000 for 6g. I don't even remember how I came up with the
old values but they are wrong.Fixes: 3acddf74f807 ("iio: st-sensors: add support for lis3lv02d accelerometer")
Cc: Lorenzo Bianconi
Cc: Giuseppe Barba
Cc: Denis Ciocca
Signed-off-by: Linus Walleij
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 65c8aea07de11b6507efa175edb44bd8b4488218 upstream.
Using realbits as i2c/spi read len, when that value is not byte aligned
(e.g 12 bits), lead to skip msb part of out data registers.
Fix this taking into account scan_type.shift in addition to
scan_type.realbits as read length:read_len = DIV_ROUND_UP(realbits + shift, 8)
This fix has been tested on 8, 12, 16, 24 bit sensors
Fixes: e7385de5291e ("iio:st_sensors: align on storagebits boundaries")
Signed-off-by: Lorenzo Bianconi
Tested-by: Linus Walleij
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
06 Nov, 2016
1 commit
-
While testing, it was observed that on some platforms the scale value
from iio sysfs for gyroscope is always 0 (E.g. Yoga 260). This results
in the final angular velocity component values to be zeros.This is caused by insufficient precision of scale value displayed in sysfs.
If the precision is changed to nano from current micro, then this is
sufficient to display the scale value on this platform.
Since this can be a problem for all other HID sensors, increase scale
precision of all HID sensors to nano from current micro.Results on Yoga 260:
name scale before scale now
--------------------------------------------
gyro_3d 0.000000 0.000000174
als 0.001000 0.001000000
magn_3d 0.000001 0.000001000
accel_3d 0.000009 0.000009806Signed-off-by: Song Hongyan
Acked-by: Srinivas Pandruvada
Cc:
Signed-off-by: Jonathan Cameron
31 Oct, 2016
1 commit
-
fix scale configuration/parsing for h3lis331dl accel driver
when sensitivity is higher than 1(m/s^2)/digitSigned-off-by: Lorenzo Bianconi
Fixes: 1e52fefc9b0c ("iio: accel: Add support for the h3lis331dl accelerometer")
Cc:
Signed-off-by: Jonathan Cameron
15 Sep, 2016
1 commit
-
…iio into staging-next
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.
12 Sep, 2016
1 commit
-
We need the IIO changes in here for future patches to build on.
Signed-off-by: Greg Kroah-Hartman
10 Sep, 2016
1 commit
-
The ST sensors can be used as a trigger for its own triggered buffer
but it is also possible to use an external trigger: a HRTimer or
even a different sensor (!) as trigger. In that case we should not
pick the timestamp from our own interrupt top half even if it is
active.This could practically happen if some other sensor is using the
ST sensor as trigger but the ST sensor itself is using e.g.
an HRTimer as trigger. So the trigger is on, but not used by us.We used to assume that whenever the hardware interrupt is turned
on, we are using it for our own trigger, but this is an
oversimplification.Handle this logically by using the iio_trigger_using_own() helper.
Cc: Giuseppe Barba
Cc: Denis Ciocca
Cc: Crestez Dan Leonard
Cc: Gregor Boirie
Signed-off-by: Linus Walleij
Signed-off-by: Jonathan Cameron
04 Sep, 2016
2 commits
-
We were checking the return code of vdd when we should be checking
vdd_io. My mistake, mea culpa.Cc: Giuseppe BARBA
Reported-by: Giuseppe BARBA
Signed-off-by: Linus Walleij
Signed-off-by: Jonathan Cameron -
According to IIO ABI definition, IIO_PRESSURE data output unit is
kilopascal:
http://lxr.free-electrons.com/source/Documentation/ABI/testing/sysfs-bus-iioThis patch fix output unit of HID pressure sensor IIO driver from pascal to
kilopascal to follow IIO ABI definition.Signed-off-by: Kweh, Hock Leong
Reviewed-by: Srinivas Pandruvada
Cc:
Signed-off-by: Jonathan Cameron
30 Aug, 2016
3 commits
-
We get 2 warnings when biuld kernel with W=1:
drivers/iio/common/st_sensors/st_sensors_trigger.c:69:13: warning: no previous prototype
for 'st_sensors_irq_handler' [-Wmissing-prototypes]
drivers/iio/common/st_sensors/st_sensors_trigger.c:85:13: warning: no previous prototype
for 'st_sensors_irq_thread' [-Wmissing-prototypes]In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
so this patch marks these functions with 'static'.Signed-off-by: Baoyou Xie
Reviewed-by: Linus Walleij
Signed-off-by: Jonathan Cameron -
A small rework of the PM code in this driver introduced a harmless
warning when CONFIG_PM_SLEEP is not set:drivers/iio/common/hid-sensors/hid-sensor-trigger.c:212:12: error: 'hid_sensor_resume' defined but not used [-Werror=unused-function]
This removes the #ifdef and instead marks all three PM functions
as __maybe_unused, which covers all possible cases and is harder
to get wrong.Signed-off-by: Arnd Bergmann
Fixes: 7f6cf7414538 ("iio: hid-sensors: use asynchronous resume")
Signed-off-by: Jonathan Cameron -
These sensors all have Vdd and Vdd_IO lines. This means the
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.Cc: Giuseppe Barba
Cc: Denis Ciocca
Cc: Crestez Dan Leonard
Cc: Gregor Boirie
Cc: Mark Brown
Signed-off-by: Linus Walleij
Signed-off-by: Jonathan Cameron
22 Aug, 2016
1 commit
-
Some platforms power off sensor hubs during S3 suspend, which will require
longer time to resume. This hurts system resume time, so resume
asynchronously.Signed-off-by: Srinivas Pandruvada
Signed-off-by: Jonathan Cameron
05 Jul, 2016
2 commits
-
Ensure triggered buffering memory accesses are properly aligned on per
channel storagebits boundaries.Signed-off-by: Gregor Boirie
Tested-by: Linus Walleij
Signed-off-by: Jonathan Cameron -
Time to finally kill off the venerable (it was one of my first drivers)
lis3l02dq driver in favour of adding support in the st sensors framework.This does loose us the event support that driver always had, but I think
that will reappear at some point and in the meantime the maintenance
advantages of dropping the 'special' driver for this one part outweigh
the issues.It's worth noting this part is ancient and I may well be the only person
who still has any on hardware running recent kernels.It has a few 'quirks'.
- No WAI register so that just became optional.
- A BDU option that really does block updates. Completely.
Whatever you do, you don't get any more data with it set.
It is documented the same as more modern parts but I presume they
are actually clearing for updates after a read of both bytes!
- Fixed scale.
- It's too quick. Even at slowest rate (280Hz) I can't read out fast
enough on my board (stargate 2) to beat new data coming in. Linus'
repeat read patch doesn't help in this case. It just means I get 10
readings before dying... So in reality this will get used with
software triggers only unless someone has this long out of production
device on a quick board.Signed-off-by: Jonathan Cameron
Reviewed-by: Linus Walleij
Cc: Denis CIOCCA
Cc: Crestez Dan Leonard
Signed-off-by: Jonathan Cameron
03 Jul, 2016
1 commit
-
Leonard Crestez observed the following phenomenon: when using
hard interrupt triggers (the DRDY line coming out of an ST
sensor) sometimes a new value would arrive while reading the
previous value, due to latencies in the system.We discovered that the ST hardware as far as can be observed
is designed for level interrupts: the DRDY line will be held
asserted as long as there are new values coming. The interrupt
handler should be re-entered until we're out of values to
handle from the sensor.If interrupts were handled as occurring on the edges (usually
low-to-high) new values could appear and the line be held
asserted after that, and these values would be missed, the
interrupt handler would also lock up as new data was
available, but as no new edges occurs on the DRDY signal,
nothing happens: the edge detector only detects edges.To counter this, do the following:
- Accept interrupt lines to be flagged as level interrupts
using IRQF_TRIGGER_HIGH and IRQF_TRIGGER_LOW. If the line
is marked like this (in the device tree node or ACPI
table or similar) it will be utilized as a level IRQ.
We mark the line with IRQF_ONESHOT and mask the IRQ
while processing a sample, then the top half will be
entered again if new values are available.- If we are flagged as using edge interrupts with
IRQF_TRIGGER_RISING or IRQF_TRIGGER_FALLING: remove
IRQF_ONESHOT so that the interrupt line is not
masked while running the thread part of the interrupt.
This way we will never miss an interrupt, then introduce
a loop that polls the data ready registers repeatedly
until no new samples are available, then exit the
interrupt handler. This way we know no new values are
available when the interrupt handler exits and
new (edge) interrupts will be triggered when data arrives.
Take some extra care to update the timestamp in the poll
loop if this happens. The timestamp will not be 100%
perfect, but it will at least be closer to the actual
events. Usually the extra poll loop will handle the new
samples, but once in a blue moon, we get a new IRQ
while exiting the loop, before returning from the
thread IRQ bottom half with IRQ_HANDLED. On these rare
occasions, the removal of IRQF_ONESHOT means the
interrupt will immediately fire again.- If no interrupt type is indicated from the DT/ACPI,
choose IRQF_TRIGGER_RISING as default, as this is necessary
for legacy boards.Tested successfully on the LIS331DL and L3G4200D by setting
sampling frequency to 400Hz/800Hz and stressing the system:
extra reads in the threaded interrupt handler occurs.Cc: Giuseppe Barba
Cc: Denis Ciocca
Tested-by: Crestez Dan Leonard
Reported-by: Crestez Dan Leonard
Signed-off-by: Linus Walleij
Signed-off-by: Jonathan Cameron
01 Jul, 2016
1 commit
-
Adds a new per-device sysfs attribute "current_timestamp_clock" to allow
userspace to select a particular POSIX clock for buffered samples and
events timestamping.Following clocks, as listed in clock_gettime(2), are supported:
CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW,
CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and
CLOCK_TAI.Signed-off-by: Gregor Boirie
Acked-by: Sanchayan Maity
Signed-off-by: Jonathan Cameron
20 Jun, 2016
1 commit
-
We want the fixes in here, and we can resolve a merge issue in
drivers/iio/industrialio-trigger.cSigned-off-by: Greg Kroah-Hartman
30 May, 2016
3 commits
-
This fixes odd behavior after reboot.
The fact that we set the device to powerdown mode is not sufficient to
prevent DRDY being active because we might still have an unread sample.Even if powerdown was sufficient keeping DRDY disabled while trigger is
not active is a good idea.Cc: Giuseppe Barba
Cc: Denis Ciocca
Signed-off-by: Crestez Dan Leonard
Reviewed-by: Linus Walleij
Signed-off-by: Jonathan Cameron -
This fixes a possible race where an interrupt arrives before complete
initialization and crashes because iio_trigger_get_drvdata returns NULL.Cc: Giuseppe Barba
Cc: Denis Ciocca
Signed-off-by: Crestez Dan Leonard
Reviewed-by: Linus Walleij
Signed-off-by: Jonathan Cameron -
commit 98ad8b41f58dff6b30713d7f09ae3834b8df7ded
("iio: st_sensors: verify interrupt event to status") caused
a regression when reading ST sensors from a HRTimer trigger
rather than the intrinsic interrupts: the HRTimer may
trigger faster than the sensor provides new values, and
as the check against new values available as a cause of
the interrupt trigger was done in the poll function,
this would bail out of the HRTimer interrupt with
IRQ_NONE.So clearly we need to only check the new values available
from the proper interrupt handler and not from the poll
function, which should rather just read the raw values
from the registers, put them into the buffer and be happy.To achieve this: switch the ST Sensors over to using a true
threaded interrupt handler.In the interrupt thread, check if new values are available,
else yield to the (potential) next device on the same
interrupt line to check the registers. If the interrupt
was ours, proceed to poll the values.Instead of relying on iio_trigger_generic_data_rdy_poll() as
a top half to wake up the thread that polls the sensor for
new data, have the thread call iio_trigger_poll_chained()
after determining that is is the proper source of the
interrupt. This is modelled on drivers/iio/accel/mma8452.c
which is already using a properly threaded interrupt handler.In order to get the same precision in timestamps as
previously, where samples would be timestamped in the
poll function pf->timestamp when calling
iio_trigger_generic_data_rdy_poll() we introduce a
local timestamp in the sensor data, set it in the top half
(fastpath) of the interrupt handler and provide that to the
core when calling iio_push_to_buffers_with_timestamp().Additionally: if the active scanmask is not set for the
sensor no IRQs should be enabled and we need to bail out
with IRQ_NONE. This can happen if spurious IRQs fire when
installing the threaded interrupt handler.Tested with hard interrupt triggers on LIS331DL, then also
tested with hrtimers on the same sensor by creating a 75Hz
HRTimer and using it to poll the sensor.Signed-off-by: Linus Walleij
Cc: Giuseppe Barba
Cc: Denis Ciocca
Reported-by: Crestez Dan Leonard
Tested-by: Crestez Dan Leonard
Tested-by: Jonathan Cameron
Fixes: 97865fe41322 ("iio: st_sensors: verify interrupt event to status")
Signed-off-by: Jonathan Cameron
29 May, 2016
3 commits
-
Ensure failure to enable power regulators is properly handled.
Signed-off-by: Gregor Boirie
Signed-off-by: Jonathan Cameron -
Use SMBus "block read" protocol only when supported by adapter.
Signed-off-by: Gregor Boirie
Signed-off-by: Jonathan Cameron -
Remove st_sensors_get_buffer_element symbol export since not explicitly
used outside of st_sensors driver.Signed-off-by: Gregor Boirie
Signed-off-by: Jonathan Cameron
20 Apr, 2016
3 commits
-
Some types of ST Sensors can be connected to the same IRQ line
as other peripherals using open drain. Add a device tree binding
and a sensor data property to flip the right bit in the interrupt
control register to enable open drain mode on the INT line.If the line is set to be open drain, also tag on IRQF_SHARED
to the IRQ flags when requesting the interrupt, as the whole
point of using open drain interrupt lines is to share them with
more than one peripheral (wire-or).Cc: devicetree@vger.kernel.org
Cc: Giuseppe Barba
Cc: Denis Ciocca
Acked-by: Rob Herring
Signed-off-by: Linus Walleij
Signed-off-by: Jonathan Cameron -
This makes all ST sensor drivers check that they actually have
new data available for the requested channel(s) before claiming
an IRQ, by reading the status register (which is conveniently
the same for all ST sensors) and check that the channel has new
data before proceeding to read it and fill the buffer.This way sensors can share an interrupt line: it can be flaged
as shared and then the sensor that did not fire will return
NO_IRQ, and the sensor that fired will handle the IRQ and
return IRQ_HANDLED.Cc: Giuseppe Barba
Cc: Denis Ciocca
Signed-off-by: Linus Walleij
Signed-off-by: Jonathan Cameron -
The current buffer read code tries to optimize reads from the
sensor data registers by issuing a single read operation across
all the indata registers.This doesn't work: when the LIS331DL accelerometer sensor is
configured to open drain, active low interrupt mode, this will
just clear the XDA (X-axis data available) bit in the STATUS_REG
register (0x27), while YDA, ZDA and even ZYXDA remain set to 1,
and the internal logic of the sensor holds the DRDY (INT1) line
asserted (the value of the status register is 0xee).If we instead issue one read operation per enabled channel
(X, Y, Z) things start working and we can use open drain and
active low interrupts.Note that a backported patch fixing this issue will be heading
via the fixes branch but changes in this file already in staging-next
will make that patch 'look' rather different. The code in here
is the correct one when that clash hits.Cc: Giuseppe Barba
Cc: Denis Ciocca
Signed-off-by: Linus Walleij
Signed-off-by: Jonathan Cameron
16 Apr, 2016
2 commits
-
This fixes the error reported by checkpatch.pl:
ERROR: code indent should use tabs where possible
Signed-off-by: Slawomir Stepien
Signed-off-by: Jonathan Cameron -
This fixes the error reported by checkpatch.pl:
ERROR: code indent should use tabs where possible
Signed-off-by: Slawomir Stepien
Signed-off-by: Jonathan Cameron
28 Mar, 2016
1 commit
-
The driver goes to some length to dynamically allocate an array
to hold the channel addresses. However no ST sensor has more than
three channels (x, y, z at most). Instead of kmalloc():ing and
kfree():in the address array, just use a fixed array of three
elements.Cc: Giuseppe Barba
Signed-off-by: Linus Walleij
Acked-by: Denis Ciocca
Signed-off-by: Jonathan Cameron
10 Jan, 2016
1 commit
-
Most ST MEMS Sensors that support interrupts can also handle sending
an active low interrupt, i.e. going from high to low on data ready
(or other interrupt) and thus triggering on a falling edge to the
interrupt controller.Set up logic to inspect the interrupt line we get for a sensor: if
it is triggering on rising edge, leave everything alone, but if it
triggers on falling edges, set up active low, and if unsupported
configurations appear: warn with errors and reconfigure the interrupt
to a rising edge, which all interrupt generating sensors support.Create a local header for st_sensors_core.h to share functions
between the sensor core and the trigger setup code.Cc: Giuseppe Barba
Cc: Denis Ciocca
Signed-off-by: Linus Walleij
Signed-off-by: Jonathan Cameron
06 Dec, 2015
1 commit
-
Definition of ST_SENSORS_WAI_ADDRESS was introduced within a very
first commit of this driver, but it was never used.
This address is already defined as ST_SENSORS_DEFAULT_WAI_ADDRESS
in include/linux/iio/common/st_sensors.hTo avoid duplication of the same constant in two different places
called almost exactly the same, the one which was never used
should be removed.Signed-off-by: Robert Kmiec
Signed-off-by: Jonathan Cameron
06 Nov, 2015
1 commit
-
Pull spi updates from Mark Brown:
"Quite a lot of activity in SPI this cycle, almost all of it in drivers
with a few minor improvements and tweaks in the core.- Updates to pxa2xx to support Intel Broxton and multiple chip selects.
- Support for big endian in the bcm63xx driver.
- Multiple slave support for the mt8173
- New driver for the auxiliary SPI controller in bcm2835 SoCs.
- Support for Layerscale SoCs in the Freescale DSPI driver"* tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (87 commits)
spi: pxa2xx: Rework self-initiated platform data creation for non-ACPI
spi: pxa2xx: Add support for Intel Broxton
spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals
spi: pxa2xx: Add output control for multiple Intel LPSS chip selects
spi: pxa2xx: Use LPSS prefix for defines that are Intel LPSS specific
spi: Add DSPI support for layerscape family
spi: ti-qspi: improve ->remove() callback
spi/spi-xilinx: Fix race condition on last word read
spi: Drop owner assignment from spi_drivers
spi: Add THIS_MODULE to spi_driver in SPI core
spi: Setup the master controller driver before setting the chipselect
spi: dw: replace magic constant by DW_SPI_DR
spi: mediatek: mt8173 spi multiple devices support
spi: mediatek: handle controller_data in mtk_spi_setup
spi: mediatek: remove mtk_spi_config
spi: mediatek: Update document devicetree bindings to support multiple devices
spi: fix kernel-doc warnings about missing return desc in spi.c
spi: fix kernel-doc warnings about missing return desc in spi.h
spi: pxa2xx: Align a few defines
spi: pxa2xx: Save other reg_cs_ctrl bits when configuring chip select
...
28 Oct, 2015
1 commit
-
An spi_driver does not need to set an owner, it will be populated by the
driver core.Signed-off-by: Andrew F. Davis
Acked-by: Jonathan Cameron
Signed-off-by: Mark Brown
13 Oct, 2015
1 commit
-
This patch changes various types to the appropriate endian specific
versions. Also introduces an additional local variable to avoid
a single variable being used for both be and cpu endianness.These aren't bugs as such, but clearing them up does make the code
clearer.Warning was:
sparse warnings: (new ones prefixed by >>)>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: sparse: incorrect type in assignment (different base types)
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: expected unsigned short [unsigned] [addressable] [usertype] send_buf
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: got restricted __be16 [usertype]
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: sparse: incorrect type in assignment (different base types)
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: expected unsigned short [unsigned] [addressable] [usertype] send_buf
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: got restricted __be16 [usertype]
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64Reported-by: kbuild test robot
Signed-off-by: Jonathan Cameron
04 Oct, 2015
1 commit
-
Measurement specialties drivers common part.
These functions are used by further drivers
in the patchset: TSYS01, TSYS02D, HTU21, MS5637, MS8607Signed-off-by: Ludovic Tancerel
Signed-off-by: Jonathan Cameron
16 Aug, 2015
1 commit
-
This adds a debugfs hook to read/write registers in the ST
sensors using debugfs. Proved to be awesome help when trying
to debug why IRQs do not arrive.Signed-off-by: Linus Walleij
Acked-by: Denis Ciocca
Signed-off-by: Jonathan Cameron
13 Aug, 2015
1 commit
-
…3/iio into staging-next
Jonathan writes:
Second set of new device support, features and cleanup for the 4.3 cycle.
Take 2 also includes a fix set that was too late for the 4.2 cycle.As we had a lot of tools and docs work in this set, I have broken those
out into their own categories in this description.Fixes from the pull request '4th set of IIO fixes for the 4.2 cycle'.
* Poll functions for both event chardev and the buffer one were returning
negative error codes (via a positive value).
* A recent change to lsiio adding some error handling that was wrong and
stopped the tool working.
* bmg160 was missing some dependencies in Kconfig
* berlin2-adc had a misshandled register (wrote a value rather than a bitmap)New device support
* TI opt3001 light sensor
* TXC PA12 ALS and proximity sensor.
* mcp3301 ADC support (in mcp320x driver)
* ST lsm303agr accelerometer and magnetometer drivers (plus some st-sensors
common support to allow different WHOAMI register addresses, devices with
fixed scale and allow interrupt equiped magnetometers).
* ADIS16305, ADIS16367, ADIS16445IMUs (in the adis16400 driver)
* ADIS16266 gyro (in the adis16260 driver)
* ADIS16137 gyro (in the adis16136 driver)New functionality
* mmc35240 DT bindings.
* Inverse unit conversion macros to aid handing of values written to sysfs
attributes.Core cleanup
* Forward declaration of struct iio_trigger to avoid a compile warning.Driver cleanup / fixes
* mxs-lradc
- Clarify which parts are supported.
- Fix spelling erorrs.
- Missing/extra includes
- reorder includes
- add datasheet name listings for all usable channels (to allow them
to be bound by name from consumer drivers)
* acpi-als - add some function prefixes as per general iio style.
* bmc150_magn - replace a magic value with the existing define.
* vf610 - determine possible sample frequencies taking into account the
electrical characteristics (defining a minimum sample time)
* dht11
- whitespace
- additional docs
- avoid mulitple assignments in one line
- Use the new funciton ktime_get_resolution_ns to cleanup a nasty trick
previously used for timing.
* Fix all drivers that consider 0 a valid IRQ for historical reasons.
* Export I2C module alias info where previously missing (to allow autoprobing)
* Export OF module alias info where previously missing.
* mmc35240 - switch some variables into arrays to improve readability.
* mlx90614 - define some magic numbers for readability.
* bmc150_magn
- expand area locked by a mutex to cover all the use of the
data->buffer.
- use descriptive naming for a mask instead of a magic value.
* berin2-adc
- pass up an error code rather that a generic error
- constify the iio_chan_spec
- some other little tidy ups.
* stk8312
- fix a dependency on triggered buffers in kconfig
- add a check for invalid attribute values
- improve error handling by returning error codes where possible and
return immediately where relevant
- rework macro defs to use GENMASK etc
- change some variable types to reduce unnecessary casting
- clean up code style
- drop a local buffer copy for bulk reads and use the one in data->buffer
instead.
* adis16400 - the adis16448 gyroscope scale was wrong.
* adis16480 - some more wrong scales for various parts.
* adis16300 - has an undocumented product id and serial number registers so
use them.
* iio_simple_dummy - fix some wrong code indentation.
* bmc150-accel - use the chip ID to detect the chip present rather than
verifying the expected part was there. This was in response to a wrong
ACPI entry on the WinBook TW100.
* mma8452
- fix _get_hp_filter_index
- drop a double include
- pass up an error code rather than rewriting it
- range check input values to attribute writes
- register defs tidy up using GENMASK and reordering them to be easier to
follow.
- various coding style cleanups
- put the Kconfig entry in the write place (alphabetically).Tools related
* Tools cleanup - drop an explicity NULL comparison, some unnecessary braces,
use the ARRAY_SIZE macro, send error messages to stderr instead of dropping
them in the middle of normal output.
* Fix tools to allow that scale and offset attributes are optional.
* More tools fixes including allowing true 32bit data (previously an overflow
prevented more than 31bits)
* Drop a stray header guard that ended up in a c file.
* Make calc_digits static as it isn't exported or in the header.
* Set ci_array pointer to NULL after free as a protection against non safe
usage of the tools core code. Also convert a double pointer to a single
one as the extra level of indirection was unnecessary.Docs
* DocBook introduction by Daniel Baluta. Glad we are beginning to
draw together some more introductory docs to suplement the various
tools / examples.
* Drop bytes_per_datum sysfs attribute docs as it no longer exists.
* A whole load of missing / fixing of kernel-doc for the core of IIO.
* Document the trigger name sysfs attribute in the ABI docs.
* Minor typos in the ABI docs related to power down modes.
24 Jul, 2015
2 commits
-
Some sensors could have only one full scale value. This means that the
sensor hasn't a full scale register. This commit add a check on the
configured full scale address to support such kind of sensors.Signed-off-by: Giuseppe Barba
Acked-by: Denis Ciocca
Signed-off-by: Jonathan Cameron -
This patch permits to configure the WhoAmI register address
because some device could have not a standard address for
this register.Signed-off-by: Giuseppe Barba
Reviewed-by: Denis Ciocca
Acked-by: Denis Ciocca
Signed-off-by: Jonathan Cameron
