linux-kernel - Re: [PATCH v2 07/22] iio: accel: adxl345: initialize IRQ number

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: <20241126174932.7987df3e@jic23-huawei>
Date: Tue, 26 Nov 2024 17:49:32 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Lothar Rubusch <l.rubusch@...il.com>
Cc: lars@...afoo.de, Michael.Hennerich@...log.com,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 eraretuya@...il.com
Subject: Re: [PATCH v2 07/22] iio: accel: adxl345: initialize IRQ number

On Tue, 26 Nov 2024 17:16:07 +0100
Lothar Rubusch <l.rubusch@...il.com> wrote:

> On Sun, Nov 24, 2024 at 7:14 PM Jonathan Cameron <jic23@...nel.org> wrote:
> >
> > On Sun, 17 Nov 2024 18:26:36 +0000
> > Lothar Rubusch <l.rubusch@...il.com> wrote:
> >  
> > > Add the possibility to claim an interrupt and init the state structure
> > > with interrupt number and interrupt line to use. The adxl345 can use
> > > two different interrupt lines, mainly to signal FIFO watermark events,
> > > single or double tap, activity, etc. Hence, having the interrupt line
> > > available is crucial to implement such features.  
> >
> > If there are two interrupt lines, you need to be more clever.
> > Imagine only one of them is wired. How do you know which one it is?
> >
> > The query needs to be done by name.  When there are multiple interrupts
> > the ones found in spi and i2c structures could be anything, so don't use
> > those.
> >
> > See fwnode_irq_get_by_name()  
> 
> One of my bigger question marks is this here: The sensor has two
> possible interrupt lines, INT1 or INT2, on which it will notify. But,
> only one is connected. Hence, the irq passed e.g. by SPI will
> automatically refer to the used one. Only this one is going to be
> configured as irq. Or, am I getting this wrong? Alternatively, no
> interrupt line is connected. This was the initial driver setup. In
> this case, it's generally BYPASS-mode for the FIFO and any further
> feature is not possible due to a lack of notification.
> 
> My questions now arise, when it comes to configure the IRQ line in the
> sensor registers. The sensor needs to be configured, that the used
> interrupt line for notifiction is INT1 or INT2. In the later patch of
> this series - "set interrupt line to INT1" - I init it with "INT1".
> But, this actually then can be configured. I can think of yet another
> /sysfs handle (could be dynamically changed at runtime, I'm not sure
> if this makes sense); by an additional devicetree binding (currently
> my preferred idea, I'd default to INT1, but let it configure to INT1
> or INT2 - or better default to bypass mode?), or is there an IIO way
> of configuring it to INT1/2, or a better way? I rather tend to DT. But
> this is still not part of this patch set.

> 
> Do I miss a point here and should still apply the
> fwnode_irq_get_by_name()? This looks a bit like the DT approach, isn't
> it?

Yes - this function does exactly what you need here (it is a very common
situation! Try grepping for INT2 and you should see examples)

To fill in the information you need:
1. Try getting INT1 by name. If succeeds use that and set config on basis INT1 is wired.
2. If not try getting INT2. If that succeeds then use INT2. 
3. If that fails no interrupts.

The binding should 'require' interrupt-names so that you always know
which one is which in the interrupt properties.

If the binding just had one interrupt before, then we add some text to say that
it is only valid if the provided interrupt is INT1.

Jonathan