* Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
From: Benjamin Herrenschmidt @ 2008-04-14 0:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux-Arch, linux-m32r, takata, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <20080413171953.bde5e9ac.akpm@linux-foundation.org>
> > +#ifndef thread_info_cache_init
> > +#define thread_info_cache_init do { } while(0)
> > +#endif
>
> This trick does cause a bit of a problem: it is undefined which arch header
> file is to provide the alternative definition of thread_info_cache_init.
I this case it's well defined: thread_info.h. Maybe I should add a
comment ?
> So we can (and have) ended up in the situation where the override appears
> in different files on different architectures and various screwups ensue.
Yup.
> So I'd suggest that we have a bigfatcomment telling implementors which file
> the override should be implemented in. And make sure that this arch file is
> directly included from within sched.h.
Will do.
> I have a suspicion that we can still get in a mess if .c files include the
> per-arch file and don't include sched.h, but I forget where this happened
> and why it broke stuff.
In this case, there's only one call site and will only every be one, so
that shouldn't be a problem. I don't see init/main.c not including
sched.h
> Sigh. A nice, coded-in-C implementation within each and every architecture
> remains the best implementation, and all the little tricks-to-save-typing
> have failure modes.
Well, I started doing it in all arch, and people around here told me
that was not a good idea , that it would be trouble if the prototype
ever had to change (adding an arg, etc... though very unlikely to happen
in that case, granted).
> otoh, if only one .c file will ever call this function then I think that
> all problems are solved by
>
> a) moving the above ifdeffery into the .c file
> b) adding a comment explaining which arch file must provide the override
> c) directly including that file from within the .c file.
I can definitely do that. I have no problem either way. I can add to all
archs too, it's just that whatever way I choose, some people won't be
happy with it :-)
Anyway, I'll move the ifdeferry to init/main.c then.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] [POWERPC] remove include of asm/of_device.h from pmi.h
From: Stephen Rothwell @ 2008-04-14 2:00 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: ppc-dev, Christian Krafft
pmi.h does not diectly reference anything in of_device.h and of the two
files that include asm/pmi.h, one includes of_device.h and the other
includes of_platform.h (which includes of_device.h).
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/pmi.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/pmi.h b/include/asm-powerpc/pmi.h
index 2259d4c..e1dc090 100644
--- a/include/asm-powerpc/pmi.h
+++ b/include/asm-powerpc/pmi.h
@@ -29,8 +29,6 @@
#ifdef __KERNEL__
-#include <asm/of_device.h>
-
#define PMI_TYPE_FREQ_CHANGE 0x01
#define PMI_READ_TYPE 0
#define PMI_READ_DATA0 1
--
1.5.5
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH] [POWERPC] remove include of asm/of_device.h from pmi.h
From: Stephen Rothwell @ 2008-04-14 2:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: ppc-dev, Christian Krafft
In-Reply-To: <20080414120047.8144976b.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
On Mon, 14 Apr 2008 12:00:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> pmi.h does not diectly reference anything in of_device.h and of the two
> files that include asm/pmi.h, one includes of_device.h and the other
> includes of_platform.h (which includes of_device.h).
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
I forgot to say this has been built for ppc64_defconfig and
cell_defconfig (the only two configs that use it).
--
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
* [PATCH] [POWEPC] replace asm/of_device.h with linux/of_device.h in macio.h
From: Stephen Rothwell @ 2008-04-14 2:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/macio.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-powerpc/macio.h b/include/asm-powerpc/macio.h
index 3a6cb1a..079c06e 100644
--- a/include/asm-powerpc/macio.h
+++ b/include/asm-powerpc/macio.h
@@ -2,7 +2,7 @@
#define __MACIO_ASIC_H__
#ifdef __KERNEL__
-#include <asm/of_device.h>
+#include <linux/of_device.h>
extern struct bus_type macio_bus_type;
--
1.5.5
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
From: Andrew Morton @ 2008-04-14 2:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, linux-m32r, takata, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <1208133506.6958.82.camel@pasglop>
On Mon, 14 Apr 2008 10:38:26 +1000 Benjamin Herrenschmidt <benh@ozlabs.org> wrote:
> > > +#ifndef thread_info_cache_init
> > > +#define thread_info_cache_init do { } while(0)
> > > +#endif
> >
> > This trick does cause a bit of a problem: it is undefined which arch header
> > file is to provide the alternative definition of thread_info_cache_init.
>
> I this case it's well defined: thread_info.h. Maybe I should add a
> comment ?
>
> > So we can (and have) ended up in the situation where the override appears
> > in different files on different architectures and various screwups ensue.
>
> Yup.
>
> > So I'd suggest that we have a bigfatcomment telling implementors which file
> > the override should be implemented in. And make sure that this arch file is
> > directly included from within sched.h.
>
> Will do.
>
> > I have a suspicion that we can still get in a mess if .c files include the
> > per-arch file and don't include sched.h, but I forget where this happened
> > and why it broke stuff.
>
> In this case, there's only one call site and will only every be one, so
> that shouldn't be a problem. I don't see init/main.c not including
> sched.h
As long as init.c directly includes sched.h, and as long as sched.h
directly includes thread_info.h and as long as all architectures which
provide the override put it in their thread_info.h, and as long as the same
applies to all future .c users, we're good. That's a lot of "as long as"'s ;)
> > Sigh. A nice, coded-in-C implementation within each and every architecture
> > remains the best implementation, and all the little tricks-to-save-typing
> > have failure modes.
>
> Well, I started doing it in all arch, and people around here told me
> that was not a good idea , that it would be trouble if the prototype
> ever had to change (adding an arg, etc... though very unlikely to happen
> in that case, granted).
Bah. Use of grep and basic typing skills: not so hard.
> > otoh, if only one .c file will ever call this function then I think that
> > all problems are solved by
> >
> > a) moving the above ifdeffery into the .c file
> > b) adding a comment explaining which arch file must provide the override
> > c) directly including that file from within the .c file.
>
> I can definitely do that. I have no problem either way. I can add to all
> archs too, it's just that whatever way I choose, some people won't be
> happy with it :-)
>
> Anyway, I'll move the ifdeferry to init/main.c then.
Thanks ;)
I'm still wounded by my recent encounter with set_softirq_pending()
and or_softirq_pending().
^ permalink raw reply
* Re: [EFIKA] Really, don't pretend to be CHRP
From: Grant Likely @ 2008-04-14 2:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1208105558.3026.137.camel@pmac.infradead.org>
On Sun, Apr 13, 2008 at 10:52 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> Fedora 9 works on Efika without the separate 'device-tree supplement',
> thanks to the kernel's own fixups. With one exception -- because 'CHRP'
> still appears on the 'machine:' line in /proc/cpuinfo, the installer
> misdetects the platform and misconfigures yaboot, putting it into a PReP
> boot partition instead of in the /boot filesystem where the Efika's
> firmware could find it.
>
> The kernel's fixups for Efika already correct one instance of 'chrp', in
> the 'device_type' property. This fixes it in the 'CODEGEN,description'
> property too, since that's what's exposed to userspace in /proc/cpuinfo.
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Looks good to me. I don't see any reason not to pick this up.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 5ab4c84..723422e 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2240,6 +2240,14 @@ static void __init fixup_device_tree_efika(void)
> if (rv != PROM_ERROR && (strcmp(prop, "chrp") == 0))
> prom_setprop(node, "/", "device_type", "efika", sizeof("efika"));
>
> + /* CODEGEN,description is exposed in /proc/cpuinfo so
> + fix that too */
> + rv = prom_getprop(node, "CODEGEN,description", prop, sizeof(prop));
> + if (rv != PROM_ERROR && (strstr(prop, "CHRP")))
> + prom_setprop(node, "/", "CODEGEN,description",
> + "Efika 5200B PowerPC System",
> + sizeof("Efika 5200B PowerPC System"));
> +
> /* Fixup bestcomm interrupts property */
> node = call_prom("finddevice", 1, 1, ADDR("/builtin/bestcomm"));
> if (PHANDLE_VALID(node)) {
>
>
>
> --
> dwmw2
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* XPS_LL_TEMAC works correctly?
From: Mohammad Sadegh Sadri @ 2008-04-14 8:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
Hi all,
Using:
EDK 9.2.02,
Xilinx Linux 2.6.24-rc8-xlnx
XPS_LL_TEMAC version 1.00.b
I bring up the Linux kernel on ML403 -Rev04 board,
LL_TEMAC buffer size 128kbits, and set to use SG DMA
I encounter the following messages when the kernel wants to mount the root file system, as one can see the kernel has mounter the nfs root file system and init is initiated, but after that a Link carrier lost happens and it stops working.
is this behavior natural? ( the PC has attansic gigabit ethernet port with kernel 2.6.24.4 running, nfs works very well in other tests)
thanks
.............
eth0: XLlTemac: speed set to 1000Mb/s
eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4
eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
IP-Config: Complete:
device=eth0, addr=10.10.10.11, mask=255.255.255.0, gw=10.10.10.10,
host=10.10.10.11, domain=, nis-domain=(none),
bootserver=10.10.10.10, rootserver=10.10.10.10, rootpath=
Looking up port of RPC 100003/2 on 10.10.10.10
Looking up port of RPC 100005/1 on 10.10.10.10
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 88k init
eth0: XLlTemac: PHY Link carrier lost.
eth0: XLlTemac: speed set to 1000Mb/s
eth0: XLlTemac: PHY Link carrier restored.
( KERNEL STOPS WORKING HERE!!!!!!!!)
_________________________________________________________________
Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games!
http://g.msn.ca/ca55/207
[-- Attachment #2: Type: text/html, Size: 1843 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] WDT driver
From: Laurent Pinchart @ 2008-04-14 8:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sean MacLennan
In-Reply-To: <20080412141146.3050e521@lappy.seanm.ca>
[-- Attachment #1: Type: text/plain, Size: 4455 bytes --]
On Saturday 12 April 2008 20:11, Sean MacLennan wrote:
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 254d115..e73a3ea 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -697,6 +697,14 @@ config BOOKE_WDT
> Please see Documentation/watchdog/watchdog-api.txt for
> more information.
>
> +config PIKA_WDT
> + tristate "PIKA FPGA Watchdog"
> + depends on WARP
> + default y
> + help
> + This enables the watchdog in the PIKA FPGA. Currently used on
> + the Warp platform.
> +
> # PPC64 Architecture
>
> config WATCHDOG_RTAS
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f3fb170..09758c5 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -105,6 +105,7 @@ obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
> obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
> obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
> obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
> +obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
>
> # PPC64 Architecture
> obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
> diff --git a/drivers/watchdog/pika_wdt.c b/drivers/watchdog/pika_wdt.c
> new file mode 100644
> index 0000000..b84ac07
> --- /dev/null
> +++ b/drivers/watchdog/pika_wdt.c
> @@ -0,0 +1,113 @@
> +/*
> + * PIKA FPGA based Watchdog Timer
> + *
> + * Copyright (c) 2008 PIKA Technologies
> + * Sean MacLennan <smaclennan at pikatech.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/fs.h>
> +#include <linux/miscdevice.h>
> +#include <linux/reboot.h>
> +#include <linux/uaccess.h>
> +#include <linux/io.h>
> +#include <linux/of_platform.h>
> +#include <linux/watchdog.h>
> +
> +
> +static void __iomem *pikawdt_fpga;
> +
> +
> +static inline void pikawdt_ping(void)
> +{
> + unsigned reset = in_be32(pikawdt_fpga + 0x14);
> + reset |= 0xf80; /* enable with max timeout - 15 seconds */
> + out_be32(pikawdt_fpga + 0x14, reset);
What about
setbits32((u32 __iomem *)(pikawdt_fpga + 0x14), 0xf80);
> +}
> +
> +static int pikawdt_open(struct inode *inode, struct file *file)
> +{
> + printk(KERN_INFO "PIKA WDT started...\n");
> +
> + pikawdt_ping();
> +
> + return 0;
> +}
> +
> +static int pikawdt_release(struct inode *inode, struct file *file)
> +{
> + pikawdt_ping(); /* one last time */
> + return 0;
> +}
> +
> +static ssize_t pikawdt_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + pikawdt_ping();
> + return count;
> +}
> +
> +/* We support the bare minimum to be conformant. */
> +static int pikawdt_ioctl(struct inode *inode, struct file *file,
> + unsigned int cmd, unsigned long arg)
> +{
> + if (cmd == WDIOC_KEEPALIVE) {
> + pikawdt_ping();
> + return 0;
> + } else
> + return -EINVAL;
> +}
> +
> +static const struct file_operations pikawdt_fops = {
> + .owner = THIS_MODULE,
> + .open = pikawdt_open,
> + .release = pikawdt_release,
> + .write = pikawdt_write,
> + .ioctl = pikawdt_ioctl,
> +};
> +
> +static struct miscdevice pikawdt_miscdev = {
> + .minor = WATCHDOG_MINOR,
> + .name = "watchdog",
> + .fops = &pikawdt_fops,
> +};
> +
> +static int __init pikawdt_init(void)
> +{
> + struct device_node *np;
> + int ret;
> +
> + np = of_find_compatible_node(NULL, NULL, "pika,fpga");
> + if (np == NULL) {
> + printk(KERN_ERR "pikawdt: Unable to find fpga.\n");
> + return -ENOENT;
> + }
> +
> + pikawdt_fpga = of_iomap(np, 0);
> +
> + of_node_put(np);
> +
> + if (pikawdt_fpga == NULL) {
> + printk(KERN_ERR "pikawdt: Unable to map fpga.\n");
> + return -ENOENT;
> + }
> +
> + ret = misc_register(&pikawdt_miscdev);
> + if (ret) {
> + iounmap(pikawdt_fpga);
> + printk(KERN_ERR "pikawdt: Unable to register miscdev.\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +module_init(pikawdt_init);
> +
> +
> +static void __exit pikawdt_exit(void)
> +{
> + misc_deregister(&pikawdt_miscdev);
> +
> + iounmap(pikawdt_fpga);
> +}
> +module_exit(pikawdt_exit);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: XPS_LL_TEMAC works correctly?
From: Mohammad Sadegh Sadri @ 2008-04-14 9:09 UTC (permalink / raw)
To: Rami WEHBI, linuxppc-embedded
In-Reply-To: <D3C541E264C021479BFB60B3B790C0FB30A657@etoilenoire.STARWARS.local>
[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]
Rami,
Thanks for reply,
But if u study the kernel log I posted carefully, you can simply see that Kernel has mounted the root file system,
Look at this line in my prev post : VFS: Mounted root (nfs filesystem). then init has began and after that nothing more happens.
the NFS is working correctly and the folder can be mounted easily from other computers. I personally think that the problem can be with NFS or the root file system of ELDK.
I have done the same things with older versions of EDK using PLB_TEMAC and every thing has worked correctly.
Subject: RE: XPS_LL_TEMAC works correctly?
Date: Mon, 14 Apr 2008 10:31:31 +0200
From: rwehbi@wirecom-tech.com
To: mamsadegh@hotmail.com
Hi,
I would suggest that you verify that your system file is already
mounted on the host PC (where your server NFS is installed), and that the
/etc/exports file (configuration file of the nfs server) permit to your board to
mount the system file.
example of an /etc/exports file:
/opt/ml403/rootfs
192.168.206.223/24(rw,no_root_squash,sync,subtree_check)
where the ip addresse is that of nfs client,
and the path indicates where I mounted the system file.
Good
luck,
Rami
De :
linuxppc-embedded-bounces+rami.wehbi=wirecom-tech.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+rami.wehbi=wirecom-tech.com@ozlabs.org] De
la part de Mohammad Sadegh Sadri
Envoyé : lundi 14 avril 2008
10:16
À : linuxppc-embedded@ozlabs.org
Objet :
XPS_LL_TEMAC works correctly?
Hi all,
Using:
EDK 9.2.02,
Xilinx Linux
2.6.24-rc8-xlnx
XPS_LL_TEMAC version 1.00.b
I bring up the Linux
kernel on ML403 -Rev04 board,
LL_TEMAC buffer size 128kbits, and set to use
SG DMA
I encounter the following messages when the kernel wants to mount
the root file system, as one can see the kernel has mounter the nfs root file
system and init is initiated, but after that a Link carrier lost happens and it
stops working.
is this behavior natural? ( the PC has attansic gigabit
ethernet port with kernel 2.6.24.4 running, nfs works very well in other
tests)
thanks
.............
eth0: XLlTemac: speed set to
1000Mb/s
eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4
eth0:
XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
IP-Config:
Complete:
device=eth0, addr=10.10.10.11,
mask=255.255.255.0, gw=10.10.10.10,
host=10.10.10.11, domain=, nis-domain=(none),
bootserver=10.10.10.10, rootserver=10.10.10.10, rootpath=
Looking up port of
RPC 100003/2 on 10.10.10.10
Looking up port of RPC 100005/1 on
10.10.10.10
VFS: Mounted root (nfs filesystem).
Freeing unused kernel
memory: 88k init
eth0: XLlTemac: PHY Link carrier lost.
eth0: XLlTemac:
speed set to 1000Mb/s
eth0: XLlTemac: PHY Link carrier restored.
( KERNEL
STOPS WORKING HERE!!!!!!!!)
Sign in today. When you sign in to Windows Live Messenger you could win $1000 a
day until May 12th. Learn more at
SignInAndWIN.ca
_________________________________________________________________
Find hidden words, unscramble celebrity names, or try the ultimate crossword puzzle with Live Search Games. Play now!
http://g.msn.ca/ca55/212
[-- Attachment #2: Type: text/html, Size: 5355 bytes --]
^ permalink raw reply
* Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
From: Paul Mackerras @ 2008-04-14 10:04 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: kernel list, linuxppc-dev, linux-next, nacc, Andrew Morton,
Balbir Singh
In-Reply-To: <47FC5227.3030501@linux.vnet.ibm.com>
Kamalesh Babulal writes:
> The SHA1 ID of the kernel is 0e81a8ae37687845f7cdfa2adce14ea6a5f1dd34 (2.6.25-rc8)
> and the source seems to have the patch 44387e9ff25267c78a99229aca55ed750e9174c7.
>
> The kernel was patched only the patch you gave me (http://lkml.org/lkml/2008/4/8/42).
Please try again with both that patch and the one below. Once again
it won't fix the bug but will give us more information. When the oops
occurs, the kernel will print a lot of debug information that should
help locate the problem.
Paul.
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index e932b43..f16db50 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -144,6 +144,9 @@ int main(void)
DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_ptr));
DEFINE(PACA_DATA_OFFSET, offsetof(struct paca_struct, data_offset));
DEFINE(PACA_TRAP_SAVE, offsetof(struct paca_struct, trap_save));
+ DEFINE(PACASLBLOG, offsetof(struct paca_struct, slblog));
+ DEFINE(PACASLBLOGIX, offsetof(struct paca_struct, slblog_ix));
+ DEFINE(PACALASTSLB, offsetof(struct paca_struct, last_slb));
DEFINE(SLBSHADOW_STACKVSID,
offsetof(struct slb_shadow, save_area[SLB_NUM_BOLTED - 1].vsid));
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 148a354..663df17 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -419,6 +419,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_1T_SEGMENT)
slbmte r7,r0
isync
+ ld r4,PACASLBLOGIX(r13)
+ addi r4,r4,1
+ clrldi r4,r4,64-6
+ std r4,PACASLBLOGIX(r13)
+ add r4,r4,r13
+ addi r4,r4,PACASLBLOG
+ li r5,4
+ std r5,0(r4)
+ mftb r5
+ std r5,8(r4)
+ std r6,16(r4)
+ std r0,24(r4)
2:
clrrdi r7,r8,THREAD_SHIFT /* base of new stack */
/* Note: this uses SWITCH_FRAME_SIZE rather than INT_FRAME_SIZE
@@ -533,6 +545,17 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
stdcx. r0,0,r1 /* to clear the reservation */
+ li r4,0
+ slbmfee r2,r4
+ std r2,PACALASTSLB(r13)
+ slbmfev r2,r4
+ std r2,PACALASTSLB+8(r13)
+ li r4,1
+ slbmfee r2,r4
+ std r2,PACALASTSLB+16(r13)
+ slbmfev r2,r4
+ std r2,PACALASTSLB+24(r13)
+
/*
* Clear RI before restoring r13. If we are returning to
* userspace and we take an exception after restoring r13,
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 4b5b7ff..c918f33 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1141,6 +1141,40 @@ void SPEFloatingPointException(struct pt_regs *regs)
}
#endif
+static void dump_unrecov_slb(void)
+{
+#ifdef CONFIG_PPC64
+ long entry, rstart;
+ unsigned long esid, vsid;
+
+ printk(KERN_EMERG "SLB contents now:\n");
+ for (entry = 0; entry < 64; ++entry) {
+ asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (entry));
+ if (esid == 0)
+ /* valid bit is clear along with everything else */
+ continue;
+ asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (entry));
+ printk(KERN_EMERG "%d: %.16lx %.16lx\n", entry, esid, vsid);
+ }
+
+ printk(KERN_EMERG "SLB 0-1 at last exception exit:\n");
+ printk(KERN_EMERG "0: %.16lx %.16lx\n", get_paca()->last_slb[0][0],
+ get_paca()->last_slb[0][1]);
+ printk(KERN_EMERG "1: %.16lx %.16lx\n", get_paca()->last_slb[1][0],
+ get_paca()->last_slb[1][1]);
+ printk(KERN_EMERG "SLB update log:\n");
+ rstart = entry = get_paca()->slblog_ix;
+ do {
+ printk(KERN_EMERG "%d: %lx %lx %.16lx %.16lx\n", entry,
+ get_paca()->slblog[entry][0],
+ get_paca()->slblog[entry][1],
+ get_paca()->slblog[entry][2],
+ get_paca()->slblog[entry][3]);
+ entry = (entry + 1) % 63;
+ } while (entry != rstart);
+#endif
+}
+
/*
* We enter here if we get an unrecoverable exception, that is, one
* that happened at a point where the RI (recoverable interrupt) bit
@@ -1151,6 +1185,8 @@ void unrecoverable_exception(struct pt_regs *regs)
{
printk(KERN_EMERG "Unrecoverable exception %lx at %lx\n",
regs->trap, regs->nip);
+ if (regs->trap == 0x4100)
+ dump_unrecov_slb();
die("Unrecoverable exception", regs, SIGABRT);
}
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 906daed..235edf7 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -105,6 +105,7 @@ void slb_flush_and_rebolt(void)
* appropriately too. */
unsigned long linear_llp, vmalloc_llp, lflags, vflags;
unsigned long ksp_esid_data, ksp_vsid_data;
+ long logix;
WARN_ON(!irqs_disabled());
@@ -144,6 +145,13 @@ void slb_flush_and_rebolt(void)
"r"(ksp_vsid_data),
"r"(ksp_esid_data)
: "memory");
+ logix = get_paca()->slblog_ix;
+ logix = (logix + 1) & 63;
+ get_paca()->slblog_ix = logix;
+ get_paca()->slblog[logix][0] = 3;
+ get_paca()->slblog[logix][1] = mftb();
+ get_paca()->slblog[logix][2] = ksp_esid_data;
+ get_paca()->slblog[logix][3] = ksp_vsid_data;
}
void slb_vmalloc_update(void)
@@ -192,6 +200,7 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
unsigned long pc = KSTK_EIP(tsk);
unsigned long stack = KSTK_ESP(tsk);
unsigned long unmapped_base;
+ long logix;
if (!cpu_has_feature(CPU_FTR_NO_SLBIE_B) &&
offset <= SLB_CACHE_ENTRIES) {
@@ -204,6 +213,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
<< SLBIE_SSIZE_SHIFT;
slbie_data |= SLBIE_C; /* C set for user addresses */
asm volatile("slbie %0" : : "r" (slbie_data));
+
+ logix = get_paca()->slblog_ix;
+ logix = (logix + 1) & 63;
+ get_paca()->slblog_ix = logix;
+ get_paca()->slblog[logix][0] = 2;
+ get_paca()->slblog[logix][1] = mftb();
+ get_paca()->slblog[logix][2] = slbie_data;
+ get_paca()->slblog[logix][3] = 0;
}
asm volatile("isync" : : : "memory");
} else {
diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
index 657f6b3..8c7ce20 100644
--- a/arch/powerpc/mm/slb_low.S
+++ b/arch/powerpc/mm/slb_low.S
@@ -249,6 +249,20 @@ _GLOBAL(slb_compare_rr_to_size)
*/
slbmte r11,r10
+ ld r3,PACASLBLOGIX(r13)
+ addi r3,r3,1
+ clrldi r3,r3,64-6
+ std r3,PACASLBLOGIX(r13)
+ sldi r3,r3,5
+ add r3,r3,r13
+ addi r3,r3,PACASLBLOG
+ li r9,1
+ std r9,0(r3)
+ mftb r9
+ std r9,8(r3)
+ std r11,16(r3)
+ std r10,24(r3)
+
/* we're done for kernel addresses */
crclr 4*cr0+eq /* set result to "success" */
bgelr cr7
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index a1ab25c..959ef26 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -325,6 +325,8 @@ static int recover_mce(struct pt_regs *regs, struct rtas_error_log * err)
if (err->disposition == RTAS_DISP_FULLY_RECOVERED) {
/* Platform corrected itself */
+ printk(KERN_ERR "FWNMI: platform corrected error %.16lx\n",
+ *(unsigned long *)err);
nonfatal = 1;
} else if ((regs->msr & MSR_RI) &&
user_mode(regs) &&
diff --git a/include/asm-powerpc/paca.h b/include/asm-powerpc/paca.h
index 748b35a..6280b82 100644
--- a/include/asm-powerpc/paca.h
+++ b/include/asm-powerpc/paca.h
@@ -115,6 +115,11 @@ struct paca_struct {
u64 system_time; /* accumulated system TB ticks */
u64 startpurr; /* PURR/TB value snapshot */
u64 startspurr; /* SPURR value snapshot */
+
+ /* SLB update log */
+ long slblog_ix;
+ u64 slblog[64][4];
+ u64 last_slb[2][2];
};
extern struct paca_struct paca[];
^ permalink raw reply related
* Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
From: Kamalesh Babulal @ 2008-04-14 13:28 UTC (permalink / raw)
To: Paul Mackerras
Cc: kernel list, linuxppc-dev, linux-next, nacc, Andrew Morton,
Balbir Singh
In-Reply-To: <18435.11286.201115.396713@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>> The SHA1 ID of the kernel is 0e81a8ae37687845f7cdfa2adce14ea6a5f1dd34 (2.6.25-rc8)
>> and the source seems to have the patch 44387e9ff25267c78a99229aca55ed750e9174c7.
>>
>> The kernel was patched only the patch you gave me (http://lkml.org/lkml/2008/4/8/42).
>
> Please try again with both that patch and the one below. Once again
> it won't fix the bug but will give us more information. When the oops
> occurs, the kernel will print a lot of debug information that should
> help locate the problem.
>
> Paul.
>
> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
> index e932b43..f16db50 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -144,6 +144,9 @@ int main(void)
> DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_ptr));
> DEFINE(PACA_DATA_OFFSET, offsetof(struct paca_struct, data_offset));
> DEFINE(PACA_TRAP_SAVE, offsetof(struct paca_struct, trap_save));
> + DEFINE(PACASLBLOG, offsetof(struct paca_struct, slblog));
> + DEFINE(PACASLBLOGIX, offsetof(struct paca_struct, slblog_ix));
> + DEFINE(PACALASTSLB, offsetof(struct paca_struct, last_slb));
>
> DEFINE(SLBSHADOW_STACKVSID,
> offsetof(struct slb_shadow, save_area[SLB_NUM_BOLTED - 1].vsid));
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 148a354..663df17 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -419,6 +419,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_1T_SEGMENT)
> slbmte r7,r0
> isync
>
> + ld r4,PACASLBLOGIX(r13)
> + addi r4,r4,1
> + clrldi r4,r4,64-6
> + std r4,PACASLBLOGIX(r13)
> + add r4,r4,r13
> + addi r4,r4,PACASLBLOG
> + li r5,4
> + std r5,0(r4)
> + mftb r5
> + std r5,8(r4)
> + std r6,16(r4)
> + std r0,24(r4)
> 2:
> clrrdi r7,r8,THREAD_SHIFT /* base of new stack */
> /* Note: this uses SWITCH_FRAME_SIZE rather than INT_FRAME_SIZE
> @@ -533,6 +545,17 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
>
> stdcx. r0,0,r1 /* to clear the reservation */
>
> + li r4,0
> + slbmfee r2,r4
> + std r2,PACALASTSLB(r13)
> + slbmfev r2,r4
> + std r2,PACALASTSLB+8(r13)
> + li r4,1
> + slbmfee r2,r4
> + std r2,PACALASTSLB+16(r13)
> + slbmfev r2,r4
> + std r2,PACALASTSLB+24(r13)
> +
> /*
> * Clear RI before restoring r13. If we are returning to
> * userspace and we take an exception after restoring r13,
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 4b5b7ff..c918f33 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -1141,6 +1141,40 @@ void SPEFloatingPointException(struct pt_regs *regs)
> }
> #endif
>
> +static void dump_unrecov_slb(void)
> +{
> +#ifdef CONFIG_PPC64
> + long entry, rstart;
> + unsigned long esid, vsid;
> +
> + printk(KERN_EMERG "SLB contents now:\n");
> + for (entry = 0; entry < 64; ++entry) {
> + asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (entry));
> + if (esid == 0)
> + /* valid bit is clear along with everything else */
> + continue;
> + asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (entry));
> + printk(KERN_EMERG "%d: %.16lx %.16lx\n", entry, esid, vsid);
> + }
> +
> + printk(KERN_EMERG "SLB 0-1 at last exception exit:\n");
> + printk(KERN_EMERG "0: %.16lx %.16lx\n", get_paca()->last_slb[0][0],
> + get_paca()->last_slb[0][1]);
> + printk(KERN_EMERG "1: %.16lx %.16lx\n", get_paca()->last_slb[1][0],
> + get_paca()->last_slb[1][1]);
> + printk(KERN_EMERG "SLB update log:\n");
> + rstart = entry = get_paca()->slblog_ix;
> + do {
> + printk(KERN_EMERG "%d: %lx %lx %.16lx %.16lx\n", entry,
> + get_paca()->slblog[entry][0],
> + get_paca()->slblog[entry][1],
> + get_paca()->slblog[entry][2],
> + get_paca()->slblog[entry][3]);
> + entry = (entry + 1) % 63;
> + } while (entry != rstart);
> +#endif
> +}
> +
> /*
> * We enter here if we get an unrecoverable exception, that is, one
> * that happened at a point where the RI (recoverable interrupt) bit
> @@ -1151,6 +1185,8 @@ void unrecoverable_exception(struct pt_regs *regs)
> {
> printk(KERN_EMERG "Unrecoverable exception %lx at %lx\n",
> regs->trap, regs->nip);
> + if (regs->trap == 0x4100)
> + dump_unrecov_slb();
> die("Unrecoverable exception", regs, SIGABRT);
> }
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index 906daed..235edf7 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -105,6 +105,7 @@ void slb_flush_and_rebolt(void)
> * appropriately too. */
> unsigned long linear_llp, vmalloc_llp, lflags, vflags;
> unsigned long ksp_esid_data, ksp_vsid_data;
> + long logix;
>
> WARN_ON(!irqs_disabled());
>
> @@ -144,6 +145,13 @@ void slb_flush_and_rebolt(void)
> "r"(ksp_vsid_data),
> "r"(ksp_esid_data)
> : "memory");
> + logix = get_paca()->slblog_ix;
> + logix = (logix + 1) & 63;
> + get_paca()->slblog_ix = logix;
> + get_paca()->slblog[logix][0] = 3;
> + get_paca()->slblog[logix][1] = mftb();
> + get_paca()->slblog[logix][2] = ksp_esid_data;
> + get_paca()->slblog[logix][3] = ksp_vsid_data;
> }
>
> void slb_vmalloc_update(void)
> @@ -192,6 +200,7 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> unsigned long pc = KSTK_EIP(tsk);
> unsigned long stack = KSTK_ESP(tsk);
> unsigned long unmapped_base;
> + long logix;
>
> if (!cpu_has_feature(CPU_FTR_NO_SLBIE_B) &&
> offset <= SLB_CACHE_ENTRIES) {
> @@ -204,6 +213,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> << SLBIE_SSIZE_SHIFT;
> slbie_data |= SLBIE_C; /* C set for user addresses */
> asm volatile("slbie %0" : : "r" (slbie_data));
> +
> + logix = get_paca()->slblog_ix;
> + logix = (logix + 1) & 63;
> + get_paca()->slblog_ix = logix;
> + get_paca()->slblog[logix][0] = 2;
> + get_paca()->slblog[logix][1] = mftb();
> + get_paca()->slblog[logix][2] = slbie_data;
> + get_paca()->slblog[logix][3] = 0;
> }
> asm volatile("isync" : : : "memory");
> } else {
> diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
> index 657f6b3..8c7ce20 100644
> --- a/arch/powerpc/mm/slb_low.S
> +++ b/arch/powerpc/mm/slb_low.S
> @@ -249,6 +249,20 @@ _GLOBAL(slb_compare_rr_to_size)
> */
> slbmte r11,r10
>
> + ld r3,PACASLBLOGIX(r13)
> + addi r3,r3,1
> + clrldi r3,r3,64-6
> + std r3,PACASLBLOGIX(r13)
> + sldi r3,r3,5
> + add r3,r3,r13
> + addi r3,r3,PACASLBLOG
> + li r9,1
> + std r9,0(r3)
> + mftb r9
> + std r9,8(r3)
> + std r11,16(r3)
> + std r10,24(r3)
> +
> /* we're done for kernel addresses */
> crclr 4*cr0+eq /* set result to "success" */
> bgelr cr7
> diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
> index a1ab25c..959ef26 100644
> --- a/arch/powerpc/platforms/pseries/ras.c
> +++ b/arch/powerpc/platforms/pseries/ras.c
> @@ -325,6 +325,8 @@ static int recover_mce(struct pt_regs *regs, struct rtas_error_log * err)
>
> if (err->disposition == RTAS_DISP_FULLY_RECOVERED) {
> /* Platform corrected itself */
> + printk(KERN_ERR "FWNMI: platform corrected error %.16lx\n",
> + *(unsigned long *)err);
> nonfatal = 1;
> } else if ((regs->msr & MSR_RI) &&
> user_mode(regs) &&
> diff --git a/include/asm-powerpc/paca.h b/include/asm-powerpc/paca.h
> index 748b35a..6280b82 100644
> --- a/include/asm-powerpc/paca.h
> +++ b/include/asm-powerpc/paca.h
> @@ -115,6 +115,11 @@ struct paca_struct {
> u64 system_time; /* accumulated system TB ticks */
> u64 startpurr; /* PURR/TB value snapshot */
> u64 startspurr; /* SPURR value snapshot */
> +
> + /* SLB update log */
> + long slblog_ix;
> + u64 slblog[64][4];
> + u64 last_slb[2][2];
> };
>
> extern struct paca_struct paca[];
Hi Paul,
After applying the patch above and the patch posted on http://lkml.org/lkml/2008/4/8/42
the bug had the following information,
Unrecoverable exception 4100 at c000000000008d4c
SLB contents now:
0: c000000008000000 0000408f92c94500
1: d000000008000000 0000f09b89af5400
2: c000000020000000 0000420e6f8ca500
3: 0000000010000000 0000947fa10bac80
4: 00000000f0000000 00009ef7aa634c80
5: 0000000040000000 000096bdec30bc80
8: 00000000f0000000 00002292895c1c80
9: 0000000040000000 00001a58cb298c80
10: 0000000010000000 0000181a80047c80
12: 00000000f0000000 0000273e59afdc80
13: 0000000040000000 00001f049b7d4c80
14: 0000000010000000 00001cc650583c80
16: 00000000f0000000 00007bbb0a7b3c80
17: 0000000040000000 000073814c48ac80
18: 0000000010000000 0000714301239c80
20: 00000000f0000000 00009ef7aa634c80
21: 0000000040000000 000096bdec30bc80
22: 0000000010000000 0000947fa10bac80
23: c000000718000000 0000950f4be7f500
24: c000000728000000 000095ceba49a500
25: cf00000008000000 0000d59aca40f500
26: 0000000018000000 00004e06613b8c80
27: 00000000f8000000 0000587e6a932c80
28: 0000000048000000 00005044ac609c80
29: c000000778000000 0000998be2321500
30: 00000000f0000000 000008ad8a1b8c80
31: 0000000040000000 00000073cbe8fc80
32: 0000000010000000 0000fe3580c3dc80
33: c000000028000000 0000420e6f8ca500
34: c000000758000000 0000980d056eb500
36: 00000000f0000000 00007bbb0a7b3c80
37: 0000000040000000 000073814c48ac80
38: 0000000010000000 0000714301239c80
39: c000000038000000 000042cdddee5500
40: c000000768000000 000098cc73d06500
41: c000000738000000 0000968e28ab5500
43: 00000000f0000000 000095a009bbcc80
44: 0000000040000000 00008d664b893c80
45: 0000000010000000 00008b2800642c80
47: 00000000f0000000 00009ef7aa634c80
48: 0000000040000000 000096bdec30bc80
49: 0000000010000000 0000947fa10bac80
51: 00000000f0000000 00007bbb0a7b3c80
52: 0000000040000000 000073814c48ac80
53: cf00000018000000 0000d65a38a2a500
54: 0000000010000000 0000714301239c80
55: c000000748000000 0000974d970d0500
57: 00000000f0000000 00009ef7aa634c80
58: 0000000040000000 000096bdec30bc80
59: 0000000010000000 0000947fa10bac80
61: 00000000f0000000 0000f5fe48cc7c80
62: 0000000040000000 0000edc48a99ec80
63: 0000000010000000 0000eb863f74dc80
SLB 0-1 at last exception exit:
0: c000000008000000 0000408f92c94500
1: d000000008000000 0000f09b89af5400
SLB update log:
4: 1 1fa087dccefc17 0000998be2321500 c00000077800001d
5: 2 1fa087dbeb2091 0000000018000000 0000000000000000
6: 1 1fa087dbeb20ac 000093c032a9fc80 0000000008000038
7: 1 1fa087dbeb20bd 00009ef7aa634c80 00000000f8000039
8: 1 1fa087dbeb20d1 000096bdec30bc80 000000004800003a
9: 1 1fa087dbeb37d5 0000947fa10bac80 000000001800003b
10: 2 1fa087dc26370a 0000000008000000 0000000000000000
11: 2 1fa087dc26370f 00000000f8000000 0000000000000000
12: 2 1fa087dc26372f 0000000048000000 0000000000000000
13: 2 1fa087dc263734 0000000018000000 0000000000000000
14: 1 1fa087dc26375f 0000eac6d1132c80 000000000800003c
15: 1 1fa087dc263772 0000f5fe48cc7c80 00000000f800003d
16: 1 1fa087dc263787 0000edc48a99ec80 000000004800003e
17: 1 1fa087dc263bc6 0000eb863f74dc80 000000001800003f
18: 2 1fa087dc264698 0000000008000000 0000000000000000
19: 2 1fa087dc26469e 00000000f8000000 0000000000000000
20: 2 1fa087dc2646a3 0000000048000000 0000000000000000
21: 2 1fa087dc2646a8 0000000018000000 0000000000000000
22: 1 1fa087dc2646be 0000947fa10bac80 0000000018000003
23: 1 1fa087dc2646cd 00009ef7aa634c80 00000000f8000004
24: 1 1fa087dc2646e2 000096bdec30bc80 0000000048000005
25: 1 1fa087dc264829 000093c032a9fc80 0000000008000006
26: 2 1fa087dc7695e9 0000000018000000 0000000000000000
27: 2 1fa087dc7695ee 00000000f8000000 0000000000000000
28: 2 1fa087dc7695f6 0000000048000000 0000000000000000
29: 2 1fa087dc7695fc 0000000008000000 0000000000000000
30: 1 1fa087dc769623 0000175b11a2cc80 0000000008000007
31: 1 1fa087dc769636 00002292895c1c80 00000000f8000008
32: 1 1fa087dc76964b 00001a58cb298c80 0000000048000009
33: 1 1fa087dc76a03d 0000181a80047c80 000000001800000a
34: 2 1fa087dc7840e0 0000000008000000 0000000000000000
35: 2 1fa087dc7840e5 00000000f8000000 0000000000000000
36: 2 1fa087dc784103 0000000048000000 0000000000000000
37: 2 1fa087dc784108 0000000018000000 0000000000000000
38: 1 1fa087dc784134 00001c06e1f68c80 000000000800000b
39: 1 1fa087dc784145 0000273e59afdc80 00000000f800000c
40: 1 1fa087dc78415a 00001f049b7d4c80 000000004800000d
41: 1 1fa087dc78542a 00001cc650583c80 000000001800000e
42: 2 1fa087dc84f844 0000000008000000 0000000000000000
43: 2 1fa087dc84f849 00000000f8000000 0000000000000000
44: 2 1fa087dc84f869 0000000048000000 0000000000000000
45: 2 1fa087dc84f86e 0000000018000000 0000000000000000
46: 1 1fa087dc84f891 0000708392c1ec80 000000000800000f
47: 1 1fa087dc84f8a5 00007bbb0a7b3c80 00000000f8000010
48: 1 1fa087dc84f8c3 000073814c48ac80 0000000048000011
49: 1 1fa087dc84fb2a 0000714301239c80 0000000018000012
50: 2 1fa087dc851369 0000000008000000 0000000000000000
51: 2 1fa087dc85136f 00000000f8000000 0000000000000000
52: 2 1fa087dc851374 0000000048000000 0000000000000000
53: 2 1fa087dc851379 0000000018000000 0000000000000000
54: 1 1fa087dc8513a2 000093c032a9fc80 0000000008000013
55: 1 1fa087dc8513b5 00009ef7aa634c80 00000000f8000014
56: 1 1fa087dc8513c5 000096bdec30bc80 0000000048000015
57: 1 1fa087dc85158f 0000947fa10bac80 0000000018000016
58: 1 1fa087dc858603 0000950f4be7f500 c000000718000017
59: 1 1fa087dc85aa02 000095ceba49a500 c000000728000018
60: 1 1fa087dcb5b5ea 0000d59aca40f500 cf00000008000019
61: 2 1fa087dccefa5a 0000000008000000 0000000000000000
62: 2 1fa087dccefa5f 00000000f8000000 0000000000000000
0: 2 1fa087dccefa69 0000000018000000 0000000000000000
1: 1 1fa087dccefa8f 00004e06613b8c80 000000001800001a
2: 1 1fa087dccefaa4 0000587e6a932c80 00000000f800001b
3: 1 1fa087dccefac6 00005044ac609c80 000000004800001c
Oops: Unrecoverable exception, sig: 6 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in:
NIP: c000000000008d4c LR: 00000000102e9790 CTR: 00000000102686c0
REGS: c00000077304fbb0 TRAP: 4100 Not tainted (2.6.25-rc8-autotest)
MSR: 8000000000001030 <ME,IR,DR> CR: 28002488 XER: 20000000
TASK = c000000774bb3200[9954] 'cc1' THREAD: c00000077304c000 CPU: 1
GPR00: 0000000000004000 c00000077304fe30 00000000102e929c 000000000000d032
GPR04: 00000000000000bc 0000000000000000 0000000000000000 0000000000000000
GPR08: 0000000000000037 0000000010440000 00000000f765d1c0 00000000f765c240
GPR12: 0000000048002488 00000000105ba630 0000000010030000 0000000010030000
GPR16: 00000000105b0000 00000000105b0000 0000000010440000 00000000ff9d92d8
GPR20: 000000001043b8f4 00000000102686c0 00000000ff9d91d8 0000000000000000
GPR24: 0000000000000000 0000000010071140 0000000000000000 0000000000000000
GPR28: 00000000105b39bc 00000000f765c530 00000000f7653770 00000000f764fbe0
NIP [c000000000008d4c] restore+0xcc/0xe8
LR [00000000102e9790] 0x102e9790
Call Trace:
[c00000077304fe30] [c000000000008d7c] do_work+0x14/0x2c (unreliable)
Instruction dump:
e88d01f0 f84d01f0 7c841050 e84d01e8 7c422214 f84d01e8 e9a100d8 7c7b03a6
e84101a0 7c4ff120 e8410170 7c5a03a6 <e8010070> e8410080 e8610088 e8810090
---[ end trace 1d1912fbf2b044ad ]---
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
From: Timur Tabi @ 2008-04-14 13:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel, Jiri Slaby, York Sun
In-Reply-To: <20080411221817.0b1eb414.akpm@linux-foundation.org>
Andrew Morton wrote:
> Thanks. I've made a note that this patch has outstanding issues. Usually
> this means that I'll defer merging it until they have been addressed:
> either by fixing them or by successfully arguing against the objections.
Sorry, I must have gotten out of sync. What are the outstanding issues? I was
under the impression that the latest patch (v5) resolved everything. In fact,
the last email from you (dated 4/1) said that you picked it up, minus the defconfig.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
From: Jiri Slaby @ 2008-04-14 13:43 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Andrew Morton, York Sun, linux-kernel
In-Reply-To: <48035E93.6070300@freescale.com>
On 04/14/2008 03:39 PM, Timur Tabi wrote:
> Andrew Morton wrote:
>
>> Thanks. I've made a note that this patch has outstanding issues. Usually
>> this means that I'll defer merging it until they have been addressed:
>> either by fixing them or by successfully arguing against the objections.
>
> Sorry, I must have gotten out of sync. What are the outstanding issues? I was
> under the impression that the latest patch (v5) resolved everything. In fact,
> the last email from you (dated 4/1) said that you picked it up, minus the defconfig.
See
http://lkml.org/lkml/2008/3/12/375
^ permalink raw reply
* Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
From: Timur Tabi @ 2008-04-14 13:45 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linuxppc-dev, Andrew Morton, York Sun, linux-kernel
In-Reply-To: <48035F98.1020404@gmail.com>
Jiri Slaby wrote:
> See
> http://lkml.org/lkml/2008/3/12/375
That email is dated 3/12 and those comments are about v1 of the patch. The most
recent posted version is v5 and it addresses all these issues. See
http://lkml.org/lkml/2008/4/1/346
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
From: Jiri Slaby @ 2008-04-14 13:54 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Andrew Morton, York Sun, linux-kernel
In-Reply-To: <48036001.10905@freescale.com>
On 04/14/2008 03:45 PM, Timur Tabi wrote:
> Jiri Slaby wrote:
>
>> See
>> http://lkml.org/lkml/2008/3/12/375
>
> That email is dated 3/12 and those comments are about v1 of the patch. The most
> recent posted version is v5 and it addresses all these issues. See
> http://lkml.org/lkml/2008/4/1/346
Ok, how is the sleep-inside-spinlock in fsl_diu_open resolved? rh_alloc might
sleep if I still see correctly, do I?
^ permalink raw reply
* Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
From: Timur Tabi @ 2008-04-14 14:12 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linuxppc-dev, Andrew Morton, York Sun, linux-kernel
In-Reply-To: <4803620C.6020905@gmail.com>
Jiri Slaby wrote:
> On 04/14/2008 03:45 PM, Timur Tabi wrote:
>> Jiri Slaby wrote:
>>
>>> See
>>> http://lkml.org/lkml/2008/3/12/375
>> That email is dated 3/12 and those comments are about v1 of the patch. The most
>> recent posted version is v5 and it addresses all these issues. See
>> http://lkml.org/lkml/2008/4/1/346
>
> Ok, how is the sleep-inside-spinlock in fsl_diu_open resolved? rh_alloc might
> sleep if I still see correctly, do I?
Hmmm... I thought I had an answer to this question, but I checked the patch
again, and it looks like this particular issue hasn't been fixed. rh_alloc can
still sleep. I know we worked on fixing this bug, so I'm not sure why it's
still there.
However, we don't need to call rh_alloc(). The arch/powerpc code has been
updated to remove the need for us to a use an rheap.
Unfortunately, the author of the patch, York, is out this week, so I'll have to
take care of this. It'd be easier to modify rh_alloc() so that it doesn't
sleep, so that's what I'm going to do.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] Add DIU platform code for MPC8610HPCD
From: Arnd Bergmann @ 2008-04-14 14:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: York Sun, linux-kernel
In-Reply-To: <12053582232536-git-send-email-yorksun@freescale.com>
On Wednesday 12 March 2008, York Sun wrote:
> +#include <linux/bootmem.h>
> +#include <asm/rheap.h>
> +
> +#undef DEBUG
> +#ifdef DEBUG
> +#define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, __func__, ## args)
> +#else
> +#define DPRINTK(fmt, args...)
> +#endif
Please don't define your own debug macros, but rather use pr_debug and related
helpers from linux/kernel.h.
> +static unsigned char *pixis_bdcfg0, *pixis_arch;
> +
These need to be __iomem, as far as I can see. Please run 'make C=1'
to have this kind of problem checked by 'sparse' and clean up its
findings.
> @@ -161,12 +173,251 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5229, quirk_uli5229);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AL, 0x5288, final_uli5288);
> #endif /* CONFIG_PCI */
>
> +static u32 get_busfreq(void)
> +{
> + struct device_node *node;
> +
> + u32 fs_busfreq = 0;
> + node = of_find_node_by_type(NULL, "cpu");
> + if (node) {
> + unsigned int size;
> + const unsigned int *prop =
> + of_get_property(node, "bus-frequency", &size);
> + if (prop)
> + fs_busfreq = *prop;
> + of_node_put(node);
> + };
> + return fs_busfreq;
> +}
I guess this breaks for frequencies larger than 2^32 Ghz, right?
IIRC, there is a method for encoding higher frequencies in the device
tree, and you should probably support that, or even better, refer
to some other function that is already interpreting it.
> +#ifdef CONFIG_FB_FSL_DIU
> +
> +static rh_block_t diu_rh_block[16];
> +static rh_info_t diu_rh_info;
> +static unsigned long diu_size = 1280 * 1024 * 4; /* One 1280x1024 buffer */
> +static void *diu_mem;
diu_mem is probably __iomem as well, right?
Also, it would be cleaner to have the variables in a data structure
pointed to by your device->driver_data. It would only be strictly
necessary if you expect to see a system with multiple DIU instances,
which I think is unlikely, but still it is the way that people
expect to see the code when they read it.
> +unsigned int platform_get_pixel_format
> + (unsigned int bits_per_pixel, int monitor_port)
> +{
> + static const unsigned long pixelformat[][3] = {
> + {0x88882317, 0x88083218, 0x65052119},
> + {0x88883316, 0x88082219, 0x65053118},
> + };
> + unsigned int pix_fmt, arch_monitor;
> +
> + arch_monitor = ((*pixis_arch == 0x01) && (monitor_port == 0))? 0 : 1;
> + /* DVI port for board version 0x01 */
> +
> + if (bits_per_pixel == 32)
> + pix_fmt = pixelformat[arch_monitor][0];
> + else if (bits_per_pixel == 24)
> + pix_fmt = pixelformat[arch_monitor][1];
> + else if (bits_per_pixel == 16)
> + pix_fmt = pixelformat[arch_monitor][2];
> + else
> + pix_fmt = pixelformat[1][0];
> +
> + return pix_fmt;
> +}
> +EXPORT_SYMBOL(platform_get_pixel_format);
Generally, when you create new functions that are going to be used
just by your own code, they should be EXPORT_SYMBOL_GPL. It's your
choice though, as you are the author.
> +void platform_set_pixel_clock(unsigned int pixclock)
> +{
> + u32 __iomem *clkdvdr;
> + u32 temp;
> + /* variables for pixel clock calcs */
> + ulong bestval, bestfreq, speed_ccb, minpixclock, maxpixclock;
> + ulong pixval;
> + long err;
> + int i;
> +
> + clkdvdr = ioremap(get_immrbase() + 0xe0800, sizeof(u32));
Please don't use get_immrbase in new code. Instead, register an
of_platform_driver for the device in the device tree, then
use of_iomap to map its register from the driver probe() callback.
> +void *fsl_diu_alloc(unsigned long size, unsigned long *phys)
> +{
> + void *virt;
> +
> + DPRINTK("size=%lu\n", size);
> +
> + virt = dma_alloc_coherent(0, size, phys, GFP_DMA | GFP_KERNEL);
> +
> + if (virt) {
> + DPRINTK("dma virt=%p phys=%lx\n", virt, *phys);
> + return virt;
> + }
> +
> + if (!diu_mem) {
> + printk(KERN_INFO "%s: no diu_mem\n", __func__);
> + return NULL;
> + }
> +
> + virt = rh_alloc(&diu_rh_info, size, "DIU");
> + if (virt)
> + *phys = virt_to_bus(virt);
> +
> + DPRINTK("rh virt=%p phys=%x\n", virt, *phys);
> +
> + return virt;
> +}
> +EXPORT_SYMBOL(fsl_diu_alloc);
Don't use virt_to_bus in new code, it does not work with the DMA
mapping API. Instead, use dma_map_single() to convert the kernel address
into something that can be addressed by hardware.
You probably don't need the dma_alloc_coherent path in that case,
but always use dma_map_single on a newly allocated piece of kernel
memory.
Arnd <><
^ permalink raw reply
* [2.6 patch] powerpc/sysdev/rtc_cmos_setup.c: add MODULE_LICENSE
From: Adrian Bunk @ 2008-04-14 14:19 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
This patch adds the missing MODULE_LICENSE("GPL").
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
6f9e3869ba8122adefb706c7d5c18cf4b2dc65c9 diff --git a/arch/powerpc/sysdev/rtc_cmos_setup.c b/arch/powerpc/sysdev/rtc_cmos_setup.c
index 0c9ac7e..c09ddc0 100644
--- a/arch/powerpc/sysdev/rtc_cmos_setup.c
+++ b/arch/powerpc/sysdev/rtc_cmos_setup.c
@@ -56,3 +56,5 @@ static int __init add_rtc(void)
return 0;
}
fs_initcall(add_rtc);
+
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
From: Jiri Slaby @ 2008-04-14 14:24 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Andrew Morton, York Sun, linux-kernel
In-Reply-To: <48036649.6000409@freescale.com>
On 04/14/2008 04:12 PM, Timur Tabi wrote:
> Unfortunately, the author of the patch, York, is out this week, so I'll have to
> take care of this. It'd be easier to modify rh_alloc() so that it doesn't
> sleep, so that's what I'm going to do.
Anyway, why do you need the spin lock there (and not mutex)? As I think you are
still trying to avoid the problem instead of fixing it. Removing GFP_WAIT
(fsl_diu_alloc) doesn't seem to me as mm friendly solution, especially if you
allocate that much memory and you can sleep. But I might be wrong, you may need
the spinlock...
^ permalink raw reply
* Re: [PATCH] FCC: fix confused base / offset
From: Sascha Hauer @ 2008-04-14 14:47 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47FE4268.2000504@freescale.com>
On Thu, Apr 10, 2008 at 11:38:00AM -0500, Scott Wood wrote:
Hi Scott,
Thank you for your help so far
> Sascha Hauer wrote:
>> See bottom of this mail. The board really is a 8260 based board. Our
>> bootloader does not fill in the clock values, so they are hardcoded. I'm
>> not very sure about the muram entries because the dpram is organized
>> slightly different on the 8260. It has some dedicated FCC space and I
>> don't know how to properly encode this in the device tree.
>
> I think the FCC space should just be left out.
The old binding used the dpram offset 0xb080 for fcc2 while the new
binding uses cpm_dpalloc which returns 0x80. When I use the old binding
and change the hardcoded value from 0xb080 to 0x80 the fcc stopped
working. I then hardcoded the value for the new binding to the same
value as the old binding used, 0xb080, but no success.
>
>>> Does the PHY negotiate OK?
>>
>> Well I put some printks into the phy_read/write functions so I can say
>> that it at least properly talks to the phy.
>
> Do you get a console message indicating that the link came up?
No, but I didn't get a message for the old binding, too.
I changed the device tree as you suggested, but still no success.
BTW there is one thing I forgot to mention which could throw some light
into this. This commit broke the FCC driver for me although it does the
right thing:
commit c6565331b7162a8348c70c37b4c33bedb6d4f02d
Author: Scott Wood <scottwood@freescale.com>
Date: Mon Oct 1 14:20:50 2007 -0500
fs_enet: mac-fcc: Eliminate __fcc-* macros.
These macros accomplish nothing other than defeating type checking.
This patch also fixes one instance of the wrong register size being
used that was revealed by enabling type checking.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
It fixes an access to the ftodr register in tx_kickstart(). After ftodr
access the next console message is truncated and my bdi2000 shows me that
the processor doesn't get out of cpm_uart_console_write(). Something
strange is going on here...
Sascha
--
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
^ permalink raw reply
* Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
From: Timur Tabi @ 2008-04-14 14:49 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linuxppc-dev, Andrew Morton, York Sun, linux-kernel
In-Reply-To: <4803690A.3080105@gmail.com>
Jiri Slaby wrote:
> On 04/14/2008 04:12 PM, Timur Tabi wrote:
>> Unfortunately, the author of the patch, York, is out this week, so I'll have to
>> take care of this. It'd be easier to modify rh_alloc() so that it doesn't
>> sleep, so that's what I'm going to do.
>
> Anyway, why do you need the spin lock there (and not mutex)?
I don't know. A spinlock just seemed obvious. Why would I prefer a mutex?
We need a mutual exclusion device in order to prevent multiple threads from
opening the DIU driver simultaneously. When the driver is opened the first
time, it needs to initialize the hardware. The hardware can't be initialized
unless we allocate a buffer first.
Now, we could pre-allocate the buffer, but then this would be a permanent 5MB
(8MB if we eliminate rh_alloc) allocation of physically contiguous memory. I'm
assuming that this would be a bad thing. It wouldn't eliminate the spinlock,
but at least we wouldn't be calling kmalloc().
I open to suggestion for improvements. I'm still going to post the rh_alloc
atomic patch, because I think it makes sense anyway. This should fix the
sleep-within-spinlock problem, but it does not fix the kmalloc-5MB-in-spinlock
problem.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] UCC nodes cleanup
From: Kumar Gala @ 2008-04-14 14:51 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Jeff Garzik, Timur Tabi, linux-serial, netdev
In-Reply-To: <20080411173100.GA20439@polina.dev.rtsoft.ru>
On Apr 11, 2008, at 12:31 PM, Anton Vorontsov wrote:
> On Fri, Apr 11, 2008 at 09:21:06PM +0400, Anton Vorontsov wrote:
>> On Fri, Apr 11, 2008 at 12:12:30PM -0500, Timur Tabi wrote:
>>> Anton Vorontsov wrote:
>>>
>>>> Or maybe I'm thinking here in terms of "fsl,ucc"... and cell-
>>>> index is
>>>> indeed should be -1... don't know. Please decide. ;-)
>>>
>>> Well, that's what I was thinking. cell-index is zero-based, so
>>> UCC1 should have
>>> cell-index = <0>.
>>>
>>> Of course, this means all the code needs to change, since I think
>>> device-id is
>>> one-based.
>>
>> Yup. You raised a really good question, because we're _introducing_
>> cell-index for UCC nodes, and if we'll choice wrong numbering scheme
>> now, then there will be no way back w/o breaking backward
>> compatibility.
>
> Hm... thinking about it more, we're introducing implementation for the
> cell-index, but device tree was "infected" already.
>
> So, too late. :-D
I say leave as you have it (UCC1 == cell-index = <1>).
Changing it so cell-index = <0> is just more confusing w/regards to
the docs.
- k
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] UCC nodes cleanup
From: Timur Tabi @ 2008-04-14 14:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jeff Garzik, linux-serial, netdev
In-Reply-To: <6B2293E0-BE5E-4C2E-9A48-4E91079A7422@kernel.crashing.org>
Kumar Gala wrote:
> I say leave as you have it (UCC1 == cell-index = <1>).
>
> Changing it so cell-index = <0> is just more confusing w/regards to
> the docs.
I don't see anything in booting-without-of.txt that requires cell-index to start
at 0, however, the only other device that starts at 1 is SATA. Even the SSI
starts at 0:
- cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on
Although I don't want to make more work for Anton, my vote is to have cell-index
start at 0. That is the convention. It's too late to fix SATA, but at least we
can avoid making it worse.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] UCC nodes cleanup
From: Kumar Gala @ 2008-04-14 14:58 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Jeff Garzik, linux-serial, netdev
In-Reply-To: <4803708B.1070009@freescale.com>
On Apr 14, 2008, at 9:56 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> I say leave as you have it (UCC1 == cell-index = <1>).
>>
>> Changing it so cell-index = <0> is just more confusing w/regards to
>> the docs.
>
> I don't see anything in booting-without-of.txt that requires cell-
> index to start
> at 0, however, the only other device that starts at 1 is SATA. Even
> the SSI
> starts at 0:
>
> - cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on
>
> Although I don't want to make more work for Anton, my vote is to
> have cell-index
> start at 0. That is the convention. It's too late to fix SATA, but
> at least we
> can avoid making it worse.
I use cell-index starting at 1 for PCI to match our docs.
I'll take Anton's last patch.
- k
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] UCC nodes cleanup
From: Kumar Gala @ 2008-04-14 14:59 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Jeff Garzik, linux-serial, netdev
In-Reply-To: <20080411160654.GA25506@polina.dev.rtsoft.ru>
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [POWERPC] UCC nodes cleanup
>
> - get rid of `model = "UCC"' in the ucc nodes
> It isn't used anywhere, so remove it. If we'll ever need something
> like this, we'll use compatible property instead.
> - replace last occurrences of device-id with cell-index.
> Drivers are modified for backward compatibility's sake.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 6 ++----
> arch/powerpc/boot/dts/mpc832x_mds.dts | 7 +------
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 4 ----
> arch/powerpc/boot/dts/mpc836x_mds.dts | 4 ----
> arch/powerpc/boot/dts/mpc8568mds.dts | 4 ----
> drivers/net/ucc_geth.c | 8 +++++++-
> drivers/net/ucc_geth_mii.c | 11 ++++++++---
> drivers/serial/ucc_uart.c | 16 ++++++++++++----
> 8 files changed, 30 insertions(+), 30 deletions(-)
applied.
- k
^ 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