Re: RFC on drivers/memory vs drivers/edac memory mapping for DDR Controller

[Borislav Petkov]

On Mon, Jan 02, 2023 at 06:14:04PM +0200, Shenhar, Talel wrote:
> Doesn't it go against the MC EDAC concept...?

You mean the concept of a glorified error reporter? :-)

> Reinventing the wheel is something that usually doesn't end well. (I could
> probably list them but guess that as the EDAC maintainer you can do it
> better than me :)  )

You mean EDAC maintainer because no one else is willing to do it?

See, I don't mind if errors get reported through EDAC but the EDAC "facilities"
are just a reporting mechanism and memory controller layout detection glue.
Yeah, yeah, it can set scrub rate and so on in some drivers but it really is
just that. Oh, and some EDAC drivers provide a simple interrupt handler when the
hw reports errors with a special interrupt.

But, if in your case we get to end up in some weird resources sharing scheme,
then you don't really need the design overhead and you can simply printk the
errors from the other driver.

> I would probably consider the other way around - take the refresh-rate
> driver inside the MC driver as the refresh-rate does not use any "memory"
> framework under drivers/memory.

That is also possible.

The x86 EDAC drivers do get to change settings in the memory controller as a
result of RAS actions because there nothing else "owns" that memory controller.

But I have no clue what your hw does so...

-- 
Regards/Gruss,
    Boris.

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