From: Ahmed Tiba <ahmed.tiba@arm.com>
To: will@kernel.org
Cc: linux-acpi@vger.kernel.org, devicetree@vger.kernel.org,
tony.luck@intel.com, bp@alien8.de, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, catalin.marinas@arm.com,
linux-arm-kernel@lists.infradead.org, rafael@kernel.org,
linux-doc@vger.kernel.org, Dmitry.Lamerov@arm.com,
Michael.Zhao2@arm.com, Ahmed.Tiba@arm.com
Subject: Re: [PATCH 11/12] ras: add DeviceTree estatus provider driver
Date: Fri, 19 Dec 2025 09:02:35 +0000 [thread overview]
Message-ID: <20251219090239.2692458-1-ahmed.tiba@arm.com> (raw)
In-Reply-To: <aUQbdZHkzumTnwVP@willie-the-truck>
On Thu, 18 Dec 2025 03:19:17PM +0000, Will Deacon wrote:
> On Thu, Dec 18, 2025 at 01:42:47PM +0000, Ahmed Tiba wrote:
>> On Thu, 18 Dec 2025 12:13:25PM +0000, Will Deacon wrote:
>> >> Introduce a platform driver that maps the CPER status block described
>> >> in DeviceTree, feeds it into the estatus core and handles either IRQ- or
>> >> poll-driven notifications. Arm64 gains a FIX_ESTATUS_IRQ slot so the
>> >> driver can safely map the shared buffer while copying records.
>> >>
>> >> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
>> >> ---
>> >> MAINTAINERS | 1 +
>> >> arch/arm64/include/asm/fixmap.h | 5 +
>> >> drivers/ras/Kconfig | 14 ++
>> >> drivers/ras/Makefile | 1 +
>> >> drivers/ras/estatus-dt.c | 318 ++++++++++++++++++++++++++++++++
>> >> include/linux/estatus.h | 3 +-
>> >> 6 files changed, 341 insertions(+), 1 deletion(-)
>> >> create mode 100644 drivers/ras/estatus-dt.c
>> >>
>> >> diff --git a/MAINTAINERS b/MAINTAINERS
>> >> index 6b2ef2ddc0c7..5567d5e82053 100644
>> >> --- a/MAINTAINERS
>> >> +++ b/MAINTAINERS
>> >> @@ -21761,6 +21761,7 @@ RAS ERROR STATUS
>> >> M: Ahmed Tiba <ahmed.tiba@arm.com>
>> >> S: Maintained
>> >> F: Documentation/devicetree/bindings/ras/arm,ras-ffh.yaml
>> >> +F: drivers/ras/estatus-dt.c
>> >> F: drivers/firmware/efi/estatus.c
>> >> F: include/linux/estatus.h
>> >>
>> >> diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
>> >> index 65555284446e..85ffba87bab9 100644
>> >> --- a/arch/arm64/include/asm/fixmap.h
>> >> +++ b/arch/arm64/include/asm/fixmap.h
>> >> @@ -64,6 +64,11 @@ enum fixed_addresses {
>> >> #endif
>> >> #endif /* CONFIG_ACPI_APEI_GHES */
>> >>
>> >> +#ifdef CONFIG_RAS_ESTATUS_DT
>> >> + /* Used for ESTATUS mapping from assorted contexts */
>> >> + FIX_ESTATUS_IRQ,
>> >> +#endif /* CONFIG_RAS_ESTATUS_DT */
>> >
>> > Why do we need this in addition to the four existing GHES slots? The DT
>> > code doesn't use it and I was assuming that the ACPI code would continue
>> > to use the existing irq; is that not the case?
>>
>>
>> We still need a dedicated slot when only the DT provider is built.
>> All four GHES slots are defined as part of the ACPI implementation,
>> so they are not present in a DT-only configuration.
>>
>> The estatus core always requests a fixmap index from each provider
>> before copying a CPER record. As a result, the DT driver must supply
>> its own slot to return a valid enum value to satisfy the common code.
>
> Sorry, but I still don't follow this. The DT code doesn't use the fixmap,
> does it? It looks like it maps the buffer ahead of time using
> devm_ioremap_resource() and then the accessors don't use the fixmap
> index at all, hence the horrible '(void)fixmap_idx;' cast which presumably
> stops the compiler from complaining about an unused variable.
Correct. The current DT driver keeps the CPER buffer permanently mapped with
devm_ioremap_resource() and that (void)fixmap_idx; line is just silencing
the warning. I’ll fix that by dropping the permanent mapping and copying the
status block via the fixmap entry, so the DT implementation mirrors GHES. That
gets rid of the cast and makes FIX_ESTATUS_IRQ do real work.
Thanks,
Ahmed
next prev parent reply other threads:[~2025-12-19 9:02 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-17 11:28 [PATCH 00/12] ras: share firmware-first estatus handling Ahmed Tiba
2025-12-17 11:28 ` [PATCH 01/12] ras: add estatus core interfaces Ahmed Tiba
2025-12-17 11:28 ` [PATCH 02/12] ras: add estatus core implementation Ahmed Tiba
2025-12-18 15:42 ` Mauro Carvalho Chehab
2025-12-19 14:35 ` Ahmed Tiba
2025-12-21 19:31 ` kernel test robot
2025-12-17 11:28 ` [PATCH 03/12] ras: add estatus vendor handling and processing Ahmed Tiba
2025-12-18 16:04 ` Mauro Carvalho Chehab
2025-12-19 14:49 ` Ahmed Tiba
2025-12-19 15:30 ` Mauro Carvalho Chehab
2025-12-19 18:11 ` Ahmed Tiba
2025-12-22 8:13 ` Mauro Carvalho Chehab
2025-12-29 15:01 ` Ahmed Tiba
2025-12-21 23:39 ` kernel test robot
2025-12-17 11:28 ` [PATCH 04/12] ras: add estatus queuing and IRQ/NMI handling Ahmed Tiba
2025-12-17 11:28 ` [PATCH 05/12] ras: flesh out estatus processing core Ahmed Tiba
2025-12-17 11:28 ` [PATCH 06/12] efi/cper: adopt estatus iteration helpers Ahmed Tiba
2025-12-17 11:28 ` [PATCH 07/12] ghes: prepare estatus hooks for shared handling Ahmed Tiba
2025-12-17 11:28 ` [PATCH 08/12] ghes: add estatus provider ops Ahmed Tiba
2025-12-17 11:28 ` [PATCH 09/12] ghes: route error handling through shared estatus core Ahmed Tiba
2025-12-17 11:28 ` [PATCH 10/12] dt-bindings: ras: document estatus provider Ahmed Tiba
2025-12-17 11:41 ` Krzysztof Kozlowski
2025-12-17 17:49 ` Ahmed Tiba
2025-12-18 6:48 ` Krzysztof Kozlowski
2025-12-18 10:22 ` Ahmed Tiba
2025-12-18 10:31 ` Ahmed Tiba
2025-12-19 9:53 ` Krzysztof Kozlowski
2025-12-19 10:37 ` Ahmed Tiba
2025-12-19 10:47 ` Ahmed Tiba
2025-12-17 11:28 ` [PATCH 11/12] ras: add DeviceTree estatus provider driver Ahmed Tiba
2025-12-18 12:13 ` Will Deacon
2025-12-18 13:42 ` Ahmed Tiba
2025-12-18 15:19 ` Will Deacon
2025-12-19 9:02 ` Ahmed Tiba [this message]
2025-12-19 13:00 ` Will Deacon
2025-12-19 17:21 ` Ahmed Tiba
2026-01-05 21:09 ` Will Deacon
2025-12-17 11:28 ` [PATCH 12/12] doc: ras: describe firmware-first estatus flow Ahmed Tiba
2025-12-21 1:35 ` [PATCH 00/12] ras: share firmware-first estatus handling Borislav Petkov
2025-12-29 11:54 ` Ahmed Tiba
2026-01-14 14:15 ` Borislav Petkov
2026-01-15 12:17 ` Ahmed Tiba
2026-01-20 11:15 ` Borislav Petkov
2026-01-26 10:58 ` Ahmed Tiba
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=20251219090239.2692458-1-ahmed.tiba@arm.com \
--to=ahmed.tiba@arm.com \
--cc=Dmitry.Lamerov@arm.com \
--cc=Michael.Zhao2@arm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=tony.luck@intel.com \
--cc=will@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