* [PATCH 0/3] Add virq mapping debugfs for PowerPC
From: Chen Gong @ 2007-07-23 11:13 UTC (permalink / raw)
To: paulus, galak; +Cc: linuxppc-dev, g.chen
Cc: g.chen@freescale.com
Hi
These patches are the update as follows:
http://ozlabs.org/pipermail/linuxppc-dev/2007-March/033091.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-March/033093.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-March/033092.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-March/033094.html
These patches are used for supplying virq mapping debugfs function.
It can be used for displaying irq-virq mapping relationship under debugfs.
Meanwhile, to express these information more clearly, we also add a new member
named "name" for struct irq_host.
[PATCH 1/3] Add a new member name to structure irq_host
[PATCH 2/3] Add irq host name for interrupt controllors
[PATCH 3/3] Add irq debugfs and virq mapping for getting the virq
Any feedback is welcome!
Best Regards,
Chen Gong
^ permalink raw reply
* Re: [PATCH 0/3] Add virq mapping debugfs for PowerPC
From: Stephen Rothwell @ 2007-07-23 11:55 UTC (permalink / raw)
To: Chen Gong; +Cc: linuxppc-dev, paulus
In-Reply-To: <11851892302391-git-send-email-g.chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 454 bytes --]
On Mon, 23 Jul 2007 19:13:47 +0800 Chen Gong <g.chen@freescale.com> wrote:
>
> [PATCH 1/3] Add a new member name to structure irq_host
> [PATCH 2/3] Add irq host name for interrupt controllors
You should really combine patches 1 and 2 so that the tree will build and
run after each final commit in the git tree (so bisect works better).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] mpc8349emitx: Add chosen node for default stdout path
From: Timur Tabi @ 2007-07-23 13:12 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev
In-Reply-To: <46A01733.6080609@gmail.com>
Jerry Van Baren wrote:
> The "force" parameter was added to sort of emulate the previous bootm
> command behavior (but behave better in the case where /chosen already
> existed).
I don't think the previous bootm behavior was ever desirable. In fact, I think most people didn't realize that bootm used to create an additional /chosen section if one was in the DTS, and the only reason it worked was because the kernel picked the right one. IMHO, I think you can safely remove the 'force' parameter and change to code to match "force==true", and no one will care.
I believe all of the DTS files have already been scrubbed of their /chosen section, so "force" doesn't matter with any recent DTS.
^ permalink raw reply
* Re: Someone broke my allmodconfig build
From: Timur Tabi @ 2007-07-23 13:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <20070722115354.0c28d704.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
>> Hmmm, we should be shipping .dtb files with the tree, so people don't
>> have to have dtc installed.
>
> Unless, of course, we ship dtc ...
I like that idea.
I don't know much about the kernel build process, but is it normal to ship C files and have kbuild build them and then use the executables to build the rest of the kernel?
^ permalink raw reply
* Re: [PATCH][12/37] Clean up duplicate includes in drivers/net/
From: John W. Linville @ 2007-07-23 13:22 UTC (permalink / raw)
To: Jesper Juhl
Cc: info, Luke Yang, Judy Fischbach, Patrick McHardy, bonding-devel,
Bryan Wu, kong.lai, Jay Vosburgh, James Morris, linuxppc-embedded,
Daniel Drake, Alex V Lasso, Ulrich Kunitz, Chad Tindel,
Amit S Kale, Jay Cliburn, Samuel Ortiz, Brian Pugh,
Alexey Kuznetsov, Chris Snook, alexandre.bounine,
Pantelis Antoniou, netdev, linux-wireless,
Linux Kernel Mailing List, Ralf Baechle, Vitaly Bordug,
Lukasz Stelmach, Ron Mercer, atl1-devel, Andrew Morton,
David S. Miller, James P Ketrenos
In-Reply-To: <200707211702.46375.jesper.juhl@gmail.com>
On Sat, Jul 21, 2007 at 05:02:45PM +0200, Jesper Juhl wrote:
> Hi,
>
> This patch cleans up duplicate includes in
> drivers/net/
>
>
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> diff --git a/drivers/net/wireless/ipw2200.h b/drivers/net/wireless/ipw2200.h
> index 626a240..9c973b9 100644
> --- a/drivers/net/wireless/ipw2200.h
> +++ b/drivers/net/wireless/ipw2200.h
> @@ -45,7 +45,6 @@
>
> #include <linux/firmware.h>
> #include <linux/wireless.h>
> -#include <linux/dma-mapping.h>
> #include <linux/jiffies.h>
> #include <asm/io.h>
>
> diff --git a/drivers/net/wireless/zd1211rw/zd_def.h b/drivers/net/wireless/zd1211rw/zd_def.h
> index deb99d1..505b4d7 100644
> --- a/drivers/net/wireless/zd1211rw/zd_def.h
> +++ b/drivers/net/wireless/zd1211rw/zd_def.h
> @@ -21,7 +21,6 @@
> #include <linux/kernel.h>
> #include <linux/stringify.h>
> #include <linux/device.h>
> -#include <linux/kernel.h>
>
> typedef u16 __nocast zd_addr_t;
ACK
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH] Use resource_size_t for serial port IO addresses
From: Josh Boyer @ 2007-07-23 14:08 UTC (permalink / raw)
To: Russell King; +Cc: linuxppc-dev, Andrew Morton, paulus, david
In-Reply-To: <20070715110606.GA32577@flint.arm.linux.org.uk>
On Sun, 2007-07-15 at 12:06 +0100, Russell King wrote:
> > This is something we should do, but I have recollections of Russell
> > identifying problems with this patch, or at least an earlier version of it?
>
> Basically, there's two patches. This one (let's call this patch A)
> and another to prevent users being surprised (let's call that patch B).
>
> I didn't have any real objections to patch A, provided something like
> patch B was merged. I did have objections against patch B, and I was
> intermittently working on a revised solution.
>
> However, for whatever reason [*], during the last merge window patch B
> got merged and patch A got dropped, and as a result I've now given up
> with my revised solution, and TBH, I no longer care.
Patch B in this case was commit abb4a2390. Since that has already been
merged, can we please merge this patch into 2.6.23? I'd really like to
avoid 44x not working in yet another kernel, so if this patch can't be
merged I'll have to come up with some alternate solution soon.
josh
^ permalink raw reply
* [PATCH] eHEA: net_poll support
From: Jan-Bernd Themann @ 2007-07-23 14:05 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
net_poll support for eHEA added
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 22 +++++++++++++++++++++-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 489c8b2..8ee2c2c 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0071"
+#define DRV_VERSION "EHEA_0072"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 4c70a93..58702f5 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -589,6 +589,23 @@ static int ehea_poll(struct net_device *dev, int *budget)
return 1;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void ehea_netpoll(struct net_device *dev)
+{
+ struct ehea_port *port = netdev_priv(dev);
+
+ netif_rx_schedule(port->port_res[0].d_netdev);
+}
+#endif
+
+static int ehea_poll_firstqueue(struct net_device *dev, int *budget)
+{
+ struct ehea_port *port = netdev_priv(dev);
+ struct net_device *d_dev = port->port_res[0].d_netdev;
+
+ return ehea_poll(d_dev, budget);
+}
+
static irqreturn_t ehea_recv_irq_handler(int irq, void *param)
{
struct ehea_port_res *pr = param;
@@ -2626,7 +2643,10 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
memcpy(dev->dev_addr, &port->mac_addr, ETH_ALEN);
dev->open = ehea_open;
- dev->poll = ehea_poll;
+ dev->poll = ehea_poll_firstqueue;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ dev->poll_controller = ehea_netpoll;
+#endif
dev->weight = 64;
dev->stop = ehea_stop;
dev->hard_start_xmit = ehea_start_xmit;
--
1.5.2
^ permalink raw reply related
* Re: [PATCH][36/37] Clean up duplicate includes in sound/ppc/
From: Takashi Iwai @ 2007-07-23 14:45 UTC (permalink / raw)
To: Jesper Juhl
Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List,
cbe-oss-dev
In-Reply-To: <200707211704.07263.jesper.juhl@gmail.com>
At Sat, 21 Jul 2007 17:04:07 +0200,
Jesper Juhl wrote:
>
> Hi,
>
> This patch cleans up duplicate includes in
> XXXX/
sound/ppc? :)
>
>
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Now applied to ALSA tree. Thanks.
Takashi
> ---
>
> diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
> index 1aa0b46..27b6189 100644
> --- a/sound/ppc/snd_ps3.c
> +++ b/sound/ppc/snd_ps3.c
> @@ -33,7 +33,6 @@
> #include <linux/dmapool.h>
> #include <linux/dma-mapping.h>
> #include <asm/firmware.h>
> -#include <linux/io.h>
> #include <asm/dma.h>
> #include <asm/lv1call.h>
> #include <asm/ps3.h>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* 2.6.23-rc1 breaks on JS20 w/SLOF
From: Adrian Reber @ 2007-07-23 14:47 UTC (permalink / raw)
To: linuxppc-dev
On a JS20 with SLOF (pretending to be Maple) 2.6.23-rc1 breaks with
following oops. 2.6.22 is working. Let me know if I can help debug this.
Maple: Found RTC at IO 0x1070
Unable to handle kernel paging request for data at address 0xd000080000001070
Faulting instruction address: 0xc00000000004d948
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 Maple
Modules linked in:
NIP: c00000000004d948 LR: c00000000004d8e4 CTR: c000000000029308
REGS: c00000000088b8e0 TRAP: 0300 Not tainted (2.6.23-rc1)
MSR: 9000000000001032 <ME,IR,DR> CR: 24000022 XER: 000fffff
DAR: d000080000001070, DSISR: 0000000042000000
TASK = c00000000079db50[0] 'swapper' THREAD: c000000000888000 CPU: 0
GPR00: d000080000000000 c00000000088bb60 c0000000008884a8 000000000000000a
GPR04: d000080000001070 0000000000000001 0000000000000000 0000000000000001
GPR08: 0000000000001070 d000080000001070 0000000000000000 c0000000008b33b0
GPR12: c00000000088bab4 c00000000079e480 0000000000000000 0000000000000000
GPR16: 0000000004000000 0000000000000000 0000000000000000 4000000001400000
GPR20: c000000000752370 0000000001b525e0 0000000000000000 c0000000008b47f0
GPR24: c00000000088be70 c0000000008b4820 000000003b9aca00 c0000000008b47f8
GPR28: 0000000000000000 000000000000000a c000000000821af8 c00000000088bcf0
NIP [c00000000004d948] .maple_clock_read+0x88/0x17c
LR [c00000000004d8e4] .maple_clock_read+0x24/0x17c
Call Trace:
[c00000000088bb60] [c00000000088bbe0] init_thread_union+0x3be0/0x4000 (unreliable)
[c00000000088bbf0] [c00000000004dc40] .maple_get_rtc_time+0x28/0x174
[c00000000088bc80] [c000000000731000] .maple_get_boot_time+0xe4/0x12c
[c00000000088bd60] [c000000000022694] .get_boot_time+0x3c/0xb8
[c00000000088be00] [c000000000721088] .time_init+0x290/0x46c
[c00000000088bee0] [c000000000716c18] .start_kernel+0x23c/0x3e4
[c00000000088bf90] [c000000000008524] .start_here_common+0x54/0xb0
Instruction dump:
419e0024 e80a0000 f8410028 7c0903a6 e96a0010 e84a0008 4e800421 e8410028
4800001c 78892300 7929e002 7c0004ac <98690000> 38000001 980d01dc e97e8008
Kernel panic - not syncing: Attempted to kill the idle task!
------------[ cut here ]------------
Badness at arch/powerpc/kernel/smp.c:202
NIP: c000000000028ae0 LR: c000000000069410 CTR: c000000000029308
REGS: c00000000088b2b0 TRAP: 0700 Tainted: G D (2.6.23-rc1)
MSR: 9000000000021032 <ME,IR,DR> CR: 28000022 XER: 000fffff
TASK = c00000000079db50[0] 'swapper' THREAD: c000000000888000 CPU: 0
GPR00: 0000000000000001 c00000000088b530 c0000000008884a8 c000000000841418
GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000001
GPR08: 0000000000000001 c0000000008b4b88 c0000000008c1af8 c000000000841418
GPR12: c000000000008524 c00000000079e480 0000000000000000 0000000000000000
GPR16: 0000000004000000 0000000000000000 0000000000000000 4000000001400000
GPR20: c000000000752370 0000000001b525e0 0000000000000000 c0000000008b47f0
GPR24: c00000000088be70 000000000000000b 000000003b9aca00 000000000000000b
GPR28: c0000000006778f0 0000000000000000 c000000000822a98 0000000000000000
NIP [c000000000028ae0] .smp_call_function_map+0x30/0x2a4
LR [c000000000069410] .panic+0x98/0x1b0
Call Trace:
[c00000000088b530] [c00000000082ebe8] gss_kerberos_pfs+0x16e18/0x25ff0 (unreliable)
[c00000000088b5e0] [c000000000069410] .panic+0x98/0x1b0
[c00000000088b680] [c00000000006dffc] .do_exit+0x8c/0xa60
[c00000000088b750] [c000000000023dcc] .die+0x238/0x264
[c00000000088b7f0] [c00000000002d2a8] .bad_page_fault+0xb8/0xd4
[c00000000088b870] [c000000000005418] handle_page_fault+0x3c/0x58
--- Exception: 300 at .maple_clock_read+0x88/0x17c
LR = .maple_clock_read+0x24/0x17c
[c00000000088bb60] [c00000000088bbe0] init_thread_union+0x3be0/0x4000 (unreliable)
[c00000000088bbf0] [c00000000004dc40] .maple_get_rtc_time+0x28/0x174
[c00000000088bc80] [c000000000731000] .maple_get_boot_time+0xe4/0x12c
[c00000000088bd60] [c000000000022694] .get_boot_time+0x3c/0xb8
[c00000000088be00] [c000000000721088] .time_init+0x290/0x46c
[c00000000088bee0] [c000000000716c18] .start_kernel+0x23c/0x3e4
[c00000000088bf90] [c000000000008524] .start_here_common+0x54/0xb0
Instruction dump:
7c0802a6 fba1ffe8 fbc1fff0 fbe1fff8 7c6b1b78 f8010010 f821ff51 7cdd3378
f8e10100 880d01da 7c000074 7800d182 <0b000000> e922a900 3860ffff e8090000
Rebooting in 180 seconds..
Adrian
^ permalink raw reply
* Re: Someone broke my allmodconfig build
From: Grant Likely @ 2007-07-23 15:07 UTC (permalink / raw)
To: Timur Tabi; +Cc: Stephen Rothwell, Paul Mackerras, ppc-dev
In-Reply-To: <46A4A9DC.6010602@freescale.com>
On 7/23/07, Timur Tabi <timur@freescale.com> wrote:
> Stephen Rothwell wrote:
>
> >> Hmmm, we should be shipping .dtb files with the tree, so people don't
> >> have to have dtc installed.
> >
> > Unless, of course, we ship dtc ...
>
> I like that idea.
>
> I don't know much about the kernel build process, but is it normal to ship C files and have kbuild build them and then use the executables to build the rest of the kernel?
That's how Kconfig is built.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Someone broke my allmodconfig build
From: Josh Boyer @ 2007-07-23 15:17 UTC (permalink / raw)
To: Grant Likely; +Cc: Stephen Rothwell, Paul Mackerras, Timur Tabi, ppc-dev
In-Reply-To: <fa686aa40707230807k450ff82dv11201ca3a4ce4c9b@mail.gmail.com>
On Mon, 2007-07-23 at 09:07 -0600, Grant Likely wrote:
> On 7/23/07, Timur Tabi <timur@freescale.com> wrote:
> > Stephen Rothwell wrote:
> >
> > >> Hmmm, we should be shipping .dtb files with the tree, so people don't
> > >> have to have dtc installed.
> > >
> > > Unless, of course, we ship dtc ...
> >
> > I like that idea.
> >
> > I don't know much about the kernel build process, but is it normal to ship C files and have kbuild build them and then use the executables to build the rest of the kernel?
>
> That's how Kconfig is built.
And mktree.
josh
^ permalink raw reply
* Re: Someone broke my allmodconfig build
From: Mark A. Greer @ 2007-07-23 15:24 UTC (permalink / raw)
To: Josh Boyer, Paul Mackerras, Stephen Rothwell, ppc-dev
In-Reply-To: <20070723014337.GC3272@localhost.localdomain>
On Mon, Jul 23, 2007 at 11:43:37AM +1000, David Gibson wrote:
> On Sat, Jul 21, 2007 at 09:04:13PM -0500, Josh Boyer wrote:
> > On Sun, Jul 22, 2007 at 10:37:06AM +1000, Paul Mackerras wrote:
> > > Stephen Rothwell writes:
> > >
> > > > WRAP arch/powerpc/boot/zImage.ps3
> > > > /home/sfr/kernels/linus/arch/powerpc/boot/wrapper: line 113: dtc: command not found
> > > > make[2]: *** [arch/powerpc/boot/zImage.ps3] Error 1
> > >
> > > Hmmm, we should be shipping .dtb files with the tree, so people don't
> > > have to have dtc installed.
> >
> > Really? I don't think we're quite ready for that. Particularly for the
> > embedded boards. Those DTS files still get lots of churn, and having to
> > update both the .dts and .dtb at the same time seems a bit fragile.
>
> I sort of prefer this option in theory, but it's basically
> impossible. People updating dts files by patch would also have to
> update the dtb, which can't be done in a normal patch, since they're
> binary.
I agree. Shipping a magic binary blob, especially ones that haven't
really settled out, will be a real headache for poeple.
> I'm working with sfr now on importing dtc into the kernel tree.
IIRC, this was discussed when dtc first came into existence but it was
pooh-poohed. I forget why now.
Mark
^ permalink raw reply
* support for MPC8220?
From: Leisner, Martin @ 2007-07-23 15:27 UTC (permalink / raw)
To: linuxppc-embedded
Is there support for MPC8220 in current kernels?
I didn't see it there, in freescale's site it mentions Montavista Pro
3.1.
marty
^ permalink raw reply
* Re: Gdbserver syscall clobber
From: Bill Gatliff @ 2007-07-23 15:37 UTC (permalink / raw)
To: Bill Gatliff, gdb, linuxppc-embedded
In-Reply-To: <20070718183143.GA25324@caradoc.them.org>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
Daniel Jacobowitz wrote:
> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
>
>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
>> lately), but it looks to me like the kernel is setting bit 0 in CR0
>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
>> (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure
>> after reading Sections 1.2 and 2.1 of the Programming Environments manual.
>>
>
> It's not checking for restart here - userspace isn't supposed to have to.
> It's probably checking for error. Check for the bit of kernel code
> that's supposed to back you up two instructions.
>
>
I don't see it in this kernel. What I see is this after the call to the
syscall handler:
li r10,-_LAST_ERRNO
cmpl 0,r3,r10
blt 30f
neg r3,r3
cmpi 0,r3,ERESTARTNOHAND
bne 22f
li r3,EINTR
22: lwz r10,_CCR(r1) /* Set SO bit in CR */
oris r10,r10,0x1000
stw r10,_CCR(r1)
30: stw r3,GPR3(r1) /* Update return value */
b ret_from_except
66: li r3,ENOSYS
b 22b
?
--
Bill Gatliff
bgat@billgatliff.com
[-- Attachment #2: Type: text/html, Size: 2229 bytes --]
^ permalink raw reply
* Re: Gdbserver syscall clobber
From: Bill Gatliff @ 2007-07-23 15:38 UTC (permalink / raw)
To: Bill Gatliff, gdb, linuxppc-embedded
In-Reply-To: <20070718183143.GA25324@caradoc.them.org>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
Daniel Jacobowitz wrote:
> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
>
>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
>> lately), but it looks to me like the kernel is setting bit 0 in CR0
>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
>> (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure
>> after reading Sections 1.2 and 2.1 of the Programming Environments manual.
>>
>
> It's not checking for restart here - userspace isn't supposed to have to.
> It's probably checking for error. Check for the bit of kernel code
> that's supposed to back you up two instructions.
>
>
I don't see it in this kernel. What I see is this after the call to the
syscall handler:
li r10,-_LAST_ERRNO
cmpl 0,r3,r10
blt 30f
neg r3,r3
cmpi 0,r3,ERESTARTNOHAND
bne 22f
li r3,EINTR
22: lwz r10,_CCR(r1) /* Set SO bit in CR */
oris r10,r10,0x1000
stw r10,_CCR(r1)
30: stw r3,GPR3(r1) /* Update return value */
b ret_from_except
66: li r3,ENOSYS
b 22b
?
--
Bill Gatliff
bgat@billgatliff.com
[-- Attachment #2: Type: text/html, Size: 2229 bytes --]
^ permalink raw reply
* Re: Someone broke my allmodconfig build
From: Timur Tabi @ 2007-07-23 15:47 UTC (permalink / raw)
To: Grant Likely; +Cc: Stephen Rothwell, Paul Mackerras, ppc-dev
In-Reply-To: <fa686aa40707230807k450ff82dv11201ca3a4ce4c9b@mail.gmail.com>
Grant Likely wrote:
> On 7/23/07, Timur Tabi <timur@freescale.com> wrote:
>> Stephen Rothwell wrote:
>>
>> >> Hmmm, we should be shipping .dtb files with the tree, so people don't
>> >> have to have dtc installed.
>> >
>> > Unless, of course, we ship dtc ...
>>
>> I like that idea.
>>
>> I don't know much about the kernel build process, but is it normal to
>> ship C files and have kbuild build them and then use the executables
>> to build the rest of the kernel?
>
> That's how Kconfig is built.
Then it shouldn't be too hard to refactor the dtc build environment to make it
Kbuild-compatible, and then Paul can pull from Jon's dtc repo whenever it gets updated.
Jon, what do you think?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Gdbserver syscall clobber
From: Bill Gatliff @ 2007-07-23 16:06 UTC (permalink / raw)
To: Bill Gatliff, gdb, linuxppc-embedded
In-Reply-To: <20070718183143.GA25324@caradoc.them.org>
Daniel Jacobowitz wrote:
> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
>
>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
>> lately), but it looks to me like the kernel is setting bit 0 in CR0
>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
>> (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure
>> after reading Sections 1.2 and 2.1 of the Programming Environments manual.
>>
>
> It's not checking for restart here - userspace isn't supposed to have to.
> It's probably checking for error. Check for the bit of kernel code
> that's supposed to back you up two instructions.
>
>
I don't see it in this kernel. What I see is this after the call to the
syscall handler:
li r10,-_LAST_ERRNO
cmpl 0,r3,r10
blt 30f
neg r3,r3
cmpi 0,r3,ERESTARTNOHAND
bne 22f
li r3,EINTR
22: lwz r10,_CCR(r1) /* Set SO bit in CR */
oris r10,r10,0x1000
stw r10,_CCR(r1)
30: stw r3,GPR3(r1) /* Update return value */
b ret_from_except
66: li r3,ENOSYS
b 22b
?
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: Gdbserver syscall clobber
From: Daniel Jacobowitz @ 2007-07-23 16:15 UTC (permalink / raw)
To: Bill Gatliff; +Cc: gdb, linuxppc-embedded
In-Reply-To: <46A4D1F5.1060005@billgatliff.com>
On Mon, Jul 23, 2007 at 11:06:13AM -0500, Bill Gatliff wrote:
> Daniel Jacobowitz wrote:
> > On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
> >
> >> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
> >> lately), but it looks to me like the kernel is setting bit 0 in CR0
> >> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
> >> (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure
> >> after reading Sections 1.2 and 2.1 of the Programming Environments manual.
> >>
> >
> > It's not checking for restart here - userspace isn't supposed to have to.
> > It's probably checking for error. Check for the bit of kernel code
> > that's supposed to back you up two instructions.
> >
> >
>
> I don't see it in this kernel. What I see is this after the call to the
> syscall handler:
Look around do_signal:
regs->nip -= 4; /* Back up & retry system call */
If your kernel has corrupted the register containing the syscall
number at this point, that would explain your problem. It will then
do the wrong syscall. I guess PPC only backs up one instruction.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* Re: Gdbserver syscall clobber
From: Andreas Schwab @ 2007-07-23 16:19 UTC (permalink / raw)
To: Bill Gatliff; +Cc: gdb, linuxppc-embedded
In-Reply-To: <46A4D1F5.1060005@billgatliff.com>
Bill Gatliff <bgat@billgatliff.com> writes:
> Daniel Jacobowitz wrote:
>> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
>>
>>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
>>> lately), but it looks to me like the kernel is setting bit 0 in CR0
>>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
>>> (bnslr+) bit 3 a.k.a. SO.
Bits are numbered from left to right, thus 0x10000000 is bit 3 of CR0
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 5/6 v2] 85xxCDS: Misc 8548 PCI Corrections.
From: Randy Vinson @ 2007-07-23 18:04 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list
In-Reply-To: <1185185072.25737.1.camel@localhost.localdomain>
Zang Roy-r61911 wrote:
> On Sat, 2007-07-21 at 06:31, Randy Vinson wrote:
>
>> @@ -272,10 +272,10 @@ static void __init mpc85xx_cds_setup_arch(void)
>> for (np = NULL; (np = of_find_node_by_type(np, "pci")) !=
>> NULL;) {
>> struct resource rsrc;
>> of_address_to_resource(np, 0, &rsrc);
>> - if ((rsrc.start & 0xfffff) == 0x9000)
>> - fsl_add_bridge(np, 0);
>> - else
>> + if ((rsrc.start & 0xfffff) == 0x8000)
>> fsl_add_bridge(np, 1);
>> + else
>> + fsl_add_bridge(np, 0);
> Why this is needed?
> For pcie@a000, fsl_add_bridge(np, 0)?
The old version of the code would call fsl_add_bridge(np, 1) for the
host bridges @8000 and @a000. When I tried it that way, it didn't work.
I don't think you can have 2 primary bridges.
Randy V.
^ permalink raw reply
* Re: [PATCH][36/37] Clean up duplicate includes in sound/ppc/
From: Geoff Levand @ 2007-07-23 18:21 UTC (permalink / raw)
To: Jesper Juhl
Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List,
cbe-oss-dev
In-Reply-To: <200707211704.07263.jesper.juhl@gmail.com>
Jesper Juhl wrote:
> Hi,
>
> This patch cleans up duplicate includes in
> XXXX/
>
>
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> ---
>
> diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
> index 1aa0b46..27b6189 100644
> --- a/sound/ppc/snd_ps3.c
> +++ b/sound/ppc/snd_ps3.c
> @@ -33,7 +33,6 @@
> #include <linux/dmapool.h>
> #include <linux/dma-mapping.h>
> #include <asm/firmware.h>
> -#include <linux/io.h>
> #include <asm/dma.h>
> #include <asm/lv1call.h>
> #include <asm/ps3.h>
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
^ permalink raw reply
* Re: Kmalloc returns which address
From: Scott Wood @ 2007-07-23 18:35 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <11737504.post@talk.nabble.com>
On Sun, Jul 22, 2007 at 08:47:47PM -0700, Misbah khan wrote:
> yes really it would really generate a machine check... but i guess if you
> convert this virt address to physical address using __pa() then pass it to
> the ioremap() i guess things will work .
What would be the point? All you'd get is another virtual mapping.
Is the DMA mapping API that difficult?
-Scott
^ permalink raw reply
* Re: [PATCH] Use resource_size_t for serial port IO addresses
From: Andrew Morton @ 2007-07-23 19:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus, Russell King, david
In-Reply-To: <1185199717.4268.5.camel@weaponx.rchland.ibm.com>
On Mon, 23 Jul 2007 09:08:37 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Sun, 2007-07-15 at 12:06 +0100, Russell King wrote:
> > > This is something we should do, but I have recollections of Russell
> > > identifying problems with this patch, or at least an earlier version of it?
> >
> > Basically, there's two patches. This one (let's call this patch A)
> > and another to prevent users being surprised (let's call that patch B).
> >
> > I didn't have any real objections to patch A, provided something like
> > patch B was merged. I did have objections against patch B, and I was
> > intermittently working on a revised solution.
> >
> > However, for whatever reason [*], during the last merge window patch B
> > got merged and patch A got dropped, and as a result I've now given up
> > with my revised solution, and TBH, I no longer care.
>
> Patch B in this case was commit abb4a2390. Since that has already been
> merged, can we please merge this patch into 2.6.23? I'd really like to
> avoid 44x not working in yet another kernel, so if this patch can't be
> merged I'll have to come up with some alternate solution soon.
>
I still have a large pile of not-completely-obviously-ready patches to go
through, of which this is one.
There _were_ issues with this patch when it first turned up, but I failed
to record what they were.
Oh well, here's hoping it got fixed.
^ permalink raw reply
* Re: [PATCH][36/37] Clean up duplicate includes in sound/ppc/
From: Jesper Juhl @ 2007-07-23 19:53 UTC (permalink / raw)
To: Takashi Iwai
Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List,
cbe-oss-dev
In-Reply-To: <s5hlkd7yy9k.wl%tiwai@suse.de>
On 23/07/07, Takashi Iwai <tiwai@suse.de> wrote:
> At Sat, 21 Jul 2007 17:04:07 +0200,
> Jesper Juhl wrote:
> >
> > Hi,
> >
> > This patch cleans up duplicate includes in
> > XXXX/
>
> sound/ppc? :)
>
Hehe, yup. Seems I forgot to edit my mail template for that one :)
> >
> >
> > Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
>
> Now applied to ALSA tree. Thanks.
>
Thanks a lot.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
From: Christoph Lameter @ 2007-07-23 20:34 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, bart.vanassche, linux-mm,
bugme-daemon@kernel-bugs.osdl.org, linuxppc-embedded
In-Reply-To: <20070718095537.d344dc0a.akpm@linux-foundation.org>
On Wed, 18 Jul 2007 09:55:37 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> hm. It should be the case that providing SLAB_HWCACHE_ALIGN at
> kmem_cache_create() time will override slab-debugging's offsetting
> of the returned addresses.
That is true for SLUB but not in SLAB. SLAB has always ignored
SLAB_HWCACHE_ALIGN when debugging is on because of the issues involved
in placing the redzone values etc. Could be fun to fix.
^ 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