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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y7ME6KRv4Hrnt+z9@zn.tnic>
Date:   Mon, 2 Jan 2023 17:23:04 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     "Shenhar, Talel" <talel@...zon.com>
Cc:     krzysztof.kozlowski@...aro.org, talelshenhar@...il.com,
        shellykz@...zon.com, linux-edac@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: RFC on drivers/memory vs drivers/edac memory mapping for DDR
 Controller

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