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 --]
next prev parent 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