Hi all,
I have created today's linux-next tree at

git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git

(tar balls at

http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).
You can see which trees have been included by looking in the Next/Trees

file in the source.  There are also quilt-import.log and merge.log files

in the Next directory.  Between each merge, the tree was built with

a ppc64_defconfig for powerpc and an allmodconfig for x86_64.
There were a few merge conflicts (fairly trivial) and several build

failures that have been notified.
We are up to 49 trees, more are welcome (even if they are currently

empty).  Thanks to those who have contributed, and to those who haven't,

please do.
In particular, I have very few of the architecture trees ....
Status of my local build tests is at

http://kisskb.ellerman.id.au/linux-next.  If maintainers want to give

advice about cross compilers/configs that work, we are always open to add

more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests

at http://l4x.org/k/ and the guys at http://test.kernel.org/.
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

Can you add my "linux drivers" tree at:

	http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-0...

to the mix as well?  It should come after my 3 other trees.  It contains

new drivers that are being worked on by the linux driver project group.
The code there isn't the best, but it is actively being worked on to

clean up and get ready for merging, and should always build properly.

If not, I'd like to know about it, as it passes my build tests on i386

and x86-64.
thanks,
greg k-h

--

Hi Greg,
Are these drivers targetted at 2.6.26?  If so, I will add this at the end

(and drop it temporarily when it breaks).  If not, then it should wait
That is promising.
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/

Some are targetted at .26, depending on how quickly the cleanup and

testing goes.  Others for probably kernels beyond that.
I have no problem if you place it at the end, it will let me know about

api changes earlier.
thanks,
greg k-h

--

Hi Greg,
I have added the tree to the end starting today (assuming I get linux-next

built today).  I have called it "ldp".  If you want a different name,

just shout.
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/

On Thu, 27 Mar 2008 18:33:57 +1100
AVR32 allnoconfig found a bug, which I've fixed. Could you try enabling

it again?
Haavard

--

Hi Haavard,
On Thu, 27 Mar 2008 10:42:24 +0100 Haavard Skinnemoen <haavard.skinnemoen@a=
Done.
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/

BTW:
According to Jan's page, there's still a build error with the defconfig:
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
--

On Thu, 27 Mar 2008 12:47:45 +0200
Hmm...that must be a pretty ancient toolchain. In any case, the patch

below should fix it. The commit being reverted is not in mainline, so

I'll probably just drop both of them next time I rebase.
FWIW, a more recent toolchain is available here:
http://avr32linux.org/twiki/bin/view/Main/BinutilsPatches

http://avr32linux.org/twiki/bin/view/Main/GccPatches
Haavard
From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>

Date: Thu, 27 Mar 2008 12:23:07 +0100

Subject: [PATCH] Revert "avr32: Use better asm constraint in prefetch()"
This reverts commit e153fa1406b68460e0a8e498a2b83d50584cc40a.
This commit caused build breakage with some old 4.0.2-based gcc.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>

---

 include/asm-avr32/processor.h |    2 +-

 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-avr32/processor.h b/include/asm-avr32/processor.h

index 2abd3de..49a88f5 100644

--- a/include/asm-avr32/processor.h

+++ b/include/asm-avr32/processor.h

@@ -169,7 +169,7 @@ extern void show_stack_log_lvl(struct task_struct *tsk, unsigned long sp,

 static inline void prefetch(const void *x)

 {

 	const char *c = x;

-	asm volatile("pref %0" : : "RKs16"(*c));

+	asm volatile("pref %0" : : "r"(c));

 }

 #define PREFETCH_STRIDE	L1_CACHE_BYTES
--

1.5.4.3
--

The oldest compiler the kernel currently supports is gcc 3.2, and

whenever it's reasonably possible (noone expects you to backport avr32

support to gcc 3.2) the aim is to support all compilers back to gcc 
cu

Adrian
BTW: What's the status of avr32 support in upstream binutils and gcc?
-- 
       "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
--

That's the toolchain from back when avr32 was first integrated in the

kernel. So it may be outdated, but I didn't read any statement on

the contrary. I tend to keep the toolchains stable as long as
So how can I get notified if I need a more recent toolchain?

IMHO every architecture should have a file somewhere (in

the kernel tree) where the required toolchain versions are

listed and required patches are linked. That would make it

such discussions unnecessary.
Jan
--

Jan Dittmer

--

On Thu, 27 Mar 2008 13:54:23 +0100
Right...and like I said later in this thread, we should really try to

keep those toolchains working for as long as possible. So don't worry
Good question. The problem is that there's really no way to tell until

someone actually runs into a problem, and when that happens, we might

as well try to fix it in the kernel.
There's no avr32 toolchain list (maybe we should add one), but the

buildroot@avr32linux.org list is probably a good bet if you want to

keep an eye on things.
Oh, and thanks a lot for doing these tests!
Haavard

--

Even more important, all architectures should get all their

required patches into upstream binutils and gcc.
There might be some time at the beginning of a port until this state is

reached, but for the majority of our architectures plain upstream

binutils 2.18.50.0.5 and gcc 4.3.0 already give a successful kernel

build.
And I'm regularly poking arch maintainers to get their binutils and gcc

patches upstream.
Regarding "required toolchain versions" - I'm not even sure anyone 
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
--

On Thu, 27 Mar 2008 13:54:59 +0200
We do have some gcc 3.x patches lying around somewhere, but I don't

think that's something we want to inflict on others ;-)
The first toolchain we ever released to the outside was based on gcc

4.0.2, so it is "ancient" in the sense that it has lots of

avr32-specific bugs that later toolchains don't have. I agree that we
Still stuck in legal hell, I think.
Haavard

--

Hi,
The next-20080327 kernel build fails on powerpc with build error
ERROR: ".pnp_get_resource" [drivers/parport/parport_pc.ko] undefined!

ERROR: ".pnp_get_resource" [drivers/net/irda/smsc-ircc2.ko] undefined!

ERROR: ".pnp_get_resource" [drivers/net/irda/nsc-ircc.ko] undefined!
--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.