linux-kernel - Re: [PATCH v7] iio: light: ltr390: Implement runtime PM support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE3SzaQXOr6nh-MFAyLm_1J9kXisnzhak_VuVH4d2z6mXFe1NA@mail.gmail.com>
Date: Wed, 10 Sep 2025 23:30:36 +0530
From: Akshay Jindal <akshayaj.lkd@...il.com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>, anshulusr@...il.com, jic23@...nel.org, 
	dlechner@...libre.com, nuno.sa@...log.com, andy@...nel.org, shuah@...nel.org, 
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7] iio: light: ltr390: Implement runtime PM support

Hi Jonathan,
Seeking your approval. If there is a requirement for v8, I can send that too.

Thanks,
Akshay

On Wed, Sep 10, 2025 at 4:32 PM Jonathan Cameron
<jonathan.cameron@...wei.com> wrote:
>
> On Wed, 10 Sep 2025 10:17:00 +0300
> Andy Shevchenko <andy.shevchenko@...il.com> wrote:
>
> > On Tue, Sep 9, 2025 at 10:47 PM Akshay Jindal <akshayaj.lkd@...il.com> wrote:
> > >
> > > Implement runtime power management for the LTR390 sensor. The device
> > > autosuspends after 1s of idle time, reducing current consumption from
> > > 100 µA in active mode to 1 µA in standby mode as per the datasheet.
> > >
> > > Ensure that interrupts continue to be delivered with runtime PM.
> > > Since the LTR390 cannot be used as a wakeup source during runtime
> > > suspend, therefore increment the runtime PM refcount when enabling
> > > events and decrement it when disabling events or powering down.
> > > This prevents event loss while still allowing power savings when IRQs
> > > are unused.
> >
> > ...
> >
> > > +static int ltr390_read_raw(struct iio_dev *iio_device,
> > > +                          struct iio_chan_spec const *chan, int *val,
> > > +                          int *val2, long mask)
> >
> > Isn't the mask unsigned long? Jonathan, do we get this fixed already?
>
> Whilst it could (and probably should) be unsigned, it's not actually a mask.
> That naming is a historical mess up / evolution thing - long ago it was a bitmap.
> It is now the index of a bit in the mask.  So this is unrelated(ish) to the
> recent fixes around the actual bitmaps/bitmasks.
>
> Changing this one is a lot more painful than the recent fix to the infomask
> as it means changing the signature in every driver.
> I'm doubtful on whether this one is worth the churn.