edac.txt: update information about newer Intel CPUs

There's a chapter at edac.rst written by the time Nehalem
support was added. Such information is used not only by the
Nehalem driver (i7core_edac), but by all newer Intel CPU
architectures that are supported by i7core_edac, sb_edac
and sbx_edac drivers.

Update the information to reflect that.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/Documentation/edac.txt b/Documentation/edac.txt
index fba1930..0c9161c 100644
--- a/Documentation/edac.txt
+++ b/Documentation/edac.txt
@@ -741,13 +741,25 @@
 http://bluesmoke.sourceforge.net project site for EDAC.
 
 
-Nehalem Usage of EDAC APIs
---------------------------
+Usage of EDAC APIs on Nehalem and newer Intel CPUs
+--------------------------------------------------
 
-Due to the way Nehalem exports Memory Controller data, some adjustments
-were done at i7core_edac driver. This chapter will cover those differences
+On older Intel architectures, the memory controller was part of the North
+Bridge chipset. Nehalem, Sandy Bridge, Ivy Bridge, Haswell, Sky Lake and
+newer Intel architectures integrated an enhanced version of the memory
+controller (MC) inside the CPUs.
 
-1) On Nehalem, there is one Memory Controller per Quick Patch Interconnect
+This chapter will cover the differences of the enhanced memory controllers
+found on newer Intel CPUs, such as ``i7core_edac``, ``sb_edac`` and
+``sbx_edac`` drivers.
+
+.. note::
+
+   The Xeon E7 processor families use a separate chip for the memory
+   controller, called Intel Scalable Memory Buffer. This section doesn't
+   apply for such families.
+
+1) There is one Memory Controller per Quick Patch Interconnect
    (QPI). At the driver, the term "socket" means one QPI. This is
    associated with a physical CPU socket.
 
@@ -757,7 +769,7 @@
 
    The minimum known unity is DIMMs. There are no information about csrows.
    As EDAC API maps the minimum unity is csrows, the driver sequentially
-   maps channel/dimm into different csrows.
+   maps channel/DIMM into different csrows.
 
    For example, supposing the following layout::
 
@@ -780,8 +792,8 @@
 
    Each QPI is exported as a different memory controller.
 
-2) Nehalem MC has the ability to generate errors. The driver implements this
-   functionality via some error injection nodes:
+2) The MC has the ability to inject errors to test drivers. The drivers
+   implement this functionality via some error injection nodes:
 
    For injecting a memory error, there are some sysfs nodes, under
    ``/sys/devices/system/edac/mc/mc?/``:
@@ -855,13 +867,14 @@
 
 	EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))
 
-3) Nehalem specific Corrected Error memory counters
+3) Corrected Error memory register counters
 
-   Nehalem have some registers to count memory errors. The driver uses those
-   registers to report Corrected Errors on devices with Registered Dimms.
+   Those newer MCs have some registers to count memory errors. The driver
+   uses those registers to report Corrected Errors on devices with Registered
+   DIMMs.
 
-   However, those counters don't work with Unregistered Dimms. As the chipset
-   offers some counters that also work with UDIMMS (but with a worse level of
+   However, those counters don't work with Unregistered DIMM. As the chipset
+   offers some counters that also work with UDIMMs (but with a worse level of
    granularity than the default ones), the driver exposes those registers for
    UDIMM memories.
 
@@ -896,8 +909,8 @@
 4) Standard error counters
 
    The standard error counters are generated when an mcelog error is received
-   by the driver. Since, with udimm, this is counted by software, it is
-   possible that some errors could be lost. With rdimm's, they display the
+   by the driver. Since, with UDIMM, this is counted by software, it is
+   possible that some errors could be lost. With RDIMM's, they display the
    contents of the registers
 
 Reference documents used on ``amd64_edac``
@@ -958,6 +971,7 @@
 * |copy| Mauro Carvalho Chehab
 
   - 05 Aug 2009	Nehalem interface
+  - 26 Oct 2016 Converted to ReST and cleanups at the Nehalem section
 
 * EDAC authors/maintainers: