These const tables are currently marked __devinitdata, but
Documentation/PCI/pci.txt says:

"o The ID table array should be marked __devinitconst; this is done
automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE()."

So use DEFINE_PCI_DEVICE_TABLE(x).

Based on PaX and earlier work by Andi Kleen.
Signed-off-by: NLionel Debroux <lionel_debroux@yahoo.fr>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

The original scrub rate API definition states that if scrub rate
accessors are not implemented, a negative value (-1) should be written
to the sysfs file (/sys/devices/system/edac/mc/mc<N>/sdram_scrub_rate,
where N is the memory controller number on the system). This is
counter-intuitive and awkward at the very least because, when setting
the scrub rate, userspace has to write to sysfs and then read it back to
check error status of the operation.

As Tony notes, best it would be to not have the sdram_scrub_rate in
sysfs if scrub rate support is not implemented. It is too late about
that and a bunch of drivers on a bunch of arches would need to be
changed and tested which is not a trivial task ATM.

Instead, settle for the next best thing of returning -ENODEV when
implementation is missing and -EINVAL when there was an error
encountered while setting the scrub rate.
Reported-by: NHan Pingtian <phan@redhat.com>
Cc: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/20110916105856.GA13253@hpt.nay.redhat.comSigned-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Fix DRAM chip select sizes calculation for K8, revisions D and E.

Reported-by: Niklas Söderlund <niklas.soderlund@ericsson.com
Link: http://lkml.kernel.org/r/1320849178-23340-1-git-send-email-niklas.soderlund@ericsson.comSigned-off-by: NBorislav Petkov <borislav.petkov@amd.com>

While initializing the array of csrow attribute instances, a few csrows
were uninitialized. This happened because the module only performed a
check for DRAM base ctl register0's and not DRAM base ctl register1's
chip select enable bit. There could be systems with DIMMs populated
on only single memory channel whereas the module also assumed that a
dual channel dimm had double the memory size of a single memory channel
instead of checking the memory on each channel.

This patch fixes these above issues.
Signed-off-by: NAshish Shenoy <ashenoy@riverbed.com>
Signed-off-by: NPrasanna S. Panchamukhi <ppanchamukhi@riverbed.com>
Link: http://lkml.kernel.org/r/4F459CFA.5090604@riverbed.comSigned-off-by: NBorislav Petkov <borislav.petkov@amd.com>

This provides unified readq()/writeq() helper functions for 32-bit
drivers.

For some cases, readq/writeq without atomicity is harmful, and order of
io access has to be specified explicitly.  So in this patch, new two
header files which contain non-atomic readq/writeq are added.

 - <asm-generic/io-64-nonatomic-lo-hi.h> provides non-atomic readq/
   writeq with the order of lower address -> higher address

 - <asm-generic/io-64-nonatomic-hi-lo.h> provides non-atomic readq/
   writeq with reversed order

This allows us to remove some readq()s that were added drivers when the
default non-atomic ones were removed in commit dbee8a0a ("x86:
remove 32-bit versions of readq()/writeq()")

The drivers which need readq/writeq but can do with the non-atomic ones
must add the line:

  #include <asm-generic/io-64-nonatomic-lo-hi.h> /* or hi-lo.h */

But this will be nop in 64-bit environments, and no other #ifdefs are
required.  So I believe that this patch can solve the problem of
 1. driver-specific readq/writeq
 2. atomicity and order of io access

This patch is tested with building allyesconfig and allmodconfig as
ARCH=x86 and ARCH=i386 on top of tip/master.

Cc: Kashyap Desai <Kashyap.Desai@lsi.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Ravi Anand <ravi.anand@qlogic.com>
Cc: Vikas Chaudhary <vikas.chaudhary@qlogic.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Jason Uhlenkott <juhlenko@akamai.com>
Cc: James Bottomley <James.Bottomley@parallels.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Roland Dreier <roland@purestorage.com>
Cc: James Bottomley <jbottomley@parallels.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NHitoshi Mitake <h.mitake@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Several fields in struct cpuinfo_x86 were not defined for the
!SMP case, likely to save space.  However, those fields still
have some meaning for UP, and keeping them allows some #ifdef
removal from other files.  The additional size of the UP kernel
from this change is not significant enough to worry about
keeping up the distinction:

	   text    data     bss     dec     hex filename
	4737168	 506459	 972040	6215667	 5ed7f3	vmlinux.o.before
	4737444	 506459	 972040	6215943	 5ed907	vmlinux.o.after

for a difference of 276 bytes for an example UP config.

If someone wants those 276 bytes back badly then it should
be implemented in a cleaner way.
Signed-off-by: NKevin Winchester <kjwinchester@gmail.com>
Cc: Steffen Persvold <sp@numascale.com>
Link: http://lkml.kernel.org/r/1324428742-12498-1-git-send-email-kjwinchester@gmail.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

After all sysdev classes are ported to regular driver core entities, the
sysdev implementation will be entirely removed from the kernel.

Cc: Doug Thompson <dougthompson@xmission.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

No functionality change, this is done so that in a follow-on patch all
queued-up MCEs can be decoded after registering on the chain.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

The below patch fixes some typos in various parts of the kernel, as well as fixes some comments.
Please let me know if I missed anything, and I will try to get it changed and resent.
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

compatible in dts has been changed, so the driver needs to be updated
accordingly.
Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The sb_edac driver is marginally useful on a 32-bit kernel, and
currently has 64-bit divide compile errors when building that config.
For now, make this build on only for 64-bit kernels.
Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The edac driver for Sandy Bridge was found to be reporting "FPM"
for edac_mode, which clearly doesn't make sense. It was found that
sb_edac.c:get_dimm_config was reusing a variable for both mem_type
and edac_type, and thus was overwriting the value after setting
it correctly. This patch fixes that issue.

Before the patch:
/sys/devices/system/edac/mc/mc0/csrow0/edac_mode:FPM
/sys/devices/system/edac/mc/mc0/csrow1/edac_mode:FPM
/sys/devices/system/edac/mc/mc0/csrow2/edac_mode:FPM
/sys/devices/system/edac/mc/mc0/csrow3/edac_mode:FPM

After:
/sys/devices/system/edac/mc/mc0/csrow0/edac_mode:S4ECD4ED
/sys/devices/system/edac/mc/mc0/csrow1/edac_mode:S4ECD4ED
/sys/devices/system/edac/mc/mc0/csrow2/edac_mode:S4ECD4ED
/sys/devices/system/edac/mc/mc0/csrow3/edac_mode:S4ECD4ED
Signed-off-by: NMark A. Grondona <mgrondona@llnl.gov>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some changes on it were required due to changeset cd90cc84c6bf0, that
changed the glue with the MCE logic.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This driver is known to work on mine and Tony's test environments,
using software error injection, and a partial hardware/software
error injection tool.

There's no broader range test yet to double check if the error decoding
logic will actually point to the right DIMM, so use it with care.
More tests are required to be sure that the driver will work on all
different types of memory configurations.

If you're willing to risk using it, I suggest you to enable EDAC debugs
for your test machines, as the debug logs helps to track what's going
inside the driver.

Please feed me with bug reports, if you notice that the driver
is miss-behaving.
Tested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The error cleanup logic was broken. Due to that, one error is generated for
every error polling.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

on i386:
	ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!\

In both get_sdram_scrub_rate() and set_sdram_scrub_rate()
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Get a more reliable DCLK value from DMI, name the SCRUBINTERVAL mask
and guard against potential overflow in the scrub rate computations.
Signed-off-by: NNils Carlson <nils.carlson@ericsson.com>

Both AMD and Intel i7 EDAC drivers use MCE features and are thus
dependent of this functionality present in the kernel. Express this in
Kconfig so that randconfig builds don't break.
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Nehalem-EX uses a different memory controller. However, as the
memory controller is not visible on some Nehalem/Nehalem-EP, we
need to indirectly probe via a X58 PCI device. The same devices
are found on (some) Nehalem-EX. So, on those machines, the
probe routine needs to return -ENODEV, as the actual Memory
Controller registers won't be detected.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remove edac_mce pieces and use the normal MCE decoder notifier chain by
retaining the same functionality with considerably less code.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This file really needs the full module.h header file present, but
was just getting it implicitly before.  Fix it up in advance so we
avoid build failures once the cleanup commit is present.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

mce->socketid and cpu_data(mce->cpu).phys_proc_id are the same,
compare with mce_setup (in mce.c):
	m->cpu = m->extcpu = smp_processor_id();
        ...
	m->socketid = cpu_data(m->extcpu).phys_proc_id;

This makes it easier for example for XEN patches to hook into
the MCE subsystem.
Compile tested on x86_64.
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: JBeulich@novell.com
CC: linux-edac@vger.kernel.org
CC: Mauro Carvalho Chehab <mchehab@redhat.com>

Xeon 35xx doesn't mention memory scrub. It seems that only Xeon 55xx
and above supports it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add scrubbing support to i7core_edac, tested on intel Xeon L5638.
Signed-off-by: NSamuel Gabrielsson <samuel.gabrielsson@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As we'll need to use those structs for trace functions, they should
be on a more public place. So, move struct mem_ctl_info & friends
to edac.h.

No functional changes on this patch.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NDoug Thompson <dougthompson@xmission.com>

Error injection needs the pci device 0:0. So, we need to revert
this changeset: 79daef20.

Tests need to be made to be sure that refcount won't be wrong
as noticed before.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

CC: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NDavid Sterba <dsterba@suse.cz>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

the clean up achieves:
  1. fix warning on 32-bit compile
  2. reorder info extraction for clarity
  3. add error-trap diagnostic message
  4. handle ALL modes of memory configurations
Signed-off-by: NArvind R. <arvino55@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Sparse complains that edac_cap was declared as dev_type and we are
returning edac_type.  Historically, edac_type was correct but since
then we have changed it to return a bit field.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: http://lkml.kernel.org/r/20111006063025.GA2615@mwandaSigned-off-by: NBorislav Petkov <borislav.petkov@amd.com>

When accessing the scrub rate control register (F3x58) on F15h, the DRAM
controller selector (F1x10C[DctCfgSel]) has to point to DCT0 so that the
scrub rate configuration can take effect. See Erratum 505 in the AMD
F15h revision guide for more details.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Drop third nbcfg argument which is old remains and not required anymore.

No functionality change.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

MCE decoding code is reporting the core which encountered the error
unconditionally now so drop this piece. Besides, it reported the
coreid in the local processor package which is not that valuable as a
datapoint.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

The MCi_STATUS bank has a AddrV bit which, when set, denotes that the
corresponding MCi_ADDR MSR contains a valid address belonging to the
MCE currently being reported. Dump it since it is definitely relevant
information.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Currently, correctable ECCs go through mcelog and do not print the scary
MCE banner. In that case, however, reporting the core where the CECC
happened is important information so dump it along with the decoded
string albeit at risk of having a minor redundancy.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

If second CPU is not enabled, CPC925 EDAC driver will spill out warnings
about errors on second Processor Interface. Support masking that out,
by detecting at runtime which CPUs are present in device tree.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Harry Ciao <qingtao.cao@windriver.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Based on a patch from the PaX Team, found during a clang analysis pass.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: stable@kernel.org [v2.6.35+]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>