* Re: [PATCH] Fix Tsi108 ethernet driver performance
From: Scott Wood @ 2007-07-13 20:32 UTC (permalink / raw)
To: Scott Wood; +Cc: Alexandre Bounine, linuxppc-dev
In-Reply-To: <4697E08B.6080700@freescale.com>
Scott Wood wrote:
> Wouldn't this cause latencies of up to a second in responding to
> received packets? I'd think that would be considered excessive.
>
> And shouldn't NAPI be reducing the RX interrupt load anyway?
Sorry, I missed that you reduced the interval to 20 ms. Still, a bit on
the high side, and a source of wasted CPU cycles when the network isn't
heavily loaded. How much of a difference in CPU usage did you see with
this patch?
-Scott
^ permalink raw reply
* Re: hvc_iseries not working
From: Tony Breeds @ 2007-07-13 21:15 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20070713170540.GA1987@aepfle.de>
On Fri, Jul 13, 2007 at 07:05:40PM +0200, Olaf Hering wrote:
Hi Olaf,
> 2.6.21 arch/powerpc/configs/iseries_defconfig works on an i825 with v5r4
> 2.6.22 arch/powerpc/configs/iseries_defconfig does not. But it works on
> a i820 with v5r3.
> 2.6.22 boots ok with CONFIG_VIOCONS
Rats!
Can you send me the complete dmesg and .config for each kernel.
I'll poke at this whne I get to work on Monday.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: boottime kernel relocation, what I missed?
From: meerkat @ 2007-07-13 22:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11574529.post@talk.nabble.com>
Figure that out, the bootstrap actually mapped the first 16M from C000000 to
the physicall address,
so calling a c routine, as long as it is in the first 16M, is OK
meerkat wrote:
>
> Good day all,
>
> For the first time I begin working on PPC, and on low level, and right
> start from boot sequence, one issue puzzled me.
>
> After bootstrap code (zImage) uncompressed the kernel vmLinux to physical
> memory (say from addr 0),
> it jumps to the kernel entry point, _start, using physically address.
>
> At this time, the MMU is not yet setup to map the kernel virtual address
> (which is statically linked against base address KERNELBASE) to the
> physically address.
>
> $ nm vmlinux |grep early_init
> c038b8e0 T early_init
>
>
> _start calls early_init before mmu is on to map the KERNEL_BASE to
> physically address
>
> The question is how "bl early_init" can branch to the early_init entry
> point, properly, as early_init is still a virtual address?
>
> Thanks
>
> Jim
>
--
View this message in context: http://www.nabble.com/boottime-kernel-relocation%2C-what-I-missed--tf4072673.html#a11588451
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
From: David Miller @ 2007-07-13 22:47 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev, netdev, ebiederm, linux-kernel
In-Reply-To: <20070713200515.GS5549@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Fri, 13 Jul 2007 15:05:15 -0500
>
> This is a patch (& bug report) for a crash in sysctl_set_parent()
> in 2.6.22-git2.
>
> Problem: 2.6.22-git2 crashes with a stack trace
> [c000000001d0fb00] c000000000067b4c .sysctl_set_parent+0x48/0x7c
> [c000000001d0fb90] c000000000069b40 .register_sysctl_table+0x7c/0xf4
> [c000000001d0fc30] c00000000065e710 .devinet_init+0x88/0xb0
> [c000000001d0fcc0] c00000000065db74 .ip_rt_init+0x17c/0x32c
> [c000000001d0fd70] c00000000065deec .ip_init+0x10/0x34
> [c000000001d0fdf0] c00000000065e898 .inet_init+0x160/0x3dc
> [c000000001d0fea0] c000000000630bc4 .kernel_init+0x204/0x3c8
>
> A bit of poking around makes it clear what the problem is:
> In sysctl_set_parent(), the for loop
>
> for (; table->ctl_name || table->procname; table++) {
>
> walks off the end of the table, and into garbage. Basically,
> this for-loop iterator expects all table arrays to be
> "null terminated". However, net/ipv4/devinet.c statically
> declares an array that is not null-terminated. The patch
> below fixes that; it works for me. Its somewhat conservative;
> if one wishes to assume that the compiler will always zero out
> the empty parts of the structure, then this pach can be shrunk
> to one line: + ctl_table devinet_root_dir[3];
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Thanks for tracking this down, I'll apply your patch.
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Benjamin Herrenschmidt @ 2007-07-13 23:06 UTC (permalink / raw)
To: James Bottomley
Cc: Jens Axboe, linux-scsi, linux-kernel, Alessandro Rubini,
linuxppc-dev, Paul Mackerras, Geert Uytterhoeven
In-Reply-To: <1184331741.3402.13.camel@localhost.localdomain>
On Fri, 2007-07-13 at 09:02 -0400, James Bottomley wrote:
> On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> > + if (!kaddr)
> > + return -1;
> > + len = sgpnt->length;
> > + if ((req_len + len) > buflen) {
> > + active = 0;
> > + len = buflen - req_len;
> > + }
> > + memcpy(kaddr + sgpnt->offset, buf + req_len,
> > len);
> > + kunmap_atomic(kaddr, KM_USER0);
>
> This isn't a SCSI objection, but this sequence appears several times in
> this driver. It's wrong for a non-PIPT architecture (and I believe the
> PS3 is VIPT) because you copy into the kernel alias for the page, which
> dirties the line in the cache of that alias (the user alias cache line
> was already invalidated). However, unless you flush the kernel alias to
> main memory, the user could read stale data. The way this is supposed
> to be done is to do a
Nah, we have no cache aliasing on ppc, at least not that matter here and
not on cell.
Ben.
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Benjamin Herrenschmidt @ 2007-07-13 23:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: James Bottomley, linux-scsi, linux-kernel, Alessandro Rubini,
linuxppc-dev, Paul Mackerras, Jens Axboe, Geert Uytterhoeven
In-Reply-To: <200707131619.54898.arnd@arndb.de>
On Fri, 2007-07-13 at 16:19 +0200, Arnd Bergmann wrote:
> I'm pretty sure that no ppc64 machine needs alias resolution in the kernel,
> although some are VIPT. Last time we discussed this, Segher explained it
> to me, but I don't remember which way Cell does it. IIRC, it automatically
> flushes cache lines that are accessed through aliases.
Ah yes, I remember reading about this automatic flushing thing. I don't
know how the caches actually work on most of our PPC's, but the fact is,
we don't have aliasing issues, so I can safely ignore it for a bit
longer :-)
There are some aliasing issues with the instruction cache specifically
on some 4xx models but that's irrelevant to this discussion (and I think
we handle them elsewhere anyway).
Ben.
^ permalink raw reply
* Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
From: Satyam Sharma @ 2007-07-14 0:49 UTC (permalink / raw)
To: Linas Vepstas
Cc: linuxppc-dev, David Miller, netdev, Eric W. Biederman,
linux-kernel
In-Reply-To: <20070713200515.GS5549@austin.ibm.com>
Hi,
I'm totally confuzed by this patch ...
On 7/14/07, Linas Vepstas <linas@austin.ibm.com> wrote:
>
> This is a patch (& bug report) for a crash in sysctl_set_parent()
> in 2.6.22-git2.
Are you sure you saw this crash on 22-git2 (Linus' tree) ???
> Problem: 2.6.22-git2 crashes with a stack trace
> [c000000001d0fb00] c000000000067b4c .sysctl_set_parent+0x48/0x7c
> [c000000001d0fb90] c000000000069b40 .register_sysctl_table+0x7c/0xf4
> [c000000001d0fc30] c00000000065e710 .devinet_init+0x88/0xb0
> [c000000001d0fcc0] c00000000065db74 .ip_rt_init+0x17c/0x32c
> [c000000001d0fd70] c00000000065deec .ip_init+0x10/0x34
> [c000000001d0fdf0] c00000000065e898 .inet_init+0x160/0x3dc
> [c000000001d0fea0] c000000000630bc4 .kernel_init+0x204/0x3c8
Please post the full dmesg output, if possible.
> A bit of poking around makes it clear what the problem is:
> In sysctl_set_parent(), the for loop
>
> for (; table->ctl_name || table->procname; table++) {
Yup, but note that the "table" there is a struct ctl_table * ...
> walks off the end of the table, and into garbage. Basically,
> this for-loop iterator expects all table arrays to be
> "null terminated". However, net/ipv4/devinet.c statically
> declares an array that is not null-terminated.
Whereas the "not null-terminated" array you're talking about
in devinet.c is a struct devinet_sysctl_table, whose *members*
are ctl_table structs.
Also note that all those members have already been declared
as arrays: struct ctl_table xxx[2]; *precisely* because the
second element (which is left un-initialized, hence will get
zeroed-out being static) is what will protect us from running
out into garbage in sysctl_set_parent().
> The patch
> below fixes that; it works for me.
Now I'm even more confuzed ...
> Its somewhat conservative;
> if one wishes to assume that the compiler will always zero out
> the empty parts of the structure,
You can always safely assume that.
Off-topic, but note that unintialized static variables being automagically
initialized to zero / NULL is guaranteed by C (the language) itself, so
nothing left in the hands of compiler implementations here. [6.7.8:10]
> then this pach can be shrunk
> to one line: + ctl_table devinet_root_dir[3];
But that's pointless. It was already [2] for the reason I mentioned.
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> [...]
> net/core/neighbour.c | 4 ++++
> net/ipv4/devinet.c | 7 ++++++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
Weirder. diffstat does not match the patch ...
> Index: linux-2.6.22-git2/net/ipv4/devinet.c
> ===================================================================
> --- linux-2.6.22-git2.orig/net/ipv4/devinet.c 2007-07-13 14:23:21.000000000 -0500
> +++ linux-2.6.22-git2/net/ipv4/devinet.c 2007-07-13 14:24:15.000000000 -0500
> @@ -1424,7 +1424,7 @@ static struct devinet_sysctl_table {
> ctl_table devinet_dev[2];
> ctl_table devinet_conf_dir[2];
> ctl_table devinet_proto_dir[2];
> - ctl_table devinet_root_dir[2];
> + ctl_table devinet_root_dir[3];
> } devinet_sysctl = {
> .devinet_vars = {
> DEVINET_SYSCTL_COMPLEX_ENTRY(FORWARDING, "forwarding",
> @@ -1493,8 +1493,13 @@ static struct devinet_sysctl_table {
And Linus' latest -git doesn't even have this stuff at line 1493.
> .data = &ipv4_devconf.loop,
> .maxlen = sizeof(int),
> .mode = 0644,
> + .child = 0x0,
> .proc_handler = &proc_dointvec,
> },
> + {
> + .ctl_name = 0,
> + .procname = 0,
> + },
> },
> };
Well, as I said, I'm totally confuzed ...
Satyam
^ permalink raw reply
* Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
From: Eric W. Biederman @ 2007-07-14 1:06 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-kernel, netdev
In-Reply-To: <20070713200515.GS5549@austin.ibm.com>
linas@austin.ibm.com (Linas Vepstas) writes:
> This is a patch (& bug report) for a crash in sysctl_set_parent()
> in 2.6.22-git2.
>
> Problem: 2.6.22-git2 crashes with a stack trace
> [c000000001d0fb00] c000000000067b4c .sysctl_set_parent+0x48/0x7c
> [c000000001d0fb90] c000000000069b40 .register_sysctl_table+0x7c/0xf4
> [c000000001d0fc30] c00000000065e710 .devinet_init+0x88/0xb0
> [c000000001d0fcc0] c00000000065db74 .ip_rt_init+0x17c/0x32c
> [c000000001d0fd70] c00000000065deec .ip_init+0x10/0x34
> [c000000001d0fdf0] c00000000065e898 .inet_init+0x160/0x3dc
> [c000000001d0fea0] c000000000630bc4 .kernel_init+0x204/0x3c8
>
> A bit of poking around makes it clear what the problem is:
> In sysctl_set_parent(), the for loop
>
> for (; table->ctl_name || table->procname; table++) {
>
> walks off the end of the table, and into garbage. Basically,
> this for-loop iterator expects all table arrays to be
> "null terminated". However, net/ipv4/devinet.c statically
> declares an array that is not null-terminated. The patch
> below fixes that; it works for me. Its somewhat conservative;
> if one wishes to assume that the compiler will always zero out
> the empty parts of the structure, then this pach can be shrunk
> to one line: + ctl_table devinet_root_dir[3];
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
> I tried to audit some of the code to see where else there
> might be similar badly-formed static declarations. This is hard,
> as there's a lot of code. Most seems fine.
Right. I believe I performed a similar audit not to long ago
when everything was converted to C99 initializers and everything
was fine then.
> net/core/neighbour.c | 4 ++++
> net/ipv4/devinet.c | 7 ++++++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.22-git2/net/ipv4/devinet.c
> ===================================================================
> --- linux-2.6.22-git2.orig/net/ipv4/devinet.c 2007-07-13 14:23:21.000000000
> -0500
> +++ linux-2.6.22-git2/net/ipv4/devinet.c 2007-07-13 14:24:15.000000000 -0500
> @@ -1424,7 +1424,7 @@ static struct devinet_sysctl_table {
> ctl_table devinet_dev[2];
> ctl_table devinet_conf_dir[2];
> ctl_table devinet_proto_dir[2];
> - ctl_table devinet_root_dir[2];
> + ctl_table devinet_root_dir[3];
> } devinet_sysctl = {
> .devinet_vars = {
> DEVINET_SYSCTL_COMPLEX_ENTRY(FORWARDING, "forwarding",
> @@ -1493,8 +1493,13 @@ static struct devinet_sysctl_table {
> .data = &ipv4_devconf.loop,
> .maxlen = sizeof(int),
> .mode = 0644,
> + .child = 0x0,
> .proc_handler = &proc_dointvec,
> },
Where did this entry above in devinet_sysctl come from?
> + {
> + .ctl_name = 0,
> + .procname = 0,
> + },
I probably would have just done:
+ {},
> },
> };
>
What added the additional entry to devinet_root_dir? I don't see that
in Linus' tree?
The result may be fine but if it isn't named in a per network device
manner we are adding duplicate entries to the root /proc/sys directory
which is wrong.
Actually come to think of it I am concerned that someone added a
settable entry into /proc/sys/ it should at least be in /proc/sys/net/
where it won't conflict with other uses of that directory. Especially
as things like network devices have user controlled names.
Eric
^ permalink raw reply
* Powerpc - Include pagemap.h in asm/powerpc/tlb.h
From: Mathieu Desnoyers @ 2007-07-14 1:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
Powerpc - Include pagemap.h in asm/powerpc/tlb.h
Fixes this powerpc build error in 2.6.22-rc6-mm1 for powerpc 64 :
In file included from include2/asm/tlb.h:60,
from /home/compudj/git/linux-2.6-lttng/arch/powerpc/mm/init_64.
c:56:
/home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h: In function 'tlb_fl
ush_mmu':
/home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h:76: error: implicit
declaration of function 'release_pages'
/home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h: In function 'tlb_re
move_page':
/home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h:105: error: implicit
declaration of function 'page_cache_release'
make[2]: *** [arch/powerpc/mm/init_64.o] Error 1
release_pages is declared in linux/pagemap.h, but cannot be included in
linux/swap.h because of a sparc related comment:
/* only sparc can not include linux/pagemap.h in this file
* so leave page_cache_release and release_pages undeclared... */
#define free_page_and_swap_cache(page) \
page_cache_release(page)
#define free_pages_and_swap_cache(pages, nr) \
release_pages((pages), (nr), 0);
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: linuxppc-dev@ozlabs.org
CC: Paul Mackerras <paulus@samba.org>
---
include/asm-powerpc/tlb.h | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6-lttng/include/asm-powerpc/tlb.h
===================================================================
--- linux-2.6-lttng.orig/include/asm-powerpc/tlb.h 2007-07-13 11:30:54.000000000 -0400
+++ linux-2.6-lttng/include/asm-powerpc/tlb.h 2007-07-13 11:31:22.000000000 -0400
@@ -23,6 +23,8 @@
#include <asm/mmu.h>
#endif
+#include <linux/pagemap.h>
+
struct mmu_gather;
#define tlb_start_vma(tlb, vma) do { } while (0)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* [patch 2/3] Add missing DATA_DATA in powerpc
From: Mathieu Desnoyers @ 2007-07-14 1:27 UTC (permalink / raw)
To: akpm, linux-kernel; +Cc: paulus, Mathieu Desnoyers, linuxppc-dev
In-Reply-To: <20070714012752.912348630@polymtl.ca>
Newer asm-generic/vmlinux.lds.h provides a DATA_DATA macro which defines the
content of what is normally referred to by *(.data). It permits adding more
"subsections" (declared by gcc with the section attribute or in assembly), which
will be linked in the .data section.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: paulus@samba.org
CC: linuxppc-dev@ozlabs.org
--
arch/powerpc/kernel/vmlinux.lds.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/arch/powerpc/kernel/vmlinux.lds.S
===================================================================
--- linux-2.6-lttng.orig/arch/powerpc/kernel/vmlinux.lds.S 2007-07-11 11:55:48.000000000 -0400
+++ linux-2.6-lttng/arch/powerpc/kernel/vmlinux.lds.S 2007-07-11 15:48:42.000000000 -0400
@@ -174,7 +174,9 @@
}
#else
.data : {
- *(.data .data.rel* .toc1)
+ DATA_DATA
+ *(.data.rel*)
+ *(.toc1)
*(.branch_lt)
}
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* OT Re: [PATCH] Xilinx SystemACE device driver
From: David H. Lynch Jr. @ 2007-07-14 5:05 UTC (permalink / raw)
To: Robertson, Joseph M.; +Cc: Linux PPC Linux PPC
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A17210@hsv1dafpew02.das.gov.sanm.corp>
Robertson, Joseph M. wrote:
> Hi,
>
> Ok, so outlook is a problem. The horror is that, where I work thats all I can use. They block all the outside systems like gmail, yahoo, etc. So under linux, I have to use the web access for outlook. ugh.
> Why I work here I don't know, they think all software HAS to be bought.
Yet they want you doing Linux development ?
I am an MSCE. I tried really really hard to like exchange/outlook.
But after loosing too many weekends and holidays to emergency rebuilds of
exchange mailstores I switched. Finding a better mail server proved
trivial - I use exim/cyrus, but many many other combinations work well.
The only time I have had to rebuild a cyrus mailstore was when the
HD it was on coughed up 64K bad sectors in one night.
I was able to recover 99% of everything, exchange would have chucked
the whole mailstore.
It has taken a long time for Open Source mail clients to offer
competitive features to OutLook
But almost every one I have ever tried has been more robust.
If you are planning on doing embedded linux development you will be
more productive the more immersed you are.
While you can do alot of linux work from windows - one of my
partners builds Linux apps inside visual studio,
it is not the same.
I have had clients with ludicrous self defeating [in]security like
you have described.
I have never met a firewall I could not pierce - included at some
defense installations I am not supposed to talk about.
I can pretty much always create a vpn back to my own servers and
then do whatever I please.
> Joe Robertson
> x8259
> Joseph.Robertson@sanmina-sci.com
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* How to add platform specific data to a of_device
From: Juergen Beisert @ 2007-07-14 16:31 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm trying to use the drivers/spi/mpc52xx_psc_spi.c as an open firmware device
(ARCH=powerpc). This device needs some platform specific data (the devices
connected to the SPI bus and how to drive the chipselects to these devices).
The driver itself get a "struct of_device *op" in his probe function and
does something like this:
struct fsl_spi_platform_data *pdata = op->dev.platform_data;
My question is: How is the correct way to bring the platform specific data
into this device structure? Is there a way to do it in the OFTree (dts file)?
Or in a way like this?
static struct fsl_spi_platform_data my_spi_master_info = {
[....]
}
static int __init my_platform_register_spi(void)
{
struct device_node *np = NULL;
struct of_device *of_dev;
if ((np = of_find_compatible_node(np, "spi", "mpc5200-psc-spi")) == NULL) {
printk("couldn't find of tree node\n");
return -1;
}
if ((of_dev = of_find_device_by_node(np)) == NULL) {
printk("couldn't find device by node\n");
return -1;
}
of_dev->dev.platform_data = &my_spi_master_info;
return 0;
}
Or is there any other way?
Regards
Juergen
^ permalink raw reply
* Re: How to add platform specific data to a of_device
From: Benjamin Herrenschmidt @ 2007-07-14 20:48 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200707141831.04107.jbe@pengutronix.de>
On Sat, 2007-07-14 at 18:31 +0200, Juergen Beisert wrote:
> Hi,
>
> I'm trying to use the drivers/spi/mpc52xx_psc_spi.c as an open firmware device
> (ARCH=powerpc). This device needs some platform specific data (the devices
> connected to the SPI bus and how to drive the chipselects to these devices).
>
> The driver itself get a "struct of_device *op" in his probe function and
> does something like this:
>
> struct fsl_spi_platform_data *pdata = op->dev.platform_data;
>
> My question is: How is the correct way to bring the platform specific data
> into this device structure? Is there a way to do it in the OFTree (dts file)?
Your approach would work I suppose.... though it's a bit ugly. I've long
considered removing platform_data from struct device, and make it part
strictly of platform device...
I'm not sure what you actually need here... if it's to know what your
child devices are, you can always walk the device-tree, though for most
things, it would be the child devices themslves who would call into your
SPI driver with whatever identification they retreived from there.
Ben.
^ permalink raw reply
* possible dead CONFIG-related content under arch/powerpc
From: Robert P. J. Day @ 2007-07-14 22:19 UTC (permalink / raw)
To: Linux PPC Mailing List
not sure if this is still the right ML, but here's the equivalent
unreferenced content under arch/powerpc:
========== FC_ENET_HAS_SCC ==========
arch/powerpc/platforms/8xx/mpc885ads_setup.c:109:#ifndef CONFIG_FC_ENET_HAS_SCC
========== SMP_750 ==========
arch/ppc/mm/tlb.c:92:#ifdef CONFIG_SMP_750
arch/powerpc/mm/tlb_32.c:92:#ifdef CONFIG_SMP_750
========== SPE_BASE ==========
arch/powerpc/mm/hash_utils_64.c:612:#ifdef CONFIG_SPE_BASE
arch/powerpc/mm/hash_utils_64.c:747:#ifdef CONFIG_SPE_BASE
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* possibly dead CONFIG-related content in arch/ppc
From: Robert P. J. Day @ 2007-07-14 22:15 UTC (permalink / raw)
To: Linux PPC Mailing List
from the most recent pull of the git tree, the output of my script
to find possibly dead content in the tree based on variables that
aren't defined in any Kconfig file anywhere in the entire tree. feel
free to do with this as you wish.
========== ADS8260 ==========
arch/ppc/boot/simple/m8260_tty.c:53:#ifdef CONFIG_ADS8260
arch/ppc/boot/simple/embed_config.c:680:#ifdef CONFIG_ADS8260
arch/ppc/8260_io/fcc_enet.c:295:#elif defined(CONFIG_EST8260) || defined(CONFIG_ADS8260) || defined(CONFIG_PQ2FADS)
========== BOOTIMG ==========
arch/ppc/platforms/ev64360.c:26:#ifdef CONFIG_BOOTIMG
arch/ppc/platforms/katana.c:30:#ifdef CONFIG_BOOTIMG
========== DEBUG_BRINGUP ==========
arch/ppc/platforms/4xx/redwood5.c:67:#ifdef CONFIG_DEBUG_BRINGUP
========== FB_RPX ==========
arch/ppc/syslib/m8xx_setup.c:114:#ifdef CONFIG_FB_RPX
arch/ppc/syslib/m8xx_setup.c:416:#if defined(CONFIG_RPXTOUCH) || defined(CONFIG_FB_RPX)
========== FEC_PACKETHOOK ==========
arch/ppc/8xx_io/fec.c:47:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:187:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:203:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:283:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:340:#endif /* CONFIG_FEC_PACKETHOOK */
arch/ppc/8xx_io/fec.c:480:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:500:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:512:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:533:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:568:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:614:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:631:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:695:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:756:#ifdef CONFIG_FEC_PACKETHOOK
arch/ppc/8xx_io/fec.c:1691:#ifdef CONFIG_FEC_PACKETHOOK
========== KGDB_MPSC ==========
arch/ppc/platforms/cpci690.c:404:#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB_MPSC)
arch/ppc/platforms/cpci690.c:443:#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB_MPSC)
arch/ppc/platforms/cpci690.c:449:#endif /* defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB_MPSC) */
========== KUP4K ==========
arch/ppc/platforms/tqm8xx.h:28:#ifndef CONFIG_KUP4K
arch/ppc/platforms/tqm8xx.h:31:#else /* CONFIG_KUP4K */
arch/ppc/platforms/tqm8xx.h:48:#endif /* CONFIG_KUP4K */
========== MV64360 ==========
arch/ppc/configs/ev64360_defconfig:115:CONFIG_MV64360=y
arch/ppc/configs/radstone_ppc7d_defconfig:117:CONFIG_MV64360=y
arch/ppc/configs/hdpu_defconfig:114:CONFIG_MV64360=y
arch/ppc/configs/chestnut_defconfig:113:CONFIG_MV64360=y
arch/ppc/configs/katana_defconfig:123:CONFIG_MV64360=y
arch/ppc/boot/simple/mv64x60_tty.c:108:#ifdef CONFIG_MV64360
arch/ppc/syslib/Makefile:55:obj-$(CONFIG_MV64360) += mv64360_pic.o
========== MV64360_SRAM_CACHE_COHERENT ==========
arch/ppc/platforms/hdpu.c:162: * Cache coherent write back, if CONFIG_MV64360_SRAM_CACHE_COHERENT set
arch/ppc/platforms/hdpu.c:168:#ifdef CONFIG_MV64360_SRAM_CACHE_COHERENT
========== NETTA ==========
arch/ppc/syslib/m8xx_setup.c:425:#if defined(CONFIG_NETTA)
drivers/net/fec_8xx/Makefile:10:ifeq ($(CONFIG_NETTA),y)
========== RPXTOUCH ==========
arch/ppc/syslib/m8xx_setup.c:416:#if defined(CONFIG_RPXTOUCH) || defined(CONFIG_FB_RPX)
========== SERIAL_CPM_ALT_SMC2 ==========
arch/ppc/configs/TQM850L_defconfig:317:CONFIG_SERIAL_CPM_ALT_SMC2=y
arch/ppc/configs/TQM823L_defconfig:317:CONFIG_SERIAL_CPM_ALT_SMC2=y
arch/ppc/configs/FADS_defconfig:316:# CONFIG_SERIAL_CPM_ALT_SMC2 is not set
arch/ppc/platforms/mpc885ads_setup.c:353:#ifndef CONFIG_SERIAL_CPM_ALT_SMC2
arch/ppc/platforms/mpc866ads_setup.c:237:#ifndef CONFIG_SERIAL_CPM_ALT_SMC2
drivers/serial/cpm_uart/cpm_uart_core.c:960:#ifdef CONFIG_SERIAL_CPM_ALT_SMC2
========== SERIAL_DETECT_IRQ ==========
arch/ppc/platforms/ev64260.h:110:#ifdef CONFIG_SERIAL_DETECT_IRQ
arch/ppc/platforms/85xx/sbc8560.h:30:#ifdef CONFIG_SERIAL_DETECT_IRQ
arch/ppc/platforms/pal4_serial.h:21:#ifdef CONFIG_SERIAL_DETECT_IRQ
arch/ppc/platforms/sandpoint.h:61:#ifdef CONFIG_SERIAL_DETECT_IRQ
arch/ppc/platforms/lopec.h:22:#ifdef CONFIG_SERIAL_DETECT_IRQ
arch/ppc/platforms/chestnut.h:112:#ifdef CONFIG_SERIAL_DETECT_IRQ
arch/ppc/platforms/radstone_ppc7d.h:148:#ifdef CONFIG_SERIAL_DETECT_IRQ
arch/i386/kernel/legacy_serial.c:18:#ifdef CONFIG_SERIAL_DETECT_IRQ
drivers/serial/8250.c:83:#define CONFIG_SERIAL_DETECT_IRQ 1
include/asm-ppc/pc_serial.h:29:#ifdef CONFIG_SERIAL_DETECT_IRQ
include/asm-alpha/serial.h:16:#ifdef CONFIG_SERIAL_DETECT_IRQ
include/asm-m68k/serial.h:20:#ifdef CONFIG_SERIAL_DETECT_IRQ
========== SERIAL_MANY_PORTS ==========
arch/ppc/syslib/ppc83xx_setup.h:45:#ifdef CONFIG_SERIAL_MANY_PORTS
arch/ppc/syslib/ppc85xx_setup.h:43:#ifdef CONFIG_SERIAL_MANY_PORTS
arch/ppc/platforms/ev64260.h:104:#ifdef CONFIG_SERIAL_MANY_PORTS
arch/ppc/platforms/85xx/sbc8560.h:21:#ifdef CONFIG_SERIAL_MANY_PORTS
arch/ppc/platforms/chestnut.h:103:#ifdef CONFIG_SERIAL_MANY_PORTS
drivers/serial/8250.c:86:#define CONFIG_SERIAL_MANY_PORTS 1
include/asm-ppc/pc_serial.h:22:#ifdef CONFIG_SERIAL_MANY_PORTS
========== SMP_750 ==========
arch/ppc/mm/tlb.c:92:#ifdef CONFIG_SMP_750
arch/powerpc/mm/tlb_32.c:92:#ifdef CONFIG_SMP_750
========== UART0_TTYS2 ==========
arch/ppc/platforms/4xx/ibmstb4.h:108:#if defined(CONFIG_UART0_TTYS2)
arch/ppc/platforms/4xx/ibmstbx25.h:125:#if defined(CONFIG_UART0_TTYS2)
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* [PATCH] POWERPC: Correct misspelled config variable in arch/powerpc/Kconfig.
From: Robert P. J. Day @ 2007-07-14 22:21 UTC (permalink / raw)
To: Linux PPC Mailing List; +Cc: Paul Mackerras
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6beee32..0e59024 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -391,7 +391,7 @@ config NOT_COHERENT_CACHE
depends on 4xx || 8xx || E200
default y
-config CONFIG_CHECK_CACHE_COHERENCY
+config CHECK_CACHE_COHERENCY
bool
endmenu
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply related
* [patch] use __attribute__ in asm-powerpc
From: Mike Frysinger @ 2007-07-15 3:36 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
Pretty much everyone uses "__attribute__" or "attribute", no one
uses "__attribute". This patch tweaks the three places in asm-powerpc where
this comes up. While only asm-powerpc/types.h is interesting (for userspace),
I did asm-powerpc/processor.h as well for consistency.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h
index d947b16..2ce6ea6 100644
--- a/include/asm-powerpc/processor.h
+++ b/include/asm-powerpc/processor.h
@@ -153,9 +153,9 @@ struct thread_struct {
unsigned long dabr; /* Data address breakpoint register */
#ifdef CONFIG_ALTIVEC
/* Complete AltiVec register set */
- vector128 vr[32] __attribute((aligned(16)));
+ vector128 vr[32] __attribute__((aligned(16)));
/* AltiVec status */
- vector128 vscr __attribute((aligned(16)));
+ vector128 vscr __attribute__((aligned(16)));
unsigned long vrsave;
int used_vr; /* set if process has used altivec */
#endif /* CONFIG_ALTIVEC */
diff --git a/include/asm-powerpc/types.h b/include/asm-powerpc/types.h
index 3b36375..a584341 100644
--- a/include/asm-powerpc/types.h
+++ b/include/asm-powerpc/types.h
@@ -48,7 +48,7 @@ typedef unsigned long long __u64;
typedef struct {
__u32 u[4];
-} __attribute((aligned(16))) __vector128;
+} __attribute__((aligned(16))) __vector128;
#endif /* __ASSEMBLY__ */
^ permalink raw reply related
* Re: [RFC 0/3] lro: Generic Large Receive Offload for TCP traffic
From: David Miller @ 2007-07-15 6:57 UTC (permalink / raw)
To: ossthema
Cc: tklein, themann, netdev, linux-kernel, linuxppc-dev, raisch,
meder, stefan.roscher
In-Reply-To: <200707111621.24852.ossthema@de.ibm.com>
I think this work is great. Thanks for doing it.
Besides the fixups Evgeniy has selected, and the suggestion
to receive into pages to cut down allocation costs, my
only request is to make this thing able to handle ipv6 as
well even if no current chips could facilitate that yet.
^ permalink raw reply
* Re: How to add platform specific data to a of_device
From: Juergen Beisert @ 2007-07-15 8:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1184446133.6059.284.camel@localhost.localdomain>
Hi Ben,
On Saturday 14 July 2007 22:48, Benjamin Herrenschmidt wrote:
> On Sat, 2007-07-14 at 18:31 +0200, Juergen Beisert wrote:
> > Hi,
> >
> > I'm trying to use the drivers/spi/mpc52xx_psc_spi.c as an open firmware
> > device (ARCH=powerpc). This device needs some platform specific data (the
> > devices connected to the SPI bus and how to drive the chipselects to
> > these devices).
> >
> > The driver itself get a "struct of_device *op" in his probe function and
> > does something like this:
> >
> > struct fsl_spi_platform_data *pdata = op->dev.platform_data;
> >
> > My question is: How is the correct way to bring the platform specific
> > data into this device structure? Is there a way to do it in the OFTree
> > (dts file)?
>
> Your approach would work I suppose.... though it's a bit ugly.
Yes, I know it works (I'm currently using it), but also yes, its very ugly. So
I want to change it.
> I'm not sure what you actually need here...
What the SPI master driver needs its something like the SPI bus number it
controls, how many chipselect lines are available (=how many SPI slave
devices are connected) and what platform specific functions it must call to
set or reset the chipselect lines to make a data transfer on its bus.
It does not need the types of connected slave devices, as this will be
controlled by the SPI framework.
struct fsl_spi_platform_data spi_master_platform_info =
{
.initial_spmode = <something SPI related>,
.sysclk = <mpc5200 internal systemclock - platform specific >,
.bus_num = <SPI bus number for this master controller>,
.max_chipselect = <platforms chipselect count>,
.activate_cs = <platform function to activate one of the chipselects>,
.deactivate_cs = <platform function to activate one of the chipselects>
};
Would it be possible to query these informations from the oftree? Can someone
give an example how the oftree dts syntax would look like for this case?
> if it's to know what your
> child devices are, you can always walk the device-tree, though for most
> things, it would be the child devices themslves who would call into your
> SPI driver with whatever identification they retreived from there.
Hmm, as I stated above: Handling the SPI slave devices is done in the SPI
framework. But including this data into the dts sounds better than including
it into the BSP. Is there some documentation around how to describe such a
SPI bus with its devices in the dts?
Thanks so far
Juergen
^ permalink raw reply
* Re: How to add platform specific data to a of_device
From: Benjamin Herrenschmidt @ 2007-07-15 8:57 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200707151033.29894.jbe@pengutronix.de>
> Hmm, as I stated above: Handling the SPI slave devices is done in the SPI
> framework. But including this data into the dts sounds better than including
> it into the BSP. Is there some documentation around how to describe such a
> SPI bus with its devices in the dts?
I don't think so, I doubt there's an SPI OF binding. You'll have to
invent something and discuss it on the list.
Ben.
^ permalink raw reply
* Re: [RFC 0/3] lro: Generic Large Receive Offload for TCP traffic
From: Christoph Hellwig @ 2007-07-15 9:12 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, netdev, linux-kernel, raisch, linuxppc-dev,
ossthema, meder, stefan.roscher
In-Reply-To: <20070714.235748.02297780.davem@davemloft.net>
On Sat, Jul 14, 2007 at 11:57:48PM -0700, David Miller wrote:
> only request is to make this thing able to handle ipv6 as
> well even if no current chips could facilitate that yet.
I'm not sure that's a good idea. If current chips can't handle ipv6
lro there is no way to actually test it and the code will surely bitrot.
^ permalink raw reply
* Re: [RFC 0/3] lro: Generic Large Receive Offload for TCP traffic
From: David Miller @ 2007-07-15 9:40 UTC (permalink / raw)
To: hch
Cc: tklein, themann, netdev, linux-kernel, raisch, linuxppc-dev,
ossthema, meder, stefan.roscher
In-Reply-To: <20070715091253.GA15790@infradead.org>
From: Christoph Hellwig <hch@infradead.org>
Date: Sun, 15 Jul 2007 10:12:53 +0100
> I'm not sure that's a good idea. If current chips can't handle ipv6
> lro there is no way to actually test it and the code will surely bitrot.
Christoph, you can do LRO pretty much completely in software.
^ permalink raw reply
* Re: [PATCH] Use resource_size_t for serial port IO addresses
From: Russell King @ 2007-07-15 11:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, paulus, david
In-Reply-To: <20070713120226.797117e2.akpm@linux-foundation.org>
On Fri, Jul 13, 2007 at 12:02:26PM -0700, Andrew Morton wrote:
> On Fri, 13 Jul 2007 09:02:16 -0500
> Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
> > This is a resend of a patch David sent out on May 7. Without it, the
> > PowerPC 44x port in 2.6.22 and on is broken. I've rebased it off of
> > Linus' current tree. Please consider pushing this soon.
> >
> > josh
> >
> >
> > At present, various parts of the serial code use unsigned long to
> > define resource addresses. This is a problem, because some 32-bit
> > platforms have physical addresses larger than 32-bits, and have mmio
> > serial uarts located above the 4GB point.
> >
> > This patch changes the type of mapbase in both struct uart_port and
> > struct plat_serial8250_port to resource_size_t, which can be
> > configured to be 64 bits on such platforms. The mapbase in
> > serial_struct can't safely be changed, because that structure is user
> > visible.
>
> 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.
* - probably a result of the patches having been worked on several
months prior to the merge window, then me forgetting the discussions
that were had, and then objecting to the wrong patch with wrong
reasoning. I really hate this "work on patches, wait months, forget
all about them, then try to work out what the hell happened" approach.
It causes mistakes like this.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* [PATCH] the wrong variable checked after request_irq()
From: Al Viro @ 2007-07-15 19:59 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
arch/powerpc/platforms/pseries/setup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 470db6e..a031d99 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -176,7 +176,7 @@ static void __init pseries_mpic_init_IRQ(void)
return;
cascade_irq = irq_of_parse_and_map(cascade, 0);
- if (cascade == NO_IRQ) {
+ if (cascade_irq == NO_IRQ) {
printk(KERN_ERR "mpic: failed to map cascade interrupt");
return;
}
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH] the wrong variable checked after request_irq()
From: Benjamin Herrenschmidt @ 2007-07-15 21:40 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, torvalds, linux-kernel
In-Reply-To: <E1IAAFp-00053g-Ti@ZenIV.linux.org.uk>
On Sun, 2007-07-15 at 20:59 +0100, Al Viro wrote:
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Out of curiosity, how did you pick it up ? You have some automated tool
to catch that (or sparse changes) or you just did -lots- of code
inspection ?
Cheers,
Ben.
> ---
> arch/powerpc/platforms/pseries/setup.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
> index 470db6e..a031d99 100644
> --- a/arch/powerpc/platforms/pseries/setup.c
> +++ b/arch/powerpc/platforms/pseries/setup.c
> @@ -176,7 +176,7 @@ static void __init pseries_mpic_init_IRQ(void)
> return;
>
> cascade_irq = irq_of_parse_and_map(cascade, 0);
> - if (cascade == NO_IRQ) {
> + if (cascade_irq == NO_IRQ) {
> printk(KERN_ERR "mpic: failed to map cascade interrupt");
> return;
> }
^ 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