Liam-Beguin/ii…
Commits on Aug 20, 2021
-
dt-bindings: iio: afe: add bindings for temperature transducers
An ADC is often used to measure other quantities indirectly. This binding describe one case, the measurement of a temperature through a temperature transducer (either voltage or current). Signed-off-by: Liam Beguin <lvb@xiphos.com> Reviewed-by: Rob Herring <robh@kernel.org>
-
dt-bindings: iio: afe: add bindings for temperature-sense-rtd
An ADC is often used to measure other quantities indirectly. This binding describe one case, the measurement of a temperature through the voltage across an RTD resistor such as a PT1000. Signed-off-by: Liam Beguin <lvb@xiphos.com> Reviewed-by: Rob Herring <robh@kernel.org>
-
iio: afe: rescale: add temperature transducers
A temperature transducer is a device that converts a thermal quantity into any other physical quantity. This patch add support for temperature to voltage (like the LTC2997) and temperature to current (like the AD590) linear transducers. In both cases these are assumed to be connected to a voltage ADC. Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: afe: rescale: add RTD temperature sensor support
An RTD (Resistance Temperature Detector) is a kind of temperature sensor used to get a linear voltage to temperature reading within a give range (usually 0 to 100 degrees Celsius). Common types of RTDs include PT100, PT500, and PT1000. Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: test: add basic tests for the iio-rescale driver
The iio-rescale driver supports various combinations of scale types and offsets. These can often result in large integer multiplications. Make sure these calculations are done right by adding a set of kunit test cases that build on top of iio-test-format. To run these tests, add the following to .kunitconfig $ cat .kunitconfig CONFIG_IIO=y CONFIG_IIO_RESCALE_KUNIT_TEST=y CONFIG_KUNIT=y Then run: $ ./tools/testing/kunit/kunit.py run --kunitconfig .kunitconfig Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: afe: rescale: fix accuracy for small fractional scales
The approximation caused by integer divisions can be costly on smaller scale values since the decimal part is significant compared to the integer part. Switch to an IIO_VAL_INT_PLUS_NANO scale type in such cases to maintain accuracy. Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: afe: rescale: reduce risk of integer overflow
Reduce the risk of integer overflow by doing the scale calculation on a 64-bit integer. Since the rescaling is only performed on *val, reuse the IIO_VAL_FRACTIONAL_LOG2 case. Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: afe: rescale: use s64 for temporary scale calculations
All four scaling coefficients can take signed values. Make tmp a signed 64-bit integer and switch to div_s64() to preserve signs during 64-bit divisions. Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: afe: rescale: add offset support
This is a preparatory change required for the addition of temperature sensing front ends. Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: afe: rescale: add INT_PLUS_{MICRO,NANO} support
Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types. Add support for these to allow using the iio-rescaler with them. Signed-off-by: Liam Beguin <lvb@xiphos.com> -
iio: afe: rescale: expose scale processing function
In preparation for the addition of kunit tests, expose the logic responsible for combining channel scales. Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: inkern: make a best effort on offset calculation
iio_convert_raw_to_processed_unlocked() assumes the offset is an integer. Make a best effort to get a valid offset value for fractional cases without breaking implicit truncations. Fixes: 48e44ce ("iio:inkern: Add function to read the processed value") Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: inkern: apply consumer scale when no channel scale is available
When a consumer calls iio_read_channel_processed() and no channel scale is available, it's assumed that the scale is one and the raw value is returned as expected. On the other hand, if the consumer calls iio_convert_raw_to_processed() the scaling factor requested by the consumer is not applied. This for example causes the consumer to process mV when expecting uV. Make sure to always apply the scaling factor requested by the consumer. Fixes: adc8ec5 ("iio: inkern: pass through raw values if no scaling") Signed-off-by: Liam Beguin <lvb@xiphos.com>
-
iio: inkern: apply consumer scale on IIO_VAL_INT cases
When a consumer calls iio_read_channel_processed() and the channel has an integer scale, the scale channel scale is applied and the processed value is returned as expected. On the other hand, if the consumer calls iio_convert_raw_to_processed() the scaling factor requested by the consumer is not applied. This for example causes the consumer to process mV when expecting uV. Make sure to always apply the scaling factor requested by the consumer. Fixes: 48e44ce ("iio:inkern: Add function to read the processed value") Signed-off-by: Liam Beguin <lvb@xiphos.com>
Commits on Jun 18, 2021
-
staging: rtl8723bs: rtw_efuse: Fix coding style
Remove unnecessary braces around single statement blocks as warned by checkpatch.pl Signed-off-by: Shreyas Krishnakumar <shreyaskumar1035@gmail.com> Link: https://lore.kernel.org/r/20210616073921.156814-1-shreyaskumar1035@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
staging: rtl8723bs: hal: use eth_broadcast_addr() to assign broadcast…
… address Using eth_broadcast_addr() to assign broadcast address instead of copying from an array that contains the all-ones broadcast address. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210616081243.2511663-4-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
staging: rtl8723bs: core: use eth_broadcast_addr() to assign broadcas…
…t address Using eth_broadcast_addr() to assign broadcast address instead of copying from an array that contains the all-ones broadcast address. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210616081243.2511663-3-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
staging: rtl8723bs: os_dep: use eth_broadcast_addr() to assign broadc…
…ast address Using eth_broadcast_addr() to assign broadcast address instead of memset() or copying from an array that contains the all-ones broadcast address. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210616081243.2511663-2-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
staging: r8188eu/core: remove the check for NULL pointer in _rtw_enqu…
…eue_cmd() Remove the check for _rtw_enqueue_cmd(), because rtw_enqueue_cmd() already has a check of NULL pointer, so this condition is not possible. Signed-off-by: Qiang Ma <maqianga@uniontech.com> Link: https://lore.kernel.org/r/20210616125332.31674-1-maqianga@uniontech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
staging: ks7010: Wrap macro definitions in parenthesis
Wrap the definition of TX_RATE_* constants in parenthesis to prevent incorrect casting during expansion, as recommended by checkpatch.pl. Signed-off-by: Caleb D.S. Brzezinski <calebdsb@protonmail.com> Link: https://lore.kernel.org/r/20210616212552.117604-1-calebdsb@protonmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
staging: rts5208: remove redundant continue statement
The continue statement at the end of a for-loop has no effect, remove it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Continue has no effect") Link: https://lore.kernel.org/r/20210617120411.11612-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> -
staging: android: ashmem: add size field in procfs fdinfo
add this information to help user to find ashmem problem. ashmem leak scenario: -000|fd = ashmem_create_region -001|mmap and pagefault -002|munmap -003|forget close(fd) <---- which lead to ashmem leak Signed-off-by: liuhailong <liuhailong@oppo.com> 收件人: 刘海龙(DuckBuBee) <liuhailong@oppo.com> Link: https://lore.kernel.org/r/20210618095035.32410-1-liuhailong@oppo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commits on Jun 17, 2021
-
Merge tag 'iio-for-5.14b' of https://git.kernel.org/pub/scm/linux/ker…
…nel/git/jic23/iio into staging-next Jonathan writes: Second set of Counter and IIO new device support, cleanups etc for 5.14 Counter ------ First part of general rework of counter subsystem to add a chrdev interface for event drive data capture. Most of it will hopefully land next cycle. * Consolidate documentation to avoid multiple copies of same docs in per device files. * Constify various arrays etc across subsystem. * 104-quad-8: - Annotate the module config parameter to avoid using it when kernel is locked down. - Spelling and trivial comment drops etc * Intel QEP - Follow up cleanups of trivial stuff from initial patch series. IIO --- Includes some cleanups as part of two ongoing audits - runtime pm usage in IIO. - Insufficient alignment on buffers passed to iio_push_to_buffers_with_timstamp() New device support * bosch,bmc150 - Add ID for BMA253 Minor features / cleanups / minor fixes / late breaking fixes * iio_push_to_buffers_with_timestamp() alignment fixes. This set includes those where the best option is to mark the buffer as __aligned(8). Normally this choice was made because there is too high a degree of possible variation in number of channels enabled to be able to guarantee the timestamp was always in the same location. This ruled out the more obvious structure form used in other drivers. Only one small class of related issues have patches under review and we can finally tighten up the explicit rules to reflect the hidden requirement. * dummy - Kconfig build dependency fix. * adi,ad_sigma_delta - General devm related simplifications for these devices. * adi,adf4350 - Fix some missing cleanup on error path. * adi,adis, ADC drivers. - Clean out unneeded spi_set_drvdata() * ams-taos,tcs3472 - Fix a potential free of an irq that was never allocated. * atlas,sensor - Drop unbalanced runtime pm call and use pm_runtime_resume_and_get() to reduce boilerplate. * bosch,bma180 - Fix bandwidth register values used. * bosch,bmc150 - Fix wrong pointer being dereferenced in remove. - Stop device trying unregister itself rather than the second device. - Refactor ACPI second device handing. - Add support for DUAL250E ACPI HID. - Move some stuff into the header to enable following patches to not add additional accessor functions. Drop existing accessors. - Add support for hinge angle setting with DUAL250E ACPI DSM to ensure keyboard and touchpad enabled correctly when in laptop mode and disabled otherwise. - Add label attr for the multiple sensor locations with DUAL250E ACPI HID. - Fix scale units for bma222 - Various reordering of devices supported lists to be alphabetical order. - Drop unnecessary duplicated chip_info_tbl[] entries. - Document that some devices have two interrupts, even if not currently used by the driver. - Move bma254 over to the bma255 driver. - Move to more consistent scale values, based on assumption that some datasheets use lower precision in their calculations in comparison with others. * hid-sensors - Use namespaces for exported symbols. - Update includes using manual inspection of output of the include-what-you-use tool. * invensense,icp10100 - Drop unbalanced runtime pm put. Use pm_runtime_resume_and_get() to cleanly handle potential error. * invensense,mpu6050 - Drop use of %hhx string formatting. - runtime pm boilerplate removal and drop an unbalanced call in remove. * liteon,ltr501 - Fix inaccurate volatile register list. - Fix wrong mode bit. - Add a missing leXX_to_cpu() conversion. - Mark ltr501_chip_info structure as const. * pulsed-light-lidar: - Boilerplate removal using runtime_pm_resume_and_get() * scmi-sensors - Formatting of SPDX fix. * silabs,si1133 - Fix a string format warning. - Drop remaining uses of %hhx string formatting. * silabs,si1145 - Drop use of %hhx string formatting. * ti,ads1015 - Drop unbalanced runtime pm call in remove and reduce boilerplate. * tag 'iio-for-5.14b' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (76 commits) iio: light: tcs3472: do not free unallocated IRQ iio: accel: bmc150: Use more consistent and accurate scale values iio: hid-sensors: Update header includes iio: pressure: icp10100: Balance runtime pm + use pm_runtime_resume_and_get() iio: prox: pulsed-light-v2: Use pm_runtime_resume_and_get() iio: chemical: atlas-sensor: Balance runtime pm + pm_runtime_resume_and_get() iio: adc: ads1015: Balance runtime pm + pm_runtime_resume_and_get() iio: imu: mpu6050: Balance runtime pm + use pm_runtime_resume_and_get() iio: hid-sensors: lighten exported symbols by moving to IIO_HID namespace iio: prox: isl29501: Fix buffer alignment in iio_push_to_buffers_with_timestamp() iio: light: vcnl4035: Fix buffer alignment in iio_push_to_buffers_with_timestamp() iio: light: vcnl4000: Fix buffer alignment in iio_push_to_buffers_with_timestamp() iio: magn: rm3100: Fix alignment of buffer in iio_push_to_buffers_with_timestamp() iio: adc: ti-ads8688: Fix alignment of buffer in iio_push_to_buffers_with_timestamp() iio: adc: mxs-lradc: Fix buffer alignment in iio_push_to_buffers_with_timestamp() iio: adc: hx711: Fix buffer alignment in iio_push_to_buffers_with_timestamp() iio: adc: at91-sama5d2: Fix buffer alignment in iio_push_to_buffers_with_timestamp() counter: interrupt-cnt: Add const qualifier for actions_list array iio: ltr501: mark ltr501_chip_info as const iio: ltr501: ltr501_read_ps(): add missing endianness conversion ...
Commits on Jun 16, 2021
-
iio: light: tcs3472: do not free unallocated IRQ
Allocating an IRQ is conditional to the IRQ existence, but freeing it was not. If no IRQ was allocate, the driver would still try to free IRQ 0. Add the missing checks. This fixes the following trace when the driver is removed: [ 100.667788] Trying to free already-free IRQ 0 [ 100.667793] WARNING: CPU: 0 PID: 2315 at kernel/irq/manage.c:1826 free_irq+0x1fd/0x370 ... [ 100.667914] Call Trace: [ 100.667920] tcs3472_remove+0x3a/0x90 [tcs3472] [ 100.667927] i2c_device_remove+0x2b/0xa0 Signed-off-by: frank zago <frank@zago.net> Link: https://lore.kernel.org/r/20210427022017.19314-2-frank@zago.net Fixes: 9d2f715 ("iio: light: tcs3472: support out-of-threshold events") Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
iio: accel: bmc150: Use more consistent and accurate scale values
It is quite strange that BMA222 and BMA222E have very close, yet subtly different values in their scale tables. Comparing the datasheets this is simply because the "Resolution" for the different measurement ranges are documented with different precision. For example, for +-2g the BMA222 datasheet [1] suggests a resolution of 15.6 mg/LSB, while the BMA222E datasheet [2] suggests 15.63 mg/LSB. Actually, there is no need to rely on the resolution given by the Bosch datasheets. The resolution and scale can be calculated more consistently and accurately using the range (e.g. +-2g) and the channel size (e.g. 8 bits). Distributing 4g (-2g to 2g) over 8 bits results in an exact resolution of (4g / 2^8) = 15.625 mg/LSB which is the same value as in both datasheets, just slightly more accurate. Multiplying g = 9.80665 m/s^2 we get a more accurate value for the IIO scale table. Generalizing this we can calculate the scale tables more accurately using (range / 2^bits) * g * 10^6 (because of IIO_VAL_INT_PLUS_MICRO). Document this and make the scale tables more consistent and accurate for all the variants using that formula. Now the scale tables for BMA222 and BMA222E are consistent and probably slightly more accurate. [1]: https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA222.pdf [2]: https://www.mouser.com/datasheet/2/783/BST-BMA222E-DS004-06-1021076.pdf Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Andy Shevchenko <andy.shevchenko@gnail.com> Link: https://lore.kernel.org/r/20210611182442.1971-1-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
iio: hid-sensors: Update header includes
General driver churn doesn't always include updates of header includes. Manual review of the output of the include-what-you-use checker lead to the following cleanup. Hopefuly this brings things back to a good state for the hid-sensor drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210608205510.4033887-1-jic23@kernel.org
-
iio: pressure: icp10100: Balance runtime pm + use pm_runtime_resume_a…
…nd_get() The devm_ handled runtime pm disable calls pm_runtime_put_sync_suspend() which isn't balancing a matching get call. It isn't a bug as such, because the runtime pm core doesn't decrement the reference count below zero, but it is missleading so let's drop it. Using pm_runtime_resume_and_get() new call makes it easy to handle failures in resume as it doesn't hold a reference count if it exits with an error. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210516162103.1332291-7-jic23@kernel.org
-
iio: prox: pulsed-light-v2: Use pm_runtime_resume_and_get()
Using this new call makes it easy to handle any errors as a result of runtime resume as it exits without leaving the reference count elevated. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210516162103.1332291-6-jic23@kernel.org
-
iio: chemical: atlas-sensor: Balance runtime pm + pm_runtime_resume_a…
…nd_get() The pm_runtime_put_noidle() call in remove isn't balanced with any get, so drop it. Note this isn't a bug as the runtime pm core will not allow the reference count to go negative, making this a noop. However, it is confusing to the reader so let's drop it. pm_runtime_resume_and_get() replacement found using the coccicheck script under review at: https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/ As pm_runtime_resume_and_get() returns <= 0 take advantage of that to change the error checking to if (ret) which is more in keeping with the rest of this driver. This is a prequel to taking a closer look at the runtime pm in IIO drivers in general. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210516162103.1332291-4-jic23@kernel.org
-
iio: adc: ads1015: Balance runtime pm + pm_runtime_resume_and_get()
The call to pm_runtime_put_noidle() in remove() is not balancing a counter increment. Note this doesn't matter as the runtime pm core will not allow the counter to go negative. However, it is confusing to the reader so let's remove it. The pm_runtime_resume_and_get() replacement was found using coccicheck script under review at: https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/ This is a prequel to taking a closer look at the runtime pm in IIO drivers in general. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210516162103.1332291-3-jic23@kernel.org
-
iio: imu: mpu6050: Balance runtime pm + use pm_runtime_resume_and_get()
Remove an unblanced pm_runtime_put_sync_suspend() call in inv_pu_pm_disable(). Not this call is not a bug, because the runtime pm core will not allow the reference counter to go negative. It is however confusing and serves no purpose. pm_runtime_resume_and_get() case found using coccicheck script under review at: https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/ pm_runtime_resume_and_get() returns <= 0 only so simplify related checks to bring this more inline with nearby calls. This is a prequel to taking a closer look at the runtime pm in IIO drivers in general. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210516162103.1332291-2-jic23@kernel.org
-
iio: hid-sensors: lighten exported symbols by moving to IIO_HID names…
…pace A namespace for exported symbols makes clear who is a provider and who is a consumer of the certain resources. Besides that, it doesn't pollute the common namespace. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210614162447.5392-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
iio: prox: isl29501: Fix buffer alignment in iio_push_to_buffers_with…
…_timestamp() Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here an explicit structure is not used, because the holes would necessitate the addition of an explict memset(), to avoid a kernel data leak, making for a less minimal fix. Fixes: 1c28799 ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Mathieu Othacehe <m.othacehe@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613152301.571002-9-jic23@kernel.org
-
iio: light: vcnl4035: Fix buffer alignment in iio_push_to_buffers_wit…
…h_timestamp() Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here an explicit structure is not used, because the holes would necessitate the addition of an explict memset(), to avoid a potential kernel data leak, making for a less minimal fix. Fixes: 5570729 ("iio: light: Add support for vishay vcnl4035") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Parthiban Nallathambi <pn@denx.de> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613152301.571002-8-jic23@kernel.org
-
staging: rtl8188eu: remove _dbg_dump_tx_info function
Remove the _dbg_dump_tx_info function from hal/rtl8188e_xmit.c, as it doesn't actually do anything and is only called from one place. It used to have some redundant debugging statements in it, but these have now been removed anyway, so all it does is read information from the adapter to set a variable 'dump_txdesc' which is then never used. This fixes a kernel test robot warning. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210615223607.13863-8-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>