linux-kernel - Re: [PATCH v1 06/12] iio: accel: adxl313: prepare interrupt handling

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: <aCzcskqKEXpM2jui@smile.fi.intel.com>
Date: Tue, 20 May 2025 22:49:06 +0300
From: Andy Shevchenko <andy@...nel.org>
To: Lothar Rubusch <l.rubusch@...il.com>
Cc: jic23@...nel.org, dlechner@...libre.com, nuno.sa@...log.com,
	corbet@....net, lucas.p.stankus@...il.com, lars@...afoo.de,
	Michael.Hennerich@...log.com, linux-iio@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 06/12] iio: accel: adxl313: prepare interrupt handling

On Tue, May 20, 2025 at 09:32:18PM +0200, Lothar Rubusch wrote:
> Hi Andy, I forgot to put my mail addresses as well. I copied your answer
> now from the mailing list archive. Hence, sorry for the bad formatting
> of this mail.
> 
> One question / remark down below.
> 
> > On Sun, May 18, 2025 at 11:13:15AM +0000, Lothar Rubusch wrote:
> > > Evaluate the devicetree property for an optional interrupt line, and
> > > configure the interrupt mapping accordingly. When no interrupt line
> > > is defined in the devicetree, keep the FIFO in bypass mode as before.

...

> > > +        ret = regmap_write(data->regmap, ADXL313_REG_INT_MAP, regval);
> >
> > Don't you want to use regmap_assign_bits() or something like this to have
> > the above ternary be included?
> 
> Thank you so much. I guess this is a function I was looking for quite
> a while and I know several places where to use it.
> 
> Anyway, I saw, my hardware test setup still runs on an older kernel
> w/o regmap_assign_bits().

You are going to upstream the driver, right? So, we don't care about old
kernels as there was no such code at all, and since it's not a fix for
backporting I see no impediments to use the modern APIs.

> So, I kindly liked to ask if you have any objections against leaving
> regmap_write() for now? Actually I'd prefer first to see the
> activity/inactivity stuff in, in case this will need some more
> modifications and I need to verify them on hardware. I think, leaving
> regmap_write() here would make that easier for this patch set. Please,
> let me know?

Ask maintainers. I will not object if they agree on your justification.

-- 
With Best Regards,
Andy Shevchenko