IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
drivers/built-in.o: In function `gp2ap020a00f_thresh_event_handler':
powercap_sys.c:(.text+0x15f90c): undefined reference to `irq_work_queue'
make[1]: *** [vmlinux] Error 1
make[1]: Target `uImage' not remade because of errors.
make: *** [sub-make] Error 2
make: Target `uImage' not remade because of errors.
You need the IRQ work support, but GP2AP020A00F is not selecting this
symbol.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In the original HID sensor hub firmwares all Named array enums were
to 0-based. But the most recent hub implemented as 1-based,
because of the implementation by one of the major OS vendor.
Using logical minimum for the field as the base of enum. So we add
logical minimum to the selector values before setting those fields.
Some sensor hub FWs already changed logical minimum from 0 to 1
to reflect this and hope every other vendor will follow.
There is no easy way to add a common HID quirk for NAry elements,
even if the standard specifies these field as NAry, the collection
used to describe selectors is still just "logical".
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The usual mixed bag of fixes.
* 3 cases where kconfig dependencies were missing. We need to keep a closer
eye on this in new drivers.
* hid_sensors was abusing the iio_dev->trigger pointer. We had a round
of clearing this out some time ago but this driver clearly slipped through.
* A misuse of the IIO_ST macro, in mcp3422, which we should really make a
concertive effort to finish removing.
* Avoid a double free introduced by recent buffer reference counting in the
one driver that (quite reasonably!) does things differently (am335x)
* A missing mutex_unlock in kxsd9 that means that driver has been non
functional for some time and no one noticed (including me who for once
actually has one of the supported devices).
* An incorrect assumption about the parameters of sign_extend32 in mcp3422.
So nothing controversial. The only substantial patch is the hid_sensors
one and that is actually just adding a new pointer to the devices private
state then moving the code over to it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJSk7SvAAoJEFSFNJnE9BaIRNsQAJnM/WiH1ghfA5nuc0V7JrnB
2Z6Qtm3Stoq4Ul5LYiEMxumo6ckL17YFddxejUF9X4Eq5N8YyAxdPd8JdDJgS2OL
yCM2x6izd9drIGA3YUMMOvZ1BScSK1e5DmXJHp4nuF68uHtf2TM4TGF/2zuqt3TN
2bL7blNF3/5O/TiBRB4XjkH4Sy5c4G2kke+0SckRnWohTn8oE7tWihr84nYPciqt
mu11Nrv9S+sr/5GzRwN8d5SU33yU2/ML32QU/4oQzb/XxBW0W759NJflqY5sSZ89
JQnHcCKKZD7IWBFT0VAMiuEjBpSRGc4vxBbYjsVHtEHzW7v3L0fvob5YqfSrzMlD
rVUiTQJm7fC/4hn7iJUPrxkWsSGsjCvVrLZmZFOK3OYONUfd+Cqg0nliihRZo65s
054/yi4v8xd6OUzqSxtWKIK/ZQjDxa5W2BlRoryShCrUAo/e3Djy+jH32v4Mmgfe
D9aEwdUqa8kPlq6pyQC2QRgWWU1K5+RRrzW5nNNLlmjYtVlfF+8OgcQYGHW8iMur
8AaDXNZwQLEYA4409T/Ar9lNg4gDqc0YZsvNibu0q4Kxfp13dJOwra+xmF+ktECr
KcIFxu5v89SgpE1Rra74OXYFWQ1I4Qy+sJxhQKymthPzmw4nuUidK33mxjtcojwz
TvQJu8f3us8Ea5vQLZo0
=cIMc
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-3.13a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First round of fixes for IIO in the 3.13 cycle.
The usual mixed bag of fixes.
* 3 cases where kconfig dependencies were missing. We need to keep a closer
eye on this in new drivers.
* hid_sensors was abusing the iio_dev->trigger pointer. We had a round
of clearing this out some time ago but this driver clearly slipped through.
* A misuse of the IIO_ST macro, in mcp3422, which we should really make a
concertive effort to finish removing.
* Avoid a double free introduced by recent buffer reference counting in the
one driver that (quite reasonably!) does things differently (am335x)
* A missing mutex_unlock in kxsd9 that means that driver has been non
functional for some time and no one noticed (including me who for once
actually has one of the supported devices).
* An incorrect assumption about the parameters of sign_extend32 in mcp3422.
So nothing controversial. The only substantial patch is the hid_sensors
one and that is actually just adding a new pointer to the devices private
state then moving the code over to it.
This will leave a lock held after reading from the device, preventing
any further reads.
Signed-off-by: Frank Zago <frank@zago.net>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch enhances the type safety for the kfifo API. It is now safe
to put const data into a non const FIFO and the API will now generate a
compiler warning when reading from the fifo where the destination
address is pointing to a const variable.
As a side effect the kfifo_put() does now expect the value of an element
instead a pointer to the element. This was suggested Russell King. It
make the handling of the kfifo_put easier since there is no need to
create a helper variable for getting the address of a pointer or to pass
integers of different sizes.
IMHO the API break is okay, since there are currently only six users of
kfifo_put().
The code is also cleaner by kicking out the "if (0)" expressions.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Stefani Seibold <stefani@seibold.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use this new function to make code more comprehensible, since we are
reinitialzing the completion, not initializing.
[akpm@linux-foundation.org: linux-next resyncs]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13)
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The driver is missing the iio_buffer_attach() call. As such it will attempt
to free the buffer twice on removal.
Introduced in commit 9e69c9 ("iio: Add reference counting for buffers").
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
the index argument to sign_extend32() gives the bit position (from 0)
to the sign bit
so e.g. if the measurement has 16-bit resolution, we need to pass 15;
a measurement of 0x8000 should be reported as -32768, not 32768
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Acked-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We can't store the trigger instance created by iio_trigger_alloc, in
trig field of iio_device structure. This needs to be stored in the
driver private data. Othewise it can result in crash during module
unload. Hence created a trig_ptr in the common data structure
for each HID sensor IIO driver and storing here.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fix to return -ENODEV instead of 0 if non-TSMR adc don't
support, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The if check is redundant as the value obtained from
iio_device_register() is already in the required format.
Hence return the function directly.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Remove an inconsequential print message and return directly
thereby cleaning up some code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The if check is redundant as the value obtained from
iio_device_register() is already in the required format.
Error messages are already printed by iio_device_register();
hence not needed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The if check is redundant as the value obtained from
iio_device_register() is already in the required format.
Hence return the function directly. Error messages are already
printed by iio_device_register(); hence not needed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The if check is redundant as the value obtained from
iio_device_register() is already in the required format.
Hence return the function directly.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Silences the following checkpatch warning:
WARNING: sizeof *iio_attr should be sizeof(*iio_attr)
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
ti_adc_dt_ids is always compiled in. Hence of_match_ptr is not
needed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
nau7802_dt_ids is always compiled in. Hence of_match_ptr is not
needed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
of_twl6030_match_tbl is always compiled in. Hence of_match_ptr is
not necessary.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The driver currently supports only I2C access. But supported devices with an
accuracy of 8-bit are compatible with the SMBus byte access routines.
This patch wraps the send and receive routines depending on the chip
accuracy and fonctionnalities of its adapter.
For instance, this allows us to use a MAX11603 on a ICH7 controller.
This patch also simplifies the max1363_write_basic_config() routine to
use the struct max1363_state fields directly.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
this just fixes the comment; however, I'm not sure if the driver reports
measurements correctly; the raw values are 0.3 uT / LSB; IIO is supposed
to report magnetic fields in Gauss, so the scale should be around 1/300
(ignoring ASA) -- but value and scale are returned as VAL_INT
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
'of_match_ptr' is defined in linux/of.h. Include it explicitly to
avoid build breakage in the future.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
'of_match_ptr' is defined in linux/of.h. Include it explicitly to
avoid build breakage in the future.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
'of_match_ptr' is defined in linux/of.h. Include it explicitly to
avoid build breakage in the future.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
'of_match_ptr' is defined in linux/of.h. Include it explicitly to
avoid build breakage in the future.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
AT91 ADC hardware integrate touch screen support. So this patch add touch
screen support for at91 adc iio driver.
To enable touch screen support in adc, you need to add the dt parameters:
1. which type of touch are used? (4 or 5 wires), sample period time.
2. correct pressure detect threshold value.
In the meantime, since touch screen will use a interal period trigger of adc,
so it is conflict to other hardware triggers. Driver will disable the hardware
trigger support if touch screen is enabled.
This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: devicetree@vger.kernel.org
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch adds a new driver for Capella CM36651 proximity and RGB sensor.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The functionality implemented by iio_sw_buffer_preenable() is now done directly
in the IIO core and previous users of iio_sw_buffer_preenable() have all been
updated to not use it anymore. It is unused now and can be remove.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core,
so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core,
so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core,
so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core,
so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core,
so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer
core, so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Zubair Lutfullah <zubair.lutfullah@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core,
so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core,
so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core,
so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core,
so there is no need to do this from the driver anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Currently a IIO device driver needs to make sure to update the buffer's bytes
per datum after the scan mask has changed. This is usually done in the preenable
callback by invoking iio_sw_buffer_preenable(). This is something that needs to
be done and is done for virtually all devices which support buffers (we
currently have only one exception). Also this a bit of a layering violation
since we have to call the buffer setup ops from the device setup ops. This
requires the device driver to know about the internal requirements of the buffer
(e.g. whether we need to call the set_bytes_per_datum) callback. And especially
with in-kernel buffer consumers, which allows to attach arbitrary buffers to a
device, this is something that the driver can't know.
Moving this to the core allows us to drop the individual calls to
iio_sw_buffer_preenable() from drivers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Denis Ciocca <denis.ciocca@st.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Zubair Lutfullah <zubair.lutfullah@gmail.com>
Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Usually the active scan mask is freed in __iio_update_buffers() when the buffer
is disabled. But when the device is still sampling when it is removed we'll end
up disabling the buffers in iio_disable_all_buffers(). So we also need to free
the active scan mask here, otherwise it will be leaked.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
update_needed is used to decide whether the kfifo buffer needs to be
re-allocated. It is set to true whenever the size of the buffer is changed. It
is never set to false though, causing the buffer to always be re-allocated.
Setting update_needed to false after the new buffer has been allocated fixes the
problem.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
