summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)Author
2021-10-19iio: inkern: introduce devm_iio_map_array_register() short-hand functionAlexandru Ardelean
This change introduces a device-managed variant to the iio_map_array_register() function. It's a simple implementation of calling iio_map_array_register() and registering a callback to iio_map_array_unregister() with the devm_add_action_or_reset(). The function uses an explicit 'dev' parameter to bind the unwinding to. It could have been implemented to implicitly use the parent of the IIO device, however it shouldn't be too expensive to callers to just specify to which device object to bind this unwind call. It would make the API a bit more flexible. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210903072917.45769-2-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: fsl-imx25-gcq: initialize regulators as neededAlexandru Ardelean
The driver tries to initialize all possible regulators from the DT, then match the external regulators with each channel and then release all unused regulators. We can change the logic a bit to initialize regulators only when at least one channel needs them. This change creates a mx25_gcq_ext_regulator_setup() function that is called only for the external regulators. If there's already a reference to an external regulator, the function will just exit early with no error. This way, the driver doesn't need to keep any track of these regulators during init. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625074325.9237-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: imu: st_lsm6dsx: move max_fifo_size in st_lsm6dsx_fifo_opsLorenzo Bianconi
Move max_fifo_size in st_lsm6dsx_fifo_ops in order to have all FIFO configuration parameters in st_lsm6dsx_fifo_ops structure. This patch does not introduce any logic change, just small code rearrangement. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/3262ad9d9d1497e19ea1bab208c495c2b9a98994.1632664866.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Don't reject external triggers when there is no IRQMiquel Raynal
External triggers do not necessarily need the EOC interrupt to be populated to work properly. The end of conversion status may either come from an interrupt or from a sufficient enough extra delay. IRQs are not mandatory so move the triggered buffer setup out of the IRQ condition and add the logic to wait enough time for all the requested conversions to be in the device's FIFO. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-17-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Allow all kind of triggers to be usedMiquel Raynal
There is no reason to limit this driver to its internal trigger. The only difference being, when using an external trigger, the sample conversion must be manually started. Drop the ->validate_trigger() hook in order to allow other triggers to be bound. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-16-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Use the EOC IRQ when populated for single readsMiquel Raynal
So far the End-Of-Conversion interrupt was only used in conjunction with the internal trigger to process the data. Let's extend the use of this interrupt handler to support regular single-shot conversions as well. Doing so requires writing our own hard IRQ handler. This handler has to check if buffers are enabled or not: *** Buffers disabled condition *** This means the user requested a single conversion and the sample is ready to be retrieved. -> This implies adding the relevant completion boilerplate. *** Buffers enabled condition *** Triggers are used. So far there is only support for the internal trigger but this trigger might soon be attached to another device as well so it is the core duty to decide which handler to call in order to process the data. The core will decide to either: * Call the internal trigger handler which will extract the data that is already present in the ADC FIFOs or * Call the trigger handler of another driver when using this trigger with another device, even though this call will be slightly delayed by the fact that the max1027 IRQ is a data-ready interrupt rather than a real trigger: -> The new handler will manually inform the core about the trigger having transitioned by directly calling iio_trigger_poll() (which iio_trigger_generic_data_rdy_poll() initially did). In order for the handler to be "source" agnostic, we also need to change the private pointer and provide the IIO device instead of the trigger object. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-15-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Stop requesting a threaded IRQMiquel Raynal
The threaded handler is not populated, this means there is nothing running in process context so let's switch to the regular devm_request_irq() call instead. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-14-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Introduce an end of conversion helperMiquel Raynal
For now this helper only waits for the maximum duration of a single conversion. In practice, a "temperature measurement" will take twice this time because it will also carry another analog conversion but as here we will only care about the temperature conversion which happens first, we can still only wait for a single sample and get the right data. This helper will soon be improved to properly handle the end of conversion interrupt as well as a higher number of samples. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-13-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Separate the IRQ handler from the read logicMiquel Raynal
Create a max1027_read_scan() helper which will make clearer the future IRQ handler updates (no functional change). Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-12-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Prevent single channel accesses during buffer readsMiquel Raynal
When hardware buffers are enabled (the cnvst pin being the trigger), one should not mess with the device state by requesting a single channel read. There is already a iio_buffer_enabled() check in *_read_single_value() to merely prevent this situation but the check is inconsistent since buffers can be enabled after the if clause anyway. Instead, use the core mutex by calling iio_device_claim/release_direct_mode(). Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-11-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Create a helper to configure the channels to scanMiquel Raynal
These bits are meant to be reused for triggered buffers setup. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-10-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Ensure a default cnvst trigger configurationMiquel Raynal
We don't expect the (hardware) cnvst trigger to be enabled at boot time, this is a user choice made in sysfs and there is a dedicated callback to enable/disable this trigger. Hence, we can just ensure it is disabled in the probe at initialization time and then assume that whenever a ->read_raw() call happens, the trigger has been disabled and conversions will start on register write. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-9-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Simplify the _set_trigger_state() helperMiquel Raynal
The call to max1027_enable_trigger() is the same in both cases thanks to the 'state' variable, so factorize a little bit to simplify the code and explain why we call this helper. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-8-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Create a helper to enable/disable the cnvst triggerMiquel Raynal
There are two ways to physically trigger a conversion: - A falling edge on the cnvst pin - A write operation on the conversion register Let's create a helper for this. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210921115408.66711-7-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Rename a helperMiquel Raynal
Make it clear that the *_set_trigger_state() hook is responsible for cnvst based conversions by renaming the helper. This may avoid confusions with software trigger support that is going to be introduced. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210921115408.66711-6-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Minimize the number of converted channelsMiquel Raynal
Provide a list of ->available_scan_masks which match the device's capabilities. Basically, these devices are able to scan from 0 to N, N being the highest voltage channel requested by the user. The temperature can be included or not, but cannot be retrieved alone. The consequence is, instead of reading and pushing to the IIO buffers all channels each time, the "minimum" number of channels will be scanned and pushed based on the ->active_scan_mask. For example, if the user wants channels 1, 4 and 5, all channels from 0 to 5 will be scanned and pushed to the IIO buffers. The core will then filter out the unneeded samples based on the ->active_scan_mask that has been selected and only channels 1, 4 and 5 will be available to the user in the shared buffer. Provide a comment in the code explaining this logic. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-5-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Drop useless debug messagesMiquel Raynal
These two debug messages bring absolutely no value, let's drop them. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-4-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Drop extra warning messageMiquel Raynal
Memory allocation errors automatically trigger the right logs, no need to have our own. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210921115408.66711-3-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: Fix styleMiquel Raynal
Follow checkpatch.pl's main advices before hacking into the driver, mainly: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Prefer 'unsigned int *' to bare use of 'unsigned *' CHECK: Comparison to NULL could be written "!foo" CHECK: Alignment should match open parenthesis Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-2-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: imx8qxp-adc: Add driver support for NXP IMX8QXP ADCCai Huoqing
The NXP i.MX 8QuadXPlus SOC has a new ADC IP, so add driver support for this ADC. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20210925020555.129-2-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: fxls8962af: add wake on eventSean Nyekjaer
This adds ways for the SoC to wake from accelerometer wake events. In the suspend function we skip disabling the sensor if wakeup-source and events are activated. If buffered reads are enabled they will be deactivated before suspend. As the onboard buffer is only holding up to 32 12-bit X/Y/Z data triplets. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210920114221.1595543-2-sean@geanix.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: fxls8962af: add threshold event handlingSean Nyekjaer
Add event channels that control the creation of motion events. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20210920114221.1595543-1-sean@geanix.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Get and set trimming data.Billy Tsai
The ADC controller has a trimming register for fine-tune the reference voltage. The trimming value comes from the OTP register which will be written during chip production. This patch will read this OTP value and configure it to the ADC register when the ADC controller probes and using dts property "aspeed,trim-data-valid" to determine whether to execute this flow. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-12-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Support battery sensing.Billy Tsai
In ast2600, ADC integrate dividing circuit at last input channel for battery sensing. This patch use the dts property "battery-sensing" to enable this feature makes the last channel of each adc can tolerance higher voltage than reference voltage. The offset interface of ch7 will be separated when enabling the battery sensing mode. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-11-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Add compensation phase.Billy Tsai
This patch adds a compensation phase to improve the accuracy of ADC measurement. This is the built-in function through input half of the reference voltage to get the ADC offset. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-10-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Add func to set sampling rate.Billy Tsai
Add the function to set the sampling rate and keep the sampling period for a driver used to wait the fresh value. In addition, since the ADC clock is required when initializing the ADC device, move clk_prepare_enable ahead of the initialization phase. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-9-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Fix the calculate error of clock.Billy Tsai
The ADC clock formula is ast2400/2500: ADC clock period = PCLK * 2 * (ADC0C[31:17] + 1) * (ADC0C[9:0] + 1) ast2600: ADC clock period = PCLK * 2 * (ADC0C[15:0] + 1) They all have one fixed divided 2 and the legacy driver didn't handle it. This patch register the fixed factory clock device as the parent of ADC clock scaler to fix this issue. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-8-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Support ast2600 adc.Billy Tsai
Make driver to support ast2600 adc device. - Use shared reset controller - Complete the vref configure function - Add the model data for ast2600 adc Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-7-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Use devm_add_action_or_reset.Billy Tsai
This patch use devm_add_action_or_reset to handle the error in probe phase. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-6-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Use model_data to set clk scaler.Billy Tsai
This patch uses need_prescaler and scaler_bit_width to set the ADC clock scaler. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-5-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Add vref config functionBilly Tsai
Add the function to check the vref_fixed_mv and set the value to driver data. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-4-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Restructure the model dataBilly Tsai
This patch refactors the model data structure to distinguish the function form different versions of aspeed ADC. - Rename the vref_voltage to vref_fixed_mv and add vref_mv driver data When driver probe will check vref_fixed_mv value and store it to vref_mv which isn't const value. - Add num_channels Make num_channles of iio device can be changed by different model_data - Add need_prescaler flag and scaler_bit_width The need_prescaler flag is used to tell the driver the clock divider needs another Prescaler and the scaler_bit_width to set the clock divider bitfield width. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-3-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: aspeed: Keep model data to driver data.Billy Tsai
Keep the model data pointer to driver data for reducing the usage of of_device_get_match_data(). Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-2-billy_tsai@aspeedtech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: chemical: Add Senseair Sunrise 006-0-007 driverJacopo Mondi
Add support for the Senseair Sunrise 006-0-0007 driver through the IIO subsystem. Datasheet: https://rmtplusstoragesenseair.blob.core.windows.net/docs/Dev/publicerat/TDE5531.pdf Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Link: https://lore.kernel.org/r/20210920135413.140310-4-jacopo+renesas@jmondi.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17Merge tag 'staging-5.15-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging and IIO driver fixes from Greg KH: "Here are a number of small IIO and staging driver fixes for 5.15-rc6. They include: - vc04_services bugfix for reported problem - r8188eu array underflow fix - iio driver fixes for a lot of tiny reported issues. All of these have been in linux-next for a while with no reported issues" * tag 'staging-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: r8188eu: prevent array underflow in rtw_hal_update_ra_mask() staging: vc04_services: shut up out-of-range warning iio: light: opt3001: Fixed timeout error when 0 lux iio: adis16480: fix devices that do not support sleep mode iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED iio: adis16475: fix deadlock on frequency set iio: ssp_sensors: add more range checking in ssp_parse_dataframe() iio: ssp_sensors: fix error code in ssp_print_mcu_debug() iio: adc: ad7793: Fix IRQ flag iio: adc: ad7780: Fix IRQ flag iio: adc: ad7192: Add IRQ flag iio: adc: aspeed: set driver data when adc probe. iio: adc: rzg2l_adc: add missing clk_disable_unprepare() in rzg2l_adc_pm_runtime_resume() iio: adc: max1027: Fix the number of max1X31 channels iio: adc: max1027: Fix wrong shift with 12-bit devices iio: adc128s052: Fix the error handling path of 'adc128_probe()' iio: adc: rzg2l_adc: Fix -EBUSY timeout error return iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed iio: dac: ti-dac5571: fix an error code in probe()
2021-10-17iio: adc: tsc2046: fix scan interval warningOleksij Rempel
Sync if statement with the actual warning. Fixes: 9504db5765e8 ("iio: adc: tsc2046: fix a warning message in tsc2046_adc_update_scan_mode()") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20211007093007.1466-2-o.rempel@pengutronix.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: core: fix double free in iio_device_unregister_sysfs()Yang Yingliang
I got the double free report: BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 iio_device_unregister_sysfs+0x108/0x13b [industrialio] iio_dev_release+0x9e/0x10e [industrialio] device_release+0xa5/0x240 If __iio_device_register() fails, iio_dev_opaque->groups will be freed in error path in iio_device_unregister_sysfs(), then iio_dev_release() will call iio_device_unregister_sysfs() again, it causes double free. Set iio_dev_opaque->groups to NULL when it's freed to fix this double free. Not this is a local work around for a more general mess around life time management that will get cleaned up and should make this handling unnecesarry. Fixes: 32f171724e5c ("iio: core: rework iio device group creation") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013030532.956133-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: core: check return value when calling dev_set_name()Yang Yingliang
I got a null-ptr-deref report when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strlen+0x0/0x20 Call Trace: start_creating+0x199/0x2f0 debugfs_create_dir+0x25/0x430 __iio_device_register+0x4da/0x1b40 [industrialio] __devm_iio_device_register+0x22/0x80 [industrialio] max1027_probe+0x639/0x860 [max1027] spi_probe+0x183/0x210 really_probe+0x285/0xc30 If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: e553f182d55b ("staging: iio: core: Introduce debugfs support...") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211012063624.3167460-1-yangyingliang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: buffer: Fix memory leak in iio_buffer_register_legacy_sysfs_groups()Yang Yingliang
If the second iio_device_register_sysfs_group() fails, 'legacy_buffer_group.attrs' need be freed too or it will cause memory leak: unreferenced object 0xffff888003618280 (size 64): comm "xrun", pid 357, jiffies 4294907259 (age 22.296s) hex dump (first 32 bytes): 80 f6 8c 03 80 88 ff ff 80 fb 8c 03 80 88 ff ff ................ 00 f9 8c 03 80 88 ff ff 80 fc 8c 03 80 88 ff ff ................ backtrace: [<00000000076bfd43>] __kmalloc+0x1a3/0x2f0 [<00000000c32e4886>] iio_buffers_alloc_sysfs_and_mask+0xc31/0x1290 [industrialio] Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013144242.1685060-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: buffer: Fix double-free in iio_buffers_alloc_sysfs_and_mask()Yang Yingliang
When __iio_buffer_alloc_sysfs_and_mask() failed, 'unwind_idx' should be set to 'i - 1' to prevent double-free when cleanup resources. BUG: KASAN: double-free or invalid-free in __iio_buffer_free_sysfs_and_mask+0x32/0xb0 [industrialio] Call Trace: kfree+0x117/0x4c0 __iio_buffer_free_sysfs_and_mask+0x32/0xb0 [industrialio] iio_buffers_alloc_sysfs_and_mask+0x60d/0x1570 [industrialio] __iio_device_register+0x483/0x1a30 [industrialio] ina2xx_probe+0x625/0x980 [ina2xx_adc] Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211013094923.2473-2-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: buffer: Fix memory leak in __iio_buffer_alloc_sysfs_and_mask()Yang Yingliang
When iio_buffer_wrap_attr() returns NULL or buffer->buffer_group.name alloc fails, the 'attr' which is allocated in __iio_buffer_alloc_sysfs_and_mask() is not freed, and cause memory leak. unreferenced object 0xffff888014882a00 (size 64): comm "i2c-adjd_s311-8", pid 424, jiffies 4294907737 (age 44.396s) hex dump (first 32 bytes): 00 0f 8a 15 80 88 ff ff 00 0e 8a 15 80 88 ff ff ................ 80 04 8a 15 80 88 ff ff 80 05 8a 15 80 88 ff ff ................ backtrace: [<0000000021752e67>] __kmalloc+0x1af/0x3c0 [<0000000043e8305c>] iio_buffers_alloc_sysfs_and_mask+0xe73/0x1570 [industrialio] [<00000000b7aa5a17>] __iio_device_register+0x483/0x1a30 [industrialio] [<000000003fa0fb2f>] __devm_iio_device_register+0x23/0x90 [industrialio] [<000000003ab040cf>] adjd_s311_probe+0x19c/0x200 [adjd_s311] [<0000000080458969>] i2c_device_probe+0xa31/0xbe0 [<00000000e20678ad>] really_probe+0x299/0xc30 [<000000006bea9b27>] __driver_probe_device+0x357/0x500 [<00000000e1df10d4>] driver_probe_device+0x4e/0x140 [<0000000003661beb>] __device_attach_driver+0x257/0x340 [<000000005bb4aa26>] bus_for_each_drv+0x166/0x1e0 [<00000000272c5236>] __device_attach+0x272/0x420 [<00000000d52a96ae>] bus_probe_device+0x1eb/0x2a0 [<00000000129f7737>] device_add+0xbf0/0x1f90 [<000000005eed4e52>] i2c_new_client_device+0x622/0xb20 [<00000000b85a9c43>] new_device_store+0x1fa/0x420 This patch fix to free it before the error return. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013094343.315275-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: buffer: check return value of kstrdup_const()Yang Yingliang
Check return value of kstrdup_const() in iio_buffer_wrap_attr(), or it will cause null-ptr-deref in kernfs_name_hash() when calling device_add() as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strlen+0x0/0x20 Call Trace: kernfs_name_hash+0x22/0x110 kernfs_find_ns+0x11d/0x390 kernfs_remove_by_name_ns+0x3b/0xb0 remove_files.isra.1+0x7b/0x190 internal_create_group+0x7f1/0xbb0 internal_create_groups+0xa3/0x150 device_add+0x8f0/0x2020 cdev_device_add+0xc3/0x160 __iio_device_register+0x1427/0x1b40 [industrialio] __devm_iio_device_register+0x22/0x80 [industrialio] adjd_s311_probe+0x195/0x200 [adjd_s311] i2c_device_probe+0xa07/0xbb0 Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013040438.1689277-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: dac: ad5446: Fix ad5622_write() return valuePekka Korpinen
On success i2c_master_send() returns the number of bytes written. The call from iio_write_channel_info(), however, expects the return value to be zero on success. This bug causes incorrect consumption of the sysfs buffer in iio_write_channel_info(). When writing more than two characters to out_voltage0_raw, the ad5446 write handler is called multiple times causing unexpected behavior. Fixes: 3ec36a2cf0d5 ("iio:ad5446: Add support for I2C based DACs") Signed-off-by: Pekka Korpinen <pekka.korpinen@iki.fi> Link: https://lore.kernel.org/r/20210929185755.2384-1-pekka.korpinen@iki.fi Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: adc: exynos: describe drivers in KConfigKrzysztof Kozlowski
Describe better which driver applies to which SoC, to make configuring kernel for Samsung SoC easier. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210924133515.112357-1-krzysztof.kozlowski@canonical.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: adc: rockchip_saradc: Make use of the helper function ↵Cai Huoqing
devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210908105631.1474-1-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: dac: stm32-dac: Make use of the helper function ↵Cai Huoqing
devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210908105638.1525-1-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: accel: mma7660: Mark acpi match table as maybe unusedDaniel Palmer
When building kernels without ACPI support the table is declared but is not used because ACPI_PTR() turns it into a NULL. Add the __maybe_unused attribute to stop the compiler whining. Signed-off-by: Daniel Palmer <daniel@0x0f.com> Link: https://lore.kernel.org/r/20210919072616.3849723-1-daniel@0x0f.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: light: max44000: use device-managed functions in probeAlexandru Ardelean
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>
2021-10-17iio: gyro: adis16080: use devm_iio_device_register() in probeAlexandru Ardelean
There is nothing else that needs to be done for this driver. The remove hook calls only the iio_device_unregister() hook. So this driver can use devm_iio_device_register() directly. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210913115308.301877-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: dac: ad5064: convert probe to full device-managedAlexandru Ardelean
This change converts the probe of the AD5064 driver to use only device-managed functions. The regulator_bulk_disable() is passed on a devm_add_action_or_reset() hook and the devm_iio_device_register() can be used to register the IIO device. The driver has both I2C and SPI hooks inside, so all these can be removed. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210913115237.301310-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>