[2.6.24 patch] restore Cell OProfile support

2007-12-28 Thread Adrian Bunk
This patch restores the Cell OProfile support that was killed by
commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 kernel/Kconfig.instrumentation |8 
 1 file changed, 8 insertions(+)

6d1446d35d367fdbdd2a0a29e0d156646ff40630 
diff --git a/kernel/Kconfig.instrumentation b/kernel/Kconfig.instrumentation
index a76635d..9d143e6 100644
--- a/kernel/Kconfig.instrumentation
+++ b/kernel/Kconfig.instrumentation
@@ -53,2 +53,10 @@ config HARDWARE_PM
 
+config OPROFILE_CELL
+   bool "OProfile for Cell Broadband Engine"
+   depends on PPC && (SPU_FS = y && OPROFILE = m) || (SPU_FS = y && 
OPROFILE = y) 
+   default y
+   help
+ Profiling of Cell BE SPUs requires special support enabled
+ by this option.
+
 config KPROBES

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc: free_property() mustn't be __init

2008-01-30 Thread Adrian Bunk
This patch fixes the following section mismatch:

<--  snip  -->

...
WARNING: vmlinux.o(.text+0x55648): Section mismatch in reference from the 
function .free_node() to the function .init.text:.free_property()
...

<--  snip  -->

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
99e9b48d8f5aba059916540fc69815db2b60b08d 
diff --git a/arch/powerpc/platforms/iseries/vio.c 
b/arch/powerpc/platforms/iseries/vio.c
index be06cfd..657b72f 100644
--- a/arch/powerpc/platforms/iseries/vio.c
+++ b/arch/powerpc/platforms/iseries/vio.c
@@ -75,7 +75,7 @@ static struct property *new_property(const char *name, int 
length,
return np;
 }
 
-static void __init free_property(struct property *np)
+static void free_property(struct property *np)
 {
kfree(np);
 }

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc: vdso_do_func_patch{32,64}() must be __init

2008-01-30 Thread Adrian Bunk
This patch fixes the following section mismatches:

<--  snip  -->

...
WARNING: vmlinux.o(.text+0xe49c): Section mismatch in reference from the 
function .vdso_do_func_patch64() to the function .init.text:.find_symbol64()
WARNING: vmlinux.o(.text+0xe4d0): Section mismatch in reference from the 
function .vdso_do_func_patch64() to the function .init.text:.find_symbol64()
WARNING: vmlinux.o(.text+0xe56c): Section mismatch in reference from the 
function .vdso_do_func_patch32() to the function .init.text:.find_symbol32()
WARNING: vmlinux.o(.text+0xe5a0): Section mismatch in reference from the 
function .vdso_do_func_patch32() to the function .init.text:.find_symbol32()
...

<--  snip  -->

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/powerpc/kernel/vdso.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

1c52ed2049b82e8458d03e50633b01ac5e1dfa40 
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 3702df7..d3437c4 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -336,9 +336,9 @@ static unsigned long __init find_function32(struct 
lib32_elfinfo *lib,
return sym->st_value - VDSO32_LBASE;
 }
 
-static int vdso_do_func_patch32(struct lib32_elfinfo *v32,
-   struct lib64_elfinfo *v64,
-   const char *orig, const char *fix)
+static int __init vdso_do_func_patch32(struct lib32_elfinfo *v32,
+  struct lib64_elfinfo *v64,
+  const char *orig, const char *fix)
 {
Elf32_Sym *sym32_gen, *sym32_fix;
 
@@ -433,9 +433,9 @@ static unsigned long __init find_function64(struct 
lib64_elfinfo *lib,
 #endif
 }
 
-static int vdso_do_func_patch64(struct lib32_elfinfo *v32,
-   struct lib64_elfinfo *v64,
-   const char *orig, const char *fix)
+static int __init vdso_do_func_patch64(struct lib32_elfinfo *v32,
+  struct lib64_elfinfo *v64,
+  const char *orig, const char *fix)
 {
Elf64_Sym *sym64_gen, *sym64_fix;
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] hvc_rtas_init() must be __init

2008-01-30 Thread Adrian Bunk
This patch fixes the following section mismatch:

<--  snip  -->

...
WARNING: vmlinux.o(.text+0x2fbca8): Section mismatch in reference from the 
function .hvc_rtas_init() to the function .devinit.text:.hvc_alloc()
...

<--  snip  -->

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
1cc00c4ad5c881db2fc256ced43f3b5ce5c76e1c 
diff --git a/drivers/char/hvc_rtas.c b/drivers/char/hvc_rtas.c
index bb09413..88590d0 100644
--- a/drivers/char/hvc_rtas.c
+++ b/drivers/char/hvc_rtas.c
@@ -76,7 +76,7 @@ static struct hv_ops hvc_rtas_get_put_ops = {
.put_chars = hvc_rtas_write_console,
 };
 
-static int hvc_rtas_init(void)
+static int __init hvc_rtas_init(void)
 {
struct hvc_struct *hp;
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-01-31 Thread Adrian Bunk
On Wed, Jan 30, 2008 at 11:33:29AM -0800, Luck, Tony wrote:
> > I'm having trouble replicating this error.  With the latest linux-2.6.git
> > plus the patch I just sent, I get the following errors:
> >
> > drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a 
> > section type conflict
> > drivers/md/md.c:5881: error: __param_start_ro causes a section type conflict
> 
> Weird.  psmouse-base.c builds ok for me.  Perhaps there is a compiler
> version difference?  I'm running a rather old 3.4.6 that came with
> my RHEL 4.5 release.
>...

It depends on the compiler version.

And you were in the Cc of Ivan's patch that fixes it... [1]

> -Tony

cu
Adrian

[1] http://lkml.org/lkml/2007/12/27/29

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target

2008-07-31 Thread Adrian Bunk
From: Scott Wood <[EMAIL PROTECTED]>

This patch fixes the following build error with mpc866_ads_defconfig:

<--  snip  -->

...
  WRAParch/powerpc/boot/cuImage.mpc866ads
powerpc64-linux-ld: arch/powerpc/boot/cuboot-mpc866ads.o: No such file: No such 
file or directory
make[2]: *** [arch/powerpc/boot/cuImage.mpc866ads] Error 1

<--  snip  -->

Reported-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was sent by Scott Wood on:
- 21 May 2008

 arch/powerpc/boot/wrapper |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d6c96d9..3b59e33 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -159,7 +159,7 @@ cuboot*)
 binary=y
 gzip=
 case "$platform" in
-*-mpc885ads|*-adder875*|*-ep88xc)
+*-mpc866ads|*-mpc885ads|*-adder875*|*-ep88xc)
 platformo=$object/cuboot-8xx.o
 ;;
 *5200*|*-motionpro)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


platforms/44x/warp-nand.c bogosity

2008-08-01 Thread Adrian Bunk
arch/powerpc/platforms/44x/warp-nand.c was added this year and updated 
quite recently.

warp-nand.c is empty unless CONFIG_MTD_NAND_NDFC=y.

MTD_NAND_NDFC depends on !PPC_MERGE.

!PPC_MERGE can never be true on PPC now that arch/ppc/ got removed.

So warp-nand.c is dead code, but that does not seem to be intentionally?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] sata_fsl.c: fix 8315DS workaround

2008-08-04 Thread Adrian Bunk
Commit e7eac96e8f0e57a6e9f94943557bc2b23be31471 (ata/sata_fsl: Move 
MPC8315DS link speed limit workaround to specific ifdef) aimed at 
limiting the workaround only to the affected hardware, but since the 
#ifdef used a nonexisting kconfig variable it actually killed
the workaround.

Reported-by: Robert P. J. Day <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
cd54dd8b6a8bca44ead212d12fe116702cc31ed7 
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 3924e72..45878ef 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -640,7 +640,7 @@ static int sata_fsl_port_start(struct ata_port *ap)
VPRINTK("HControl = 0x%x\n", ioread32(hcr_base + HCONTROL));
VPRINTK("CHBA  = 0x%x\n", ioread32(hcr_base + CHBA));
 
-#ifdef CONFIG_MPC8315_DS
+#ifdef CONFIG_MPC831x_RDB
/*
 * Workaround for 8315DS board 3gbps link-up issue,
 * currently limit SATA port to GEN1 speed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [2.6 patch] sata_fsl.c: fix 8315DS workaround

2008-08-04 Thread Adrian Bunk
On Mon, Aug 04, 2008 at 04:55:37PM +0800, Li Yang wrote:
> > -Original Message-
> > From: Adrian Bunk [mailto:[EMAIL PROTECTED] 
> > Sent: Monday, August 04, 2008 4:46 PM
> > To: Kalra Ashish; Li Yang; Jeff Garzik; [EMAIL PROTECTED]
> > Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; 
> > Robert P. J. Day
> > Subject: [2.6 patch] sata_fsl.c: fix 8315DS workaround
> > 
> > Commit e7eac96e8f0e57a6e9f94943557bc2b23be31471 
> > (ata/sata_fsl: Move MPC8315DS link speed limit workaround to 
> > specific ifdef) aimed at limiting the workaround only to the 
> > affected hardware, but since the #ifdef used a nonexisting 
> > kconfig variable it actually killed the workaround.
> 
> This workaround is only for MPC8315_DS board which is not supported in the 
> main line yet.  We can remove the workaround if we need to do something here.

Thanks, in this case my patch is complete crap.

There's no need for any action.

> - Leo

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH]: Remove bogons from the iSeries console

2008-08-06 Thread Adrian Bunk
On Thu, Aug 07, 2008 at 12:10:06AM +1000, Stephen Rothwell wrote:
> Hi Alan,
> 
> On Wed, 6 Aug 2008 14:06:29 +0100 Alan Cox <[EMAIL PROTECTED]> wrote:
> >
> > The iSeries driver calls into the n_tty ldisc code directly for some
> > bizarre reason. I previously tagged this with a query but this actually
> > does need fixing as n_tty methods when you have a different ldisc set are
> > not a good thing to call.
> > 
> > In n_tty mode this change should have no effect, the core tty layer has
> > always called the ldisc ioctl method *anyway* and will call the one for
> > the right ldisc.
> > 
> > Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
> 
> I will take your word for it as I have no idea.  This driver needs to be
> deprecated anyway (in favour of hcv_iseries).
>...

You already marked it as "Obsolete" more than 2 years ago, and due the 
kconfig dependencies most people anyway won't even see the option (since 
they have HVC_ISERIES enabled).

IMHO a candidate for a straight removal?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] cleanup powerpc/include/asm/ide.h

2008-08-08 Thread Adrian Bunk
This patch removes code that became unused through IDE changes and the 
arch/ppc/ removal.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/powerpc/include/asm/ide.h |   43 -
 1 file changed, 1 insertion(+), 42 deletions(-)

363979e32b08c578431a1773e7b885698feb30aa 
diff --git a/arch/powerpc/include/asm/ide.h b/arch/powerpc/include/asm/ide.h
index 048480e..da01b20 100644
--- a/arch/powerpc/include/asm/ide.h
+++ b/arch/powerpc/include/asm/ide.h
@@ -6,12 +6,7 @@
 #ifndef _ASM_POWERPC_IDE_H
 #define _ASM_POWERPC_IDE_H
 
-#ifdef __KERNEL__
-
-#ifndef __powerpc64__
-#include 
-#include 
-#endif
+#include 
 #include 
 
 #define __ide_mm_insw(p, a, c) readsw((void __iomem *)(p), (a), (c))
@@ -19,40 +14,4 @@
 #define __ide_mm_outsw(p, a, c)writesw((void __iomem *)(p), (a), (c))
 #define __ide_mm_outsl(p, a, c)writesl((void __iomem *)(p), (a), (c))
 
-#ifndef  __powerpc64__
-#include 
-
-/* FIXME: use ide_platform host driver */
-static __inline__ int ide_default_irq(unsigned long base)
-{
-#ifdef CONFIG_PPLUS
-   switch (base) {
-   case 0x1f0: return 14;
-   case 0x170: return 15;
-   }
-#endif
-   return 0;
-}
-
-/* FIXME: use ide_platform host driver */
-static __inline__ unsigned long ide_default_io_base(int index)
-{
-#ifdef CONFIG_PPLUS
-   switch (index) {
-   case 0: return 0x1f0;
-   case 1: return 0x170;
-   }
-#endif
-   return 0;
-}
-
-#ifdef CONFIG_BLK_DEV_MPC8xx_IDE
-#define IDE_ARCH_ACK_INTR  1
-#define ide_ack_intr(hwif) ((hwif)->ack_intr ? (hwif)->ack_intr(hwif) : 1)
-#endif
-
-#endif /* __powerpc64__ */
-
-#endif /* __KERNEL__ */
-
 #endif /* _ASM_POWERPC_IDE_H */

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[12/17] powerpc: use bcd2bin/bin2bcd

2008-08-08 Thread Adrian Bunk
This patch changes powerpc to use the new bcd2bin/bin2bcd functions 
instead of the obsolete BCD_TO_BIN/BIN_TO_BCD macros.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/powerpc/platforms/chrp/time.c  |   24 
 arch/powerpc/platforms/iseries/mf.c |   26 +-
 arch/powerpc/platforms/maple/time.c |   24 
 3 files changed, 37 insertions(+), 37 deletions(-)

e6d9f2f91ed9e6b761aba2754ec5339b4c76beed 
diff --git a/arch/powerpc/platforms/chrp/time.c 
b/arch/powerpc/platforms/chrp/time.c
index 96d1e4b..054dfe5 100644
--- a/arch/powerpc/platforms/chrp/time.c
+++ b/arch/powerpc/platforms/chrp/time.c
@@ -94,12 +94,12 @@ int chrp_set_rtc_time(struct rtc_time *tmarg)
chrp_cmos_clock_write((save_freq_select|RTC_DIV_RESET2), 
RTC_FREQ_SELECT);
 
if (!(save_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
-   BIN_TO_BCD(tm.tm_sec);
-   BIN_TO_BCD(tm.tm_min);
-   BIN_TO_BCD(tm.tm_hour);
-   BIN_TO_BCD(tm.tm_mon);
-   BIN_TO_BCD(tm.tm_mday);
-   BIN_TO_BCD(tm.tm_year);
+   tm.tm_sec = bin2bcd(tm.tm_sec);
+   tm.tm_min = bin2bcd(tm.tm_min);
+   tm.tm_hour = bin2bcd(tm.tm_hour);
+   tm.tm_mon = bin2bcd(tm.tm_mon);
+   tm.tm_mday = bin2bcd(tm.tm_mday);
+   tm.tm_year = bin2bcd(tm.tm_year);
}
chrp_cmos_clock_write(tm.tm_sec,RTC_SECONDS);
chrp_cmos_clock_write(tm.tm_min,RTC_MINUTES);
@@ -136,12 +136,12 @@ void chrp_get_rtc_time(struct rtc_time *tm)
} while (sec != chrp_cmos_clock_read(RTC_SECONDS));
 
if (!(chrp_cmos_clock_read(RTC_CONTROL) & RTC_DM_BINARY) || 
RTC_ALWAYS_BCD) {
-   BCD_TO_BIN(sec);
-   BCD_TO_BIN(min);
-   BCD_TO_BIN(hour);
-   BCD_TO_BIN(day);
-   BCD_TO_BIN(mon);
-   BCD_TO_BIN(year);
+   sec = bcd2bin(sec);
+   min = bcd2bin(min);
+   hour = bcd2bin(hour);
+   day = bcd2bin(day);
+   mon = bcd2bin(mon);
+   year = bcd2bin(year);
}
if (year < 70)
year += 100;
diff --git a/arch/powerpc/platforms/iseries/mf.c 
b/arch/powerpc/platforms/iseries/mf.c
index 1dc7295..8dfc78e 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -722,13 +722,13 @@ static int mf_set_rtc(struct rtc_time *tm)
day = tm->tm_mday;
mon = tm->tm_mon + 1;
 
-   BIN_TO_BCD(sec);
-   BIN_TO_BCD(min);
-   BIN_TO_BCD(hour);
-   BIN_TO_BCD(mon);
-   BIN_TO_BCD(day);
-   BIN_TO_BCD(y1);
-   BIN_TO_BCD(y2);
+   sec = bin2bcd(sec);
+   min = bin2bcd(min);
+   hour = bin2bcd(hour);
+   mon = bin2bcd(mon);
+   day = bin2bcd(day);
+   y1 = bin2bcd(y1);
+   y2 = bin2bcd(y2);
 
memset(ce_time, 0, sizeof(ce_time));
ce_time[3] = 0x41;
@@ -777,12 +777,12 @@ static int rtc_set_tm(int rc, u8 *ce_msg, struct rtc_time 
*tm)
u8 day = ce_msg[10];
u8 mon = ce_msg[11];
 
-   BCD_TO_BIN(sec);
-   BCD_TO_BIN(min);
-   BCD_TO_BIN(hour);
-   BCD_TO_BIN(day);
-   BCD_TO_BIN(mon);
-   BCD_TO_BIN(year);
+   sec = bcd2bin(sec);
+   min = bcd2bin(min);
+   hour = bcd2bin(hour);
+   day = bcd2bin(day);
+   mon = bcd2bin(mon);
+   year = bcd2bin(year);
 
if (year <= 69)
year += 100;
diff --git a/arch/powerpc/platforms/maple/time.c 
b/arch/powerpc/platforms/maple/time.c
index 53bca13..eac569d 100644
--- a/arch/powerpc/platforms/maple/time.c
+++ b/arch/powerpc/platforms/maple/time.c
@@ -68,12 +68,12 @@ void maple_get_rtc_time(struct rtc_time *tm)
 
if (!(maple_clock_read(RTC_CONTROL) & RTC_DM_BINARY)
|| RTC_ALWAYS_BCD) {
-   BCD_TO_BIN(tm->tm_sec);
-   BCD_TO_BIN(tm->tm_min);
-   BCD_TO_BIN(tm->tm_hour);
-   BCD_TO_BIN(tm->tm_mday);
-   BCD_TO_BIN(tm->tm_mon);
-   BCD_TO_BIN(tm->tm_year);
+   tm->tm_sec = bcd2bin(tm->tm_sec);
+   tm->tm_min = bcd2bin(tm->tm_min);
+   tm->tm_hour = bcd2bin(tm->tm_hour);
+   tm->tm_mday = bcd2bin(tm->tm_mday);
+   tm->tm_mon = bcd2bin(tm->tm_mon);
+   tm->tm_year = bcd2bin(tm->tm_year);
  }
if ((tm->tm_year + 1900) < 1970)
tm->tm_year += 100;
@@ -104,12 +104,12 @@ int maple_set_rtc_time(struct rtc_time *tm)
year = tm->tm_year;
 
if (!(save_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
-   BIN_TO_BCD(sec);
-   BIN_TO_BCD(min)

Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selects CONFIG_INTEL_IOATDMA=y

2008-10-13 Thread Adrian Bunk
On Mon, Oct 13, 2008 at 03:45:59PM +0530, Kamalesh Babulal wrote:
> Hi,
> 
>2.6.27-git2 kernel build fails, while building the kernel with
> allyesconfig option. The allyesconfig selects CONFIG_INTEL_IOATDMA=y
> 
> CC   drivers/dma/ioat_dca.o
> drivers/dma/ioat_dca.c: In function ‘dca_enabled_in_bios’:
> drivers/dma/ioat_dca.c:81: error: implicit declaration of function 
> ‘cpuid_eax’
> drivers/dma/ioat_dca.c: In function ‘system_has_dca_enabled’:
> drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
> ‘boot_cpu_has’
> drivers/dma/ioat_dca.c:91: error: ‘X86_FEATURE_DCA’ undeclared (first use 
> in this function)
> drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
> only once
> drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
> drivers/dma/ioat_dca.c: In function ‘ioat_dca_get_tag’:
> drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
> ‘cpu_physical_id’
> make[2]: *** [drivers/dma/ioat_dca.o] Error 1
> make[1]: *** [drivers/dma] Error 2
> make: *** [drivers] Error 2
>...

Thanks for the report, the MYRI10GE and IXGBE commits that introduced 
the select's are really broken.

For fixing it I need to know the intended semantics.

Brian, Jesse, is it OK to limit the drivers to m with 
CONFIG_INTEL_IOATDMA=m ?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[2.6 patch] export genphy_restart_aneg

2008-10-13 Thread Adrian Bunk
This patch fixes the following build error caused by
commit ed94493fb38a665cebcf750dfabe8a6dd13e136f
(mv643xx_eth: convert to phylib):

<--  snip  -->

...
  Building modules, stage 2.
  MODPOST 1280 modules
ERROR: "genphy_restart_aneg" [drivers/net/mv643xx_eth.ko] undefined!
...
make[2]: *** [__modpost] Error 1

<--  snip  -->


Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1716274..f11e900 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -557,6 +557,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
 
return ctl;
 }
+EXPORT_SYMBOL(genphy_restart_aneg);
 
 
 /**

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y

2008-10-13 Thread Adrian Bunk
On Mon, Oct 13, 2008 at 08:21:45PM +0200, Brice Goglin wrote:
> Brandeburg, Jesse wrote:
> > What we want, is myri10ge and ixgbe drivers that can build whether or not 
> > CONFIG_INTEL_IOATDMA is enabled.  IF CONFIG_INTEL_IOATDMA *is* enabled 
> > (which it should not be on PPC) then there are several cases we want to 
> > work:
> > CONFIG_INTEL_IOATDMA=m  ---> CONFIG_IXGBE=[m|n]
> > CONFIG_INTEL_IOATDMA=y  ---> CONFIG_IXGBE=[m|y|n]
> > CONFIG_INTEL_IOATDMA=n  ---> CONFIG_IXGBE=[m|y|n]
> > CONFIG_INTEL_IOATDMA depends on X86
> 
> I am not sure I want to prevent myri10ge=y just because ioatdma=m.
>...

Technically both solutions are possible, which to choose is just a 
policy decision you have to agree on.

In practice it will anyway only rarely matter.

But considering that igb is in a similar situation it would be nice if 
all 3 drivers would handle it the same way.

> Brice

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y

2008-10-14 Thread Adrian Bunk
On Tue, Oct 14, 2008 at 11:12:30AM +0200, Brice Goglin wrote:
> Adrian Bunk wrote:
> > But considering that igb is in a similar situation it would be nice if 
> > all 3 drivers would handle it the same way.
> >   
> 
> Jesse,
> What do you think of the below patch?
> I am not very familiar with Kconfig, but it seems to solve the problem.
> If a Kconfig guru could double-check...

The patch looks good, but the main problem is to get an agreement 
on the policy.

> Brice
>...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y

2008-10-14 Thread Adrian Bunk
On Tue, Oct 14, 2008 at 09:10:33AM -0700, Brandeburg, Jesse wrote:
> Brice Goglin wrote:
> > Adrian Bunk wrote:
> >> But considering that igb is in a similar situation it would be nice
> >> if all 3 drivers would handle it the same way.
> >> 
> > 
> > Jesse,
> > What do you think of the below patch?
> 
> Seems like a much better solution.  I can have Jeff Kirsher work on the
> equivalent patches for igb, and ixgbe today.
> 
> > I am not very familiar with Kconfig, but it seems to solve the
> > problem. 
> > If a Kconfig guru could double-check...
> 
> Yeah, please Kconfig gurus on the list have a quick look.

Brice's patch looks fine.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: powerpc allmodconfig

2008-10-16 Thread Adrian Bunk
On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
> At Wed, 15 Oct 2008 21:33:37 -0700,
> Andrew Morton wrote:
> > 
> > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
> > deprecated (declared at sound/soc/soc-dapm.c:1026)
> > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
> > deprecated (declared at sound/soc/soc-dapm.c:1026)
> 
> These are definitions of deprecated interfaces.
> We can remove it in 2.6.29.  If we don't want to be conservative, it
> can be removed in 2.6.28, too.
>...

Since it's an in-kernel API there's no reason to keep it once there are 
no users left.

But currently sound/soc/at32/playpaq_wm8510.c still seems to use it.

> thanks,
> 
> Takashi

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: powerpc allmodconfig

2008-10-16 Thread Adrian Bunk
On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
> At Thu, 16 Oct 2008 10:38:36 +0300,
> Adrian Bunk wrote:
> > 
> > On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
> > > At Wed, 15 Oct 2008 21:33:37 -0700,
> > > Andrew Morton wrote:
> > > > 
> > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
> > > > deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
> > > > deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > 
> > > These are definitions of deprecated interfaces.
> > > We can remove it in 2.6.29.  If we don't want to be conservative, it
> > > can be removed in 2.6.28, too.
> > >...
> > 
> > Since it's an in-kernel API there's no reason to keep it once there are 
> > no users left.
> 
> Right.  But, IMO, now is no suitable time.
> A thing like API removal should have been tested in linux-next, and we
> had plenty of time indeed for 2.6.28.
>...

A grep through the tree and one test compile that covers 
sound/soc/soc-dapm.c should be enough testing.

And having it then in -next once should be enough to discover if someone 
wrongly added a new user.

I have removed many functions in the kernel, and there isn't much that 
can go wrong - even adding a PCI ID to a driver has a bigger risk of 
introducing a regression.

> thanks,
> 
> Takashi

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: powerpc allmodconfig

2008-10-16 Thread Adrian Bunk
On Thu, Oct 16, 2008 at 10:43:33AM +0200, Takashi Iwai wrote:
> At Thu, 16 Oct 2008 11:21:57 +0300,
> Adrian Bunk wrote:
> > 
> > On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
> > > At Thu, 16 Oct 2008 10:38:36 +0300,
> > > Adrian Bunk wrote:
> > > > 
> > > > On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
> > > > > At Wed, 15 Oct 2008 21:33:37 -0700,
> > > > > Andrew Morton wrote:
> > > > > > 
> > > > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
> > > > > > deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
> > > > > > deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > > > 
> > > > > These are definitions of deprecated interfaces.
> > > > > We can remove it in 2.6.29.  If we don't want to be conservative, it
> > > > > can be removed in 2.6.28, too.
> > > > >...
> > > > 
> > > > Since it's an in-kernel API there's no reason to keep it once there are 
> > > > no users left.
> > > 
> > > Right.  But, IMO, now is no suitable time.
> > > A thing like API removal should have been tested in linux-next, and we
> > > had plenty of time indeed for 2.6.28.
> > >...
> > 
> > A grep through the tree and one test compile that covers 
> > sound/soc/soc-dapm.c should be enough testing.
> > 
> > And having it then in -next once should be enough to discover if someone 
> > wrongly added a new user.
> 
> My point is the time for removal.  The API changes should have been
> done in the merge window, and it should have been tested *before* the
> merge window.
>...

My point is simply that compared to many other patches that weren't 
tested before the merge window, and that still get (for various reasons) 
into the tree, the removal of unused functions is extremely low-risk 
(assuming the patch creator knows what grep is and does a test compile 
of the changed code).

> thanks,
> 
> Takashi

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] hvc_rtas_init() must be __init

2008-02-13 Thread Adrian Bunk
This patch fixes the following section mismatch:

<--  snip  -->

...
WARNING: vmlinux.o(.text+0x2fbca8): Section mismatch in reference from the 
function .hvc_rtas_init() to the function .devinit.text:.hvc_alloc()
...

<--  snip  -->

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch has been sent on:
- 30 Jan 2008

1cc00c4ad5c881db2fc256ced43f3b5ce5c76e1c 
diff --git a/drivers/char/hvc_rtas.c b/drivers/char/hvc_rtas.c
index bb09413..88590d0 100644
--- a/drivers/char/hvc_rtas.c
+++ b/drivers/char/hvc_rtas.c
@@ -76,7 +76,7 @@ static struct hv_ops hvc_rtas_get_put_ops = {
.put_chars = hvc_rtas_write_console,
 };
 
-static int hvc_rtas_init(void)
+static int __init hvc_rtas_init(void)
 {
struct hvc_struct *hp;
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc: free_property() mustn't be __init

2008-02-13 Thread Adrian Bunk
This patch fixes the following section mismatch:

<--  snip  -->

...
WARNING: vmlinux.o(.text+0x55648): Section mismatch in reference from the 
function .free_node() to the function .init.text:.free_property()
...

<--  snip  -->

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>

---

This patch has been sent on:
- 30 Jan 2008

99e9b48d8f5aba059916540fc69815db2b60b08d 
diff --git a/arch/powerpc/platforms/iseries/vio.c 
b/arch/powerpc/platforms/iseries/vio.c
index be06cfd..657b72f 100644
--- a/arch/powerpc/platforms/iseries/vio.c
+++ b/arch/powerpc/platforms/iseries/vio.c
@@ -75,7 +75,7 @@ static struct property *new_property(const char *name, int 
length,
return np;
 }
 
-static void __init free_property(struct property *np)
+static void free_property(struct property *np)
 {
kfree(np);
 }

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc: vdso_do_func_patch{32,64}() must be __init

2008-02-13 Thread Adrian Bunk
This patch fixes the following section mismatches:

<--  snip  -->

...
WARNING: vmlinux.o(.text+0xe49c): Section mismatch in reference from the 
function .vdso_do_func_patch64() to the function .init.text:.find_symbol64()
WARNING: vmlinux.o(.text+0xe4d0): Section mismatch in reference from the 
function .vdso_do_func_patch64() to the function .init.text:.find_symbol64()
WARNING: vmlinux.o(.text+0xe56c): Section mismatch in reference from the 
function .vdso_do_func_patch32() to the function .init.text:.find_symbol32()
WARNING: vmlinux.o(.text+0xe5a0): Section mismatch in reference from the 
function .vdso_do_func_patch32() to the function .init.text:.find_symbol32()
...

<--  snip  -->

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch has been sent on:
- 30 Jan 2008

 arch/powerpc/kernel/vdso.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

1c52ed2049b82e8458d03e50633b01ac5e1dfa40 
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 3702df7..d3437c4 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -336,9 +336,9 @@ static unsigned long __init find_function32(struct 
lib32_elfinfo *lib,
return sym->st_value - VDSO32_LBASE;
 }
 
-static int vdso_do_func_patch32(struct lib32_elfinfo *v32,
-   struct lib64_elfinfo *v64,
-   const char *orig, const char *fix)
+static int __init vdso_do_func_patch32(struct lib32_elfinfo *v32,
+  struct lib64_elfinfo *v64,
+  const char *orig, const char *fix)
 {
Elf32_Sym *sym32_gen, *sym32_fix;
 
@@ -433,9 +433,9 @@ static unsigned long __init find_function64(struct 
lib64_elfinfo *lib,
 #endif
 }
 
-static int vdso_do_func_patch64(struct lib32_elfinfo *v32,
-   struct lib64_elfinfo *v64,
-   const char *orig, const char *fix)
+static int __init vdso_do_func_patch64(struct lib32_elfinfo *v32,
+  struct lib64_elfinfo *v64,
+  const char *orig, const char *fix)
 {
Elf64_Sym *sym64_gen, *sym64_fix;
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/3] Fix Unlikely(x) == y

2008-02-18 Thread Adrian Bunk
On Sun, Feb 17, 2008 at 10:50:03PM +1100, Michael Ellerman wrote:
> On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
>...
> > for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
> > than the coder in general. Same for most other architectures.
> > 
> > unlikely() creates bigger code as well.
> > 
> > Now... we're talking about your super duper hotpath function here right?
> > One where you care about 0.5 cycle speed improvement? (less on modern
> > systems ;)
> 
> The first patch was to platforms/ps3 code, which runs on the Cell, in
> particular the PPE ... which is not an x86 :)
> 
> eg:
> 
> [EMAIL PROTECTED] ~]$ cat branch.c
> #include 
> int main(void)
> {
> int i, j;
> 
> for (i = 0, j = 0; i < 10; i++)
> if (i % 4 == 0)
> j++;
> 
> printf("j = %d\n", j);
> return 0;
> }
> [EMAIL PROTECTED] ~]$ ppu-gcc -Wall -O3 -o branch branch.c
> [EMAIL PROTECTED] ~]$ time ./branch
> real0m5.172s
> 
> [EMAIL PROTECTED] ~]$ cat branch.c
> ..
> for (i = 0, j = 0; i < 10; i++)
> if (__builtin_expect(i % 4 == 0, 0))
> j++;
> ..
> [EMAIL PROTECTED] ~]$ ppu-gcc -Wall -O3 -o branch branch.c
> [EMAIL PROTECTED] ~]$ time ./branch
> real0m3.762s
> 
> 
> Which looks as though unlikely() is helping. Admittedly we don't have a
> lot of kernel code that looks like that, but at least unlikely is doing
> what we want it to.


This means it generates faster code with a current gcc for your platform.

But a future gcc might e.g. replace the whole loop with a division
(gcc SVN head (that will soon become gcc 4.3) already does 
transformations like replacing loops with divisions [1]).

And your __builtin_expect() then might have unwanted effects on gcc.

Or the kernel code changes much but the likely/unlikely stays unchanged
although it becomes wrong.

If it is a real hotpath in the kernel where you have _measurable_ 
performance advantages from using likely/unlikely it's usage might be 
justified, but otherwise it shouldn't be used.


> cheers

cu
Adrian

[1] e.g. the while() loop in timespec_add_ns() in include/linux/time.h
gets replaced by a division and a modulo (whether this 
transformation is correct in this specific case is a different
question, but that's the level of code transformation gcc already 
does today)

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/3] Fix Unlikely(x) == y

2008-02-18 Thread Adrian Bunk
On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> On Mon, 18 Feb 2008, Adrian Bunk wrote:
> > 
> > This means it generates faster code with a current gcc for your platform.
> > 
> > But a future gcc might e.g. replace the whole loop with a division
> > (gcc SVN head (that will soon become gcc 4.3) already does 
> > transformations like replacing loops with divisions [1]).
> 
> Hence shouldn't we ask the gcc people what's the purpose of 
> __builtin_expect(),
> if it doesn't live up to its promise?

That's a different issue.

My point here is that we do not know how the latest gcc available in the 
year 2010 might transform this code, and how a likely/unlikely placed 
there might influence gcc's optimizations then.

If this is in hotpath code with a measurable speedup when using 
likely/unlikely with a current gcc then it's worth it.

But otherwise it brings no real advantage today and the longterm effects 
are not predictable.

> With kind regards,
> 
> Geert Uytterhoeven

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/3] Fix Unlikely(x) == y

2008-02-18 Thread Adrian Bunk
On Tue, Feb 19, 2008 at 08:46:03AM +1100, Michael Ellerman wrote:
> On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
> > On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, 18 Feb 2008, Adrian Bunk wrote:
> > > > 
> > > > This means it generates faster code with a current gcc for your 
> > > > platform.
> > > > 
> > > > But a future gcc might e.g. replace the whole loop with a division
> > > > (gcc SVN head (that will soon become gcc 4.3) already does 
> > > > transformations like replacing loops with divisions [1]).
> > > 
> > > Hence shouldn't we ask the gcc people what's the purpose of 
> > > __builtin_expect(),
> > > if it doesn't live up to its promise?
> > 
> > That's a different issue.
> > 
> > My point here is that we do not know how the latest gcc available in the 
> > year 2010 might transform this code, and how a likely/unlikely placed 
> > there might influence gcc's optimizations then.
> 
> You're right, we don't know. But if giving the compiler _more_
> information causes it to produce vastly inferior code then we should be
> filing gcc bugs. After all the unlikely/likely is just a hint, if gcc
> knows better it can always ignore it.

It's the other way round, gcc assumes that you know better than gcc when 
you give it a __builtin_expect().

The example you gave had only a 1:3 ratio, which is far outside of the 
ratios where __builtin_expect() should be used.

What if you gave this annotation for the 1:3 case and gcc generates code 
that performs better for ratios > 1:1000 but much worse for a 1:3 ratio
since your hint did override a better estimate of gcc?

And I'm sure that > 90% of all kernel developers (including me) are 
worse in such respects than the gcc heuristics.

I'm a firm believer in the following:
- it's the programmer's job to write clean and efficient C code
- it's the compiler's job to convert C code into efficient assembler
  code

The stable interface between the programmer and the compiler is C, and 
when the programmer starts manually messing with internals of the 
compiler that's a layering violation that requires a _good_ 
justification.

With a "good justification" not consisting of some microbenchmark but of 
measurements of the actual annotations in the kernel code.

> cheers

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc

2008-02-26 Thread Adrian Bunk
On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
> Hi,
> 
> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option,
> the .config has been attached.
>...

Builds fine here.

Local problem (e.g. disk full) on your machine?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc

2008-02-26 Thread Adrian Bunk
On Tue, Feb 26, 2008 at 11:48:29PM +0530, Kamalesh Babulal wrote:
> Adrian Bunk wrote:
> > On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
> >> Hi,
> >>
> >> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config 
> >> option,
> >> the .config has been attached.
> >> ...
> > 
> > Builds fine here.
> > 
> > Local problem (e.g. disk full) on your machine?
> > 
> > cu
> > Adrian
> > 
> Hi Adrain,

Hi Kamalseh,  ;)

> It Builds fine on another powerpc box with the same .config file, the problem 
> seems to be with the gcc
> on that box, the reported build failure might have been the side effect of 
> the same. 
> 
> 
> drivers/md/raid6int8.c: In function `raid6_int8_gen_syndrome':
> drivers/md/raid6int8.c:185: error: unable to find a register to spill in 
> class `FLOAT_REGS'
> drivers/md/raid6int8.c:185: error: this is the insn:
> (insn:HI 619 799 638 4 drivers/md/raid6int8.c:168 (set (mem:DI (plus:DI 
> (reg/v/f:DI 122 [ p ])
> (reg/v:DI 66 ctr [orig:124 d ] [124])) [0 S8 A64])
> (reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
> (expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
> (nil)))
> drivers/md/raid6int8.c:185: confused by earlier errors, bailing out
> make[2]: *** [drivers/md/raid6int8.o] Error 1
> make[1]: *** [drivers/md] Error 2
> make: *** [drivers] Error 2
> 
> # gcc --version
> gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)

this means your quite old vendor gcc has a bug.

> Thanks & Regards,
> Kamalesh Babulal,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: undefined references to __udivdi3 on powerpc

2008-02-28 Thread Adrian Bunk
On Thu, Feb 28, 2008 at 02:37:18PM +0100, Olaf Hering wrote:
> 
> While debugging __divdi3 calls in drivers/crypto/hifn_795x.c (due to the
> ndelay() delay call with a s64), I found even more breakage of that
> sort. This is after a allnoconfig with ARCH=powerpc in 2.6.25-rc3,
> plus CONFIG_MODULES=y and CONFIG_CRYPTO_DEV_HIFN_795X=y:
> 
>   LD  .tmp_vmlinux1
>   kernel/built-in.o: In function `update_xtime_cache':
>   (.text+0x221a0): undefined reference to `__umoddi3'
>   kernel/built-in.o: In function `update_xtime_cache':
>   (.text+0x221c0): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `getnstimeofday':
>   (.text+0x22330): undefined reference to `__umoddi3'
>   kernel/built-in.o: In function `getnstimeofday':
>   (.text+0x22350): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `timekeeping_resume':
>   timekeeping.c:(.text+0x226a0): undefined reference to `__udivdi3'
>   timekeeping.c:(.text+0x22778): undefined reference to `__umoddi3'
>   timekeeping.c:(.text+0x22798): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `update_wall_time':
>   (.text+0x22c7c): undefined reference to `__umoddi3'
>   kernel/built-in.o: In function `update_wall_time':
>   (.text+0x22c9c): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `update_wall_time':
>   (.text+0x230f8): undefined reference to `__umoddi3'
>   kernel/built-in.o: In function `update_wall_time':
>   (.text+0x23118): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `do_settimeofday':
>   (.text+0x23520): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `timekeeping_init':
>   (.init.text+0x1870): undefined reference to `__udivdi3'
>   make[1]: *** [.tmp_vmlinux1] Error 1
> 
> But its not a regression, 2.6.24 allnoconfig does not link either on
> powerpc32. 
>...

You didn't mention your gcc version, but you should only get these 
errors when using the not yet released gcc 4.3.

And this issue is known for at about half a year.

> Olaf

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


powerpc: cuImage.* creation error

2008-03-17 Thread Adrian Bunk
When building all powerpc defconfigs in 2.6.25-rc6 exactly three of 
them fail to build, and all with similar problems:


mpc85xx_defconfig:

<--  snip  -->

...
  WRAParch/powerpc/boot/cuImage.tqm8540
DTC: dts->dtb  on file 
"/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/tqm8540.dts"
powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such 
file or directory
make[2]: *** [arch/powerpc/boot/cuImage.tqm8540] Error 1

<--  snip  -->


sbc8548_defconfig:

<--  snip  -->

...
Entry Point:  0x
make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', needed 
by `arch/powerpc/boot/zImage'.  Stop.

<--  snip  -->


tqm8540_defconfig:

<--  snip  -->

...
  WRAParch/powerpc/boot/cuImage.tqm8540
DTC: dts->dtb  on file 
"/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/tqm8540.dts"
powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such 
file or directory
make[2]: *** [arch/powerpc/boot/cuImage.tqm8540] Error 1

<--  snip  -->


Is this a problem on my side or is there a bug that should be fixed?


TIA
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: powerpc: cuImage.* creation error

2008-03-17 Thread Adrian Bunk
On Mon, Mar 17, 2008 at 04:07:55PM -0400, Paul Gortmaker wrote:
> In message: powerpc: cuImage.* creation error
> on 17/03/2008 Adrian Bunk wrote:
> 
> > When building all powerpc defconfigs in 2.6.25-rc6 exactly three of 
> > them fail to build, and all with similar problems:
> > 
> > <--  snip  -->
> > 
> > 
> > sbc8548_defconfig:
> > 
> > <--  snip  -->
> > 
> > ...
> > Entry Point:  0x
> > make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', 
> > needed by `arch/powerpc/boot/zImage'.  Stop.
> > 
> 
> Untested, but I'll guess that this is at least part of the problem for
> the sbc one...

It doesn't fix the build, and adds sbc8560_defconfig to the list of 
non-compiling defconfigs:

<--  snip  -->

...
  WRAParch/powerpc/boot/cuImage.sbc8560
DTC: dts->dtb  on file 
"/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/sbc8560.dts"
powerpc64-linux-ld: arch/powerpc/boot/cuboot-sbc8560.o: No such file: No such 
file or directory
make[2]: *** [arch/powerpc/boot/cuImage.sbc8560] Error 1

<--  snip  -->

> Thanks,
> Paul.
> 
> ---
> 
> Author: Paul Gortmaker <[EMAIL PROTECTED]>
> Date:   Mon Mar 17 15:47:03 2008 -0400
> 
> cuimage: fix board names in Makefile
> 
> Fix the copy and paste error from 25431333813686654907ab987fb5de10c10a16db
> for the sbc8548 and sbc8560
> 
> Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
> 
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 4974d9e..1aded8f 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540)   += 
> cuImage.tqm8540
>  image-$(CONFIG_TQM8541)  += cuImage.tqm8541
>  image-$(CONFIG_TQM8555)  += cuImage.tqm8555
>  image-$(CONFIG_TQM8560)  += cuImage.tqm8560
> -image-$(CONFIG_SBC8548)  += cuImage.tqm8548
> -image-$(CONFIG_SBC8560)  += cuImage.tqm8560
> +image-$(CONFIG_SBC8548)  += cuImage.sbc8548
> +image-$(CONFIG_SBC8560)  += cuImage.sbc8560
>  
>  # Board ports in arch/powerpc/platform/embedded6xx/Kconfig
>  image-$(CONFIG_STORCENTER)   += cuImage.storcenter

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc: remove the non-functional PPC_PREP bits

2008-03-30 Thread Adrian Bunk
Back in November 2005, the PPC_PREP bits under arch/powerpc/ were marked 
as BROKEN due to not being working.

It doesn't seem to make much sense to keep this rudimentary support even 
longer.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/powerpc/Kconfig|5 +---
 arch/powerpc/kernel/setup-common.c  |6 -
 arch/powerpc/platforms/Kconfig  |3 --
 arch/powerpc/platforms/prep/Kconfig |   31 
 include/asm-powerpc/processor.h |7 --
 5 files changed, 3 insertions(+), 49 deletions(-)

75e5883ddd71921318afb01dd7d2402528f3b8e5 diff --git a/arch/powerpc/Kconfig 
b/arch/powerpc/Kconfig
index 1189d8d..380b7a0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -309,7 +309,6 @@ config CRASH_DUMP
 
 config PPCBUG_NVRAM
bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
-   default y if PPC_PREP
 
 config IRQ_ALL_CPUS
bool "Distribute interrupts on all CPUs by default"
@@ -453,7 +452,7 @@ menu "Bus options"
 
 config ISA
bool "Support for ISA-bus hardware"
-   depends on PPC_PREP || PPC_CHRP
+   depends on PPC_CHRP
select PPC_I8259
help
  Find out whether you have ISA slots on your motherboard.  ISA is the
@@ -635,7 +634,7 @@ config TASK_SIZE_BOOL
 
 config TASK_SIZE
hex "Size of user task space" if TASK_SIZE_BOOL
-   default "0x8000" if PPC_PREP || PPC_8xx
+   default "0x8000" if PPC_8xx
default "0xc000"
 
 config CONSISTENT_START_BOOL
diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 6adb5a1..fc32f53 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -570,12 +570,6 @@ int check_legacy_ioport(unsigned long base_port)
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, "fdc");
break;
-#ifdef CONFIG_PPC_PREP
-   case _PIDXR:
-   case _PNPWRP:
-   case PNPBIOS_BASE:
-   /* implement me */
-#endif
default:
/* ipmi is supposed to fail here */
break;
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index a578b96..3a2954d 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -42,7 +42,6 @@ source "arch/powerpc/platforms/chrp/Kconfig"
 source "arch/powerpc/platforms/512x/Kconfig"
 source "arch/powerpc/platforms/52xx/Kconfig"
 source "arch/powerpc/platforms/powermac/Kconfig"
-source "arch/powerpc/platforms/prep/Kconfig"
 source "arch/powerpc/platforms/maple/Kconfig"
 source "arch/powerpc/platforms/pasemi/Kconfig"
 source "arch/powerpc/platforms/celleb/Kconfig"
@@ -210,7 +209,7 @@ endmenu
 
 config PPC601_SYNC_FIX
bool "Workarounds for PPC601 bugs"
-   depends on 6xx && (PPC_PREP || PPC_PMAC)
+   depends on 6xx && PPC_PMAC
help
  Some versions of the PPC601 (the first PowerPC chip) have bugs which
  mean that extra synchronization instructions are required near
diff --git a/arch/powerpc/platforms/prep/Kconfig 
b/arch/powerpc/platforms/prep/Kconfig
deleted file mode 100644
index 29d4112..000
--- a/arch/powerpc/platforms/prep/Kconfig
+++ /dev/null
@@ -1,31 +0,0 @@
-config PPC_PREP
-   bool "PowerPC Reference Platform (PReP) based machines"
-   depends on PPC_MULTIPLATFORM && PPC32 && BROKEN
-   select MPIC
-   select PPC_I8259
-   select PPC_INDIRECT_PCI
-   select PPC_UDBG_16550
-   select PPC_NATIVE
-   default n
-
-config PREP_RESIDUAL
-   bool "Support for PReP Residual Data"
-   depends on PPC_PREP
-   help
- Some PReP systems have residual data passed to the kernel by the
- firmware.  This allows detection of memory size, devices present and
- other useful pieces of information.  Sometimes this information is
- not present or incorrect, in which case it could lead to the machine 
- behaving incorrectly.  If this happens, either disable PREP_RESIDUAL
- or pass the 'noresidual' option to the kernel.
-
- If you are running a PReP system, say Y here, otherwise say N.
-
-config PROC_PREPRESIDUAL
-   bool "Support for reading of PReP Residual Data in /proc"
-   depends on PREP_RESIDUAL && PROC_FS
-   help
- Enabling this option will create a /proc/residual file which allows
- you to get at the residual data on PReP systems.  You will need a tool
- (lsresidual) to parse it.  If you aren't on a PReP system, you don't
- want this.
diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h
index f

[2.6 patch] powerpc/sysdev/rtc_cmos_setup.c: add MODULE_LICENSE

2008-04-14 Thread Adrian Bunk
This patch adds the missing MODULE_LICENSE("GPL").

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
6f9e3869ba8122adefb706c7d5c18cf4b2dc65c9 diff --git 
a/arch/powerpc/sysdev/rtc_cmos_setup.c b/arch/powerpc/sysdev/rtc_cmos_setup.c
index 0c9ac7e..c09ddc0 100644
--- a/arch/powerpc/sysdev/rtc_cmos_setup.c
+++ b/arch/powerpc/sysdev/rtc_cmos_setup.c
@@ -56,3 +56,5 @@ static int  __init add_rtc(void)
return 0;
 }
 fs_initcall(add_rtc);
+
+MODULE_LICENSE("GPL");

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] char/xilinx_hwicap/ section fix

2008-04-23 Thread Adrian Bunk
This patch fixes the following build error:

<--  snip  -->

...
  CC [M]  drivers/char/xilinx_hwicap/xilinx_hwicap.o
...
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/char/xilinx_hwicap/xilinx_hwicap.c:806:
 error: hwicap_of_match causes a section type conflict
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/char/xilinx_hwicap/xilinx_hwicap.c:806:
 error: hwicap_of_match causes a section type conflict
make[4]: *** [drivers/char/xilinx_hwicap/xilinx_hwicap.o] Error 1

<--  snip  -->

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
2f0f31d8aa696ca6cc45ab865ec8c68b90cd0e46 diff --git 
a/drivers/char/xilinx_hwicap/xilinx_hwicap.c 
b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 016f905..dfe6907 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -803,7 +803,7 @@ static int __devexit hwicap_of_remove(struct of_device *op)
 }
 
 /* Match table for of_platform binding */
-static const struct of_device_id __devinit hwicap_of_match[] = {
+static const struct of_device_id __devinitconst hwicap_of_match[] = {
{ .compatible = "xlnx,opb-hwicap-1.00.b", .data = &buffer_icap_config},
{ .compatible = "xlnx,xps-hwicap-1.00.a", .data = &fifo_icap_config},
{},

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] drivers/of/of_i2c.c: add MODULE_LICENSE

2008-04-23 Thread Adrian Bunk
After commit 585468e5d5962660867c269e26f0a4b89a599473
([POWERPC] i2c: Fix build breakage introduced by OF helpers)
drivers/of/of_i2c.c needs a MODULE_LICENSE.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/of/of_i2c.c |3 +++
 1 file changed, 3 insertions(+)

946ca8103416a313577b0b9d52d30541fe7eef85 diff --git a/drivers/of/of_i2c.c 
b/drivers/of/of_i2c.c
index 6316891..715a444 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 
 struct i2c_driver_device {
char*of_device;
@@ -113,3 +114,5 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
}
 }
 EXPORT_SYMBOL(of_register_i2c_devices);
+
+MODULE_LICENSE("GPL");

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [BUG] 2.6.25-git8 Kernel Bug while bootup on ppc and x86

2008-04-26 Thread Adrian Bunk
On Sat, Apr 26, 2008 at 04:51:54PM +0530, Kamalesh Babulal wrote:
> While booting the 2.6.25-git8 kernel on the ppc and x86_64 machine, kernel
> bug is hit. This was reported in the next-20080423 kernel 
> http://lkml.org/lkml/2008/4/23/206.
> 
> Call trace of x86_64 machine
> 
> BUG: unable to handle kernel paging request at 
> IP: [] put_files_struct+0x25/0x110
> PGD 0 
> Oops: 0002 [333] SMP 
> CPU 3 
> Modules linked in:
> Pid: 1391, comm: khelper Tainted: G  D  2.6.25-git8-autotest #1
> RIP: 0010:[]  [] 
> put_files_struct+0x25/0x110
> RSP: :81090d06bdb0  EFLAGS: 00010282
> RAX: 0101 RBX: fffe RCX: 8100010260e0
> RDX: 0007 RSI: 0001 RDI: 
> RBP: fffe R08: 2267 R09: 
> R10: 0010 R11:  R12: 
> R13: 81032d2e9000 R14: 81090e74b000 R15: 81061e4cbce0
> FS:  () GS:81032e4ae940() knlGS:
> CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
> CR2:  CR3: 00201000 CR4: 06e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: 0ff0 DR7: 0400
> Process khelper (pid: 1391, threadinfo 81090d06a000, task 
> 81090d8113a0)
> Stack:  81090d8113a0 fffe fffe 81032e556e00
>  81032d2e9000 81090e74b000 81061e4cbce0 80294278
>  81090d06be70 80636bc0 81090d3646c0 81032d2e9000
> Call Trace:
>  [] do_execve+0x108/0x230
>...

Most likely fixed by
  http://lkml.org/lkml/2008/4/26/1

> Thanks & Regards,
> Kamalesh Babulal,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: 2.6.25: pmac_newworld undefined

2008-04-29 Thread Adrian Bunk
On Mon, Apr 28, 2008 at 09:33:24PM +0200, Sam Ravnborg wrote:
> On Mon, Apr 28, 2008 at 02:20:44PM +1000, Tony Breeds wrote:
> > On Sun, Apr 27, 2008 at 08:03:46PM +0200, Christian Kujau wrote:
> > > Hi,
> > > 
> > > the build failure reported[0] by Kamalesh back in 01/2008 is still 
> > > present in today's 2.6.25-git with CONFIG_NVRAM=m (instead of =y):
> > > 
> > >   Building modules, stage 2.
> > >   MODPOST 72 modules
> > > ERROR: "pmac_newworld" [arch/powerpc/platforms/powermac/nvram.ko] 
> > > undefined!
> > > ERROR: "__alloc_bootmem" [arch/powerpc/platforms/powermac/nvram.ko] 
> > > undefined!
> > > make[1]: *** [__modpost] Error 1
> > 
> > Yeah that isn't really surprising.  Essentially
> > arch/powerpc/platforms/powermac/nvram.c must be builtin (not modular)
> > but CONFIG_NVRAM is tristate, and your .config has CONFIG_NVRAM=m.
> > 
> > We can probably "fix" this by adding another config config symbol and
> > "selecting" that from CONFIG_NVRAM.  Then using this new symbol in
> > arch/powerpc/platforms/powermac/*
> > 
> > so I think with we need is:
> > config NVRAM
> >   bool "..." if PPC32
> >   tristate "..." if !PPC32
> >   ...
> >   ...
> > 
> > Sam is there some way to achieve that or should we just create an
> > secondary symbol?
> 
> In the Makefile you could just do a:
> 
> obj-$(CONFIG_NVRAM:m=y) += nvram.o
> 
> Then you would force nvram to be build-in.
> That looks simpler than messing with Kconfig in this case.

You miss that this is only true on powerpc.

And for such issues Kconfig anyway is the right place - assume how your 
solution would break if NVRAM would some day select or depend on some 
helper code.

>   Sam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: 2.6.25: pmac_newworld undefined

2008-04-29 Thread Adrian Bunk
On Tue, Apr 29, 2008 at 09:17:53PM +0200, Sam Ravnborg wrote:
>...
> So something like:
> 
> config PPC32_NVRAM
>   bool
>   depends on NVRAM
> 
> obj-$(CONFIG_PPC32_NVRAM) += nvram.o
> obj-$(CONFIG_NVRAM)   += nvram.o
> 
> Or did you have another solution in mind?

I start to understand the problem, and I'm currently wondering why 
powerpc uses CONFIG_NVRAM although the code CONFIG_NVRAM enables on 
other platforms is not enabled on powerpc.

Can we rename it and move drivers/char/generic_nvram.c under 
arch/powerpc/ ?

Can some powerpc person bring some background what's going on and why 
it's this way?

>   Sam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds

2008-05-07 Thread Adrian Bunk
On Wed, May 07, 2008 at 06:52:53PM +0530, Kamalesh Babulal wrote:
> While running the ltp over the powerpc with the 2.6.26-rc1-git4 kernel,
> task get blocked for more 120 seconds and does not proceeds future.
> 
> The task msgctl08 is a ipc testcase, which test the msgget(2) msgctl(2)
> syscalls.

Thanks for your report.

I assume this is reproducible?

If yes, what was the last kernel that worked for you?

I've also added Pierre Peiffer and Nadia Derbey to the Cc since their 
recent ipc commits are my first suspects.

> Machine is stuck in the task, printing the following call trace
> more than 5000 times. The oom-killer invoked once in-between.
> 
> INFO: task msgctl08:16248 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Call Trace:
> [c000762435a0] [0001] 0x1 (unreliable)
> [c00076243770] [c0010acc] .__switch_to+0x128/0x16c
> [c00076243800] [c04b07a4] .schedule+0x7ac/0x890
> [c000762438f0] [c04b2ba4] .rwsem_down_failed_common+0x260/0x2b0
> [c000762439b0] [c04b2c60] .rwsem_down_read_failed+0x2c/0x44
> [c00076243a60] [c04b1b84] .down_read+0x44/0x5c
> [c00076243af0] [c0295e10] .ipc_lock+0x34/0xe0
> [c00076243b90] [c029690c] .ipc_lock_check+0x24/0x78
> [c00076243c20] [c02972c0] .do_msgsnd+0xb0/0x3f8
> [c00076243d10] [c0293ce8] .compat_sys_msgsnd+0x94/0xc0
> [c00076243db0] [c0014418] .compat_sys_ipc+0x130/0x1f4
> [c00076243e30] [c0008734] syscall_exit+0x0/0x40
> msgctl08 invoked oom-killer: gfp_mask=0x1200d2, order=0, oomkilladj=0
> Call Trace:
> [c0001e1c7640] [c00101bc] .show_stack+0x70/0x1bc (unreliable)
> [c0001e1c76f0] [c00c2c78] .oom_kill_process+0x78/0x230
> [c0001e1c77a0] [c00c3390] .out_of_memory+0x28c/0x320
> [c0001e1c7870] [c00c70ac] .__alloc_pages_internal+0x364/0x468
> [c0001e1c7980] [c00e83cc] .alloc_page_vma+0x120/0x14c
> [c0001e1c7a20] [c00e0224] .read_swap_cache_async+0x7c/0x160
> [c0001e1c7ae0] [c00e035c] .swapin_readahead+0x54/0xd4
> [c0001e1c7ba0] [c00d47e8] .handle_mm_fault+0x520/0x9d8
> [c0001e1c7c80] [c04b5054] .do_page_fault+0x440/0x624
> [c0001e1c7e30] [c00053fc] handle_page_fault+0x20/0x5c
> Mem-info:
> Node 0 DMA per-cpu:
> CPU0: hi:6, btch:   1 usd:   1
> CPU1: hi:6, btch:   1 usd:   1
> Node 1 DMA per-cpu:
> CPU0: hi:6, btch:   1 usd:   5
> CPU1: hi:6, btch:   1 usd:   5
> Active:31 inactive:2628 dirty:1 writeback:6 unstable:0
>  free:156 slab:13071 mapped:548 pagetables:41109 bounce:0
> Node 0 DMA free:5312kB min:5760kB low:7168kB high:8640kB active:1024kB 
> inactive:768kB present:3928832kB pages_scanned:3912 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> Node 1 DMA free:4672kB min:4992kB low:6208kB high:7488kB active:960kB 
> inactive:169792kB present:3404992kB pages_scanned:140140 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> Node 0 DMA: 5*64kB 15*128kB 2*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB 
> 0*8192kB 0*16384kB = 5312kB
> Node 1 DMA: 8*64kB 5*128kB 6*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB 
> 0*8192kB 0*16384kB = 4736kB
> 8185 total pagecache pages
> Swap cache: add 29545, delete 21888, find 5602/10373
> Free swap  = 803712kB
> Total swap = 2048128kB
> 114688 pages of RAM
> 766 reserved pages
> 231218 pages shared
> 7657 pages swap cached
> Out of memory: kill process 15371 (msgctl08) score 39223 or a child
> Killed process 15373 (msgctl08)
> INFO: task msgctl08:15385 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Call Trace:
> [c000e9a43290] [0001] 0x1 (unreliable)
> [c000e9a43460] [c0010acc] .__switch_to+0x128/0x16c
> [c000e9a434f0] [c04b07a4] .schedule+0x7ac/0x890
> [c000e9a435e0] [c04b0d90] .io_schedule+0x7c/0xe8
> [c000e9a43670] [c02d7f44] .get_request_wait+0x15c/0x1e0
> [c000e9a43750] [c02d8950] .__make_request+0x3ec/0x4d8
> [c000e9a43800] [c02d6624] .generic_make_request+0x35c/0x3b0
> [c000e9a438e0] [c02d81b0] .submit_bio+0x118/0x140
> [c000e9a439a0] [c00dfa88] .swap_readpage+0x94/0xb4
> [c000e9a43a20] [c00e02b8] .read_swap_cache_async+0x110/0x160
> [c000e9a43ae0] [c00e035c] .swapin_readahead+0x54/0xd4
> [c000e9a43ba0] [c00d47e8] .handle_mm_fault+0x520/0x9d8
> [c000e9a43c80] [c04b5054] .do_page_fault+0x440/0x624
> [c000e9a43e30] [c00053fc] handle_page_fault+0x20/0x5c
> INFO: task msgctl08:15405 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Call Trace:
> [c000b1757290] [0001] 0x1 (unreliable)
> [c000b1757460] [c0010acc] .__switch_to+0x128/0x16c
> [c000b17574f0] [c00

[2.6 patch] powerpc/mm/hash_low_32.S: remove CVS keyword

2008-05-19 Thread Adrian Bunk
This patch removes a CVS keyword that wasn't updated for a long time 
from a comment.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
92f17f771c22fa93afe058210ddf51920aca1451 diff --git 
a/arch/powerpc/mm/hash_low_32.S b/arch/powerpc/mm/hash_low_32.S
index ddeaf9e..b9ba7d9 100644
--- a/arch/powerpc/mm/hash_low_32.S
+++ b/arch/powerpc/mm/hash_low_32.S
@@ -1,6 +1,4 @@
 /*
- *  $Id: hashtable.S,v 1.6 1999/10/08 01:56:15 paulus Exp $
- *
  *  PowerPC version
  *Copyright (C) 1995-1996 Gary Thomas ([EMAIL PROTECTED])
  *  Rewritten by Cort Dougan ([EMAIL PROTECTED]) for PReP

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc/boot/Makefile CONFIG_ variable fixes

2008-05-21 Thread Adrian Bunk
This patch corrects the names of two CONFIG_ variables.

Note that the CONFIG_MPC86XADS fix uncovers another bug
(with mpc866_ads_defconfig) that will require fixing:

<--  snip  -->

...
arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/mpc866ads.dtb -b 0  
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts
DTC: dts->dtb  on file 
"/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts"
  WRAParch/powerpc/boot/cuImage.mpc866ads
powerpc64-linux-ld: arch/powerpc/boot/cuboot-mpc866ads.o: No such file: No such 
file or directory
make[2]: *** [arch/powerpc/boot/cuImage.mpc866ads] Error 1

<--  snip  -->

Reported-by: Robert P. J. Day <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
9a0137fa7d60e7ee62ae4e08e3e5b7d94b66debf diff --git 
a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 7822d25..cfb6983 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -221,8 +221,8 @@ image-$(CONFIG_WARP)+= cuImage.warp
 image-$(CONFIG_YOSEMITE)   += cuImage.yosemite
 
 # Board ports in arch/powerpc/platform/8xx/Kconfig
-image-$(CONFIG_PPC_MPC86XADS)  += cuImage.mpc866ads
-image-$(CONFIG_PPC_MPC885ADS)  += cuImage.mpc885ads
+image-$(CONFIG_MPC86XADS)  += cuImage.mpc866ads
+image-$(CONFIG_MPC885ADS)  += cuImage.mpc885ads
 image-$(CONFIG_PPC_EP88XC) += dtbImage.ep88xc
 image-$(CONFIG_PPC_ADDER875)   += cuImage.adder875-uboot \
   dtbImage.adder875-redboot

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] phylib: Don't allow core of phylib to build as a module

2008-06-02 Thread Adrian Bunk
On Mon, Jun 02, 2008 at 11:25:14AM -0500, Kumar Gala wrote:
>
> On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote:
>
>> Kumar Gala wrote:
>>> The core portions of the phylib aren't capable of being used as
>>> a module.  This isn't really any different than something like i2c
>>> in that the bus driver and core need to be built into the kernel.
>>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>>> ---
>>> Jeff, please consider this for 2.6.26 as w/o it we get build issues
>>> if phylib is config'd as a module on ppc.
>>> drivers/net/phy/Kconfig |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
>>> index 6eb2d31..ab04cc7 100644
>>> --- a/drivers/net/phy/Kconfig
>>> +++ b/drivers/net/phy/Kconfig
>>> @@ -3,7 +3,7 @@
>>> #
>>> menuconfig PHYLIB
>>> -   tristate "PHY Device support and infrastructure"
>>> +   bool "PHY Device support and infrastructure"
>>> depends on !S390
>>> depends on NET_ETHERNET
>>
>> What are the issues?
>>
>> The core _should_ be able to be built as a module.
>
> The core provides functions like phy_read/phy_write.  Andy has recently 
> introduced board level workaround/fixups.  The problem is these 
> workarounds tend to use phy_read/phy_write and the board/platform code is 
> not built as modules.
>
> So we get errors like:
>
> arch/powerpc/platforms/built-in.o: In function `mpc8568_mds_phy_fixups':
> /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ 
> mpc85xx_mds.c:99: undefined reference to `phy_write'
>...

At first glance PHYLIB=n might also cause similar problems.

Please send me the failing .config and I'll cook up a fix.

> - k

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Adrian Bunk
On Tue, Jun 03, 2008 at 09:47:19AM -0500, Kumar Gala wrote:
> How is this as a fix.
> 
> - k
> 
> diff --git a/arch/powerpc/platforms/85xx/Kconfig 
> b/arch/powerpc/platforms/85xx/Kconfig
> index 7ff29d5..9e5c884 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -34,6 +34,7 @@ config MPC85xx_MDS
>   bool "Freescale MPC85xx MDS"
>   select DEFAULT_UIMAGE
>   select QUICC_ENGINE
> + select PHYLIB if GIANFAR=m
>   help
> This option enables support for the MPC85xx MDS board

The .config you sent me as an example didn't have GIANFAR set, so it 
couldn't help there.

How early do the fixups have to run?

I see two possible solutions:
- let MPC85xx_MDS unconditionally select PHYLIB or
- move the fixups to the gianfar driver

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: 4xx support in arch/ppc is going away Real Soon Now

2008-06-06 Thread Adrian Bunk
On Thu, Jun 05, 2008 at 09:11:48AM -0600, Grant Likely wrote:
> On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> > This commit (patch omitted due to size) is sitting in my local tree:
> >
> > commit 0d7efc1e80fc262bcc507a605482c5681e3f082a
> > Author: Josh Boyer <[EMAIL PROTECTED]>
> > Date:   Thu Jun 5 09:46:17 2008 -0500
> >
> >ppc/4xx: Remove 4xx support from arch/ppc
> >
> >Remove support for PPC 403, 405, and 440 processors from arch/ppc.  The
> >arch/powerpc equivalents should be used.  Boards that are not ported yet
> >will need to be ported to arch/powerpc to have continued support.
> 
> This looks like unneeded churn.
> 
> Paulus, Can we just kill all of arch/ppc for .27 right now?

Is anyone already working on doing this and the cleanups that will then 
be possible?

Otherwise I'll be glad to contribute to it.   :)

BTW:
I remember Paul wanted to get PReP under arch/powerpc/ working -
should this be done before the big ppc removal?

> g.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: 4xx support in arch/ppc is going away Real Soon Now

2008-06-06 Thread Adrian Bunk
On Fri, Jun 06, 2008 at 10:09:54PM +1000, Paul Mackerras wrote:
> Adrian Bunk writes:
> 
> > BTW:
> > I remember Paul wanted to get PReP under arch/powerpc/ working -
> > should this be done before the big ppc removal?
> 
> I have a PReP port for arch/powerpc that works for one machine, at
> least. :)  The key part is the residual to device-tree converter that
> I posted some time back with a request for people to test it on their
> PReP machines, but I haven't heard back from anybody.  I'm going to
> post the patch shortly anyway.

Meelis Roos <[EMAIL PROTECTED]> has a Motorola Powerstack II Pro4000 and 
recently reported (now fixed) 2.6.26-rc build problems with the rusty 
ppc code.

You might have luck asking him for testing, thereby doubling the number 
of known-working machines.  :)

> Paul.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: arch/ppc is going away Real Soon Now

2008-06-08 Thread Adrian Bunk
On Sun, Jun 08, 2008 at 06:57:10PM +0400, Jochen Friedrich wrote:
> Stefan Roese пишет:
>> On Saturday 07 June 2008, Peter Korsgaard wrote:
>>   
>>>>>>>> "Sean" == Sean MacLennan <[EMAIL PROTECTED]> writes:
>>>>>>>>   
>>>  Sean> On Fri, 06 Jun 2008 10:34:28 -0500
>>>
>>>  Sean> "Jon Loeliger" <[EMAIL PROTECTED]> wrote:
>>>  >> On Fri, 2008-06-06 at 13:19 +0200, Wolfgang Denk wrote:
>>>  >> > In message <[EMAIL PROTECTED]>
>>>  >> >
>>>  >> > Becky Bruce wrote:
>>>  >> > > On Jun 5, 2008, at 3:30 PM, Scott Wood wrote:
>>>  >> > > > Olof Johansson wrote:
>>>  >> > > >> On Jun 5, 2008, at 3:12 PM, Arnd Bergmann wrote:
>>>  >> > > >>> On Thursday 05 June 2008, Stephen Neuendorffer wrote:
>>>  >> > > >>>>> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>>>  >> > > >>>>>> Paulus, Can we just kill all of arch/ppc for .27 right now?
>>>  >> > > >>>>>
>>>  >> > > >>>>> Acked-by: Josh Boyer <[EMAIL PROTECTED]>
>>>  >> > > >>>> Acked-by: Stephen Neuendorffer
>>>  >> > > >>>> <[EMAIL PROTECTED]>
>>>  >> > > >>> Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
>>>  >> > > >> Acked-by: Olof Johansson <[EMAIL PROTECTED]>
>>>  >> > > > Acked-by: Scott Wood <[EMAIL PROTECTED]>
>>>  >> > > Acked-by: Becky Bruce <[EMAIL PROTECTED]>
>>>  >> > Acked-by: Wolfgang Denk <[EMAIL PROTECTED]>
>>>  >> Acked-by: Jon Loeliger <[EMAIL PROTECTED]>
>>>  > Acked-by: Sean MacLennan <[EMAIL PROTECTED]>
>>> Acked-by: Peter Korsgaard <[EMAIL PROTECTED]>
>> Acked-by: Stefan Roese <[EMAIL PROTECTED]>
> Acked-by: Jochen Friedrich <[EMAIL PROTECTED]>
Acked-by: Adrian Bunk <[EMAIL PROTECTED]>

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[2.6 patch] drivers/macintosh/: possible cleanups

2008-06-09 Thread Adrian Bunk
This patch contains the following possible cleanups:
- make the following needlessly global code static:
  - adb.c: adb_controller
  - adb.c: adb_init()
  - adbhid.c: adb_to_linux_keycodes[]
  - via-pmu68k.c: backlight_level
  - via-pmu68k.c: backlight_enabled
- remove the following unused code:
  - via-pmu68k.c: sleep_notifier_list

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/macintosh/adb.c|5 ++---
 drivers/macintosh/adbhid.c |2 +-
 drivers/macintosh/via-pmu68k.c |5 ++---
 include/linux/adb.h|1 -
 4 files changed, 5 insertions(+), 8 deletions(-)

45413fb42fb4215d80bb15f50a5bdc869465e9a1 diff --git a/drivers/macintosh/adb.c 
b/drivers/macintosh/adb.c
index dbaad39..61b62a6 100644
--- a/drivers/macintosh/adb.c
+++ b/drivers/macintosh/adb.c
@@ -46,7 +46,6 @@
 #endif
 
 
-EXPORT_SYMBOL(adb_controller);
 EXPORT_SYMBOL(adb_client_list);
 
 extern struct adb_driver via_macii_driver;
@@ -80,7 +79,7 @@ static struct adb_driver *adb_driver_list[] = {
 
 static struct class *adb_dev_class;
 
-struct adb_driver *adb_controller;
+static struct adb_driver *adb_controller;
 BLOCKING_NOTIFIER_HEAD(adb_client_list);
 static int adb_got_sleep;
 static int adb_inited;
@@ -290,7 +289,7 @@ static int adb_resume(struct platform_device *dev)
 }
 #endif /* CONFIG_PM */
 
-int __init adb_init(void)
+static int __init adb_init(void)
 {
struct adb_driver *driver;
int i;
diff --git a/drivers/macintosh/adbhid.c b/drivers/macintosh/adbhid.c
index ef4c117..af72f97 100644
--- a/drivers/macintosh/adbhid.c
+++ b/drivers/macintosh/adbhid.c
@@ -75,7 +75,7 @@ static struct notifier_block adbhid_adb_notifier = {
 #define ADB_KEY_POWER_OLD  0x7e
 #define ADB_KEY_POWER  0x7f
 
-u16 adb_to_linux_keycodes[128] = {
+static u16 adb_to_linux_keycodes[128] = {
/* 0x00 */ KEY_A,   /*  30 */
/* 0x01 */ KEY_S,   /*  31 */
/* 0x02 */ KEY_D,   /*  32 */
diff --git a/drivers/macintosh/via-pmu68k.c b/drivers/macintosh/via-pmu68k.c
index e2f84da..b64741c 100644
--- a/drivers/macintosh/via-pmu68k.c
+++ b/drivers/macintosh/via-pmu68k.c
@@ -101,7 +101,6 @@ static int pmu_kind = PMU_UNKNOWN;
 static int pmu_fully_inited;
 
 int asleep;
-BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
 
 static int pmu_probe(void);
 static int pmu_init(void);
@@ -741,8 +740,8 @@ pmu_handle_data(unsigned char *data, int len)
}
 }
 
-int backlight_level = -1;
-int backlight_enabled = 0;
+static int backlight_level = -1;
+static int backlight_enabled = 0;
 
 #define LEVEL_TO_BRIGHT(lev)   ((lev) < 1? 0x7f: 0x4a - ((lev) << 1))
 
diff --git a/include/linux/adb.h b/include/linux/adb.h
index 64d8878..63bca50 100644
--- a/include/linux/adb.h
+++ b/include/linux/adb.h
@@ -84,7 +84,6 @@ enum adb_message {
 ADB_MSG_PRE_RESET, /* Called before resetting the bus */
 ADB_MSG_POST_RESET /* Called after resetting the bus (re-do init & 
register) */
 };
-extern struct adb_driver *adb_controller;
 extern struct blocking_notifier_head adb_client_list;
 
 int adb_request(struct adb_request *req, void (*done)(struct adb_request *),

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] drivers/macintosh/mediabay.c build fix

2008-06-10 Thread Adrian Bunk
This patch fixes the following build error with CONFIG_BLK_DEV_IDE_PMAC=n:

<--  snip  -->

...
  CC  drivers/macintosh/mediabay.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/macintosh/mediabay.c: In 
function 'check_media_bay':
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/macintosh/mediabay.c:428: 
error: 'struct media_bay_info' has no member named 'cd_index'
make[3]: *** [drivers/macintosh/mediabay.o] Error 1

<--  snip  -->

Reported-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/macintosh/mediabay.c   |4 ++--
 include/asm-powerpc/mediabay.h |   12 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

e644eb541d73b1fe13550506398d725a536c6aef diff --git 
a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index 82add26..7d406ef 100644
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -84,7 +84,7 @@ struct media_bay_info {
int cd_irq;
int cd_retry;
 #endif
-#if defined(CONFIG_BLK_DEV_IDE_PMAC) || defined(CONFIG_MAC_FLOPPY)
+#if defined(CONFIG_BLK_DEV_IDE_PMAC)
int cd_index;
 #endif
 };
@@ -417,6 +417,7 @@ static void poll_media_bay(struct media_bay_info* bay)
}
 }
 
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
 int check_media_bay(struct device_node *which_bay, int what)
 {
int i;
@@ -432,7 +433,6 @@ int check_media_bay(struct device_node *which_bay, int what)
 }
 EXPORT_SYMBOL(check_media_bay);
 
-#ifdef CONFIG_BLK_DEV_IDE_PMAC
 int check_media_bay_by_base(unsigned long base, int what)
 {
int i;
diff --git a/include/asm-powerpc/mediabay.h b/include/asm-powerpc/mediabay.h
index df111c3..b2efb33 100644
--- a/include/asm-powerpc/mediabay.h
+++ b/include/asm-powerpc/mediabay.h
@@ -17,8 +17,6 @@
 #define MB_POWER   6   /* media bay contains a Power device (???) */
 #define MB_NO  7   /* media bay contains nothing */
 
-int check_media_bay(struct device_node *which_bay, int what);
-
 /* Number of bays in the machine or 0 */
 extern int media_bay_count;
 
@@ -29,6 +27,16 @@ int check_media_bay_by_base(unsigned long base, int what);
 /* called by IDE PMAC host driver to register IDE controller for media bay */
 int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
int irq, ide_hwif_t *hwif);
+
+int check_media_bay(struct device_node *which_bay, int what);
+
+#else
+
+static inline int check_media_bay(struct device_node *which_bay, int what)
+{
+   return -ENODEV;
+}
+
 #endif
 
 #endif /* __KERNEL__ */

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC PATCH 2/2] Update defconfigs for CONFIG_HUGETLB

2008-06-12 Thread Adrian Bunk
On Thu, Jun 12, 2008 at 02:55:45PM -0400, Adam Litke wrote:
> Update all defconfigs that specify a default configuration for hugetlbfs.
> There is now only one option: CONFIG_HUGETLB.  Replace the old
> CONFIG_HUGETLB_PAGE and CONFIG_HUGETLBFS options with the new one.  I found no
> cases where CONFIG_HUGETLBFS and CONFIG_HUGETLB_PAGE had different values so
> this patch is large but completely mechanical:
>...
>  335 files changed, 335 insertions(+), 385 deletions(-)
>...

Please don't do this kind of patches - it doesn't bring any advantage 
but can create tons of patch conflicts.

The next time a defconfig gets updated it will anyway automatically be 
fixed, and for defconfigs that aren't updated it doesn't create any 
problems to keep them as they are today until they might one day get 
updated.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [Bug 10714] Badness seen on 2.6.26-rc2 with lockdep enabled

2008-06-14 Thread Adrian Bunk
On Sat, Jun 14, 2008 at 10:12:02PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10714
> Subject   : Badness seen on 2.6.26-rc2 with lockdep enabled
> Submitter : Balbir Singh <[EMAIL PROTECTED]>
> Date  : 2008-05-14 12:57 (32 days old)
> References: http://marc.info/?l=linux-kernel&m=121076917429133&w=4

Benjamin, you said you wanted to have a look at this?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [git pull] Please pull powerpc.git merge branch

2008-06-16 Thread Adrian Bunk
On Mon, Jun 16, 2008 at 09:25:05PM +1000, Paul Mackerras wrote:
> Linus,
> 
> As Ben pointed out, I had forgotten to re-do a couple of defconfigs
> where I had inadvertently turned off the SATA driver for the G5
> powermacs.  So when you do the pull as I requested earlier from
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
> 
> you'll also get one more commit as listed below.
> 
> Thanks,
> Paul.
> 
>  arch/powerpc/configs/g5_defconfig|   62 ++--
>  arch/powerpc/configs/ppc64_defconfig |   66 
> --
>  2 files changed, 122 insertions(+), 6 deletions(-)
> 
> Paul Mackerras (1):
>   [POWERPC] Turn on ATA_SFF so we get SATA_SVW back in defconfigs
>...

What about my patch [1] to eliminate this new trap in kconfig since we 
do not have to bother kconfig users with ATA_SFF at all?

Besides some orthoginal discussion whether this stuff should actually be 
called SFF I am not aware of any reactions to my patch from the ATA 
people.

I already sent this patch twice and I can update it to the latest tree 
if it's considered OK, but I'd like to get some ACK/NAK first.

cu
Adrian

[1] http://lkml.org/lkml/2008/4/21/501

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] drivers/macintosh/: possible cleanups

2008-06-23 Thread Adrian Bunk
On Tue, Jun 10, 2008 at 10:21:25AM +1000, Stephen Rothwell wrote:
> Hi Adrian,
> 
> On Tue, 10 Jun 2008 01:23:12 +0300 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > +++ b/drivers/macintosh/adbhid.c
> > @@ -75,7 +75,7 @@ static struct notifier_block adbhid_adb_notifier = {
> >  #define ADB_KEY_POWER_OLD  0x7e
> >  #define ADB_KEY_POWER  0x7f
> >  
> > -u16 adb_to_linux_keycodes[128] = {
> > +static u16 adb_to_linux_keycodes[128] = {
> 
> This could be const as well.

Updated patch below.

cu
Adrian


<--  snip  -->


This patch contains the following possible cleanups:
- make the following needlessly global code static:
  - adb.c: adb_controller
  - adb.c: adb_init()
  - adbhid.c: adb_to_linux_keycodes[]  (also make it const)
  - via-pmu68k.c: backlight_level
  - via-pmu68k.c: backlight_enabled
- remove the following unused code:
  - via-pmu68k.c: sleep_notifier_list

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/macintosh/adb.c|5 ++---
 drivers/macintosh/adbhid.c |2 +-
 drivers/macintosh/via-pmu68k.c |5 ++---
 include/linux/adb.h|1 -
 4 files changed, 5 insertions(+), 8 deletions(-)

45413fb42fb4215d80bb15f50a5bdc869465e9a1 diff --git a/drivers/macintosh/adb.c 
b/drivers/macintosh/adb.c
index dbaad39..61b62a6 100644
--- a/drivers/macintosh/adb.c
+++ b/drivers/macintosh/adb.c
@@ -46,7 +46,6 @@
 #endif
 
 
-EXPORT_SYMBOL(adb_controller);
 EXPORT_SYMBOL(adb_client_list);
 
 extern struct adb_driver via_macii_driver;
@@ -80,7 +79,7 @@ static struct adb_driver *adb_driver_list[] = {
 
 static struct class *adb_dev_class;
 
-struct adb_driver *adb_controller;
+static struct adb_driver *adb_controller;
 BLOCKING_NOTIFIER_HEAD(adb_client_list);
 static int adb_got_sleep;
 static int adb_inited;
@@ -290,7 +289,7 @@ static int adb_resume(struct platform_device *dev)
 }
 #endif /* CONFIG_PM */
 
-int __init adb_init(void)
+static int __init adb_init(void)
 {
struct adb_driver *driver;
int i;
diff --git a/drivers/macintosh/adbhid.c b/drivers/macintosh/adbhid.c
index ef4c117..af72f97 100644
--- a/drivers/macintosh/adbhid.c
+++ b/drivers/macintosh/adbhid.c
@@ -75,7 +75,7 @@ static struct notifier_block adbhid_adb_notifier = {
 #define ADB_KEY_POWER_OLD  0x7e
 #define ADB_KEY_POWER  0x7f
 
-u16 adb_to_linux_keycodes[128] = {
+static const u16 adb_to_linux_keycodes[128] = {
/* 0x00 */ KEY_A,   /*  30 */
/* 0x01 */ KEY_S,   /*  31 */
/* 0x02 */ KEY_D,   /*  32 */
diff --git a/drivers/macintosh/via-pmu68k.c b/drivers/macintosh/via-pmu68k.c
index e2f84da..b64741c 100644
--- a/drivers/macintosh/via-pmu68k.c
+++ b/drivers/macintosh/via-pmu68k.c
@@ -101,7 +101,6 @@ static int pmu_kind = PMU_UNKNOWN;
 static int pmu_fully_inited;
 
 int asleep;
-BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
 
 static int pmu_probe(void);
 static int pmu_init(void);
@@ -741,8 +740,8 @@ pmu_handle_data(unsigned char *data, int len)
}
 }
 
-int backlight_level = -1;
-int backlight_enabled = 0;
+static int backlight_level = -1;
+static int backlight_enabled = 0;
 
 #define LEVEL_TO_BRIGHT(lev)   ((lev) < 1? 0x7f: 0x4a - ((lev) << 1))
 
diff --git a/include/linux/adb.h b/include/linux/adb.h
index 64d8878..63bca50 100644
--- a/include/linux/adb.h
+++ b/include/linux/adb.h
@@ -84,7 +84,6 @@ enum adb_message {
 ADB_MSG_PRE_RESET, /* Called before resetting the bus */
 ADB_MSG_POST_RESET /* Called after resetting the bus (re-do init & 
register) */
 };
-extern struct adb_driver *adb_controller;
 extern struct blocking_notifier_head adb_client_list;
 
 int adb_request(struct adb_request *req, void (*done)(struct adb_request *),

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] asm/ptrace.h userspace headers cleanup

2008-06-23 Thread Adrian Bunk
This patch contains the following cleanups for the asm/ptrace.h 
userspace headers:
- include/asm-generic/Kbuild.asm already lists ptrace.h, remove
  the superfluous listings in the Kbuild files of the following
  architectures:
  - cris
  - frv
  - powerpc
  - x86
- don't expose function prototypes and macros to userspace:
  - arm
  - blackfin
  - cris
  - mn10300
  - parisc
- remove #ifdef CONFIG_'s around #define's:
  - blackfin
  - m68knommu
- sh: AFAIK __SH5__ should work in both kernel and userspace,
  no need to leak CONFIG_SUPERH64 to userspace
- xtensa: cosmetical change to remove empty
#ifndef __ASSEMBLY__ #else #endif
  from the userspace headers

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

Not changed by this patch is the fact that the following architectures 
have a different struct pt_regs depending on CONFIG_ variables:
- h8300
- m68knommu
- mips

This does not work in userspace.


 include/asm-arm/ptrace.h   |6 ++
 include/asm-blackfin/ptrace.h  |6 --
 include/asm-cris/arch-v10/Kbuild   |1 -
 include/asm-cris/arch-v10/ptrace.h |4 
 include/asm-cris/arch-v32/Kbuild   |1 -
 include/asm-cris/arch-v32/ptrace.h |4 
 include/asm-cris/ptrace.h  |4 +++-
 include/asm-frv/Kbuild |1 -
 include/asm-m68knommu/ptrace.h |2 --
 include/asm-mn10300/ptrace.h   |8 ++--
 include/asm-parisc/ptrace.h|4 +++-
 include/asm-powerpc/Kbuild |1 -
 include/asm-sh/ptrace.h|2 +-
 include/asm-x86/Kbuild |1 -
 include/asm-xtensa/ptrace.h|   10 +-
 15 files changed, 32 insertions(+), 23 deletions(-)

fc14755b77cff7af5ff00e938a4c493a669e25cd diff --git a/include/asm-arm/ptrace.h 
b/include/asm-arm/ptrace.h
index 7aaa206..8382b75 100644
--- a/include/asm-arm/ptrace.h
+++ b/include/asm-arm/ptrace.h
@@ -139,8 +139,6 @@ static inline int valid_user_regs(struct pt_regs *regs)
return 0;
 }
 
-#endif /* __KERNEL__ */
-
 #define pc_pointer(v) \
((v) & ~PCMASK)
 
@@ -153,10 +151,10 @@ extern unsigned long profile_pc(struct pt_regs *regs);
 #define profile_pc(regs) instruction_pointer(regs)
 #endif
 
-#ifdef __KERNEL__
 #define predicate(x)   ((x) & 0xf000)
 #define PREDICATE_ALWAYS   0xe000
-#endif
+
+#endif /* __KERNEL__ */
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/include/asm-blackfin/ptrace.h b/include/asm-blackfin/ptrace.h
index b8346cd..a45a80e 100644
--- a/include/asm-blackfin/ptrace.h
+++ b/include/asm-blackfin/ptrace.h
@@ -83,14 +83,14 @@ struct pt_regs {
 #define PTRACE_GETREGS12
 #define PTRACE_SETREGS13   /* ptrace signal  */
 
-#ifdef CONFIG_BINFMT_ELF_FDPIC
 #define PTRACE_GETFDPIC   31
 #define PTRACE_GETFDPIC_EXEC  0
 #define PTRACE_GETFDPIC_INTERP1
-#endif
 
 #define PS_S  (0x0002)
 
+#ifdef __KERNEL__
+
 /* user_mode returns true if only one bit is set in IPEND, other than the
master interrupt enable.  */
 #define user_mode(regs) (!(((regs)->ipend & ~0x10) & (((regs)->ipend & ~0x10) 
- 1)))
@@ -98,6 +98,8 @@ struct pt_regs {
 #define profile_pc(regs) instruction_pointer(regs)
 extern void show_regs(struct pt_regs *);
 
+#endif  /*  __KERNEL__  */
+
 #endif /* __ASSEMBLY__ */
 
 /*
diff --git a/include/asm-cris/arch-v10/Kbuild b/include/asm-cris/arch-v10/Kbuild
index 60e7e1b..7a192e1 100644
--- a/include/asm-cris/arch-v10/Kbuild
+++ b/include/asm-cris/arch-v10/Kbuild
@@ -1,4 +1,3 @@
-header-y += ptrace.h
 header-y += user.h
 header-y += svinto.h
 header-y += sv_addr_ag.h
diff --git a/include/asm-cris/arch-v10/ptrace.h 
b/include/asm-cris/arch-v10/ptrace.h
index fb14c5e..2f464ea 100644
--- a/include/asm-cris/arch-v10/ptrace.h
+++ b/include/asm-cris/arch-v10/ptrace.h
@@ -106,10 +106,14 @@ struct switch_stack {
unsigned long return_ip; /* ip that _resume will return to */
 };
 
+#ifdef __KERNEL__
+
 /* bit 8 is user-mode flag */
 #define user_mode(regs) (((regs)->dccr & 0x100) != 0)
 #define instruction_pointer(regs) ((regs)->irp)
 #define profile_pc(regs) instruction_pointer(regs)
 extern void show_regs(struct pt_regs *);
 
+#endif  /*  __KERNEL__  */
+
 #endif
diff --git a/include/asm-cris/arch-v32/Kbuild b/include/asm-cris/arch-v32/Kbuild
index a0ec545..35f2fc4 100644
--- a/include/asm-cris/arch-v32/Kbuild
+++ b/include/asm-cris/arch-v32/Kbuild
@@ -1,3 +1,2 @@
-header-y += ptrace.h
 header-y += user.h
 header-y += cryptocop.h
diff --git a/include/asm-cris/arch-v32/ptrace.h 
b/include/asm-cris/arch-v32/ptrace.h
index 516cc70..41f4e86 100644
--- a/include/asm-cris/arch-v32/ptrace.h
+++ b/include/asm-cris/arch-v32/ptrace.h
@@ -106,9 +106,13 @@ struct switch_stack {
unsigned long return_ip; /* ip that _resume will return to */
 };
 
+#ifdef __KERNEL__
+
 #define user_mode(regs) (((regs)->ccs & (1 << (U_CCS_BITNR + CCS_SHIFT)

[RFC: 2.6 patch] powerpc: don't export asm/asm-compat.h to userspace

2008-06-23 Thread Adrian Bunk
asm/asm-compat.h doesn't seem to be intended for userspace usage.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 include/asm-powerpc/Kbuild |1 -
 include/asm-powerpc/cputable.h |5 +++--
 2 files changed, 3 insertions(+), 3 deletions(-)

4c78f2fc562d3aae525c8f62706a80479228c50e diff --git 
a/include/asm-powerpc/Kbuild b/include/asm-powerpc/Kbuild
index 6920904..90cb216 100644
--- a/include/asm-powerpc/Kbuild
+++ b/include/asm-powerpc/Kbuild
@@ -24,7 +24,6 @@ header-y += sigcontext.h
 header-y += statfs.h
 header-y += ps3fb.h
 
-unifdef-y += asm-compat.h
 unifdef-y += bootx.h
 unifdef-y += byteorder.h
 unifdef-y += cputable.h
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 1e79673..08b594a 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -1,8 +1,6 @@
 #ifndef __ASM_POWERPC_CPUTABLE_H
 #define __ASM_POWERPC_CPUTABLE_H
 
-#include 
-
 #define PPC_FEATURE_32 0x8000
 #define PPC_FEATURE_64 0x4000
 #define PPC_FEATURE_601_INSTR  0x2000
@@ -31,6 +29,9 @@
 #define PPC_FEATURE_PPC_LE 0x0001
 
 #ifdef __KERNEL__
+
+#include 
+
 #ifndef __ASSEMBLY__
 
 /* This structure can grow, it's real size is used by head.S code

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[RFC: 2.6 patch] powerpc: asm/elf.h: reduce userspace header

2008-06-23 Thread Adrian Bunk
This patch makes asm/elf.h export less non-userspace stuff to userspace.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 include/asm-powerpc/elf.h |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

6e868802e4b350a9dac071044b7cf52af7404134 diff --git a/include/asm-powerpc/elf.h 
b/include/asm-powerpc/elf.h
index 9080d85..d1e3bda 100644
--- a/include/asm-powerpc/elf.h
+++ b/include/asm-powerpc/elf.h
@@ -224,8 +224,6 @@ extern int dump_task_altivec(struct task_struct *, 
elf_vrregset_t *vrregs);
 #define ELF_CORE_XFPREG_TYPE NT_PPC_VMX
 #endif
 
-#endif /* __KERNEL__ */
-
 /* ELF_HWCAP yields a mask that user programs can use to figure out what
instruction set this cpu supports.  This could be done in userspace,
but it's not easy, and we've already done it here.  */
@@ -243,8 +241,6 @@ extern int dump_task_altivec(struct task_struct *, 
elf_vrregset_t *vrregs);
 } while (0)
 #endif /* __powerpc64__ */
 
-#ifdef __KERNEL__
-
 #ifdef __powerpc64__
 # define SET_PERSONALITY(ex, ibcs2)\
 do {   \
@@ -272,8 +268,6 @@ do {
\
 # define SET_PERSONALITY(ex, ibcs2) set_personality((ibcs2)?PER_SVR4:PER_LINUX)
 #endif /* __powerpc64__ */
 
-#endif /* __KERNEL__ */
-
 extern int dcache_bsize;
 extern int icache_bsize;
 extern int ucache_bsize;
@@ -285,6 +279,8 @@ extern int arch_setup_additional_pages(struct linux_binprm 
*bprm,
   int executable_stack);
 #define VDSO_AUX_ENT(a,b) NEW_AUX_ENT(a,b);
 
+#endif /* __KERNEL__ */
+
 /*
  * The requirements here are:
  * - keep the final alignment of sp (sp & 0xf)
@@ -422,6 +418,8 @@ do {
\
 /* Keep this the last entry.  */
 #define R_PPC64_NUM107
 
+#ifdef  __KERNEL__
+
 #ifdef CONFIG_SPU_BASE
 /* Notes used in ET_CORE. Note name is "SPU//". */
 #define NT_SPU 1
@@ -430,4 +428,6 @@ do {
\
 
 #endif /* CONFIG_SPU_BASE */
 
+#endif /* __KERNEL */
+
 #endif /* _ASM_POWERPC_ELF_H */

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 02/60] microblaze_v4: Makefiles for Microblaze cpu

2008-06-26 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 02:29:31PM +0200, [EMAIL PROTECTED] wrote:
>...
> --- /dev/null
> +++ b/arch/microblaze/Makefile
>...
> +# Work out HW multipler support.  This is icky.
> +# 1. Spartan2 has no HW multiplers.
> +# 2. MicroBlaze v3.x always uses them, except in Spartan 2
> +# 3. All other FPGa/CPU ver combos, we can trust the CONFIG_ settings
> +ifeq (,$(findstring spartan2,$(CONFIG_XILINX_MICROBLAZE0_FAMILY)))
> +  ifeq ($(CPU_MAJOR),3)
> +CPUFLAGS-1 += -mno-xl-soft-mul
> +  else
> +# USE_HW_MUL can be 0, 1, or 2, defining a heirarchy of HW Mul support.
> +CPUFLAGS-$(subst 1,,$(CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL)) += 
> -mxl-multiply-high
> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL) += -mno-xl-soft-mul
> +  endif
> +endif
> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP) += -mxl-pattern-compare
> +
> +CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
> +
> +# The various CONFIG_XILINX cpu features options are integers 0/1/2...
> +# rather than bools y/n
> +CFLAGS += $(CPUFLAGS-1)
> +CFLAGS += $(CPUFLAGS-2)
>...

Why are the options not bools?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 07/60] microblaze_v4: Support for semaphores

2008-06-26 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 02:29:36PM +0200, [EMAIL PROTECTED] wrote:
> From: Michal Simek <[EMAIL PROTECTED]>
> 
> 
> Signed-off-by: Michal Simek <[EMAIL PROTECTED]>
> ---
>  include/asm-microblaze/semaphore.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>  create mode 100644 include/asm-microblaze/semaphore.h
> 
> diff --git a/include/asm-microblaze/semaphore.h 
> b/include/asm-microblaze/semaphore.h
> new file mode 100644
> index 000..d9b2034
> --- /dev/null
> +++ b/include/asm-microblaze/semaphore.h
> @@ -0,0 +1 @@
> +#include 

In -next all asm/semaphore.h headers gained a
  #warning Use linux/semaphore.h, not asm/semaphore.h
and the number of asm/semaphore.h is approaching zero.

You can simply drop this patch.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 30/60] microblaze_v4: support for a.out

2008-06-26 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 02:29:59PM +0200, [EMAIL PROTECTED] wrote:
> From: Michal Simek <[EMAIL PROTECTED]>
> 
> 
> Signed-off-by: Michal Simek <[EMAIL PROTECTED]>
> ---
>  0 files changed, 0 insertions(+), 0 deletions(-)
>  create mode 100644 include/asm-microblaze/a.out.h
> 
> diff --git a/include/asm-microblaze/a.out.h b/include/asm-microblaze/a.out.h
> new file mode 100644
> index 000..e69de29

As of 2.6.26-rc7 you do no longer need this header.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Microblaze init port v4

2008-06-26 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 02:29:29PM +0200, [EMAIL PROTECTED] wrote:
> Hi everybody,
> 
> current linux version is 2.6.26-rc8 and I think this is the right time
> to send latest patches againts rc8 for Microblaze CPU.
>...

Thanks for your work on getting the architecture included.

I have two questions:

Where can I find a toolchain for compiling a Microblaze kernel?
What is the status of Microblaze support in upstream binutils and gcc?

> Best regards,
> Michal Simek

TIA
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-26 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 05:35:11PM +0200, Arnd Bergmann wrote:
> On Thursday 26 June 2008, [EMAIL PROTECTED] wrote:
> > +
> > +#ifndef _ASM_MICROBLAZE_NAMEI_H
> > +#define _ASM_MICROBLAZE_NAMEI_H
> > +
> > +#ifdef __KERNEL__
> > +
> > +/* This dummy routine maybe changed to something useful
> > + * for /usr/gnemul/ emulation stuff.
> > + * Look at asm-sparc/namei.h for details.
> > + */
> > +#define __emul_prefix() NULL
> > +
> > +#endif /* __KERNEL__ */
> > +
> > +#endif /* _ASM_MICROBLAZE_NAMEI_H */
> 
> Could you move this to asm-generic? Note that the comment is wrong,
> asm-sparc doesn't actually implement it any more, only ia64, mips and
> arm have an implementation that actually does something interesting
> here.

The comment could be nuked (as well as the #ifdef __KERNEL__), but for 
the one #define an asm-generic header would IMHO be overkill.

>   Arnd <><

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-26 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 06:38:32PM +0200, Arnd Bergmann wrote:
> On Thursday 26 June 2008, Adrian Bunk wrote:
> > The comment could be nuked (as well as the #ifdef __KERNEL__), but for 
> > the one #define an asm-generic header would IMHO be overkill.
> 
> I agree that it doesn't technically make sense to have a one-line
> asm-generic header, but I like the idea of reducing the number of
> asm/*.h files that actually contain anything other that
> #include , mostly for documentation purposes.
> 
> If we can eventually agree on a way to get rid of the requirement
> for explicit redirection, we can remove a larger number of source
> files completely.

Honestly, I do not completely like your approach of getting the 
microblaze port submitter to create the asm-generic files - I would 
personally prefer if the microblaze port would look exactly like all 
other ports and the (reasonable) changes you have in mind were not
being discussed and done as part of the submission of a new port.

After all, it won't matter whether we'll unify resp. remove
22 or 23 files.

>   Arnd <><

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 02/60] microblaze_v4: Makefiles for Microblaze cpu

2008-06-26 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 08:46:44PM +0200, Michal Simek wrote:
> Adrian Bunk napsal(a):
> > On Thu, Jun 26, 2008 at 02:29:31PM +0200, [EMAIL PROTECTED] wrote:
> >> ...
> >> --- /dev/null
> >> +++ b/arch/microblaze/Makefile
> >> ...
> >> +# Work out HW multipler support.  This is icky.
> >> +# 1. Spartan2 has no HW multiplers.
> >> +# 2. MicroBlaze v3.x always uses them, except in Spartan 2
> >> +# 3. All other FPGa/CPU ver combos, we can trust the CONFIG_ settings
> >> +ifeq (,$(findstring spartan2,$(CONFIG_XILINX_MICROBLAZE0_FAMILY)))
> >> +  ifeq ($(CPU_MAJOR),3)
> >> +CPUFLAGS-1 += -mno-xl-soft-mul
> >> +  else
> >> +# USE_HW_MUL can be 0, 1, or 2, defining a heirarchy of HW Mul 
> >> support.
> >> +CPUFLAGS-$(subst 1,,$(CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL)) += 
> >> -mxl-multiply-high
> >> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL) += -mno-xl-soft-mul
> >> +  endif
> >> +endif
> >> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
> >> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
> >> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP) += -mxl-pattern-compare
> >> +
> >> +CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
> >> +
> >> +# The various CONFIG_XILINX cpu features options are integers 0/1/2...
> >> +# rather than bools y/n
> >> +CFLAGS += $(CPUFLAGS-1)
> >> +CFLAGS += $(CPUFLAGS-2)
> >> ...
> > 
> > Why are the options not bools?
> > 
> > cu
> > Adrian
> 
> because CONFIG_XILINX_... are 0, 1 or 2 not only y, n.

I understood that.

But _why_ are these options not bools?

In most cases the order of gcc flags does not matter, and it is not 
obvious for me why the order matters here.

> M

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Microblaze init port v4

2008-06-26 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 08:50:37PM +0200, Michal Simek wrote:
> Hi Adrian,
> 
> > On Thu, Jun 26, 2008 at 02:29:29PM +0200, [EMAIL PROTECTED] wrote:
> >> Hi everybody,
> >>
> >> current linux version is 2.6.26-rc8 and I think this is the right time
> >> to send latest patches againts rc8 for Microblaze CPU.
> >> ...
> > 
> > Thanks for your work on getting the architecture included.
> > 
> > I have two questions:
> > 
> > Where can I find a toolchain for compiling a Microblaze kernel?
> I personally use petalogix toolchain from www.petalogix.com.
> 
> > What is the status of Microblaze support in upstream binutils and gcc?
> 
> I don't have any information about. We will discuss with John Williams and 
> guys
> from Xilinx
> what we can do for it.

Thanks!

> M

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-27 Thread Adrian Bunk
On Fri, Jun 27, 2008 at 01:23:05AM +0200, Arnd Bergmann wrote:
> On Thursday 26 June 2008, Adrian Bunk wrote:
> > Honestly, I do not completely like your approach of getting the 
> > microblaze port submitter to create the asm-generic files - I would 
> > personally prefer if the microblaze port would look exactly like all 
> > other ports and the (reasonable) changes you have in mind were not
> > being discussed and done as part of the submission of a new port.
> 
> But it works really well this way ;-). My point is that a new port
> should look just like all the other ports should have looked as
> well, not like they did. When it comes to the ABI, you
> cannot make incompatible changes after it's merged, so IMHO all
> ABI defining headers should go to asm-generic if possible.
>...

For the ABI it doesn't matter where the headers are.

> > After all, it won't matter whether we'll unify resp. remove
> > 22 or 23 files.
> 
> That wasn't my idea. The logic was that if one more file exists
> in asm-generic that can be removed from the architectures,
> we get 22 more files to remove without anyone having to look
> at the big picture. When microblaze is in,

Discussions of the "big picture" should be in an own thread, not as 
part of a merge of a new architecture.

I am not an architecture maintainer, but I do not like the way you want 
to couple the microblaze merge with the move of stuff to asm-generic.

They both make sense, but they are clearly separate issues.

> I can compile a list
> with asm-generic files that can be used to replace the architecture
> specific files, so the arch maintainers can decide on their own
> whether to clean their own stuff up or not.
>...

We need either all architectures changed or none at all - we do need the 
arch headers to become more similar, not more different.

And this is why we need an agreement _before_ an asm-generic header gets 
added, not after it.

>   Arnd <><

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 27/60] microblaze_v4: virtualization

2008-07-01 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 02:29:56PM +0200, [EMAIL PROTECTED] wrote:
> From: Michal Simek <[EMAIL PROTECTED]>
> 
> 
> Signed-off-by: Michal Simek <[EMAIL PROTECTED]>
> ---
>  include/asm-microblaze/kvm.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>  create mode 100644 include/asm-microblaze/kvm.h
> 
> diff --git a/include/asm-microblaze/kvm.h b/include/asm-microblaze/kvm.h
> new file mode 100644
> index 000..01c5e79
> --- /dev/null
> +++ b/include/asm-microblaze/kvm.h
> @@ -0,0 +1 @@
> +/* Microblaze does not support KVM */

There's a patch pending for 2.6.27 that will remove the requirement for 
this empty header.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc: remove duplicate 6xx option

2008-07-17 Thread Adrian Bunk
The real option is above in the same Kconfig file.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
2251e74345df51309579a0a5fd8339e2f14762b9 
diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index 5bc4b61..6489d57 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -84,9 +84,6 @@ config TUNE_CELL
  machines. When building a kernel that is supposed to run only
  on Cell, you should also select the POWER4_ONLY option.
 
-config 6xx
-   bool
-
 # this is temp to handle compat with arch=ppc
 config 8xx
bool

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc/boot/Makefile: change spaces to tabs

2008-07-17 Thread Adrian Bunk
For C code spaces versus tabs is just a religious issue,
but for Makefiles it actually matters.

This patch fixes he following errors:
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/Makefile:166: *** 
missing separator.  Stop.
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/Makefile:171: *** 
missing separator.  Stop.

Since this was inside an ifdef DTC_GENPARSER it was not a problem unless 
someone wanted to regenerate the shipped generated files.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/powerpc/boot/Makefile |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -163,12 +163,12 @@ quiet_cmd_flex = FLEX$@
   cmd_flex = $(FLEX) -o$@ $<; cp $@ [EMAIL PROTECTED]
 
 $(obj)/dtc-src/dtc-parser.tab.c: $(src)/dtc-src/dtc-parser.y FORCE
- $(call if_changed,bison)
+   $(call if_changed,bison)
 
 $(obj)/dtc-src/dtc-parser.tab.h: $(obj)/dtc-src/dtc-parser.tab.c
 
 $(obj)/dtc-src/dtc-lexer.lex.c: $(src)/dtc-src/dtc-lexer.l FORCE
- $(call if_changed,flex)
+   $(call if_changed,flex)
 endif
 
 #

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc/boot/dtc-src/dtc-lexer.l: add %option noinput

2008-07-17 Thread Adrian Bunk
gcc 4.3 correctly determines that input() is unused and gives the 
following warning:

<--  snip  -->

...
  HOSTCC  arch/powerpc/boot/dtc-src/dtc-lexer.lex.o
dtc-lexer.lex.c:1436: warning: ‘input’ defined but not used
...

<--  snip  -->

Fix it by adding %option noinput to 
arch/powerpc/boot/dtc-src/dtc-lexer.l and 
regeneration of arch/powerpc/boot/dtc-src/dtc-lexer.lex.c_shipped.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/powerpc/boot/dtc-src/dtc-lexer.l |2 
 arch/powerpc/boot/dtc-src/dtc-lexer.lex.c_shipped |  127 +-
 2 files changed, 84 insertions(+), 45 deletions(-)

551cd080360b31cf9b8bb387916f3852e4fb6156 
diff --git a/arch/powerpc/boot/dtc-src/dtc-lexer.l 
b/arch/powerpc/boot/dtc-src/dtc-lexer.l
index c811b22..1f76fea 100644
--- a/arch/powerpc/boot/dtc-src/dtc-lexer.l
+++ b/arch/powerpc/boot/dtc-src/dtc-lexer.l
@@ -18,7 +18,7 @@
  *   USA
  */
 
-%option noyywrap nounput yylineno
+%option noyywrap nounput yylineno noinput
 
 %x INCLUDE
 %x BYTESTRING
diff --git a/arch/powerpc/boot/dtc-src/dtc-lexer.lex.c_shipped 
b/arch/powerpc/boot/dtc-src/dtc-lexer.lex.c_shipped
index d0f7424..fa309bc 100644
--- a/arch/powerpc/boot/dtc-src/dtc-lexer.lex.c_shipped
+++ b/arch/powerpc/boot/dtc-src/dtc-lexer.lex.c_shipped
@@ -1,6 +1,6 @@
-#line 2 "dtc-lexer.lex.c"
+#line 2 "arch/powerpc/boot/dtc-src/dtc-lexer.lex.c"
 
-#line 4 "dtc-lexer.lex.c"
+#line 4 "arch/powerpc/boot/dtc-src/dtc-lexer.lex.c"
 
 #define  YY_INT_ALIGNED short int
 
@@ -9,7 +9,7 @@
 #define FLEX_SCANNER
 #define YY_FLEX_MAJOR_VERSION 2
 #define YY_FLEX_MINOR_VERSION 5
-#define YY_FLEX_SUBMINOR_VERSION 33
+#define YY_FLEX_SUBMINOR_VERSION 35
 #if YY_FLEX_SUBMINOR_VERSION > 0
 #define FLEX_BETA
 #endif
@@ -31,7 +31,7 @@
 
 /* C99 systems have . Non-C99 systems may or may not. */
 
-#if __STDC_VERSION__ >= 199901L
+#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
 
 /* C99 says to define __STDC_LIMIT_MACROS before including stdint.h,
  * if you want the limit (max/min) macros for int types. 
@@ -54,7 +54,6 @@ typedef int flex_int32_t;
 typedef unsigned char flex_uint8_t; 
 typedef unsigned short int flex_uint16_t;
 typedef unsigned int flex_uint32_t;
-#endif /* ! C99 */
 
 /* Limits of integral types. */
 #ifndef INT8_MIN
@@ -85,6 +84,8 @@ typedef unsigned int flex_uint32_t;
 #define UINT32_MAX (4294967295U)
 #endif
 
+#endif /* ! C99 */
+
 #endif /* ! FLEXINT_H */
 
 #ifdef __cplusplus
@@ -94,11 +95,12 @@ typedef unsigned int flex_uint32_t;
 
 #else  /* ! __cplusplus */
 
-#if __STDC__
+/* C99 requires __STDC__ to be defined as 1. */
+#if defined (__STDC__)
 
 #define YY_USE_CONST
 
-#endif /* __STDC__ */
+#endif /* defined (__STDC__) */
 #endif /* ! __cplusplus */
 
 #ifdef YY_USE_CONST
@@ -191,14 +193,9 @@ extern FILE *yyin, *yyout;
 
 #define unput(c) yyunput( c, (yytext_ptr)  )
 
-/* The following is because we cannot portably get our hands on size_t
- * (without autoconf's help, which isn't available because we want
- * flex-generated scanners to compile on their own).
- */
-
 #ifndef YY_TYPEDEF_YY_SIZE_T
 #define YY_TYPEDEF_YY_SIZE_T
-typedef unsigned int yy_size_t;
+typedef size_t yy_size_t;
 #endif
 
 #ifndef YY_STRUCT_YY_BUFFER_STATE
@@ -349,7 +346,7 @@ void yyfree (void *  );
 
 /* Begin user sect3 */
 
-#define yywrap() 1
+#define yywrap(n) 1
 #define YY_SKIP_YYWRAP
 
 typedef unsigned char YY_CHAR;
@@ -576,7 +573,7 @@ int yy_flex_debug = 0;
 #define YY_MORE_ADJ 0
 #define YY_RESTORE_YY_MORE_OFFSET
 char *yytext;
-#line 1 "dtc-lexer.l"
+#line 1 "arch/powerpc/boot/dtc-src/dtc-lexer.l"
 /*
  * (C) Copyright David Gibson <[EMAIL PROTECTED]>, IBM Corporation.  2005.
  *
@@ -596,11 +593,12 @@ char *yytext;
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
  *   USA
  */
+#define YY_NO_INPUT 1
 
 
 
 
-#line 33 "dtc-lexer.l"
+#line 33 "arch/powerpc/boot/dtc-src/dtc-lexer.l"
 #include "dtc.h"
 #include "srcpos.h"
 #include "dtc-parser.tab.h"
@@ -623,7 +621,7 @@ static int dts_version; /* = 0 */
DPRINT("\n"); \
BEGIN(V1); \
}
-#line 627 "dtc-lexer.lex.c"
+#line 625 "arch/powerpc/boot/dtc-src/dtc-lexer.lex.c"
 
 #define INITIAL 0
 #define INCLUDE 1
@@ -645,6 +643,35 @@ static int dts_version; /* = 0 */
 
 static int yy_init_globals (void );
 
+/* Accessor methods to globals.
+   These are made visible to non-reentrant scanners for convenience. */
+
+int yylex_destroy (void );
+
+int yyget_debug (void );
+
+void yyset_debug (int debug_flag  );
+
+YY_EXTRA_TYPE yyget_extra (void );
+
+void yyset_extra (YY_EXTRA_TYPE user_defined  );
+
+FILE *yyget_in (vo

Re: [RFC: 2.6 patch] ppc: remove APUS support

2007-07-01 Thread Adrian Bunk
On Mon, Jul 02, 2007 at 12:55:36AM +0200, Geert Uytterhoeven wrote:
> On Sun, 1 Jul 2007, Adrian Bunk wrote:
> > Current status of APUS:
> > - arch/powerpc/: a patch to remove it is in powerpc.git
> > - arch/ppc/: marked BROKEN since 2 years
> > 
> > This patch therefore removes the remaining parts of APUS support.
> 
> > --- linux-2.6.22-rc6-mm1/include/asm-m68k/pgtable.h.old 2007-06-30 
> > 01:23:33.0 +0200
> > +++ linux-2.6.22-rc6-mm1/include/asm-m68k/pgtable.h 2007-06-30 
> > 01:23:43.0 +0200
> > @@ -107,8 +107,6 @@ extern void *empty_zero_page;
> >  /* 64-bit machines, beware!  SRB. */
> >  #define SIZEOF_PTR_LOG2   2
> >  
> > -#define mm_end_of_chunk(addr, len) 0
> > -
> >  extern void kernel_set_cachemode(void *addr, unsigned long size, int 
> > cmode);
> >  
> >  /*
> > --- linux-2.6.22-rc6-mm1/drivers/scsi/a2091.c.old   2007-06-30 
> > 01:23:53.0 +0200
> > +++ linux-2.6.22-rc6-mm1/drivers/scsi/a2091.c   2007-06-30 
> > 01:24:08.0 +0200
> > @@ -46,8 +46,7 @@ static int dma_setup(struct scsi_cmnd *c
> >  struct Scsi_Host *instance = cmd->device->host;
> >  
> >  /* don't allow DMA if the physical address is bad */
> > -if (addr & A2091_XFER_MASK ||
> > -   (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> > +if (addr & A2091_XFER_MASK)
> >  {
> > HDATA(instance)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> > & ~0x1ff;
> > --- linux-2.6.22-rc6-mm1/drivers/scsi/a3000.c.old   2007-06-30 
> > 01:24:17.0 +0200
> > +++ linux-2.6.22-rc6-mm1/drivers/scsi/a3000.c   2007-06-30 
> > 01:24:26.0 +0200
> > @@ -54,8 +54,7 @@ static int dma_setup(struct scsi_cmnd *c
> >   * end of a physical memory chunk, then allocate a bounce
> >   * buffer
> >   */
> > -if (addr & A3000_XFER_MASK ||
> > -   (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> > +if (addr & A3000_XFER_MASK)
> >  {
> > HDATA(a3000_host)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> > & ~0x1ff;
> > --- linux-2.6.22-rc6-mm1/drivers/scsi/gvp11.c.old   2007-06-30 
> > 01:24:35.0 +0200
> > +++ linux-2.6.22-rc6-mm1/drivers/scsi/gvp11.c   2007-06-30 
> > 01:24:46.0 +0200
> > @@ -54,8 +54,7 @@ static int dma_setup(struct scsi_cmnd *c
> >  static int scsi_alloc_out_of_range = 0;
> >  
> >  /* use bounce buffer if the physical address is bad */
> > -if (addr & HDATA(cmd->device->host)->dma_xfer_mask ||
> > -   (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> > +if (addr & HDATA(cmd->device->host)->dma_xfer_mask)
> >  {
> > HDATA(cmd->device->host)->dma_bounce_len = (cmd->SCp.this_residual + 
> > 511)
> > & ~0x1ff;
> 
> These seem to be completely unrelated to removing APUS support?

For APUS mm_end_of_chunk() was an actual function, otherwise it was 
always 0.

> Gr{oetje,eeting}s,
> 
>   Geert

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] drivers/video/macmodes.c:mac_find_mode() mustn't be __devinit

2007-07-09 Thread Adrian Bunk
On Tue, Jul 10, 2007 at 01:47:14AM +0200, Mikael Pettersson wrote:
> A vanilla 2.6.22 built for ppc32 and configured with CONFIG_FB_MACMODES=y, 
> CONFIG_HOTPLUG=n,
> and CONFIG_MODULES=y, triggers the following warning from modpost:
> 
> WARNING: drivers/built-in.o(__ksymtab+0x3b0): Section mismatch: reference to 
> .init.text:mac_find_mode (between '__ksymtab_mac_find_mode' and 
> '__ksymtab_mac_map_monitor_sense')
> 
> There's an EXPORT_SYMBOL(mac_find_mode), but mac_find_mode() is __devinit
> and thus __init in this kernel.

So let's fix it.  ;-)

> /Mikael

cu
Adrian


<--  snip  -->


If it's EXPORT_SYMBOL'ed it can't be __devinit.

Reported by Mikael Pettersson.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

@stable:
Fixes a real bug on ppc.

 drivers/video/macmodes.c |5 ++---
 drivers/video/macmodes.h |8 
 2 files changed, 6 insertions(+), 7 deletions(-)

--- linux-2.6.22-rc6-mm1/drivers/video/macmodes.h.old   2007-07-10 
01:55:14.0 +0200
+++ linux-2.6.22-rc6-mm1/drivers/video/macmodes.h   2007-07-10 
01:55:29.0 +0200
@@ -55,10 +55,10 @@
 extern int mac_var_to_vmode(const struct fb_var_screeninfo *var, int *vmode,
int *cmode);
 extern int mac_map_monitor_sense(int sense);
-extern int __devinit mac_find_mode(struct fb_var_screeninfo *var,
-  struct fb_info *info,
-  const char *mode_option,
-  unsigned int default_bpp);
+extern int mac_find_mode(struct fb_var_screeninfo *var,
+struct fb_info *info,
+const char *mode_option,
+unsigned int default_bpp);
 
 
 /*
--- linux-2.6.22-rc6-mm1/drivers/video/macmodes.c.old   2007-07-10 
01:54:36.0 +0200
+++ linux-2.6.22-rc6-mm1/drivers/video/macmodes.c   2007-07-10 
01:55:04.0 +0200
@@ -369,9 +369,8 @@
  *
  */
 
-int __devinit mac_find_mode(struct fb_var_screeninfo *var,
-   struct fb_info *info, const char *mode_option,
-   unsigned int default_bpp)
+int mac_find_mode(struct fb_var_screeninfo *var, struct fb_info *info,
+ const char *mode_option, unsigned int default_bpp)
 {
 const struct fb_videomode *db = NULL;
 unsigned int dbsize = 0;

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] remove awacs dmasound

2007-07-17 Thread Adrian Bunk
On Tue, Jul 17, 2007 at 03:28:31PM +0200, Johannes Berg wrote:
> This patch kills the obsolete awacs dmasound because it is in
> the way of doing power management improvements since it uses
> ancient API.
> 
> Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
> Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Cc: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> This patch contains only the patch for the first two files here, please
> remove the other ones manually:
> 
> git rm -- sound/oss/dmasound/awacs_defs.h
> git rm -- sound/oss/dmasound/dac3550a.c
> git rm -- sound/oss/dmasound/dmasound_awacs.c
> git rm -- sound/oss/dmasound/tas3001c.c
> git rm -- sound/oss/dmasound/tas3001c.h
> git rm -- sound/oss/dmasound/tas3001c_tables.c
> git rm -- sound/oss/dmasound/tas3004.c
> git rm -- sound/oss/dmasound/tas3004.h
> git rm -- sound/oss/dmasound/tas3004_tables.c
> git rm -- sound/oss/dmasound/tas_common.c
> git rm -- sound/oss/dmasound/tas_common.h
> git rm -- sound/oss/dmasound/tas_eq_prefs.h
> git rm -- sound/oss/dmasound/tas_ioctl.h
> git rm -- sound/oss/dmasound/trans_16.c
> 
>  sound/oss/dmasound/Kconfig   |   14 

That's not in your patch, most likely because it's already removed as 
scheduled.

>  sound/oss/dmasound/Makefile  |6 
>  sound/oss/dmasound/awacs_defs.h  |  251 --
>  sound/oss/dmasound/dac3550a.c|  209 --
>  sound/oss/dmasound/dmasound_awacs.c  | 3215 
> ---
>  sound/oss/dmasound/tas3001c.c|  849 -
>  sound/oss/dmasound/tas3001c.h|   64 
>  sound/oss/dmasound/tas3001c_tables.c |  375 
>  sound/oss/dmasound/tas3004.c | 1138 
>  sound/oss/dmasound/tas3004.h |   77 
>  sound/oss/dmasound/tas3004_tables.c  |  301 ---
>  sound/oss/dmasound/tas_common.c  |  214 --
>  sound/oss/dmasound/tas_common.h  |  284 ---
>  sound/oss/dmasound/tas_eq_prefs.h|   24 
>  sound/oss/dmasound/tas_ioctl.h   |   24 
>  sound/oss/dmasound/trans_16.c|  898 -
>  16 files changed, 7943 deletions(-)
>...

The option is already removed from the Kconfig file, and the code 
removal is scheduled for 2.6.24. I'll take care of this (I'll send
a patch through Andrew).

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [patch 1/3] m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible

2007-07-20 Thread Adrian Bunk
On Fri, Jul 20, 2007 at 01:47:36PM -0400, Dmitry Torokhov wrote:
> Hi Geert,
>
> On 7/20/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
>>
>> m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
>>
>> drivers/char/keyboard.c: In function 'kbd_keycode':
>> drivers/char/keyboard.c:1142: error: implicit declaration of function 
>> 'mac_hid_mouse_emulate_buttons'
>>
>> The forward declaration of mac_hid_mouse_emulate_buttons() is not visible 
>> on
>> m68k because it's hidden in the middle of a big #ifdef block.
>>
>> Move it to , correct the type of the second parameter, and
>> include  where needed.
>
> linux/hid.h contains definitions needed for drivers speaking HID
> protocol, I don't think we want to put quirks for legacy keyboard
> driver there. I'd just move the #ifdef within drivers/char/keyboard.c
> for now.
>...

If you only move it you will keep the bug of the wrong second parameter.

But if you move it to any header file gcc is able to figure out such 
errors itself instead of them being nasty runtime errors.

Such prototypes in C files are really bad since (like in this case) they 
prevent the finding of bugs. It doesn't matter which header file you put 
the prototype into (it can even be a new one), but it belongs into a 
header file.

> Dmitry

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [patch 1/3] m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible

2007-07-20 Thread Adrian Bunk
On Fri, Jul 20, 2007 at 02:51:02PM -0400, Dmitry Torokhov wrote:
> On 7/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>> On Fri, Jul 20, 2007 at 01:47:36PM -0400, Dmitry Torokhov wrote:
>> > Hi Geert,
>> >
>> > On 7/20/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>> >> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
>> >>
>> >> m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
>> >>
>> >> drivers/char/keyboard.c: In function 'kbd_keycode':
>> >> drivers/char/keyboard.c:1142: error: implicit declaration of function
>> >> 'mac_hid_mouse_emulate_buttons'
>> >>
>> >> The forward declaration of mac_hid_mouse_emulate_buttons() is not 
>> visible
>> >> on
>> >> m68k because it's hidden in the middle of a big #ifdef block.
>> >>
>> >> Move it to , correct the type of the second parameter, and
>> >> include  where needed.
>> >
>> > linux/hid.h contains definitions needed for drivers speaking HID
>> > protocol, I don't think we want to put quirks for legacy keyboard
>> > driver there. I'd just move the #ifdef within drivers/char/keyboard.c
>> > for now.
>> >...
>>
>> If you only move it you will keep the bug of the wrong second parameter.
>>
>> But if you move it to any header file gcc is able to figure out such
>> errors itself instead of them being nasty runtime errors.
>>
>> Such prototypes in C files are really bad since (like in this case) they
>> prevent the finding of bugs. It doesn't matter which header file you put
>> the prototype into (it can even be a new one), but it belongs into a
>> header file.
>
> I am OK with adding a new header file. I was just saying that placing
> that declaration in linux/hid.h makes about the same sense as putting
> it into linux/scsi.h

scsi.h would also be fine with me.  ;-)

Are you making a patch or should I send one? [1]

> Dmitry

cu
Adrian

[1] for a new header file, not scsi.h

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [2.6 patch] arch/powerpc/Kconfig: fix the EMBEDDED6xx dependencies

2007-07-28 Thread Adrian Bunk
On Mon, Dec 04, 2006 at 02:06:34PM +1100, Paul Mackerras wrote:
> Adrian Bunk writes:
> 
> > This patch changes the EMBEDDED6xx dependencies to the equivalent 
> > dependency that seems to have been intended.
> 
> Nack - CONFIG_EMBEDDED6xx is going away entirely, soon.

Still there - and still with this strange dependency.

> Paul.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] ppc .gitignore update

2007-08-01 Thread Adrian Bunk
arch/ppc/.gitignore shouldn't exclude arch/ppc/boot/include

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- /dev/null   2006-09-19 00:45:31.0 +0200
+++ linux-2.6.23-rc1-mm2/arch/ppc/boot/.gitignore   2007-08-01 
15:18:33.0 +0200
@@ -0,0 +1 @@
+!include

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [2.6 patch] ppc .gitignore update

2007-08-01 Thread Adrian Bunk
On Wed, Aug 01, 2007 at 07:53:28AM -0600, Grant Likely wrote:
> On 8/1/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > arch/ppc/.gitignore shouldn't exclude arch/ppc/boot/include
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > ---
> > --- /dev/null   2006-09-19 00:45:31.0 +0200
> > +++ linux-2.6.23-rc1-mm2/arch/ppc/boot/.gitignore   2007-08-01 
> > 15:18:33.0 +0200
> > @@ -0,0 +1 @@
> > +!include
> 
> I don't think this is the best way to go about it; rather,
> arch/ppc/.gitignore should be made more specific like so:
> 
> diff --git a/arch/ppc/.gitignore b/arch/ppc/.gitignore
> index a1a869c..1e79a0a 100644
> --- a/arch/ppc/.gitignore
> +++ b/arch/ppc/.gitignore
> @@ -1 +1 @@
> -include
> +/include

Thanks, that's obviously better than my patch.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] ppc .gitignore update

2007-08-21 Thread Adrian Bunk
From: Grant Likely <[EMAIL PROTECTED]>

arch/ppc/.gitignore shouldn't exclude arch/ppc/boot/include

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- a/arch/ppc/.gitignore
+++ b/arch/ppc/.gitignore
@@ -1 +1 @@
-include
+/include

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] powerpc: proper defconfig for crosscompiles

2007-09-09 Thread Adrian Bunk
The trick for finding the right defconfig is neat, but you forgot to 
provide an i686_defconfig.  ;-)

More seriously, cross compiling the defconfig is often useful, e.g. for 
testing the compilation of patches that touch multiple architectures, 
and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is 
non-empty.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
0b0e6e0e3a16f48348cb9c40ef1bb55ef42f92eb 
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 2065138..a39bac4 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -35,7 +35,11 @@ endif
 
 export CROSS32CC CROSS32AS CROSS32LD CROSS32AR CROSS32OBJCOPY
 
+ifeq ($(CROSS_COMPILE),)
 KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
+else
+KBUILD_DEFCONFIG := g5_defconfig
+endif
 
 ifeq ($(CONFIG_PPC64),y)
 OLDARCH:= ppc64

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[2.6 patch] the scheduled I2C RTC driver removal

2007-10-31 Thread Adrian Bunk
This patch contains the scheduled removal of legacy I2C RTC drivers with 
replacement drivers.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 Documentation/feature-removal-schedule.txt |7 
 arch/powerpc/platforms/83xx/mpc832x_mds.c  |   24 -
 arch/powerpc/platforms/83xx/mpc834x_mds.c  |   24 -
 arch/powerpc/platforms/83xx/mpc836x_mds.c  |   24 -
 arch/ppc/platforms/83xx/mpc834x_sys.c  |   20 -
 arch/ppc/platforms/85xx/tqm85xx.c  |   21 -
 arch/ppc/platforms/katana.c|   21 -
 drivers/i2c/chips/Kconfig  |   38 -
 drivers/i2c/chips/Makefile |3 
 drivers/i2c/chips/ds1337.c |  410 
 drivers/i2c/chips/ds1374.c |  267 -
 drivers/i2c/chips/m41t00.c |  413 -
 include/linux/m41t00.h |   50 --
 13 files changed, 1322 deletions(-)

bf858b44b3071082be3aaf71e2d46ddb26415247 
diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index 6bb9be5..391f2d1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -275,13 +275,6 @@ Who:  Tejun Heo <[EMAIL PROTECTED]>
 
 ---
 
-What:  Legacy RTC drivers (under drivers/i2c/chips)
-When:  November 2007
-Why:   Obsolete. We have a RTC subsystem with better drivers.
-Who:   Jean Delvare <[EMAIL PROTECTED]>
-

-
 What:  iptables SAME target
 When:  1.1. 2008
 Files: net/ipv4/netfilter/ipt_SAME.c, include/linux/netfilter_ipv4/ipt_SAME.h
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c 
b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 972fa85..66382df 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -145,30 +145,6 @@ static void __init mpc832x_sys_init_IRQ(void)
 #endif /* CONFIG_QUICC_ENGINE */
 }
 
-#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
-extern ulong ds1374_get_rtc_time(void);
-extern int ds1374_set_rtc_time(ulong);
-
-static int __init mpc832x_rtc_hookup(void)
-{
-   struct timespec tv;
-
-   if (!machine_is(mpc832x_mds))
-   return 0;
-
-   ppc_md.get_rtc_time = ds1374_get_rtc_time;
-   ppc_md.set_rtc_time = ds1374_set_rtc_time;
-
-   tv.tv_nsec = 0;
-   tv.tv_sec = (ppc_md.get_rtc_time) ();
-   do_settimeofday(&tv);
-
-   return 0;
-}
-
-late_initcall(mpc832x_rtc_hookup);
-#endif
-
 /*
  * Called very early, MMU is off, device-tree isn't unflattened
  */
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c 
b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 00aed7c..a81bb3c 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -106,30 +106,6 @@ static void __init mpc834x_mds_init_IRQ(void)
ipic_set_default_priority();
 }
 
-#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
-extern ulong ds1374_get_rtc_time(void);
-extern int ds1374_set_rtc_time(ulong);
-
-static int __init mpc834x_rtc_hookup(void)
-{
-   struct timespec tv;
-
-   if (!machine_is(mpc834x_mds))
-   return 0;
-
-   ppc_md.get_rtc_time = ds1374_get_rtc_time;
-   ppc_md.set_rtc_time = ds1374_set_rtc_time;
-
-   tv.tv_nsec = 0;
-   tv.tv_sec = (ppc_md.get_rtc_time) ();
-   do_settimeofday(&tv);
-
-   return 0;
-}
-
-late_initcall(mpc834x_rtc_hookup);
-#endif
-
 /*
  * Called very early, MMU is off, device-tree isn't unflattened
  */
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c 
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0f3855c..8d87b9c 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -152,30 +152,6 @@ static void __init mpc836x_mds_init_IRQ(void)
 #endif /* CONFIG_QUICC_ENGINE */
 }
 
-#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
-extern ulong ds1374_get_rtc_time(void);
-extern int ds1374_set_rtc_time(ulong);
-
-static int __init mpc8360_rtc_hookup(void)
-{
-   struct timespec tv;
-
-   if (!machine_is(mpc836x_mds))
-   return 0;
-
-   ppc_md.get_rtc_time = ds1374_get_rtc_time;
-   ppc_md.set_rtc_time = ds1374_set_rtc_time;
-
-   tv.tv_nsec = 0;
-   tv.tv_sec = (ppc_md.get_rtc_time) ();
-   do_settimeofday(&tv);
-
-   return 0;
-}
-
-late_initcall(mpc8360_rtc_hookup);
-#endif
-
 /*
  * Called very early, MMU is off, device-tree isn't unflattened
  */
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c 
b/arch/ppc/platforms/83xx/mpc834x_sys.c
index b84f8df..cb0a749 100644
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -224,26 +224,6 @@ mpc834x_sys_init_IRQ(void)
ipic_set_default_priority();
 }
 
-#if defined(CONFIG_I2C_MPC) &