[PATCH v2 1/2] pstore/ram: avoid atomic accesses for ioremapped regions

buffer size and start updates on ioremapped regions instead. Signed-off-by: Rob Herring Acked-by: Anton Vorontsov Signed-off-by: Tony Luck [hkp: Backported to 3.10: adjust context] Signed-off-by: HuKeping --- fs/pstore/ram_core.c | 54 ++-- 1 file

[PATCH 2/2] efi-pstore: Make efi-pstore return a unique id

From: Madper Xie Commit fdeadb43fdf1e7d5698c027b555c389174548e5a upstream. Pstore fs expects that backends provide a unique id which could avoid pstore making entries as duplication or denominating entries the same name. So I combine the timestamp, part and count into id. Signed-off-by: Madper

[PATCH v2 0/2][request for stable inclusion] several pstore related bugfixs

Hi greg, We want to use pstore on linux 3.10. But we found several bugfixs have not been merged yet. Most of them are obvious and can be cherry-picked cleanly. Would you please apply them to stable 3.10? Change from v1: - remove d4bf205da618bbd0b038e404d646f14e76915718 which has already been merg

[PATCH v3 1/2] pstore/ram: avoid atomic accesses for ioremapped regions

cannot be used. This commit uses spinlock protection for buffer size and start updates on ioremapped regions instead. Signed-off-by: Rob Herring Acked-by: Anton Vorontsov Signed-off-by: Tony Luck [hkp: Backported to 3.10: adjust context] Signed-off-by: HuKeping --- fs/pstore/ram_core.c | 54

[PATCH v3 0/2][request for stable inclusion] several pstore related bugfixs

Hi greg, We want to use pstore on linux 3.10. But we found several bugfixs have not been merged yet. Most of them are obvious and can be cherry-picked cleanly. Would you please apply them to stable 3.10? v1 -> v2: - remove d4bf205da618bbd0b038e404d646f14e76915718 which has already been merged -

[PATCH v3 2/2] efi-pstore: Make efi-pstore return a unique id

From: Madper Xie Commit fdeadb43fdf1e7d5698c027b555c389174548e5a upstream. Pstore fs expects that backends provide a unique id which could avoid pstore making entries as duplication or denominating entries the same name. So I combine the timestamp, part and count into id. Signed-off-by: Madper

[PATCH V2] Add arm description to Documentation/kdump/kdump.txt

Add arm specific parts to kdump kernel documentation. It seem that we prefer to use nr_cpus=1 instead of maxcpus=1. but nr_cpus does not work fine on arm. There will be a warning when dump-caputre kernel booting if use nr_cpus: "[0.00] DT/cpu 2nod

[PATCH v3] Add arm description to Documentation/kdump/kdump.txt

Add arm specific parts to kdump kernel documentation. v2 -> v3 - fix some spelling mistakes Signed-off-by: Hu Keping --- Documentation/kdump/kdump.txt | 36 +--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --gi

[PATCH] ARM: kexec: Fix validating CPU hotplug support

Due to commit:2103f6cba61a8b8bea3fc1b63661d830a2125e76, there is a hotplug checking in machine_kexec_prepare(), but it will lead a failure when loading the crash-kernel in some cases. Kexec utility can load the crash kernel by two ways: 1. kexec -l kernel-image --append=command-line-options --init

[PATCH v2] ARM: kexec: Fix validating CPU hotplug support

v1 -> v2: -do some source format Due to commit:2103f6cba61a8b8bea3fc1b63661d830a2125e76, there is a hotplug checking in machine_kexec_prepare(), but it will lead a failure when loading the crash-kernel in some cases. Kexec utility can load the crash kernel by two ways: 1. kexec -l kernel-image

[RESEND PATCH] ARM: kexec: Fix validating CPU hotplug support

Commit 2103f6cba61a8b8bea3fc1b63661d830a2125e76 added a hotplug checking in machine_kexec_prepare(), but it will lead a failure when loading the crash-kernel in some cases. Kexec utility can load the crash kernel by two ways: 1. kexec -l kernel-image 2. kexec -p kernel-image In case #1, for rapid