From: "Farber, Eliav" <farbere@amazon.com>
To: Conor Dooley <conor@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>,
"Shenhar, Talel" <talel@amazon.com>,
Radu Rendec <radu@rendec.net>, Rob Herring <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 3/6] dt-bindings: interrupt-controller: amazon, al-fic: add error/fatal groups
Date: Sun, 27 Sep 2026 08:03:06 +0000 [thread overview]
Message-ID: <BY3PR18MB47223BF66D289D4AD9A77BEBC68E2@BY3PR18MB4722.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20260925-emit-activate-672c6e428fcb@spud>
On Fri, Sep 25, 2026 at 06:13:38PM +0100, Conor Dooley wrote:
> On Fri, Sep 25, 2026 at 10:24:38AM +0000, Farber, Eliav wrote:
> > Agreed, the message failed to describe the hardware. Here it is, and v2
> > will carry it.
>
> Cool. I won't pretend to understand all of what is written here, but it
> does assuage my concern that you were coming up with compatibles for
> the 0x2c and 0x34 registers. I'm not entirely sure that a compatible
> change is the right way to communicate which aspect of the device is
> being used - typically things like this get dedicated properties because
> AFAICT from the below the hardware is the same, just the output path
> differs, something like this incomplete diff:
Agreed, a property is the right fit. v2 does that.
One compatible (amazon,al-fic) and a new optional property,
amazon,al-fic-mask, enum [info, error, fatal], default info. No
amazon,al-fic-v2 fallback: a node describes one group, and the group
reports its revision in its own control register, so the driver reads it
rather than encoding it in a string. The default keeps existing
amazon,al-fic nodes behaving as they do today.
> The fallback does worry me a little though, since it'd operate the
> instances intended to be fatal or error as info, which would probably
> cause problems? Unless each has different output ports, and it's not
> controlling a mux to a single port, and the worst outcome then would be
> that nothing would ever be reported.
Right on the second half: they are different output ports, not a mux. A
group drives exactly one of three separate outputs (info, error, fatal),
each with its own mask register and its own aggregation tree to the GIC.
The property picks which mask register the driver programs; it does not
retarget a shared port.
That is also why there is no unsafe fallback. On the classic revision the
error and fatal masks do not exist, so asking for error or fatal there is
rejected at probe against the control register rather than silently
falling back to info.
The commit message now describes the hardware and the group granularity,
and the binding gains an example.
Thanks for the review.
Eliav
next prev parent reply other threads:[~2026-09-27 8:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 6:23 [PATCH 0/6] irqchip/al-fic: shared parent IRQ, FIC v2/v3 and affinity Eliav Farber
2026-09-24 6:23 ` [PATCH 1/6] irqchip/al-fic: use full node name and raise init log level Eliav Farber
2026-09-24 6:23 ` [PATCH 2/6] irqchip/al-fic: switch to shared parent interrupt Eliav Farber
2026-09-24 6:23 ` [PATCH 3/6] dt-bindings: interrupt-controller: amazon,al-fic: add error/fatal groups Eliav Farber
2026-09-24 17:13 ` Conor Dooley
2026-09-25 10:24 ` [PATCH 3/6] dt-bindings: interrupt-controller: amazon, al-fic: " Farber, Eliav
2026-09-25 17:13 ` Conor Dooley
2026-09-27 8:03 ` Farber, Eliav [this message]
2026-09-24 6:23 ` [PATCH 4/6] irqchip/al-fic: add support for FIC v2 Eliav Farber
2026-09-24 6:26 ` [PATCH 5/6] irqchip/al-fic: add support for FIC v3 Eliav Farber
2026-09-24 6:26 ` [PATCH 6/6] irqchip/al-fic: add irq_set_affinity callback Eliav Farber
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=BY3PR18MB47223BF66D289D4AD9A77BEBC68E2@BY3PR18MB4722.namprd18.prod.outlook.com \
--to=farbere@amazon.com \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=radu@rendec.net \
--cc=robh@kernel.org \
--cc=talel@amazon.com \
--cc=tglx@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
all inboxes | Powered by JetHome®