linux-kernel - Re: [PATCH v7 3/7] dt-bindings: iio: accel: adxl345: add interrupt-names

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: <20241227-facebook-paralyze-275c075d37a2@spud>
Date: Fri, 27 Dec 2024 17:55:30 +0000
From: Conor Dooley <conor@...nel.org>
To: Lothar Rubusch <l.rubusch@...il.com>
Cc: Jonathan Cameron <jic23@...nel.org>, lars@...afoo.de,
	Michael.Hennerich@...log.com, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, devicetree@...r.kernel.org,
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
	eraretuya@...il.com
Subject: Re: [PATCH v7 3/7] dt-bindings: iio: accel: adxl345: add
 interrupt-names

On Wed, Dec 25, 2024 at 02:01:50PM +0100, Lothar Rubusch wrote:
> On Thu, Dec 19, 2024 at 7:21 PM Conor Dooley <conor@...nel.org> wrote:
> >
> > On Thu, Dec 19, 2024 at 05:58:15PM +0000, Jonathan Cameron wrote:
> > > On Sun, 15 Dec 2024 14:56:58 +0000
> > > Conor Dooley <conor@...nel.org> wrote:
> > >
> > > > On Sat, Dec 14, 2024 at 12:10:57PM +0000, Jonathan Cameron wrote:
> > > > > On Fri, 13 Dec 2024 21:19:05 +0000
> > > > > Lothar Rubusch <l.rubusch@...il.com> wrote:
> > > > >
> > > > > > Add interrupt-names INT1 and INT2 for the two interrupt lines of the
> > > > > > sensor.
> > > > > >
> > > > > > When one of the two interrupt lines is connected, the interrupt as its
> > > > > > interrupt-name, need to be declared in the devicetree. The driver then
> > > > > > configures the sensor to indicate its events on either INT1 or INT2.
> > > > > >
> > > > > > If no interrupt is configured, then no interrupt-name should be
> > > > > > configured, and vice versa. In this case the sensor runs in FIFO BYPASS
> > > > > > mode. This allows sensor measurements, but none of the sensor events.
> > > > > >
> > > > > > Signed-off-by: Lothar Rubusch <l.rubusch@...il.com>
> > > > >
> > > > > Just to repeat what I sent in reply to v6 (well after you'd posted this).
> > > > > Maybe we can maintain compatibility with the binding before this by adding
> > > > > a default of INT1.
> > > >
> > > > But can you make that assumption? If we did, and it's not universally
> > > > true, we break systems that had INT2 connected that previously worked.
> > >
> > > I guess there is a possibility of a driver in some other OS assuming INT2, but
> > > seems an odd 'default' choice.
> >
> > Ye, I think that it is unlikely a driver author would think that way.
> >
> > > Also odd for a writer of DT for a platform
> > > to assume it.
> >
> > I agree, I think it is unlikely that someone would assume it'd work like
> > this. I think a lack of attention paid to the schematic of the board is
> > a more likely culprit.
> >
> > > There is a thing that comes up in spec orgs when discussing whether to
> > > rush out an errata.  "Is this bug something people would get wrong
> > > thinking the answer was clear, or something where the would ask a question?"
> > > Anyone who thinks INT2 is the obvious choice for me falls into the would
> > > ask category.
> > >
> > > However, in the linux driver we would would go from assuming no interrupts
> > > to assuming the wrong one.  That's indeed bad.  So I guess this doesn't work.
> > > Oh well no default it is.
> >
> > I don't think you really lose anything from having no default. The
> > driver works just fine without the interrupt, so the albeit small risk
> > just doesn't seem worth it.
> 
> Agree. To be honest, I'm not sure if I catch the point here. IMHO,
> falling back to FIFO bypass should match with backward compatibility.
> Please let me know what I'm missing here.

Ye, falling back to the current behaviour is fine. The only problematic
thing is not checking "for a specified INT name" but assuming the
provided interrupt is either INT1 or INT2 when interrupt-names is not
provided.

> 
> I would prefer just to check for a specified INT name. Then configure
> the specified interrupt line in the probe. In this sense, the
> interrupt line is only useful also if the INT name is defined in the
> DT. If no INT name is specified, the iio driver will setup FIFO_BYPASS
> which is the legacy behavior (according to the datasheet: if none of
> the FIFO mode bits are set, defaults to bypass mode). This is the new
> behavior.
> 
> The old iio driver did not use interrupts at all. It stayed in
> FIFO_BYPASS mode (or did not change it, after power on, it assumes
> FIFO_BYPASS to my interpretation). Thus declaring the IRQ line yes or
> no, with or without INT names - for the iio driver implementation
> before this patch series, should not make any difference. It uses
> FIFO_BYPASS in all cases.
> 
> The input driver (AFAIR we already agreed on ignoring this driver)
> needed interrupts. Defining INT names here does not change anything,
> either. The input driver configures by default INT1 and simply ignores
> what was specified as INT names in the DT.
> 
> I cannot really think of any third case here. Please, let me know if
> I'm wrong. If not I will keep the above explained behavior, since to
> my understanding it should match the desired compatibility
> requirements. Am I wrong here?
> 
> Sorry for the late answer. Best,
> L

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)