Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 9月, 2016 5 次提交
  3. 25 9月, 2016 1 次提交
  5. 24 9月, 2016 2 次提交
  7. 23 9月, 2016 1 次提交
    • A
      iio:pressure: zpa2326: remove redundant "DEBUG" ifdef · 59dc1c86
      由 Arnd Bergmann 提交于 
      The -Wempty-body gcc warning triggers in the newly added zpa2326 driver:

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

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

Fixing this also simplifies the driver.

Fixes: 03b262f2 ("iio:pressure: initial zpa2326 barometer support")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      59dc1c86
  9. 19 9月, 2016 2 次提交
  11. 18 9月, 2016 19 次提交
  13. 13 9月, 2016 1 次提交
    • H
      iio: accel: mxc6255: Fix chip-id check · 1696566f
      由 Hans de Goede 提交于 
      The initial commit adding support for the mxc6225 assumed the
mxc6225 has a chip-id of 0xe5 based on testing on a single Allwinner
A23 tablet with a mxc6225. Testing on a bunch of other Allwinner
tablets have shown that the chip-id for the mxc6225 is not constant.

A datasheet for the MXC6255 which I've found online says that bits
7 and 6 of the chip-id register are undefined (for the mxc6255), testing
on 5 different tablets with a mxc6225 has found the following ids:
0x25, 0x45, 0x65, 0x85, 0xe5. So it seems that for the mxc6225 bits
7, 6 and 5 of the chip-id register are undefined.

This commit adjusts the chip-id check so that the mxc6255 driver
properly recognizes the mxc6225 in all these tablets.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      1696566f
  15. 10 9月, 2016 3 次提交
    • L
      iio: st_sensors: use the helper function · 7ba4b884
      由 Linus Walleij 提交于 
      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 <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      7ba4b884
    • L
      iio: trigger: helpers to determine own trigger · 702a7b8e
      由 Linus Walleij 提交于 
      This adds a helper function to the IIO trigger framework:

iio_trigger_using_own(): for an IIO device, this tells
  whether the device is using itself as a trigger.
  This is true if the indio device:
  (A) supplies a trigger and
  (B) has assigned its own buffer poll function to use this
      trigger.

This helper function is good when constructing triggered,
buffered drivers that can either use its own hardware *OR*
an external trigger such as a HRTimer or even the trigger from
a totally different sensor.

Under such circumstances it is important to know for example
if the timestamp from the same trigger hardware should be used
when populating the buffer: if iio_trigger_using_own() is true,
we can use this timestamp, else we need to pick a unique
timestamp directly in the trigger handler.

For this to work of course IIO devices registering hardware
triggers must follow the convention to set the parent device
properly, as as well as setting the parent of the IIO device
itself.

When a new poll function is attached, we check if the parent
device of the IIO of the poll function is the same as the
parent device of the trigger and in that case we conclude that
the hardware is using itself as trigger.

Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      702a7b8e
    • L
      iio: iio_push_event(): Don't crash if the event interface is not registered · 4b1a9380
      由 Lars-Peter Clausen 提交于 
      iio_push_event() operates on a struct iio_dev. This struct can be allocated
using iio_device_alloc() which returns a valid struct iio_dev pointer. But
iio_push_event() is not safe to use on such a iio_dev until
iio_device_register() for the same device has successfully completed.

This restriction is not documented anywhere and most drivers are written
with the assumption that this restriction does not exist. The basic pattern
that is followed by all drivers looks like the following:

	irqreturn_t event_callback(int irq, void *devid)
	{
		struct iio_dev *indio_dev = devid;
		...
		iio_push_event(indio_dev, ...);

		return IRQ_HANDLED;
	}

	int driver_probe(struct device *dev)
	{
		struct iio_dev *indio_dev;

		indio_dev = iio_device_alloc(...);

		request_irq(event_irq, event_callback, ..., indio_dev);

		return iio_device_register(indio_dev);
	}

And while it is unlikely that the IRQ fires before iio_device_register()
completes (e.g. because the IRQ is disabled in the device) it is not
impossible and might be triggered by glitches on the signal line or
incorrect hardware configuration.

To avoid undefined behaviour in such a case extend iio_push_event() to
check if the event has been registered and discard generated events if it
has not.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      4b1a9380
  17. 06 9月, 2016 6 次提交