Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 4月, 2017 4 次提交
    • B
      EDAC: Move edac_op_state to edac_mc.c · 8c22b4fe
      由 Borislav Petkov 提交于 
      ... as part of moving stuff away from edac_stub.c
Signed-off-by: NBorislav Petkov <bp@suse.de>
      8c22b4fe
    • B
      EDAC: Remove edac_err_assert · d3116a08
      由 Borislav Petkov 提交于 
      ... and the glue around it. It is not needed anymore.
Signed-off-by: NBorislav Petkov <bp@suse.de>
      d3116a08
    • B
      EDAC: Get rid of edac_handlers · 97bb6c17
      由 Borislav Petkov 提交于 
      Use mc_devices list instead to check whether we have EDAC driver
instances successfully registered with EDAC core.
Signed-off-by: NBorislav Petkov <bp@suse.de>
      97bb6c17
    • B
      x86/nmi, EDAC: Get rid of DRAM error reporting thru PCI SERR NMI · db47d5f8
      由 Borislav Petkov 提交于 
      Apparently, some machines used to report DRAM errors through a PCI SERR
NMI. This is why we have a call into EDAC in the NMI handler. See

  c0d12172 ("drivers/edac: add new nmi rescan").

From looking at the patch above, that's two drivers: e752x_edac.c and
e7xxx_edac.c. Now, I wanna say those are old machines which are probably
decommissioned already.

Tony says that "[t]the newest CPU supported by either of those drivers
is the Xeon E7520 (a.k.a. "Nehalem") released in Q1'2010. Possibly some
folks are still using these ... but people that hold onto h/w for 7
years generally cling to old s/w too ... so I'd guess it unlikely that
we will get complaints for breaking these in upstream."

So even if there is a small number still in use, we did load EDAC with
edac_op_state == EDAC_OPSTATE_POLL by default (we still do, in fact)
which means a default EDAC setup without any parameters supplied on the
command line or otherwise would never even log the error in the NMI
handler because we're polling by default:

  inline int edac_handler_set(void)
  {
         if (edac_op_state == EDAC_OPSTATE_POLL)
                 return 0;

         return atomic_read(&edac_handlers);
  }

So, long story short, I'd like to get rid of that nastiness called
edac_stub.c and confine all the EDAC drivers solely to drivers/edac/. If
we ever have to do stuff like that again, it should be notifiers we're
using and not some insanity like this one.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
      db47d5f8
  3. 11 12月, 2015 1 次提交
    • B
      EDAC: Rip out the edac_subsys reference counting · 733476cf
      由 Borislav Petkov 提交于 
      This was really dumb - reference counting for the main EDAC sysfs
object. While we could've simply registered it as the first thing in the
module init path and then hand it around to what needs it.

Do that and rip out all the code around it, thus simplifying the whole
handling significantly.

Move the edac_subsys node back to edac_module.c.
Signed-off-by: NBorislav Petkov <bp@suse.de>
      733476cf
  5. 30 5月, 2015 1 次提交
  7. 12 12月, 2013 1 次提交
  9. 30 10月, 2012 1 次提交
  11. 12 3月, 2012 1 次提交
    • P
      device.h: cleanup users outside of linux/include (C files) · 51990e82
      由 Paul Gortmaker 提交于 
      For files that are actively using linux/device.h, make sure
that they call it out.  This will allow us to clean up some
of the implicit uses of linux/device.h within include/*
without introducing build regressions.

Yes, this was created by "cheating" -- i.e. the headers were
cleaned up, and then the fallout was found and fixed, and then
the two commits were reordered.  This ensures we don't introduce
build regressions into the git history.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      51990e82
  13. 15 12月, 2011 1 次提交
  15. 27 7月, 2011 1 次提交
  17. 21 10月, 2010 1 次提交
  19. 20 7月, 2007 4 次提交