Patches for 2.6.15

If anyone has patches for arch/ppc{,64} and include/asm-ppc{,64} that they would like to see go upstream now that 2.6.14 is out, other than patches that are already in the powerpc-merge tree, please let me know. I am planning to ask Linus to pull the powerpc-merge tree shortly, and that will probably break your patches.

I think the merge tree is looking pretty good, although the merge is by no means complete yet. The powermac, pseries and iseries platforms seem to be working fine with ARCH=powerpc. 32-bit chrp is mostly there but needs a bit more work.

If possible, I'd like to get to the point where we can remove arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.

Paul.

I haven't been following this seriously, so forgive me if this has already been asked.

Under the unified architecture, what is the machine type in the "uname" outout?

Chris

I don't think that should change in any way.

Andreas.

Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

When building the merge tree for a 32-bit cpu uname spits out:

Linux fred 2.6.14-rc5-g278144ed #9 Thu Oct 27 09:20:01 CDT 2005 ppc unknown

- kumar

"ppc" on 32-bit machines, "ppc64" on 64-bit machines, same as before.

The intention is that the merge doesn't change the user/kernel ABI in any way. :)

Paul.

Ok, we have a set of 4xx patches that I plan to send to Andrew. They are some existing 4xx SoC/board updates as well as a new SoC/board. They are obviously mostly confined to the 4xx code paths but there's likely conflicts in changes to Makefiles, etc.

Would you prefer these going upstream before or after the powerpc-merge pull?

-Matt

Can we ask Andrew to flush any ppc patches in -mm to linus before we have Linus pull the merge tree.

The following are patches that should probably go to linus before the merge tree that exist in 2.6.14-rc5-mm1:

(I may have missed some, but these where the obvious ones)

+ppc32-85xx-phy-platform-update.patch
+ppc32-ppc_sys-fixes-for-8xx-and-82xx.patch

ppc32 updates

+various-powerpc-32bit-ppc64-build-fixes.patch +ppc64-reenable-make-install-with-defconfig.patch +ppc64-change-name-of-target-file-during-make-install.patch +ppc64-remove-duplicate-local-variable-in-set_preferred_console.patch

- kumar

Well I'd prefer that ;)

Paul?

My concern is that if we do that we may end up losing some of the changes from Andrew's patches when the merge goes in and/or creating a nasty, difficult merge.

Probably the best thing is if I take the patches and apply them on top of the merge tree (hacking them as necessary) and then get Linus to pull.

Andrew, will I just grab the ones you listed from the latest -mm, or will you send them to me?

Paul.

I'll mail them all over.

Got them, thanks. I'm going to drop 06, 12, 13, 18, 19, 20, 21, and 37 for now. The rest I have committed to the powerpc-merge tree.

The reasons for dropping them are:

06 - need to discuss the specifics of the patch with Marcelo 12, 13 - going through netdev tree
18 - it seems there is still ongoing discussion about whether this is
the best approach
19, 20, 21 - BenH's SMU stuff, which he told me he would rebase on
top of the merge tree
37 - I want the patch done a little differently

Regards,
Paul.

OK, well I'll probably drop all those patches as well - hopefully all the originators know what's going on and nothing will fall through a crack.

Did you send them yet? Linus has pulled the powerpc-merge tree, as I'm sure you've noticed.

Paul.

Yes I did. I saw the merge go into mainline and rebased what was necessary off of that. Andrew now has them queued up for Linus so we are set. BTW, we're starting to look at merging 4xx to arch/powerpc/ now.

-Matt

Can you merge this in:

http://patchwork.ozlabs.org/linuxppc/patch?id=2931

- kumar

I can't find any use of mpc85xx_show_cpuinfo. Is there something subtle here?

Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/

No, you are correct. This was a bogus decleration before. I will kill it and resend the patch.

- kumar

Having the same extern declaration in several C files raises a red flag. Could we have that in a suitable header file instead please?

Paul.

Out of my spufs patches, I'd like to have at least the reservation for my two system call numbers in there so we don't get any conflicts on that front. The patch follows in another mail.

=46rom my point of view, the spufs itself could go in at this point, but I have the feeling that the real concerns from other people will come up at the moment that I post them for inclusion.=20

Andrew, are you ok with including spufs in -mm when the merge tree is upstream?

Ok, I'll do a new patch to move over the BPA files then to get my stuff out of the way ASAP.

	Arnd <><

This creates two powerpc specific dummy system calls that will later be used on the Cell platform to manage SPUs.

Reserve the system call numbers now so we don't accidentally use the same numbers for different system calls.

---
Please apply to merge tree

@@ -90,3 +90,5 @@
 cond_syscall(sys32_ipc);
 cond_syscall(sys32_sysctl);
 cond_syscall(ppc_rtas);
+cond_syscall(sys_spu_run);
+cond_syscall(sys_spu_create);

@@ -319,3 +319,5 @@
 SYSCALL(inotify_init)
 SYSCALL(inotify_add_watch)
 SYSCALL(inotify_rm_watch)
+SYSCALL(spu_run)
+SYSCALL(spu_create)

@@ -297,7 +297,9 @@
 #define __NR_inotify_add_watch	276
 #define __NR_inotify_rm_watch	277
 
-#define __NR_syscalls		278
+#define __NR_spu_run		278
+#define __NR_spu_create		279
+#define __NR_syscalls		280
 
 #ifdef __KERNEL__
 #define __NR__exit __NR_exit

Probably. I haven't paid much attention to them thus far, sorry.