Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
On Thu, 2019-12-12 at 11:53 +1100, Michael Ellerman wrote: > Thadeu Lima de Souza Cascardo writes: [...] > > This is a patch on binutils carried by Fedora: > > > > https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8 > > > > " b8265c Have readelf display extra symbol information at the end of the > > line. " > > > > It has the following comment: > > > > # FIXME:The proper fix would be to update the scripts that are expecting > > # a fixed output from readelf. But it seems that some of them are > > # no longer being maintained. > > > > This commit is from 2017, had it been on binutils upstream, maybe the > > situation > > right now would be different. > > Bleeping bleep. > > Looks like it was actually ruby that was the original problem: > > https://bugzilla.redhat.com/show_bug.cgi?id=1479302 > > > Why it wasn't hacked around in the ruby package I don't know, doing it in > the distro binutils package is not ideal. That wouldn't help people building Ruby from upstream. Any tool generating tabular output like this should add new fields at the end (or show them only if requested), since there are bound to be scripts that parse the output like this. So I think Fedora's change to readelf was reasonable, but should have been pushed upstream as soon as possible. Now everyone is going to have to deal with both formats. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Re: [Y2038] [PATCH 3/8] powerpc: fix vdso32 for ppc64le
On Thu, 2019-11-21 at 11:02 +0100, Arnd Bergmann wrote: > On Wed, Nov 20, 2019 at 10:49 PM Ben Hutchings > wrote: > > On Wed, 2019-11-20 at 20:35 +0100, Arnd Bergmann wrote: > > > On Wed, Nov 20, 2019 at 8:13 PM Ben Hutchings > > > wrote: > > > > On Fri, 2019-11-08 at 21:34 +0100, Arnd Bergmann wrote: > > > > > On little-endian 32-bit application running on 64-bit kernels, > > > > > the current vdso would read the wrong half of the xtime seconds > > > > > field. Change it to return the lower half like it does on > > > > > big-endian. > > > > > > > > ppc64le doesn't have 32-bit compat so this is only theoretical. > > > > > > That is probably true. I only looked at the kernel, which today still > > > supports compat mode for ppc64le, but I saw the patches to disable > > > it, and I don't think anyone has even attempted building user space > > > for it. > > > > COMPAT is still enabled for some reason, but VDSO32 isn't (since 4.2). > > Ok, I had missed that detail. Should I just drop my patch then? I think so. Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
Re: [Y2038] [PATCH 07/23] y2038: vdso: powerpc: avoid timespec references
On Fri, 2019-11-08 at 22:07 +0100, Arnd Bergmann wrote: [...] > --- a/arch/powerpc/kernel/vdso32/gettimeofday.S > +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S > @@ -15,10 +15,8 @@ > /* Offset for the low 32-bit part of a field of long type */ > #if defined(CONFIG_PPC64) && defined(CONFIG_CPU_BIG_ENDIAN) > #define LOPART 4 > -#define TSPEC_TV_SEC TSPC64_TV_SEC+LOPART > #else > #define LOPART 0 > -#define TSPEC_TV_SEC TSPC32_TV_SEC > #endif > > .text > @@ -192,7 +190,7 @@ V_FUNCTION_BEGIN(__kernel_time) > bl __get_datapage@local > mr r9, r3 /* datapage ptr in r9 */ > > - lwz r3,STAMP_XTIME+TSPEC_TV_SEC(r9) > + lwz r3,STAMP_XTIME_SEC+LOWPART(r9) "LOWPART" should be "LOPART". > > cmplwi r11,0 /* check if t is NULL */ > beq 2f > @@ -268,7 +266,7 @@ __do_get_tspec: >* as a 32.32 fixed-point number in r3 and r4. >* Load & add the xtime stamp. >*/ > - lwz r5,STAMP_XTIME+TSPEC_TV_SEC(r9) > + lwz r5,STAMP_XTIME_SEC+LOWPART(r9) Same here. > lwz r6,STAMP_SEC_FRAC(r9) > addcr4,r4,r6 > adder3,r3,r5 [...] -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
Re: [Y2038] [PATCH 3/8] powerpc: fix vdso32 for ppc64le
On Wed, 2019-11-20 at 20:35 +0100, Arnd Bergmann wrote: > On Wed, Nov 20, 2019 at 8:13 PM Ben Hutchings > wrote: > > On Fri, 2019-11-08 at 21:34 +0100, Arnd Bergmann wrote: > > > On little-endian 32-bit application running on 64-bit kernels, > > > the current vdso would read the wrong half of the xtime seconds > > > field. Change it to return the lower half like it does on > > > big-endian. > > > > ppc64le doesn't have 32-bit compat so this is only theoretical. > > That is probably true. I only looked at the kernel, which today still > supports compat mode for ppc64le, but I saw the patches to disable > it, and I don't think anyone has even attempted building user space > for it. COMPAT is still enabled for some reason, but VDSO32 isn't (since 4.2). Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
Re: [Y2038] [PATCH 3/8] powerpc: fix vdso32 for ppc64le
On Fri, 2019-11-08 at 21:34 +0100, Arnd Bergmann wrote: > On little-endian 32-bit application running on 64-bit kernels, > the current vdso would read the wrong half of the xtime seconds > field. Change it to return the lower half like it does on > big-endian. ppc64le doesn't have 32-bit compat so this is only theoretical. Ben. > Signed-off-by: Arnd Bergmann > --- > arch/powerpc/kernel/vdso32/gettimeofday.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S > b/arch/powerpc/kernel/vdso32/gettimeofday.S > index becd9f8767ed..4327665ad86f 100644 > --- a/arch/powerpc/kernel/vdso32/gettimeofday.S > +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S > @@ -13,7 +13,7 @@ > #include > > /* Offset for the low 32-bit part of a field of long type */ > -#ifdef CONFIG_PPC64 > +#if defined(CONFIG_PPC64) && defined(CONFIG_CPU_BIG_ENDIAN) > #define LOPART 4 > #define TSPEC_TV_SEC TSPC64_TV_SEC+LOPART > #else -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
Re: [Y2038] [PATCH 08/23] y2038: ipc: remove __kernel_time_t reference from headers
On Fri, 2019-11-08 at 22:07 +0100, Arnd Bergmann wrote:
[...]
> --- a/arch/x86/include/uapi/asm/sembuf.h
> +++ b/arch/x86/include/uapi/asm/sembuf.h
> @@ -21,9 +21,9 @@ struct semid64_ds {
> unsigned long sem_ctime; /* last change time */
> unsigned long sem_ctime_high;
> #else
> - __kernel_time_t sem_otime; /* last semop time */
> + longsem_otime; /* last semop time */
> __kernel_ulong_t __unused1;
> - __kernel_time_t sem_ctime; /* last change time */
> + longsem_ctime; /* last change time */
> __kernel_ulong_t __unused2;
> #endif
> __kernel_ulong_t sem_nsems; /* no. of semaphores in array */
[...]
We need to use __kernel_long_t here to do the right thing on x32.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
[PATCH 3.16 76/87] perf/ioctl: Add check for the sample_period value
3.16.75-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ravi Bangoria
commit 913a90bc5a3a06b1f04c337320e9aeee2328dd77 upstream.
perf_event_open() limits the sample_period to 63 bits. See:
0819b2e30ccb ("perf: Limit perf_event_attr::sample_period to 63 bits")
Make ioctl() consistent with it.
Also on PowerPC, negative sample_period could cause a recursive
PMIs leading to a hang (reported when running perf-fuzzer).
Signed-off-by: Ravi Bangoria
Signed-off-by: Peter Zijlstra (Intel)
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Vince Weaver
Cc: a...@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: ma...@linux.vnet.ibm.com
Cc: m...@ellerman.id.au
Fixes: 0819b2e30ccb ("perf: Limit perf_event_attr::sample_period to 63 bits")
Link: https://lkml.kernel.org/r/20190604042953.914-1-ravi.bango...@linux.ibm.com
Signed-off-by: Ingo Molnar
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings
---
kernel/events/core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3823,6 +3823,9 @@ static int perf_event_period(struct perf
if (perf_event_check_period(event, value))
return -EINVAL;
+ if (!event->attr.freq && (value & (1ULL << 63)))
+ return -EINVAL;
+
task = ctx->task;
pe.value = value;
[PATCH 3.16 09/86] jump_label: Allow jump labels to be used in assembly
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Anton Blanchard
commit c0ccf6f99e3a43b87980c9df7da48427885206d0 upstream.
To use jump labels in assembly we need the HAVE_JUMP_LABEL
define, so we select a fallback version if the toolchain does
not support them.
Modify linux/jump_label.h so it can be included by assembly
files. We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
Signed-off-by: Anton Blanchard
Acked-by: Peter Zijlstra (Intel)
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: b...@kernel.crashing.org
Cc: catalin.mari...@arm.com
Cc: da...@davemloft.net
Cc: heiko.carst...@de.ibm.com
Cc: jba...@akamai.com
Cc: li...@arm.linux.org.uk
Cc: linuxppc-dev@lists.ozlabs.org
Cc: liu...@gmail.com
Cc: mgor...@suse.de
Cc: mma...@suse.cz
Cc: m...@ellerman.id.au
Cc: pau...@samba.org
Cc: r...@linux-mips.org
Cc: rost...@goodmis.org
Cc: schwidef...@de.ibm.com
Cc: will.dea...@arm.com
Link: http://lkml.kernel.org/r/1428551492-21977-2-git-send-email-an...@samba.org
Signed-off-by: Ingo Molnar
Signed-off-by: Ben Hutchings
---
Makefile | 1 +
include/linux/jump_label.h | 21 +
2 files changed, 18 insertions(+), 4 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -761,6 +761,7 @@ KBUILD_ARFLAGS := $(call ar-option,D)
# check for 'asm goto'
ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
+ KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
endif
include $(srctree)/scripts/Makefile.extrawarn
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -45,6 +45,12 @@
* same as using STATIC_KEY_INIT_FALSE.
*/
+#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+# define HAVE_JUMP_LABEL
+#endif
+
+#ifndef __ASSEMBLY__
+
#include
#include
#include
@@ -55,7 +61,7 @@ extern bool static_key_initialized;
"%s used before call to jump_label_init", \
__func__)
-#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+#ifdef HAVE_JUMP_LABEL
struct static_key {
atomic_t enabled;
@@ -66,13 +72,18 @@ struct static_key {
#endif
};
-# include
-# define HAVE_JUMP_LABEL
#else
struct static_key {
atomic_t enabled;
};
-#endif /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
+#endif /* HAVE_JUMP_LABEL */
+#endif /* __ASSEMBLY__ */
+
+#ifdef HAVE_JUMP_LABEL
+#include
+#endif
+
+#ifndef __ASSEMBLY__
enum jump_label_type {
JUMP_LABEL_DISABLE = 0,
@@ -223,3 +234,5 @@ static inline void static_key_disable(st
}
#endif /* _LINUX_JUMP_LABEL_H */
+
+#endif /* __ASSEMBLY__ */
[PATCH 3.16 79/86] cpu/speculation: Add 'mitigations=' cmdline option
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Josh Poimboeuf
commit 98af8452945c55652de68536afdde3b520fec429 upstream.
Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users. It's getting more and more
complicated to decide which mitigations are needed for a given
architecture. Complicating matters is the fact that each arch tends to
have its own custom way to mitigate the same vulnerability.
Most users fall into a few basic categories:
a) they want all mitigations off;
b) they want all reasonable mitigations on, with SMT enabled even if
it's vulnerable; or
c) they want all reasonable mitigations on, with SMT disabled if
vulnerable.
Define a set of curated, arch-independent options, each of which is an
aggregation of existing options:
- mitigations=off: Disable all mitigations.
- mitigations=auto: [default] Enable all the default mitigations, but
leave SMT enabled, even if it's vulnerable.
- mitigations=auto,nosmt: Enable all the default mitigations, disabling
SMT if needed by a mitigation.
Currently, these options are placeholders which don't actually do
anything. They will be fleshed out in upcoming patches.
Signed-off-by: Josh Poimboeuf
Signed-off-by: Thomas Gleixner
Tested-by: Jiri Kosina (on x86)
Reviewed-by: Jiri Kosina
Cc: Borislav Petkov
Cc: "H . Peter Anvin"
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Jiri Kosina
Cc: Waiman Long
Cc: Andrea Arcangeli
Cc: Jon Masters
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: linux-s...@vger.kernel.org
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-a...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: Tyler Hicks
Cc: Linus Torvalds
Cc: Randy Dunlap
Cc: Steven Price
Cc: Phil Auld
Link:
https://lkml.kernel.org/r/b07a8ef9b7c5055c3a4637c87d07c296d5016fe0.1555085500.git.jpoim...@redhat.com
[bwh: Backported to 3.16:
- Drop the auto,nosmt option which we can't support
- Adjust filename]
Signed-off-by: Ben Hutchings
---
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1906,6 +1906,25 @@ bytes respectively. Such letter suffixes
in the "bleeding edge" mini2440 support kernel at
http://repo.or.cz/w/linux-2.6/mini2440.git
+ mitigations=
+ Control optional mitigations for CPU vulnerabilities.
+ This is a set of curated, arch-independent options, each
+ of which is an aggregation of existing arch-specific
+ options.
+
+ off
+ Disable all optional CPU mitigations. This
+ improves system performance, but it may also
+ expose users to several CPU vulnerabilities.
+
+ auto (default)
+ Mitigate all CPU vulnerabilities, but leave SMT
+ enabled, even if it's vulnerable. This is for
+ users who don't want to be surprised by SMT
+ getting disabled across kernel upgrades, or who
+ have other ways of avoiding SMT-based attacks.
+ This is the default behavior.
+
mminit_loglevel=
[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
parameter allows control of the logging verbosity for
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -277,4 +277,21 @@ void arch_cpu_idle_enter(void);
void arch_cpu_idle_exit(void);
void arch_cpu_idle_dead(void);
+/*
+ * These are used for a global "mitigations=" cmdline option for toggling
+ * optional CPU mitigations.
+ */
+enum cpu_mitigations {
+ CPU_MITIGATIONS_OFF,
+ CPU_MITIGATIONS_AUTO,
+};
+
+extern enum cpu_mitigations cpu_mitigations;
+
+/* mitigations=off */
+static inline bool cpu_mitigations_off(void)
+{
+ return cpu_mitigations == CPU_MITIGATIONS_OFF;
+}
+
#endif /* _LINUX_CPU_H_ */
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -795,3 +795,16 @@ void init_cpu_online(const struct cpumas
{
cpumask_copy(to_cpumask(cpu_online_bits), src);
}
+
+enum cpu_mitigations cpu_mitigations = CPU_MITIGATIONS_AUTO;
+
+static int __init mitigations_parse_cmdline(char *arg)
+{
+ if (!strcmp(arg, "off"))
+ cpu_mitigations = CPU_MITIGATIONS_OFF;
+ else if (!strcmp(arg, "auto"))
+ cpu_mitigations = CPU_MITIGATIONS_AUTO;
+
+ return 0;
+}
+early_param("mitigations", mitigations_parse_cmdline);
[PATCH 3.16 08/86] jump_label: Allow asm/jump_label.h to be included in assembly
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Anton Blanchard
commit 55dd0df781e58ec23d218376ea4a676e7362a98c upstream.
Wrap asm/jump_label.h for all archs with #ifndef __ASSEMBLY__.
Since these are kernel only headers, we don't need #ifdef
__KERNEL__ so can simplify things a bit.
If an architecture wants to use jump labels in assembly, it
will still need to define a macro to create the __jump_table
entries (see ARCH_STATIC_BRANCH in the powerpc asm/jump_label.h
for an example).
Signed-off-by: Anton Blanchard
Acked-by: Peter Zijlstra (Intel)
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: b...@kernel.crashing.org
Cc: catalin.mari...@arm.com
Cc: da...@davemloft.net
Cc: heiko.carst...@de.ibm.com
Cc: jba...@akamai.com
Cc: li...@arm.linux.org.uk
Cc: linuxppc-dev@lists.ozlabs.org
Cc: liu...@gmail.com
Cc: mgor...@suse.de
Cc: mma...@suse.cz
Cc: m...@ellerman.id.au
Cc: pau...@samba.org
Cc: r...@linux-mips.org
Cc: rost...@goodmis.org
Cc: schwidef...@de.ibm.com
Cc: will.dea...@arm.com
Link: http://lkml.kernel.org/r/1428551492-21977-1-git-send-email-an...@samba.org
Signed-off-by: Ingo Molnar
Signed-off-by: Ben Hutchings
---
arch/arm/include/asm/jump_label.h | 5 ++---
arch/arm64/include/asm/jump_label.h | 8
arch/mips/include/asm/jump_label.h | 7 +++
arch/s390/include/asm/jump_label.h | 3 +++
arch/sparc/include/asm/jump_label.h | 5 ++---
arch/x86/include/asm/jump_label.h | 5 ++---
6 files changed, 16 insertions(+), 17 deletions(-)
--- a/arch/arm/include/asm/jump_label.h
+++ b/arch/arm/include/asm/jump_label.h
@@ -1,7 +1,7 @@
#ifndef _ASM_ARM_JUMP_LABEL_H
#define _ASM_ARM_JUMP_LABEL_H
-#ifdef __KERNEL__
+#ifndef __ASSEMBLY__
#include
@@ -27,8 +27,6 @@ l_yes:
return true;
}
-#endif /* __KERNEL__ */
-
typedef u32 jump_label_t;
struct jump_entry {
@@ -37,4 +35,5 @@ struct jump_entry {
jump_label_t key;
};
+#endif /* __ASSEMBLY__ */
#endif
--- a/arch/arm64/include/asm/jump_label.h
+++ b/arch/arm64/include/asm/jump_label.h
@@ -18,11 +18,12 @@
*/
#ifndef __ASM_JUMP_LABEL_H
#define __ASM_JUMP_LABEL_H
+
+#ifndef __ASSEMBLY__
+
#include
#include
-#ifdef __KERNEL__
-
#define JUMP_LABEL_NOP_SIZEAARCH64_INSN_SIZE
static __always_inline bool arch_static_branch(struct static_key *key)
@@ -39,8 +40,6 @@ l_yes:
return true;
}
-#endif /* __KERNEL__ */
-
typedef u64 jump_label_t;
struct jump_entry {
@@ -49,4 +48,5 @@ struct jump_entry {
jump_label_t key;
};
+#endif /* __ASSEMBLY__ */
#endif /* __ASM_JUMP_LABEL_H */
--- a/arch/mips/include/asm/jump_label.h
+++ b/arch/mips/include/asm/jump_label.h
@@ -8,9 +8,9 @@
#ifndef _ASM_MIPS_JUMP_LABEL_H
#define _ASM_MIPS_JUMP_LABEL_H
-#include
+#ifndef __ASSEMBLY__
-#ifdef __KERNEL__
+#include
#define JUMP_LABEL_NOP_SIZE 4
@@ -39,8 +39,6 @@ l_yes:
return true;
}
-#endif /* __KERNEL__ */
-
#ifdef CONFIG_64BIT
typedef u64 jump_label_t;
#else
@@ -53,4 +51,5 @@ struct jump_entry {
jump_label_t key;
};
+#endif /* __ASSEMBLY__ */
#endif /* _ASM_MIPS_JUMP_LABEL_H */
--- a/arch/s390/include/asm/jump_label.h
+++ b/arch/s390/include/asm/jump_label.h
@@ -1,6 +1,8 @@
#ifndef _ASM_S390_JUMP_LABEL_H
#define _ASM_S390_JUMP_LABEL_H
+#ifndef __ASSEMBLY__
+
#include
#define JUMP_LABEL_NOP_SIZE 6
@@ -39,4 +41,5 @@ struct jump_entry {
jump_label_t key;
};
+#endif /* __ASSEMBLY__ */
#endif
--- a/arch/sparc/include/asm/jump_label.h
+++ b/arch/sparc/include/asm/jump_label.h
@@ -1,7 +1,7 @@
#ifndef _ASM_SPARC_JUMP_LABEL_H
#define _ASM_SPARC_JUMP_LABEL_H
-#ifdef __KERNEL__
+#ifndef __ASSEMBLY__
#include
@@ -22,8 +22,6 @@ l_yes:
return true;
}
-#endif /* __KERNEL__ */
-
typedef u32 jump_label_t;
struct jump_entry {
@@ -32,4 +30,5 @@ struct jump_entry {
jump_label_t key;
};
+#endif /* __ASSEMBLY__ */
#endif
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -1,7 +1,7 @@
#ifndef _ASM_X86_JUMP_LABEL_H
#define _ASM_X86_JUMP_LABEL_H
-#ifdef __KERNEL__
+#ifndef __ASSEMBLY__
#include
#include
@@ -30,8 +30,6 @@ l_yes:
return true;
}
-#endif /* __KERNEL__ */
-
#ifdef CONFIG_X86_64
typedef u64 jump_label_t;
#else
@@ -44,4 +42,5 @@ struct jump_entry {
jump_label_t key;
};
+#endif /* __ASSEMBLY__ */
#endif
[PATCH 3.16 80/86] x86/speculation: Support 'mitigations=' cmdline option
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Josh Poimboeuf
commit d68be4c4d31295ff6ae34a8ddfaa4c1a8ff42812 upstream.
Configure x86 runtime CPU speculation bug mitigations in accordance with
the 'mitigations=' cmdline option. This affects Meltdown, Spectre v2,
Speculative Store Bypass, and L1TF.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
Signed-off-by: Thomas Gleixner
Tested-by: Jiri Kosina (on x86)
Reviewed-by: Jiri Kosina
Cc: Borislav Petkov
Cc: "H . Peter Anvin"
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Jiri Kosina
Cc: Waiman Long
Cc: Andrea Arcangeli
Cc: Jon Masters
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: linux-s...@vger.kernel.org
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-a...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: Tyler Hicks
Cc: Linus Torvalds
Cc: Randy Dunlap
Cc: Steven Price
Cc: Phil Auld
Link:
https://lkml.kernel.org/r/6616d0ae169308516cfdf5216bedd169f8a8291b.1555085500.git.jpoim...@redhat.com
[bwh: Backported to 3.16:
- Drop the auto,nosmt option and the l1tf mitigation selection, which we can't
support
- Adjust filenames, context]
Signed-off-by: Ben Hutchings
---
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1907,15 +1907,19 @@ bytes respectively. Such letter suffixes
http://repo.or.cz/w/linux-2.6/mini2440.git
mitigations=
- Control optional mitigations for CPU vulnerabilities.
- This is a set of curated, arch-independent options, each
- of which is an aggregation of existing arch-specific
- options.
+ [X86] Control optional mitigations for CPU
+ vulnerabilities. This is a set of curated,
+ arch-independent options, each of which is an
+ aggregation of existing arch-specific options.
off
Disable all optional CPU mitigations. This
improves system performance, but it may also
expose users to several CPU vulnerabilities.
+ Equivalent to: nopti [X86]
+ nospectre_v2 [X86]
+ spectre_v2_user=off [X86]
+ spec_store_bypass_disable=off
[X86]
auto (default)
Mitigate all CPU vulnerabilities, but leave SMT
@@ -1923,7 +1927,7 @@ bytes respectively. Such letter suffixes
users who don't want to be surprised by SMT
getting disabled across kernel upgrades, or who
have other ways of avoiding SMT-based attacks.
- This is the default behavior.
+ Equivalent to: (default behavior)
mminit_loglevel=
[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -545,7 +545,8 @@ static enum spectre_v2_mitigation_cmd __
char arg[20];
int ret, i;
- if (cmdline_find_option_bool(boot_command_line, "nospectre_v2"))
+ if (cmdline_find_option_bool(boot_command_line, "nospectre_v2") ||
+ cpu_mitigations_off())
return SPECTRE_V2_CMD_NONE;
ret = cmdline_find_option(boot_command_line, "spectre_v2", arg,
sizeof(arg));
@@ -809,7 +810,8 @@ static enum ssb_mitigation_cmd __init ss
char arg[20];
int ret, i;
- if (cmdline_find_option_bool(boot_command_line,
"nospec_store_bypass_disable")) {
+ if (cmdline_find_option_bool(boot_command_line,
"nospec_store_bypass_disable") ||
+ cpu_mitigations_off()) {
return SPEC_STORE_BYPASS_CMD_NONE;
} else {
ret = cmdline_find_option(boot_command_line,
"spec_store_bypass_disable",
--- a/arch/x86/mm/kaiser.c
+++ b/arch/x86/mm/kaiser.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#undef pr_fmt
@@ -294,7 +295,8 @@ void __init kaiser_check_boottime_disabl
goto skip;
}
- if (cmdline_find_option_bool(boot_command_line, "nopti"))
+ if (cmdline_find_option_bool(boot_command_line, "nopti") ||
+ cpu_mitigations_off())
goto disable;
skip:
[PATCH 3.16 92/99] block/swim3: Fix -EBUSY error when re-opening device after unmount
3.16.65-rc1 review patch. If anyone has any objections, please let me know.
--
From: Finn Thain
commit 296dcc40f2f2e402facf7cd26cf3f2c8f4b17d47 upstream.
When the block device is opened with FMODE_EXCL, ref_count is set to -1.
This value doesn't get reset when the device is closed which means the
device cannot be opened again. Fix this by checking for refcount <= 0
in the release method.
Reported-and-tested-by: Stan Johnson
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Finn Thain
Signed-off-by: Jens Axboe
Signed-off-by: Ben Hutchings
---
drivers/block/swim3.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/block/swim3.c
+++ b/drivers/block/swim3.c
@@ -1027,7 +1027,11 @@ static void floppy_release(struct gendis
struct swim3 __iomem *sw = fs->swim3;
mutex_lock(_mutex);
- if (fs->ref_count > 0 && --fs->ref_count == 0) {
+ if (fs->ref_count > 0)
+ --fs->ref_count;
+ else if (fs->ref_count == -1)
+ fs->ref_count = 0;
+ if (fs->ref_count == 0) {
swim3_action(fs, MOTOR_OFF);
out_8(>control_bic, 0xff);
swim3_select(fs, RELAX);
Re: powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations
On Mon, 2019-03-25 at 01:03 +0100, Andreas Schwab wrote: > On Mär 24 2019, Ben Hutchings wrote: > > > Presumably you have CONFIG_PPC_BOOK3S_64 enabled and > > CONFIG_SPARSEMEM > > disabled? Was this configuration actually usable? > > Why not? I assume that CONFIG_SPARSEMEM is the default for a good reason. What I don't know is how strong that reason is (I am not a Power expert at all). Looking a bit further, it seems to be related to CONFIG_NUMA in that you can enable CONFIG_FLATMEM if and only if that's disabled. So I suppose the configuration you used works for non-NUMA systems. Anyway, does the patch I sent work for you? Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your signature. signature.asc Description: This is a digitally signed message part
Re: powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations
On Sun, 2019-03-24 at 23:18 +0100, Andreas Schwab wrote:
> On Mär 22 2019, Michael Ellerman wrote:
>
> > On Sun, 2019-03-17 at 01:17:56 UTC, Ben Hutchings wrote:
> > > MAX_PHYSMEM_BITS only needs to be defined if CONFIG_SPARSEMEM is
> > > enabled, and that was the case before commit 4ffe713b7587
> > > ("powerpc/mm: Increase the max addressable memory to 2PB").
> > >
> > > On 32-bit systems, where CONFIG_SPARSEMEM is not enabled, we now
> > > define it as 46. That is larger than the real number of physical
> > > address bits, and breaks calculations in zsmalloc:
> > >
> > > mm/zsmalloc.c:130:49: warning: right shift count is negative
> > > [-Wshift-count-negative]
> > > MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
> > > ^~
> > > ...
> > > mm/zsmalloc.c:253:21: error: variably modified 'size_class' at file
> > > scope
> > > struct size_class *size_class[ZS_SIZE_CLASSES];
> > > ^~
> > >
> > > Fixes: 4ffe713b7587 ("powerpc/mm: Increase the max addressable memory to
> > > 2PB")
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Ben Hutchings
> >
> > Applied to powerpc fixes, thanks.
> >
> > https://git.kernel.org/powerpc/c/8bc086899816214fbc6047c9c7e15fca
>
> In file included from ./arch/powerpc/include/asm/book3s/64/mmu.h:39:0,
> from ./arch/powerpc/include/asm/mmu.h:360,
> from ./arch/powerpc/include/asm/lppaca.h:36,
> from ./arch/powerpc/include/asm/paca.h:21,
> from ./arch/powerpc/include/asm/current.h:16,
> from ./include/linux/thread_info.h:21,
> from ./include/asm-generic/preempt.h:5,
> from ./arch/powerpc/include/generated/asm/preempt.h:1,
> from ./include/linux/preempt.h:78,
> from ./include/linux/spinlock.h:51,
> from ./include/linux/mmzone.h:8,
> from ./include/linux/gfp.h:6,
> from ./include/linux/slab.h:15,
> from ./include/linux/crypto.h:24,
> from ./include/crypto/algapi.h:15,
> from ./include/crypto/internal/hash.h:16,
> from arch/powerpc/crypto/md5-glue.c:15:
> ./arch/powerpc/include/asm/book3s/64/mmu-hash.h:584:6: error:
> "MAX_PHYSMEM_BITS" is not defined [-Werror=undef]
> #if (MAX_PHYSMEM_BITS > MAX_EA_BITS_PER_CONTEXT)
> ^
Presumably you have CONFIG_PPC_BOOK3S_64 enabled and CONFIG_SPARSEMEM
disabled? Was this configuration actually usable?
I think this would fix the build failure:
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -341,7 +341,7 @@ static inline u16 get_mm_addr_key(struct mm_struct
*mm, unsigned long address)
#if defined(CONFIG_SPARSEMEM_VMEMMAP) &&
defined(CONFIG_SPARSEMEM_EXTREME) && \
defined (CONFIG_PPC_64K_PAGES)
#define MAX_PHYSMEM_BITS51
-#elif defined(CONFIG_SPARSEMEM)
+#elif defined(CONFIG_PPC64)
#define MAX_PHYSMEM_BITS46
#endif
--- END ---
but whether the result will actually *work*, I don't know.
Ben.
--
Ben Hutchings
Larkinson's Law: All laws are basically false.
signature.asc
Description: This is a digitally signed message part
[PATCH] powerpc: vdso: Make vdso32 installation conditional in vdso_install
The 32-bit vDSO is not needed and not normally built for 64-bit
little-endian configurations. However, the vdso_install target still
builds and installs it. Add the same config condition as is normally
used for the build.
Fixes: e0d005916994 ("powerpc/vdso: Disable building the 32-bit VDSO ...")
Signed-off-by: Ben Hutchings
---
arch/powerpc/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 488c9edffa58..3def265cf1cf 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -406,7 +406,9 @@ endef
ifdef CONFIG_PPC64
$(Q)$(MAKE) $(build)=arch/$(ARCH)/kernel/vdso64 $@
endif
+ifdef CONFIG_VDSO32
$(Q)$(MAKE) $(build)=arch/$(ARCH)/kernel/vdso32 $@
+endif
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
signature.asc
Description: PGP signature
[PATCH] powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations
MAX_PHYSMEM_BITS only needs to be defined if CONFIG_SPARSEMEM is
enabled, and that was the case before commit 4ffe713b7587
("powerpc/mm: Increase the max addressable memory to 2PB").
On 32-bit systems, where CONFIG_SPARSEMEM is not enabled, we now
define it as 46. That is larger than the real number of physical
address bits, and breaks calculations in zsmalloc:
mm/zsmalloc.c:130:49: warning: right shift count is negative
[-Wshift-count-negative]
MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
^~
...
mm/zsmalloc.c:253:21: error: variably modified 'size_class' at file scope
struct size_class *size_class[ZS_SIZE_CLASSES];
^~
Fixes: 4ffe713b7587 ("powerpc/mm: Increase the max addressable memory to 2PB")
Cc: sta...@vger.kernel.org
Signed-off-by: Ben Hutchings
---
arch/powerpc/include/asm/mmu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 25607604a7a5..2bc8c3f04f8a 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -341,7 +341,7 @@ static inline u16 get_mm_addr_key(struct mm_struct *mm,
unsigned long address)
#if defined(CONFIG_SPARSEMEM_VMEMMAP) && defined(CONFIG_SPARSEMEM_EXTREME) &&
\
defined (CONFIG_PPC_64K_PAGES)
#define MAX_PHYSMEM_BITS51
-#else
+#elif defined(CONFIG_SPARSEMEM)
#define MAX_PHYSMEM_BITS46
#endif
signature.asc
Description: PGP signature
Re: [PATCH] powerpc: Fix -mcpu= options for SPE-only compiler
On Wed, 2018-12-26 at 17:45 -0600, Segher Boessenkool wrote: > Hi! > > On Wed, Dec 26, 2018 at 02:15:11PM +0000, Ben Hutchings wrote: > > GCC for Debian's "powerpcspe" architecture only supports 32-bit > > SPE targets, and using -mcpu=powerpc or -mcpu=powerpc64 is a fatal > > error. > > I don't see where your patch touches -mcpu=powerpc, and I don't see how > it would make a difference either? Look at the assignments that are conditional on HAS_BIARCH. > > +ifdef CONFIG_PPC64 > > ifdef CONFIG_PPC_BOOK3S_64 > > ifdef CONFIG_CPU_LITTLE_ENDIAN > > CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power8 > > @@ -177,6 +178,7 @@ endif > > else > > CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64 > > endif > > +endif > > How can CONFIG_PPC_BOOK3S_64 be true while CONFIG_PPC64 is fals? That > does not make a lot of sense. But there is an "else" part here. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
[PATCH] powerpc: Fix -mcpu= options for SPE-only compiler
GCC for Debian's "powerpcspe" architecture only supports 32-bit SPE targets, and using -mcpu=powerpc or -mcpu=powerpc64 is a fatal error. * Change the test for a biarch compiler to pass both the -m32 and -m64 options, so that it doesn't catch 32-bit-only compilers * Add an ifdef CONFIG_PPC64 around the 64-bit CPU option definitions Signed-off-by: Ben Hutchings --- arch/powerpc/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 488c9edffa58..c2e815863500 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -12,7 +12,7 @@ # Rewritten by Cort Dougan and Paul Mackerras # -HAS_BIARCH := $(call cc-option-yn, -m32) +HAS_BIARCH := $(call cc-option-yn, -m32 -m64) # Set default 32 bits cross compilers for vdso and boot wrapper CROSS32_COMPILE ?= @@ -166,6 +166,7 @@ CFLAGS-$(CONFIG_PPC32) += $(call cc-option, $(MULTIPLEWORD)) CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata) +ifdef CONFIG_PPC64 ifdef CONFIG_PPC_BOOK3S_64 ifdef CONFIG_CPU_LITTLE_ENDIAN CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power8 @@ -177,6 +178,7 @@ endif else CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64 endif +endif ifdef CONFIG_FUNCTION_TRACER CC_FLAGS_FTRACE := -pg signature.asc Description: PGP signature
[PATCH 3.16 153/366] powerpc/e500mc: Set assembler machine type to e500mc
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
--
From: Michael Jeanson
commit 69a8405999aa1c489de4b8d349468f0c2b83f093 upstream.
In binutils 2.26 a new opcode for the "wait" instruction was added for the
POWER9 and has precedence over the one specific to the e500mc. Commit
ebf714ff3756 ("powerpc/e500mc: Add support for the wait instruction in
e500_idle") uses this instruction specifically on the e500mc to work around
an erratum.
This results in an invalid instruction in idle_e500 when we build for the
e500mc on bintutils >= 2.26 with the default assembler machine type.
Since multiplatform between e500 and non-e500 is not supported, set the
assembler machine type globaly when CONFIG_PPC_E500MC=y.
Signed-off-by: Michael Jeanson
Reviewed-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Kumar Gala
CC: Vakul Garg
CC: Scott Wood
CC: Mathieu Desnoyers
CC: linuxppc-dev@lists.ozlabs.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Michael Ellerman
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings
---
arch/powerpc/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -205,6 +205,7 @@ endif
cpu-as-$(CONFIG_4xx) += -Wa,-m405
cpu-as-$(CONFIG_ALTIVEC) += -Wa,-maltivec
cpu-as-$(CONFIG_E200) += -Wa,-me200
+cpu-as-$(CONFIG_PPC_E500MC)+= $(call as-option,-Wa$(comma)-me500mc)
KBUILD_AFLAGS += $(cpu-as-y)
KBUILD_CFLAGS += $(cpu-as-y)
[PATCH 3.16 122/370] powerpc: Fix build warning on 32-bit PPC
3.16.42-rc1 review patch. If anyone has any objections, please let me know.
--
From: Larry Finger <larry.fin...@lwfinger.net>
commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream.
I am getting the following warning when I build kernel 4.9-git on my
PowerBook G4 with a 32-bit PPC processor:
AS arch/powerpc/kernel/misc_32.o
arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not
defined [-Wundef]
This problem is evident after commit 989cea5c14be ("kbuild: prevent
lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
error that has been in the code since 2005 when this source file was
created. That was with commit 9994a33865f4 ("powerpc: Introduce
entry_{32,64}.S, misc_{32,64}.S, systbl.S").
The offending line does not make a lot of sense. This error does not
seem to cause any errors in the executable, thus I am not recommending
that it be applied to any stable versions.
Thanks to Nicholas Piggin for suggesting this solution.
Fixes: 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S,
systbl.S")
Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
Cc: Nicholas Piggin <npig...@gmail.com>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
arch/powerpc/kernel/misc_32.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -313,7 +313,7 @@ _GLOBAL(flush_instruction_cache)
lis r3, KERNELBASE@h
iccci 0,r3
#endif
-#elif CONFIG_FSL_BOOKE
+#elif defined(CONFIG_FSL_BOOKE)
BEGIN_FTR_SECTION
mfspr r3,SPRN_L1CSR0
ori r3,r3,L1CSR0_CFI|L1CSR0_CLFC
Re: [PATCH] kbuild: avoid unrecognized option error for external DTC
On Mon, 2017-02-27 at 14:40 +0900, Masahiro Yamada wrote:
> Since commit 6b22b3d1614a ("kbuild: Allow using host dtc instead of
> kernel's copy"), it is possible to use an external dtc. In this
> case, we do not know which options are supported on it.
>
> Commit bc553986a2f7 ("dtc: turn off dtc unit address warnings by
> default") gives -Wno-unit_address_vs_reg, but this options is only
> recognized by v1.4.2 or later.
>
> If an older version is specified, the build fails:
But the option to use an external dtc was intended to allow testing of
newer versions. If there's no reason to use this option to run an
older version, why bother trying to support that?
[...]
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -171,6 +171,20 @@ ld-version = $(shell $(LD) --version |
> $(srctree)/scripts/ld-version.sh)
> # Usage: $(call ld-ifversion, -ge, 22252, y)
> ld-ifversion = $(shell [ $(ld-version) $(1) $(2) ] && echo $(3) || echo $(4))
>
> +# dtc-option
> +# Usage: DTC_FLAGS += $(call dtc-option,-Wno-unit_address_vs_reg)
> +#
> +# When we use the external dtc, check if the desired options are supported.
> +# When we use the kernel's copy (scripts/dtc/dtc), just use the fixed option.
> +# Until Kbuild descends into the scripts/dtc/ directory, scripts/dtc/dtc may
> +# not exist, i.e. $(call try-run,...) may not work.
> +ifeq ("$(origin DTC)", "command line")
[...]
It could also be specified as an environment variable (assignment with
"?=" doesn't override them, but "=" does).
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 1/2] powerpc: Remove Mac-on-Linux hooks
On Fri, Dec 02, 2016 at 02:56:47PM +1100, Michael Ellerman wrote: > Ben Hutchings <b...@decadent.org.uk> writes: > > > [ Unknown signature status ] > > The symbols exported for use by MOL aren't getting CRCs and I was > > about to fix that. But MOL is dead upstream, and the latest work on > > it was to make it use KVM instead of its own kernel module. So remove > > them instead. > > Sounds good to me. > > > diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S > > index 9d963547d243..87998430cd9b 100644 > > --- a/arch/powerpc/kernel/head_32.S > > +++ b/arch/powerpc/kernel/head_32.S > > @@ -735,11 +735,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_NEED_DTLB_SW_LRU) > > EXCEPTION(0x2c00, Trap_2c, unknown_exception, EXC_XFER_EE) > > EXCEPTION(0x2d00, Trap_2d, unknown_exception, EXC_XFER_EE) > > EXCEPTION(0x2e00, Trap_2e, unknown_exception, EXC_XFER_EE) > > - EXCEPTION(0x2f00, MOLTrampoline, unknown_exception, EXC_XFER_EE_LITE) > > - > > - .globl mol_trampoline > > - .set mol_trampoline, i0x2f00 > > - EXPORT_SYMBOL(mol_trampoline) > > + EXCEPTION(0x2f00, Trap_2f, unknown_exception, EXC_XFER_EE) > > > > . = 0x3000 > > > > @@ -1289,7 +1285,6 @@ intercept_table: > > .long 0, 0, 0, 0, 0, 0, 0, 0 > > .long 0, 0, 0, 0, 0, 0, 0, 0 > > .long 0, 0, 0, 0, 0, 0, 0, 0 > > -EXPORT_SYMBOL(intercept_table) > > I don't see intercept_table used anywhere, so I think we can just remove > it entirely? That's strange, so it's actually constant data. And... I've managed to confuse myself about which symbols are for MOL. This one was actually used by rtlinux, which AFAICS is also long dead. > > diff --git a/arch/powerpc/mm/hash_low_32.S b/arch/powerpc/mm/hash_low_32.S > > index 09cc50c8dace..cddf14f60bf3 100644 > > --- a/arch/powerpc/mm/hash_low_32.S > > +++ b/arch/powerpc/mm/hash_low_32.S > > @@ -34,7 +34,6 @@ > > .globl mmu_hash_lock > > mmu_hash_lock: > > .space 4 > > -EXPORT_SYMBOL(mmu_hash_lock) > > #endif /* CONFIG_SMP */ > > And now mmu_hash_lock is only used in this file, so doesn't need to be > global anymore. Right. Ben. > I can fix both of those up here, will just wait a bit to see if anyone > else has comments. > > cheers -- Ben Hutchings It's easier to fight for one's principles than to live up to them. signature.asc Description: Digital signature
[PATCH 2/2] powerpc: Fix missing CRCs, add yet more asm-prototypes.h declarations
Add declarations for: - __mfdcr, __mtdcr (if CONFIG_PPC_DCR_NATIVE=y; through ) - switch_mmu_context (if CONFIG_PPC_BOOK3S_64=n; through ) Signed-off-by: Ben Hutchings <b...@decadent.org.uk> --- I checked all the symbols potentially exported from assembly under arch/powerpc, and these seem to be the only ones not yet declared through asm-prototypes.h (aside from those supporting Mac-on-Linux which are removed by the previous patch). Ben. arch/powerpc/include/asm/asm-prototypes.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h index e0baba1535e6..ba0225ff38f8 100644 --- a/arch/powerpc/include/asm/asm-prototypes.h +++ b/arch/powerpc/include/asm/asm-prototypes.h @@ -18,6 +18,8 @@ #include #include #include +#include +#include #include signature.asc Description: Digital signature
[PATCH 1/2] powerpc: Remove Mac-on-Linux hooks
The symbols exported for use by MOL aren't getting CRCs and I was about to fix that. But MOL is dead upstream, and the latest work on it was to make it use KVM instead of its own kernel module. So remove them instead. Signed-off-by: Ben Hutchings <b...@decadent.org.uk> --- arch/powerpc/kernel/head_32.S | 7 +-- arch/powerpc/mm/hash_low_32.S | 1 - 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index 9d963547d243..87998430cd9b 100644 --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -735,11 +735,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_NEED_DTLB_SW_LRU) EXCEPTION(0x2c00, Trap_2c, unknown_exception, EXC_XFER_EE) EXCEPTION(0x2d00, Trap_2d, unknown_exception, EXC_XFER_EE) EXCEPTION(0x2e00, Trap_2e, unknown_exception, EXC_XFER_EE) - EXCEPTION(0x2f00, MOLTrampoline, unknown_exception, EXC_XFER_EE_LITE) - - .globl mol_trampoline - .set mol_trampoline, i0x2f00 - EXPORT_SYMBOL(mol_trampoline) + EXCEPTION(0x2f00, Trap_2f, unknown_exception, EXC_XFER_EE) . = 0x3000 @@ -1289,7 +1285,6 @@ intercept_table: .long 0, 0, 0, 0, 0, 0, 0, 0 .long 0, 0, 0, 0, 0, 0, 0, 0 .long 0, 0, 0, 0, 0, 0, 0, 0 -EXPORT_SYMBOL(intercept_table) /* Room for two PTE pointers, usually the kernel and current user pointers * to their respective root page table. diff --git a/arch/powerpc/mm/hash_low_32.S b/arch/powerpc/mm/hash_low_32.S index 09cc50c8dace..cddf14f60bf3 100644 --- a/arch/powerpc/mm/hash_low_32.S +++ b/arch/powerpc/mm/hash_low_32.S @@ -34,7 +34,6 @@ .globl mmu_hash_lock mmu_hash_lock: .space 4 -EXPORT_SYMBOL(mmu_hash_lock) #endif /* CONFIG_SMP */ /* signature.asc Description: Digital signature
Re: [PATCH] cxl: Fix potential build failure - select ANON_INODES
On Thu, 2016-11-17 at 09:30 +1100, Andrew Donnellan wrote:
> On 17/11/16 05:29, Ben Hutchings wrote:
> > cxl calls anon_inode_get() so must select ANON_INODES.
> >
> > Fixes: 6f7f0b3df6d4 ("cxl: Add AFU virtual PHB and kernel API")
> > Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
>
> Thanks for catching this.
>
> Is this patch still necessary once
> http://patchwork.ozlabs.org/patch/694415/ is applied though?
It doesn't appear to be.
Ben.
--
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at
once.
signature.asc
Description: This is a digitally signed message part
[PATCH] cxl: Fix potential build failure - select ANON_INODES
cxl calls anon_inode_get() so must select ANON_INODES.
Fixes: 6f7f0b3df6d4 ("cxl: Add AFU virtual PHB and kernel API")
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
drivers/misc/cxl/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
index b75cf830d08a..e745f77ac6a6 100644
--- a/drivers/misc/cxl/Kconfig
+++ b/drivers/misc/cxl/Kconfig
@@ -16,6 +16,7 @@ config CXL
depends on PPC_POWERNV && PCI_MSI && EEH
select CXL_BASE
select CXL_AFU_DRIVER_OPS
+ select ANON_INODES
default m
help
Select this option to enable driver support for IBM Coherent
signature.asc
Description: Digital signature
[PATCH] powerpc/boot: Fix build failure in 32-bit boot wrapper
OPAL is not callable from 32-bit mode and the assembly code for it
may not even build (depending on how binutils was configured).
References:
https://buildd.debian.org/status/fetch.php?pkg=linux=powerpcspe=4.8.7-1=1479203712
Fixes: 656ad58ef19e ("powerpc/boot: Add OPAL console to epapr wrappers")
Cc: stable <sta...@vger.kernel.org> # 4.8
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
I build-tested this (only) with minimal configurations for:
- 32-bit big-endian, CONFIG_PPC_85xx
- 64-bit big-endian, CONFIG_PPC_BOOK3S_64
- 64-bit little-endian, CONFIG_PPC_BOOK3S_64
Ben.
arch/powerpc/boot/Makefile | 3 ++-
arch/powerpc/boot/opal.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index eae2dc8bc218..9d47f2efa830 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -100,7 +100,8 @@ src-wlib-y := string.S crt0.S crtsavres.S stdio.c
decompress.c main.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
elf_util.c $(zlib-y) devtree.c stdlib.c \
oflib.c ofconsole.c cuboot.c mpsc.c cpm-serial.c \
- uartlite.c mpc52xx-psc.c opal.c opal-calls.S
+ uartlite.c mpc52xx-psc.c opal.c
+src-wlib-$(CONFIG_PPC64_BOOT_WRAPPER) += opal-calls.S
src-wlib-$(CONFIG_40x) += 4xx.c planetcore.c
src-wlib-$(CONFIG_44x) += 4xx.c ebony.c bamboo.c
src-wlib-$(CONFIG_8xx) += mpc8xx.c planetcore.c fsl-soc.c
diff --git a/arch/powerpc/boot/opal.c b/arch/powerpc/boot/opal.c
index 1f37e1c1d6d8..c2659978ef0c 100644
--- a/arch/powerpc/boot/opal.c
+++ b/arch/powerpc/boot/opal.c
@@ -13,7 +13,7 @@
#include
#include "../include/asm/opal-api.h"
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64_BOOT_WRAPPER
/* Global OPAL struct used by opal-call.S */
struct opal {
signature.asc
Description: Digital signature
Re: powerpc/mm: Fix HAVE_ARCH_SOFT_DIRTY dependencies
On Mon, 2016-02-22 at 19:24 +1100, Michael Ellerman wrote:
> On Sat, 2016-20-02 at 17:58:37 UTC, Ben Hutchings wrote:
> > Soft dirty bit support was only implemented for 64-bit Book3S, and
> > 32-bit configurations currently fail to build.
> >
> > Fixes: 7207f43665b8 ("powerpc/mm: Add page soft dirty tracking")
> > References:
> > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=4.5%7Erc4-1%7Eexp1=1455791718
> > Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
>
> Thanks for the patch Ben.
>
> I merged a similar but not identical patch into my fixes branch last week, and
> Linus merged it over the weekend. Let me know if it isn't sufficient for you:
>
> https://git.kernel.org/torvalds/c/19f97c983071
Yes that works, thanks.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc/mm: Fix HAVE_ARCH_SOFT_DIRTY dependencies
Soft dirty bit support was only implemented for 64-bit Book3S, and
32-bit configurations currently fail to build.
Fixes: 7207f43665b8 ("powerpc/mm: Add page soft dirty tracking")
References:
https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=4.5%7Erc4-1%7Eexp1=1455791718
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -557,7 +557,7 @@ choice
config PPC_4K_PAGES
bool "4k page size"
- select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S
+ select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S_64
config PPC_16K_PAGES
bool "16k page size"
@@ -566,7 +566,7 @@ config PPC_16K_PAGES
config PPC_64K_PAGES
bool "64k page size"
depends on !PPC_FSL_BOOK3E && (44x || PPC_STD_MMU_64 || PPC_BOOK3E_64)
- select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S
+ select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S_64
config PPC_256K_PAGES
bool "256k page size"
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3.2 51/94] locking/mutex: Disable optimistic spinning on some architectures
3.2.62-rc1 review patch. If anyone has any objections, please let me know. -- From: Peter Zijlstra pet...@infradead.org commit 4badad352a6bb202ec68afa7a574c0bb961e5ebc upstream. The optimistic spin code assumes regular stores and cmpxchg() play nice; this is found to not be true for at least: parisc, sparc32, tile32, metag-lock1, arc-!llsc and hexagon. There is further wreckage, but this in particular seemed easy to trigger, so blacklist this. Opt in for known good archs. Signed-off-by: Peter Zijlstra pet...@infradead.org Reported-by: Mikulas Patocka mpato...@redhat.com Cc: David Miller da...@davemloft.net Cc: Chris Metcalf cmetc...@tilera.com Cc: James Bottomley james.bottom...@hansenpartnership.com Cc: Vineet Gupta vgu...@synopsys.com Cc: Jason Low jason.l...@hp.com Cc: Waiman Long waiman.l...@hp.com Cc: James E.J. Bottomley j...@parisc-linux.org Cc: Paul McKenney paul...@linux.vnet.ibm.com Cc: John David Anglin dave.ang...@bell.net Cc: James Hogan james.ho...@imgtec.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: Davidlohr Bueso davidl...@hp.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Catalin Marinas catalin.mari...@arm.com Cc: Russell King li...@arm.linux.org.uk Cc: Will Deacon will.dea...@arm.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: sparcli...@vger.kernel.org Link: http://lkml.kernel.org/r/20140606175316.gv13...@laptop.programming.kicks-ass.net Signed-off-by: Ingo Molnar mi...@kernel.org [bwh: Backported to 3.2: - Adjust context - Drop arm64 change] Signed-off-by: Ben Hutchings b...@decadent.org.uk --- --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1,6 +1,7 @@ config ARM bool default y + select ARCH_SUPPORTS_ATOMIC_RMW select HAVE_DMA_API_DEBUG select HAVE_IDE if PCI || ISA || PCMCIA select HAVE_MEMBLOCK --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -137,6 +137,7 @@ config PPC select HAVE_BPF_JIT if (PPC64 NET) select HAVE_ARCH_JUMP_LABEL select ARCH_HAVE_NMI_SAFE_CMPXCHG + select ARCH_SUPPORTS_ATOMIC_RMW config EARLY_PRINTK bool --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -57,6 +57,7 @@ config SPARC64 select IRQ_PREFLOW_FASTEOI select ARCH_HAVE_NMI_SAFE_CMPXCHG select HAVE_C_RECORDMCOUNT + select ARCH_SUPPORTS_ATOMIC_RMW config ARCH_DEFCONFIG string --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -75,6 +75,7 @@ config X86 select HAVE_BPF_JIT if (X86_64 NET) select CLKEVT_I8253 select ARCH_HAVE_NMI_SAFE_CMPXCHG + select ARCH_SUPPORTS_ATOMIC_RMW config INSTRUCTION_DECODER def_bool (KPROBES || PERF_EVENTS) --- a/kernel/Kconfig.locks +++ b/kernel/Kconfig.locks @@ -198,5 +198,9 @@ config INLINE_WRITE_UNLOCK_IRQ config INLINE_WRITE_UNLOCK_IRQRESTORE def_bool !DEBUG_SPINLOCK ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE +config ARCH_SUPPORTS_ATOMIC_RMW + bool + config MUTEX_SPIN_ON_OWNER - def_bool SMP !DEBUG_MUTEXES + def_bool y + depends on SMP !DEBUG_MUTEXES ARCH_SUPPORTS_ATOMIC_RMW ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ibmveth: Fix more little endian issues
On Tue, 2013-12-24 at 12:55 +1100, Anton Blanchard wrote:
The hypervisor expects MAC addresses passed in registers to be big
endian u64. Create a helper function called ibmveth_encode_mac_addr
which does the right thing in both big and little endian.
We were storing the MAC address in a long in struct ibmveth_adapter.
It's never used so remove it - we don't need another place in the
driver where we create endian issues with MAC addresses.
[...]
@@ -523,10 +523,20 @@ retry:
return rc;
}
+/* The hypervisor expects MAC addresses passed in registers to be
+ * big endian u64.
+ */
+static __be64 ibmveth_encode_mac_addr(char *mac)
+{
+ unsigned long encoded = 0;
u64
+ memcpy(((char *)encoded) + 2, mac, ETH_ALEN);
+ return cpu_to_be64(encoded);
+}
[...]
So on big-endian systems the byte order of the result will be:
0 0 mac0 mac1 mac2 mac3 mac4 mac5
and on little-endian systems it's:
mac5 mac4 mac3 mac2 mac1 mac0 0 0
It seems to me that 'encoded' is actually in big-endian order and this
function returns the address in CPU order.
So are you sure your explanation isn't backwards, because it looks to me
like the driver was already holding the MAC address in big-endian order
and perhaps the hypercall mechanism does a byte-swap when the guest is
little-endian.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Wed, 2013-11-06 at 12:34 +1100, Alistair Popple wrote: On Tue, 5 Nov 2013 23:11:50 Ben Hutchings wrote: On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote: [snip] It's an SoC bit so there's little point making it generally selectable by the user. I think a better way to do this is: config IBM_EMAC_RGMII_WOL bool IBM EMAC RGMII wake-on-LAN support depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST default y if MY_WONDERFUL_NEW_SOC Then anyone making an API change that affects this driver can check that it still complies. The method used in this patch is the same as what is currently used by the other IBM EMAC PHY interfaces (eg. config IBM_EMAC_ZMII etc). I'm happy to send a patch to update all of those as well for consistency but that would mean adding what each platform requires into EMACS Kconfig as well. Personally I think it is nicer to keep the definitions of what each platform requires in one place (ie. arch/powerpc/platforms/44x/Kconfig) as it is consistent with what we do for other 44x drivers, however I am happy to use the above method if people think it's better. Yes, I see your point. Alternatively we could do something like this: config IBM_EMAC_RGMII_WOL bool default y if COMPILE_TEST default n This would leave the platform dependencies as they are currently but still allow compile testing. It still shouldn't default to y in that case. Instead you can make the symbol conditionally configurable: config IBM_EMAC_RGMII_WOL bool IBM EMAC RGMII wake-on-LAN support if COMPILE_TEST and then select this from your platform Kconfig as you intended. (There is no need to put 'default n' as that's implicit for a configurable symbol. But it doesn't hurt either.) Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote: [...] --- a/drivers/net/ethernet/ibm/emac/Kconfig +++ b/drivers/net/ethernet/ibm/emac/Kconfig @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII bool default n +config IBM_EMAC_RGMII_WOL + bool + default n + [...] So no-one can even build-test this at present! Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote: On Tue, 2013-11-05 at 18:16 +, Ben Hutchings wrote: On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote: [...] --- a/drivers/net/ethernet/ibm/emac/Kconfig +++ b/drivers/net/ethernet/ibm/emac/Kconfig @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII bool default n +config IBM_EMAC_RGMII_WOL + bool + default n + [...] So no-one can even build-test this at present! Patch 7/7 adds the select to the platform, isn't that sufficient ? I suppose so, but I don't think that went to netdev. It's an SoC bit so there's little point making it generally selectable by the user. I think a better way to do this is: config IBM_EMAC_RGMII_WOL bool IBM EMAC RGMII wake-on-LAN support depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST default y if MY_WONDERFUL_NEW_SOC Then anyone making an API change that affects this driver can check that it still complies. Ben. Alistair: The commit name should be different, it's not a PHY you are adding, it's a PHY interface (the PHY itself is off chip). -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing _restvr_20 and _savevr_20 subroutines for lib/raid6/altivec8.o
On Wed, 2013-10-23 at 00:28 -0500, Kumar Gala wrote: On Oct 19, 2013, at 5:24 PM, Ben Hutchings wrote: When building lib/raid6/altivec8.o with gcc 4.8 on Debian, the compiler is generating references to two new runtime subroutines which are apparently not included in the kernel: ERROR: _restvr_20 [lib/raid6/raid6_pq.ko] undefined! ERROR: _savevr_20 [lib/raid6/raid6_pq.ko] undefined! The save/restore subroutines are specified in http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.7.1.html#SAVE-RESTORE and we do have the _restgpr_* and _savegpr_* subroutines in arch/powerpc/boot/crtsavres.S. I'm not sure whether these subroutines should be added or whether this indicates the compiler is doing something wrong. A configuration that triggers this is included below. Ben. Try with CONFIG_CC_OPTIMIZE_FOR_SIZE=n. A feature was added to gcc for -Os to outline the save/restore routines. I'm surprised this hasn't shown up sooner. That does avoid the problem, thanks. Ben. Well need to add _restvr_* / _savevr_* to the version in lib/crtsaveres.S. http://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/config/rs6000/crtrestvr.S;hb=HEAD http://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/config/rs6000/crtsavevr.S;hb=HEAD - k -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/vio: Fix modalias_show return values
Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 introduces a trivial
local denial of service.
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1351,11 +1351,15 @@ static ssize_t modalias_show(struct devi
const char *cp;
dn = dev-of_node;
- if (!dn)
- return -ENODEV;
+ if (!dn) {
+ strcat(buf, \n);
Every read from the same sysfs file handle uses the same buffer, which
gets zero-initialised just once. So if I open the file, read it and
seek back to 0 repeatedly, I can make modalias_show() write arbitrary
numbers of newlines into *and beyond* that page-sized buffer.
Obviously strcat() should be strcpy().
Ben.
+ return strlen(buf);
+ }
cp = of_get_property(dn, compatible, NULL);
- if (!cp)
- return -ENODEV;
+ if (!cp) {
+ strcat(buf, \n);
+ return strlen(buf);
+ }
return sprintf(buf, vio:T%sS%s\n, vio_dev-type, cp);
}
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Tue, 2013-10-08 at 07:10 +1100, Benjamin Herrenschmidt wrote: On Mon, 2013-10-07 at 14:01 -0400, Tejun Heo wrote: I don't think the same race condition would happen with the loop. The problem case is where multiple msi(x) allocation fails completely because the global limit went down before inquiry and allocation. In the loop based interface, it'd retry with the lower number. As long as the number of drivers which need this sort of adaptive allocation isn't too high and the common cases can be made simple, I don't think the complex part of interface is all that important. Maybe we can have reserve / cancel type interface or just keep the loop with more explicit function names (ie. try_enable or something like that). I'm thinking a better API overall might just have been to request individual MSI-X one by one :-) We want to be able to request an MSI-X at runtime anyway ... if I want to dynamically add a queue to my network interface, I want it to be able to pop a new arbitrary MSI-X. Yes, this would be very useful. And we don't want to lock drivers into contiguous MSI-X sets either. I don't think there's any such limitation now. The entries array passed to pci_enable_msix() specifies which MSI-X vectors the driver wants to enable. It's usually filled with 0..nvec-1 in order, but not always. And the IRQ numbers returned aren't usually contiguous either, on x86. Ben. And for the cleanup ... well that's what the pcim functions are for, we can just make MSI-X variants. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Sun, 2013-10-06 at 09:10 +0200, Alexander Gordeev wrote: On Sun, Oct 06, 2013 at 05:19:46PM +1100, Benjamin Herrenschmidt wrote: On Sun, 2013-10-06 at 08:02 +0200, Alexander Gordeev wrote: In fact, in the current design to address the quota race decently the drivers would have to protect the *loop* to prevent the quota change between a pci_enable_msix() returned a positive number and the the next call to pci_enable_msix() with that number. Is it doable? I am not advocating for the current design, simply saying that your proposal doesn't address this issue while Ben's does. There is one major flaw in min-max approach - the generic MSI layer will have to take decisions on exact number of MSIs to request, not device drivers. [... No, the min-max functions should be implemented using the same loop that drivers are expected to use now. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Fri, 2013-10-04 at 10:29 +0200, Alexander Gordeev wrote: On Thu, Oct 03, 2013 at 11:49:45PM +0100, Ben Hutchings wrote: On Wed, 2013-10-02 at 12:48 +0200, Alexander Gordeev wrote: This update converts pci_enable_msix() and pci_enable_msi_block() interfaces to canonical kernel functions and makes them return a error code in case of failure or 0 in case of success. [...] I think this is fundamentally flawed: pci_msix_table_size() and pci_get_msi_cap() can only report the limits of the *device* (which the driver usually already knows), whereas MSI allocation can also be constrained due to *global* limits on the number of distinct IRQs. Even the current implementation by no means addresses it. Although it might seem a case for architectures to report the number of IRQs available for a driver to retry, in fact they all just fail. The same applies to *any* other type of resource involved: irq_desc's, CPU interrupt vector space, msi_desc's etc. No platform cares about it and just bails out once a constrain met (please correct me if I am wrong here). Given that Linux has been doing well even on embedded I think we should not change it. The only exception to the above is pSeries platform which takes advantage of the current design (to implement MSI quota). There are indications we can satisfy pSeries requirements, but the design proposed in this RFC is not going to change drastically anyway. The start of the discusstion is here: https://lkml.org/lkml/2013/9/5/293 All I can see there is that Tejun didn't think that the global limits and positive return values were implemented by any architecture. But you have a counter-example, so I'm not sure what your point is. It has been quite a while since I saw this happen on x86. But I just checked on a test system running RHEL 5 i386 (Linux 2.6.18). If I ask for 16 MSI-X vectors on a device that supports 1024, the return value is 8, and indeed I can then successfully allocate 8. Now that's going quite a way back, and it may be that global limits aren't a significant problem any more. With the x86_64 build of RHEL 5 on an identical system, I can allocate 16 or even 32, so this is apparently not a hardware limit in this case. Currently pci_enable_msix() will report a positive value if it fails due to the global limit. Your patch 7 removes that. pci_enable_msi_block() unfortunately doesn't appear to do this. pci_enable_msi_block() can do more than one MSI only on x86 (with IOMMU), but it does not bother to return positive numbers, indeed. It seems to me that a more useful interface would take a minimum and maximum number of vectors from the driver. This wouldn't allow the driver to specify that it could only accept, say, any even number within a certain range, but you could still leave the current functions available for any driver that needs that. Mmmm.. I am not sure I am getting it. Could you please rephrase? Most drivers seem to either: (a) require exactly a certain number of MSI vectors, or (b) require a minimum number of MSI vectors, usually want to allocate more, and work with any number in between We can support drivers in both classes by adding new allocation functions that allow specifying a minimum (required) and maximum (wanted) number of MSI vectors. Those in class (a) would just specify the same value for both. These new functions can take account of any global limit or allocation policy without any further changes to the drivers that use them. The few drivers with more specific requirements would still need to implement the currently recommended loop, using the old allocation functions. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 01/77] PCI/MSI: Fix return value when populate_msi_sysfs() failed
On Wed, 2013-10-02 at 17:39 -0700, Jon Mason wrote: On Wed, Oct 02, 2013 at 12:48:17PM +0200, Alexander Gordeev wrote: Signed-off-by: Alexander Gordeev agord...@redhat.com Since you are changing the behavior of the msix_capability_init function on populate_msi_sysfs error, a comment describing why in this commit would be nice. [...] This function was already treating that error as fatal, and freeing the MSIs. The change in behaviour is that it now returns the error code in this case, rather than 0. This is obviously correct and properly described by the one-line summary. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 06/77] PCI/MSI: Factor out pci_get_msi_cap() interface
On Wed, 2013-10-02 at 12:48 +0200, Alexander Gordeev wrote:
[...]
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -812,6 +812,21 @@ static int pci_msi_check_device(struct pci_dev *dev, int
nvec, int type)
return 0;
}
+int pci_get_msi_cap(struct pci_dev *dev)
+{
+ int ret;
+ u16 msgctl;
+
+ if (!dev-msi_cap)
+ return -EINVAL;
[...]
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1144,6 +1144,11 @@ struct msix_entry {
#ifndef CONFIG_PCI_MSI
+static inline int pci_get_msi_cap(struct pci_dev *dev)
+{
+ return -1;
[...]
Shouldn't this also return -EINVAL?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Wed, 2013-10-02 at 12:48 +0200, Alexander Gordeev wrote:
This series is against next branch in Bjorn's repo:
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
Currently pci_enable_msi_block() and pci_enable_msix() interfaces
return a error code in case of failure, 0 in case of success and a
positive value which indicates the number of MSI-X/MSI interrupts
that could have been allocated. The latter value should be passed
to a repeated call to the interfaces until a failure or success:
for (i = 0; i FOO_DRIVER_MAXIMUM_NVEC; i++)
adapter-msix_entries[i].entry = i;
while (nvec = FOO_DRIVER_MINIMUM_NVEC) {
rc = pci_enable_msix(adapter-pdev,
adapter-msix_entries, nvec);
if (rc 0)
nvec = rc;
else
return rc;
}
return -ENOSPC;
This technique proved to be confusing and error-prone. Vast share
of device drivers simply fail to follow the described guidelines.
This update converts pci_enable_msix() and pci_enable_msi_block()
interfaces to canonical kernel functions and makes them return a
error code in case of failure or 0 in case of success.
[...]
I think this is fundamentally flawed: pci_msix_table_size() and
pci_get_msi_cap() can only report the limits of the *device* (which the
driver usually already knows), whereas MSI allocation can also be
constrained due to *global* limits on the number of distinct IRQs.
Currently pci_enable_msix() will report a positive value if it fails due
to the global limit. Your patch 7 removes that. pci_enable_msi_block()
unfortunately doesn't appear to do this.
It seems to me that a more useful interface would take a minimum and
maximum number of vectors from the driver. This wouldn't allow the
driver to specify that it could only accept, say, any even number within
a certain range, but you could still leave the current functions
available for any driver that needs that.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote: Provide a helper to set both the DMA and coherent DMA masks to the same value - this avoids duplicated code in a number of drivers, sometimes with buggy error handling, and also allows us identify which drivers do things differently. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Documentation/DMA-API-HOWTO.txt | 37 ++--- Documentation/DMA-API.txt |8 include/linux/dma-mapping.h | 14 ++ 3 files changed, 44 insertions(+), 15 deletions(-) diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 14129f1..5e98303 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt [...] -dma_set_coherent_mask() will always be able to set the same or a -smaller mask as dma_set_mask(). However for the rare case that a +The coherent coherent mask will always be able to set the same or a +smaller mask as the streaming mask. However for the rare case that a [...] The new wording doesn't make sense; a mask doesn't set itself. I would suggest: The coherent mask can always be set to the same or a smaller mask than the streaming mask. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] hvc_vio: Do not override preferred console set by kernel parameter
The original version of this was done by Bastian Blank, who wrote: The problem is the following: - Architecture specific code sets preferred console to something bogus. - Command line handling tries to set preferred console but is overruled by the old setting. The udbg0 console is a boot console and independant. References: http://bugs.debian.org/492703 Signed-off-by: Ben Hutchings b...@decadent.org.uk --- We've been carrying this in Debian for 5 years now, so it's about time it got reviewed. I'm not convinced strstr() is the right way to check the command line (what if there's also a 'netconsole='?). Ben. --- a/drivers/tty/hvc/hvc_vio.c +++ b/drivers/tty/hvc/hvc_vio.c @@ -48,6 +48,7 @@ #include asm/prom.h #include asm/hvsi.h #include asm/udbg.h +#include asm/machdep.h #include hvc_console.h @@ -440,7 +441,9 @@ if (hvterm_priv0.proto == HV_PROTOCOL_HVSI) goto out; #endif - add_preferred_console(hvc, 0, NULL); + /* Check whether the user has requested a different console. */ + if (!strstr(cmd_line, console=)) + add_preferred_console(hvc, 0, NULL); hvc_instantiate(0, 0, ops); out: of_node_put(stdout_node); -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Sat, 2013-08-03 at 06:47 +1000, Benjamin Herrenschmidt wrote: On Fri, 2013-08-02 at 16:47 +0200, Michel Dänzer wrote: On Fre, 2013-08-02 at 22:51 +1000, Benjamin Herrenschmidt wrote: On Fri, 2013-08-02 at 12:03 +0200, Michel Dänzer wrote: Could a similar change fix the same problem on desktop G5s? The same values for slots_param in windfarm_pm112.c don't help, unfortunately. You have a 11,2 and a noisy fan ? Odd, mine(s) don't I can dbl check the values vs. what Darwin uses tomorrow... Yes, see /proc/cpuinfo below. With older kernels (currently still using Debian's 3.2.0-4-powerpc64 because of this problem), the fans go basically silent as soon as the windfarm modules are loaded. With current kernels, the fans stay at the level OF sets them to, until after a while they go into 'airplane mode'. One thing I notice now is that the lines like [9.539173] windfarm: CPUs control loops started. [ 16.209962] windfarm: Backside control loop started. [ 16.262274] windfarm: Slots control loop started. [ 16.371642] windfarm: Drive bay control loop started. no longer appear in dmesg with current kernels. Should they? Yes. Do you have all the windfarm modules loaded ? What about i2c-powermac ? (It's typical that the latter is missed, I think it doesn't auto-load, which we never fixed, we used to request distros to just built it in) We built it as a module in 3.2 and we still do. The regression apparently occurred between 3.8 and 3.9. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix numa distance for form0 device tree
On Tue, 2013-05-07 at 13:49 +1000, Michael Ellerman wrote: From: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com Commit 7122b7bc1757682049780179d7c216dd1c83 upstream. [...] Queued up for 3.2, thanks. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: net/eth/ibmveth: Fixup retrieval of MAC address
On Thu, 2013-05-02 at 11:35 +1000, Benjamin Herrenschmidt wrote:
Some ancient pHyp versions used to create a 8 bytes local-mac-address
property in the device-tree instead of a 6 bytes one for veth.
The Linux driver code to deal with that is an insane hack which also
happens to break with some choices of MAC addresses in qemu by testing
for a bit in the address rather than just looking at the size of the
property.
Sanitize this by doing the latter instead.
[...]
@@ -1334,11 +1334,19 @@ static int ibmveth_probe(struct vio_dev *dev, const
struct vio_device_id *id)
dev-unit_address);
mac_addr_p = (unsigned char *)vio_get_attribute(dev, VETH_MAC_ADDR,
- NULL);
+ mac_len);
if (!mac_addr_p) {
dev_err(dev-dev, Can't find VETH_MAC_ADDR attribute\n);
return -EINVAL;
}
+ /* Workaround for old/broken pHyp */
+ if (mac_len == 8)
+ mac_addr_p += 2;
+ if (mac_len != 6) {
Missing 'else' before the second if?
+ dev_err(dev-dev, VETH_MAC_ADDR attribute wrong len %d\n,
+ mac_len);
+ return -EINVAL;
+ }
[...]
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] af_unix: fix a fatal race with bit fields
On Wed, 2013-05-01 at 11:39 +1000, Benjamin Herrenschmidt wrote: On Tue, 2013-04-30 at 18:12 -0700, Eric Dumazet wrote: From: Eric Dumazet eduma...@google.com Using bit fields is dangerous on ppc64, as the compiler uses 64bit instructions to manipulate them. If the 64bit word includes any atomic_t or spinlock_t, we can lose critical concurrent changes. This is happening in af_unix, where unix_sk(sk)-gc_candidate/ gc_maybe_cycle/lock share the same 64bit word. This leads to fatal deadlock, as one/several cpus spin forever on a spinlock that will never be available again. Reported-by: Ambrose Feinstein ambr...@google.com Signed-off-by: Eric Dumazet eduma...@google.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org --- Could ppc64 experts confirm using byte is safe, or should we really add a 32bit hole after the spinlock ? If so, I wonder how many other places need a change... Wow, nice one ! I'm not even completely certain bytes are safe to be honest, though probably more than bitfields. I'll poke our compiler people. There is a longstanding and hard-to-fix bug in gcc that is specific to bitfields. I think that the underlying type isn't propagated, so when it comes to code generation the compiler doesn't know the natural width for the memory access. As for bytes - early Alphas couldn't load/store less than 32 bits, but I doubt anyone cares any more. The worry is of course how many more of these do we potentially have ? We might be able to automate finding these issues with sparse, I suppose. Also I'd be surprised if ppc64 is the only one with that problem... what about sparc64 and arm64 ? I expect they can have the same general problem, but gcc may be more or less keen to generate 64-bit load/store instructions for bitfields on different architectures. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add GRO support
On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote: This patch adds GRO support to mv643xx_eth by making it invoke napi_gro_receive instead of netif_receive_skb. The inet_lro support should be removed at the same time; inet_lro is now deprecated and there should be no need to keep both of them. Ben. Signed-off-by: Soeren Moch sm...@web.de Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Cc: David S. Miller da...@davemloft.net Cc: Lennert Buytenhek buyt...@wantstofly.org Cc: Andrew Lunn and...@lunn.ch Cc: Jason Cooper ja...@lakedaemon.net Cc: Florian Fainelli flor...@openwrt.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Dale Farnsworth d...@farnsworth.org Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- drivers/net/ethernet/marvell/mv643xx_eth.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c index 305038f..c850d04 100644 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget) lro_receive_skb(rxq-lro_mgr, skb, (void *)cmd_sts); lro_flush_needed = 1; } else - netif_receive_skb(skb); + napi_gro_receive(mp-napi, skb); continue; -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ethtool occationally fails to communicate with with ucc_geth
On Wed, 2013-02-06 at 15:05 -0500, Lennart Sorensen wrote:
We are occationally seeing ethtool fail to communicate with ucc_geth.
I think I have tracked down why it happens, but I don't see a good way
to fix it.
When the phy state changes, adjust_link() checks if the state has changed
and if the link is up. If it is it does:
if (new_state) {
/*
* To change the MAC configuration we need to disable
* the controller. To do so, we have to either grab
* ugeth-lock, which is a bad idea since 'graceful
* stop' commands might take quite a while, or we can
* quiesce driver's activity.
*/
ugeth_quiesce(ugeth);
ugeth_disable(ugeth, COMM_DIR_RX_AND_TX);
out_be32(ug_regs-maccfg2, tempval);
out_be32(uf_regs-upsmr, upsmr);
ugeth_enable(ugeth, COMM_DIR_RX_AND_TX);
ugeth_activate(ugeth);
}
The problem I believe is that ugeth_quiesce() does netif_device_detach
which clears __LINK_STATE_PRESENT, and hence makes dev_ethtool fail
due to:
if (!dev || !netif_device_present(dev))
return -ENODEV;
So if ethtool happens to be run between ugeth_quiesce() and
ugeth_activate(), it fails as if the device simply doesn't exist, which
is of course not true, it's just temporarily disabled.
[...]
Any suggestions?
This seems to be a workaround for a bug in phylib: phy_state_machine()
calls netif_carrier_on() before adjust_link(), so the TX scheduler can
start immediately even though the MAC has not been configured.
A better workaround would be to use netif_carrier_{off,on}() in
ugeth_{quiesce,activate}() respectively instead of
netif_device_{detach,attach}(). But I think phylib really ought to be
fixed.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: fix wii_memory_fixups() compile error on 3.0.y tree
On Wed, 2012-12-12 at 16:27 -0700, Shuah Khan wrote: Fix wii_memory_fixups() the following compile error on 3.0.y tree with wii_defconfig on 3.0.y tree. CC arch/powerpc/platforms/embedded6xx/wii.o arch/powerpc/platforms/embedded6xx/wii.c: In function ‘wii_memory_fixups’: arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format] cc1: all warnings being treated as errors make[2]: *** [arch/powerpc/platforms/embedded6xx/wii.o] Error 1 make[1]: *** [arch/powerpc/platforms/embedded6xx] Error 2 make: *** [arch/powerpc/platforms] Error 2 Signed-off-by: Shuah Khan shuah.k...@hp.com CC: sta...@vger.kernel.org 3.0.y [...] This looks fine, and I've queued it up for 3.2 since the errant code wasn't removed until 3.3. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: fix wii_memory_fixups() compile error on 3.0.y tree
On Mon, Dec 10, 2012 at 10:23:16AM -0700, Shuah Khan wrote: Fix wii_memory_fixups() the following compile error on 3.0.y tree with wii_defconfig on 3.0.y tree. CC arch/powerpc/platforms/embedded6xx/wii.o arch/powerpc/platforms/embedded6xx/wii.c: In function ‘wii_memory_fixups’: arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format] cc1: all warnings being treated as errors make[2]: *** [arch/powerpc/platforms/embedded6xx/wii.o] Error 1 make[1]: *** [arch/powerpc/platforms/embedded6xx] Error 2 make: *** [arch/powerpc/platforms] Error 2 Signed-off-by: Shuah Khan shuah.k...@hp.com CC: sta...@vger.kernel.org 3.0.y --- arch/powerpc/platforms/embedded6xx/wii.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/powerpc/platforms/embedded6xx/wii.c index 1b5dc1a..d8ff38f 100644 --- a/arch/powerpc/platforms/embedded6xx/wii.c +++ b/arch/powerpc/platforms/embedded6xx/wii.c @@ -85,9 +85,11 @@ void __init wii_memory_fixups(void) wii_hole_start = p[0].base + p[0].size; wii_hole_size = p[1].base - wii_hole_start; - pr_info(MEM1: %08llx %08llx\n, p[0].base, p[0].size); + pr_info(MEM1: %08ulx %08ulx\n, + (phys_addr_t) p[0].base, (phys_addr_t) p[0].size); [...] This is incorrect in exactly the same way as the last version, but with extra redundant casts. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix wii_memory_fixups() compile error on 3.0.y tree
On Fri, 2012-12-07 at 19:07 -0700, Shuah Khan wrote: Fix wii_memory_fixups() the following compile error on 3.0.y tree with wii_defconfig on 3.0.y tree. CC arch/powerpc/platforms/embedded6xx/wii.o arch/powerpc/platforms/embedded6xx/wii.c: In function ‘wii_memory_fixups’: arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format] cc1: all warnings being treated as errors make[2]: *** [arch/powerpc/platforms/embedded6xx/wii.o] Error 1 make[1]: *** [arch/powerpc/platforms/embedded6xx] Error 2 make: *** [arch/powerpc/platforms] Error 2 Signed-off-by: Shuah Khan shuah.k...@hp.com CC: sta...@vger.kernel.org 3.0.y --- arch/powerpc/platforms/embedded6xx/wii.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/powerpc/platforms/embedded6xx/wii.c index 1b5dc1a..13d58dd 100644 --- a/arch/powerpc/platforms/embedded6xx/wii.c +++ b/arch/powerpc/platforms/embedded6xx/wii.c @@ -85,9 +85,9 @@ void __init wii_memory_fixups(void) wii_hole_start = p[0].base + p[0].size; wii_hole_size = p[1].base - wii_hole_start; - pr_info(MEM1: %08llx %08llx\n, p[0].base, p[0].size); + pr_info(MEM1: %08ulx %08ulx\n, p[0].base, p[0].size); %08ulx is the conversion specification %08u followed by literal lx. If phys_addr_t is always defined as unsigned long or always unsigned int for this platform then you could use %08lx or %08x respectively. But usually the right thing to do is to cast the arguments of type phys_addr_t to unsigned long long (or, equivalently, u64). Ben. pr_info(HOLE: %08lx %08lx\n, wii_hole_start, wii_hole_size); - pr_info(MEM2: %08llx %08llx\n, p[1].base, p[1].size); + pr_info(MEM2: %08ulx %08ulx\n, p[1].base, p[1].size); p[0].size += wii_hole_size + p[1].size; -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
On Tue, 2012-11-20 at 18:20 +1100, Benjamin Herrenschmidt wrote: On Fri, 2010-07-23 at 14:56 +0100, Ben Hutchings wrote: commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 PCI: MSI: Remove unsafe and unnecessary hardware access changed read_msi_msg_desc() to return the last MSI message written instead of reading it from the device, since it may be called while the device is in a reduced power state. Looks reasonable... Jesse ? [...] So reasonable that it was committed a couple of years ago! Where did you dredge this from? Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] ibm emac: delete module references; phy.c only supported as built-in
On Mon, 2012-02-27 at 14:47 -0500, Paul Gortmaker wrote: The Makefile has it as ibm_emac-y := mal.o core.o phy.o so there is no way this can be built modular, so remove all references to module support. No, that's nonsense. You need to look at whether ibm_emac.o can be added to obj-m (which it can). Ben. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com diff --git a/drivers/net/ethernet/ibm/emac/phy.c b/drivers/net/ethernet/ibm/emac/phy.c index d3b9d10..fb96387 100644 --- a/drivers/net/ethernet/ibm/emac/phy.c +++ b/drivers/net/ethernet/ibm/emac/phy.c @@ -11,13 +11,15 @@ * Copyright 2007 Benjamin Herrenschmidt, IBM Corp. *b...@kernel.crashing.org * + * Originally listed as MODULE_LICENSE(GPL) in the code, but that + * was removed, since this code is only supported as non-modular. + * * Based on the arch/ppc version of the driver: * * (c) 2003, Benjamin Herrenscmidt (b...@kernel.crashing.org) * (c) 2004-2005, Eugene Surovegin e...@ebshome.net * */ -#include linux/module.h #include linux/kernel.h #include linux/types.h #include linux/netdevice.h @@ -537,5 +539,3 @@ int emac_mii_phy_probe(struct mii_phy *phy, int address) return 0; } - -MODULE_LICENSE(GPL); -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Bug#630845: linux-image-2.6.39-2-powerpc: CHRP Pegasos2 boot failure
On Thu, 2011-06-23 at 20:36 +0800, Andrew Buckeridge wrote: Package: linux-image-3.0.0-rc3-powerpc Version: 3.0.0~rc3-1~experimental.1 On Wed, 22 Jun 2011 04:01:38 +0100 Ben Hutchings b...@decadent.org.uk wrote: linux-image-2.6.36-trunk-powerpc_2.6.36-1~experimental.1_powerpc.deb linux-image-2.6.37-1-powerpc_2.6.37-1_powerpc.deb linux-image-2.6.37-2-powerpc_2.6.37-2_powerpc.deb These failed to boot. In all cases stuck at the spinner. At a guess, this may be fixed by a change in Linux 3.0-rc1: Please can you test Linux 3.0-rc3, currently available in experimental? linux-image-3.0.0-rc3-powerpc_3.0.0~rc3-1~experimental.1_powerpc.deb Also failed to boot and got stuck at spinner. Gabriel, Michael, do you recognise this bug? Are there any fixes for Pegasos that are missing from 3.0-rc3? Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/1] BPF JIT for PPC64
On Fri, 2011-06-24 at 16:02 +1000, Matt Evans wrote: [...] + case BPF_S_ALU_ADD_K: /* A += K; */ + if (!K) + break; + if (K 32768) + PPC_ADDI(r_A, r_A, K); + else + PPC_ADDI(r_A, r_A, IMM_L(K)); + PPC_ADDIS(r_A, r_A, IMM_HA(K)); + break; Missing braces. + case BPF_S_ALU_SUB_X: /* A -= X; */ + ctx-seen |= SEEN_XREG; + PPC_SUB(r_A, r_A, r_X); + break; + case BPF_S_ALU_SUB_K: /* A -= K */ + if (!K) + break; + if (K 32768) + PPC_ADDI(r_A, r_A, -K); + else + PPC_ADDI(r_A, r_A, IMM_L(-K)); + PPC_ADDIS(r_A, r_A, IMM_HA(-K)); + break; [...] Here as well. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/kexec: Fix build failure on 32-bit SMP
Commit b987812b3fcaf70fdf0037589e5d2f5f2453e6ce left
crash_kexec_wait_realmode() undefined for UP.
Commit 7c7a81b53e581d727d069cc45df5510516faac31 defined it for UP but
left it undefined for 32-bit SMP.
Seems like people are getting confused by nested #ifdef's, so move the
definitions of crash_kexec_wait_realmode() after the #ifdef CONFIG_SMP
section.
Compile-tested with 32-bit UP, 32-bit SMP and 64-bit SMP configurations.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -162,34 +162,6 @@
/* Leave the IPI callback set */
}
-/* wait for all the CPUs to hit real mode but timeout if they don't come in */
-#ifdef CONFIG_PPC_STD_MMU_64
-static void crash_kexec_wait_realmode(int cpu)
-{
- unsigned int msecs;
- int i;
-
- msecs = 1;
- for (i=0; i NR_CPUS msecs 0; i++) {
- if (i == cpu)
- continue;
-
- while (paca[i].kexec_state KEXEC_STATE_REAL_MODE) {
- barrier();
- if (!cpu_possible(i)) {
- break;
- }
- if (!cpu_online(i)) {
- break;
- }
- msecs--;
- mdelay(1);
- }
- }
- mb();
-}
-#endif /* CONFIG_PPC_STD_MMU_64 */
-
/*
* This function will be called by secondary cpus or by kexec cpu
* if soft-reset is activated to stop some CPUs.
@@ -234,7 +206,6 @@
}
#else /* ! CONFIG_SMP */
-static inline void crash_kexec_wait_realmode(int cpu) {}
static void crash_kexec_prepare_cpus(int cpu)
{
@@ -257,6 +228,36 @@
}
#endif /* CONFIG_SMP */
+/* wait for all the CPUs to hit real mode but timeout if they don't come in */
+#if defined(CONFIG_SMP) defined(CONFIG_PPC_STD_MMU_64)
+static void crash_kexec_wait_realmode(int cpu)
+{
+ unsigned int msecs;
+ int i;
+
+ msecs = 1;
+ for (i=0; i NR_CPUS msecs 0; i++) {
+ if (i == cpu)
+ continue;
+
+ while (paca[i].kexec_state KEXEC_STATE_REAL_MODE) {
+ barrier();
+ if (!cpu_possible(i)) {
+ break;
+ }
+ if (!cpu_online(i)) {
+ break;
+ }
+ msecs--;
+ mdelay(1);
+ }
+ }
+ mb();
+}
+#else
+static inline void crash_kexec_wait_realmode(int cpu) {}
+#endif /* CONFIG_SMP CONFIG_PPC_STD_MMU_64 */
+
/*
* Register a function to be called on shutdown. Only use this if you
* can't reset your device in the second kernel.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V14 3/4] ptp: Added a clock driver for the IXP46x.
On Mon, 2011-04-18 at 08:29 +0200, Richard Cochran wrote:
This patch adds a driver for the hardware time stamping unit found on the
IXP465. The basic clock operations and an external trigger are implemented.
[...]
--- a/drivers/net/arm/ixp4xx_eth.c
+++ b/drivers/net/arm/ixp4xx_eth.c
[...]
@@ -246,6 +255,169 @@ static int ports_open;
static struct port *npe_port_tab[MAX_NPES];
static struct dma_pool *dma_pool;
+static struct sock_filter ptp_filter[] = {
+ PTP_FILTER
+};
+
+static int ixp_ptp_match(struct sk_buff *skb, u16 uid_hi, u32 uid_lo, u16
seq)
+{
+ unsigned int type;
+ u16 *hi, *id;
+ u8 *lo, *data = skb-data;
+
+ type = sk_run_filter(skb, ptp_filter);
+
+ if (PTP_CLASS_V1_IPV4 == type) {
+
+ id = (u16 *)(data + 42 + 30);
+ hi = (u16 *)(data + 42 + 22);
+ lo = data + 42 + 24;
[...]
PTP_FILTER does not verify that the packet length is sufficient to hold
a complete PTP header, nor does it require that the IPv4 header length
is 5 (i.e. 20 bytes). So you have to check those here rather than using
magic numbers.
I think you also need to use be16_to_cpup() to read 'id' and 'hi', since
the host byte order may vary.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V14 4/4] ptp: Added a clock driver for the National Semiconductor PHYTER.
On Mon, 2011-04-18 at 08:30 +0200, Richard Cochran wrote:
This patch adds support for the PTP clock found on the DP83640.
The basic clock operations and one external time stamp have
been implemented.
[...]
--- /dev/null
+++ b/drivers/net/phy/dp83640.c
[...]
+static int match(struct sk_buff *skb, unsigned int type, struct rxts *rxts)
+{
+ u16 *seqid;
Should be __be16 *, and similarly for the casts.
+ u8 *msgtype, *data = skb_mac_header(skb);
+
+ /* check sequenceID, messageType, 12 bit hash of offset 20-29 */
+ /* We assume that the IPv4 header has no options. */
Does the hardware definitely not timestamp received packets with IP
options?
+ switch (type) {
+ case PTP_CLASS_V1_IPV4:
+ msgtype = data + 42 + 32;
+ seqid = (u16 *)(data + 42 + 30);
+ break;
+ case PTP_CLASS_V1_IPV6:
+ msgtype = data + 62 + 32;
+ seqid = (u16 *)(data + 62 + 30);
+ break;
+ case PTP_CLASS_V2_IPV4:
+ msgtype = data + 42 + 0;
+ seqid = (u16 *)(data + 42 + 30);
+ break;
+ case PTP_CLASS_V2_IPV6:
+ msgtype = data + 62 + 0;
+ seqid = (u16 *)(data + 62 + 30);
+ break;
+ case PTP_CLASS_V2_L2:
+ msgtype = data + 14 + 0;
+ seqid = (u16 *)(data + 14 + 30);
+ break;
+ case PTP_CLASS_V2_VLAN:
+ msgtype = data + 18 + 0;
+ seqid = (u16 *)(data + 18 + 30);
+ break;
[...]
Would be better without the magic numbers.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH net-next-2.6 1/2] gianfar: Clean up implementation of RX network flow classification
This code was cribbed from niu, so gfar_set_hash_opts() begins by
converting the ethtool flow class code into a class code for Sun
Neptune hardware, then does the same thing again for the hardware it's
really dealing with. It may also return -1 (-EPERM) for some
unhandled ethtool flow class codes.
Remove the useless code and definitions, and fix the error code.
Signed-off-by: Ben Hutchings bhutchi...@solarflare.com
---
This isn't even compile-tested, since it can only be built for some
PowerPC SoCs. Could someone on ppc-dev check that this won't break the
driver?
Ben.
drivers/net/gianfar.h | 17 -
drivers/net/gianfar_ethtool.c | 52 +
2 files changed, 1 insertions(+), 68 deletions(-)
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index ec5d595..57ee3b0 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -382,23 +382,6 @@ extern const char gfar_driver_version[];
#define BD_LFLAG(flags) ((flags) 16)
#define BD_LENGTH_MASK 0x
-#define CLASS_CODE_UNRECOG 0x00
-#define CLASS_CODE_DUMMY1 0x01
-#define CLASS_CODE_ETHERTYPE1 0x02
-#define CLASS_CODE_ETHERTYPE2 0x03
-#define CLASS_CODE_USER_PROG1 0x04
-#define CLASS_CODE_USER_PROG2 0x05
-#define CLASS_CODE_USER_PROG3 0x06
-#define CLASS_CODE_USER_PROG4 0x07
-#define CLASS_CODE_TCP_IPV40x08
-#define CLASS_CODE_UDP_IPV40x09
-#define CLASS_CODE_AH_ESP_IPV4 0x0a
-#define CLASS_CODE_SCTP_IPV4 0x0b
-#define CLASS_CODE_TCP_IPV60x0c
-#define CLASS_CODE_UDP_IPV60x0d
-#define CLASS_CODE_AH_ESP_IPV6 0x0e
-#define CLASS_CODE_SCTP_IPV6 0x0f
-
#define FPR_FILER_MASK 0x
#define MAX_FILER_IDX 0xFF
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 3bc8e27..0840590 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -645,42 +645,6 @@ static int gfar_set_wol(struct net_device *dev, struct
ethtool_wolinfo *wol)
}
#endif
-static int gfar_ethflow_to_class(int flow_type, u64 *class)
-{
- switch (flow_type) {
- case TCP_V4_FLOW:
- *class = CLASS_CODE_TCP_IPV4;
- break;
- case UDP_V4_FLOW:
- *class = CLASS_CODE_UDP_IPV4;
- break;
- case AH_V4_FLOW:
- case ESP_V4_FLOW:
- *class = CLASS_CODE_AH_ESP_IPV4;
- break;
- case SCTP_V4_FLOW:
- *class = CLASS_CODE_SCTP_IPV4;
- break;
- case TCP_V6_FLOW:
- *class = CLASS_CODE_TCP_IPV6;
- break;
- case UDP_V6_FLOW:
- *class = CLASS_CODE_UDP_IPV6;
- break;
- case AH_V6_FLOW:
- case ESP_V6_FLOW:
- *class = CLASS_CODE_AH_ESP_IPV6;
- break;
- case SCTP_V6_FLOW:
- *class = CLASS_CODE_SCTP_IPV6;
- break;
- default:
- return 0;
- }
-
- return 1;
-}
-
static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow)
{
u32 fcr = 0x0, fpr = FPR_FILER_MASK;
@@ -778,11 +742,6 @@ static int gfar_ethflow_to_filer_table(struct gfar_private
*priv, u64 ethflow, u
case UDP_V6_FLOW:
cmp_rqfpr = RQFPR_IPV6 |RQFPR_UDP;
break;
- case IPV4_FLOW:
- cmp_rqfpr = RQFPR_IPV4;
- case IPV6_FLOW:
- cmp_rqfpr = RQFPR_IPV6;
- break;
default:
printk(KERN_ERR Right now this class is not supported\n);
return 0;
@@ -848,18 +807,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private
*priv, u64 ethflow, u
static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc
*cmd)
{
- u64 class;
-
- if (!gfar_ethflow_to_class(cmd-flow_type, class))
- return -EINVAL;
-
- if (class CLASS_CODE_USER_PROG1 ||
- class CLASS_CODE_SCTP_IPV6)
- return -EINVAL;
-
/* write the filer rules here */
if (!gfar_ethflow_to_filer_table(priv, cmd-data, cmd-flow_type))
- return -1;
+ return -EINVAL;
return 0;
}
--
1.7.4
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/boot/Makefile: Use $(src) and $(obj) as per makefiles.txt
$(src) and $(obj) are normally the same, but are supposed to be used for paths under $(srctree) and $(objtree) respectively. Also use $(dtstree) and $(wrapper) as appropriate. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- This is totally untested, so please review carefully! Ben. arch/powerpc/boot/Makefile |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 8917816..bd7abba 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -33,7 +33,7 @@ ifeq ($(call cc-option-yn, -fstack-protector),y) BOOTCFLAGS += -fno-stack-protector endif -BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj) +BOOTCFLAGS += -I$(obj) -I$(srctree)/$(src) DTC_FLAGS ?= -p 1024 @@ -399,10 +399,10 @@ $(extra-installed): $(DESTDIR)$(WRAPPER_OBJDIR)/% : $(obj)/% | $(DESTDIR)$(WRAP $(hostprogs-installed) : $(DESTDIR)$(WRAPPER_BINDIR)/% : $(obj)/% | $(DESTDIR)$(WRAPPER_BINDIR) $(call cmd,install_exe) -$(dts-installed) : $(DESTDIR)$(WRAPPER_DTSDIR)/% : $(srctree)/$(obj)/dts/% | $(DESTDIR)$(WRAPPER_DTSDIR) +$(dts-installed) : $(DESTDIR)$(WRAPPER_DTSDIR)/% : $(dtstree)/% | $(DESTDIR)$(WRAPPER_DTSDIR) $(call cmd,install_dts) -$(wrapper-installed): $(DESTDIR)$(WRAPPER_BINDIR) $(srctree)/$(obj)/wrapper | $(DESTDIR)$(WRAPPER_BINDIR) +$(wrapper-installed): $(DESTDIR)$(WRAPPER_BINDIR) $(wrapper) | $(DESTDIR)$(WRAPPER_BINDIR) $(call cmd,install_wrapper) $(obj)/bootwrapper_install: $(all-installed) -- 1.7.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/boot/dts: Install dts from the right directory
The dts-installed variable is initialised using a wildcard path that will be expanded relative to the build directory. Use the existing variable dtstree to generate an absolute wildcard path that will work when building in a separate directory. Reported-by: Gerhard Pircher gerhard_pirc...@gmx.net Signed-off-by: Ben Hutchings b...@decadent.org.uk Tested-by: Gerhard Pircher gerhard_pirc...@gmx.net [against 2.6.32] --- arch/powerpc/boot/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 96deec6..8917816 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -368,7 +368,7 @@ INSTALL := install extra-installed:= $(patsubst $(obj)/%, $(DESTDIR)$(WRAPPER_OBJDIR)/%, $(extra-y)) hostprogs-installed:= $(patsubst %, $(DESTDIR)$(WRAPPER_BINDIR)/%, $(hostprogs-y)) wrapper-installed := $(DESTDIR)$(WRAPPER_BINDIR)/wrapper -dts-installed := $(patsubst $(obj)/dts/%, $(DESTDIR)$(WRAPPER_DTSDIR)/%, $(wildcard $(obj)/dts/*.dts)) +dts-installed := $(patsubst $(dtstree)/%, $(DESTDIR)$(WRAPPER_DTSDIR)/%, $(wildcard $(dtstree)/*.dts)) all-installed := $(extra-installed) $(hostprogs-installed) $(wrapper-installed) $(dts-installed) -- 1.7.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v1 PATCH] ucc_geth: fix ethtool set ring param bug
On Thu, 2010-09-02 at 08:50 +0800, Liang Li wrote:
On Wed, Sep 01, 2010 at 02:42:30PM +0100, Ben Hutchings wrote:
On Wed, 2010-09-01 at 09:43 +0800, Liang Li wrote:
It's common sense that when we should do change to driver ring
desc/buffer etc only after 'stop/shutdown' the device. When we
do change while devices/driver is running, kernel oops occur:
[...]
- ug_info-bdRingLenRx[queue] = ring-rx_pending;
- ug_info-bdRingLenTx[queue] = ring-tx_pending;
-
if (netif_running(netdev)) {
- /* FIXME: restart automatically */
- printk(KERN_INFO
- Please re-open the interface.\n);
+ u16 rx_t;
+ u16 tx_t;
+ printk(KERN_INFO Stopping interface %s.\n, netdev-name);
+ ucc_geth_close(netdev);
+
+ rx_t = ug_info-bdRingLenRx[queue];
+ tx_t = ug_info-bdRingLenTx[queue];
+
+ ug_info-bdRingLenRx[queue] = ring-rx_pending;
+ ug_info-bdRingLenTx[queue] = ring-tx_pending;
+
+ printk(KERN_INFO Reactivating interface %s.\n, netdev-name);
+ ret = ucc_geth_open(netdev);
+ if (ret) {
+ printk(KERN_WARNING uec_set_ringparam: set ring param
for running
+ interface %s failed. Please try to
make the interface
+ down, then try again.\n,
netdev-name);
+ ug_info-bdRingLenRx[queue] = rx_t;
+ ug_info-bdRingLenTx[queue] = tx_t;
+ }
[...]
Bringing the interface down will call ucc_geth_close(), which will try
to free resources that have not been allocated!
Sorry, I did not understand you on this point. There is no
ucc_geth_close when 'open fail'. What you mean here exactly?
[...]
Read your own warning.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v1 PATCH] ucc_geth: fix ethtool set ring param bug
On Thu, 2010-09-02 at 23:48 +0800, Liang Li wrote:
On Thu, Sep 02, 2010 at 12:11:47PM +0100, Ben Hutchings wrote:
On Thu, 2010-09-02 at 08:50 +0800, Liang Li wrote:
On Wed, Sep 01, 2010 at 02:42:30PM +0100, Ben Hutchings wrote:
On Wed, 2010-09-01 at 09:43 +0800, Liang Li wrote:
It's common sense that when we should do change to driver ring
desc/buffer etc only after 'stop/shutdown' the device. When we
do change while devices/driver is running, kernel oops occur:
[...]
- ug_info-bdRingLenRx[queue] = ring-rx_pending;
- ug_info-bdRingLenTx[queue] = ring-tx_pending;
-
if (netif_running(netdev)) {
- /* FIXME: restart automatically */
- printk(KERN_INFO
- Please re-open the interface.\n);
+ u16 rx_t;
+ u16 tx_t;
+ printk(KERN_INFO Stopping interface %s.\n,
netdev-name);
+ ucc_geth_close(netdev);
+
+ rx_t = ug_info-bdRingLenRx[queue];
+ tx_t = ug_info-bdRingLenTx[queue];
+
+ ug_info-bdRingLenRx[queue] = ring-rx_pending;
+ ug_info-bdRingLenTx[queue] = ring-tx_pending;
+
+ printk(KERN_INFO Reactivating interface %s.\n,
netdev-name);
+ ret = ucc_geth_open(netdev);
+ if (ret) {
+ printk(KERN_WARNING uec_set_ringparam: set
ring param for running
+ interface %s failed. Please
try to make the interface
+ down, then try again.\n,
netdev-name);
+ ug_info-bdRingLenRx[queue] = rx_t;
+ ug_info-bdRingLenTx[queue] = tx_t;
+ }
[...]
Bringing the interface down will call ucc_geth_close(), which will try
to free resources that have not been allocated!
Sorry, I did not understand you on this point. There is no
ucc_geth_close when 'open fail'. What you mean here exactly?
[...]
Read your own warning.
So the warning is mis-leading... We may not need it... Still, let's talk
about the rare case that 'fail of open', may you please show me what is
the right thing to do 'clean up work' when ever the open fail. Maybe
dev_close(net_dev)?
I give up.
Just s/ucc_geth_open/dev_open/ and s/ucc_geth_close/dev_close/.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2 PATCH] ucc_geth: fix ethtool set ring param bug
On Fri, 2010-09-03 at 00:02 +0800, Liang Li wrote:
It's common sense that when we should do change to driver ring
desc/buffer etc only after 'stop/shutdown' the device. When we
do change while devices/driver is running, kernel oops occur:
[...]
+ printk(KERN_INFO Reactivating interface %s.\n, netdev-name);
+ ret = ucc_geth_open(netdev);
+ if (ret) {
+ printk(KERN_WARNING uec_set_ringparam: set ring param
for running
+ interface %s failed. Please try
again.\n, netdev-name);
+ dev_close(netdev);
[...]
If ucc_geth_open() failed you MUST NOT call ucc_geth_close(), but that
is what dev_close() is going to do. But the device is still flagged as
running so 'ifconfig down' is going to call dev_close() as well. There
is no way out.
This is why I said you must call dev_close() and then dev_open()
instead. Then if dev_open() fails, just print the error, e.g.:
dev_close(netdev);
ret = dev_open(netdev);
if (ret)
netdev_err(netdev,
uec_set_ringparam: failed to restart
interface with new ring parameters\n);
(And I think this really is a serious error, hence the 'err' rather than
'warning' severity.)
(By the way, I noticed there are other places where ucc_geth_close() and
ucc_geth_open() are called, without error checking. These are also
bugs, but that doesn't justify adding new bugs.)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v1 PATCH] ucc_geth: fix ethtool set ring param bug
On Wed, 2010-09-01 at 09:43 +0800, Liang Li wrote:
It's common sense that when we should do change to driver ring
desc/buffer etc only after 'stop/shutdown' the device. When we
do change while devices/driver is running, kernel oops occur:
[...]
- ug_info-bdRingLenRx[queue] = ring-rx_pending;
- ug_info-bdRingLenTx[queue] = ring-tx_pending;
-
if (netif_running(netdev)) {
- /* FIXME: restart automatically */
- printk(KERN_INFO
- Please re-open the interface.\n);
+ u16 rx_t;
+ u16 tx_t;
+ printk(KERN_INFO Stopping interface %s.\n, netdev-name);
+ ucc_geth_close(netdev);
+
+ rx_t = ug_info-bdRingLenRx[queue];
+ tx_t = ug_info-bdRingLenTx[queue];
+
+ ug_info-bdRingLenRx[queue] = ring-rx_pending;
+ ug_info-bdRingLenTx[queue] = ring-tx_pending;
+
+ printk(KERN_INFO Reactivating interface %s.\n, netdev-name);
+ ret = ucc_geth_open(netdev);
+ if (ret) {
+ printk(KERN_WARNING uec_set_ringparam: set ring param
for running
+ interface %s failed. Please try to
make the interface
+ down, then try again.\n,
netdev-name);
+ ug_info-bdRingLenRx[queue] = rx_t;
+ ug_info-bdRingLenTx[queue] = tx_t;
+ }
[...]
Bringing the interface down will call ucc_geth_close(), which will try
to free resources that have not been allocated!
If you cannot roll back a failed change then at least use dev_close()
and dev_open() rather than calling ucc_geth_{close,open}() directly, so
that the interface state is updated correctly. Or just refuse to make
the change if the interface is up.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ucc_geth: fix ethtool set ring param bug
On Mon, 2010-08-30 at 22:47 +0800, Liang Li wrote:
It's common sense that when we should do change to driver ring
desc/buffer etc only after 'stop/shutdown' the device. When we
do change while devices/driver is running, kernel oops occur:
[...]
diff --git a/drivers/net/ucc_geth_ethtool.c b/drivers/net/ucc_geth_ethtool.c
index 6f92e48..1b37aaa 100644
--- a/drivers/net/ucc_geth_ethtool.c
+++ b/drivers/net/ucc_geth_ethtool.c
@@ -255,13 +255,18 @@ uec_set_ringparam(struct net_device *netdev,
return -EINVAL;
}
- ug_info-bdRingLenRx[queue] = ring-rx_pending;
- ug_info-bdRingLenTx[queue] = ring-tx_pending;
-
if (netif_running(netdev)) {
- /* FIXME: restart automatically */
- printk(KERN_INFO
- Please re-open the interface.\n);
+ printk(KERN_INFO Stopping interface %s.\n, netdev-name);
+ ucc_geth_close(netdev);
+
+ ug_info-bdRingLenRx[queue] = ring-rx_pending;
+ ug_info-bdRingLenTx[queue] = ring-tx_pending;
+
+ printk(KERN_INFO Reactivating interface %s.\n, netdev-name);
+ ucc_geth_open(netdev);
What if ucc_geth_open() fails?
Ben.
+ } else {
+ ug_info-bdRingLenRx[queue] = ring-rx_pending;
+ ug_info-bdRingLenTx[queue] = ring-tx_pending;
}
return ret;
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ucc_geth: fix ethtool set ring param bug
On Tue, 2010-08-31 at 23:16 +0800, Liang Li wrote:
On Tue, Aug 31, 2010 at 03:41:22PM +0100, Ben Hutchings wrote:
On Mon, 2010-08-30 at 22:47 +0800, Liang Li wrote:
It's common sense that when we should do change to driver ring
desc/buffer etc only after 'stop/shutdown' the device. When we
do change while devices/driver is running, kernel oops occur:
[...]
diff --git a/drivers/net/ucc_geth_ethtool.c
b/drivers/net/ucc_geth_ethtool.c
index 6f92e48..1b37aaa 100644
--- a/drivers/net/ucc_geth_ethtool.c
+++ b/drivers/net/ucc_geth_ethtool.c
@@ -255,13 +255,18 @@ uec_set_ringparam(struct net_device *netdev,
return -EINVAL;
}
- ug_info-bdRingLenRx[queue] = ring-rx_pending;
- ug_info-bdRingLenTx[queue] = ring-tx_pending;
-
if (netif_running(netdev)) {
- /* FIXME: restart automatically */
- printk(KERN_INFO
- Please re-open the interface.\n);
+ printk(KERN_INFO Stopping interface %s.\n, netdev-name);
+ ucc_geth_close(netdev);
+
+ ug_info-bdRingLenRx[queue] = ring-rx_pending;
+ ug_info-bdRingLenTx[queue] = ring-tx_pending;
+
+ printk(KERN_INFO Reactivating interface %s.\n, netdev-name);
+ ucc_geth_open(netdev);
What if ucc_geth_open() fails?
I did some runtime tests but did not witness the ucc_geth_open fail.
Assume it may fail for some reason, then I tend to think give out
warnings for request user to open/enable it mannually? Or we may need
to keep the 'FIXME' line?
The easy way out is to allow changing the ring size only while the
interface is down. The hard way is to make the change in such a way
that you can roll back in case of failure.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 PCI: MSI: Remove
unsafe and unnecessary hardware access changed read_msi_msg_desc() to
return the last MSI message written instead of reading it from the
device, since it may be called while the device is in a reduced
power state.
However, the pSeries platform code really does need to read messages
from the device, since they are initially written by firmware.
Therefore:
- Restore the previous behaviour of read_msi_msg_desc()
- Add new functions get_cached_msi_msg{,_desc}() which return the
last MSI message written
- Use the new functions where appropriate
Signed-off-by: Ben Hutchings bhutchi...@solarflare.com
---
Compile-tested only.
Ben.
arch/ia64/kernel/msi_ia64.c|2 +-
arch/ia64/sn/kernel/msi_sn.c |2 +-
arch/x86/kernel/apic/io_apic.c |2 +-
drivers/pci/msi.c | 47 +++
include/linux/msi.h|2 +
5 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
index 6c89228..4a746ea 100644
--- a/arch/ia64/kernel/msi_ia64.c
+++ b/arch/ia64/kernel/msi_ia64.c
@@ -25,7 +25,7 @@ static int ia64_set_msi_irq_affinity(unsigned int irq,
if (irq_prepare_move(irq, cpu))
return -1;
- read_msi_msg(irq, msg);
+ get_cached_msi_msg(irq, msg);
addr = msg.address_lo;
addr = MSI_ADDR_DEST_ID_MASK;
diff --git a/arch/ia64/sn/kernel/msi_sn.c b/arch/ia64/sn/kernel/msi_sn.c
index ebfdd6a..0c72dd4 100644
--- a/arch/ia64/sn/kernel/msi_sn.c
+++ b/arch/ia64/sn/kernel/msi_sn.c
@@ -175,7 +175,7 @@ static int sn_set_msi_irq_affinity(unsigned int irq,
* Release XIO resources for the old MSI PCI address
*/
- read_msi_msg(irq, msg);
+ get_cached_msi_msg(irq, msg);
sn_pdev = (struct pcidev_info *)sn_irq_info-irq_pciioinfo;
pdev = sn_pdev-pdi_linux_pcidev;
provider = SN_PCIDEV_BUSPROVIDER(pdev);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e41ed24..4dc0084 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3397,7 +3397,7 @@ static int set_msi_irq_affinity(unsigned int irq, const
struct cpumask *mask)
cfg = desc-chip_data;
- read_msi_msg_desc(desc, msg);
+ get_cached_msi_msg_desc(desc, msg);
msg.data = ~MSI_DATA_VECTOR_MASK;
msg.data |= MSI_DATA_VECTOR(cfg-vector);
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 4c14f31..69b7be3 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -197,9 +197,46 @@ void read_msi_msg_desc(struct irq_desc *desc, struct
msi_msg *msg)
{
struct msi_desc *entry = get_irq_desc_msi(desc);
- /* We do not touch the hardware (which may not even be
-* accessible at the moment) but return the last message
-* written. Assert that this is valid, assuming that
+ BUG_ON(entry-dev-current_state != PCI_D0);
+
+ if (entry-msi_attrib.is_msix) {
+ void __iomem *base = entry-mask_base +
+ entry-msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;
+
+ msg-address_lo = readl(base + PCI_MSIX_ENTRY_LOWER_ADDR);
+ msg-address_hi = readl(base + PCI_MSIX_ENTRY_UPPER_ADDR);
+ msg-data = readl(base + PCI_MSIX_ENTRY_DATA);
+ } else {
+ struct pci_dev *dev = entry-dev;
+ int pos = entry-msi_attrib.pos;
+ u16 data;
+
+ pci_read_config_dword(dev, msi_lower_address_reg(pos),
+ msg-address_lo);
+ if (entry-msi_attrib.is_64) {
+ pci_read_config_dword(dev, msi_upper_address_reg(pos),
+ msg-address_hi);
+ pci_read_config_word(dev, msi_data_reg(pos, 1), data);
+ } else {
+ msg-address_hi = 0;
+ pci_read_config_word(dev, msi_data_reg(pos, 0), data);
+ }
+ msg-data = data;
+ }
+}
+
+void read_msi_msg(unsigned int irq, struct msi_msg *msg)
+{
+ struct irq_desc *desc = irq_to_desc(irq);
+
+ read_msi_msg_desc(desc, msg);
+}
+
+void get_cached_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg)
+{
+ struct msi_desc *entry = get_irq_desc_msi(desc);
+
+ /* Assert that the cache is valid, assuming that
* valid messages are not all-zeroes. */
BUG_ON(!(entry-msg.address_hi | entry-msg.address_lo |
entry-msg.data));
@@ -207,11 +244,11 @@ void read_msi_msg_desc(struct irq_desc *desc, struct
msi_msg *msg)
*msg = entry-msg;
}
-void read_msi_msg(unsigned int irq, struct msi_msg *msg)
+void get_cached_msi_msg(unsigned int irq, struct msi_msg *msg)
{
struct irq_desc *desc = irq_to_desc(irq);
- read_msi_msg_desc(desc, msg
Re: linux-next: OOPS at bot time
On Fri, 2010-07-23 at 10:22 +1000, Stephen Rothwell wrote:
Hi all,
My Power7 boot test paniced like this: (next-20100722)
%GQLogic Fibre Channel HBA Driver: 8.03.03-k0
qla2xxx 0002:01:00.2: enabling device (0144 - 0146)
qla2xxx 0002:01:00.2: Found an ISP8001, irq 35, iobase 0xd80080014000
[ cut here ]
kernel BUG at drivers/pci/msi.c:205!
[...]
Call Trace:
[c278b270] [c0048d9c] .rtas_setup_msi_irqs+0x1d8/0x254
(unreliable)
[c278b360] [c002a9cc] .arch_setup_msi_irqs+0x34/0x4c
[c278b3e0] [c02fd3fc] .pci_enable_msix+0x49c/0x4ac
[...]
That line number is this:
BUG_ON(!(entry-msg.address_hi | entry-msg.address_lo |
entry-msg.data));
in read_msi_msg_desc(). That BUG_ON was added by commit
2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 (PCI: MSI: Remove unsafe and
unnecessary hardware access) from the pci tree.
I wanted to assert that read_msi_msg_desc() is only used to update
MSI/MSI-X descriptors that have already been generated by Linux. It
looks like you found an exception.
We could make read_msi_msg() fall back to reading from the hardware, but
I think that what the pSeries code is trying to do - save an MSI message
generated by firmware - is different from what the other callers want.
Instead we could add:
void save_msi_msg(unsigned int irq)
{
struct irq_desc *desc = irq_to_desc(irq);
struct msi_desc *entry = get_irq_desc_msi(desc);
struct msi_msg *msg = entry-msg;
/* ...followed by the old implementation of read_msi_msg_desc() */
}
Possibly conditional on something like CONFIG_ARCH_NEEDS_SAVE_MSI_MSG.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] panic: Allow warnings to set different taint flags
WARN() is used in some places to report firmware or hardware bugs that
are then worked-around. These bugs do not affect the stability of the
kernel and should not set the flag for TAINT_WARN. To allow for this,
add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint number
as argument.
Architectures that implement warnings using trap instructions instead
of calls to warn_slowpath_*() now implement __WARN_TAINT(taint)
instead of __WARN().
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
Changes since the previous version:
- Added note to Documentation/oops-tracing.txt
- Changed the commit message to distinguish taint numbers from taint
flags
- Removed 'must' from last sentence of commit message; this patch
converts all mainline architectures
Ben.
Documentation/oops-tracing.txt |1 +
arch/parisc/include/asm/bug.h |8
arch/powerpc/include/asm/bug.h |6 +++---
arch/s390/include/asm/bug.h|8
arch/sh/include/asm/bug.h |4 ++--
include/asm-generic/bug.h | 34 --
kernel/panic.c | 24
lib/bug.c |2 +-
8 files changed, 67 insertions(+), 20 deletions(-)
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
index c10c022..069fab3 100644
--- a/Documentation/oops-tracing.txt
+++ b/Documentation/oops-tracing.txt
@@ -256,6 +256,7 @@ characters, each representing a particular tainted value.
9: 'A' if the ACPI table has been overridden.
10: 'W' if a warning has previously been issued by the kernel.
+ (Though some warnings may set more specific taint flags.)
11: 'C' if a staging driver has been loaded.
diff --git a/arch/parisc/include/asm/bug.h b/arch/parisc/include/asm/bug.h
index 75e46c5..72cfdb0 100644
--- a/arch/parisc/include/asm/bug.h
+++ b/arch/parisc/include/asm/bug.h
@@ -44,7 +44,7 @@
#endif
#ifdef CONFIG_DEBUG_BUGVERBOSE
-#define __WARN() \
+#define __WARN_TAINT(taint)\
do {\
asm volatile(\n \
1:\t PARISC_BUG_BREAK_ASM \n \
@@ -54,11 +54,11 @@
\t.org 2b+%c3\n \
\t.popsection\
: : i (__FILE__), i (__LINE__),\
-i (BUGFLAG_WARNING), \
+i (BUGFLAG_TAINT(taint)),\
i (sizeof(struct bug_entry)) ); \
} while(0)
#else
-#define __WARN() \
+#define __WARN_TAINT(taint)\
do {\
asm volatile(\n \
1:\t PARISC_BUG_BREAK_ASM \n \
@@ -67,7 +67,7 @@
\t.short %c0\n \
\t.org 2b+%c1\n \
\t.popsection\
-: : i (BUGFLAG_WARNING), \
+: : i (BUGFLAG_TAINT(taint)),\
i (sizeof(struct bug_entry)) ); \
} while(0)
#endif
diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 2c15212..065c590 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -85,12 +85,12 @@
} \
} while (0)
-#define __WARN() do { \
+#define __WARN_TAINT(taint) do { \
__asm__ __volatile__( \
1: twi 31,0,0\n \
_EMIT_BUG_ENTRY \
: : i (__FILE__), i (__LINE__), \
- i (BUGFLAG_WARNING),\
+ i (BUGFLAG_TAINT(taint)), \
i (sizeof(struct bug_entry))); \
} while (0)
@@ -104,7 +104,7 @@
1: PPC_TLNEI %4,0\n \
_EMIT_BUG_ENTRY \
: : i (__FILE__), i (__LINE__), \
- i (BUGFLAG_WARNING),\
+ i (BUGFLAG_TAINT(TAINT_WARN)), \
i (sizeof(struct bug_entry)), \
r (__ret_warn_on
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
On Mon, 2010-03-22 at 22:47 -0400, Andrew Morton wrote: On Sat, 20 Mar 2010 23:05:40 + Ben Hutchings b...@decadent.org.uk wrote: WARN() is used in some places to report firmware or hardware bugs that are then worked-around. These bugs do not affect the stability of the kernel and should not set the usual TAINT_WARN flag. To allow for this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint flag as argument. Architectures that implement warnings using trap instructions instead of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) instead of __WARN(). When you say they must now implement, I assume that you mean that they _do_ now implement, and that no additional architecture work is needed. Right, I believe I fixed-up all the current architectures. There might be more architectures out there, unmerged as yet. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
On Tue, 2010-03-23 at 16:45 +0900, Paul Mundt wrote: On Sat, Mar 20, 2010 at 11:05:40PM +, Ben Hutchings wrote: WARN() is used in some places to report firmware or hardware bugs that are then worked-around. These bugs do not affect the stability of the kernel and should not set the usual TAINT_WARN flag. To allow for this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint flag as argument. Architectures that implement warnings using trap instructions instead of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) instead of __WARN(). Signed-off-by: Ben Hutchings b...@decadent.org.uk --- The architecture-specific changes here are untested and need to be reviewed by architecture maintainers. I'm a bit confused about how this is supposed to work, the TAINT_xxx values are bit positions presently from 0 to 10, while BUGFLAG_xxx are ranged from 0 up. You've set up BUGFLAG_TAINT() to that the TAINT_xxx value is shifted up 8 bits but neglected the fact that the trap type is 16-bits on most (all?) of the platforms using trap-based BUG handling. If the 'taint' in question is just the TAINT_xxx value by itself and will never be a bitmap then that's fine, but there's certainly not enough room to pass the bitmap in on top of the bugflag otherwise (I don't know if this is your intention or not though). Yes, the taint value must be a bit number not a flag. Sloppy wording on my part. Also note that some platforms (like SH) implement additional bugflags, so we at least want to keep the lower byte available for architecture private use. I noticed, that's why I started at 8 not 1. Having said that, the current patch does work for me, although I'm a bit nervous about someone thinking it's ok to pass in a taint bitmap here. We can maybe use BUILD_BUG_ON() here as the taint bit is already required to be a compile-time constant. Ben. Tested-by: Paul Mundt let...@linux-sh.org -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
On Sun, 2010-03-21 at 20:10 +0100, Andi Kleen wrote: Ben Hutchings b...@decadent.org.uk writes: WARN() is used in some places to report firmware or hardware bugs that are then worked-around. These bugs do not affect the stability of the kernel and should not set the usual TAINT_WARN flag. To allow for this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint flag as argument. Architectures that implement warnings using trap instructions instead of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) instead of __WARN(). I guess this should enforce that at least some taint flag is set? (e.g. with a BUILD_BUG_ON) I'm being a bit sloppy with the wording here. The TAINT_* macros are actually bit numbers, not flags. I could define a TAINT_MAX and add: BUILD_BUG_ON(taint 0 || taint TAINT_MAX); Not sure that that's really worth doing though. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
WARN() is used in some places to report firmware or hardware bugs that
are then worked-around. These bugs do not affect the stability of the
kernel and should not set the usual TAINT_WARN flag. To allow for
this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint
flag as argument.
Architectures that implement warnings using trap instructions instead
of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint)
instead of __WARN().
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
The architecture-specific changes here are untested and need to be
reviewed by architecture maintainers.
Ben.
arch/parisc/include/asm/bug.h |8
arch/powerpc/include/asm/bug.h |6 +++---
arch/s390/include/asm/bug.h|8
arch/sh/include/asm/bug.h |4 ++--
include/asm-generic/bug.h | 34 --
kernel/panic.c | 24
lib/bug.c |2 +-
7 files changed, 66 insertions(+), 20 deletions(-)
diff --git a/arch/parisc/include/asm/bug.h b/arch/parisc/include/asm/bug.h
index 75e46c5..72cfdb0 100644
--- a/arch/parisc/include/asm/bug.h
+++ b/arch/parisc/include/asm/bug.h
@@ -44,7 +44,7 @@
#endif
#ifdef CONFIG_DEBUG_BUGVERBOSE
-#define __WARN() \
+#define __WARN_TAINT(taint)\
do {\
asm volatile(\n \
1:\t PARISC_BUG_BREAK_ASM \n \
@@ -54,11 +54,11 @@
\t.org 2b+%c3\n \
\t.popsection\
: : i (__FILE__), i (__LINE__),\
-i (BUGFLAG_WARNING), \
+i (BUGFLAG_TAINT(taint)),\
i (sizeof(struct bug_entry)) ); \
} while(0)
#else
-#define __WARN() \
+#define __WARN_TAINT(taint)\
do {\
asm volatile(\n \
1:\t PARISC_BUG_BREAK_ASM \n \
@@ -67,7 +67,7 @@
\t.short %c0\n \
\t.org 2b+%c1\n \
\t.popsection\
-: : i (BUGFLAG_WARNING), \
+: : i (BUGFLAG_TAINT(taint)),\
i (sizeof(struct bug_entry)) ); \
} while(0)
#endif
diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 2c15212..065c590 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -85,12 +85,12 @@
} \
} while (0)
-#define __WARN() do { \
+#define __WARN_TAINT(taint) do { \
__asm__ __volatile__( \
1: twi 31,0,0\n \
_EMIT_BUG_ENTRY \
: : i (__FILE__), i (__LINE__), \
- i (BUGFLAG_WARNING),\
+ i (BUGFLAG_TAINT(taint)), \
i (sizeof(struct bug_entry))); \
} while (0)
@@ -104,7 +104,7 @@
1: PPC_TLNEI %4,0\n \
_EMIT_BUG_ENTRY \
: : i (__FILE__), i (__LINE__), \
- i (BUGFLAG_WARNING),\
+ i (BUGFLAG_TAINT(TAINT_WARN)), \
i (sizeof(struct bug_entry)), \
r (__ret_warn_on)); \
} \
diff --git a/arch/s390/include/asm/bug.h b/arch/s390/include/asm/bug.h
index 9beeb9d..bf90d1f 100644
--- a/arch/s390/include/asm/bug.h
+++ b/arch/s390/include/asm/bug.h
@@ -46,18 +46,18 @@
unreachable(); \
} while (0)
-#define __WARN() do { \
- __EMIT_BUG(BUGFLAG_WARNING);\
+#define __WARN_TAINT(taint) do { \
+ __EMIT_BUG(BUGFLAG_TAINT(taint)); \
} while (0)
#define WARN_ON(x) ({ \
int __ret_warn_on = !!(x
