Mostly all stubs, as the TLB is managed by the hypervisor.
Signed-off-by: Richard Kuo <rkuo@codeaurora.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Modules should be compiled as ordinary .o's; shared objects are not
supported.
Signed-off-by: Linas Vepstas <linas@codeaurora.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Richard Kuo <rkuo@codeaurora.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 0db3bfc72a (""HID: multitouch: decide if hid-multitouch
needs to handle mt devices").
The generic detection of hid-mt devices has two major flaws, and was
merged prematurely. Firstly, the hid-multitouch gets loaded even when
the device is handled by a special device. Secondly, the patch only
partially duplicates the device whitelist already present in hid-core,
effectively rendering a number of devices non-functional.
Reported-by: Sean Young <sean@mess.org>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It is not possible to take the lock in device if device is NULL.
The mutex_lock is thus moved after the NULL test. New error handling
labels are added at the end to differentiate between the cases where
different sets of locks should be unlocks, and between whether or not
reader should be freed (only on error).
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r@
expression E, E1;
identifier f;
statement S1,S2,S3;
@@
if (E == NULL)
{
... when != if (E == NULL || ...) S1 else S2
when != E = E1
*E->f
... when any
return ...;
}
else S3
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Mark A. Grondona <mgrondona@llnl.gov>
Signed-off-by: Mauro 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: Mauro 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: Tony Luck <tony.luck@intel.com>
Signed-off-by: Mauro 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: Mauro 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: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Mauro 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: Nils 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: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Mauro 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: Mauro Carvalho Chehab <mchehab@redhat.com>
