[PATCH v3] Linux VM workaround for Knights Landing A/D leak

lready happenend. The official erratum will be posted hopefully by the end of July'16. v3 (Lukasz Anaczkowski): () Improved documentation () Removed unnecessary declaration and call to fix_pte_leak from hugetlb.h () Moved fix_pte_leak() definition from tlb.c to intel.c () Replaced

[PATCH v3] Linux VM workaround for Knights Landing A/D leak

al erratum will be posted hopefully by the end of July'16. v3 (Lukasz Anaczkowski): () Improved documentation () Removed unnecessary declaration and call to fix_pte_leak from hugetlb.h () Moved fix_pte_leak() definition from tlb.c to intel.c () Replaced boot_cpu_has_bug() with static_c

[PATCH v2] Linux VM workaround for Knights Landing A/D leak

w. As a followon optimization this could be avoided by telling the callers that the flush already happenend. v2 (Lukasz Anaczkowski): () added call to smp_mb__after_atomic() to synchornize with switch_mm, based on Nadav's comment () fixed compilation breakage Signed-off-by: Andi Kleen <a

[PATCH v2] Linux VM workaround for Knights Landing A/D leak

this could be avoided by telling the callers that the flush already happenend. v2 (Lukasz Anaczkowski): () added call to smp_mb__after_atomic() to synchornize with switch_mm, based on Nadav's comment () fixed compilation breakage Signed-off-by: Andi Kleen Signed-off-by: Lukasz Anaczkowski

[PATCH] Linux VM workaround for Knights Landing A/D leak

From: Andi Kleen Knights Landing has a issue that a thread setting A or D bits may not do so atomically against checking the present bit. A thread which is going to page fault may still set those bits, even though the present bit was already atomically cleared. This

[PATCH] Linux VM workaround for Knights Landing A/D leak

From: Andi Kleen Knights Landing has a issue that a thread setting A or D bits may not do so atomically against checking the present bit. A thread which is going to page fault may still set those bits, even though the present bit was already atomically cleared. This implies that when the kernel

Re: [PATCH] ACPI/SRAT: fix SRAT order parsing when both LAPIC and X2APIC present

From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Thursday, April 21, 2016 2:08 AM > The changelog describes the problem (good), but it doesn't say anything > about the mitigation (not good). You should say something about what the > patch does to address the issue, like "To address that

[PATCH v2] ACPI/SRAT: fix SRAT order parsing when both LAPIC and X2APIC present

by d81056b5278 (thus "Fixes:" tag) and using same mechanism introduced by 9b3fedd (ACPI / tables: Add acpi_subtable_proc to ACPI table parsers). Fixes: d81056b5278 (Handle apic/x2apic entries in MADT in correct order) Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkow...@intel.com> --- dri

Re: [PATCH] ACPI/SRAT: fix SRAT order parsing when both LAPIC and X2APIC present

From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Thursday, April 21, 2016 2:08 AM > The changelog describes the problem (good), but it doesn't say anything > about the mitigation (not good). You should say something about what the > patch does to address the issue, like "To address that

[PATCH v2] ACPI/SRAT: fix SRAT order parsing when both LAPIC and X2APIC present

by d81056b5278 (thus "Fixes:" tag) and using same mechanism introduced by 9b3fedd (ACPI / tables: Add acpi_subtable_proc to ACPI table parsers). Fixes: d81056b5278 (Handle apic/x2apic entries in MADT in correct order) Signed-off-by: Lukasz Anaczkowski --- drivers/acpi/numa.c | 16 --

[PATCH] ACPI/SRAT: fix SRAT order parsing when both LAPIC and X2APIC present

is as assumed by BIOS. However, once APIC entries are mixed, X2APIC entries would be first mapped which causes unexpected NUMA node mapping. Fixes: d81056b5278 (Handle apic/x2apic entries in MADT in correct order) Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkow...@intel.com> --- driver

[PATCH] ACPI/SRAT: fix SRAT order parsing when both LAPIC and X2APIC present

is as assumed by BIOS. However, once APIC entries are mixed, X2APIC entries would be first mapped which causes unexpected NUMA node mapping. Fixes: d81056b5278 (Handle apic/x2apic entries in MADT in correct order) Signed-off-by: Lukasz Anaczkowski --- drivers/acpi/numa.c | 16 1

[PATCH] Added multiplier for APERF and MPERF counters

-by: Hubert Chrzaniuk Signed-off-by: Lukasz Anaczkowski --- tools/power/x86/turbostat/turbostat.c | 13 + 1 file changed, 13 insertions(+) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index 9655cb4..1dda607 100644 --- a/tools/power/x86

[PATCH] Added multiplier for APERF and MPERF counters

APERF/MPERF counters. Signed-off-by: Hubert Chrzaniuk <hubert.chrzan...@intel.com> Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkow...@intel.com> --- tools/power/x86/turbostat/turbostat.c | 13 + 1 file changed, 13 insertions(+) diff --git a/tools/power/x86/turbostat/tu

[PATCH v4 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs

, which did not required ACPI parsing interface changes, however it failed to meet requirements. More details can be found here: https://lkml.org/lkml/2015/9/7/285 Lukasz Anaczkowski (2): acpi: Added acpi_subtable_proc to ACPI table parsers x86, acpi: Handle apic/x2apic entries in MADT in correct

[PATCH v4 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers

it to acpi_parse_entries_array() and acpi_table_parse_entries_array(). This is needed to fix CPU enumeration when APIC/X2APIC entries are interleaved. Signed-off-by: Lukasz Anaczkowski Reviewed-by: Marc Zyngier Tested-by: Marc Zyngier --- drivers/acpi/tables.c | 91

[PATCH v4 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order

s >= 0xFF, right? This patch is based on work of "Yinghai Lu " previously published at https://lkml.org/lkml/2013/1/21/563 Here's the explanation why parsing interface needs to be changed and why simpler approach will not work https://lkml.org/lkml/2015/9/7/285 Signed-off-by: Luk

Re: [PATCH 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers

From: Marc Zyngier [mailto:marc.zyng...@arm.com] Sent: Wednesday, September 9, 2015 12:48 PM > Nit: Please add a version number to the patches you send - this is at > least the 4th revision of this series, and it is harder to keep track of > what I'm reviewing. git send-email --subject-prefix

[PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order

s >= 0xFF, right? This patch is based on work of "Yinghai Lu " previously published at https://lkml.org/lkml/2013/1/21/563 Here's the explanation why parsing interface needs to be changed and why simpler approach will not work https://lkml.org/lkml/2015/9/7/285 Signed-off-by: Luk

[PATCH 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers

it to acpi_parse_entries_array() and acpi_table_parse_entries_array(). This is needed to fix CPU enumeration when APIC/X2APIC entries are interleaved. Signed-off-by: Lukasz Anaczkowski --- drivers/acpi/tables.c | 89 +-- include/linux/acpi.h | 13 2 files changed

[PATCH 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs

, which did not required ACPI parsing interface changes, however it failed to meet requirements. More details can be found here: https://lkml.org/lkml/2015/9/7/285 Lukasz Anaczkowski (2): acpi: Added acpi_subtable_proc to ACPI table parsers x86, acpi: Handle apic/x2apic entries in MADT in correct

[PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order

s >= 0xFF, right? This patch is based on work of "Yinghai Lu <ying...@kernel.org>" previously published at https://lkml.org/lkml/2013/1/21/563 Here's the explanation why parsing interface needs to be changed and why simpler approach will not work https://lkml.org/lkml/2015/9/

[PATCH 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers

it to acpi_parse_entries_array() and acpi_table_parse_entries_array(). This is needed to fix CPU enumeration when APIC/X2APIC entries are interleaved. Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkow...@intel.com> --- drivers/acpi/tables.c | 89 +-- include/linux/

[PATCH 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs

, which did not required ACPI parsing interface changes, however it failed to meet requirements. More details can be found here: https://lkml.org/lkml/2015/9/7/285 Lukasz Anaczkowski (2): acpi: Added acpi_subtable_proc to ACPI table parsers x86, acpi: Handle apic/x2apic entries in MADT in correct

Re: [PATCH 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers

From: Marc Zyngier [mailto:marc.zyng...@arm.com] Sent: Wednesday, September 9, 2015 12:48 PM > Nit: Please add a version number to the patches you send - this is at > least the 4th revision of this series, and it is harder to keep track of > what I'm reviewing. git send-email --subject-prefix

[PATCH v4 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order

s >= 0xFF, right? This patch is based on work of "Yinghai Lu <ying...@kernel.org>" previously published at https://lkml.org/lkml/2013/1/21/563 Here's the explanation why parsing interface needs to be changed and why simpler approach will not work https://lkml.org/lkml/2015/9/

[PATCH v4 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers

it to acpi_parse_entries_array() and acpi_table_parse_entries_array(). This is needed to fix CPU enumeration when APIC/X2APIC entries are interleaved. Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkow...@intel.com> Reviewed-by: Marc Zyngier <marc.zyng...@arm.com> Tested-by: Marc Zyngier <marc.zyng...@arm.co

[PATCH v4 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs

, which did not required ACPI parsing interface changes, however it failed to meet requirements. More details can be found here: https://lkml.org/lkml/2015/9/7/285 Lukasz Anaczkowski (2): acpi: Added acpi_subtable_proc to ACPI table parsers x86, acpi: Handle apic/x2apic entries in MADT in correct

[PATCH 0/4] Fix how CPUs are enumerated when there's more than 255 CPUs

. Although interface has changed, semantics stayed the same, thus runtime issues should not appear. Please verify, thanks! Lukasz Anaczkowski (4): acpi: rename acpi_table_parse_entries x86, arm64, acpi: Added acpi_subtable_proc acpi: multi proc support x86, acpi: Handle apic/x2apic entries

Re: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT

Hi Lorenzo, Ingo and Tomasz, I'm sending revisited set of patches with all your comments addressed (I hope), thus I'll skip replying to single each of them. Thanks in advance for comments. Cheers, Lukasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

[PATCH 4/4] x86, acpi: Handle apic/x2apic entries in MADT in correct order

"Yinghai Lu " previously published at https://lkml.org/lkml/2013/1/21/563, thus putting Yinghai Lu as 'Signed-off-by', as well. Signed-off-by: Lukasz Anaczkowski Signed-off-by: Yinghai Lu Acked-by: Thomas Gleixner (commit message) --- arch/x86/kernel/acpi/boot.c | 37 ++--

[PATCH 3/4] acpi: multi proc support

Now, it is possible to pass two or more handlers. Signed-off-by: Lukasz Anaczkowski --- drivers/acpi/tables.c | 31 ++- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index 33539ee..ececeac 100644

[PATCH 1/4] acpi: rename acpi_table_parse_entries

ACPI subtable parsing needs to be extended to allow two or more handlers to be run in the same ACPI table walk. This is needed to fix CPU enumeration when APIC/X2APIC entries are interleaved. Signed-off-by: Lukasz Anaczkowski --- drivers/acpi/tables.c | 13 - include/linux/acpi.h

[PATCH 2/4] x86, arm64, acpi: Added acpi_subtable_proc

Single item array is only supported to verify that original logic is not changed. Update for many item array support is to be added in next patch. Signed-off-by: Lukasz Anaczkowski --- arch/x86/kernel/acpi/boot.c | 36 drivers/acpi/numa.c | 13

[PATCH 3/4] acpi: multi proc support

Now, it is possible to pass two or more handlers. Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkow...@intel.com> --- drivers/acpi/tables.c | 31 ++- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c

[PATCH 4/4] x86, acpi: Handle apic/x2apic entries in MADT in correct order

;Yinghai Lu <ying...@kernel.org>" previously published at https://lkml.org/lkml/2013/1/21/563, thus putting Yinghai Lu as 'Signed-off-by', as well. Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkow...@intel.com> Signed-off-by: Yinghai Lu <ying...@kernel.org> Acked-by: Thomas Gleix

[PATCH 2/4] x86, arm64, acpi: Added acpi_subtable_proc

Single item array is only supported to verify that original logic is not changed. Update for many item array support is to be added in next patch. Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkow...@intel.com> --- arch/x86/kernel/acpi/boot.c | 36 d

[PATCH 1/4] acpi: rename acpi_table_parse_entries

ACPI subtable parsing needs to be extended to allow two or more handlers to be run in the same ACPI table walk. This is needed to fix CPU enumeration when APIC/X2APIC entries are interleaved. Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkow...@intel.com> --- drivers/acpi/tables.

[PATCH 0/4] Fix how CPUs are enumerated when there's more than 255 CPUs

. Although interface has changed, semantics stayed the same, thus runtime issues should not appear. Please verify, thanks! Lukasz Anaczkowski (4): acpi: rename acpi_table_parse_entries x86, arm64, acpi: Added acpi_subtable_proc acpi: multi proc support x86, acpi: Handle apic/x2apic entries

Re: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT

Hi Lorenzo, Ingo and Tomasz, I'm sending revisited set of patches with all your comments addressed (I hope), thus I'll skip replying to single each of them. Thanks in advance for comments. Cheers, Lukasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

[PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT

ously published at https://lkml.org/lkml/2013/1/21/563, thus putting Yinghai Lu as 'Signed-off-by', as well. Signed-off-by: Yinghai Lu Signed-off-by: Lukasz Anaczkowski Acked-by: Thomas Gleixner --- arch/x86/kernel/acpi/boot.c | 29 drivers/acpi/numa.c | 28 ---

Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

Marc nad Lorenzo, First of all appologies for breaking arm64 (again) and thank you for debugging effort. I own you. > - count is only incremented when max_entries != 0, as you noticed You are right, sorry for that, it's fixed in v3. > - With max_entries != 0, count now represent the sum of all

[PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT

://lkml.org/lkml/2013/1/21/563, thus putting Yinghai Lu as 'Signed-off-by', as well. Signed-off-by: Yinghai Lu ying...@kernel.org Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com Acked-by: Thomas Gleixner t...@linutronix.de --- arch/x86/kernel/acpi/boot.c | 29 drivers/acpi

Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

Marc nad Lorenzo, First of all appologies for breaking arm64 (again) and thank you for debugging effort. I own you. - count is only incremented when max_entries != 0, as you noticed You are right, sorry for that, it's fixed in v3. - With max_entries != 0, count now represent the sum of all

Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

Hi Marc, > You haven't ever tried compiling this, have you? I *thought* I tried, but obviously I did it wrong. This time I made sure it compiles. Thanks for poiting this out. Sending v2 of the patch with fixed arm64 compilation. Cheers, Lukasz -- To unsubscribe from this list: send the line

[PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

that time since nobody cared about cores with APIC IDs >= 0xFF, right? This patch is based on work of "Yinghai Lu " previously published at https://lkml.org/lkml/2013/1/21/563, thus putting Yinghai Lu as 'Signed-off-by', as well. Signed-off-by: Yinghai Lu Signed-off-by: Lukasz Anaczkowsk

Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

Hi Marc, You haven't ever tried compiling this, have you? I *thought* I tried, but obviously I did it wrong. This time I made sure it compiles. Thanks for poiting this out. Sending v2 of the patch with fixed arm64 compilation. Cheers, Lukasz -- To unsubscribe from this list: send the line

[PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

about cores with APIC IDs = 0xFF, right? This patch is based on work of Yinghai Lu ying...@kernel.org previously published at https://lkml.org/lkml/2013/1/21/563, thus putting Yinghai Lu as 'Signed-off-by', as well. Signed-off-by: Yinghai Lu ying...@kernel.org Signed-off-by: Lukasz Anaczkowski

Re: [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

> Please add proper explanations why the array parser is required and > why the parse order needs to be reverse. Thanks for comments. I'm sending patch with reworked commit message. I hope that at least some of the doubts are cleaner now. Cheers, Lukasz -- To unsubscribe from this list: send

[PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

ut cores with APIC IDs >= 0xFF, right? This patch is based on work of "Yinghai Lu " previously published at https://lkml.org/lkml/2013/1/21/563, thus putting Yinghai Lu as 'Signed-off-by', as well. Signed-off-by: Yinghai Lu Signed-off-by: Lukasz Anaczkowski --

[PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

, right? This patch is based on work of Yinghai Lu ying...@kernel.org previously published at https://lkml.org/lkml/2013/1/21/563, thus putting Yinghai Lu as 'Signed-off-by', as well. Signed-off-by: Yinghai Lu ying...@kernel.org Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com

Re: [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

Please add proper explanations why the array parser is required and why the parse order needs to be reverse. Thanks for comments. I'm sending patch with reworked commit message. I hope that at least some of the doubts are cleaner now. Cheers, Lukasz -- To unsubscribe from this list: send the

[PATCH] intel_pstate: Add get_scaling cpu_defaults param to Knights Landing

Scaling for Knights Landing is same as the default scaling (10). When Knigts Landing support was added to the pstate driver, this parameter was omitted resulting in a kernel panic during boot. Reported-by: Yasuaki Ishimatsu Signed-off-by: Dasaratharaman Chandramouli Signed-off-by: Lukasz

[PATCH] intel_pstate: Add get_scaling cpu_defaults param to Knights Landing

dasaratharaman.chandramo...@intel.com Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com --- drivers/cpufreq/intel_pstate.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 15ada47..fcb929e 100644 --- a/drivers/cpufreq

[PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

f]) 44 ( 16 [0010]), 76 ( 17 [0011]), 148 ( 18 [0012]), 220 ( 19 [0013]) 55 ( 20 [0014]), 77 ( 21 [0015]), 149 ( 22 [0016]), 221 ( 23 [0017]) ... Signed-off-by: Lukasz Anaczkowski --- arch/x86/kernel/acpi/boot.c | 29 +- drivers/acpi/numa.c

Re: [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

On 07/13/2015 23:22 PM, Hanjun Guo wrote: >> In case when BIOS is populating MADT wiht both x2apic and local apic >> entries (as per ACPI spec), kernel builds it's processor table >> in the following order: BSP, X2APIC, local APIC, resulting in >> processors on the same core are not separated by

[PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

[000f]) 44 ( 16 [0010]), 76 ( 17 [0011]), 148 ( 18 [0012]), 220 ( 19 [0013]) 55 ( 20 [0014]), 77 ( 21 [0015]), 149 ( 22 [0016]), 221 ( 23 [0017]) ... Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com --- arch/x86/kernel/acpi/boot.c | 29 +- drivers/acpi

Re: [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

On 07/13/2015 23:22 PM, Hanjun Guo wrote: In case when BIOS is populating MADT wiht both x2apic and local apic entries (as per ACPI spec), kernel builds it's processor table in the following order: BSP, X2APIC, local APIC, resulting in processors on the same core are not separated by core

[PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

resulting in processors on the same core are not separated by core count. This patch fixes this behavior and resulting assignment is correct. Signed-off-by: Lukasz Anaczkowski --- arch/x86/kernel/acpi/boot.c | 29 +- drivers/acpi/numa.c | 28 - drivers/acp

[PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

APIC, resulting in processors on the same core are not separated by core count. This patch fixes this behavior and resulting assignment is correct. Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com --- arch/x86/kernel/acpi/boot.c | 29 +- drivers/acpi/numa.c

[PATCH 2/3] sb_edac: virtualize several hard-coded functions

From: Jim Snow Signed-off-by: Jim Snow Signed-off-by: Lukasz Anaczkowski --- drivers/edac/sb_edac.c | 55 -- 1 file changed, 44 insertions(+), 11 deletions(-) diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c index 1acf57b..6e35405

[PATCH 3/3] sb_edac: support for duplicate device IDs

From: Jim Snow Add options to sbridge_get_all_devices to allow for duplicate device IDs and devices that are scattered across mulitple PCI buses. Signed-off-by: Jim Snow Signed-off-by: Lukasz Anaczkowski --- drivers/edac/sb_edac.c | 40 1 file changed

[PATCH 1/3] EDAC: add DDR4 flag

From: Jim Snow Signed-off-by: Jim Snow Signed-off-by: Lukasz Anaczkowski --- include/linux/edac.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/edac.h b/include/linux/edac.h index da3b72e..bb305b17 100644 --- a/include/linux/edac.h +++ b/include/linux

[PATCH 0/3] EDAC: add DDR4 flag, misc improvements

From: Lukasz Anaczkowski Series of patches that makes sb_edac more flexible for adding support for future platforms. Jim Snow (3): EDAC: add DDR4 flag sb_edac: virtualize several hard-coded functions sb_edac: support for duplicate device IDs drivers/edac/sb_edac.c | 95

[PATCH 0/3] EDAC: add DDR4 flag, misc improvements

From: Lukasz Anaczkowski lukasz.anaczkow...@intel.com Series of patches that makes sb_edac more flexible for adding support for future platforms. Jim Snow (3): EDAC: add DDR4 flag sb_edac: virtualize several hard-coded functions sb_edac: support for duplicate device IDs drivers/edac

[PATCH 2/3] sb_edac: virtualize several hard-coded functions

From: Jim Snow jim.m.s...@intel.com Signed-off-by: Jim Snow jim.m.s...@intel.com Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com --- drivers/edac/sb_edac.c | 55 -- 1 file changed, 44 insertions(+), 11 deletions(-) diff --git

[PATCH 3/3] sb_edac: support for duplicate device IDs

From: Jim Snow jim.m.s...@intel.com Add options to sbridge_get_all_devices to allow for duplicate device IDs and devices that are scattered across mulitple PCI buses. Signed-off-by: Jim Snow jim.m.s...@intel.com Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com --- drivers/edac

[PATCH 1/3] EDAC: add DDR4 flag

From: Jim Snow jim.m.s...@intel.com Signed-off-by: Jim Snow jim.m.s...@intel.com Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com --- include/linux/edac.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/edac.h b/include/linux/edac.h index

[PATCH 2/2] sb_edac: Fix erroneous bytes->gigabytes conversion

From: Jim Snow Signed-off-by: Jim Snow Signed-off-by: Lukasz Anaczkowski --- drivers/edac/sb_edac.c | 38 -- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c index e9bb1af..f37d01f 100644

[PATCH 1/2] sb_edac: Fix off-by-one error in number of channels

From: Jim Snow This prevented edac sysfs code from properly handling 6 channels per memory controller. Signed-off-by: Jim Snow Signed-off-by: Lukasz Anaczkowski --- drivers/edac/edac_mc_sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/edac_mc_sysfs.c b

[PATCH 0/2] sb_edac: two bugfixes

Hello there, These are two bugfixes for sb_edac. This is my first time sending patches, so appologies for any process errors I may did. Let me know if this suffice to get these patches merged (unless there are comments to the code itself). Cheers, Lukasz

[PATCH 0/2] sb_edac: two bugfixes

Hello there, These are two bugfixes for sb_edac. This is my first time sending patches, so appologies for any process errors I may did. Let me know if this suffice to get these patches merged (unless there are comments to the code itself). Cheers, Lukasz

[PATCH 1/2] sb_edac: Fix off-by-one error in number of channels

From: Jim Snow jim.m.s...@intel.com This prevented edac sysfs code from properly handling 6 channels per memory controller. Signed-off-by: Jim Snow jim.s...@intel.com Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com --- drivers/edac/edac_mc_sysfs.c | 2 +- 1 file changed, 1

[PATCH 2/2] sb_edac: Fix erroneous bytes-gigabytes conversion

From: Jim Snow jim.m.s...@intel.com Signed-off-by: Jim Snow jim.s...@intel.com Signed-off-by: Lukasz Anaczkowski lukasz.anaczkow...@intel.com --- drivers/edac/sb_edac.c | 38 -- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/drivers/edac