kernel/drivers/edac, branch linux-5.7.y

EDAC/{i7core,sb,pnd2,skx}: Fix error event severity

2020-08-26T09:42:23Z

commit 45bc6098a3e279d8e391d22428396687562797e2 upstream. IA32_MCG_STATUS.RIPV indicates whether the return RIP value pushed onto the stack as part of machine check delivery is valid or not. Various drivers copied a code fragment that uses the RIPV bit to determine the severity of the error as either HW_EVENT_ERR_UNCORRECTED or HW_EVENT_ERR_FATAL, but this check is reversed (marking errors where RIPV is set as "FATAL"). Reverse the tests so that the error is marked fatal when RIPV is not set. Reported-by: Gabriele Paoloni Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20200707194324.14884-1-tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman

EDAC: Fix reference count leaks

2020-08-19T06:23:26Z

[ Upstream commit 17ed808ad243192fb923e4e653c1338d3ba06207 ] When kobject_init_and_add() returns an error, it should be handled because kobject_init_and_add() takes a reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Therefore, replace calling kfree() and call kobject_put() and add a missing kobject_put() in the edac_device_register_sysfs_main_kobj() error path. [ bp: Massage and merge into a single patch. ] Fixes: b2ed215a3338 ("Kobject: change drivers/edac to use kobject_init_and_add") Signed-off-by: Qiushi Wu Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200528202238.18078-1-wu000273@umn.edu Link: https://lkml.kernel.org/r/20200528203526.20908-1-wu000273@umn.edu Signed-off-by: Sasha Levin

EDAC/amd64: Read back the scrub rate PCI register on F15h

2020-06-30T19:36:31Z

commit ee470bb25d0dcdf126f586ec0ae6dca66cb340a4 upstream. Commit: da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h") added support for F15h, model 0x60 CPUs but in doing so, missed to read back SCRCTRL PCI config register on F15h CPUs which are *not* model 0x60. Add that read so that doing $ cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate can show the previously set DRAM scrub rate. Fixes: da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h") Reported-by: Anders Andersson Signed-off-by: Borislav Petkov Cc: #v4.4.. Link: https://lkml.kernel.org/r/CAKkunMbNWppx_i6xSdDHLseA2QQmGJqj_crY=NF-GZML5np4Vw@mail.gmail.com Signed-off-by: Greg Kroah-Hartman

EDAC/amd64: Add AMD family 17h model 60h PCI IDs

2020-06-22T07:33:03Z

commit b6bea24d41519e8c31e4798f1c1a3f67e540c5d0 upstream. Add support for AMD Renoir (4000-series Ryzen CPUs). Signed-off-by: Alexander Monakov Signed-off-by: Borislav Petkov Acked-by: Yazen Ghannam Link: https://lkml.kernel.org/r/20200510204842.2603-4-amonakov@ispras.ru Signed-off-by: Greg Kroah-Hartman

EDAC/skx: Use the mcmtr register to retrieve close_pg/bank_xor_enable

2020-06-17T14:43:00Z

commit 1032095053b34d474aa20f2625d97dd306e0991b upstream. The skx_edac driver wrongly uses the mtr register to retrieve two fields close_pg and bank_xor_enable. Fix it by using the correct mcmtr register to get the two fields. Cc: Signed-off-by: Qiuxu Zhuo Reported-by: Matthew Riley Acked-by: Aristeu Rozanski Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20200515210146.1337-1-tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman

Merge branch 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2020-03-30T23:40:08Z

Pull perf updates from Ingo Molnar: "The main changes in this cycle were: Kernel side changes: - A couple of x86/cpu cleanups and changes were grandfathered in due to patch dependencies. These clean up the set of CPU model/family matching macros with a consistent namespace and C99 initializer style. - A bunch of updates to various low level PMU drivers: * AMD Family 19h L3 uncore PMU * Intel Tiger Lake uncore support * misc fixes to LBR TOS sampling - optprobe fixes - perf/cgroup: optimize cgroup event sched-in processing - misc cleanups and fixes Tooling side changes are to: - perf {annotate,expr,record,report,stat,test} - perl scripting - libapi, libperf and libtraceevent - vendor events on Intel and S390, ARM cs-etm - Intel PT updates - Documentation changes and updates to core facilities - misc cleanups, fixes and other enhancements" * 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (89 commits) cpufreq/intel_pstate: Fix wrong macro conversion x86/cpu: Cleanup the now unused CPU match macros hwrng: via_rng: Convert to new X86 CPU match macros crypto: Convert to new CPU match macros ASoC: Intel: Convert to new X86 CPU match macros powercap/intel_rapl: Convert to new X86 CPU match macros PCI: intel-mid: Convert to new X86 CPU match macros mmc: sdhci-acpi: Convert to new X86 CPU match macros intel_idle: Convert to new X86 CPU match macros extcon: axp288: Convert to new X86 CPU match macros thermal: Convert to new X86 CPU match macros hwmon: Convert to new X86 CPU match macros platform/x86: Convert to new CPU match macros EDAC: Convert to new X86 CPU match macros cpufreq: Convert to new X86 CPU match macros ACPI: Convert to new X86 CPU match macros x86/platform: Convert to new CPU match macros x86/kernel: Convert to new CPU match macros x86/kvm: Convert to new CPU match macros x86/perf/events: Convert to new CPU match macros ...

Merge branches 'edac-mc-cleanup', 'edac-misc', 'edac-drivers' and 'edac-urgent' into edac-updates-for-5.7

2020-03-30T08:07:58Z

Signed-off-by: Borislav Petkov

Merge branch 'x86/cpu' into perf/core, to resolve conflict

2020-03-25T14:20:44Z

Conflicts: arch/x86/events/intel/uncore.c Signed-off-by: Ingo Molnar

EDAC: Convert to new X86 CPU match macros

2020-03-24T20:32:28Z

The new macro set has a consistent namespace and uses C99 initializers instead of the grufty C89 ones. Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Reviewed-by: Greg Kroah-Hartman Acked-by: Tony Luck Link: https://lkml.kernel.org/r/20200320131509.673579000@linutronix.de

EDAC/armada_xp: Use scnprintf() for avoiding potential buffer overflow

2020-03-17T18:26:09Z

Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai Signed-off-by: Borislav Petkov Reviewed-by: Jan Luebbe Link: https://lkml.kernel.org/r/20200311071728.4541-1-tiwai@suse.de