From: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2 2/7] EDAC/amd64: Recognize DRAM device type with EDAC_CTL_CAP
Date: Mon, 19 Aug 2019 20:19:16 +0000 [thread overview]
Message-ID: <SN6PR12MB26397171F6D504EE1F6F09FBF8A80@SN6PR12MB2639.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20190802074224.GB30661@zn.tnic>
> -----Original Message-----
> From: linux-edac-owner@vger.kernel.org <linux-edac-owner@vger.kernel.org> On Behalf Of Borislav Petkov
> Sent: Friday, August 2, 2019 2:42 AM
> To: Ghannam, Yazen <Yazen.Ghannam@amd.com>
> Cc: linux-edac@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 2/7] EDAC/amd64: Recognize DRAM device type with EDAC_CTL_CAP
>
> On Tue, Jul 09, 2019 at 09:56:55PM +0000, Ghannam, Yazen wrote:
> > From: Yazen Ghannam <yazen.ghannam@amd.com>
> >
> > AMD Family 17h systems support x4 and x16 DRAM devices. However, the
> > device type is not checked when setting EDAC_CTL_CAP.
> >
> > Set the appropriate EDAC_CTL_CAP flag based on the device type.
> >
> > Fixes: 2d09d8f301f5 ("EDAC, amd64: Determine EDAC MC capabilities on Fam17h")
>
> This is better: a patch which fixes a previous patch and is simple,
> small and clear. That you can tag with Fixes: just fine.
>
> > Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
> > ---
> > Link:
> > https://lkml.kernel.org/r/20190531234501.32826-4-Yazen.Ghannam@amd.com
> >
> > v1->v2:
> > * No change.
> >
> > drivers/edac/amd64_edac.c | 13 ++++++++++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> > index dd60cf5a3d96..125d6e2a828e 100644
> > --- a/drivers/edac/amd64_edac.c
> > +++ b/drivers/edac/amd64_edac.c
> > @@ -3150,12 +3150,15 @@ static bool ecc_enabled(struct pci_dev *F3, u16 nid)
> > static inline void
> > f17h_determine_edac_ctl_cap(struct mem_ctl_info *mci, struct amd64_pvt *pvt)
> > {
> > - u8 i, ecc_en = 1, cpk_en = 1;
> > + u8 i, ecc_en = 1, cpk_en = 1, dev_x4 = 1, dev_x16 = 1;
> >
> > for_each_umc(i) {
> > if (pvt->umc[i].sdp_ctrl & UMC_SDP_INIT) {
> > ecc_en &= !!(pvt->umc[i].umc_cap_hi & UMC_ECC_ENABLED);
> > cpk_en &= !!(pvt->umc[i].umc_cap_hi & UMC_ECC_CHIPKILL_CAP);
> > +
> > + dev_x4 &= !!(pvt->umc[i].dimm_cfg & BIT(6));
> > + dev_x16 &= !!(pvt->umc[i].dimm_cfg & BIT(7));
>
> Are those bits mutually exclusive?
>
> I.e., so that you can do:
>
> if (dev_x4)
> mci->edac_ctl_cap |= EDAC_FLAG_S4ECD4ED;
> else
> mci->edac_ctl_cap |= EDAC_FLAG_S16ECD16ED;
>
> ?
>
I don't think so. I believe they can both be zero. I'll verify and make the change if they are mutually exclusive.
Thanks,
Yazen
next prev parent reply other threads:[~2019-08-19 20:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-09 21:56 [PATCH v2 0/7] AMD64 EDAC fixes Ghannam, Yazen
2019-07-09 21:56 ` [PATCH v2 1/7] EDAC/amd64: Support more than two controllers for chip selects handling Ghannam, Yazen
2019-07-10 16:54 ` Phillips, Kim
2019-08-02 6:49 ` Borislav Petkov
2019-08-19 19:55 ` Ghannam, Yazen
2019-07-09 21:56 ` [PATCH v2 3/7] EDAC/amd64: Initialize DIMM info for systems with more than two channels Ghannam, Yazen
2019-07-09 21:56 ` [PATCH v2 2/7] EDAC/amd64: Recognize DRAM device type with EDAC_CTL_CAP Ghannam, Yazen
2019-08-02 7:42 ` Borislav Petkov
2019-08-19 20:19 ` Ghannam, Yazen [this message]
2019-07-09 21:56 ` [PATCH v2 4/7] EDAC/amd64: Find Chip Select memory size using Address Mask Ghannam, Yazen
2019-07-09 21:56 ` [PATCH v2 6/7] EDAC/amd64: Cache secondary Chip Select registers Ghannam, Yazen
2019-07-09 21:56 ` [PATCH v2 5/7] EDAC/amd64: Decode syndrome before translating address Ghannam, Yazen
2019-07-09 21:56 ` [PATCH v2 7/7] EDAC/amd64: Support Asymmetric Dual-Rank DIMMs Ghannam, Yazen
2019-08-02 14:46 ` [PATCH v2 0/7] AMD64 EDAC fixes Borislav Petkov
2019-08-15 20:08 ` Ghannam, Yazen
2019-08-16 6:47 ` 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=SN6PR12MB26397171F6D504EE1F6F09FBF8A80@SN6PR12MB2639.namprd12.prod.outlook.com \
--to=yazen.ghannam@amd.com \
--cc=bp@alien8.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).