[PATCH 1/2] PCI/MSI/PPC: Remove arch_msi_check_device()

PowerPC is the only architecture that makes use of hook arch_msi_check_device() and does perform some checks to figure out if MSI/MSI-X could be enabled for a device. However, there are no reasons why those checks could not be done within arch_setup_msi_irqs() hook. Moving MSI checks into

[PATCH 2/2] PCI/MSI: Remove arch_msi_check_device()

There are no archs that override arch_msi_check_device() hook. Remove it as it is completely redundant. If an arch would need to check MSI/MSI-X possibility for a device it should make it within arch_setup_msi_irqs() hook. Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-...@vger.kernel.org

[PATCH 0/7] arch/powerpc: convert single variable sscanf to kstrtotype

Here is a small untested patchset to use the current string manipulation kstrtotype functions instead of sscanf like specified in checkpatch: Prefer kstrtotype to single variable sscanf autodetect base 0 has been used for both %d, %i, %ld, %lu, %u and base 16 for %lx Fabian Frederick (7):

[PATCH 1/7] powerpc: fadump: replace sscanf by kstrtoint

See checkpatch warning Prefer kstrtotype to single variable sscanf Signed-off-by: Fabian Frederick f...@skynet.be --- arch/powerpc/kernel/fadump.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c index

[PATCH 2/7] powerpc/mv64x60_pci: replace sscanf by kstrtou32

See checkpatch warning Prefer kstrtotype to single variable sscanf Signed-off-by: Fabian Frederick f...@skynet.be --- arch/powerpc/sysdev/mv64x60_pci.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/sysdev/mv64x60_pci.c

[PATCH 5/7] hugetlb: replace sscanf by kstrtoul

See checkpatch warning Prefer kstrtotype to single variable sscanf Signed-off-by: Fabian Frederick f...@skynet.be --- arch/powerpc/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index

[PATCH 3/7] powerpc/powernv: replace sscanf %lx by kstrtoul 16

See checkpatch warning Prefer kstrtotype to single variable sscanf Signed-off-by: Fabian Frederick f...@skynet.be --- arch/powerpc/platforms/powernv/subcore.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/platforms/powernv/subcore.c

[PATCH 4/7] powerpc/sysfs: replace sscanf by kstrtol

See checkpatch warning Prefer kstrtotype to single variable sscanf Signed-off-by: Fabian Frederick f...@skynet.be --- arch/powerpc/kernel/sysfs.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c index

[PATCH 6/7] powerpc/cell: replace sscanf by kstrtouint

See checkpatch warning Prefer kstrtotype to single variable sscanf Signed-off-by: Fabian Frederick f...@skynet.be --- arch/powerpc/platforms/cell/cbe_thermal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/cell/cbe_thermal.c

[PATCH 7/7] powerpc/pseries: replace sscanf by kstrtoul

See checkpatch warning Prefer kstrtotype to single variable sscanf Signed-off-by: Fabian Frederick f...@skynet.be --- arch/powerpc/platforms/pseries/power.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/platforms/pseries/power.c

bit fields data tearing

Hello, I am not sure I should ask here, but since Documentation/memory-barriers.txt mentions load/store tearing perhaps my question is not completely off-topic... I am fighting with mysterious RHEL bug, it can be reproduced on ppc and s390 but not on x86. Finally I seem to understand the

Re: bit fields data tearing

OK, looks like this is compiler bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Thanks to Dan who informed me privately. On 07/12, Oleg Nesterov wrote: Hello, I am not sure I should ask here, but since Documentation/memory-barriers.txt mentions load/store tearing perhaps my

Re: bit fields data tearing

On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote: OK, looks like this is compiler bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Thanks to Dan who informed me privately. So yes, there's is this compiler bug which means a bitfield access can cause a r-m-w access to a