Em Wed, 14 Aug 2013 16:27:06 +0530 "Naveen N. Rao" <naveen.n.rao@xxxxxxxxxxxxxxxxxx> escreveu: > On 08/13/2013 11:28 PM, Borislav Petkov wrote: > > On Tue, Aug 13, 2013 at 11:02:08PM +0530, Naveen N. Rao wrote: > >> If I'm not mistaken, even for systems that have EDAC drivers, it looks > >> to me like EDAC can't really decode to the DIMM given what is provided > >> by the bios in the APEI report currently. If and when ghes_edac gains > >> this capability, users will have a choice between raw APEI reports vs. > >> edac processed ones. > > > > Which kinda makes that APEI tracepoint not really useful and we can call > > the one we have already - trace_mc_event - from APEI... > > This looks like a nice option. Mauro, what do you think? I considered calling trace_mc_event directly in APEI, before writing ghes_edac. I decided to implement it as a separate driver due to some reasons: 1) EDAC core needs to know that it should reject "hardware first" drivers. So, any solution would need to talk to EDAC core anyway (or we would need to write some other kind of resource allocation somewhere); 2) EDAC userspace would need to detect the type of memory. Even being crappy, the current way the memory is reported as a single contiguous block at sysfs. So, EDAC userspace is aware that it can't decode the DIMM; 3) If BIOS vendors add later some solution to enumerate the DIMMS per memory controller, channel, socket with APEI, the addition to the existing driver would be trivial. So, while it would work to just call the tracing at APEI, on the current way, I believe that having this part on a separate code is better. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
