Cc: Stephen Neuendorffer <stephen.neuendorffer@...>, John Williams <john.williams@...>, <jwboyer@...>, <benh@...>, John Linn <John.Linn@...>, <git-dev@...>, Grant Likely <grant.likely@...>, <git@...>, <microblaze-uclinux@...>, <linux-kernel@...>, <paulus@...>
I think the easiest way is to include those patches in your series
and ask for an Acked-by from paulus.
The order of the patches should be:
1. fix up any coding style issues you have found
2. move the files without further changes to drivers/of
3. add whatever code you need to make it work on both architectures
Be careful not to break sparc in the process, as they are already
sharing substantial parts of the OF code with powerpc.
2.6.26 will have a common implementation in kernel/semaphore.c.
All you need is a one-line asm/semaphore.h to #include linux/semaphore.h.
From what I can see, your consistent.c code is just wrong and uses an
obsolete interface. Since you currently don't use it, I'd suggest to
drop it from your current tree for the merge. We can discuss it again
when you add MMU support.
LMB doesn't have much to do with an MMU, but more with the way certain IBM
machines extend the OF interfaces.
I'd recommend splitting prom.c into code that can be shared between powerpc
and microblaze and architecture specific code. Anything that deals with
LMB should go into powerpc, and you can simply use the alloc_bootmem
mechanism for your architecture.
That was not my point, although it would be a good idea as well.
The important bit is that your version of these files don't contain
any architecture specific code (no guarantees, my review may have
been sloppy). Even if every architecture so far has a different
version of them, but any of them would be ok for you, please throw
one of them into asm-generic and start using it.
All future architectures can simply use that copy as well, as long as
they have the same constraints (e.g. you atomic.h assumes there are
no atomic operations other than spinlock, iirc).
If you want to be really nice, look for the most common implementation
across the existing architectures and put that into asm-generic.
Also, please cc the linux-arch mailing list on any patch that adds
a file in asm-generic.
Sorry, my comment was impossible to understand ;-).
What I meant is that a new architecture should not define these macros, because
only architectures with a need for backwards compatibility want the syscalls
they enable. If you find an exception and think you need one of them, please
tell us.
Arnd <><
--
