Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1702537

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

From "Kani, Toshimitsu" <toshi.kani@hpe.com>
Newsgroups linux.kernel
Subject Re: [PATCH 3/3] EDAC, ghes: Make it a proper module
Date 2017-08-03 00:50 +0200
Message-ID <uaaCK-7MS-3@gated-at.bofh.it> (permalink)
References (3 earlier) <u8tJv-6SE-7@gated-at.bofh.it> <u9pku-2jJ-13@gated-at.bofh.it> <u9BYl-1SZ-1@gated-at.bofh.it> <u9PHX-2zV-13@gated-at.bofh.it> <u9Smu-4n4-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, 2017-08-02 at 05:18 +0200, Borislav Petkov wrote:
> On Wed, Aug 02, 2017 at 12:19:29AM +0000, Kani, Toshimitsu wrote:
> > 1. Device-probing-logic should belong to a driver, and should
> > remain private to a driver.  When we add the white-list, it should
> > be added to ghes_edac.
> 
> Nonsense. There are a lot of examples where driver probing depends on
> outside modalities like built-in quirks and such.
> 
> > 2. ghes_edac is an extension to the ghes driver as they both are
> > specific to ghes.  ghes_edac is merely ghes driver's edac error-
> > reporting wrapper than an independent edac driver.  It looks OK to
> > let ghes_edac get registered as part of ghes_probe() and leave it
> > as an unconventional edac driver.
> 
> Except that GHES wants to report into the EDAC infrastructure so it
> better has a wrapper for it.
> 
> One of the directions I explored when looking at this is to stick
> ghes_edac functionality into ghes.c or so and make it completely
> independent from EDAC. Would've been much cleaner.

Agreed. I think the current model aimed at this direction while it was
needed to depend on EDAC.

> > 3. EDAC does not have its managed probe-chain.  All edac drivers
> > are called from module_init list.  They independently probe the
> > hardware and get unloaded when not needed.  The core edac is simply
> > a set of library to them.  I think it's good to keep them
> > independent, and not to introduce a new central mechanism for a
> > special case like ghes_edac.
> 
> They're independent because before GHES we needed to load one driver
> per system. Until the bolted-on thing came. And it is bolted on
> because the already overwhelmed firmware decided to do error
> reporting too.
> 
> So the only real reason why I'm fine with keeping the current
> situation is the whitelist. Because then, we can at least control
> what loads and what not.
> 
> But then we need:
> 
> 1. A clean mechanism for the platform drivers to query whether
> another agent is loaded (ghes_edac) and not do any probing then.
> 
> 2. ghes_edac needs to drop that multiple probing thing as its
> dmi_walk(ghes_edac_count_dimms, &num_dimm) already probes *all* DIMMs
> on the system so no need to do that multiple times.

Sounds good. I will keep the current model and address the above
points.

Thanks,
-Toshi

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2017-07-31 22:20 +0200
  Re: [PATCH 3/3] EDAC, ghes: Make it a proper module Borislav Petkov <bp@alien8.de> - 2017-08-01 11:50 +0200
    Re: [PATCH 3/3] EDAC, ghes: Make it a proper module "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2017-08-02 02:30 +0200
      Re: [PATCH 3/3] EDAC, ghes: Make it a proper module Borislav Petkov <bp@alien8.de> - 2017-08-02 05:20 +0200
        Re: [PATCH 3/3] EDAC, ghes: Make it a proper module "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2017-08-03 00:50 +0200

csiph-web