All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] EDAC/amd64: Print ECC enabled/disabled for nodes with enabled MCs
Date: Wed, 28 Mar 2018 17:43:49 +0200	[thread overview]
Message-ID: <20180328154349.GD20533@pd.tnic> (raw)
In-Reply-To: <DM5PR12MB191699DD131B3EB4C11579DAF8A30@DM5PR12MB1916.namprd12.prod.outlook.com>

On Wed, Mar 28, 2018 at 02:38:11PM +0000, Ghannam, Yazen wrote:
> In either of those cases we won't get to debug_display_dimm_sizes*
> because we won't initialize the instance.

So you move that code which accesses csrows up so that it has the
required information to query DIMM state/presence.

>                 /* Assume UMC MCA banks are enabled. */
>                 nb_mce_en = true;

Also, I don't like that assumption.

> This would work for Fam17h. For older systems I think we can look at
> D18F2x94_dct[1:0][DisDramInterface]
> 
> Or maybe we have a separate function to check for enabled memory controllers
> before we check for ECC?

The best would be to have a function which checks whether DIMMs are
present on the node and act accordingly. You can pull up some of the
work of caching registers which are used in debug_display_dimm_sizes*
and use that info to get the required DIMM state upfront.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [1/3] EDAC/amd64: Print ECC enabled/disabled for nodes with enabled MCs
Date: Wed, 28 Mar 2018 17:43:49 +0200	[thread overview]
Message-ID: <20180328154349.GD20533@pd.tnic> (raw)

On Wed, Mar 28, 2018 at 02:38:11PM +0000, Ghannam, Yazen wrote:
> In either of those cases we won't get to debug_display_dimm_sizes*
> because we won't initialize the instance.

So you move that code which accesses csrows up so that it has the
required information to query DIMM state/presence.

>                 /* Assume UMC MCA banks are enabled. */
>                 nb_mce_en = true;

Also, I don't like that assumption.

> This would work for Fam17h. For older systems I think we can look at
> D18F2x94_dct[1:0][DisDramInterface]
> 
> Or maybe we have a separate function to check for enabled memory controllers
> before we check for ECC?

The best would be to have a function which checks whether DIMMs are
present on the node and act accordingly. You can pull up some of the
work of caching registers which are used in debug_display_dimm_sizes*
and use that info to get the required DIMM state upfront.

Thx.

  reply	other threads:[~2018-03-28 15:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 19:13 [PATCH 1/3] EDAC/amd64: Print ECC enabled/disabled for nodes with enabled MCs Yazen Ghannam
2018-03-21 19:13 ` [1/3] " Yazen Ghannam
2018-03-21 19:13 ` [PATCH 2/3] EDAC/amd64: Only remove instances that exist Yazen Ghannam
2018-03-21 19:13   ` [2/3] " Yazen Ghannam
2018-03-21 19:13 ` [PATCH 3/3] EDAC/amd64: Add DIMM device type for Fam17h Yazen Ghannam
2018-03-21 19:13   ` [3/3] " Yazen Ghannam
2018-03-28 13:00 ` [PATCH 1/3] EDAC/amd64: Print ECC enabled/disabled for nodes with enabled MCs Borislav Petkov
2018-03-28 13:00   ` [1/3] " Borislav Petkov
2018-03-28 14:38   ` [PATCH 1/3] " Ghannam, Yazen
2018-03-28 14:38     ` [1/3] " Yazen Ghannam
2018-03-28 15:43     ` Borislav Petkov [this message]
2018-03-28 15:43       ` Borislav Petkov
2018-03-28 15:59       ` [PATCH 1/3] " Ghannam, Yazen
2018-03-28 15:59         ` [1/3] " Yazen Ghannam

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=20180328154349.GD20533@pd.tnic \
    --to=bp@alien8.de \
    --cc=Yazen.Ghannam@amd.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.