The changes are to make sure to check the operation status.
Actually the flash write and erase error behavior is caused on our products.
The flash is Macronix flash device MX29GL512FHT2I-11G used by our products.
The patch series was separated for changes of flash write and erase.
Since those were not depended each other at the time.
But by additional changes the changes are related more as same way currently.
So combine patch series for the flash write and erase changes as v6.
Signed-off-by: Tokunori Ikegami <ikegami(a)allied-telesis.co.jp>
Reviewed-by: Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com>
Cc: Chris Packham <chris.packham(a)alliedtelesis.co.nz>
Cc: Brian Norris <computersforpeace(a)gmail.com>
Cc: David Woodhouse <dwmw2(a)infradead.org>
Cc: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Cc: Marek Vasut <marek.vasut(a)gmail.com>
Cc: Richard Weinberger <richard(a)nod.at>
Cc: Cyrille Pitchen <cyrille.pitchen(a)wedev4u.fr>
Cc: linux-mtd(a)lists.infradead.org
Cc: stable(a)vger.kernel.org
Tokunori Ikegami (5):
mtd: cfi_cmdset_0002: Change write buffer to check correct value
mtd: cfi_cmdset_0002: Change definition naming to retry write
operation
mtd: cfi_cmdset_0002: Change erase functions to retry for error
mtd: cfi_cmdset_0002: Change erase functions to check chip good only
mtd: cfi_cmdset_0002: Change erase one block to enable XIP once
drivers/mtd/chips/cfi_cmdset_0002.c | 36 +++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 13 deletions(-)
--
2.16.1
Clear the PCR (Processor Compatibility Register) on boot to ensure we
are not running in a compatibility mode.
We've seen this cause problems when a crash (and kdump) occurs while
running compat mode guests. The kdump kernel then runs with the PCR
set and causes problems. The symptom in the kdump kernel (also seen in
petitboot after fast-reboot) is early userspace programs taking
sigills on newer instructions (seen in libc).
Signed-off-by: Michael Neuling <mikey(a)neuling.org>
Cc: stable(a)vger.kernel.org # v4.9
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
--
Greg, This is a backport for v4.9 only since the original patch didn't
apply.
Commit faf37c44a105f3608115785f17cbbf3500f8bc71 upstream.
---
arch/powerpc/kernel/cpu_setup_power.S | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cpu_setup_power.S
index 9e05c8828e..ff45d007d1 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -28,6 +28,7 @@ _GLOBAL(__setup_cpu_power7)
beqlr
li r0,0
mtspr SPRN_LPID,r0
+ mtspr SPRN_PCR,r0
mfspr r3,SPRN_LPCR
bl __init_LPCR
bl __init_tlb_power7
@@ -41,6 +42,7 @@ _GLOBAL(__restore_cpu_power7)
beqlr
li r0,0
mtspr SPRN_LPID,r0
+ mtspr SPRN_PCR,r0
mfspr r3,SPRN_LPCR
bl __init_LPCR
bl __init_tlb_power7
@@ -57,6 +59,7 @@ _GLOBAL(__setup_cpu_power8)
beqlr
li r0,0
mtspr SPRN_LPID,r0
+ mtspr SPRN_PCR,r0
mfspr r3,SPRN_LPCR
ori r3, r3, LPCR_PECEDH
bl __init_LPCR
@@ -78,6 +81,7 @@ _GLOBAL(__restore_cpu_power8)
beqlr
li r0,0
mtspr SPRN_LPID,r0
+ mtspr SPRN_PCR,r0
mfspr r3,SPRN_LPCR
ori r3, r3, LPCR_PECEDH
bl __init_LPCR
@@ -98,6 +102,7 @@ _GLOBAL(__setup_cpu_power9)
li r0,0
mtspr SPRN_LPID,r0
mtspr SPRN_PID,r0
+ mtspr SPRN_PCR,r0
mfspr r3,SPRN_LPCR
LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE)
or r3, r3, r4
@@ -121,6 +126,7 @@ _GLOBAL(__restore_cpu_power9)
li r0,0
mtspr SPRN_LPID,r0
mtspr SPRN_PID,r0
+ mtspr SPRN_PCR,r0
mfspr r3,SPRN_LPCR
LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE)
or r3, r3, r4
--
2.17.0
Hi Greg,
please queue:
1. 8a331f4a0863 ("x86/mce/AMD: Carve out SMCA get_block_address() code")
2. 78ce241099bb ("x86/MCE/AMD: Cache SMCA MISC block addresses")
in that order to
4.14
4.16
as it fixes an uninit mem read bug: https://bugzilla.kernel.org/show_bug.cgi?id=199851
Patches apply cleanly and build fine.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.