#
5291fed7 |
|
31-Dec-2023 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio: light: max44000: drop ACPI_PTR() and CONFIG_ACPI guards The complexity of config guards needed for ACPI_PTR() is not worthwhile for the small amount of saved data. This example was doing it correctly but I am proposing dropping this so as to reduce chance of cut and paste where it is done wrong. Also drop now unneeded linux/acpi.h include and added linux/mod_devicetable.h for struct acpi_device_id definition. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-24-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
7cf15f42 |
|
15-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
iio: Switch i2c drivers back to use .probe() After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230515205048.19561-1-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
0978ef36 |
|
18-Nov-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
iio: light: max44000: Convert to i2c's .probe_new() The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221118224540.619276-132-uwe@kleine-koenig.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
2b025c92 |
|
13-Sep-2021 |
Alexandru Ardelean <aardelean@deviqon.com> |
iio: light: max44000: use device-managed functions in probe This is a simple conversion. Both iio_device_register() and iio_triggered_buffer_setup() functions have device-managed variants. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210913120002.306280-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
52362885 |
|
22-Jul-2020 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio:light:max44000 Fix timestamp alignment and prevent data leak. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc so no data can leak appart from previous readings. It is necessary to force the alignment of ts to avoid the padding on x86_32 being different from 64 bit platorms (it alows for 4 bytes aligned 8 byte types. Fixes: 06ad7ea10e2b ("max44000: Initial triggered buffer support") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: <Stable@vger.kernel.org>
|
#
d3be8324 |
|
22-May-2020 |
Alexandru Ardelean <alexandru.ardelean@analog.com> |
iio: remove explicit IIO device parent assignment This patch applies the semantic patch: @@ expression I, P, SP; @@ I = devm_iio_device_alloc(P, SP); ... - I->dev.parent = P; It updates 302 files and does 307 deletions. This semantic patch also removes some comments like '/* Establish that the iio_dev is a child of the i2c device */' But this is is only done in case where the block is left empty. The patch does not seem to cover all cases. It looks like in some cases a different variable is used in some cases to assign the parent, but it points to the same reference. In other cases, the block covered by ... may be just too big to be covered by the semantic patch. However, this looks pretty good as well, as it does cover a big bulk of the drivers that should remove the parent assignment. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
36edc939 |
|
29-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 330 Based on 1 normalized pattern(s): this file is subject to the terms and conditions of version 2 of the gnu general public license see the file copying in the main directory of this archive for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 55 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000436.108941081@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1c96a2f6 |
|
01-Sep-2018 |
David Frey <dpfrey@gmail.com> |
regmap: split up regmap_config.use_single_rw Split regmap_config.use_single_rw into use_single_read and use_single_write. This change enables drivers of devices which only support bulk operations in one direction to use the regmap_bulk_*() functions for both directions and have their bulk operation split into single operations only when necessary. Update all struct regmap_config instances where use_single_rw==true to instead set both use_single_read and use_single_write. No attempt was made to evaluate whether it is possible to set only one of use_single_read or use_single_write. Signed-off-by: David Frey <dpfrey@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
eb2e1888 |
|
09-Aug-2018 |
Colin Ian King <colin.king@canonical.com> |
iio: max44000: remove unused variable max44000_alstim_shift Variable max44000_alstim_shift is defined but is never used hence it is redundant and can be removed. This variable has been like this since the driver was added back in 2016. Cleans up clang warning: warning: 'max44000_alstim_shift' defined but not used [-Wunused-const-variable=] Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
4166b47c |
|
23-Jul-2017 |
Jonathan Cameron <jic23@kernel.org> |
iio:light: drop assign iio_info.driver_module and iio_trigger_ops.owner The equivalent of both of these are now done via macro magic when the relevant register calls are made. The actual structure elements will shortly go away. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
#
b4e8a0eb |
|
28-Dec-2016 |
Akinobu Mita <akinobu.mita@gmail.com> |
iio: max44000: correct value in illuminance_integration_time_available According to the datasheet, the shortest available integration time for ALS ADC conversion is 1.5625ms but illuminance_integration_time_available sysfs file shows wrong value. Cc: Crestez Dan Leonard <leonard.crestez@intel.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Fixes: d5d8f49b6 ("max44000: Expose ambient sensor scaling") Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
2a20af72 |
|
24-Sep-2016 |
Sandhya Bankar <bankarsandhya512@gmail.com> |
drivers: iio: light: Fix sparse warnings Fixing below warnings: drivers/iio/light/max44000.c:217:18: warning: cast to restricted __be16 drivers/iio/light/max44000.c:217:18: warning: cast to restricted __be16 drivers/iio/light/max44000.c:217:18: warning: cast to restricted __be16 drivers/iio/light/max44000.c:217:18: warning: cast to restricted __be16 Signed-off-by: Sandhya Bankar <bankarsandhya512@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
bc2b7dab |
|
09-Mar-2016 |
Gregor Boirie <gregor.boirie@parrot.com> |
iio:core: timestamping clock selection support 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 <gregor.boirie@parrot.com> Acked-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
14f2461b |
|
20-May-2016 |
Crestez Dan Leonard <leonard.crestez@intel.com> |
max44000: Remove scale from proximity This is not implemented and doesn't really make sense because IIO proximity is unit-less. Remove IIO_CHAN_INFO_SCALE from info_mask because so that the _scale sysfs entry won't appear. This fixes userspace tools like generic_buffer which abort when reads returns an error. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
06ad7ea1 |
|
18-Apr-2016 |
Crestez Dan Leonard <leonard.crestez@intel.com> |
max44000: Initial triggered buffer support Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
d5d8f49b |
|
18-Apr-2016 |
Crestez Dan Leonard <leonard.crestez@intel.com> |
max44000: Expose ambient sensor scaling This patch exposes ALSTIM as illuminance_integration_time and ALSPGA as illuminance_scale. Changing ALSTIM also changes the number of bits available in the data register. This is handled inside raw value reading because: * It's very easy to shift a few bits * It allows SCALE and INT_TIME to be completely independent controls * Buffer support requires constant scan_type.realbits per-channel Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
237a378b |
|
18-Apr-2016 |
Crestez Dan Leonard <leonard.crestez@intel.com> |
max44000: Support controlling LED current output This is exposed as an output channel with "led" as an extend_name. Other sensors also have support for controlling an external LED. It's not clear that simply exposing an undecorated output channel is the correct approach. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
35b651f3 |
|
18-Apr-2016 |
Crestez Dan Leonard <leonard.crestez@intel.com> |
max44000: Initial support for proximity reading The proximity sensor relies on sending pulses to an external IR led and it is disabled by default on powerup. The driver will enable it with a default power setting. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
b9567e66 |
|
18-Apr-2016 |
Crestez Dan Leonard <leonard.crestez@intel.com> |
max44000: Initial support This just adds support for reporting illuminance with default settings. Important default registers are written on probe because the device otherwise lacks a reset function. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|