linux-kernel - Re: [PATCH] iio: light: ltr390: Add 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] [day] [month] [year] [list]

Message-ID: <20250831160821.041ce895@jic23-huawei>
Date: Sun, 31 Aug 2025 16:08:21 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Akshay Jindal <akshayaj.lkd@...il.com>
Cc: anshulusr@...il.com, 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] iio: light: ltr390: Add runtime PM support

On Sun, 31 Aug 2025 01:19:39 +0530
Akshay Jindal <akshayaj.lkd@...il.com> wrote:

> On Sat, Aug 30, 2025 at 11:38 PM Jonathan Cameron <jic23@...nel.org> wrote:
> >
> > On Tue, 26 Aug 2025 02:29:12 +0530
> > Akshay Jindal <akshayaj.lkd@...il.com> wrote:
> > Normally we'd check the register to find out what whether the event
> > is enabled or not.  If we are asking for the state it is already in
> > then just return having done nothing.  If bus reads are an overhead
> > worth avoiding regcache will ensure we only do it once.
> >
> > Then if we are doing something, do the runtime pm get / put as appropriate.  
> 
> Hi Jonathan,
> I looked into the code of multiple drivers. Almost every other driver
> uses a flag
> inside driver specific data structure to denote whether events are enabled or
> disabled. Some use masks to mark which events are enabled in case multiple
> types of events are supported.
> For eg: bmc150, fxls8962af, kxcjk1013, ad7173, ad7291, ad799x, hi8435,
> max1363, nct7201, pac1921, palmas_adc, bd79124, ads1015, ad5421, bmg160,
> bmi323, inv_mpu6050, and the list goes on. I see this in at least 30+ drivers,
> maybe more.
> 
> On the other hand, regcache is used by only 4-5 drivers.
> 
> On the basis of the above arguments, I am strongly advocating the usage of
> irq_enabled flag in ltr390_data. Moreover, using register read to
> determine existing
> event config every time we do event configuration, seems to be an unnecessary
> burden on the bus and increases lines of code which I am finding it tough to
> convince myself for.

Alright I'll give in on this though I consider the regcache approach
superior in this case. It might also be applicable to a number of the above
but they are old drivers on the whole and I'm not going to pursue changing
this in those.  Some of those are IIRC conversions from pre regmap code
where they just didn't go as far as replacing the existing driver specific
state caching.

Anyhow, not worth arguing about.

Jonathan


> 
> Having said that, I have prepared a v3. Kindly give your feedback on it.
> 
> Thanks,
> Akshay.