[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200316121214.qb3nq22xsbiqaz3e@rric.localdomain>
Date: Mon, 16 Mar 2020 13:12:14 +0100
From: Robert Richter <rrichter@...vell.com>
To: Borislav Petkov <bp@...en8.de>
CC: Mauro Carvalho Chehab <mchehab@...nel.org>,
Tony Luck <tony.luck@...el.com>,
James Morse <james.morse@....com>,
Aristeu Rozanski <aris@...hat.com>,
<linux-edac@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/11] EDAC/ghes: Carve out MC device handling into
separate functions
On 16.03.20 10:31:34, Borislav Petkov wrote:
> On Fri, Mar 06, 2020 at 04:13:13PM +0100, Robert Richter wrote:
> > The functions are too long, carve out code that handles MC devices
> > into the new functions ghes_mc_create(), ghes_mc_add_or_free() and
> > ghes_mc_free(). Apart from better code readability the functions can
> > be reused and the implementation of the error paths becomes easier.
> >
> > Signed-off-by: Robert Richter <rrichter@...vell.com>
> > ---
> > drivers/edac/ghes_edac.c | 133 +++++++++++++++++++++++----------------
> > 1 file changed, 79 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
> > index 358519e8c2e9..5a4c9694bbff 100644
> > --- a/drivers/edac/ghes_edac.c
> > +++ b/drivers/edac/ghes_edac.c
> > @@ -462,16 +462,81 @@ static struct acpi_platform_list plat_list[] = {
> > { } /* End */
> > };
> >
> > -int ghes_edac_register(struct ghes *ghes, struct device *dev)
> > +static struct mem_ctl_info *ghes_mc_create(struct device *dev, int mc_idx,
> > + int num_dimm)
> > {
> > - bool fake = false;
> > - int rc = 0, num_dimm = 0;
> > + struct edac_mc_layer layers[1];
> > struct mem_ctl_info *mci;
> > struct ghes_mci *pvt;
> > - struct edac_mc_layer layers[1];
> > - struct ghes_dimm_fill dimm_fill;
> > +
> > + layers[0].type = EDAC_MC_LAYER_ALL_MEM;
> > + layers[0].size = num_dimm;
> > + layers[0].is_virt_csrow = true;
> > +
> > + mci = edac_mc_alloc(mc_idx, ARRAY_SIZE(layers), layers, sizeof(*pvt));
> > + if (!mci)
> > + return NULL;
> > +
> > + pvt = mci->pvt_info;
> > + pvt->mci = mci;
> > +
> > + mci->pdev = dev;
> > + mci->mtype_cap = MEM_FLAG_EMPTY;
> > + mci->edac_ctl_cap = EDAC_FLAG_NONE;
> > + mci->edac_cap = EDAC_FLAG_NONE;
> > + mci->mod_name = "ghes_edac.c";
> > + mci->ctl_name = "ghes_edac";
> > + mci->dev_name = "ghes";
> > +
> > + return mci;
> > +}
> > +
> > +static int ghes_mc_add_or_free(struct mem_ctl_info *mci)
>
> ghes_mc_add() is good enough. The fact that the function has error
> handling doesn't need to be in the name.
It's not just error handling here. I choose the name as the mci is
freed if it could not be added, which is different to just return an
error if it fails. Otherwise the flow would be something like:
mci = ghes_mc_create(...);
rc = ghes_mc_add(mci);
if (rc) {
ghes_mc_free(mci);
/* do something */
}
But we do not need mci any longer on error, so we can free it directly
which makes the code much easier, but in fact it does 2 things at a
time then:
mci = ghes_mc_create(...);
rc = ghes_mc_add_or_free(mci);
if (rc)
/* do something */
I would rather prefer ghes_mc_add_or_free().
-Robert
Powered by blists - more mailing lists