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

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 18 Oct 2026 02:42:18 +0530
Nikhil Gautam <nikhilgtr@gmail.com> wrote:

> 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.
Given it's an error path and just as likely the attempt to put it
to sleep may also fail, this becomes a possible improvement rather htan
a fix.  I'm not entirely convinced we care about that corner case
but feel free to send it with a description that talks about this
and we'll see what others think.

Thanks,

Jonathan

> 
> Thanks,
> Nikhil