* [PATCH RFC] Simplify the Linux kernel by reducing its state space
From: Paul E. McKenney @ 2012-03-31 16:33 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, linux-mips, linux-m32r, linux-ia64, linux-parisc,
linux-s390, linux-hexagon, linux-sh, jejb, x86, linux, dhowells,
linux390, linux-am33-list, cmetcalf, linux-alpha, sparclinux,
uclinux-dist-devel, tglx, linuxppc-dev, linux-arm-kernel
Although there have been numerous complaints about the complexity of
parallel programming (especially over the past 5-10 years), the plain
truth is that the incremental complexity of parallel programming over
that of sequential programming is not as large as is commonly believed.
Despite that you might have heard, the mind-numbing complexity of modern
computer systems is not due so much to there being multiple CPUs, but
rather to there being any CPUs at all. In short, for the ultimate in
computer-system simplicity, the optimal choice is NR_CPUS=0.
This commit therefore limits kernel builds to zero CPUs. This change
has the beneficial side effect of rendering all kernel bugs harmless.
Furthermore, this commit enables additional beneficial changes, for
example, the removal of those parts of the kernel that are not needed
when there are zero CPUs.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
alpha/Kconfig | 11 ++++++-----
arm/Kconfig | 6 +++---
blackfin/Kconfig | 3 ++-
hexagon/Kconfig | 9 +++++----
ia64/Kconfig | 9 +++++----
m32r/Kconfig | 10 ++++++----
mips/Kconfig | 21 +++++++++++----------
mn10300/Kconfig | 3 ++-
parisc/Kconfig | 6 +++---
powerpc/platforms/Kconfig.cputype | 8 ++++----
s390/Kconfig | 12 +++++++-----
sh/Kconfig | 11 ++++++-----
sparc/Kconfig | 8 ++++----
tile/Kconfig | 9 +++++----
x86/Kconfig | 16 +++++++++-------
15 files changed, 78 insertions(+), 64 deletions(-)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 56a4df9..1766b4a 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -541,14 +541,15 @@ config HAVE_DEC_LOCK
default y
config NR_CPUS
- int "Maximum number of CPUs (2-32)"
- range 2 32
+ int "Maximum number of CPUs (0-0)"
+ range 0 0
depends on SMP
- default "32" if ALPHA_GENERIC || ALPHA_MARVEL
- default "4" if !ALPHA_GENERIC && !ALPHA_MARVEL
+ default "0" if ALPHA_GENERIC || ALPHA_MARVEL
+ default "0" if !ALPHA_GENERIC && !ALPHA_MARVEL
help
MARVEL support can handle a maximum of 32 CPUs, all the others
- with working support have a maximum of 4 CPUs.
+ with working support have a maximum of 4 CPUs. But why take
+ chances? Just stick with zero CPUs.
config ARCH_DISCONTIGMEM_ENABLE
bool "Discontiguous Memory Support (EXPERIMENTAL)"
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a48aecc..1f07a3a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1551,10 +1551,10 @@ config PAGE_OFFSET
default 0xC0000000
config NR_CPUS
- int "Maximum number of CPUs (2-32)"
- range 2 32
+ int "Maximum number of CPUs (0-0)"
+ range 0 0
depends on SMP
- default "4"
+ default "0"
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs (EXPERIMENTAL)"
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index abe5a9e..6a78549 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -241,7 +241,8 @@ config SMP
config NR_CPUS
int
depends on SMP
- default 2 if BF561
+ range 0 0
+ default 0 if BF561
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 9059e39..daab009 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -158,13 +158,14 @@ config SMP
config NR_CPUS
int "Maximum number of CPUs" if SMP
- range 2 6 if SMP
- default "1" if !SMP
- default "6" if SMP
+ range 0 0 if SMP
+ default "0" if !SMP
+ default "0" if SMP
---help---
This allows you to specify the maximum number of CPUs which this
kernel will support. The maximum supported value is 6 and the
- minimum value which makes sense is 2.
+ minimum value which makes sense is 2. But a limit of zero is
+ so much safer!
This is purely to save memory - each supported CPU adds
approximately eight kilobytes to the kernel image.
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index bd72669..fea0e6d 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -373,16 +373,17 @@ config SMP
If you don't know what to do here, say N.
config NR_CPUS
- int "Maximum number of CPUs (2-4096)"
- range 2 4096
+ int "Maximum number of CPUs (0-0)"
+ range 0 0
depends on SMP
- default "4096"
+ default "0"
help
You should set this to the number of CPUs in your system, but
keep in mind that a kernel compiled for, e.g., 2 CPUs will boot but
only use 2 CPUs on a >2 CPU system. Setting this to a value larger
than 64 will cause the use of a CPU mask array, causing a small
- performance hit.
+ performance hit. And setting it larger than zero risks all
+ manner of software bugs, so we just play it safe.
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs (EXPERIMENTAL)"
diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
index ef80a65..68b9e88 100644
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -300,14 +300,16 @@ config CHIP_M32700_TS1
default n
config NR_CPUS
- int "Maximum number of CPUs (2-32)"
- range 2 32
+ int "Maximum number of CPUs (0-0)"
+ range 0 0
depends on SMP
- default "2"
+ default "0"
help
This allows you to specify the maximum number of CPUs which this
kernel will support. The maximum supported value is 32 and the
- minimum value which makes sense is 2.
+ minimum value which makes sense is 2. Zero may not make sense,
+ but given that there is much in this world that does not make
+ sense, zero it is!
This is purely to save memory - each supported CPU adds
approximately eight kilobytes to the kernel image.
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 5ab6e89..3d7d06c 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2192,16 +2192,16 @@ config NR_CPUS_DEFAULT_64
bool
config NR_CPUS
- int "Maximum number of CPUs (2-64)"
- range 1 64 if NR_CPUS_DEFAULT_1
+ int "Maximum number of CPUs (0-0)"
+ range 0 0 if NR_CPUS_DEFAULT_1
depends on SMP
- default "1" if NR_CPUS_DEFAULT_1
- default "2" if NR_CPUS_DEFAULT_2
- default "4" if NR_CPUS_DEFAULT_4
- default "8" if NR_CPUS_DEFAULT_8
- default "16" if NR_CPUS_DEFAULT_16
- default "32" if NR_CPUS_DEFAULT_32
- default "64" if NR_CPUS_DEFAULT_64
+ default "0" if NR_CPUS_DEFAULT_1
+ default "0" if NR_CPUS_DEFAULT_2
+ default "0" if NR_CPUS_DEFAULT_4
+ default "0" if NR_CPUS_DEFAULT_8
+ default "0" if NR_CPUS_DEFAULT_16
+ default "0" if NR_CPUS_DEFAULT_32
+ default "0" if NR_CPUS_DEFAULT_64
help
This allows you to specify the maximum number of CPUs which this
kernel will support. The maximum supported value is 32 for 32-bit
@@ -2212,7 +2212,8 @@ config NR_CPUS
This is purely to save memory - each supported CPU adds
approximately eight kilobytes to the kernel image. For best
performance should round up your number of processors to the next
- power of two.
+ power of two. And just think how much more memory we will
+ save by setting the limit to zero!
source "kernel/time/Kconfig"
diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig
index 8f1c40d..85fc112 100644
--- a/arch/mn10300/Kconfig
+++ b/arch/mn10300/Kconfig
@@ -201,7 +201,8 @@ config SMP
config NR_CPUS
int
depends on SMP
- default "2"
+ range 0 0
+ default "0"
source "kernel/Kconfig.preempt"
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 242a1b7..358eaf8 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -254,10 +254,10 @@ config HPUX
depends on !64BIT
config NR_CPUS
- int "Maximum number of CPUs (2-32)"
- range 2 32
+ int "Maximum number of CPUs (0-0)"
+ range 0 0
depends on SMP
- default "32"
+ default "0"
endmenu
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 425db18..5e607e0 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -356,11 +356,11 @@ config SMP
If you don't know what to do here, say N.
config NR_CPUS
- int "Maximum number of CPUs (2-8192)"
- range 2 8192
+ int "Maximum number of CPUs (0-0)"
+ range 0 0
depends on SMP
- default "32" if PPC64
- default "4"
+ default "0" if PPC64
+ default "0"
config NOT_COHERENT_CACHE
bool
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index d172758..f9bc067 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -169,15 +169,17 @@ config SMP
Even if you don't know what to do here, say Y.
config NR_CPUS
- int "Maximum number of CPUs (2-64)"
- range 2 64
+ int "Maximum number of CPUs (0-0)"
+ range 0 0
depends on SMP
- default "32" if !64BIT
- default "64" if 64BIT
+ default "0" if !64BIT
+ default "0" if 64BIT
help
This allows you to specify the maximum number of CPUs which this
kernel will support. The maximum supported value is 64 and the
- minimum value which makes sense is 2.
+ minimum value which makes sense is 2. The minimal value that
+ makes sense might well be 2, but we all know that the only
+ -sane- value is zero!
This is purely to save memory - each supported CPU adds
approximately sixteen kilobytes to the kernel image.
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 713fb58..5ddc7c0 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -705,18 +705,19 @@ config SMP
If you don't know what to do here, say N.
config NR_CPUS
- int "Maximum number of CPUs (2-32)"
- range 2 32
+ int "Maximum number of CPUs (0-0)"
+ range 0 0
depends on SMP
- default "4" if CPU_SUBTYPE_SHX3
- default "2"
+ default "0" if CPU_SUBTYPE_SHX3
+ default "0"
help
This allows you to specify the maximum number of CPUs which this
kernel will support. The maximum supported value is 32 and the
minimum value which makes sense is 2.
This is purely to save memory - each supported CPU adds
- approximately eight kilobytes to the kernel image.
+ approximately eight kilobytes to the kernel image. Debloating
+ is the way, NR_CPUS to zero today!!!
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs (EXPERIMENTAL)"
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index ca5580e..0de9f0f 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -177,10 +177,10 @@ config SMP
config NR_CPUS
int "Maximum number of CPUs"
depends on SMP
- range 2 32 if SPARC32
- range 2 1024 if SPARC64
- default 32 if SPARC32
- default 64 if SPARC64
+ range 0 0 if SPARC32
+ range 0 0 if SPARC64
+ default 0 if SPARC32
+ default 0 if SPARC64
source kernel/Kconfig.hz
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 11270ca..a05112c 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -126,14 +126,15 @@ source "init/Kconfig"
menu "Tilera-specific configuration"
config NR_CPUS
- int "Maximum number of tiles (2-255)"
- range 2 255
+ int "Maximum number of tiles (0-0)"
+ range 0 0
depends on SMP
- default "64"
+ default "0"
---help---
Building with 64 is the recommended value, but a slightly
smaller kernel memory footprint results from using a smaller
- value on chips with fewer tiles.
+ value on chips with fewer tiles. To minimize both memory
+ footprint and bugs, use zero and only zero.
source "kernel/time/Kconfig"
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5bed94e..a6977f2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -773,19 +773,21 @@ config MAXSMP
config NR_CPUS
int "Maximum number of CPUs" if SMP && !MAXSMP
- range 2 8 if SMP && X86_32 && !X86_BIGSMP
- range 2 512 if SMP && !MAXSMP
- default "1" if !SMP
- default "4096" if MAXSMP
- default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000)
- default "8" if SMP
+ range 0 0 if SMP && X86_32 && !X86_BIGSMP
+ range 0 0 if SMP && !MAXSMP
+ default "0" if !SMP
+ default "0" if MAXSMP
+ default "0" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000)
+ default "0" if SMP
---help---
This allows you to specify the maximum number of CPUs which this
kernel will support. The maximum supported value is 512 and the
minimum value which makes sense is 2.
This is purely to save memory - each supported CPU adds
- approximately eight kilobytes to the kernel image.
+ approximately eight kilobytes to the kernel image. But
+ the first supported CPU brings a lot of bugs with it, so
+ for ultimate reliability, set the number of CPUs to zero.
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
^ permalink raw reply related
* Re: powerpc/85xx: p2020rdb - move the NAND address.
From: Kumar Gala @ 2012-03-31 14:48 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: Bryan Hundven, linuxppc-dev
In-Reply-To: <4F75BD6B.30609@linutronix.de>
On Mar 30, 2012, at 9:04 AM, Sebastian Andrzej Siewior wrote:
> On 03/29/2012 03:10 PM, Kumar Gala wrote:
>
>>> - include/configs/P1_P2_RDB.h
>>>
>>> #ifndef CONFIG_NAND_SPL
>>> #define CONFIG_SYS_NAND_BASE 0xffa00000
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull
>>> #else
>>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>>> #endif
>>> #else
>>> #define CONFIG_SYS_NAND_BASE 0xfff00000
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull
>>> #else
>>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>>> #endif
>>> #endif
>>>
>>> - include/configs/p1_p2_rdb_pc.h
>>>
>>> #ifdef CONFIG_NAND_FSL_ELBC
>>> #define CONFIG_SYS_NAND_BASE 0xff800000
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull
>>> #else
>>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>>> #endif
>>>
>>
>> There are two (well 3 since rdb-pc has both 32b& 36b) in the tree now:
>>
>> arch/powerpc/boot/dts/p2020rdb.dts
>> arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
>> arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
>
> Okay. So I assume that one has the proper NAND address and my patch
> should be reverted then. Do want a patch from me for that?
Yes, please do.
>>> Since both system have the same SoC and the NAND_SPL is always linked
>>> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
>>> later to 0xff800000 (or to 0xffa00000) and having it consistent among
>>> both configs.
>
> what about this thing? Should leave it as it or move to the same
> location? Since I have no HW *I* would prefer not to touch it :)
Hmm, that implies a u-boot change, right?
- k
^ permalink raw reply
* Re: [PATCH 0/19 v2] mmu: arch/mm: Port OOM changes to arch page fault handlers.
From: Kautuk Consul @ 2012-03-31 12:15 UTC (permalink / raw)
To: linux-alpha, linuxppc-dev, linux, linux-am33-list,
microblaze-uclinux, linux-m68k, linux-m32r-ja, linux-ia64,
linux-hexagon, linux-cris-kernel, linux-sh, linux-parisc,
linux-mm, linux-arch
Cc: linux-kernel
In-Reply-To: <CAFPAmTT19hFymnFftLkV1jQjYmJgyk3y4b-kTXO3VP1YCR-_fQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 110 bytes --]
Ugh, sorry I forgot to attach the stress_32k.c test-case to this email.
Please find it attached to this one.
[-- Attachment #2: stress_32k.c --]
[-- Type: text/x-csrc, Size: 3897 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>
#include <unistd.h>
#define ALLOC_BYTE 512*1024
#define COUNT 50
void *alloc_function_one( void *ptr );
void *alloc_function_two( void *ptr );
void *alloc_function_three( void *ptr );
void *alloc_function_four( void *ptr );
void *alloc_function_five( void *ptr );
void *enable_function( void *ptr );
int main(int argc, char *argv[])
{
pthread_t thread1, thread2, thread3, thread4, thread5;
char *message1 = "Thread 1";
char *message2 = "Thread 2";
char *message3 = "Thread 3";
char *message4 = "Thread 4";
char *message5 = "Thread 5";
int iret1 = -1;
int iret2 = -1;
int iret3 = -1;
int iret4 = -1;
int iret5 = -1;
fork();
iret1 = pthread_create( &thread1, NULL, alloc_function_one, (void*) message1);
iret2 = pthread_create( &thread2, NULL, alloc_function_two, (void*) message2);
iret2 = pthread_create( &thread3, NULL, alloc_function_three, (void*) message2);
iret2 = pthread_create( &thread4, NULL, alloc_function_four, (void*) message2);
iret2 = pthread_create( &thread5, NULL, alloc_function_five, (void*) message2);
pthread_join( thread1, NULL);
pthread_join( thread2, NULL);
pthread_join( thread3, NULL);
pthread_join( thread4, NULL);
pthread_join( thread5, NULL);
printf("Thread 1 returns: %d\n",iret1);
printf("Thread 2 returns: %d\n",iret2);
printf("Thread 3 returns: %d\n",iret3);
printf("Thread 4 returns: %d\n",iret4);
printf("Thread 5 returns: %d\n",iret5);
exit(0);
}
void *alloc_function_two( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
void *alloc_function_one( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
void *alloc_function_three( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
void *alloc_function_four( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
void *alloc_function_five( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
^ permalink raw reply
* [PATCH 0/19 v2] mmu: arch/mm: Port OOM changes to arch page fault handlers.
From: Kautuk Consul @ 2012-03-31 11:58 UTC (permalink / raw)
To: linux-alpha, linuxppc-dev, linux, linux-am33-list,
microblaze-uclinux, linux-m68k, linux-m32r-ja, linux-ia64,
linux-hexagon, linux-cris-kernel, linux-sh, linux-parisc,
linux-mm, linux-arch
Cc: linux-kernel
In-Reply-To: <CAFPAmTQs9dOpQTaXU=6Or66YU+my_CnPw33TE4h++YArBNa38g@mail.gmail.com>
Commit d065bd810b6deb67d4897a14bfe21f8eb526ba99
(mm: retry page fault when blocking on disk transfer) and
commit 37b23e0525d393d48a7d59f870b3bc061a30ccdb
(x86,mm: make pagefault killable)
The above commits introduced changes into the x86 pagefault handler
for making the page fault handler retryable as well as killable.
These changes reduce the mmap_sem hold time, which is crucial
during OOM killer invocation.
I was facing hang and livelock problems on my ARM and MIPS boards when
I invoked OOM by running the stress_32k.c test-case attached to this email.
Since both the ARM and MIPS porting changes were accepted, me and my
co-worker decided to take the initiative to port these changes to all other
MMU based architectures.
This is v2 of this patch set as there were some problems with the v1 of this
patchset:
- Whitespace issues as reported by David Miller and Joe Perches
- In 2 of the patches, the write(or equivalent) local variable has
been removed from the
page fault handler because it is not really needed anymore with the
advent of the "flags"
local variable. Thanks to Geert Uytterhoeven for that.
- The powerpc patch for this has been removed as this has already been
done by someone
else for powerpc.
At the moment, 8 of these patches have Acked these patches as valid.
I have included their ACKed-By headers for them in their respective
arch patches.
And thanks to Guan Xuetao for actually testing this out on unicore32.
Rest of the arch owners: Please review these patches.
Signed-off-by: Mohd. Faris <mohdfarisq2010@gmail.com>
Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
---
^ permalink raw reply
* teach i2c-mpc to selectively ignore !RXAK errors
From: Anthony Foiani @ 2012-03-31 9:19 UTC (permalink / raw)
To: linuxppc-dev
On the project I'm working on, the hardware engineers put an I2C
device behind a unidirectional level translator. When I tried to
write to it, I was getting EIO due to the lack of receiver ack.
This is my hack to support this situation, based off 3.0.6 with a few
minor additions (none of which impact the I2C bits, SFAICT).
There are really two distinct changes here:
1. Change mpc_read and mpc_write to take a generic "flags" argument,
instead of just passing the message index; and
2. In the very specific case of performing a write when the user has
specified I2C_M_NO_RD_ACK on a message, do not error out on !RXAK
condition.
My apologies for not breaking it down, but I don't have the bandwidth
to respin and track this change. I'm mostly posting it so that other
people can find it if they run into the same issue.
The use of I2C_M_NO_RD_ACK is a bit obscure, but it's barely used in
the kernel, and it makes a certain amount of sense in this context.
Thanks to everyone that's contributed to the PPC Linux stack; it's
made this project (and my current livelihood!) possible.
Best Regards,
Anthony Foiani
-----------------------------------------------------------------------
>From a529752a703bcbb4a751e2e8fef721a65c702c6f Mon Sep 17 00:00:00 2001
From: Anthony Foiani <anthony.foiani@gmail.com>
Date: Wed, 28 Mar 2012 20:51:53 -0600
Subject: [PATCH] Selectively ignore missing RXAK.
Overload the I2C_M_NO_RD_ACK flag to continue with writes even when
the receiver has not acknowledged. This was useful when talking to a
part that was electrically isolated such that it could not drive the
bus lines back to the CPU.
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
---
drivers/i2c/busses/i2c-mpc.c | 46 ++++++++++++++++++++++++-----------------
1 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 107397a..961a0e1 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -48,6 +48,8 @@
#define CCR_TXAK 0x08
#define CCR_RSTA 0x04
+#define CCR_MASK 0xff
+
#define CSR_MCF 0x80
#define CSR_MAAS 0x40
#define CSR_MBB 0x20
@@ -116,7 +118,7 @@ static void mpc_i2c_fixup(struct mpc_i2c *i2c)
}
}
-static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
+static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing, u32 flags)
{
unsigned long orig_jiffies = jiffies;
u32 x;
@@ -163,10 +165,13 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
}
if (writing && (x & CSR_RXAK)) {
- dev_dbg(i2c->dev, "No RXAK\n");
- /* generate stop */
- writeccr(i2c, CCR_MEN);
- return -EIO;
+ if (!(flags & I2C_M_NO_RD_ACK)) {
+ dev_dbg(i2c->dev, "No RXAK\n");
+ /* generate stop */
+ writeccr(i2c, CCR_MEN);
+ return -EIO;
+ }
+ dev_dbg(i2c->dev, "suppressed !RXAK\n");
}
return 0;
}
@@ -426,18 +431,18 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
}
static int mpc_write(struct mpc_i2c *i2c, int target,
- const u8 *data, int length, int restart)
+ const u8 *data, int length, u32 flags)
{
int i, result;
unsigned timeout = i2c->adap.timeout;
- u32 flags = restart ? CCR_RSTA : 0;
/* Start as master */
- writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA | CCR_MTX | flags);
+ writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA |
+ CCR_MTX | (flags & CCR_MASK));
/* Write target byte */
writeb((target << 1), i2c->base + MPC_I2C_DR);
- result = i2c_wait(i2c, timeout, 1);
+ result = i2c_wait(i2c, timeout, 1, flags);
if (result < 0)
return result;
@@ -445,7 +450,7 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write data byte */
writeb(data[i], i2c->base + MPC_I2C_DR);
- result = i2c_wait(i2c, timeout, 1);
+ result = i2c_wait(i2c, timeout, 1, flags);
if (result < 0)
return result;
}
@@ -454,18 +459,18 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
}
static int mpc_read(struct mpc_i2c *i2c, int target,
- u8 *data, int length, int restart)
+ u8 *data, int length, u32 flags)
{
unsigned timeout = i2c->adap.timeout;
int i, result;
- u32 flags = restart ? CCR_RSTA : 0;
/* Switch to read - restart */
- writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA | CCR_MTX | flags);
+ writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA |
+ CCR_MTX | (flags & CCR_MASK));
/* Write target address byte - this time with the read flag set */
writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
- result = i2c_wait(i2c, timeout, 1);
+ result = i2c_wait(i2c, timeout, 1, flags);
if (result < 0)
return result;
@@ -479,7 +484,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
}
for (i = 0; i < length; i++) {
- result = i2c_wait(i2c, timeout, 0);
+ result = i2c_wait(i2c, timeout, 0, flags);
if (result < 0)
return result;
@@ -502,6 +507,7 @@ static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
int ret = 0;
unsigned long orig_jiffies = jiffies;
struct mpc_i2c *i2c = i2c_get_adapdata(adap);
+ u32 restart;
mpc_i2c_start(i2c);
@@ -526,6 +532,7 @@ static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
schedule();
}
+ restart = 0;
for (i = 0; ret >= 0 && i < num; i++) {
pmsg = &msgs[i];
dev_dbg(i2c->dev,
@@ -533,11 +540,12 @@ static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
pmsg->flags & I2C_M_RD ? "read" : "write",
pmsg->len, pmsg->addr, i + 1, num);
if (pmsg->flags & I2C_M_RD)
- ret =
- mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ ret = mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart | (pmsg->flags & ~CCR_MASK));
else
- ret =
- mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ ret = mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart | (pmsg->flags & ~CCR_MASK));
+ restart = CCR_RSTA;
}
mpc_i2c_stop(i2c);
return (ret < 0) ? ret : num;
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH] Bug fix in commit 178db7d3 triggered a bug in the SPI driver for MPC83XX (pdata is NULL).
From: Grant Likely @ 2012-03-30 22:25 UTC (permalink / raw)
To: Kenth Eriksson, spi-devel-general, linuxppc-dev, joakim.tjernlund
Cc: Kenth Eriksson
In-Reply-To: <1333119930-21129-1-git-send-email-kenth.eriksson@transmode.com>
On Fri, 30 Mar 2012 17:05:30 +0200, Kenth Eriksson <kenth.eriksson@transmode.com> wrote:
> After commit 178db7d3 devices are initialized as children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization.
>
> Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
Applied; but I have a comments on your commit text.
SHA1 id's are great for looking up commits, but they don't help at all
for casual readers on the mailing list or doing web searches. Please
always include the commit title when referencing an earlier commit. I
had to edit the commit text. Here is what I changed it to:
spi/mpc83xx: fix NULL pdata dereference bug
Commit 178db7d3, "spi: Fix device unregistration when unregistering
the bus master", changed device initialization to be children of the
bus master, not children of the bus masters parent device. The pdata
pointer used in fsl_spi_chipselect must updated to reflect the changed
initialization.
g.
> ---
> drivers/spi/spi-fsl-spi.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
> index 7d6ca68..dc747a0 100644
> --- a/drivers/spi/spi-fsl-spi.c
> +++ b/drivers/spi/spi-fsl-spi.c
> @@ -139,10 +139,12 @@ static void fsl_spi_change_mode(struct spi_device *spi)
> static void fsl_spi_chipselect(struct spi_device *spi, int value)
> {
> struct mpc8xxx_spi *mpc8xxx_spi = spi_master_get_devdata(spi->master);
> - struct fsl_spi_platform_data *pdata = spi->dev.parent->platform_data;
> + struct fsl_spi_platform_data *pdata;
> bool pol = spi->mode & SPI_CS_HIGH;
> struct spi_mpc8xxx_cs *cs = spi->controller_state;
>
> + pdata = spi->dev.parent->parent->platform_data;
> +
> if (value == BITBANG_CS_INACTIVE) {
> if (pdata->cs_control)
> pdata->cs_control(spi, !pol);
> --
> 1.7.3.4
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> spi-devel-general mailing list
> spi-devel-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Benjamin Herrenschmidt @ 2012-03-31 0:03 UTC (permalink / raw)
To: Frank Svendsbøe; +Cc: linuxppc-dev, Wolfgang Denk, robert.karl.berger
In-Reply-To: <CADNf2swF2EVO2u-yPziF2z6HyF6jRBvVsQC2nbY=W2sXJpp2hQ@mail.gmail.com>
On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote:
> Hi Josh Boyer,
>
> just wanted to add that I'm experiencing the same problem that Robert
> reported, but on 8xx instead of 4xx. The mpc8xx does not support the
> mfdcrx instruction, so maybe it's more to it than just a binutils bug?
The kernel shouldn't have tried to build that instruction on 8xx, though
I suppose if it's in arch/powerpc/boot, we are a bit too eager at
building everything including what's not relevant, we might to be a bit
more careful at excluding 4xx stuff on a 8xx kernel.
Can you give us the exact error ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: fix fallout from system.h split up
From: Stephen Rothwell @ 2012-03-31 0:01 UTC (permalink / raw)
To: Linus; +Cc: David Howells, ppc-dev
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/fadump.c | 2 ++
arch/powerpc/kernel/kgdb.c | 1 +
2 files changed, 3 insertions(+)
Just a resend of what I sent yesterday - this is what I am using in
linux-next. Linus, please apply.
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index cfe7a38..18bdf74 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -40,6 +40,8 @@
#include <asm/prom.h>
#include <asm/rtas.h>
#include <asm/fadump.h>
+#include <asm/debug.h>
+#include <asm/setup.h>
static struct fw_dump fw_dump;
static struct fadump_mem_struct fdm;
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 76a6e40..782bd0a 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -24,6 +24,7 @@
#include <asm/current.h>
#include <asm/processor.h>
#include <asm/machdep.h>
+#include <asm/debug.h>
/*
* This table contains the mapping between PowerPC hardware trap types, and
--
1.7.9.5
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Frank Svendsbøe @ 2012-03-30 22:53 UTC (permalink / raw)
To: Josh Boyer; +Cc: Wolfgang Denk, robert.karl.berger, linuxppc-dev
In-Reply-To: <CA+5PVA4pGhbrM1P8Dbjaxw_1_ZgEweimLCSc1xrw0Rombr_2rg@mail.gmail.com>
On Mon, Mar 26, 2012 at 3:36 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Sat, Mar 24, 2012 at 7:53 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Wed, 2012-03-21 at 17:25 +0100, Wolfgang Denk wrote:
>>> > > The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes
>>> with the
>>> > > ELDK 4.2) this assembly instruction is not known and the build
>>> breaks.
>>> >
>>> > Sigh. =A0GCC 4.2 is pretty old at this point.
>>>
>>> But still rock-solid ... =A0We use it a lot, especially as reference fo=
r
>>> more recent (and sometimes more broken) versions of GCC.
>>
>> Isn't this a binutils rather than gcc issue ?
>
> Pretty much.
>
Hi Josh Boyer,
just wanted to add that I'm experiencing the same problem that Robert
reported, but on 8xx instead of 4xx. The mpc8xx does not support the
mfdcrx instruction, so maybe it's more to it than just a binutils bug?
Best regards,
Frank
^ permalink raw reply
* [PATCH v2 10/15] powerpc: mark const init data with __initconst instead of __initdata
From: Uwe Kleine-König @ 2012-03-30 20:05 UTC (permalink / raw)
To: linux-kernel, Andrew Morton
Cc: cbe-oss-dev, Arnd Bergmann, Paul Mackerras, kernel,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20120330200358.GV15647@pengutronix.de>
As long as there is no other non-const variable marked __initdata in the
same compilation unit it doesn't hurt. If there were one however
compilation would fail with
error: $variablename causes a section type conflict
because a section containing const variables is marked read only and so
cannot contain non-const variables.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Josh Boyer <jwboyer@gmail.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: cbe-oss-dev@lists.ozlabs.org
---
changes since (implicit) v1:
- drop wrong changes to several files:
- arch/powerpc/platforms/40x/ppc40x_simple.c
- arch/powerpc/platforms/512x/mpc5121_generic.c
- arch/powerpc/platforms/52xx/lite5200.c
- arch/powerpc/platforms/52xx/media5200.c
- arch/powerpc/platforms/52xx/mpc5200_simple.c
- arch/powerpc/platforms/83xx/mpc830x_rdb.c
- arch/powerpc/platforms/83xx/mpc831x_rdb.c
- arch/powerpc/platforms/83xx/mpc837x_rdb.c
- arch/powerpc/platforms/85xx/tqm85xx.c
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 2 +-
arch/powerpc/platforms/cell/qpace_setup.c | 2 +-
arch/powerpc/platforms/cell/setup.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index bfb11e0..e2d401a 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -93,7 +93,7 @@ struct mpc52xx_pci {
};
/* MPC5200 device tree match tables */
-const struct of_device_id mpc52xx_pci_ids[] __initdata = {
+const struct of_device_id mpc52xx_pci_ids[] __initconst = {
{ .type = "pci", .compatible = "fsl,mpc5200-pci", },
{ .type = "pci", .compatible = "mpc5200-pci", },
{}
diff --git a/arch/powerpc/platforms/cell/qpace_setup.c b/arch/powerpc/platforms/cell/qpace_setup.c
index 7f9b674..6e3409d 100644
--- a/arch/powerpc/platforms/cell/qpace_setup.c
+++ b/arch/powerpc/platforms/cell/qpace_setup.c
@@ -61,7 +61,7 @@ static void qpace_progress(char *s, unsigned short hex)
printk("*** %04x : %s\n", hex, s ? s : "");
}
-static const struct of_device_id qpace_bus_ids[] __initdata = {
+static const struct of_device_id qpace_bus_ids[] __initconst = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "spider", },
diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
index fa3e294..4ab0876 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -140,7 +140,7 @@ static int __devinit cell_setup_phb(struct pci_controller *phb)
return 0;
}
-static const struct of_device_id cell_bus_ids[] __initdata = {
+static const struct of_device_id cell_bus_ids[] __initconst = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "spider", },
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 00/15] mark const init data with __initconst instead of __initdata
From: Uwe Kleine-König @ 2012-03-30 20:03 UTC (permalink / raw)
To: linux-kernel, Andrew Morton
Cc: Andrew Lunn, Christoph Lameter, linux-mips, Tony Lindgren,
Linus Walleij, Nicolas Ferre, Matthew Garrett,
platform-driver-x86, ibm-acpi-devel, Randy Dunlap, linux-mtd,
Sekhar Nori, Daniel Walker, lm-sensors, Klaus Kudielka,
Guenter Roeck, Kevin Hilman, linux-ia64, Kukjin Kim, Russell King,
Samuel Ortiz, Yoshinori Sato, Lennert Buytenhek, Kyungmin Park,
David Brown, Anatolij Gustschin, Jean-Christophe Plagniol-Villard,
Alexey Dobriyan, Joerg Reuter, linux-media, cbe-oss-dev,
Fenghua Yu, Arnd Bergmann, Tony Luck, Lucas De Marchi,
linux-arm-msm, Andreas Koensgen, Henrique de Moraes Holschuh,
Haojian Zhuang, Mauro Carvalho Chehab, Tejun Heo,
linux-samsung-soc, linux-mm, Barry Song, linux-hams, linux-omap,
Andrew Victor, linux-arm-kernel, David Howells,
davinci-linux-open-source, Jean-Paul Roubelat, Eric Miao,
Linus Walleij, linux-ide, linuxppc-dev, Nicolas Pitre,
Ralf Baechle, Tomasz Stanislawski, Bryan Huntsman, Sascha Hauer,
netdev, Jean Delvare, Paul Mackerras, Shawn Guo, David Woodhouse,
David S. Miller
In-Reply-To: <20120329211131.GA31250@pengutronix.de>
Hello,
On Thu, Mar 29, 2012 at 11:11:31PM +0200, Uwe Kleine-König wrote:
> this series fixes a common error to use __initdata to mark const
> variables. Most of the time this works well enough to go unnoticed
> (though I wonder why the linker doesn't warn about that).
> Just try adding something like
>
> int something __initdata;
>
> to one of the patched files and compile to see the error.
>
> While touching these annotations I also corrected the position where it
> was wrong to go between the variable name and the =.
>
> Note this series is not compile tested.
I now dropped the wrong annotations. So two patches became obsolete
(mtd and percpu). Note that I also dropped fixing the position of
__initdata if changing it to __initconst was wrong. (I think if
__initdata is placed before the variable name it doesn't have any
effect.)
I didn't promote the Acks I got because all acked changes changed in v2.
For the details changed in each patch see the changelogs in the
respective patch mails that I follow up to this mail.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [REGRESSION][PATCH V4 1/3] bpf jit: Make the filter.c::__load_pointer helper non-static for the jits
From: Eric Dumazet @ 2012-03-30 18:56 UTC (permalink / raw)
To: Jan Seiffert
Cc: netdev, linuxppc-dev, linux-kernel, Matt Evans, David S. Miller
In-Reply-To: <4F75CC63.10405@googlemail.com>
On Fri, 2012-03-30 at 17:08 +0200, Jan Seiffert wrote:
> The function is renamed to make it a little more clear what it does.
> It is not added to any .h because it is not for general consumption, only for
> bpf internal use (and so by the jits).
>
> Signed-of-by: Jan Seiffert <kaffeemonster@googlemail.com>
>
Missing "---" line separator (check Documentation/SubmittingPatches line
490)
You can check http://patchwork.ozlabs.org/patch/149683/ and see there is
a problem, compared to http://patchwork.ozlabs.org/patch/149441/ for
example
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -40,8 +40,12 @@
> #include <linux/reciprocal_div.h>
> #include <linux/ratelimit.h>
>
> -/* No hurry in this branch */
> -static void *__load_pointer(const struct sk_buff *skb, int k, unsigned int size)
> +/*
> + * No hurry in this branch
> + *
> + * Exported for the bpf jit load helper.
> + */
Seems good to me, maybe add a strong warning in the comment to say that
function prototype can NOT change without major surgery in ASM files,
since assembler wont catch the prototype change for us.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* [REGRESSION][PATCH V4 0/3] bpf jit drops the ball on negative memory references
From: Jan Seiffert @ 2012-03-30 15:00 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, linuxppc-dev, linux-kernel, Matt Evans,
David S. Miller
Consider the following test program:
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <pcap-bpf.h>
#define die(x) do {perror(x); return 1;} while (0)
struct bpf_insn udp_filter[] = {
/* 0 */ BPF_STMT(BPF_LDX|BPF_W|BPF_IMM, -1048576+(0)), /* leax net[0] */
/* 1 */ BPF_STMT(BPF_LD|BPF_B|BPF_IND, 0), /* ldb [x+0] */
/* 2 */ BPF_STMT(BPF_RET|BPF_A, 0), /* ret a */
};
int main(int argc, char *argv[])
{
char buf[512];
struct sockaddr_in addr;
struct bpf_program prg;
socklen_t addr_s;
ssize_t res;
int fd;
addr.sin_family = AF_INET;
addr.sin_port = htons(5000);
addr.sin_addr.s_addr = 0;
addr_s = sizeof(addr);
prg.bf_len = sizeof(udp_filter)/sizeof(udp_filter[0]);
prg.bf_insns = udp_filter;
if(-1 == (fd = socket(AF_INET, SOCK_DGRAM, 0)))
die("socket");
if(-1 == bind(fd, (struct sockaddr *)&addr, sizeof(addr)))
die("bind");
if(-1 == setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, &prg, sizeof(prg)))
die("setsockopt");
res = recvfrom(fd, buf, sizeof(buf), 0, (struct sockaddr *)&addr, &addr_s);
if(res != -1)
printf("packet received: %zi bytes\n", res);
else
die("recvfrom");
return 0;
}
when used with the bpf jit disabled works:
console 1 $ ./bpf
console 2 $ echo "hello" | nc -u localhost 5000
console 1: packet received: 6 bytes
When the bpf jit gets enabled (echo 100 >
/proc/sys/net/core/bpf_jit_enable) the same program stops working:
console 1 $ ./bpf
console 2 $ echo "hello" | nc -u localhost 5000
console 1:
The reason is that both jits (x86 and powerpc) do not handle negative
memory references like SKF_NET_OFF or SKF_LL_OFF, only the simple
ancillary data references are supported (by mapping to special
instructions).
In the case of an absolute reference, the jit aborts the translation
if a negative reference is seen, also a negative k on the indirect
load aborts the translation, but if X is negative to begin with, only
the error handler is reached at runtime which drops the whole packet.
Such a setup is useful to say filter bogus source addresses on an UDP
socket.
I propose the following patch series to fix this situation.
Patch 1 exports the helper function the interpreter uses.
Patch 2 incorporates the helper into the x86 jit (so it depends on patch 1).
Patch 3 incorporates the helper into the powerpc jit (so it depends on patch 1).
Lightly tested on x86, but the powerpc asm part is prop. wrong, could
need assistance.
Signed-of-by: Jan Seiffert <kaffeemonster@googlemail.com>
^ permalink raw reply
* [REGRESSION][PATCH V4 1/3] bpf jit: Make the filter.c::__load_pointer helper non-static for the jits
From: Jan Seiffert @ 2012-03-30 15:08 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, linuxppc-dev, linux-kernel, Matt Evans,
David S. Miller
In-Reply-To: <4F75CA89.4010709@googlemail.com>
The function is renamed to make it a little more clear what it does.
It is not added to any .h because it is not for general consumption, only for
bpf internal use (and so by the jits).
Signed-of-by: Jan Seiffert <kaffeemonster@googlemail.com>
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -40,8 +40,12 @@
#include <linux/reciprocal_div.h>
#include <linux/ratelimit.h>
-/* No hurry in this branch */
-static void *__load_pointer(const struct sk_buff *skb, int k, unsigned int size)
+/*
+ * No hurry in this branch
+ *
+ * Exported for the bpf jit load helper.
+ */
+void *bpf_internal_load_pointer_neg_helper(const struct sk_buff *skb, int k, unsigned int size)
{
u8 *ptr = NULL;
@@ -60,7 +64,7 @@ static inline void *load_pointer(const struct sk_buff *skb, int k,
{
if (k >= 0)
return skb_header_pointer(skb, k, size, buffer);
- return __load_pointer(skb, k, size);
+ return bpf_internal_load_pointer_neg_helper(skb, k, size);
}
/**
^ permalink raw reply
* [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
From: Jan Seiffert @ 2012-03-30 15:35 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, linuxppc-dev, linux-kernel, Matt Evans,
David S. Miller
In-Reply-To: <4F75CA89.4010709@googlemail.com>
Now the helper function from filter.c for negative offsets is exported,
it can be used it in the jit to handle negative offsets.
First modify the asm load helper functions to handle:
- know positive offsets
- know negative offsets
- any offset
then the compiler can be modified to explicitly use these helper
when appropriate.
This fixes the case of a negative X register and allows to lift
the restriction that bpf programs with negative offsets can't
be jited.
Signed-off-by: Jan Seiffert <kaffeemonster@googlemail.com>
I have only compile tested this, -ENOHARDWARE.
Can someone with more powerpc kung-fu review and maybe test this?
Esp. powerpc asm is not my strong point. I think i botched the
stack frame in the call setup. Help?
diff --git a/arch/powerpc/net/bpf_jit_64.S b/arch/powerpc/net/bpf_jit_64.S
index ff4506e..e590aa5 100644
--- a/arch/powerpc/net/bpf_jit_64.S
+++ b/arch/powerpc/net/bpf_jit_64.S
@@ -31,14 +31,13 @@
* then branch directly to slow_path_XXX if required. (In fact, could
* load a spare GPR with the address of slow_path_generic and pass size
* as an argument, making the call site a mtlr, li and bllr.)
- *
- * Technically, the "is addr < 0" check is unnecessary & slowing down
- * the ABS path, as it's statically checked on generation.
*/
.globl sk_load_word
sk_load_word:
cmpdi r_addr, 0
- blt bpf_error
+ blt bpf_slow_path_word_neg
+ .globl sk_load_word_positive_offset
+sk_load_word_positive_offset:
/* Are we accessing past headlen? */
subi r_scratch1, r_HL, 4
cmpd r_scratch1, r_addr
@@ -51,7 +50,9 @@ sk_load_word:
.globl sk_load_half
sk_load_half:
cmpdi r_addr, 0
- blt bpf_error
+ blt bpf_slow_path_half_neg
+ .globl sk_load_half_positive_offset
+sk_load_half_positive_offset:
subi r_scratch1, r_HL, 2
cmpd r_scratch1, r_addr
blt bpf_slow_path_half
@@ -61,7 +62,9 @@ sk_load_half:
.globl sk_load_byte
sk_load_byte:
cmpdi r_addr, 0
- blt bpf_error
+ blt bpf_slow_path_byte_neg
+ .globl sk_load_byte_positive_offset
+sk_load_byte_positive_offset:
cmpd r_HL, r_addr
ble bpf_slow_path_byte
lbzx r_A, r_D, r_addr
@@ -69,22 +72,20 @@ sk_load_byte:
/*
* BPF_S_LDX_B_MSH: ldxb 4*([offset]&0xf)
- * r_addr is the offset value, already known positive
+ * r_addr is the offset value
*/
.globl sk_load_byte_msh
sk_load_byte_msh:
+ cmpdi r_addr, 0
+ blt bpf_slow_path_byte_msh_neg
+ .globl sk_load_byte_msh_positive_offset
+sk_load_byte_msh_positive_offset:
cmpd r_HL, r_addr
ble bpf_slow_path_byte_msh
lbzx r_X, r_D, r_addr
rlwinm r_X, r_X, 2, 32-4-2, 31-2
blr
-bpf_error:
- /* Entered with cr0 = lt */
- li r3, 0
- /* Generated code will 'blt epilogue', returning 0. */
- blr
-
/* Call out to skb_copy_bits:
* We'll need to back up our volatile regs first; we have
* local variable space at r1+(BPF_PPC_STACK_BASIC).
@@ -136,3 +137,85 @@ bpf_slow_path_byte_msh:
lbz r_X, BPF_PPC_STACK_BASIC+(2*8)(r1)
rlwinm r_X, r_X, 2, 32-4-2, 31-2
blr
+
+/* Call out to bpf_internal_load_pointer_neg_helper:
+ * We'll need to back up our volatile regs first; we have
+ * local variable space at r1+(BPF_PPC_STACK_BASIC).
+ * Allocate a new stack frame here to remain ABI-compliant in
+ * stashing LR.
+ */
+#define sk_negative_common(SIZE) \
+ mflr r0; \
+ std r0, 16(r1); \
+ /* R3 goes in parameter space of caller's frame */ \
+ std r_skb, (BPF_PPC_STACKFRAME+48)(r1); \
+ std r_A, (BPF_PPC_STACK_BASIC+(0*8))(r1); \
+ std r_X, (BPF_PPC_STACK_BASIC+(1*8))(r1); \
+ stdu r1, -BPF_PPC_SLOWPATH_FRAME(r1); \
+ /* R3 = r_skb, as passed */ \
+ mr r4, r_addr; \
+ li r5, SIZE; \
+ bl bpf_internal_load_pointer_neg_helper; \
+ /* R3 != 0 on success */ \
+ addi r1, r1, BPF_PPC_SLOWPATH_FRAME; \
+ ld r0, 16(r1); \
+ ld r_A, (BPF_PPC_STACK_BASIC+(0*8))(r1); \
+ ld r_X, (BPF_PPC_STACK_BASIC+(1*8))(r1); \
+ mtlr r0; \
+ cmpldi r3, 0; \
+ beq bpf_error_slow; /* cr0 = EQ */ \
+ mr r_addr, r3; \
+ ld r_skb, (BPF_PPC_STACKFRAME+48)(r1); \
+ /* Great success! */
+
+bpf_slow_path_word_neg:
+ lis r_scratch1,-32 /* SKF_LL_OFF */
+ cmpd r_addr, r_scratch1 /* addr < SKF_* */
+ blt bpf_error /* cr0 = LT */
+ .globl sk_load_word_negative_offset
+sk_load_word_negative_offset:
+ sk_negative_common(4)
+ lwz r_A, 0(r_addr)
+ blr
+
+bpf_slow_path_half_neg:
+ lis r_scratch1,-32 /* SKF_LL_OFF */
+ cmpd r_addr, r_scratch1 /* addr < SKF_* */
+ blt bpf_error /* cr0 = LT */
+ .globl sk_load_half_negative_offset
+sk_load_half_negative_offset:
+ sk_negative_common(2)
+ lhz r_A, 0(r_addr)
+ blr
+
+bpf_slow_path_byte_neg:
+ lis r_scratch1,-32 /* SKF_LL_OFF */
+ cmpd r_addr, r_scratch1 /* addr < SKF_* */
+ blt bpf_error /* cr0 = LT */
+ .globl sk_load_byte_negative_offset
+sk_load_byte_negative_offset:
+ sk_negative_common(1)
+ lbz r_A, 0(r_addr)
+ blr
+
+bpf_slow_path_byte_msh_neg:
+ lis r_scratch1,-32 /* SKF_LL_OFF */
+ cmpd r_addr, r_scratch1 /* addr < SKF_* */
+ blt bpf_error /* cr0 = LT */
+ .globl sk_load_byte_msh_negative_offset
+sk_load_byte_msh_negative_offset:
+ sk_negative_common(1)
+ lbz r_X, 0(r_addr)
+ rlwinm r_X, r_X, 2, 32-4-2, 31-2
+ blr
+
+bpf_error_slow:
+ /* fabricate a cr0 = lt */
+ li r_scratch1, -1
+ cmpdi r_scratch1, 0
+bpf_error:
+ /* Entered with cr0 = lt */
+ li r3, 0
+ /* Generated code will 'blt epilogue', returning 0. */
+ blr
+
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 73619d3..2dc8b14 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -127,6 +127,9 @@ static void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
PPC_BLR();
}
+#define CHOOSE_LOAD_FUNC(K, func) \
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+
/* Assemble the body code between the prologue & epilogue. */
static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
struct codegen_context *ctx,
@@ -391,21 +394,16 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
/*** Absolute loads from packet header/data ***/
case BPF_S_LD_W_ABS:
- func = sk_load_word;
+ func = CHOOSE_LOAD_FUNC(K, sk_load_word);
goto common_load;
case BPF_S_LD_H_ABS:
- func = sk_load_half;
+ func = CHOOSE_LOAD_FUNC(K, sk_load_half);
goto common_load;
case BPF_S_LD_B_ABS:
- func = sk_load_byte;
+ func = CHOOSE_LOAD_FUNC(K, sk_load_byte);
common_load:
- /*
- * Load from [K]. Reference with the (negative)
- * SKF_NET_OFF/SKF_LL_OFF offsets is unsupported.
- */
+ /* Load from [K]. */
ctx->seen |= SEEN_DATAREF;
- if ((int)K < 0)
- return -ENOTSUPP;
PPC_LI64(r_scratch1, func);
PPC_MTLR(r_scratch1);
PPC_LI32(r_addr, K);
@@ -429,7 +427,7 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
common_load_ind:
/*
* Load from [X + K]. Negative offsets are tested for
- * in the helper functions, and result in a 'ret 0'.
+ * in the helper functions.
*/
ctx->seen |= SEEN_DATAREF | SEEN_XREG;
PPC_LI64(r_scratch1, func);
@@ -443,13 +441,7 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
break;
case BPF_S_LDX_B_MSH:
- /*
- * x86 version drops packet (RET 0) when K<0, whereas
- * interpreter does allow K<0 (__load_pointer, special
- * ancillary data). common_load returns ENOTSUPP if K<0,
- * so we fall back to interpreter & filter works.
- */
- func = sk_load_byte_msh;
+ func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
goto common_load;
break;
^ permalink raw reply related
* Re: [PATCH] Bug fix in commit 178db7d3 triggered a bug in the SPI driver for MPC83XX (pdata is NULL).
From: Joakim Tjernlund @ 2012-03-30 15:16 UTC (permalink / raw)
To: Kenth Eriksson; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <1333119930-21129-1-git-send-email-kenth.eriksson@transmode.com>
Kenth Eriksson <kenth.eriksson@transmode.com> wrote on 2012/03/30 17:05:30:
>
> After commit 178db7d3 devices are initialized as children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization.
>
> Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
^ permalink raw reply
* [PATCH] Bug fix in commit 178db7d3 triggered a bug in the SPI driver for MPC83XX (pdata is NULL).
From: Kenth Eriksson @ 2012-03-30 15:05 UTC (permalink / raw)
To: spi-devel-general, linuxppc-dev, joakim.tjernlund; +Cc: Kenth Eriksson
After commit 178db7d3 devices are initialized as children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization.
Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
---
drivers/spi/spi-fsl-spi.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
index 7d6ca68..dc747a0 100644
--- a/drivers/spi/spi-fsl-spi.c
+++ b/drivers/spi/spi-fsl-spi.c
@@ -139,10 +139,12 @@ static void fsl_spi_change_mode(struct spi_device *spi)
static void fsl_spi_chipselect(struct spi_device *spi, int value)
{
struct mpc8xxx_spi *mpc8xxx_spi = spi_master_get_devdata(spi->master);
- struct fsl_spi_platform_data *pdata = spi->dev.parent->platform_data;
+ struct fsl_spi_platform_data *pdata;
bool pol = spi->mode & SPI_CS_HIGH;
struct spi_mpc8xxx_cs *cs = spi->controller_state;
+ pdata = spi->dev.parent->parent->platform_data;
+
if (value == BITBANG_CS_INACTIVE) {
if (pdata->cs_control)
pdata->cs_control(spi, !pol);
--
1.7.3.4
^ permalink raw reply related
* Re: powerpc/85xx: p2020rdb - move the NAND address.
From: Sebastian Andrzej Siewior @ 2012-03-30 14:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: Bryan Hundven, linuxppc-dev
In-Reply-To: <9460468D-281C-4960-839A-F8435638DE4B@kernel.crashing.org>
On 03/29/2012 03:10 PM, Kumar Gala wrote:
>> - include/configs/P1_P2_RDB.h
>>
>> #ifndef CONFIG_NAND_SPL
>> #define CONFIG_SYS_NAND_BASE 0xffa00000
>> #ifdef CONFIG_PHYS_64BIT
>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull
>> #else
>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>> #endif
>> #else
>> #define CONFIG_SYS_NAND_BASE 0xfff00000
>> #ifdef CONFIG_PHYS_64BIT
>> #define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull
>> #else
>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>> #endif
>> #endif
>>
>> - include/configs/p1_p2_rdb_pc.h
>>
>> #ifdef CONFIG_NAND_FSL_ELBC
>> #define CONFIG_SYS_NAND_BASE 0xff800000
>> #ifdef CONFIG_PHYS_64BIT
>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull
>> #else
>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>> #endif
>>
>
> There are two (well 3 since rdb-pc has both 32b& 36b) in the tree now:
>
> arch/powerpc/boot/dts/p2020rdb.dts
> arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
> arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
Okay. So I assume that one has the proper NAND address and my patch
should be reverted then. Do want a patch from me for that?
>> Since both system have the same SoC and the NAND_SPL is always linked
>> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
>> later to 0xff800000 (or to 0xffa00000) and having it consistent among
>> both configs.
what about this thing? Should leave it as it or move to the same
location? Since I have no HW *I* would prefer not to touch it :)
>
> - k
Sebastian
^ permalink raw reply
* Re: [PATCH 00/17] mark const init data with __initconst instead of __initdata
From: Uwe Kleine-König @ 2012-03-30 9:59 UTC (permalink / raw)
To: linux-kernel, Andrew Morton
Cc: Andrew Lunn, Christoph Lameter, linux-mips, Tony Lindgren,
Linus Walleij, Nicolas Ferre, Matthew Garrett,
platform-driver-x86, ibm-acpi-devel, Randy Dunlap, linux-mtd,
Sekhar Nori, Daniel Walker, lm-sensors, Klaus Kudielka,
Guenter Roeck, Kevin Hilman, linux-ia64, Kukjin Kim, Russell King,
Samuel Ortiz, Yoshinori Sato, Lennert Buytenhek, Kyungmin Park,
David Brown, Anatolij Gustschin, Jean-Christophe Plagniol-Villard,
Alexey Dobriyan, Joerg Reuter, linux-media, cbe-oss-dev,
Fenghua Yu, Arnd Bergmann, Tony Luck, Lucas De Marchi,
linux-arm-msm, Andreas Koensgen, Henrique de Moraes Holschuh,
Haojian Zhuang, Mauro Carvalho Chehab, Tejun Heo,
linux-samsung-soc, linux-mm, Barry Song, linux-hams, linux-omap,
Andrew Victor, linux-arm-kernel, David Howells,
davinci-linux-open-source, Jean-Paul Roubelat, Eric Miao,
Linus Walleij, linux-ide, linuxppc-dev, Nicolas Pitre,
Ralf Baechle, Tomasz Stanislawski, Bryan Huntsman, Sascha Hauer,
netdev, Jean Delvare, Paul Mackerras, Shawn Guo, David Woodhouse,
David S. Miller
In-Reply-To: <20120329211131.GA31250@pengutronix.de>
On Thu, Mar 29, 2012 at 11:11:31PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this series fixes a common error to use __initdata to mark const
> variables. Most of the time this works well enough to go unnoticed
> (though I wonder why the linker doesn't warn about that).
> Just try adding something like
>
> int something __initdata;
>
> to one of the patched files and compile to see the error.
>
> While touching these annotations I also corrected the position where it
> was wrong to go between the variable name and the =.
>
> Note this series is not compile tested.
After a question by Shawn Guo I noticed that my command to do the changes
was to lax and changed things that must not be changed (at least not
with further care). Affected are lines like:
static const char *at91_dt_board_compat[] __initconst = {
While at91_dt_board_compat[0] is const, at91_dt_board_compat is not.
I will send a fixed series later today.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] powerpc: select PPC_CLOCK unconditionally for FSL_SOC
From: Shawn Guo @ 2012-03-30 5:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: alsa-devel, Shawn Guo, Timur Tabi
Freescale PowerPC SoCs share a number of IP blocks with Freescale
ARM/IMX SoCs, FlexCAN, SSI, FEC, eSDHC, USB, etc. There are some
effort consolidating those drivers to make them work for both
architectures.
One outstanding difference between two architectures is ARM/IMX will
turn off module clocks during platform initialization for power saving
and expects drivers manage clocks using clk API, while PowerPC
mostly does not do that, and thus does not always build in clk API.
Listing all those driver Kconfig options in "select PPC_CLOCK if" seems
not scalable for long term maintenance, and could easily introduce
Kconfig recursive dependency. This patch chooses to select PPC_CLOCK
unconditionally for FSL_SOC to always build clk API for PowerPC in.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
arch/powerpc/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index feab3ba..63fa7fb 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -661,7 +661,7 @@ config SBUS
config FSL_SOC
bool
select HAVE_CAN_FLEXCAN if NET && CAN
- select PPC_CLOCK if CAN_FLEXCAN
+ select PPC_CLOCK
config FSL_PCI
bool
--
1.7.5.4
^ permalink raw reply related
* RE: powerpc/85xx: p2020rdb - move the NAND address.
From: Bryan Hundven @ 2012-03-29 23:17 UTC (permalink / raw)
To: Kumar Gala, Sebastian Andrzej Siewior; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5cfxnrfxtgpc584nns33030w.1333045723838@email.android.com>
[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]
One final question on this change is: If the nand base address was wrong in the kernel, but right in u-boot, how did this work before this change and what kinds of problems would I see with the old base address value in the kernel.
Thanks for your time in advance,
-Bryan
________________________________
From: Bryan Hundven
Sent: Thursday, March 29, 2012 11:28 AM
To: Kumar Gala; Sebastian Andrzej Siewior
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: powerpc/85xx: p2020rdb - move the NAND address.
Kumar,
Sorry, i should have posted to the ml.
Thank you, I was looking in the wrong spot.
Cheers,
-Bryan
Kumar Gala <galak@kernel.crashing.org> wrote:
On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:
> On 03/28/2012 10:30 PM, Bryan Hundven wrote:
>> > It is not at 0xffa00000. According to current u-boot source the NAND
>> > controller is always at 0xff800000 and it is either at CS0 or CS1
>> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
>> > 0xfff800000 but it has always an eight there and never an A.
>> >
>> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> I am having a hard time verifying this change. I don't think you are
>> wrong, I'm just having a hard time following.
>>
>> I do not see where this has always been 0xff800000 in u-boot.
>
> <cut>
>
>> But while I was checking changes in arch/powerpc/, I found this change
>> and wanted to understand why 0xffa00000 has worked for us for so long?
>
> Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
> provides two different configs, not just one define like its for
> SPL/SPI/...:
>
> - include/configs/P1_P2_RDB.h
>
> #ifndef CONFIG_NAND_SPL
> #define CONFIG_SYS_NAND_BASE 0xffa00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
> #else
> #define CONFIG_SYS_NAND_BASE 0xfff00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
> #endif
>
> - include/configs/p1_p2_rdb_pc.h
>
> #ifdef CONFIG_NAND_FSL_ELBC
> #define CONFIG_SYS_NAND_BASE 0xff800000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
>
> and for kernel they use both the same device tree. So with the change,
> the _pc variant finds its flash. Before that it worked for the non-pc
> variant only if NAND_SPL wasn't used.
> Any suggestion on fixing that? Providing a new dt for _pc would "fix"
> it but the non pc variant won't find it in the case of NAND_SPL.
There are two (well 3 since rdb-pc has both 32b & 36b) in the tree now:
arch/powerpc/boot/dts/p2020rdb.dts
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
>
> Since both system have the same SoC and the NAND_SPL is always linked
> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
> later to 0xff800000 (or to 0xffa00000) and having it consistent among
> both configs.
- k
[-- Attachment #2: Type: text/html, Size: 5272 bytes --]
^ permalink raw reply
* Re: [GIT PULL] Disintegrate and kill asm/system.h
From: Grant Likely @ 2012-03-29 22:16 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-arch, Stephen Rothwell, Michael Neuling, arnd, ppc-dev,
linux-kernel, David Howells, paul.gortmaker, hpa, akpm,
Linus Torvalds
In-Reply-To: <alpine.LFD.2.02.1203292344140.2542@ionos>
On Thu, Mar 29, 2012 at 3:48 PM, Thomas Gleixner <tglx@linutronix.de> wrote=
:
> On Thu, 29 Mar 2012, Grant Likely wrote:
>> On Thu, Mar 29, 2012 at 2:11 AM, Benjamin Herrenschmidt
>> The rightmost fields of /proc/interrupts are a weird set of
>> conditional outputs that don't really have any parsable formatting to
>> them. =A0It may be safe to apply my patch because it adds another field
>> in the middle of a section of conditional outputs* anyway so tools
>> already won't know what those fields mean. =A0But, regardless, I'm not
>> going to take responsibility for applying that patch unless encouraged
>> by several other maintainers to do so.
>
> Go ahead. We changed that output several times in the last years
> without causing the end of the universe.
Okay, RFC patch sent. I'm okay to wait for v3.5 for this, but it can
go into v3.4 if anyone really wants it faster.
g.
^ permalink raw reply
* Re: [GIT PULL] Disintegrate and kill asm/system.h
From: Thomas Gleixner @ 2012-03-29 21:48 UTC (permalink / raw)
To: Grant Likely
Cc: linux-arch, Stephen Rothwell, Michael Neuling, arnd, ppc-dev,
linux-kernel, David Howells, paul.gortmaker, hpa, akpm,
Linus Torvalds
In-Reply-To: <CACxGe6v+nMMuEM+bBMdYf_OeuaXb+NsS0qz-+puRtdzHLPH2hA@mail.gmail.com>
On Thu, 29 Mar 2012, Grant Likely wrote:
> On Thu, Mar 29, 2012 at 2:11 AM, Benjamin Herrenschmidt
> The rightmost fields of /proc/interrupts are a weird set of
> conditional outputs that don't really have any parsable formatting to
> them. It may be safe to apply my patch because it adds another field
> in the middle of a section of conditional outputs* anyway so tools
> already won't know what those fields mean. But, regardless, I'm not
> going to take responsibility for applying that patch unless encouraged
> by several other maintainers to do so.
Go ahead. We changed that output several times in the last years
without causing the end of the universe.
Thanks,
tglx
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Tabi Timur-B04825 @ 2012-03-29 21:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <alpine.LFD.2.02.1203291544170.14273@spiff>
On Thu, Mar 29, 2012 at 3:44 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
>
> A few minor bug fixes and missing dts updates for 3.4. =A0There got lost =
in
> the mix. =A0Sorry for the delay
What about my "don't call of_platform_bus_probe() twice" patch?
That's still an important fix for the P1022DS.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [GIT PULL] Disintegrate and kill asm/system.h
From: Grant Likely @ 2012-03-29 21:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-arch, Stephen Rothwell, Michael Neuling, arnd, ppc-dev,
linux-kernel, David Howells, paul.gortmaker, hpa, akpm,
Linus Torvalds
In-Reply-To: <1333008684.3010.9.camel@pasglop>
On Thu, Mar 29, 2012 at 2:11 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2012-03-28 at 22:02 -0700, Linus Torvalds wrote:
>> On Wed, Mar 28, 2012 at 9:42 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > How about this (build tested on powerpc allyesconfig):
>>
>> Looks better.
>>
>> Grant - what's the plan about that CONFIG_VIRQ_DEBUG thing? In theory
>> something like it could be useful as a generic thing, but at least
>> right now it is clearly powerpc-specific (not just that the config
>> option only exists for powerpc: it has that whole
>> 'powerpc_debugfs_root' thing in it)?
>>
>> Stephen's patch very much looks like the right thing, but if there was
>> some plan to actually make this generic ...
>
> Yes, as I said earlier I think Grant should make it generic, there's
> no reason to keep that powerpc specific, it's fairly useful and nothing
> in userspace relies on the existing location of the debugfs file that I
> know about.
>
> Another option is to put the mapping information in /proc/interrupts but
> worry that changing anything in there (like adding a column) will break
> countless userspace tools.
I posted an RFC patch that does exactly that, but I'm similarly
nervous for the same reason:
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg56368.html
The rightmost fields of /proc/interrupts are a weird set of
conditional outputs that don't really have any parsable formatting to
them. It may be safe to apply my patch because it adds another field
in the middle of a section of conditional outputs* anyway so tools
already won't know what those fields mean. But, regardless, I'm not
going to take responsibility for applying that patch unless encouraged
by several other maintainers to do so.
*It's added to the middle instead of the end purely for aesthetic
reasons. The rightmost field is a freeform string without a field
width, so if put at the end they would never line up. Suggestions for
a better layout are welcome.
g.
^ 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