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: <20241219-pregame-blot-e15ff0fbfe45@spud>
Date: Thu, 19 Dec 2024 18:21:10 +0000
From: Conor Dooley <conor@...nel.org>
To: Jonathan Cameron <jic23@...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 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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ