[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <154454fe-2cbd-4432-ae44-634b1624504a@web.de>
Date: Wed, 20 Dec 2023 17:15:40 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Yazen Ghannam <yazen.ghannam@....com>, Borislav Petkov <bp@...en8.de>,
linux-edac@...r.kernel.org, kernel-janitors@...r.kernel.org
Cc: LKML <linux-kernel@...r.kernel.org>, Avadhut Naik <avadhut.naik@....com>,
Christophe Jaillet <christophe.jaillet@...adoo.fr>,
John Allen <john.allen@....com>, Muralidhara M K <muralidhara.mk@....com>,
Tony Luck <tony.luck@...el.com>, William Roche <william.roche@...cle.com>
Subject: Re: [PATCH v4 1/3] RAS: Introduce AMD Address Translation Library
…
> +++ b/drivers/ras/amd/atl/core.c
> @@ -0,0 +1,225 @@
…
> +unsigned long norm_to_sys_addr(u8 socket_id, u8 die_id, u8 coh_st_inst_id, unsigned long addr)
> +{
…
> + if (!late_hole_remove(&ctx) && add_base_and_hole(&ctx))
> + return -EINVAL;
> +
> + if (dehash_address(&ctx))
> + return -EINVAL;
> +
> + if (late_hole_remove(&ctx) && add_base_and_hole(&ctx))
> + return -EINVAL;
…
> + return ctx.ret_addr;
> +}
…
I wonder which condition checks should actually be used for such
a function implementation.
How do you think about to avoid also the specification of duplicate
return statements here?
Regards,
Markus
Powered by blists - more mailing lists