The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Shenhar, Talel" <talel@amazon.com>
To: Borislav Petkov <bp@alien8.de>
Cc: <krzysztof.kozlowski@linaro.org>, <talelshenhar@gmail.com>,
	<shellykz@amazon.com>, <linux-edac@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: RFC on drivers/memory vs drivers/edac memory mapping for DDR Controller
Date: Mon, 2 Jan 2023 18:14:04 +0200	[thread overview]
Message-ID: <4d5eead4-c5f6-f852-9e77-35177887ad22@amazon.com> (raw)
In-Reply-To: <Y7LfhB5IrLcFzPOi@zn.tnic>


On 1/2/2023 3:43 PM, Borislav Petkov wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Mon, Jan 02, 2023 at 02:17:24PM +0200, Shenhar, Talel wrote:
>> * We want to introduce driver that reads DDR controller RAS register and
>> notify for ECC errors by using EDAC MC API found in drivers/edac.
>> * We also want to have a capability to dynamically change DDR refresh rate
>> based on thermal values (best to be done in drivers/memory ?).
> Is there any particular reason to want to report the errors through EDAC?
>
> Or can't you simply read the RAS register in your memory driver and dump error
> info from there so that you have a single driver that does it all?

Doesn't it go against the MC EDAC concept...?

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 :)  )

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.

>
> --
> Regards/Gruss,
>      Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette

  reply	other threads:[~2023-01-02 16:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-02 12:17 RFC on drivers/memory vs drivers/edac memory mapping for DDR Controller Shenhar, Talel
2023-01-02 12:47 ` Krzysztof Kozlowski
2023-01-02 13:44   ` Shenhar, Talel
2023-01-02 13:59     ` Krzysztof Kozlowski
2023-01-02 16:21       ` Shenhar, Talel
2023-01-02 16:25         ` Krzysztof Kozlowski
2023-01-03 13:12           ` Shenhar, Talel
2023-01-03 13:23             ` Krzysztof Kozlowski
2023-01-03 13:47               ` Shenhar, Talel
2023-01-03 14:02                 ` Krzysztof Kozlowski
2023-01-03 14:24                 ` Krzysztof Kozlowski
2023-01-03 14:34                   ` Shenhar, Talel
2023-01-02 13:43 ` Borislav Petkov
2023-01-02 16:14   ` Shenhar, Talel [this message]
2023-01-02 16:23     ` Borislav Petkov

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=4d5eead4-c5f6-f852-9e77-35177887ad22@amazon.com \
    --to=talel@amazon.com \
    --cc=bp@alien8.de \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shellykz@amazon.com \
    --cc=talelshenhar@gmail.com \
    /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