* Re: [Cbe-oss-dev] [PATCH 03/49] arch/powerpc: Use vzalloc
From: Jeremy Kerr @ 2010-11-05 13:08 UTC (permalink / raw)
To: cbe-oss-dev
Cc: Jiri Kosina, kvm, Arnd Bergmann, Marcelo Tosatti, Alexander Graf,
kvm-ppc, linux-kernel, Paul Mackerras, Avi Kivity, Joe Perches,
linuxppc-dev
In-Reply-To: <5da00d7f95b5c7a96fbfa8420f5e3a8ef33e01e6.1288925424.git.joe@perches.com>
Hi Joe,
> diff --git a/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
> b/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c index a101abf..3b894f5
> 100644
> --- a/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
> +++ b/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
> @@ -36,10 +36,9 @@ static int spu_alloc_lscsa_std(struct spu_state *csa)
> struct spu_lscsa *lscsa;
> unsigned char *p;
>
> - lscsa = vmalloc(sizeof(struct spu_lscsa));
> + lscsa = vzalloc(sizeof(struct spu_lscsa));
> if (!lscsa)
> return -ENOMEM;
> - memset(lscsa, 0, sizeof(struct spu_lscsa));
> csa->lscsa = lscsa;
>
> /* Set LS pages reserved to allow for user-space mapping. */
For the spufs bit:
Acked-By: Jeremy Kerr <jk@ozlabs.org>
Cheers,
Jeremy
^ permalink raw reply
* Problem Ethernet Initialization MPC5200 + LXT971A
From: Stefan Strobl @ 2010-11-05 16:32 UTC (permalink / raw)
To: linuxppc-dev
Hi
I'm having a Problem with the Initialization of my Ethernet PHY
(FEC_MPC5200 + LXT971A Phy). I'm using latest U-Boot and Linux 2.6.37
from Denx.
Once in Linux I can ping my own IP-Address but not any other device in
my network. The Link LED is on when connected to the network but when
pinging some other device nothing is being transmitted (Traffic LED is off).
If - before booting - I'm using any network command under U-Boot (which
is calling eth_init()), the interface works fine after that under Linux
also!
In that case the kernel prints the line:
PHY: f003000:00 - Link is Up - 100/Full
So I'm not sure whether the Linux driver does not initialize the PHY
correctly or whether I should be running a command under Linux that
makes the interface work. I've played around with ifconfig but that
didn't get me any further.
Under sysfs I can see that the MAC address is assigned correctly but:
carrier = 0 (should be 1)
duplex = half (should be full)
operstate = down
speed = 10 (should be 100)
To workaround I could make u-boot run eth_init() always but that doesn't
seem the right approach to this.
Any ideas?
Many Thanks,
Stefan.
^ permalink raw reply
* RapidIO: Flowcontrol?
From: Bastiaan Nijkamp @ 2010-11-05 17:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Bounine, Alexandre, John Traill
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
Hi,
I am currently working on a character device to benchmark the difference in
performance between an ethernet driver (rionet) and a character driver. One
issue that i am currently having is that i sometimes run out of mailbox
buffers when there is a lot of data being received. The read function then
does not get a chance to read the data because it
is continuously interrupted by the inbound ISR. When the receiver runs out
of buffers i would have expected that the transmitter would receive an
retry-packet symbol and that the data arrives as soon as some of the buffers
are cleared and reallocated (receiver controlled flow-control). Instead, the
transceiver totally hangs and i have to reset the processor to solve this. I
am using a p2p connection with two sbc85487 boards from windriver that both
feature a PowerQuicc 8548E.
Do i have to take actions when i reallocate the buffers e.g. resetting the
Mailbox Full error bit back to zero or something else?
Regards,
Bastiaan Nijkamp
[-- Attachment #2: Type: text/html, Size: 1130 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: Disable VPHN polling during a suspend operation
From: Jesse Larrew @ 2010-11-05 20:33 UTC (permalink / raw)
To: michael; +Cc: markn, pmac, tbreeds, lkessler, mjwolf, linuxppc-dev
In-Reply-To: <1288786362.989.66.camel@concordia>
On 11/03/2010 07:12 AM, Michael Ellerman wrote:
> On Thu, 2010-10-28 at 20:30 -0400, Jesse Larrew wrote:
>> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>
> Hi Jesse, a few comments ...
>
>> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
>> index afe4aaa..1747d27 100644
>> --- a/arch/powerpc/include/asm/topology.h
>> +++ b/arch/powerpc/include/asm/topology.h
>> @@ -49,7 +49,7 @@ static inline int pcibus_to_node(struct pci_bus *bus)
>> {
>> return -1;
>> }
>> -#endif
>> +#endif /* CONFIG_PCI */
>
> Random change, though not a biggy I suppose.
>
That was a change that made the header easier to read, but that change should probably be submitted separately.
>> #define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ? \
>> cpu_all_mask : \
>> @@ -93,6 +93,8 @@ extern void __init dump_numa_cpu_topology(void);
>> extern int sysfs_add_device_to_node(struct sys_device *dev, int nid);
>> extern void sysfs_remove_device_from_node(struct sys_device *dev, int nid);
>>
>> +extern int __init init_topology_update(void);
>> +extern int stop_topology_update(void);
>
> init_topology_update() is called repeatedly from post_suspend_work() so
> it seems like it should be called start_topology_update(). And it can't
> be __init because the suspend code is called after boot. You should get
> a section mismatch warning if they are enabled.
>
Agreed. My implementation was based on a similar feature for System Z in arch/s390/kernel/topology.c, and I had simply carried over some of their naming conventions. start_topology_update() is a better name.
>> #else
>>
>> static inline void dump_numa_cpu_topology(void) {}
>> @@ -107,6 +109,8 @@ static inline void sysfs_remove_device_from_node(struct sys_device *dev,
>> {
>> }
>>
>> +static int __init init_topology_update(void) {}
>> +static int stop_topology_update(void) {}
>
> That doesn't look like it compiles to me, you want static inline, and
> they both return int.
>
Good catch! I hadn't tried to compile this with CONFIG_NUMA turned off.
>> #endif /* CONFIG_NUMA */
>>
>> #include <asm-generic/topology.h>
>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
>> index 8fe8bc6..317ff2f 100644
>> --- a/arch/powerpc/kernel/rtas.c
>> +++ b/arch/powerpc/kernel/rtas.c
>> @@ -41,6 +41,7 @@
>> #include <asm/atomic.h>
>> #include <asm/time.h>
>> #include <asm/mmu.h>
>> +#include <asm/topology.h>
>>
>> struct rtas_t rtas = {
>> .lock = __ARCH_SPIN_LOCK_UNLOCKED
>> @@ -706,6 +707,18 @@ void rtas_os_term(char *str)
>>
>> static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
>> #ifdef CONFIG_PPC_PSERIES
>> +static void pre_suspend_work(void)
>> +{
>> + stop_topology_update();
>> + return;
>> +}
>> +
>> +static void post_suspend_work(void)
>> +{
>> + init_topology_update();
>> + return;
>> +}
>
> I'm not sure if it's worth splitting these out into "generic"
> callbacks ..
>
I talked with Nathan Fontenot about this a couple weeks ago, and I think the plan going forward is to implement a notifier call chain that executes before/after a suspend operation to handle reinitializations like this. In the mean time, I'll just remove the pre_suspend_work() and post_suspend_work() functions in my next revision.
>> static int __rtas_suspend_last_cpu(struct rtas_suspend_me_data *data, int wake_when_done)
>> {
>> u16 slb_size = mmu_slb_size;
>> @@ -713,6 +726,7 @@ static int __rtas_suspend_last_cpu(struct rtas_suspend_me_data *data, int wake_w
>> int cpu;
>>
>> slb_set_size(SLB_MIN_SIZE);
>> + pre_suspend_work();
>> printk(KERN_DEBUG "calling ibm,suspend-me on cpu %i\n", smp_processor_id());
>>
>> while (rc == H_MULTI_THREADS_ACTIVE && !atomic_read(&data->done) &&
>
> And isn't there an error case here where you're not re-enabling the
> polling? See eg. the slb_set_size() call.
>
I'm not sure that I understand this point. I looked it over, and it looks to me that all possible code paths touch pre_suspend_work() and post_suspend_work() exactly once (even the paths that call slb_set_size()). Which path appears to be unhandled?
>> @@ -728,6 +742,7 @@ static int __rtas_suspend_last_cpu(struct rtas_suspend_me_data *data, int wake_w
>> rc = atomic_read(&data->error);
>>
>> atomic_set(&data->error, rc);
>> + post_suspend_work();
>>
>> if (wake_when_done) {
>> atomic_set(&data->done, 1);
>
> cheers
>
>
--
Jesse Larrew
Software Engineer, Linux on Power Kernel Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlarrew@linux.vnet.ibm.com
^ permalink raw reply
* [Resend][PATCH] Drivers: ps3: Makefile: replace the use of <module>-objs with <module>-y
From: Tracey Dent @ 2010-11-06 18:55 UTC (permalink / raw)
To: geoff; +Cc: cbe-oss-dev, Tracey Dent, linuxppc-dev, linux-kernel
Changed <module>-objs to <module>-y in Makefile.
Signed-off-by: Tracey Dent <tdent48227@gmail.com>
---
drivers/ps3/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ps3/Makefile b/drivers/ps3/Makefile
index ccea15c..50cb1e1 100644
--- a/drivers/ps3/Makefile
+++ b/drivers/ps3/Makefile
@@ -1,6 +1,6 @@
obj-$(CONFIG_PS3_VUART) += ps3-vuart.o
obj-$(CONFIG_PS3_PS3AV) += ps3av_mod.o
-ps3av_mod-objs += ps3av.o ps3av_cmd.o
+ps3av_mod-y := ps3av.o ps3av_cmd.o
obj-$(CONFIG_PPC_PS3) += sys-manager-core.o
obj-$(CONFIG_PS3_SYS_MANAGER) += ps3-sys-manager.o
obj-$(CONFIG_PS3_STORAGE) += ps3stor_lib.o
--
1.7.3.2.146.gca209
^ permalink raw reply related
* [PATCH] powerpc: Add jump label support
From: Michael Ellerman @ 2010-11-08 4:12 UTC (permalink / raw)
To: linuxppc-dev
Cc: jbaron, linux-kernel, rostedt, David S. Miller, Anton Blanchard,
Kumar Gala
This patch adds support for the new "jump label" feature.
Built for 64 & 32 bit, tested on 64 bit. Survives a kernel build under
perf with all tracepoints enabled, and manual inspection of the patched
code looks right. But still, lightly tested, YMMV.
Unlike x86 and sparc we just merrily patch the code with no locks etc,
as far as I know this is safe, but I'm not really sure what the x86/sparc
code is protecting against so maybe it's not.
I also don't see any reason for us to implement the poke_early() routine,
even though sparc does.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/jump_label.h | 46 +++++++++++++++++++++++++++++++++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/jump_label.c | 23 ++++++++++++++++
4 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b644719..301c5b7 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -136,6 +136,7 @@ config PPC
select HAVE_PERF_EVENTS
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
+ select HAVE_ARCH_JUMP_LABEL
config EARLY_PRINTK
bool
diff --git a/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
new file mode 100644
index 0000000..feffb86
--- /dev/null
+++ b/arch/powerpc/include/asm/jump_label.h
@@ -0,0 +1,46 @@
+#ifndef _ASM_POWERPC_JUMP_LABEL_H
+#define _ASM_POWERPC_JUMP_LABEL_H
+
+/*
+ * Copyright 2010 Michael Ellerman, IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifdef __KERNEL__
+
+#include <linux/types.h>
+#include <asm/feature-fixups.h>
+
+#define JUMP_ENTRY_TYPE stringify_in_c(FTR_ENTRY_LONG)
+
+#define JUMP_LABEL_NOP_SIZE 4
+
+#define JUMP_LABEL(key, label) \
+do { \
+ asm goto("1:\n\t" \
+ "nop\n\t" \
+ ".pushsection __jump_table, \"a\"\n\t" \
+ JUMP_ENTRY_TYPE "1b, %l[" #label "], %c0\n\t" \
+ ".popsection \n\t" \
+ : : "i" (key) : : label); \
+} while (0)
+
+#ifdef CONFIG_PPC64
+typedef u64 jump_label_t;
+#else
+typedef u32 jump_label_t;
+#endif
+
+struct jump_entry {
+ jump_label_t code;
+ jump_label_t target;
+ jump_label_t key;
+};
+
+#endif /* __KERNEL__ */
+
+#endif /* _ASM_POWERPC_JUMP_LABEL_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 36c30f3..315e933 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_44x) += cpu_setup_44x.o
obj-$(CONFIG_PPC_FSL_BOOK3E) += cpu_setup_fsl_booke.o dbell.o
obj-$(CONFIG_PPC_BOOK3E_64) += dbell.o
+obj-$(CONFIG_JUMP_LABEL) += jump_label.o
extra-y := head_$(CONFIG_WORD_SIZE).o
extra-$(CONFIG_PPC_BOOK3E_32) := head_new_booke.o
diff --git a/arch/powerpc/kernel/jump_label.c b/arch/powerpc/kernel/jump_label.c
new file mode 100644
index 0000000..368d158
--- /dev/null
+++ b/arch/powerpc/kernel/jump_label.c
@@ -0,0 +1,23 @@
+/*
+ * Copyright 2010 Michael Ellerman, IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/jump_label.h>
+#include <asm/code-patching.h>
+
+void arch_jump_label_transform(struct jump_entry *entry,
+ enum jump_label_type type)
+{
+ u32 *addr = (u32 *)(unsigned long)entry->code;
+
+ if (type == JUMP_LABEL_ENABLE)
+ patch_branch(addr, entry->target, 0);
+ else
+ patch_instruction(addr, PPC_INST_NOP);
+}
--
1.7.1
^ permalink raw reply related
* [PATCH] powerpc: Ensure the else case of feature sections will fit
From: Michael Ellerman @ 2010-11-08 4:22 UTC (permalink / raw)
To: linuxppc-dev
When we create an alternative feature section, the else case must be the
same size or smaller than the body. This is because when we patch the
else case in we just overwrite the body, so there must be room.
Up to now we just did this by inspection, but it's quite easy to enforce
it in the assembler, so we should.
The only change is to add the ifgt block, but that effects the alignment
of the tabs and so the whole macro is modified.
Also add a test, but #if 0 it because we don't want to break the build.
Anyone who's modifying the feature macros should enable the test.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/feature-fixups.h | 27 +++++++++++++++------------
arch/powerpc/lib/feature-fixups-test.S | 19 +++++++++++++++++++
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/feature-fixups.h b/arch/powerpc/include/asm/feature-fixups.h
index 96a7d06..921a847 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -37,18 +37,21 @@ label##2: \
.align 2; \
label##3:
-#define MAKE_FTR_SECTION_ENTRY(msk, val, label, sect) \
-label##4: \
- .popsection; \
- .pushsection sect,"a"; \
- .align 3; \
-label##5: \
- FTR_ENTRY_LONG msk; \
- FTR_ENTRY_LONG val; \
- FTR_ENTRY_OFFSET label##1b-label##5b; \
- FTR_ENTRY_OFFSET label##2b-label##5b; \
- FTR_ENTRY_OFFSET label##3b-label##5b; \
- FTR_ENTRY_OFFSET label##4b-label##5b; \
+#define MAKE_FTR_SECTION_ENTRY(msk, val, label, sect) \
+label##4: \
+ .popsection; \
+ .pushsection sect,"a"; \
+ .align 3; \
+label##5: \
+ FTR_ENTRY_LONG msk; \
+ FTR_ENTRY_LONG val; \
+ FTR_ENTRY_OFFSET label##1b-label##5b; \
+ FTR_ENTRY_OFFSET label##2b-label##5b; \
+ FTR_ENTRY_OFFSET label##3b-label##5b; \
+ FTR_ENTRY_OFFSET label##4b-label##5b; \
+ .ifgt (label##4b-label##3b)-(label##2b-label##1b); \
+ .error "Feature section else case larger than body"; \
+ .endif; \
.popsection;
diff --git a/arch/powerpc/lib/feature-fixups-test.S b/arch/powerpc/lib/feature-fixups-test.S
index cb73748..f461311 100644
--- a/arch/powerpc/lib/feature-fixups-test.S
+++ b/arch/powerpc/lib/feature-fixups-test.S
@@ -172,6 +172,25 @@ globl(ftr_fixup_test6_expected)
3: or 3,3,3
+#if 0
+/* Test that if we have a larger else case the assembler spots it and
+ * reports an error. #if 0'ed so as not to break the build normally.
+ */
+ftr_fixup_test7:
+ or 1,1,1
+BEGIN_FTR_SECTION
+ or 2,2,2
+ or 2,2,2
+ or 2,2,2
+FTR_SECTION_ELSE
+ or 3,3,3
+ or 3,3,3
+ or 3,3,3
+ or 3,3,3
+ALT_FTR_SECTION_END(0, 1)
+ or 1,1,1
+#endif
+
#define MAKE_MACRO_TEST(TYPE) \
globl(ftr_fixup_test_ ##TYPE##_macros) \
or 1,1,1; \
--
1.7.1
^ permalink raw reply related
* [PATCH] powerpc: Consolidate obj-y assignments
From: Michael Ellerman @ 2010-11-08 4:24 UTC (permalink / raw)
To: linuxppc-dev
No need to have three of them.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/Makefile | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 36c30f3..259e4ce 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -29,8 +29,10 @@ endif
obj-y := cputable.o ptrace.o syscalls.o \
irq.o align.o signal_32.o pmc.o vdso.o \
init_task.o process.o systbl.o idle.o \
- signal.o sysfs.o cacheinfo.o
-obj-y += vdso32/
+ signal.o sysfs.o cacheinfo.o time.o \
+ time.o prom.o traps.o setup-common.o \
+ udbg.o misc.o io.o dma.o \
+ misc_$(CONFIG_WORD_SIZE).o vdso32/
obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o nvram_64.o firmware.o
@@ -80,9 +82,6 @@ extra-$(CONFIG_FSL_BOOKE) := head_fsl_booke.o
extra-$(CONFIG_8xx) := head_8xx.o
extra-y += vmlinux.lds
-obj-y += time.o prom.o traps.o setup-common.o \
- udbg.o misc.o io.o dma.o \
- misc_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_PPC32) += entry_32.o setup_32.o
obj-$(CONFIG_PPC64) += dma-iommu.o iommu.o
obj-$(CONFIG_KGDB) += kgdb.o
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Consolidate obj-y assignments
From: Peter Korsgaard @ 2010-11-08 7:23 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <0429b4b15a3c65fdae92f92cce656b4859dca05e.1289190214.git.michael@ellerman.id.au>
>>>>> "Michael" == Michael Ellerman <michael@ellerman.id.au> writes:
Michael> No need to have three of them.
Michael> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Michael> ---
Michael> arch/powerpc/kernel/Makefile | 9 ++++-----
Michael> 1 files changed, 4 insertions(+), 5 deletions(-)
Michael> - signal.o sysfs.o cacheinfo.o
Michael> -obj-y += vdso32/
Michael> + signal.o sysfs.o cacheinfo.o time.o \
Michael> + time.o prom.o traps.o setup-common.o \
You have time.o twice.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Problem Ethernet Initialization MPC5200 + LXT971A
From: tiejun.chen @ 2010-11-08 9:50 UTC (permalink / raw)
To: Stefan Strobl; +Cc: linuxppc-dev
In-Reply-To: <4CD431B4.7060405@gersys.de>
Stefan Strobl wrote:
> Hi
>
> I'm having a Problem with the Initialization of my Ethernet PHY
> (FEC_MPC5200 + LXT971A Phy). I'm using latest U-Boot and Linux 2.6.37
> from Denx.
>
> Once in Linux I can ping my own IP-Address but not any other device in
> my network. The Link LED is on when connected to the network but when
> pinging some other device nothing is being transmitted (Traffic LED is
> off).
>
> If - before booting - I'm using any network command under U-Boot (which
> is calling eth_init()), the interface works fine after that under Linux
> also!
> In that case the kernel prints the line:
> PHY: f003000:00 - Link is Up - 100/Full
Can you probe PHY successfully when failed?
>
> So I'm not sure whether the Linux driver does not initialize the PHY
> correctly or whether I should be running a command under Linux that
> makes the interface work. I've played around with ifconfig but that
> didn't get me any further.
>
> Under sysfs I can see that the MAC address is assigned correctly but:
> carrier = 0 (should be 1)
> duplex = half (should be full)
> operstate = down
> speed = 10 (should be 100)
>
Can you use 'ethtool' utility to access/control that? If no please check how you
access PHY by MII bus? I doubts some multiplex PIN should be configured when you
operate PHY.
> To workaround I could make u-boot run eth_init() always but that doesn't
> seem the right approach to this.
Yes. Often we shouldn't depend the bootloader do this when we use NIC. But its
worth tracking eth_init in detail to check what are missed for Linux. I guest
those should be dedicated to the hardware. For example, configuring
multiplex-pin, or reset PHY before the real operation action and so on.
Tiejun
>
> Any ideas?
>
> Many Thanks,
> Stefan.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH] ucc_geth: Fix hung tasks.
From: Joakim Tjernlund @ 2010-11-08 10:23 UTC (permalink / raw)
To: linuxppc-dev, netdev, Anton Vorontsov
We noticed a few hangs like this:
INFO: task ifconfig:572 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ifconfig D 0ff65760 0 572 369 0x00000000
Call Trace:
[c6157be0] [c6008460] 0xc6008460 (unreliable)
[c6157ca0] [c0008608] __switch_to+0x4c/0x6c
[c6157cb0] [c028fecc] schedule+0x184/0x310
[c6157ce0] [c0290e54] __mutex_lock_slowpath+0xa4/0x150
[c6157d20] [c0290c48] mutex_lock+0x44/0x48
[c6157d30] [c01aba74] phy_stop+0x20/0x70
[c6157d40] [c01aef40] ucc_geth_stop+0x30/0x98
[c6157d60] [c01b18fc] ucc_geth_close+0x9c/0xdc
[c6157d80] [c01db0cc] __dev_close+0xa0/0xd0
[c6157d90] [c01deddc] __dev_change_flags+0x8c/0x148
[c6157db0] [c01def54] dev_change_flags+0x1c/0x64
[c6157dd0] [c0237ac8] devinet_ioctl+0x678/0x784
[c6157e50] [c0239a58] inet_ioctl+0xb0/0xbc
[c6157e60] [c01cafa8] sock_ioctl+0x174/0x2a0
[c6157e80] [c009a16c] vfs_ioctl+0xcc/0xe0
[c6157ea0] [c009a998] do_vfs_ioctl+0xc4/0x79c
[c6157f10] [c009b0b0] sys_ioctl+0x40/0x74
[c6157f40] [c00117c4] ret_from_syscall+0x0/0x38
I THINK this is due to a missing cancel_work_sync in the driver
although we cannot be sure. I found this by comparing
ucc_geth with gianfar.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
drivers/net/ucc_geth.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 97f9f7d..6647ed7 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3556,6 +3556,7 @@ static int ucc_geth_close(struct net_device *dev)
napi_disable(&ugeth->napi);
+ cancel_work_sync(&ugeth->timeout_work);
ucc_geth_stop(ugeth);
free_irq(ugeth->ug_info->uf_info.irq, ugeth->ndev);
--
1.7.2.2
^ permalink raw reply related
* Re: Problem Ethernet Initialization MPC5200 + LXT971A
From: Stefan Strobl @ 2010-11-08 13:25 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <4CD7C802.8020908@windriver.com>
Hi Tiejun
tiejun.chen wrote:
> Stefan Strobl wrote:
>> To workaround I could make u-boot run eth_init() always but that doesn't
>> seem the right approach to this.
>
> Yes. Often we shouldn't depend the bootloader do this when we use NIC. But its
> worth tracking eth_init in detail to check what are missed for Linux. I guest
> those should be dedicated to the hardware. For example, configuring
> multiplex-pin, or reset PHY before the real operation action and so on.
>
You're right! It was a wrong Port Multiplex Configuration.
I think it's fair to expect the bootloader to do that bit of setup,
since it's very hardware dependent. All I did was to adapt my
CONFIG_SYS_GPS_PORT_CONFIG in u-boot.
Many thanks
Stefan.
^ permalink raw reply
* Re: [PATCH] powerpc: Add jump label support
From: Steven Rostedt @ 2010-11-08 14:18 UTC (permalink / raw)
To: Michael Ellerman
Cc: Kumar Gala, linux-kernel, David S.Miller, linuxppc-dev,
Anton Blanchard, jbaron
In-Reply-To: <45fbc3cd7f6ce404d1e25bf01695fb629d86189d.1289189560.git.michael@ellerman.id.au>
On Mon, 2010-11-08 at 15:12 +1100, Michael Ellerman wrote:
> This patch adds support for the new "jump label" feature.
Darn it! I wanted to port this!!!
;-)
>
> Built for 64 & 32 bit, tested on 64 bit. Survives a kernel build under
> perf with all tracepoints enabled, and manual inspection of the patched
> code looks right. But still, lightly tested, YMMV.
>
> Unlike x86 and sparc we just merrily patch the code with no locks etc,
> as far as I know this is safe, but I'm not really sure what the x86/sparc
> code is protecting against so maybe it's not.
Thanks, I'll give it a test on my electra as soon as I get a gcc 4.5.1
cross compiler working.
-- Steve
^ permalink raw reply
* INFO: task snmpd:398 blocked for more than 120 seconds.
From: Joakim Tjernlund @ 2010-11-08 15:05 UTC (permalink / raw)
To: linuxppc-dev
I can't make out what is causing this hang every now an then:
INFO: task snmpd:398 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
snmpd D 0fad1760 0 398 1 0x00000000
Call Trace:
[c7b5fc70] [c7a49a80] 0xc7a49a80 (unreliable)
[c7b5fd30] [c0008608] __switch_to+0x4c/0x6c
[c7b5fd40] [c028fed4] schedule+0x184/0x310
[c7b5fd70] [c0290e5c] __mutex_lock_slowpath+0xa4/0x150
[c7b5fdb0] [c0290c50] mutex_lock+0x44/0x48
[c7b5fdc0] [c01eb5b0] rtnl_lock+0x18/0x28
[c7b5fdd0] [c01df6c4] dev_ioctl+0x2b4/0x764
[c7b5fe60] [c01cafc8] sock_ioctl+0x18c/0x2a0
[c7b5fe80] [c009a16c] vfs_ioctl+0xcc/0xe0
[c7b5fea0] [c009a998] do_vfs_ioctl+0xc4/0x79c
[c7b5ff10] [c009b0b0] sys_ioctl+0x40/0x74
[c7b5ff40] [c00117c4] ret_from_syscall+0x0/0x38
The dev_ioctl is in SIOCGIFCONF:
int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
{
struct ifreq ifr;
int ret;
char *colon;
/* One special case: SIOCGIFCONF takes ifconf argument
and requires shared lock, because it sleeps writing
to user space.
*/
if (cmd == SIOCGIFCONF) {
rtnl_lock();
ret = dev_ifconf(net, (char __user *) arg);
rtnl_unlock();
return ret;
}
Any ideas? Kernel is 2.6.35
^ permalink raw reply
* RE: INFO: task snmpd:398 blocked for more than 120 seconds.
From: David Laight @ 2010-11-08 15:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <OF385C74E5.E81887CB-ONC12577D5.00527686-C12577D5.0052E6B5@transmode.se>
=20
> I can't make out what is causing this hang every now an then:
>=20
> INFO: task snmpd:398 blocked for more than 120 seconds.
My problem with that 'error' message is that there is no way
for a driver to disable it on a per-process basis.
We have some processes whose 'normal state' is to sleep
uninterruptibly in the kernel. Shutdown is handled by
an explicit request (not by sending a signal).
The processes could be kernel worker threads (except that
is is ~impossible to handle them exiting from a loadble
kernel module) so are actually children of a daemon sat
inside an ioctl() request that never terminates!
However, on the face of it, your case does look as though
the mutex is fubar'ed.
Might be worth (somehow) dumping the mutex state.
David
^ permalink raw reply
* RE: INFO: task snmpd:398 blocked for more than 120 seconds.
From: Joakim Tjernlund @ 2010-11-08 15:51 UTC (permalink / raw)
To: David Laight; +Cc: linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AB9A@saturn3.aculab.com>
>
> > I can't make out what is causing this hang every now an then:
> >
> > INFO: task snmpd:398 blocked for more than 120 seconds.
>
> My problem with that 'error' message is that there is no way
> for a driver to disable it on a per-process basis.
> We have some processes whose 'normal state' is to sleep
> uninterruptibly in the kernel. Shutdown is handled by
> an explicit request (not by sending a signal).
> The processes could be kernel worker threads (except that
> is is ~impossible to handle them exiting from a loadble
> kernel module) so are actually children of a daemon sat
> inside an ioctl() request that never terminates!
>
> However, on the face of it, your case does look as though
> the mutex is fubar'ed.
>
> Might be worth (somehow) dumping the mutex state.
ehh, it is locked, isn't it? How to find who locked it
and forgot to release it?
Jocke
^ permalink raw reply
* Better performance when CONFIG_DEBUG_KERNEL is on
From: Jean-Michel Hautbois @ 2010-11-08 16:00 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody,
I am using a mpc5200 chip with a linux 2.6.33.7-rt29.
I am using the ELDK toolchain :
ppc_6xx-gcc -v
Target: powerpc-linux
Configured with:
/opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/configure
--target=powerpc-linux --host=i686-host_pc-linux-gnu
--prefix=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux
--disable-hosted-libstdcxx
--with-headers=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/powerpc-linux/include
--with-local-prefix=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/powerpc-linux
--disable-nls --enable-threads=posix --enable-symvers=gnu
--enable-__cxa_atexit --enable-languages=c,c++,java --enable-shared
--enable-c99 --enable-long-long --without-x
Thread model: posix
gcc version 4.2.2
When I have the CONFIG_DEBUG_KERNEL flag, the latencies I am mesuring
are better than when the flag is off.
And the jitter is lower...
I must tell I am confused. I have no explanation about that, except
maybe optimisations which would be different when the -g flag is
added...
If any of you has an idea, I am looking forward for your response :).
Thanks in advance,
Best Regards.
JM
^ permalink raw reply
* PowerMac8600 help ...
From: kevin diggs @ 2010-11-08 16:43 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
Sorry for the noise but I am having trouble getting the latest kernel
built for a PowerMac8600 with a 750GX processor card. If this is not
an appropriate topic for the list please tell me (and hopefully point
me in the correct direction).
I have narrowed the problem down to the compiler. YDL 4.0 is installed
on the machine. The stock compiler is 3.3.3. That version can NOT
build past 2.6.28. I built 3.4.6, (the latest 3 series I could find).
It can NOT build later kernel versions either. It can build Firefox
2.0.0.15pre, including powerpc thin lock support. Running it now.
I then tried 4.3.5. This will build the kernel. But the resulting
kernel will NOT run. A firefox built with 4.3.5 also will not run. Or
if it runs it crashes often (http://abcnews.com).
What really puzzles me is I used the same basic compiler boot
strapping (3.3.3 to build 3.4.6, 3.4.6 to build 4.3.5) on a GiGE. That
machine is now running 2.6.36.
The CFLAGS used were: "-O2 -mcpu=7450 -mmultiple -mstring" for the
GiGE (dual 7455s). Substitute 750 for the 8600.
Any suggestions would be appreciated.
Thanks!
kevin
P.S.: Why does this program work:
int main(int argc, char *argv[])
{
unsigned int pvr;
// asm("mfspr %0,22\n"
asm("mfspr %0,287\n"
:"=r" (pvr)
);
printf("pvr is 0x%x\n",pvr);
}
>From what I have read, access to the pvr is restricted? strace does
not show an illegal instruction trap for SPRN_PVR.
^ permalink raw reply
* Re: INFO: task snmpd:398 blocked for more than 120 seconds.
From: Joakim Tjernlund @ 2010-11-08 17:33 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <OF385C74E5.E81887CB-ONC12577D5.00527686-C12577D5.0052E6B5@transmode.se>
linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org wrote on 2010/11/08 16:05:30:
> From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> To: linuxppc-dev@ozlabs.org
> Date: 2010/11/08 16:12
> Subject: INFO: task snmpd:398 blocked for more than 120 seconds.
> Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
>
>
> I can't make out what is causing this hang every now an then:
>
> INFO: task snmpd:398 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> snmpd D 0fad1760 0 398 1 0x00000000
> Call Trace:
> [c7b5fc70] [c7a49a80] 0xc7a49a80 (unreliable)
> [c7b5fd30] [c0008608] __switch_to+0x4c/0x6c
> [c7b5fd40] [c028fed4] schedule+0x184/0x310
> [c7b5fd70] [c0290e5c] __mutex_lock_slowpath+0xa4/0x150
> [c7b5fdb0] [c0290c50] mutex_lock+0x44/0x48
> [c7b5fdc0] [c01eb5b0] rtnl_lock+0x18/0x28
> [c7b5fdd0] [c01df6c4] dev_ioctl+0x2b4/0x764
> [c7b5fe60] [c01cafc8] sock_ioctl+0x18c/0x2a0
> [c7b5fe80] [c009a16c] vfs_ioctl+0xcc/0xe0
> [c7b5fea0] [c009a998] do_vfs_ioctl+0xc4/0x79c
> [c7b5ff10] [c009b0b0] sys_ioctl+0x40/0x74
> [c7b5ff40] [c00117c4] ret_from_syscall+0x0/0x38
>
> The dev_ioctl is in SIOCGIFCONF:
> int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
> {
> struct ifreq ifr;
> int ret;
> char *colon;
>
> /* One special case: SIOCGIFCONF takes ifconf argument
> and requires shared lock, because it sleeps writing
> to user space.
> */
>
> if (cmd == SIOCGIFCONF) {
> rtnl_lock();
> ret = dev_ifconf(net, (char __user *) arg);
> rtnl_unlock();
> return ret;
> }
>
> Any ideas? Kernel is 2.6.35
I tried PROVE_LOCKING but now my kernel doesn't boot at all :)
Something goes very wrong in arch/powerpc/kernel/prom.c:694
694 memblock_reserve(PHYSICAL_START, __pa(klimit) - PHYSICAL_START);
(gdb) print klimit
$8 = 0xc08c9000
What is klimit and can I do something about it?
kernel 2.6.35 on a mpc8321
^ permalink raw reply
* Re: INFO: task snmpd:398 blocked for more than 120 seconds.
From: Joakim Tjernlund @ 2010-11-08 18:22 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <OF5A1033A2.48B05F1F-ONC12577D5.00605774-C12577D5.00606A22@transmode.se>
>
> linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org wrote on 2010/11/08 16:05:30:
>
> > From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > To: linuxppc-dev@ozlabs.org
> > Date: 2010/11/08 16:12
> > Subject: INFO: task snmpd:398 blocked for more than 120 seconds.
> > Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
> >
> >
> > I can't make out what is causing this hang every now an then:
> >
> > INFO: task snmpd:398 blocked for more than 120 seconds.
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > snmpd D 0fad1760 0 398 1 0x00000000
> > Call Trace:
> > [c7b5fc70] [c7a49a80] 0xc7a49a80 (unreliable)
> > [c7b5fd30] [c0008608] __switch_to+0x4c/0x6c
> > [c7b5fd40] [c028fed4] schedule+0x184/0x310
> > [c7b5fd70] [c0290e5c] __mutex_lock_slowpath+0xa4/0x150
> > [c7b5fdb0] [c0290c50] mutex_lock+0x44/0x48
> > [c7b5fdc0] [c01eb5b0] rtnl_lock+0x18/0x28
> > [c7b5fdd0] [c01df6c4] dev_ioctl+0x2b4/0x764
> > [c7b5fe60] [c01cafc8] sock_ioctl+0x18c/0x2a0
> > [c7b5fe80] [c009a16c] vfs_ioctl+0xcc/0xe0
> > [c7b5fea0] [c009a998] do_vfs_ioctl+0xc4/0x79c
> > [c7b5ff10] [c009b0b0] sys_ioctl+0x40/0x74
> > [c7b5ff40] [c00117c4] ret_from_syscall+0x0/0x38
> >
> > The dev_ioctl is in SIOCGIFCONF:
> > int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
> > {
> > struct ifreq ifr;
> > int ret;
> > char *colon;
> >
> > /* One special case: SIOCGIFCONF takes ifconf argument
> > and requires shared lock, because it sleeps writing
> > to user space.
> > */
> >
> > if (cmd == SIOCGIFCONF) {
> > rtnl_lock();
> > ret = dev_ifconf(net, (char __user *) arg);
> > rtnl_unlock();
> > return ret;
> > }
> >
> > Any ideas? Kernel is 2.6.35
>
> I tried PROVE_LOCKING but now my kernel doesn't boot at all :)
>
> Something goes very wrong in arch/powerpc/kernel/prom.c:694
> 694 memblock_reserve(PHYSICAL_START, __pa(klimit) - PHYSICAL_START);
>
> (gdb) print klimit
> $8 = 0xc08c9000
>
> What is klimit and can I do something about it?
>
> kernel 2.6.35 on a mpc8321
That was not quite right, turns out that early_init_devtree(*params)
points to a memory that has been zeroed:
print initial_boot_params
$3 = (struct boot_param_header *) 0xc07fa000
Above matches what u-boot writes:
Booting kernel from Legacy Image at 00200000 ...
Image Name: oskernel02a:p1a:99
Created: 2010-11-08 18:09:28 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1898430 Bytes = 1.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 07fdebb0
Booting using the fdt blob at 0x7fdebb0
Uncompressing Kernel Image ... OK
Loading Device Tree to 007fa000, end 007ff327 ... OK
(gdb) print *initial_boot_params
$4 = {magic = 0x0, totalsize = 0x0, off_dt_struct = 0x0, off_dt_strings = 0x0,
off_mem_rsvmap = 0x0, version = 0x0, last_comp_version = 0x0,
boot_cpuid_phys = 0x0, dt_strings_size = 0x0, dt_struct_size = 0x0}
Jocke
^ permalink raw reply
* Re: [RFC PATCH 0/7 v2] ppc: enable dynamic dma window support
From: Nishanth Aravamudan @ 2010-11-08 19:42 UTC (permalink / raw)
To: sonnyrao, miltonm, Benjamin Herrenschmidt, Paul Mackerras,
Grant Likely, linuxppc-dev
In-Reply-To: <1288150518-4026-1-git-send-email-nacc@us.ibm.com>
Hi all,
On 26.10.2010 [20:35:10 -0700], Nishanth Aravamudan wrote:
> The following series, which builds upon the series of cleanups I posted
> on 9/15 and 10/18 as "ppc iommu cleanups", enables the pseries firmware
> feature dynamic dma windows. This feature will allow future devices to
> have a 64-bit DMA mapping covering all memory, coexisting with a smaller
> IOMMU window in 32-bit PCI space
Was ping'ing on this changeset. If there are no objections, I will
repost it without the RFC tag asking Ben to merge it.
Thanks,
Nish
> Changes from v1 to v2:
>
> Fixed numerous bugs/issues found in testing.
> Reworked to be based off platform hook dma_set_mask().
>
> Nishanth Aravamudan (7):
> macio: ensure all dma routines get copied over
> ppc: add memory_hotplug_max
> ppc: do not search for dma-window property on dlpar remove
> ppc: checking for pdn->parent is redundant
> ppc/iommu: do not need to check for dma_window == NULL
> ppc/iommu: pass phb only to iommu_table_setparms_lpar
> ppc: add dynamic dma window support
>
> arch/powerpc/include/asm/device.h | 6 +
> arch/powerpc/include/asm/mmzone.h | 5 +
> arch/powerpc/mm/numa.c | 26 ++
> arch/powerpc/platforms/pseries/iommu.c | 600 ++++++++++++++++++++++++++++++--
> drivers/macintosh/macio_asic.c | 7 +-
> 5 files changed, 619 insertions(+), 25 deletions(-)
>
>
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: PowerMac8600 help ...
From: Benjamin Herrenschmidt @ 2010-11-08 22:31 UTC (permalink / raw)
To: kevin diggs; +Cc: Linuxppc-dev
In-Reply-To: <AANLkTiksY8x7XOifU3FAAPpCa_h4oEBmqu_a0vjRE5h5@mail.gmail.com>
On Mon, 2010-11-08 at 10:43 -0600, kevin diggs wrote:
>
> Sorry for the noise but I am having trouble getting the latest kernel
> built for a PowerMac8600 with a 750GX processor card. If this is not
> an appropriate topic for the list please tell me (and hopefully point
> me in the correct direction).
>
> I have narrowed the problem down to the compiler. YDL 4.0 is installed
> on the machine. The stock compiler is 3.3.3. That version can NOT
> build past 2.6.28. I built 3.4.6, (the latest 3 series I could find).
> It can NOT build later kernel versions either. It can build Firefox
> 2.0.0.15pre, including powerpc thin lock support. Running it now.
>
> I then tried 4.3.5. This will build the kernel. But the resulting
> kernel will NOT run. A firefox built with 4.3.5 also will not run. Or
> if it runs it crashes often (http://abcnews.com).
>
> What really puzzles me is I used the same basic compiler boot
> strapping (3.3.3 to build 3.4.6, 3.4.6 to build 4.3.5) on a GiGE. That
> machine is now running 2.6.36.
>
> The CFLAGS used were: "-O2 -mcpu=7450 -mmultiple -mstring" for the
> GiGE (dual 7455s). Substitute 750 for the 8600.
>
> Any suggestions would be appreciated.
This is odd... I wonder if your 8600 is having some memory problems ?
Have you tried using the kernel/firefox built with 4.3.5 on the GigE and
booting them on the 8600 ?
3.x are ancient but I would expect 4.3.x to work just fine
Cheers,
Ben.
^ permalink raw reply
* [PATCH 01/17][trivial] powerpc: Remove unnecessary casts of void ptr returning alloc function return values
From: Jesper Juhl @ 2010-11-08 23:07 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, trivial, Paul Mackerras
Hi,
The [vk][cmz]alloc(_node) family of functions return void pointers which
it's completely unnecessary/pointless to cast to other pointer types since
that happens implicitly.
This patch removes such casts from arch/powerpc/
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
pgtable_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index a87ead0..d1833ed 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -78,7 +78,7 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
/* pgdir take page or two with 4K pages and a page fraction otherwise */
#ifndef CONFIG_PPC_4K_PAGES
- ret = (pgd_t *)kzalloc(1 << PGDIR_ORDER, GFP_KERNEL);
+ ret = kzalloc(1 << PGDIR_ORDER, GFP_KERNEL);
#else
ret = (pgd_t *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
PGDIR_ORDER - PAGE_SHIFT);
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH] powerpc: Consolidate obj-y assignments
From: Michael Ellerman @ 2010-11-09 1:25 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87y694z3b8.fsf@macbook.be.48ers.dk>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Mon, 2010-11-08 at 08:23 +0100, Peter Korsgaard wrote:
> >>>>> "Michael" == Michael Ellerman <michael@ellerman.id.au> writes:
>
> Michael> No need to have three of them.
> Michael> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> Michael> ---
> Michael> arch/powerpc/kernel/Makefile | 9 ++++-----
> Michael> 1 files changed, 4 insertions(+), 5 deletions(-)
>
> Michael> - signal.o sysfs.o cacheinfo.o
> Michael> -obj-y += vdso32/
> Michael> + signal.o sysfs.o cacheinfo.o time.o \
> Michael> + time.o prom.o traps.o setup-common.o \
>
> You have time.o twice.
Yeah, it makes the kernel run twice as fast.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add jump label support
From: Stephen Rothwell @ 2010-11-09 2:35 UTC (permalink / raw)
To: Michael Ellerman
Cc: Kumar Gala, jbaron, linux-kernel, rostedt, linuxppc-dev,
Anton Blanchard, David S. Miller
In-Reply-To: <45fbc3cd7f6ce404d1e25bf01695fb629d86189d.1289189560.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
Hi Michael,
Just a trivial note ...
On Mon, 8 Nov 2010 15:12:46 +1100 (EST) Michael Ellerman <michael@ellerman.id.au> wrote:
>
> diff --git a/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
> new file mode 100644
> index 0000000..feffb86
> --- /dev/null
> +++ b/arch/powerpc/include/asm/jump_label.h
> @@ -0,0 +1,46 @@
> +#ifndef _ASM_POWERPC_JUMP_LABEL_H
> +#define _ASM_POWERPC_JUMP_LABEL_H
> +
> +/*
> + * Copyright 2010 Michael Ellerman, IBM Corp.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#ifdef __KERNEL__
You don't need this protection in a file that is not exported to user
space.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox