* [PATCH v2] drivers/hvc: add missing __devexit_p()
From: Mike Frysinger @ 2009-05-18 7:44 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <1242632521-15954-1-git-send-email-vapier@gentoo.org>
The remove function uses __devexit, so the .remove assignment needs
__devexit_p() to fix a build error with hotplug disabled.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: linuxppc-dev@ozlabs.org
---
v2
- include all hvc files
drivers/char/hvc_iseries.c | 2 +-
drivers/char/hvc_vio.c | 2 +-
drivers/char/hvcs.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
index 449727b..936d05b 100644
--- a/drivers/char/hvc_iseries.c
+++ b/drivers/char/hvc_iseries.c
@@ -241,7 +241,7 @@ static int __devexit hvc_vio_remove(struct vio_dev *vdev)
static struct vio_driver hvc_vio_driver = {
.id_table = hvc_driver_table,
.probe = hvc_vio_probe,
- .remove = hvc_vio_remove,
+ .remove = __devexit_p(hvc_vio_remove),
.driver = {
.name = hvc_driver_name,
.owner = THIS_MODULE,
diff --git a/drivers/char/hvc_vio.c b/drivers/char/hvc_vio.c
index bd62dc8..c72b994 100644
--- a/drivers/char/hvc_vio.c
+++ b/drivers/char/hvc_vio.c
@@ -113,7 +113,7 @@ static int __devexit hvc_vio_remove(struct vio_dev *vdev)
static struct vio_driver hvc_vio_driver = {
.id_table = hvc_driver_table,
.probe = hvc_vio_probe,
- .remove = hvc_vio_remove,
+ .remove = __devexit_p(hvc_vio_remove),
.driver = {
.name = hvc_driver_name,
.owner = THIS_MODULE,
diff --git a/drivers/char/hvcs.c b/drivers/char/hvcs.c
index c76bccf..2724d62 100644
--- a/drivers/char/hvcs.c
+++ b/drivers/char/hvcs.c
@@ -868,7 +868,7 @@ static int __devexit hvcs_remove(struct vio_dev *dev)
static struct vio_driver hvcs_vio_driver = {
.id_table = hvcs_driver_table,
.probe = hvcs_probe,
- .remove = hvcs_remove,
+ .remove = __devexit_p(hvcs_remove),
.driver = {
.name = hvcs_driver_name,
.owner = THIS_MODULE,
--
1.6.3
^ permalink raw reply related
* [PATCH] drivers/hvc: add missing __devexit_p()
From: Mike Frysinger @ 2009-05-18 7:42 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev
The remove function uses __devexit, so the .remove assignment needs
__devexit_p() to fix a build error with hotplug disabled.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: linuxppc-dev@ozlabs.org
CC: linux-kernel@vger.kernel.org
---
drivers/char/hvc_iseries.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
index 449727b..936d05b 100644
--- a/drivers/char/hvc_iseries.c
+++ b/drivers/char/hvc_iseries.c
@@ -241,7 +241,7 @@ static int __devexit hvc_vio_remove(struct vio_dev *vdev)
static struct vio_driver hvc_vio_driver = {
.id_table = hvc_driver_table,
.probe = hvc_vio_probe,
- .remove = hvc_vio_remove,
+ .remove = __devexit_p(hvc_vio_remove),
.driver = {
.name = hvc_driver_name,
.owner = THIS_MODULE,
--
1.6.3
^ permalink raw reply related
* "test" branch updates
From: Benjamin Herrenschmidt @ 2009-05-18 7:19 UTC (permalink / raw)
To: linuxppc-dev list
Just a quick note before I leave the office...
I've just pushed out a bunch of stuff to my "test" branch. There's a
couple of known breakage (iseries and 8xx) which will have to be sorted
out before that stuff goes into "next". hopefully in a couple of days.
Still... feel free to take a peek, test, etc...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc/pci: clean up direct access to sysdata by iseries platform
From: Benjamin Herrenschmidt @ 2009-05-18 7:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, Linuxppc-dev Development
In-Reply-To: <8530F7E1-6EA9-4DA3-9130-DDA1C6E4B510@kernel.crashing.org>
On Fri, 2009-05-15 at 07:50 -0500, Kumar Gala wrote:
> On May 15, 2009, at 7:47 AM, Kumar Gala wrote:
>
> > We shouldn't directly access sysdata to get the device node. We
> > should
> > be calling pci_device_to_OF_node().
> >
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> > ---
> > * Updated based on sfr's iseries pci fix patch
> >
> > arch/powerpc/platforms/iseries/iommu.c | 2 +-
> > arch/powerpc/platforms/iseries/pci.c | 8 ++++----
> > 2 files changed, 5 insertions(+), 5 deletions(-)
>
> Stephen if you can test this version that would be great.
Fails with:
/home/benh/linux-powerpc-test/arch/powerpc/platforms/iseries/iommu.c: In function ‘pci_dma_dev_setup_iseries’:
/home/benh/linux-powerpc-test/arch/powerpc/platforms/iseries/iommu.c:180: error: ‘dev’ undeclared (first use in this function)
/home/benh/linux-powerpc-test/arch/powerpc/platforms/iseries/iommu.c:180: error: (Each undeclared identifier is reported only once
/home/benh/linux-powerpc-test/arch/powerpc/platforms/iseries/iommu.c:180: error: for each function it appears in.)
(I suspect it should have been "pdev" instead of "dev")
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Make the NR_CPUS max 8192
From: Michael Neuling @ 2009-05-18 7:01 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, paulus
In-Reply-To: <alpine.LRH.2.00.0905180857060.16754@vixen.sonytel.be>
In message <alpine.LRH.2.00.0905180857060.16754@vixen.sonytel.be> you wrote:
> On Mon, 18 May 2009, Michael Neuling wrote:
> > > > We can compile and boot with NR_CPUS=3D8192, so make this the max. 102
4
> > > > was an arbitrary decision anyway.
> > >
> > > Is 8192 still arbitrary? Or does something break above that?
> >
> > Yeah, the compile breaks after that with 4K pages.
> >
> > In drivers/base/node.c we have:
> > /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */
> > BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1));
> > which causes:
> > drivers/base/node.c: In function 'node_read_cpumap':
> > drivers/base/node.c:31: error: size of array 'type name' is negative
> >
> > I can compile with 16384 CPUs with 64K pages, but it doesn't boot.
> >
> > sfr asked for size info for different builds, so I may as well repost
> > them here:
> >
> > text data bss dec hex filenam
e
> > 9237767 3225768 4409996 16873531 101783b vmlinux
.1024
> > 9247355 4769472 7373708 21390535 14664c7 vmlinux
.2048
> > 9267239 7857032 13301132 30425403 1d0413b vmlinux
.4096
> > 9302623 14035832 25155980 48494435 2e3f763 vmlinux
.8192
> > 9373283 26389360 48865676 84628319 50b535f vmlinux
.16384
>
> Will distros now start pushing NR_CPUS=8192-kernels on us?
Yeah, that's a concern.
Mikey
^ permalink raw reply
* fs_enet build breakage
From: Benjamin Herrenschmidt @ 2009-05-18 7:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
Hi Kumar
Commit 4484079d517c2b6521621be0b1ea246ccc55c7d7 from your next branch
breaks my 8xx test config with the following error:
/home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: In function ‘setup_immap’:
/home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:947: error: ‘IMAP_ADDR’ undeclared (first use in this function)
/home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:947: error: (Each undeclared identifier is reported only once
/home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:947: error: for each function it appears in.)
I'm still pushing it with a bunch of other stuff to "test" so people get
to find more breakage but it will need to be fixed for the actual "next"
branch.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Make the NR_CPUS max 8192
From: Geert Uytterhoeven @ 2009-05-18 6:57 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus
In-Reply-To: <9686.1242620044@neuling.org>
On Mon, 18 May 2009, Michael Neuling wrote:
> > > We can compile and boot with NR_CPUS=3D8192, so make this the max. 1024
> > > was an arbitrary decision anyway.
> >
> > Is 8192 still arbitrary? Or does something break above that?
>
> Yeah, the compile breaks after that with 4K pages.
>
> In drivers/base/node.c we have:
> /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */
> BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1));
> which causes:
> drivers/base/node.c: In function 'node_read_cpumap':
> drivers/base/node.c:31: error: size of array 'type name' is negative
>
> I can compile with 16384 CPUs with 64K pages, but it doesn't boot.
>
> sfr asked for size info for different builds, so I may as well repost
> them here:
>
> text data bss dec hex filename
> 9237767 3225768 4409996 16873531 101783b vmlinux.1024
> 9247355 4769472 7373708 21390535 14664c7 vmlinux.2048
> 9267239 7857032 13301132 30425403 1d0413b vmlinux.4096
> 9302623 14035832 25155980 48494435 2e3f763 vmlinux.8192
> 9373283 26389360 48865676 84628319 50b535f vmlinux.16384
Will distros now start pushing NR_CPUS=8192-kernels on us?
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-05-18 6:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
A few more 2.6.30 things for you... a defconfig update, and a couple
of small fixes, either obvious enough or regression fixes.
Cheers,
Ben.
The following changes since commit 86460103c412f9e11aeb7950cce64b9e51539d4d:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../rafael/suspend-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (1):
powerpc: Explicit alignment for .data.cacheline_aligned
Geoff Levand (1):
powerpc/ps3: Update ps3_defconfig
Mel Gorman (1):
powerpc: Do not assert pte_locked for hugepage PTE entries
Michael Ellerman (1):
powerpc/ftrace: Use pr_devel() in ftrace.c
Steven Rostedt (1):
powerpc/ftrace: Fix constraint to be early clobber
arch/powerpc/configs/ps3_defconfig | 105 +++++++++++++++++++++---------------
arch/powerpc/kernel/ftrace.c | 22 ++++----
arch/powerpc/kernel/vmlinux.lds.S | 1 +
arch/powerpc/mm/pgtable.c | 3 +-
4 files changed, 76 insertions(+), 55 deletions(-)
^ permalink raw reply
* Re: [PATCH] bug fix in arch/powerpc/mm/tlb_nohash_low.S
From: Benjamin Herrenschmidt @ 2009-05-18 5:52 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Torez Smith
In-Reply-To: <20090518154721.0a9c3dee.sfr@canb.auug.org.au>
On Mon, 2009-05-18 at 15:47 +1000, Stephen Rothwell wrote:
> Hi Ben,
>
> On Mon, 18 May 2009 15:12:03 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > Thanks, but it's been fixed already :-)
> >
> > See commit b62c31ae401c6df25c61b206681a6e904ef97169.
>
> Should this be submitted for 2.6.29 stable?
Probably, will do.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] bug fix in arch/powerpc/mm/tlb_nohash_low.S
From: Stephen Rothwell @ 2009-05-18 5:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Torez Smith
In-Reply-To: <1242623523.18075.39.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 366 bytes --]
Hi Ben,
On Mon, 18 May 2009 15:12:03 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Thanks, but it's been fixed already :-)
>
> See commit b62c31ae401c6df25c61b206681a6e904ef97169.
Should this be submitted for 2.6.29 stable?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Explicit alignment for .data.cacheline_aligned
From: Benjamin Herrenschmidt @ 2009-05-18 5:17 UTC (permalink / raw)
To: linuxppc-dev
I don't think anything guarantees that the objects in data.page_aligned
are a multiple of PAGE_SIZE, thus the section may end on any boundary.
So the following section, .data.cacheline_aligned needs an explicit
alignment.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
And this is the right patch after a "quilt ref" and without typo :-)
arch/powerpc/kernel/vmlinux.lds.S | 1 +
1 file changed, 1 insertion(+)
--- linux-work.orig/arch/powerpc/kernel/vmlinux.lds.S 2009-05-18 14:24:05.000000000 +1000
+++ linux-work/arch/powerpc/kernel/vmlinux.lds.S 2009-05-18 15:16:54.000000000 +1000
@@ -264,6 +264,7 @@ SECTIONS
*(.data.page_aligned)
}
+ . = ALIGN(L1_CACHE_BYTES);
.data.cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - LOAD_OFFSET) {
*(.data.cacheline_aligned)
}
^ permalink raw reply
* Re: [PATCH] bug fix in arch/powerpc/mm/tlb_nohash_low.S
From: Benjamin Herrenschmidt @ 2009-05-18 5:12 UTC (permalink / raw)
To: Torez Smith; +Cc: linuxppc-dev
In-Reply-To: <1242622146.31702.26.camel@torez.austin.ibm.com>
On Sun, 2009-05-17 at 23:49 -0500, Torez Smith wrote:
> File arch/powerpc/mm/tlb_nohash_low.S defines various processor specific low level TLB invalidation. Most all family of validations are grouped via pre-processor defines with the intent we error out if we reach the end and our platform is not represented. Given this, the last few lines of the file should look similar to the following....
> << SNIP >>
> 1: wrtee r10
> blr
> #else
> #error Unsupported processor type !
> #endif
>
> However, the #else is incorrectly written as #elif. On some of the newer compilers/assemblers, this will not successfully assemble and will cause an error.
Thanks, but it's been fixed already :-)
See commit b62c31ae401c6df25c61b206681a6e904ef97169.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] bug fix in arch/powerpc/mm/tlb_nohash_low.S
From: Torez Smith @ 2009-05-18 4:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
File arch/powerpc/mm/tlb_nohash_low.S defines various processor specific low level TLB invalidation. Most all family of validations are grouped via pre-processor defines with the intent we error out if we reach the end and our platform is not represented. Given this, the last few lines of the file should look similar to the following....
<< SNIP >>
1: wrtee r10
blr
#else
#error Unsupported processor type !
#endif
However, the #else is incorrectly written as #elif. On some of the newer compilers/assemblers, this will not successfully assemble and will cause an error.
Signed-off-by: Torez Smith <lnxtorez@linux.vnet.ibm.com>
---
Index: linux-2.6.29/arch/powerpc/mm/tlb_nohash_low.S
===================================================================
--- linux-2.6.29.orig/arch/powerpc/mm/tlb_nohash_low.S 2009-05-17 21:31:20.000000000 -0500
+++ linux-2.6.29/arch/powerpc/mm/tlb_nohash_low.S 2009-05-17 21:31:40.000000000 -0500
@@ -161,6 +161,6 @@
isync
1: wrtee r10
blr
-#elif
+#else
#error Unsupported processor type !
#endif
--
Torez Smith
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Benjamin Herrenschmidt @ 2009-05-18 4:49 UTC (permalink / raw)
To: Becky Bruce; +Cc: fujita.tomonori, linuxppc-dev
In-Reply-To: <1242340949-16369-2-git-send-email-beckyb@kernel.crashing.org>
On Thu, 2009-05-14 at 17:42 -0500, Becky Bruce wrote:
> This patch includes the basic infrastructure to use swiotlb
> bounce buffering on 32-bit powerpc. It is not yet enabled on
> any platforms. Probably the most interesting bit is the
> addition of addr_needs_map to dma_ops - we need this as
> a dma_op because the decision of whether or not an addr
> can be mapped by a device is device-specific.
>
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Hi Becky !
Finally I got to look at your patch :-)
A few comments below...
> #ifdef CONFIG_NOT_COHERENT_CACHE
> /*
> * DMA-consistent mapping functions for PowerPCs that don't support
> @@ -76,6 +85,8 @@ struct dma_mapping_ops {
> dma_addr_t dma_address, size_t size,
> enum dma_data_direction direction,
> struct dma_attrs *attrs);
> + int (*addr_needs_map)(struct device *dev, dma_addr_t addr,
> + size_t size);
What annoys me here is that we basically end up with two indirect
function calls for pretty much any DMA map. One was bad enough on low
end processors or very intensive networking, but this is getting real
bad don't you think ?
Granted, this is only used when swiotlb is used too, but still...
So the problem is that the region that can pass-through is somewhat
a mix of bus specific (incoming DMA window location & size) and
device specific (device addressing limitations).
Now, if we can always reduce it to a single range though, which I
think is practically the case, can't we instead pre-calculate that
range and stick -that- in the struct dev archdata or similar thus
speeding up the decision for a given address as to whether it needs
a swiotlb mapping or not ? Or does it gets too messy ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: Explicit alignment for .data.cacheline_aligned
From: Benjamin Herrenschmidt @ 2009-05-18 4:29 UTC (permalink / raw)
To: linuxppc-dev
I don't think anything guarantees that the objects in data.page_aligned
are a multiple of PAGE_SIZE, thus the section may end on any boundary.
So the following section, .data.cacheline_aligned needs an explicit
alignment.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/vmlinux.lds.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/kernel/vmlinux.lds.S 2009-05-18 14:24:05.000000000 +1000
+++ linux-work/arch/powerpc/kernel/vmlinux.lds.S 2009-05-18 14:24:22.000000000 +1000
@@ -264,7 +264,8 @@ SECTIONS
*(.data.page_aligned)
}
- .data.cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - LOAD_OFFSET) {
+ . = ALIGN(L1_CACHE_BYTES);
+ .cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - LOAD_OFFSET) {
*(.data.cacheline_aligned)
}
^ permalink raw reply
* Re: [PATCH 5/8] powerpc: use new macro for .data.cacheline_aligned section.
From: Benjamin Herrenschmidt @ 2009-05-18 4:23 UTC (permalink / raw)
To: Tim Abbott
Cc: Denys Vlasenko, Jeff Arnold, Linux kernel mailing list,
Anders Kaseorg, linuxppc-dev, Paul Mackerras, Sam Ravnborg,
Waseem Daher
In-Reply-To: <1241135777-9462-6-git-send-email-tabbott@mit.edu>
On Thu, 2009-04-30 at 19:56 -0400, Tim Abbott wrote:
> .data.cacheline_aligned should not need a separate output section;
> this change moves it into the .data section.
>
> Since there isn't an ALIGN() directive before the
> .data.cacheline_aligned scetion in the current linker script, I'd like
> an ack from one of the powerpc maintainers that L1_CACHE_BYTES is the
> correct alignment here.
Yes, that's the right size.
Also. that looks like a bug to me in the current stuff. I'm queuing your
patch set for .31 but I'll stick a "fix" in .30 for that just in case
which unfortunately means your patches will probably need to be rebased.
Cheers,
Ben.
> Signed-off-by: Tim Abbott <tabbott@mit.edu>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@ozlabs.org
> ---
> arch/powerpc/kernel/vmlinux.lds.S | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
> index 4223892..e769717 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -223,6 +223,7 @@ SECTIONS
> .data : AT(ADDR(.data) - LOAD_OFFSET) {
> PAGE_ALIGNED_DATA
> NOSAVE_DATA
> + CACHELINE_ALIGNED_DATA(L1_CACHE_BYTES)
> DATA_DATA
> #ifdef CONFIG_PPC32
> *(.sdata)
> @@ -260,10 +261,6 @@ SECTIONS
> *(.data.init_task)
> }
>
> - .data.cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - LOAD_OFFSET) {
> - *(.data.cacheline_aligned)
> - }
> -
> . = ALIGN(L1_CACHE_BYTES);
> .data.read_mostly : AT(ADDR(.data.read_mostly) - LOAD_OFFSET) {
> *(.data.read_mostly)
^ permalink raw reply
* Re: [PATCH] mv643xx_eth: fix PPC DMA breakage
From: David Miller @ 2009-05-18 4:16 UTC (permalink / raw)
To: buytenh; +Cc: netdev, linuxppc-dev, pacman, tbm
In-Reply-To: <20090515235330.GC1727@mail.wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Sat, 16 May 2009 01:53:30 +0200
> On Fri, May 15, 2009 at 08:39:24PM +0200, Gabriel Paubert wrote:
>
>> After 2.6.29, PPC no more admits passing NULL to the dev parameter of
>> the DMA API. The result is a BUG followed by solid lock-up when the
>> mv643xx_eth driver brings an interface up. The following patch makes
>> the driver work on my Pegasos again; it is mostly a search and replace
>> of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping
>> functions.
>>
>> Signed-off-by: Gabriel Paubert <paubert@iram.es>
>
> Acked-by: Lennert Buytenhek <buytenh@marvell.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Benjamin Herrenschmidt @ 2009-05-18 4:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Sam Ravnborg
In-Reply-To: <1241565080.11379.14.camel@localhost.localdomain>
On Tue, 2009-05-05 at 19:11 -0400, Steven Rostedt wrote:
> OK, so what's the status with this patch series?
>
> I don't want to pull it in unless I have an ack from Sam, and now
> there's issues with having -fno-omit-frame-pointer. Should we add a
> patch instead that simply removes that?
>
> If we eliminate the -fno-omit-frame-pointer, would that solve the PPC
> problem? And would it cause any other issues with other archs?
Well, the patch looks fine to me to be honest I'm not sure what the
complaint is above...
IE. On arch that define the new HAVE_NORMAL_FRAME_POINTER (let's just
call it HAVE_IMPLIED_FRAME_POINTER then :-) we just don't do
-fno-omit-frame-pointer and avoid triggering the bug...
Segher, what are we missing here ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Make the NR_CPUS max 8192
From: Michael Neuling @ 2009-05-18 4:14 UTC (permalink / raw)
To: michael; +Cc: paulus, linuxppc-dev
In-Reply-To: <1242609873.13757.4.camel@concordia>
> > We can compile and boot with NR_CPUS=3D8192, so make this the max. 1024
> > was an arbitrary decision anyway.
>
> Is 8192 still arbitrary? Or does something break above that?
Yeah, the compile breaks after that with 4K pages.
In drivers/base/node.c we have:
/* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */
BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1));
which causes:
drivers/base/node.c: In function 'node_read_cpumap':
drivers/base/node.c:31: error: size of array 'type name' is negative
I can compile with 16384 CPUs with 64K pages, but it doesn't boot.
sfr asked for size info for different builds, so I may as well repost
them here:
text data bss dec hex filename
9237767 3225768 4409996 16873531 101783b vmlinux.1024
9247355 4769472 7373708 21390535 14664c7 vmlinux.2048
9267239 7857032 13301132 30425403 1d0413b vmlinux.4096
9302623 14035832 25155980 48494435 2e3f763 vmlinux.8192
9373283 26389360 48865676 84628319 50b535f vmlinux.16384
config was pseries_defconfig but with 64K pages.
Mikey
^ permalink raw reply
* Re: [RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure
From: Benjamin Herrenschmidt @ 2009-05-18 3:35 UTC (permalink / raw)
To: K.Prasad
Cc: linuxppc-dev, Michael Neuling, Alan Stern, Roland McGrath, paulus
In-Reply-To: <20090514134335.GB14229@in.ibm.com>
On Thu, 2009-05-14 at 19:13 +0530, K.Prasad wrote:
> plain text document attachment (ppc64_prepare_code_01)
> Prepare the PowerPC code for HW Breakpoint infrastructure patches by including
> relevant constant definitions and function declarations.
Hi !
Some comments below...
> +#define HBP_NUM 1 /* Number of physical HW breakpoint registers */
Can you use a more verbose constant ? reg.h is included everywhere so
the risk of collision is high.
> #define DABR_TRANSLATION (1UL << 2)
> #define DABR_DATA_WRITE (1UL << 1)
> #define DABR_DATA_READ (1UL << 0)
> +#define DABR_DATA_RW (3UL << 0)
Do you really need that ? It's just DABR_DATA_WRITE | DABR_DATA_READ :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] ppc64: xmon: Add dl command to dump contents of __log_buf
From: Benjamin Herrenschmidt @ 2009-05-18 3:29 UTC (permalink / raw)
To: Vinay Sridhar; +Cc: linuxppc-dev, ellerman
In-Reply-To: <200905151443.07723.vinay@linux.vnet.ibm.com>
On Fri, 2009-05-15 at 14:43 +0530, Vinay Sridhar wrote:
> Hello All,
>
> Quite a while back Michael Ellerman had posted a patch to add support to xmon to print the contents of the console log pointed to by __log_buf.
> Here's the link to that patch - http://ozlabs.org/pipermail/linuxppc64-dev/2005-March/003657.html
> I've ported the patch in the above link to 2.6.30-rc5 and have tested it.
Thanks, good idea.
I'll review & test and if all goes well, it will be in -next.
Cheers,
Ben
^ permalink raw reply
* Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Benjamin Herrenschmidt @ 2009-05-18 3:24 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: LinuxPPC
In-Reply-To: <20090515181813.GA28132@iram.es>
On Fri, 2009-05-15 at 20:18 +0200, Gabriel Paubert wrote:
> Since PPC_MUTIPLATFORM was removed, it was impossible to select the
> driver for mv643xx_eth on the Pegasos. Fix by allowing to select
> the driver on CHRP platforms; Pegasos is a CHRP platform and the driver
> will not work wihtout arch/powerpc/platforms/chrp/pegasos_eth.
>
> The patch also removes all references to MV64360 config option which
> no more exists.
>
> Signed-off-by: Gabriel Paubert <paubert@iram.es>
Please break that up into 2 different patches. The arch/powerpc one that
removes the reference from IRQ_ALL_CPUs and the drivers/net/ one which
should be set to the netdev mailing list.
Thanks !
Cheers,
Ben.
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index a0d1146..1dfeb62 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -360,7 +360,7 @@ config PPCBUG_NVRAM
>
> config IRQ_ALL_CPUS
> bool "Distribute interrupts on all CPUs by default"
> - depends on SMP && !MV64360
> + depends on SMP
> help
> This option gives the kernel permission to distribute IRQs across
> multiple CPUs. Saying N here will route all IRQs to the first
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 214a92d..6fc0ff4 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
>
> config MV643XX_ETH
> tristate "Marvell Discovery (643XX) and Orion ethernet support"
> - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) || PLAT_ORION
> + depends on MV64X60 || PPC_CHRP || PLAT_ORION
> select INET_LRO
> select PHYLIB
> help
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH] fbdev: Add PLB support and cleanup DCR in xilinxfb driver.
From: Benjamin Herrenschmidt @ 2009-05-18 3:20 UTC (permalink / raw)
To: Krzysztof Helt
Cc: linux-fbdev-devel, Antonino Daplas, Suneel, linuxppc-dev,
Geert Uytterhoeven, John Linn
In-Reply-To: <20090517122644.f537f500.krzysztof.h1@poczta.fm>
On Sun, 2009-05-17 at 12:26 +0200, Krzysztof Helt wrote:
> If so please ignore my comment.
>
> Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Andrew, will you merge this or should I stick it into the powerpc.git
tree ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Make the NR_CPUS max 8192
From: Michael Ellerman @ 2009-05-18 1:24 UTC (permalink / raw)
To: Michael Neuling; +Cc: paulus, linuxppc-dev
In-Reply-To: <17087.1242609196@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 244 bytes --]
On Mon, 2009-05-18 at 11:13 +1000, Michael Neuling wrote:
> We can compile and boot with NR_CPUS=8192, so make this the max. 1024
> was an arbitrary decision anyway.
Is 8192 still arbitrary? Or does something break above that?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Make the NR_CPUS max 8192
From: Michael Neuling @ 2009-05-18 1:13 UTC (permalink / raw)
To: paulus, benh; +Cc: linuxppc-dev
We can compile and boot with NR_CPUS=8192, so make this the max. 1024
was an arbitrary decision anyway.
Signed-off-by: Michael Neuling <mikey@neuling.org>
--
No, I've not actually booted on a 8192 way machine, although if wishing
made it so....
arch/powerpc/platforms/Kconfig.cputype | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/platforms/Kconfig.cputype
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/Kconfig.cputype
+++ linux-2.6-ozlabs/arch/powerpc/platforms/Kconfig.cputype
@@ -262,8 +262,8 @@ config SMP
If you don't know what to do here, say N.
config NR_CPUS
- int "Maximum number of CPUs (2-1024)"
- range 2 1024
+ int "Maximum number of CPUs (2-8192)"
+ range 2 8192
depends on SMP
default "32" if PPC64
default "4"
^ 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