lkml.org 
[lkml]   [2022]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject回复: [PATCH] ACPI: APEI: move edac init ah ead of ghes platform drv register
Date
Hi Kani,

> -----邮件原件-----
> 发件人: Kani, Toshi <toshi.kani@hpe.com>
> 发送时间: Tuesday, August 9, 2022 4:40 AM
> 收件人: Borislav Petkov <bp@alien8.de>; Rafael J. Wysocki
> <rafael@kernel.org>
> 抄送: Justin He <Justin.He@arm.com>; Len Brown <lenb@kernel.org>; James
> Morse <James.Morse@arm.com>; Tony Luck <tony.luck@intel.com>; Mauro
> Carvalho Chehab <mchehab@kernel.org>; Robert Richter <rric@kernel.org>;
> Shuai Xue <xueshuai@linux.alibaba.com>; Jarkko Sakkinen
> <jarkko@kernel.org>; ACPI Devel Maling List <linux-acpi@vger.kernel.org>;
> Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; open
> list:EDAC-CORE <linux-edac@vger.kernel.org>
> 主题: RE: [PATCH] ACPI: APEI: move edac_init ahead of ghes platform drv
> register
>
> On Monday, August 8, 2022 12:38 PM, Borislav Petkov wrote:
> > On Mon, Aug 08, 2022 at 08:17:58PM +0200, Rafael J. Wysocki wrote:
> > > This effectively makes EDAC depend on GHES which may not be always
> > > valid AFAICS.
> >
> > Yes, and this has been getting on my nerves since forever.
> >
> > The GHES code which does collect all those errors *forces* the
> > registration of an EDAC module which does only the reporting.
> >
> > Which cannot be any more backwards.
> >
> > What should happen is, GHES inits and starts working on the errors.
> > Then, at some point later, ghes_edac loads and starts reporting
> > whatever it gets. If there's no EDAC module, it doesn't report them.
> > The same way MCA works.
> >
> > That's it.
> >
> > And then ghes_edac can be made a normal module again and we can get
> > rid of this insanity.
>
> The following approach may be considerable:
> - Separate ghes_edac_register() into two functions, e.g., ghes_edac_register()
> and ghes_edac_init().
> - ghes_edac_register() only takes the first if-block with IS_ENABLED() &
> force_load check, and then calls a new function,
> edac_set_owner(mod_name), which simply sets mod_name to
> edac_mc_owner. This allows ghes_edac_register() to run before edac_init(),
> and sets edac_mc_owner to prevent chipset-specific edac driver to be loaded
> before ghes_edac.
> - ghes_edac_init() first calls edac_get_owner() to match with its mod_name.
> If so, it performs the rest of the original ghes_edac_register() procedure.
> This
> ghes_edac_init() is called from the normal module init path, e.g.,
> module_init().
Thanks for the suggestion, one gap is that under module_init path, how can we pass
the 2nd parameter of ghes_edac_register (struct device *dev) to the new
* ghes_edac_init()?

IIUC, the parameter of any functions under module_init() path should be void.


--
Cheers,
Justin (Jia He)


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
\
 
 \ /
  Last update: 2022-08-09 12:07    [W:0.091 / U:2.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site