Re: [RFC PATCH 00/11] soc: mediatek: add a DRAM ECC error handling driver

Re: [RFC PATCH 00/11] soc: mediatek: add a DRAM ECC error handling driver

[Jonathan Cameron]

On Mon, 2 Nov 2026 17:23:22 +0800
santino.wang <santino.wang@mediatek.com> wrote:

> From: Santino Wang <santino.wang@mediatek.com>
> 
> On the MediaTek mt8992 SoC the DRAM controller (DRAMC) raises an interrupt for
> every corrected (CE) and uncorrectable (UCE) ECC error. The interrupt is
> owned by the secure firmware (Arm Trusted Firmware at EL3). It reads the
> DRAMC error registers, applies the error containment policy and the CE
> storm protection, and hands the error to the OS firmware-first as an ACPI
> GHES record in a buffer that UEFI describes in the HEST. The OS is
> notified with an edge interrupt that the DSDT delivers through a Generic
> Event Device and a Hardware Error Device (GSIV notification).

So far this all sounds standard for asynchronous error reporting.
I'm assuming you have a something else for synchronous consumption.
From a Linux side of things we just care that error record shows up
and is signaled via GSIV (with normal Generic Event Device and Hardware
Error Device in the DSDT I guess)

> 
> The record carries a standard Platform Memory Error section and a
> MediaTek vendor section with the raw DRAMC error registers.

I'd like some details here on what those raw registers are bringing
to the OS wrt to handling these errors. 

What extra info?  I see you have a subchannel in there, but Memory
Error Section 2 brings that.  So why isn't this being reported
as a standard CPER?

> This series
> adds the driver that consumes the vendor section through the existing
> ghes_register_vendor_record_notifier() interface. No change to the GHES
> core or to arm64 code is needed.

Given a lot here doesn't sound mediatek specific it feels like it
shouldn't necessarily be in the vendor defined path.  More discussion
of why you have gone that way would be help.

> 
> The driver
>  - decodes the most severe error of a record and keeps counters, also
>    across boots in EFI variables,

Interesting.  How does this compare with just making it a userspace problem?
Perhaps you can't do that for some reason but it would take a lot to
convince me that it makes sense to have an upstream solution that relies
on custom EFI variable path.

>  - isolates pages with memory_failure(): immediately for a recoverable
>    UCE on memory that Linux manages, and for a page whose corrected
>    error count reaches a threshold (leaky bucket); memory owned by a
>    device is only reported to its owner,

This sounds standard, so I'm missing why you need a vendor driver for it.
Please provides some more info.

>  - lets in-kernel clients and user space (generic netlink, tracepoints)
>    follow the events,

Why your own netlink for this?  These are memory errors so I'd expect
existing paths to be sufficient, or perhaps there to be a need to
extend those as Pierre is doing with the Memory Error Section 2 series.

>  - exposes the containment policy, the storm protection and per range
>    severity overrides in sysfs and pushes them to the secure firmware
>    through a vendor SMC call,

The pushing of policy down to firmware is possibly something that needs
a custom driver.  I need to think a bit more on that and check a few things.
Input from Borislav or Tony might help here.

>  - after a fatal UCE (GHES panic and reset), finds the error in the BERT
>    of the next boot and reports it through the mc_event tracepoint.

If this were using the standard records that should just work. What
is missing that you need?

> 
> The driver depends on firmware that is not part of this series: the
> secure firmware provides the SMC interface used by patch 2 and writes the
> vendor section decoded by patch 4. The firmware side (the TF-A and
> edk2-platforms changes for the mt8992 SoC, plus the preloader that keeps
> the error across the reset) is being developed in the vendor's BSP trees
> and is not published yet.
> 
> Open question for this RFC: is drivers/soc/mediatek the right place for a
> driver that is built on GHES vendor records and a vendor SMC interface, or
> would the maintainers prefer another location?

You already got a reply on that. Almost nothing should ever go in drivers/soc
and definitely not something RAS related. +CC linux-edac, Borislav and Tony.

Anyhow, always interesting to discuss expanding what we do for
memory error handling, so I'll be interested to see what other feedback
this series gets.

Thanks,

Jonathan

> 
> Testing: each patch builds with the arm64 defconfig plus
> CONFIG_MTK_DRAM_ECC=m on linux-next 20261030 (W=1, no warnings).
> The series has been tested pre-silicon on a Palladium emulation platform.
> 
> Santino Wang (11):
>   soc: mediatek: dram-ecc: add the DRAM ECC driver skeleton
>   soc: mediatek: dram-ecc: add the SMC interface to the secure firmware
>   soc: mediatek: dram-ecc: add tracepoints
>   soc: mediatek: dram-ecc: handle GHES vendor records from the firmware
>   soc: mediatek: dram-ecc: add error counters and the address lists
>   soc: mediatek: dram-ecc: keep error counters across boots
>   soc: mediatek: dram-ecc: add containment policy and storm protection
>   soc: mediatek: dram-ecc: add the corrected error leaky bucket
>   soc: mediatek: dram-ecc: add a generic netlink event interface
>   soc: mediatek: dram-ecc: report an uncorrectable error of the previous
>     boot
>   Documentation: ABI: add the sysfs attributes of the MediaTek DRAM ECC
>     driver
> 
>  .../ABI/testing/sysfs-class-mtk-dram-ecc      | 182 +++++++++
>  MAINTAINERS                                   |  10 +
>  drivers/soc/mediatek/Kconfig                  |   2 +
>  drivers/soc/mediatek/Makefile                 |   1 +
>  drivers/soc/mediatek/dram-ecc/Kconfig         |  19 +
>  drivers/soc/mediatek/dram-ecc/Makefile        |   3 +
>  drivers/soc/mediatek/dram-ecc/core/Makefile   |  20 +
>  .../soc/mediatek/dram-ecc/core/addresses.c    |  88 ++++
>  .../soc/mediatek/dram-ecc/core/addresses.h    |  13 +
>  .../soc/mediatek/dram-ecc/core/bert_check.c   | 240 +++++++++++
>  .../soc/mediatek/dram-ecc/core/bert_check.h   |  12 +
>  drivers/soc/mediatek/dram-ecc/core/counters.c | 336 ++++++++++++++++
>  drivers/soc/mediatek/dram-ecc/core/counters.h |  29 ++
>  .../mediatek/dram-ecc/core/ghes_notifier.c    | 377 ++++++++++++++++++
>  .../mediatek/dram-ecc/core/ghes_notifier.h    |  22 +
>  drivers/soc/mediatek/dram-ecc/core/main.c     | 113 ++++++
>  .../soc/mediatek/dram-ecc/core/mtk_dram_ecc.h |  27 ++
>  .../dram-ecc/core/mtk_dram_ecc_event.h        |  47 +++
>  drivers/soc/mediatek/dram-ecc/core/netlink.c  |  83 ++++
>  drivers/soc/mediatek/dram-ecc/core/netlink.h  |  14 +
>  .../dram-ecc/core/policy/address_range.c      | 120 ++++++
>  .../dram-ecc/core/policy/containment.c        | 107 +++++
>  .../dram-ecc/core/policy/leaky_bucket.c       | 277 +++++++++++++
>  .../mediatek/dram-ecc/core/policy/policy.c    |  57 +++
>  .../mediatek/dram-ecc/core/policy/policy.h    |  23 ++
>  .../dram-ecc/core/policy/storm_protection.c   | 137 +++++++
>  drivers/soc/mediatek/dram-ecc/core/smc.c      | 137 +++++++
>  drivers/soc/mediatek/dram-ecc/core/smc.h      |  55 +++
>  drivers/soc/mediatek/dram-ecc/core/trace.c    |   6 +
>  drivers/soc/mediatek/dram-ecc/core/trace.h    | 119 ++++++
>  include/uapi/linux/mtk_dram_ecc_netlink.h     |  44 ++
>  31 files changed, 2720 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-mtk-dram-ecc
>  create mode 100644 drivers/soc/mediatek/dram-ecc/Kconfig
>  create mode 100644 drivers/soc/mediatek/dram-ecc/Makefile
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/Makefile
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/addresses.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/addresses.h
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/bert_check.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/bert_check.h
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/counters.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/counters.h
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/ghes_notifier.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/ghes_notifier.h
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/main.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/mtk_dram_ecc.h
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/mtk_dram_ecc_event.h
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/netlink.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/netlink.h
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/address_range.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/containment.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/leaky_bucket.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/policy.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/policy.h
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/storm_protection.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/smc.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/smc.h
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/trace.c
>  create mode 100644 drivers/soc/mediatek/dram-ecc/core/trace.h
>  create mode 100644 include/uapi/linux/mtk_dram_ecc_netlink.h
> 

Re: [RFC PATCH 00/11] soc: mediatek: add a DRAM ECC error handling driver

[Jonathan Cameron]

On Mon, 2 Nov 2026 12:36:42 -0800
Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> wrote:

> On Mon, 2 Nov 2026 17:23:22 +0800
> santino.wang <santino.wang@mediatek.com> wrote:
> 

+CC Mauro as well as I realized I asked about userspace part and
he may have input on that as well as on the kernel side of things.

> > From: Santino Wang <santino.wang@mediatek.com>
> > 
> > On the MediaTek mt8992 SoC the DRAM controller (DRAMC) raises an interrupt for
> > every corrected (CE) and uncorrectable (UCE) ECC error. The interrupt is
> > owned by the secure firmware (Arm Trusted Firmware at EL3). It reads the
> > DRAMC error registers, applies the error containment policy and the CE
> > storm protection, and hands the error to the OS firmware-first as an ACPI
> > GHES record in a buffer that UEFI describes in the HEST. The OS is
> > notified with an edge interrupt that the DSDT delivers through a Generic
> > Event Device and a Hardware Error Device (GSIV notification).  
> 
> So far this all sounds standard for asynchronous error reporting.
> I'm assuming you have a something else for synchronous consumption.
> From a Linux side of things we just care that error record shows up
> and is signaled via GSIV (with normal Generic Event Device and Hardware
> Error Device in the DSDT I guess)
> 
> > 
> > The record carries a standard Platform Memory Error section and a
> > MediaTek vendor section with the raw DRAMC error registers.  
> 
> I'd like some details here on what those raw registers are bringing
> to the OS wrt to handling these errors. 
> 
> What extra info?  I see you have a subchannel in there, but Memory
> Error Section 2 brings that.  So why isn't this being reported
> as a standard CPER?
> 
> > This series
> > adds the driver that consumes the vendor section through the existing
> > ghes_register_vendor_record_notifier() interface. No change to the GHES
> > core or to arm64 code is needed.  
> 
> Given a lot here doesn't sound mediatek specific it feels like it
> shouldn't necessarily be in the vendor defined path.  More discussion
> of why you have gone that way would be help.
> 
> > 
> > The driver
> >  - decodes the most severe error of a record and keeps counters, also
> >    across boots in EFI variables,  
> 
> Interesting.  How does this compare with just making it a userspace problem?
> Perhaps you can't do that for some reason but it would take a lot to
> convince me that it makes sense to have an upstream solution that relies
> on custom EFI variable path.
> 
> >  - isolates pages with memory_failure(): immediately for a recoverable
> >    UCE on memory that Linux manages, and for a page whose corrected
> >    error count reaches a threshold (leaky bucket); memory owned by a
> >    device is only reported to its owner,  
> 
> This sounds standard, so I'm missing why you need a vendor driver for it.
> Please provides some more info.
> 
> >  - lets in-kernel clients and user space (generic netlink, tracepoints)
> >    follow the events,  
> 
> Why your own netlink for this?  These are memory errors so I'd expect
> existing paths to be sufficient, or perhaps there to be a need to
> extend those as Pierre is doing with the Memory Error Section 2 series.
> 
> >  - exposes the containment policy, the storm protection and per range
> >    severity overrides in sysfs and pushes them to the secure firmware
> >    through a vendor SMC call,  
> 
> The pushing of policy down to firmware is possibly something that needs
> a custom driver.  I need to think a bit more on that and check a few things.
> Input from Borislav or Tony might help here.
> 
> >  - after a fatal UCE (GHES panic and reset), finds the error in the BERT
> >    of the next boot and reports it through the mc_event tracepoint.  
> 
> If this were using the standard records that should just work. What
> is missing that you need?
> 
> > 
> > The driver depends on firmware that is not part of this series: the
> > secure firmware provides the SMC interface used by patch 2 and writes the
> > vendor section decoded by patch 4. The firmware side (the TF-A and
> > edk2-platforms changes for the mt8992 SoC, plus the preloader that keeps
> > the error across the reset) is being developed in the vendor's BSP trees
> > and is not published yet.
> > 
> > Open question for this RFC: is drivers/soc/mediatek the right place for a
> > driver that is built on GHES vendor records and a vendor SMC interface, or
> > would the maintainers prefer another location?  
> 
> You already got a reply on that. Almost nothing should ever go in drivers/soc
> and definitely not something RAS related. +CC linux-edac, Borislav and Tony.
> 
> Anyhow, always interesting to discuss expanding what we do for
> memory error handling, so I'll be interested to see what other feedback
> this series gets.
> 
> Thanks,
> 
> Jonathan
> 
> > 
> > Testing: each patch builds with the arm64 defconfig plus
> > CONFIG_MTK_DRAM_ECC=m on linux-next 20261030 (W=1, no warnings).
> > The series has been tested pre-silicon on a Palladium emulation platform.
> > 
> > Santino Wang (11):
> >   soc: mediatek: dram-ecc: add the DRAM ECC driver skeleton
> >   soc: mediatek: dram-ecc: add the SMC interface to the secure firmware
> >   soc: mediatek: dram-ecc: add tracepoints
> >   soc: mediatek: dram-ecc: handle GHES vendor records from the firmware
> >   soc: mediatek: dram-ecc: add error counters and the address lists
> >   soc: mediatek: dram-ecc: keep error counters across boots
> >   soc: mediatek: dram-ecc: add containment policy and storm protection
> >   soc: mediatek: dram-ecc: add the corrected error leaky bucket
> >   soc: mediatek: dram-ecc: add a generic netlink event interface
> >   soc: mediatek: dram-ecc: report an uncorrectable error of the previous
> >     boot
> >   Documentation: ABI: add the sysfs attributes of the MediaTek DRAM ECC
> >     driver
> > 
> >  .../ABI/testing/sysfs-class-mtk-dram-ecc      | 182 +++++++++
> >  MAINTAINERS                                   |  10 +
> >  drivers/soc/mediatek/Kconfig                  |   2 +
> >  drivers/soc/mediatek/Makefile                 |   1 +
> >  drivers/soc/mediatek/dram-ecc/Kconfig         |  19 +
> >  drivers/soc/mediatek/dram-ecc/Makefile        |   3 +
> >  drivers/soc/mediatek/dram-ecc/core/Makefile   |  20 +
> >  .../soc/mediatek/dram-ecc/core/addresses.c    |  88 ++++
> >  .../soc/mediatek/dram-ecc/core/addresses.h    |  13 +
> >  .../soc/mediatek/dram-ecc/core/bert_check.c   | 240 +++++++++++
> >  .../soc/mediatek/dram-ecc/core/bert_check.h   |  12 +
> >  drivers/soc/mediatek/dram-ecc/core/counters.c | 336 ++++++++++++++++
> >  drivers/soc/mediatek/dram-ecc/core/counters.h |  29 ++
> >  .../mediatek/dram-ecc/core/ghes_notifier.c    | 377 ++++++++++++++++++
> >  .../mediatek/dram-ecc/core/ghes_notifier.h    |  22 +
> >  drivers/soc/mediatek/dram-ecc/core/main.c     | 113 ++++++
> >  .../soc/mediatek/dram-ecc/core/mtk_dram_ecc.h |  27 ++
> >  .../dram-ecc/core/mtk_dram_ecc_event.h        |  47 +++
> >  drivers/soc/mediatek/dram-ecc/core/netlink.c  |  83 ++++
> >  drivers/soc/mediatek/dram-ecc/core/netlink.h  |  14 +
> >  .../dram-ecc/core/policy/address_range.c      | 120 ++++++
> >  .../dram-ecc/core/policy/containment.c        | 107 +++++
> >  .../dram-ecc/core/policy/leaky_bucket.c       | 277 +++++++++++++
> >  .../mediatek/dram-ecc/core/policy/policy.c    |  57 +++
> >  .../mediatek/dram-ecc/core/policy/policy.h    |  23 ++
> >  .../dram-ecc/core/policy/storm_protection.c   | 137 +++++++
> >  drivers/soc/mediatek/dram-ecc/core/smc.c      | 137 +++++++
> >  drivers/soc/mediatek/dram-ecc/core/smc.h      |  55 +++
> >  drivers/soc/mediatek/dram-ecc/core/trace.c    |   6 +
> >  drivers/soc/mediatek/dram-ecc/core/trace.h    | 119 ++++++
> >  include/uapi/linux/mtk_dram_ecc_netlink.h     |  44 ++
> >  31 files changed, 2720 insertions(+)
> >  create mode 100644 Documentation/ABI/testing/sysfs-class-mtk-dram-ecc
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/Kconfig
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/Makefile
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/Makefile
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/addresses.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/addresses.h
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/bert_check.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/bert_check.h
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/counters.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/counters.h
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/ghes_notifier.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/ghes_notifier.h
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/main.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/mtk_dram_ecc.h
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/mtk_dram_ecc_event.h
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/netlink.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/netlink.h
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/address_range.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/containment.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/leaky_bucket.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/policy.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/policy.h
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/policy/storm_protection.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/smc.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/smc.h
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/trace.c
> >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/trace.h
> >  create mode 100644 include/uapi/linux/mtk_dram_ecc_netlink.h
> >   
> 

Re: [RFC PATCH 00/11] soc: mediatek: add a DRAM ECC error handling driver

[Santino Wang (王俊傑)]

On Mon, 2026-11-02 at 12:44 -0800, Jonathan Cameron wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On Mon, 2 Nov 2026 12:36:42 -0800
> Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> wrote:
> 
> > On Mon, 2 Nov 2026 17:23:22 +0800
> > santino.wang <santino.wang@mediatek.com> wrote:
> > 
> 
> +CC Mauro as well as I realized I asked about userspace part and
> he may have input on that as well as on the kernel side of things.

Hi Jonathan,

Thanks for the review. On our platform, memory is managed by Linux and
other subsystems. ECC errors from all of these subsystems are reported
to the Linux kernel, so the statistics must also cover memory outside
Linux MM's control. Error handling and retirement remain the
responsibility of the respective memory owner.

Our product requires the following seven counters. Based on our current
assessment, items 1–4 can be supported using existing infrastructure.
For items 5–7, could you recommend suitable existing interfaces, or
advise whether we need an MTK driver to implement them?

Here, volatile counts cover the current boot, while aggregate counts
accumulate across all boots. Items 5 and 6 require both the counts and
the incremental lists of pages successfully retired during the current
boot. Item 7 tracks pages awaiting retirement during the current boot.
On our platform, CE corresponds to single-bit ECC and UCE to double-bit
ECC.

1. Volatile DRAM Correctable

   We plan to use the GHES EDAC controller's `ce_count` for corrected
error reports during the current boot.

2. Volatile DRAM Uncorrectable

   There are two cases: recoverable UCE and fatal UCE. Recoverable UCE
reports can use EDAC's `ue_count`. Fatal UCE causes the system to
panic/reset, so we cannot collect it during the current boot. We will
record it from BERT at the next boot and count it under item 4,
Aggregate DRAM Uncorrectable.

3. Aggregate DRAM Correctable

   We plan to use rasdaemon to store the standard `ras:mc_event`
records in its SQLite database and retain them across boots. The
aggregate CE count will be calculated by summing `err_count` for
corrected events in the database.

4. Aggregate DRAM Uncorrectable

   Rasdaemon already collects recoverable UCE events through the
standard RAS tracepoints. For fatal UCE, we will develop our own
userspace tool to read BERT at the next boot and keep a count of fatal
UCE records. The aggregate UE count will include both recoverable and
fatal UCE records.

5. Retired Pages — Single Bit ECC

   When firmware reports that the CE threshold has been exceeded, we
add the affected page to the pending list in item 7. This includes
memory not managed by Linux MM. The memory owner handles retirement.
Only after the owner confirms successful retirement do we count the
page under this item and remove it from item 7. Otherwise, the page
remains pending.

   Firmware can set `CPER_SEC_ERROR_THRESHOLD_EXCEEDED` in the standard
Platform Memory Error section. However, `ghes_register_report_chain()`
passes only the record severity and `struct cper_sec_mem_err` payload,
without the section header flags. The existing EDAC `mc_event` does not
expose this flag either. A consumer of these reports can obtain the CE
address, when valid, but cannot tell whether the CE threshold has been
exceeded for that address.

   Would you recommend extending the standard GHES notifier or a
standard RAS event to expose this flag, or is there an existing
interface we should use? If no suitable existing interface is
available, would we need to develop an MTK driver to support this
functionality?

6. Retired Pages — Double Bit ECC

   On receiving a runtime recoverable UCE report with a valid physical
address, we immediately add the affected page to the pending list in
item 7. Only after its memory owner confirms successful retirement do
we count the page under this item and remove it from item 7. Otherwise,
the page remains pending.

   Standard GHES/EDAC reports provide the UCE events. For Linux-managed
memory, rasdaemon can also collect `ras:memory_failure_event` to obtain
the PFN and recovery result. Can this event be used to confirm
successful retirement, and if so, which recovery results indicate
success? If not, is there another existing interface we should use?

7. Pending Page Blacklist

   This is the number of pages awaiting retirement following CE
threshold-exceeded or UCE reports during the current boot. A page stays
pending until its owner confirms successful retirement; repeated
reports for the same page do not add another pending entry. This covers
Linux-managed RAM and memory managed by other subsystems.

   Which existing interfaces would you recommend for obtaining
retirement status from each memory owner? With that information
available, can items 5–7 be maintained in userspace, or would they
require support from an MTK driver?

Thanks,
Santino


> 
> > > From: Santino Wang <santino.wang@mediatek.com>
> > > 
> > > On the MediaTek mt8992 SoC the DRAM controller (DRAMC) raises an
> > > interrupt for
> > > every corrected (CE) and uncorrectable (UCE) ECC error. The
> > > interrupt is
> > > owned by the secure firmware (Arm Trusted Firmware at EL3). It
> > > reads the
> > > DRAMC error registers, applies the error containment policy and
> > > the CE
> > > storm protection, and hands the error to the OS firmware-first as
> > > an ACPI
> > > GHES record in a buffer that UEFI describes in the HEST. The OS
> > > is
> > > notified with an edge interrupt that the DSDT delivers through a
> > > Generic
> > > Event Device and a Hardware Error Device (GSIV notification).
> > 
> > So far this all sounds standard for asynchronous error reporting.
> > I'm assuming you have a something else for synchronous consumption.
> > From a Linux side of things we just care that error record shows up
> > and is signaled via GSIV (with normal Generic Event Device and
> > Hardware
> > Error Device in the DSDT I guess)
> > 
> > > 
> > > The record carries a standard Platform Memory Error section and a
> > > MediaTek vendor section with the raw DRAMC error registers.
> > 
> > I'd like some details here on what those raw registers are bringing
> > to the OS wrt to handling these errors.
> > 
> > What extra info?  I see you have a subchannel in there, but Memory
> > Error Section 2 brings that.  So why isn't this being reported
> > as a standard CPER?
> > 
> > > This series
> > > adds the driver that consumes the vendor section through the
> > > existing
> > > ghes_register_vendor_record_notifier() interface. No change to
> > > the GHES
> > > core or to arm64 code is needed.
> > 
> > Given a lot here doesn't sound mediatek specific it feels like it
> > shouldn't necessarily be in the vendor defined path.  More
> > discussion
> > of why you have gone that way would be help.
> > 
> > > 
> > > The driver
> > >  - decodes the most severe error of a record and keeps counters,
> > > also
> > >    across boots in EFI variables,
> > 
> > Interesting.  How does this compare with just making it a userspace
> > problem?
> > Perhaps you can't do that for some reason but it would take a lot
> > to
> > convince me that it makes sense to have an upstream solution that
> > relies
> > on custom EFI variable path.
> > 
> > >  - isolates pages with memory_failure(): immediately for a
> > > recoverable
> > >    UCE on memory that Linux manages, and for a page whose
> > > corrected
> > >    error count reaches a threshold (leaky bucket); memory owned
> > > by a
> > >    device is only reported to its owner,
> > 
> > This sounds standard, so I'm missing why you need a vendor driver
> > for it.
> > Please provides some more info.
> > 
> > >  - lets in-kernel clients and user space (generic netlink,
> > > tracepoints)
> > >    follow the events,
> > 
> > Why your own netlink for this?  These are memory errors so I'd
> > expect
> > existing paths to be sufficient, or perhaps there to be a need to
> > extend those as Pierre is doing with the Memory Error Section 2
> > series.
> > 
> > >  - exposes the containment policy, the storm protection and per
> > > range
> > >    severity overrides in sysfs and pushes them to the secure
> > > firmware
> > >    through a vendor SMC call,
> > 
> > The pushing of policy down to firmware is possibly something that
> > needs
> > a custom driver.  I need to think a bit more on that and check a
> > few things.
> > Input from Borislav or Tony might help here.
> > 
> > >  - after a fatal UCE (GHES panic and reset), finds the error in
> > > the BERT
> > >    of the next boot and reports it through the mc_event
> > > tracepoint.
> > 
> > If this were using the standard records that should just work. What
> > is missing that you need?
> > 
> > > 
> > > The driver depends on firmware that is not part of this series:
> > > the
> > > secure firmware provides the SMC interface used by patch 2 and
> > > writes the
> > > vendor section decoded by patch 4. The firmware side (the TF-A
> > > and
> > > edk2-platforms changes for the mt8992 SoC, plus the preloader
> > > that keeps
> > > the error across the reset) is being developed in the vendor's
> > > BSP trees
> > > and is not published yet.
> > > 
> > > Open question for this RFC: is drivers/soc/mediatek the right
> > > place for a
> > > driver that is built on GHES vendor records and a vendor SMC
> > > interface, or
> > > would the maintainers prefer another location?
> > 
> > You already got a reply on that. Almost nothing should ever go in
> > drivers/soc
> > and definitely not something RAS related. +CC linux-edac, Borislav
> > and Tony.
> > 
> > Anyhow, always interesting to discuss expanding what we do for
> > memory error handling, so I'll be interested to see what other
> > feedback
> > this series gets.
> > 
> > Thanks,
> > 
> > Jonathan
> > 
> > > 
> > > Testing: each patch builds with the arm64 defconfig plus
> > > CONFIG_MTK_DRAM_ECC=m on linux-next 20261030 (W=1, no warnings).
> > > The series has been tested pre-silicon on a Palladium emulation
> > > platform.
> > > 
> > > Santino Wang (11):
> > >   soc: mediatek: dram-ecc: add the DRAM ECC driver skeleton
> > >   soc: mediatek: dram-ecc: add the SMC interface to the secure
> > > firmware
> > >   soc: mediatek: dram-ecc: add tracepoints
> > >   soc: mediatek: dram-ecc: handle GHES vendor records from the
> > > firmware
> > >   soc: mediatek: dram-ecc: add error counters and the address
> > > lists
> > >   soc: mediatek: dram-ecc: keep error counters across boots
> > >   soc: mediatek: dram-ecc: add containment policy and storm
> > > protection
> > >   soc: mediatek: dram-ecc: add the corrected error leaky bucket
> > >   soc: mediatek: dram-ecc: add a generic netlink event interface
> > >   soc: mediatek: dram-ecc: report an uncorrectable error of the
> > > previous
> > >     boot
> > >   Documentation: ABI: add the sysfs attributes of the MediaTek
> > > DRAM ECC
> > >     driver
> > > 
> > >  .../ABI/testing/sysfs-class-mtk-dram-ecc      | 182 +++++++++
> > >  MAINTAINERS                                   |  10 +
> > >  drivers/soc/mediatek/Kconfig                  |   2 +
> > >  drivers/soc/mediatek/Makefile                 |   1 +
> > >  drivers/soc/mediatek/dram-ecc/Kconfig         |  19 +
> > >  drivers/soc/mediatek/dram-ecc/Makefile        |   3 +
> > >  drivers/soc/mediatek/dram-ecc/core/Makefile   |  20 +
> > >  .../soc/mediatek/dram-ecc/core/addresses.c    |  88 ++++
> > >  .../soc/mediatek/dram-ecc/core/addresses.h    |  13 +
> > >  .../soc/mediatek/dram-ecc/core/bert_check.c   | 240 +++++++++++
> > >  .../soc/mediatek/dram-ecc/core/bert_check.h   |  12 +
> > >  drivers/soc/mediatek/dram-ecc/core/counters.c | 336
> > > ++++++++++++++++
> > >  drivers/soc/mediatek/dram-ecc/core/counters.h |  29 ++
> > >  .../mediatek/dram-ecc/core/ghes_notifier.c    | 377
> > > ++++++++++++++++++
> > >  .../mediatek/dram-ecc/core/ghes_notifier.h    |  22 +
> > >  drivers/soc/mediatek/dram-ecc/core/main.c     | 113 ++++++
> > >  .../soc/mediatek/dram-ecc/core/mtk_dram_ecc.h |  27 ++
> > >  .../dram-ecc/core/mtk_dram_ecc_event.h        |  47 +++
> > >  drivers/soc/mediatek/dram-ecc/core/netlink.c  |  83 ++++
> > >  drivers/soc/mediatek/dram-ecc/core/netlink.h  |  14 +
> > >  .../dram-ecc/core/policy/address_range.c      | 120 ++++++
> > >  .../dram-ecc/core/policy/containment.c        | 107 +++++
> > >  .../dram-ecc/core/policy/leaky_bucket.c       | 277
> > > +++++++++++++
> > >  .../mediatek/dram-ecc/core/policy/policy.c    |  57 +++
> > >  .../mediatek/dram-ecc/core/policy/policy.h    |  23 ++
> > >  .../dram-ecc/core/policy/storm_protection.c   | 137 +++++++
> > >  drivers/soc/mediatek/dram-ecc/core/smc.c      | 137 +++++++
> > >  drivers/soc/mediatek/dram-ecc/core/smc.h      |  55 +++
> > >  drivers/soc/mediatek/dram-ecc/core/trace.c    |   6 +
> > >  drivers/soc/mediatek/dram-ecc/core/trace.h    | 119 ++++++
> > >  include/uapi/linux/mtk_dram_ecc_netlink.h     |  44 ++
> > >  31 files changed, 2720 insertions(+)
> > >  create mode 100644 Documentation/ABI/testing/sysfs-class-mtk-
> > > dram-ecc
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/Kconfig
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/Makefile
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/Makefile
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/addresses.c
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/addresses.h
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/bert_check.c
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/bert_check.h
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/counters.c
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/counters.h
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/ghes_notifier.c
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/ghes_notifier.h
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/main.c
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/mtk_dram_ecc.h
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/mtk_dram_ecc_event.h
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/netlink.c
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/netlink.h
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/policy/address_range.c
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/policy/containment.c
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/policy/leaky_bucket.c
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/policy/policy.c
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/policy/policy.h
> > >  create mode 100644 drivers/soc/mediatek/dram-
> > > ecc/core/policy/storm_protection.c
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/smc.c
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/smc.h
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/trace.c
> > >  create mode 100644 drivers/soc/mediatek/dram-ecc/core/trace.h
> > >  create mode 100644 include/uapi/linux/mtk_dram_ecc_netlink.h
> > > 
> > 
> 

Re: [RFC PATCH 00/11] soc: mediatek: add a DRAM ECC error handling driver

[Borislav Petkov]

On Thu, Nov 05, 2026 at 04:19:27AM +0000, Santino Wang (王俊傑) wrote:
> Which existing interfaces would you recommend for obtaining retirement
> status from each memory owner? With that information available, can items
> 5–7 be maintained in userspace, or would they require support from an MTK
> driver?

mm/memory-failure.c

Look how the others use it.

What you write above sounds like you need an EDAC driver which collects and
reports errors. Look at examples in drivers/edac/ and there's some
documentation in Documentation/edac/. Perhaps ask AI too.

If the stuff you need is not there, you can extend the existing interfaces by
justifying the extensions properly.

But what you have - a completely separate RAS implementation, homegrown
somewhere else in the kernel doesn't fly. I'm actually wondering how you even
managed to do this driver without *finding* all the RAS/EDAC glue we have in
the kernel. Googling for it would've told you that there's something...

HTH.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [RFC PATCH 00/11] soc: mediatek: add a DRAM ECC error handling driver

[Jonathan Cameron]

On Wed, 4 Nov 2026 20:53:21 -0800
Borislav Petkov <bp@alien8.de> wrote:

> On Thu, Nov 05, 2026 at 04:19:27AM +0000, Santino Wang (王俊傑) wrote:
> > Which existing interfaces would you recommend for obtaining retirement
> > status from each memory owner? With that information available, can items
> > 5–7 be maintained in userspace, or would they require support from an MTK
> > driver?  
> 
> mm/memory-failure.c
> 
> Look how the others use it.
> 
> What you write above sounds like you need an EDAC driver which collects and
> reports errors. Look at examples in drivers/edac/ and there's some
> documentation in Documentation/edac/. Perhaps ask AI too.
> 
> If the stuff you need is not there, you can extend the existing interfaces by
> justifying the extensions properly.
> 
> But what you have - a completely separate RAS implementation, homegrown
> somewhere else in the kernel doesn't fly. I'm actually wondering how you even
> managed to do this driver without *finding* all the RAS/EDAC glue we have in
> the kernel. Googling for it would've told you that there's something...
> 

I would add to this that if the standards don't work for you, consider changing
them.  These days it isn't that hard to get ACPI changed and they have a nice
code first path so discussion can take place on kernel mailing lists to refine
the idea before going to the standards org.

There is some overlap with things we will probably be proposing for ACPI in
the next few weeks. I'll make sure to +CC everyone in this thread on that
discussion.  Inputs form Mediatek (and ideally Borislav, Tony etc!)
should help refine that and avoid pitfalls that have made previous RAS ACPI
stuff less than ideal.

Jonathan

> HTH.
>