- 17 Feb, 2024 27 commits
-
-
Lorenzo Bianconi authored
Add support to STM ASM330LHHXG1 (accelerometer and gyroscope) Mems sensor. The ASM330LHHXG1 sensor can use LSM6DSR as fallback device since LSM6DSR implements all the ASM330LHHXG1 features currently implemented in st_lsm6dsx. Link: https://www.st.com/resource/en/datasheet/asm330lhhxg1.pdfSigned-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/e3dbe4720cdf407d0152e93b1331306a8c7f5df3.1706961432.git.lorenzo@kernel.orgSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Lorenzo Bianconi authored
Improve kernel docs and comments reporting supported sensors in a list in order to make more easy to add new devices in the future. Signed-off-by:
-
Jonathan Cameron authored
Done to reduce boilerplate and simplify code flow by allowing early returns with the lock automatically released. Reviewed-by:
Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-11-jic23@kernel.orgSigned-off-by:
-
Jonathan Cameron authored
Reduces boilerplate and allows for simpler to follow direct returns. Reviewed-by:
-
Jonathan Cameron authored
This simplifies error handling paths and generallly removes a bunch of boilerplate. Reviewed-by:
-
Jonathan Cameron authored
This simplifies error handling paths and generallly removes a bunch of boilerplate. Reviewed-by:
-
Jonathan Cameron authored
This simplifies error handling paths and generallly removes a bunch of boilerplate. Reviewed-by:
-
Jonathan Cameron authored
This simplifies error return paths. Reviewed-by:
-
Jonathan Cameron authored
Similar to existing use of guard() in this driver, iio_device_claim_direct_scoped() will ensure that scope based cleanup occurs. Reviewed-by:
-
Jonathan Cameron authored
Switching to the iio_device_claim_direct_scoped() for state and to guard() based unlocking of mutexes simplifies error handling by allowing direct returns when an error is encountered. Reviewed-by:
-
Jonathan Cameron authored
Given we now have iio_device_claim_direct_scoped() to perform automatic releasing of direct mode at exit from the scope that follows it, this can be used in conjunction with guard(mutex) etc remove a lot of special case handling. Note that in this particular example code, there is no real reason you can't read channels via sysfs at the same time as filling the software buffer. To make it look more like a real driver constrain raw and processed channel reads from occurring whilst the buffer is in use. Reviewed-by:
David Lechner <dlechner@baylibre.com> Reviewed-by:
-
Jonathan Cameron authored
Allows use of: iio_device_claim_direct_scoped(return -EBUSY, indio_dev) { } to automatically call iio_device_release_direct_mode() based on scope. Typically seen in combination with local device specific locks which are already have automated cleanup options via guard(mutex)(&st->lock) and scoped_guard(). Using both together allows most error handling to be automated. Reviewed-by: -
Justin Stitt authored
We're doing some needless string copies when trying to assign the proper `prop` string. We can make `prop` a const char* and simply assign to string literals. For the case where a format string is used, let's extract the parsing logic out into sx9324_parse_phase_prop(). We no longer need to create copies or allocate new memory. sx9324_parse_phase_prop() will simply return the default def value if it fails. This also cleans up some deprecated strncpy() uses [1]. Furthermore, let's clean up this code further by removing some unused defines: | #define SX9324_PIN_DEF "semtech,ph0-pin" | #define SX9324_RESOLUTION_DEF "semtech,ph01-resolution" | #define SX9324_PROXRAW_DEF "semtech,ph01-proxraw-strength" Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
Justin Stitt <justinstitt@google.com> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20240201-strncpy-drivers-iio-proximity-sx9324-c-v5-1-78dde23553bc@google.comSigned-off-by:
-
Nikita Mikhailevich authored
New ID was introduced by Chuwi on Minibook X 2023. Signed-off-by:
Nikita Mikhailevich <ermyril@gmail.com> Link: https://lore.kernel.org/r/20240201151848.1666245-1-ermyril@gmail.comSigned-off-by:
-
Kim Seer Paller authored
Dual microwave down converter module with input RF and LO frequency ranges from 0.5 to 32 GHz and an output IF frequency range from 0.1 to 8 GHz. It consists of a LNA, mixer, IF filter, DSA, and IF amplifier for each down conversion path. Signed-off-by:
Kim Seer Paller <kimseer.paller@analog.com> Link: https://lore.kernel.org/r/20240123081059.5746-2-kimseer.paller@analog.comSigned-off-by:
-
Kim Seer Paller authored
Dual microwave down converter module with input RF and LO frequency ranges from 0.5 to 32 GHz and an output IF frequency range from 0.1 to 8 GHz. It consists of a LNA, mixer, IF filter, DSA, and IF amplifier for each down conversion path. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240123081059.5746-1-kimseer.paller@analog.comSigned-off-by:
-
Andrew Davis authored
Use a device lifecycle managed IIO helper functions. This helps prevent mistakes like unregistering and freeing out of order in cleanup functions and forgetting to unregister and free on error paths. Signed-off-by:
Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123140918.215818-4-afd@ti.comSigned-off-by:
-
Andrew Davis authored
Use a device lifecycle managed action for regulator disable function. This helps prevent mistakes like unregistering out of order in cleanup functions and forgetting to unregister on error paths. Signed-off-by:
-
Andrew Davis authored
Use a device lifecycle managed IIO helper functions. This helps prevent mistakes like unregistering and freeing out of order in cleanup functions and forgetting to unregister and free on error paths. Signed-off-by:
-
Andrew Davis authored
Use a device lifecycle managed action for regulator disable function. This helps prevent mistakes like unregistering out of order in cleanup functions and forgetting to unregister on error paths. Signed-off-by:
-
Matti Vaittinen authored
Add undersigned as a maintainer for IIO GTS helper's KUnit tests. Signed-off-by:
Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/52c66fe2798192529738ac2ab98a27230a6ad8cd.1705328293.git.mazziesaccount@gmail.comSigned-off-by:
-
Matti Vaittinen authored
Some light sensors can adjust both the HW-gain and integration time. There are cases where adjusting the integration time has similar impact to the scale of the reported values as gain setting has. IIO users do typically expect to handle scale by a single writable 'scale' entry. Driver should then adjust the gain/time accordingly. It however is difficult for a driver to know whether it should change gain or integration time to meet the requested scale. Usually it is preferred to have longer integration time which usually improves accuracy, but there may be use-cases where long measurement times can be an issue. Thus it can be preferable to allow also changing the integration time - but mitigate the scale impact by also changing the gain underneath. Eg, if integration time change doubles the measured values, the driver can reduce the HW-gain to half. The theory of the computations of gain-time-scale is simple. However, some people (undersigned) got that implemented wrong for more than once. Hence some gain-time-scale helpers were introduced. Add some simple tests to verify the most hairy functions. Signed-off-by:
-
Mårten Lindahl authored
The vcnl4040/vcnl4200 proximity sensor defaults to 12 bit data resolution, but the chip also supports 16 bit data resolution, which is called proximity high definition (PS_HD). Make the vcnl4040/vcnl4200 proximity sensor use the high definition for all data readings. Please note that in order to preserve the 12 bit integer part of the in_proximity_raw output, the format is changed from integer to fixed point. Signed-off-by:
Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20231221-vcnl4000-ps-hd-v3-1-6dcc889372be@axis.comSigned-off-by:
-
Nuno Sa authored
Make sure we can specify the IRQ trigger type from firmware and drivers won't ignore it. In fact, this how it should be done but since someone might be already depending on the driver to hardcode the trigger type (and not specifying it in firmware), let's do it like this so there's no possible breakage. Signed-off-by:
Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240117-dev_sigma_delta_no_irq_flags-v1-2-db39261592cf@analog.comSigned-off-by:
-
Nuno Sa authored
There's no need to call both irq_get_irq_data() and irqd_get_trigger_type() as we already have an helper for that. This allows for code simplification. Signed-off-by:
-
Nuno Sa authored
There's no need to call both irq_get_irq_data() and irqd_get_trigger_type() as we already have an helper for that. This allows for code simplification. Signed-off-by:
-
Randy Dunlap authored
Drop kernel-doc comments for struct fields that were removed to prevent kernel-doc warnings: iio_dummy_evgen.c:43: warning: Excess struct member 'irq_sim' description in 'iio_dummy_eventgen' iio_dummy_evgen.c:43: warning: Excess struct member 'base' description in 'iio_dummy_eventgen' Fixes: 337cbeb2 ("genirq/irq_sim: Simplify the API") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20240121055005.20042-1-rdunlap@infradead.orgSigned-off-by:
-
- 23 Jan, 2024 13 commits
-
-
ChiYuan Huang authored
RTQ6053 and RTQ6059 are the same series of RTQ6056. The respective differences with RTQ6056 are listed below RTQ6053 - chip package type RTQ6059 - Reduce the pinout for vbus sensing pin - Some internal ADC scaling change Signed-off-by:
ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/3541207c4727e3a76b9a3caf88ef812a4d47b764.1704676198.git.cy_huang@richtek.comSigned-off-by:
-
ChiYuan Huang authored
Add compatible support for RTQ6053 and RTQ6059. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/c1abb261bb00846f456eb8fe9b5919f59f287c24.1704676198.git.cy_huang@richtek.comSigned-off-by:
-
Nuno Sa authored
Respect the @dev argument in devm_iio_dmaengine_buffer_setup() and bind the IIO DMA buffer lifetime to that device. For the only user of this function, the IIO parent device is the struct device being passed to the API so no real fix in here (just consistency with other IIO APIs). Signed-off-by:
-
David Lechner authored
This replaces use of individual buffer mode flags with INDIO_ALL_BUFFER_MODES in the iio_buffer_enabled() function. This simplifies the code and makes it robust in case of the addition of new buffer modes. Signed-off-by:
-
Amit Dhingra authored
File entry has driver/iio/adc two times. Fix the file entry Found by ./scripts/get_maintainer.pl --self-test=patterns Signed-off-by:
Amit Dhingra <mechanicalamit@gmail.com> Reviewed-by:
Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://lore.kernel.org/r/CAO=gReEUr4B+E2mQsSrncHf41f0A915SuoWgA522_2Ts-dZbSg@mail.gmail.comSigned-off-by:
-
Petre Rodan authored
Replace seekdir() with rewinddir() in order to fix a localized glibc bug. One of the glibc patches that stable Gentoo is using causes an improper directory stream positioning bug on 32bit arm. That in turn ends up as a floating point exception in iio_generic_buffer. The attached patch provides a fix by using an equivalent function which should not cause trouble for other distros and is easier to reason about in general as it obviously always goes back to to the start. https://sourceware.org/bugzilla/show_bug.cgi?id=31212Signed-off-by:
Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20240108103224.3986-1-petre.rodan@subdimension.roSigned-off-by:
-
Colin Ian King authored
The variable period is being initialized with a value that is never read, it is being re-assigned a new value later on before it is read. The initialization is redundant and can be removed. Cleans up clang scan build warning: Value stored to 'period' during its initialization is never read [deadcode.DeadStores] Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Acked-by:
Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20240106153202.54861-1-colin.i.king@gmail.comSigned-off-by:
-
Jun Yan authored
The BMI088, BMI085 and BMI090L accelerometer also support I2C protocol, so let's add the missing I2C support. The I2C interface of the {BMI085,BMI088,BMI090L} is compatible with the I2C Specification UM10204 Rev. 03 (19 June 2007), available at http://www.nxp.com. The {BMI085,BMI088,BMI090L} supports I2C standard mode and fast mode, only 7-bit address mode is supported. Datasheet: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi085-ds001.pdf Datasheet: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi088-ds001.pdf Datasheet: https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/4807/BST-BMI090L-DS000-00.pdfSigned-off-by:Jun Yan <jerrysteve1101@gmail.com> Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312191325.jfiyeL5F-lkp@intel.com/ Link: https://lore.kernel.org/r/20231219150440.264033-1-jerrysteve1101@gmail.comSigned-off-by:
-
Jonathan Cameron authored
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. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-25-jic23@kernel.orgSigned-off-by:
-
Jonathan Cameron authored
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:
-
Jonathan Cameron authored
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:
-
Jonathan Cameron authored
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. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Denis CIOCCA <denis.ciocca@st.com> Reviewed-by:
-
Jonathan Cameron authored
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include from acpi.h to mod_devicetable.h which includes the definition of struct acpi_device_id. Reported-by:
-
