public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Lothar Rubusch <l.rubusch@gmail.com>,
	lars@metafoo.de, Michael.Hennerich@analog.com, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org, eraretuya@gmail.com
Subject: Re: [PATCH v7 3/7] dt-bindings: iio: accel: adxl345: add interrupt-names
Date: Sun, 15 Dec 2024 14:56:58 +0000	[thread overview]
Message-ID: <20241215-satisfied-expiring-9200ec935768@spud> (raw)
In-Reply-To: <20241214121057.5b12a236@jic23-huawei>

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

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@gmail.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@gmail.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.

> 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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2024-12-15 14:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-13 21:19 [PATCH v7 0/7] iio: accel: adxl345: add FIFO operating with IRQ triggered watermark events Lothar Rubusch
2024-12-13 21:19 ` [PATCH v7 1/7] iio: accel: adxl345: add function to switch measuring mode Lothar Rubusch
2024-12-14 11:33   ` Christophe JAILLET
2024-12-15  9:32     ` Lothar Rubusch
2024-12-14 12:02   ` Jonathan Cameron
2024-12-15  9:41     ` Lothar Rubusch
2024-12-15 14:10       ` Jonathan Cameron
2024-12-13 21:19 ` [PATCH v7 2/7] dt-bindings: iio: accel: adxl345: make interrupts not a required property Lothar Rubusch
2024-12-14 12:04   ` Jonathan Cameron
2024-12-16  7:45   ` Krzysztof Kozlowski
2024-12-13 21:19 ` [PATCH v7 3/7] dt-bindings: iio: accel: adxl345: add interrupt-names Lothar Rubusch
2024-12-13 22:42   ` Rob Herring (Arm)
2024-12-14 12:10   ` Jonathan Cameron
2024-12-15 14:56     ` Conor Dooley [this message]
2024-12-19 17:58       ` Jonathan Cameron
2024-12-19 18:21         ` Conor Dooley
2024-12-25 13:01           ` Lothar Rubusch
2024-12-27 17:55             ` Conor Dooley
2024-12-13 21:19 ` [PATCH v7 4/7] iio: accel: adxl345: introduce interrupt handling Lothar Rubusch
2024-12-14 12:16   ` Jonathan Cameron
2024-12-13 21:19 ` [PATCH v7 5/7] iio: accel: adxl345: initialize FIFO delay value for SPI Lothar Rubusch
2024-12-13 21:19 ` [PATCH v7 6/7] iio: accel: adxl345: add FIFO with watermark events Lothar Rubusch
2024-12-14 12:36   ` Jonathan Cameron
2024-12-25 18:13     ` Lothar Rubusch
2024-12-13 21:19 ` [PATCH v7 7/7] iio: accel: adxl345: complete the list of defines Lothar Rubusch
2024-12-14 12:39   ` Jonathan Cameron
2024-12-25 16:59     ` Lothar Rubusch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241215-satisfied-expiring-9200ec935768@spud \
    --to=conor@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=eraretuya@gmail.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=l.rubusch@gmail.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox