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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241219175815.797b376a@jic23-huawei>
Date: Thu, 19 Dec 2024 17:58:15 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Conor Dooley <conor@...nel.org>
Cc: Lothar Rubusch <l.rubusch@...il.com>, 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 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.  Also odd for a writer of DT for a platform
to assume it.

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.

Jonathan

> 
> > Then you'd need to drop the dependency on interrupt-names.
> > 
> > I'm not sure though if the checking of number of entries will work against
> > a default. Give it a go and see what happens :)
> > 
> > We are lucky that we can't have bindings in the wild assuming ordering
> > of the two interrupts due to the maxItems being set for interrupts.
> > 
> > It's a messy corner, perhaps we should just not bother in the binding,
> > but keep that default handling in the driver?
> > 
> > DT binding folk, what do you think the best way of handling this is?