Re: AVR32 architecture patch against Linux 2.6.18-rc1 available
From: Andrew Morton
Date: Mon Jul 10 2006 - 05:30:32 EST
On Mon, 10 Jul 2006 11:03:25 +0200
Haavard Skinnemoen <hskinnemoen@xxxxxxxxx> wrote:
> On Thu, 6 Jul 2006 03:14:16 -0700
> Andrew Morton <akpm@xxxxxxxx> wrote:
>
> > OK, thanks. Send me the whole lot when you think it's ready and
> > we'll get it into the pipeline. Not for 2.6.18 though - we need to
> > give people time to look through it and send you nastygrams ;)
>
> I've put up an updated patch at
> http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-3.patch
Thanks, I'll grab it.
> which fixes most of the issues people have pointed out. Thanks a lot
> to everyone for taking the time to look through this.
>
> I've appended the changelog below, but first I'll mention the things I
> didn't fix and why:
>
> There are three libgcc functions left, which handle the three possible
> variants of 64-bit shift. There's no easy way to eliminate these, but
> maybe our gcc maintainer can get gcc to emit the instructions inline
> instead. However, these functions are actually specified by the AVR32
> ABI, so they should be the same no matter which compiler you use.
Sure, if the compier doesn't inline 64-bit shift then you'll certainly need
the library function.
> The clk API is still exported as non-GPL. I don't feel very strongly
> one way or another, but since Russell is keeping them non-GPL on ARM,
> it makes most sense to keep them non-GPL on AVR32 as well.
OK.
> I've kept the volatiles in the arguments to the bitops functions as
> they are. I'm not sure if they're really needed, but as I understood
> from reading the recent thread about spinlocks, this doesn't fall in
> the category of "obviously bad" usage of volatile.
Nope. i386 does it too, as does include/asm-generic/bitops/atomic.h
(wrongly, I suspect. The volatile gets typecast away.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/