Re: [PATCH v2] iio: ccs811: Deassert WAKE GPIO on error paths

[Nikhil Gautam <nikhilgtr@gmail.com>]

Hi Jonathan,

Thanks for the review.

>> Ensure the WAKE GPIO is deasserted when status polling fails or
>> the data-ready timeout expires. Early returns could leave WAKE asserted,
>> preventing the sensor from returning to its low-power state and
>> potentially disrupting subsequent I2C transactions.
> I need more on this point to know whether we care if an error
> means we don't deassert the wake pin.
>
> Why would failing to go to sleep break future transactions?
> I'd kind of assume we'd awaken an already awake device (which sounds
> idempotent but maybe not?) and carry on from there?
>
> Jonathan

The relevant information is in the CCS811 datasheet (v1-06),
under “CCS811 – Pin Assignment” (page 4) and “Detailed Description” 
(page 7 onwards).

The datasheet specifies that nWAKE is active-low and should be asserted
before an I²C transaction and held low throughout it. It also describes
the sleep behavior: when nWAKE is deasserted, the device enters sleep
mode and ignores I²C requests. The timing specifications specify a 50 µs
wake-up time and a minimum 20 µs deassertion interval.

I agree that the datasheet does not explicitly state that leaving nWAKE
asserted after an error will cause subsequent transactions to fail.
My concern is primarily that an early return leaves the device awake
instead of restoring the intended low-power state.

I'll adjust the justification accordingly, rather than claiming that 
subsequent
transactions would necessarily be disrupted.

Thanks,
Nikhil