Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1702537
| 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 |
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 | Next — Previous in thread | Find similar | Unroll 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