Re: [PATCH v4 1/3] dt-bindings: edac: xlnx,versal-ddrmc: Add xlnx,versal-xilsem compatible

[Michal Simek <michal.simek@amd.com>]

On 10/29/26 16:25, Borislav Petkov wrote:
> On Thu, Oct 29, 2026 at 03:52:35PM +0100, Michal Simek wrote:
>> Let me jump to it and start that discussion again
> 
> Sure, but pls trim your reply. I almost missed it from the gazillion pages of
> quoted text.

sorry about it.

> 
>> Please correct me if I am wrong but today edac core only checks that there
>> should be only one MC edac but there could be multiple EDAC devices.
> 
> An EDAC driver contains controls for all the RAS functionality in a platform.
> 
>> XILSEM edac device is present on Versal and Versal NET SOCs.
>> https://docs.amd.com/r/en-US/oslib_rm/Tool-Configuration-for-XilSEM
>> (Actually also on Versal Gen 2 but firmware interface is going to be different).
>>
>> I don't think we should try to integrate EDAC memory controller with EDAC
>> device because their usage is independent of each other.
> 
> Are you saying that you will have this XILSEM hw in different platforms?

yes. We have it on Versal SOC family (a72s) also on Versal NET family (a78s 16 
cores) and it is also present in Versal Gen 2 family (a78s 8cores or 4cores).

> 
> IOW, you will have a Versal or Versalnet thing and then something else, and
> then XILSEM will be in all of them?

yes hw is on all of them.

> 
> Then perhaps it is better to have it as a separate EDAC "driver". In air
> quotes because this is not really a driver but simply a wrapper so that it can
> be called an EDAC driver.
> 
> It all depends on what hw configurations will be built.
> 
> But if you have XILSEM *only* with Versal, then I don't want a separate EDAC,
> hm, driver.
> 
> I don't want to maintain a zoo of "EDAC drivers", each for the RAS
> functionality in a hw functional unit. IOW, I don't want to have:
> 
> AMD64_EDAC_L1
> AMD64_EDAC_L2
> AMD64_EDAC_L3
> AMD64_EDAC_DRAM
> AMD64_EDAC_SB
> ...
> 
> and whatever else hw blocks you can imagine which have RAS capability.
> 
> Makes sense?
I understand your intention but just trying to wrap my head around in connection 
to FPGAs.
If you look at Versal family based on a72. There is already EDAC device driver 
drivers/edac/a72_edac.c for L1/L2 from arm64 point of view via sysregs.

Then we have drivers/edac/versal_edac.c for memory controller.

Then this one for XILSEM for FPGA configuration memory and interconnect.

Then I can imagine that anybody can put another soft IP memory controller to 
programmable logic. And there could be more/different.

Not sure if HBM has own/different memory controller too.

It means with fpga it is already zoo of EDAC drivers already. It would be nice 
to have only one driver for all but it is hard to do with different MMIO access 
and complicated separate configurations.

With Versal Gen 2 which is still under development I can imagine that we can 
design it in a way that we say that we won't allow any MMIO interface and only 
firmware interface will be used and firmware itself will integrate all edacs in 
the system and export it via the same API. Then we will have only one single 
driver for the whole platform and it depends only on firmware which 
functionality is going to be exported to Linux. Which is IMHO model which you 
would like to see.

Obviously if there is a78 edac for L1/L2 which is using sysregs we can't do much 
about it.

Thanks,
Michal