Re: [PATCH] iio: chemical: scd30: Prevent potential divide-by-zero error

[David Lechner <dlechner@baylibre.com>]

On 5/9/26 4:36 PM, Maxwell Doose wrote:
> On Sat, May 9, 2026 at 4:25 PM David Lechner <dlechner@baylibre.com> wrote:
>>
>> On 5/9/26 4:19 PM, Maxwell Doose wrote:
>>> In scd30_read_raw, the current value of tmp in the
>>> IIO_CHAN_INFO_SAMP_FREQ case is unchecked. Add checking to see if the
>>> value we got was 0 to prevent a divide-by-zero error.
>>>
>>> Fixes: 64b3d8b1b0f5 ("iio: chemical: scd30: add core driver")
>>> Signed-off-by: Maxwell Doose <m32285159@gmail.com>
>>> ---
>>>  drivers/iio/chemical/scd30_core.c | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/iio/chemical/scd30_core.c b/drivers/iio/chemical/scd30_core.c
>>> index be8c055be184..3e2bb6f4e42c 100644
>>> --- a/drivers/iio/chemical/scd30_core.c
>>> +++ b/drivers/iio/chemical/scd30_core.c
>>> @@ -237,6 +237,13 @@ static int scd30_read_raw(struct iio_dev *indio_dev, struct iio_chan_spec const
>>>               if (ret)
>>>                       return ret;
>>>
>>> +             /* Likely only taken if something really strange happens */
>>
>> Instead of saying "strange" I would mention a possible hardware failure
>> to justify the EIO return. I'm assuming this is reading the value over
>> SPI or I2C?
>>
> 
> Yes, we're reading over either SPI or I2C, the sensor supports both.
> Hardware failure is going to be the most likely cause of this path
> being taken, but I could also see some sort of noise on the bus being
> the cause. Perhaps we change it to:
> 
> /* Likely taken if hardware is failing or noise on bus */
> 
> best regards,
> max

Sounds OK. 

A more verbose alternative:

/*
 * Value of 0 is unexpected, but could happen, e.g. due to
 * hardware failure.
 */