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: [RFC PATCH v3 08/10] EDAC/amd64: Gather hardware information early
Date: Thu, 29 Aug 2019 11:22:41 +0200	[thread overview]
Message-ID: <20190829092241.GB1312@zn.tnic> (raw)
In-Reply-To: <20190821235938.118710-9-Yazen.Ghannam@amd.com>

On Thu, Aug 22, 2019 at 12:00:02AM +0000, Ghannam, Yazen wrote:
> From: Yazen Ghannam <yazen.ghannam@amd.com>
> 
> Split out gathering hardware information from init_one_instance() into a
> separate function get_hardware_info().
> 
> This is necessary so that the information can be cached earlier and used
> to check if memory is populated and if ECC is enabled on a node.
> 
> Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
> ---
>  drivers/edac/amd64_edac.c | 76 +++++++++++++++++++++++----------------
>  1 file changed, 45 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 4d1e6daa7ec4..84832771dec0 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -3405,34 +3405,17 @@ static void compute_num_umcs(void)
>  	edac_dbg(1, "Number of UMCs: %x", num_umcs);
>  }
>  
> -static int init_one_instance(unsigned int nid)
> +static int get_hardware_info(struct amd64_pvt *pvt,
> +			     struct amd64_family_type *fam_type)
>  {
> -	struct pci_dev *F3 = node_to_amd_nb(nid)->misc;
> -	struct amd64_family_type *fam_type = NULL;
> -	struct mem_ctl_info *mci = NULL;
> -	struct edac_mc_layer layers[2];
> -	struct amd64_pvt *pvt = NULL;
>  	u16 pci_id1, pci_id2;
> -	int err = 0, ret;
> -
> -	ret = -ENOMEM;
> -	pvt = kzalloc(sizeof(struct amd64_pvt), GFP_KERNEL);
> -	if (!pvt)
> -		goto err_ret;
> -
> -	pvt->mc_node_id	= nid;
> -	pvt->F3 = F3;
> -
> -	ret = -EINVAL;
> -	fam_type = per_family_init(pvt);
> -	if (!fam_type)
> -		goto err_free;
> +	int ret = -EINVAL;
>  
>  	if (pvt->fam >= 0x17) {
>  		pvt->umc = kcalloc(num_umcs, sizeof(struct amd64_umc), GFP_KERNEL);

Yeah, a get_hardware_info() function which does an allocation of that
struct amd64_umc on => F17 which is only 20 bytes. Just add it into the
pvt struct:

struct amd64_pvt {
	...
	struct amd64_umc umc;  /* UMC registers */
};

and be done with it. This should simplify the code flow here a bit and
20 bytes more per pvt is not a big deal.

And I know we do test "if (pvt->umc)" in a bunch of places but that can
be replaced with a "if (pvt->fam >= 0x17)" test which is equivalent.

And that conversion should be a single patch.

>  		if (!pvt->umc) {
>  			ret = -ENOMEM;
> -			goto err_free;
> +			goto err_ret;
>  		}
>  
>  		pci_id1 = fam_type->f0_id;
> @@ -3442,18 +3425,34 @@ static int init_one_instance(unsigned int nid)
>  		pci_id2 = fam_type->f2_id;
>  	}
>  
> -	err = reserve_mc_sibling_devs(pvt, pci_id1, pci_id2);
> -	if (err)
> +	ret = reserve_mc_sibling_devs(pvt, pci_id1, pci_id2);
> +	if (ret)
>  		goto err_post_init;
>  
>  	read_mc_regs(pvt);
>  
> +	return 0;
> +
> +err_post_init:
> +	if (pvt->fam >= 0x17)
> +		kfree(pvt->umc);
> +
> +err_ret:
> +	return ret;
> +}
> +
> +static int init_one_instance(struct amd64_pvt *pvt,
> +			     struct amd64_family_type *fam_type)

Yeah, that fam_type can be made global. No need to hand it around in
functions since it is going to be a single struct per system. Do that in
another, separate patch please.

After you've done those things, this patch would become a lot simpler.

Thx.

-- 
Regards/Gruss,
    Boris.

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

  reply	other threads:[~2019-08-29  9:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21 23:59 [PATCH v3 0/8] AMD64 EDAC fixes Ghannam, Yazen
2019-08-21 23:59 ` [PATCH v3 1/8] EDAC/amd64: Support more than two controllers for chip selects handling Ghannam, Yazen
2019-08-21 23:59 ` [PATCH v3 2/8] EDAC/amd64: Recognize DRAM device type with EDAC_CTL_CAP Ghannam, Yazen
2019-08-21 23:59 ` [PATCH v3 3/8] EDAC/amd64: Initialize DIMM info for systems with more than two channels Ghannam, Yazen
2019-08-21 23:59 ` [PATCH v3 4/8] EDAC/amd64: Find Chip Select memory size using Address Mask Ghannam, Yazen
2019-08-22  0:00 ` [PATCH v3 5/8] EDAC/amd64: Decode syndrome before translating address Ghannam, Yazen
2019-08-22  0:00 ` [PATCH v3 6/8] EDAC/amd64: Cache secondary Chip Select registers Ghannam, Yazen
2019-08-22  0:00 ` [RFC PATCH v3 08/10] EDAC/amd64: Gather hardware information early Ghannam, Yazen
2019-08-29  9:22   ` Borislav Petkov [this message]
2019-09-06 19:14     ` Ghannam, Yazen
2019-09-06 20:35       ` Borislav Petkov
2019-09-06 20:49         ` Ghannam, Yazen
2019-09-09 15:31           ` Borislav Petkov
2019-08-22  0:00 ` [PATCH v3 7/8] EDAC/amd64: Support Asymmetric Dual-Rank DIMMs Ghannam, Yazen
2019-08-23 11:26   ` Borislav Petkov
2019-08-23 13:27     ` Ghannam, Yazen
2019-08-23 15:11       ` Borislav Petkov
2019-08-22  0:00 ` [RFC PATCH v3 10/10] EDAC/amd64: Check for memory before fully initializing an instance Ghannam, Yazen
2019-08-22 18:51   ` [RFC PATCH v2] " Ghannam, Yazen
2019-08-22  0:00 ` [RFC PATCH v3 09/10] EDAC/amd64: Use cached data when checking for ECC Ghannam, Yazen
2019-08-22  0:50 ` [PATCH v3 0/8] AMD64 EDAC fixes Adam Borowski
2019-08-22  8:35   ` Borislav Petkov
2019-08-22  9:46     ` Adam Borowski
2019-08-22  9:55       ` Borislav Petkov
2019-08-22 18:54   ` Ghannam, Yazen
2019-08-23 15:28     ` Ghannam, Yazen
2019-08-23 15:37       ` Borislav Petkov
2019-08-26 14:19         ` Ghannam, Yazen
2019-08-26 14:59           ` Borislav Petkov
2019-08-26 15:05             ` Ghannam, Yazen
2019-08-22 18:48 ` [RFC PATCH v2] EDAC/amd64: Check for memory before fully initializing an instance Ghannam, Yazen

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=20190829092241.GB1312@zn.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.