kernel/linux.git/drivers/staging/iio, branch v6.12.80

staging: iio: ad5933: Correct settling cycles encoding per datasheet

2025-06-27T10:11:23+00:00

commit 60638e2a2d4bc03798f00d5ab65ce9b83cb8b03b upstream. The AD5933 datasheet (Table 13) lists the maximum cycles to be 0x7FC (2044). Clamp the user input to the maximum effective value of 0x7FC cycles. Fixes: f94aa354d676 ("iio: impedance-analyzer: New driver for AD5933/4 Impedance Converter, Network Analyzer") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Shahrouzi Reviewed-by: Marcelo Schmitt Link: https://patch.msgid.link/20250420013009.847851-1-gshahrouzi@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

staging: iio: adc: ad7816: Correct conditional logic for store mode

2025-05-18T06:24:51+00:00

commit 2e922956277187655ed9bedf7b5c28906e51708f upstream. The mode setting logic in ad7816_store_mode was reversed due to incorrect handling of the strcmp return value. strcmp returns 0 on match, so the `if (strcmp(buf, "full"))` block executed when the input was not "full". This resulted in "full" setting the mode to AD7816_PD (power-down) and other inputs setting it to AD7816_FULL. Fix this by checking it against 0 to correctly check for "full" and "power-down", mapping them to AD7816_FULL and AD7816_PD respectively. Fixes: 7924425db04a ("staging: iio: adc: new driver for AD7816 devices") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Shahrouzi Acked-by: Nuno Sá Link: https://lore.kernel.org/stable/20250414152920.467505-1-gshahrouzi%40gmail.com Link: https://patch.msgid.link/20250414154050.469482-1-gshahrouzi@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

staging: iio: ad9832: Correct phase range check

2025-01-17T12:40:52+00:00

commit 4636e859ebe0011f41e35fa79bab585b8004e9a3 upstream. User Perspective: When a user sets the phase value, the ad9832_write_phase() is called. The phase register has a 12-bit resolution, so the valid range is 0 to 4095. If the phase offset value of 4096 is input, it effectively exactly equals 0 in the lower 12 bits, meaning no offset. Reasons for the Change: 1) Original Condition (phase > BIT(AD9832_PHASE_BITS)): This condition allows a phase value equal to 2^12, which is 4096. However, this value exceeds the valid 12-bit range, as the maximum valid phase value should be 4095. 2) Modified Condition (phase >= BIT(AD9832_PHASE_BITS)): Ensures that the phase value is within the valid range, preventing invalid datafrom being written. Impact on Subsequent Logic: st->data = cpu_to_be16(addr | phase): If the phase value is 2^12, i.e., 4096 (0001 0000 0000 0000), and addr is AD9832_REG_PHASE0 (1100 0000 0000 0000), then addr | phase results in 1101 0000 0000 0000, occupying DB12. According to the section of WRITING TO A PHASE REGISTER in the datasheet, the MSB 12 PHASE0 bits should be DB11. The original condition leads to incorrect DB12 usage, which contradicts the datasheet and could pose potential issues for future updates if DB12 is used in such related cases. Fixes: ea707584bac1 ("Staging: IIO: DDS: AD9832 / AD9835 driver") Cc: stable@vger.kernel.org Signed-off-by: Zicheng Qu Link: https://patch.msgid.link/20241107011015.2472600-3-quzicheng@huawei.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

staging: iio: ad9834: Correct phase range check

2025-01-17T12:40:52+00:00

commit c0599762f0c7e260b99c6b7bceb8eae69b804c94 upstream. User Perspective: When a user sets the phase value, the ad9834_write_phase() is called. The phase register has a 12-bit resolution, so the valid range is 0 to 4095. If the phase offset value of 4096 is input, it effectively exactly equals 0 in the lower 12 bits, meaning no offset. Reasons for the Change: 1) Original Condition (phase > BIT(AD9834_PHASE_BITS)): This condition allows a phase value equal to 2^12, which is 4096. However, this value exceeds the valid 12-bit range, as the maximum valid phase value should be 4095. 2) Modified Condition (phase >= BIT(AD9834_PHASE_BITS)): Ensures that the phase value is within the valid range, preventing invalid datafrom being written. Impact on Subsequent Logic: st->data = cpu_to_be16(addr | phase): If the phase value is 2^12, i.e., 4096 (0001 0000 0000 0000), and addr is AD9834_REG_PHASE0 (1100 0000 0000 0000), then addr | phase results in 1101 0000 0000 0000, occupying DB12. According to the section of WRITING TO A PHASE REGISTER in the datasheet, the MSB 12 PHASE0 bits should be DB11. The original condition leads to incorrect DB12 usage, which contradicts the datasheet and could pose potential issues for future updates if DB12 is used in such related cases. Fixes: 12b9d5bf76bf ("Staging: IIO: DDS: AD9833 / AD9834 driver") Cc: stable@vger.kernel.org Signed-off-by: Zicheng Qu Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20241107011015.2472600-2-quzicheng@huawei.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()

2024-10-24T17:30:47+00:00

In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value. Link: https://lore.kernel.org/all/2024100904-CVE-2024-47663-9bdc@gregkh/ Fixes: ea707584bac1 ("Staging: IIO: DDS: AD9832 / AD9835 driver") Cc: stable@vger.kernel.org Signed-off-by: Zicheng Qu Reviewed-by: Nuno Sa Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20241022134354.574614-1-quzicheng@huawei.com Signed-off-by: Jonathan Cameron

Merge 6.11-rc7 into char-misc-next

2024-09-09T06:36:23+00:00

We need the char-misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman

staging: iio: impedance-analyzer: ad5933: make use of iio_get_masklength()

2024-08-03T09:13:43+00:00

Use iio_get_masklength() to access '.masklength' so it can be annotated as __private when there are no more direct users of it. Signed-off-by: Nuno Sa Link: https://patch.msgid.link/20240726-dev-iio-masklength-private3-v1-22-82913fc0fb87@analog.com Signed-off-by: Jonathan Cameron

staging: iio: frequency: ad9834: Validate frequency parameter value

2024-07-29T19:31:23+00:00

In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 12b9d5bf76bf ("Staging: IIO: DDS: AD9833 / AD9834 driver") Suggested-by: Dan Carpenter Signed-off-by: Aleksandr Mishin Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20240703154506.25584-1-amishin@t-argos.ru Cc: Signed-off-by: Jonathan Cameron

staging: iio: Drop explicit initialization of struct i2c_device_id::driver_data to 0

2024-06-13T18:19:23+00:00

These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. Signed-off-by: Uwe Kleine-König Reviewed-by: Nuno Sa Link: https://lore.kernel.org/r/20240606155407.499344-1-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron

staging: iio: adt7316: remove unused struct 'adt7316_limit_regs'

2024-06-04T18:53:07+00:00

'adt7316_limit_regs' has never been used since the original commit 35f6b6b86ede ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver"). The comment above it is a copy-and-paste from a different struct. Remove both the struct and the comment. Reviewed-by: Nuno Sa Signed-off-by: Dr. David Alan Gilbert Link: https://lore.kernel.org/r/20240529160055.28489-1-linux@treblig.org Signed-off-by: Jonathan Cameron