Re: Patches added to powerpc.git powerpc-next and master branches
From: Paul Mackerras <[EMAIL PROTECTED]> Date: Mon, 7 Apr 2008 15:52:12 +1000 > The following patches have been added to the master and powerpc-next > branches of the powerpc.git repository. There is a bunch that I > pulled from Josh Boyer's tree plus others that I have committed. Please let me know if you're going to require that I fix a bug that already exists in the LMB code just to get my NUMA node LMB allocation support patch in. Please be straightforward and don't just drop the patch quietly in situations like this, let me know what you want to happen in order to add the change. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Update linker script to properly set physical addresses
Kumar Gala writes: > We can set LOAD_OFFSET and use the AT attribute on sections and the > linker will properly set the physical address of the LOAD program > header for us. Nice... > #define KERNELBASE ASM_CONST(CONFIG_KERNEL_START) > #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET) > +#define LOAD_OFFSET ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START)) I think this should be CONFIG_PAGE_OFFSET - CONFIG_PHYSICAL_START though. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Patches added to powerpc.git powerpc-next and master branches
The following patches have been added to the master and powerpc-next branches of the powerpc.git repository. There is a bunch that I pulled from Josh Boyer's tree plus others that I have committed. Paul. Grant Likely (2): [POWERPC] add target for building .dtb files [POWERPC] bootwrapper: Add a firmware-independent simpleboot target. Ionut Nicu (1): [POWERPC] Fix kernel panic in arch_arm_kprobe Josh Boyer (2): [POWERPC] 4xx: Add Canyonlands and Yosemite to multi-board defconfig [POWERPC] Add of_device_is_available function Nathan Lynch (1): [POWERPC] Convert pci and eeh code to of_device_is_available Robert P. J. Day (1): [POWERPC] Use __SPIN_LOCK_UNLOCKED macro in mpc52xx_set_psc_clkdiv Roel Kluin (1): [POWERPC] Replace logical-AND by bit-AND in pci_process_ISA_OF_ranges() Stefan Roese (5): [POWERPC] 4xx: Only reset PCIe PHY on 405EX systems when no link is detected [POWERPC] 4xx: Fix PESDRn_UTLSET1 register setup on 460EX/GT [POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c [POWERPC] 4xx: Some EMAC related changes in Canyonlands & Glacier dts files [POWERPC] 4xx: Change dts files to support jumbo frames Stephen Neuendorffer (1): [POWERPC] of_serial: Fix possible null dereference. Stephen Rothwell (2): [POWERPC] htab_remove_mapping is only used by MEMORY_HOTPLUG [POWERPC] Remove CONFIG_PCI_LEGACY from some configs Steven Rostedt (1): [POWERPC] Add hand-coded assembly strcmp Timur Tabi (1): [POWERPC] Enable CONFIG_FORCE_MAX_ZONEORDER for all PowerPC, and make selectable Valentine Barshak (1): [POWERPC] 4xx: Use machine_device_initcall() for warp_nand ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Add irqtrace support for 32-bit powerpc
I think I found one: .../... > - mr r6,r3 > rlwinm r12,r1,0,0,(31-THREAD_SHIFT)/* current_thread_info() */ > /* disable interrupts so current_thread_info()->flags can't change */ > LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */ > SYNC > MTMSRD(r10) > +#ifdef CONFIG_TRACE_IRQFLAGS > + stwur1,-16(r1) > + stw r3,12(r1) > + bl trace_hardirqs_off > + lwz r3,12(r1) > + addir1,r1,16 > + LOAD_MSR_KERNEL(r10,MSR_KERNEL) > +#endif Here, r12 is clobbered, though it's used two lines later: > + mr r6,r3 > lwz r9,TI_FLAGS(r12) Here. You can probably just move the rlwinm down as you moved the mr. Note that I've been wondering wether we should attempt to trace all those IRQ state change internally to the exception code. I've looked at not doing it, which simplifies things a bit. Unfortunately, that will make us occasionally trace redundant enable/disable (which isn't a big problem per-se, just counters). The idea is that I only kept the trace of disable in transfer_to_handler and I modified the enable tracing in restore: moved it lower down, and made it test for _MSR(r1):MSR_EE. I added a trace_irq_off just before the preempt_schedule_irq() as well. Anyway, let me know what you think. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc - Use KBUILD_CFLAGS and similar
Bastian Blank writes: > The attached patch changes the powerpc main Makefile from using the override > make directive to KBUILD_CFLAGS and similar. I get build failures on all 64-bit targets with this patch. It ends up using both -m32 and -m64 on the gcc command line for assembling .S files. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
a question about use dtb to bootting linux kernel on MPC83xx platform
I am Linux software engineer. These days I was debugging a MPC8313 system. In the debugging process, some source code in the kernel makes me puzzled. So I have find your email address in the source code. I think you can give me some advises to solve the problem. My version is linux-2.6.23.9 and I use the device tree(dtb) to booting the kernel. In my bootloader I use the following code to jump to the kernel. (*image)((bd_t *)dtb_entry, (unsigned int)image, 0, 0, 0); The dtb_entry is the address of dtb file which in the SDRAM, the image is the kernel entry point. I flashed some LEDs in my board. So I can make sure the program run to the machine_init() which is defined in the /arch/powerpc/kernel/setup_32.c In order to trace the problem I search the source code. I can find that these information is printed by the start function which is defined in the /arch/powerpc/boot/main.c. Fourth more I have found that the kernel call the platform_init which is defined in the /arch/powerpc/boot/cuboot-83xx.c. looking the file head I have known you are the author for this file. Could you told me how the kernel call the platform_init function and I hope you can show me the booting process of the MPC83xx linux or you could give me some document about it. - 雅虎邮箱，您的终生邮箱！___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
> You have FIX_PCIE_MCFG in there too (keyed off CONFIG_PCI_MMCONFIG > which we don't have and don't want to have). If you need to map in > PCIe config space, what's wrong with just using ioremap? Why do you > need to have a fixed virtual address for it? Well, that was the whole point for doing the fixmap stuff actually, to be able to have a non-HIGHMEM version of a quick kmap_atomic for ... PCIe config space :-) On some PCIe host brigdes like the ones used on 4xx or FSL chips, the config space is physically mapped as a large linear space, too large to ioremap permanently, and we can't ioremap from within the low level config ops. So the idea is to use a fixmap as a "window" to the config space, possibly per-cpu. Ultimately, we should even be able to directly insert TLB entries in kmap_atomic/fixmap to make it even faster. > More generally, I think we need to take an overall look at what things > we are using fixed virtual addresses for, and why they need to be > fixed. If there are indeed several such things then we can introduce > the fixmap stuff. The virtual address doesn't _need_ to be fixed in our case. It's more like x86 builds kmap on top of fixmap and we were thinking about doing the same, having it fixed makes it slightly easier to whack things but I agree it's not necessarily the best option. We could instead have something allocated a chunk of virtual space at boot and provide a quick map/unmap. But by using fixmap, we can use common code with kmap_atomic quickly and easily. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
Kumar Gala writes: > Wanted to get any feedback on this initial port of the fixmap support over > from x86. There are a few TODOs: I have no objection in principle, but your patch below imports a few things that aren't (and won't be) needed on powerpc AFAICS -- for example, we don't need FIX_VDSO, since our VDSO is mapped into user space at the 1MB point (by default). You have FIX_PCIE_MCFG in there too (keyed off CONFIG_PCI_MMCONFIG which we don't have and don't want to have). If you need to map in PCIe config space, what's wrong with just using ioremap? Why do you need to have a fixed virtual address for it? More generally, I think we need to take an overall look at what things we are using fixed virtual addresses for, and why they need to be fixed. If there are indeed several such things then we can introduce the fixmap stuff. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] make help: Show defconfig subdirs
PowerPC will start moving board defconfigs into subarch-specific subdirs soon. "make help" currently does not look in subdirs to find the defconfigs to show. This is partially a good thing, since there are way too many defconfigs for one list. This patch makes the main "make help" display something like help-40x - Show 40x-specific targets help-44x - Show 44x-specific targets help-boards - Show all of the above and wires up stuff so those new help-* commands actually work. Cc: Josh Boyer <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]> --- Makefile | 21 + 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index fec2a12..05d9fda 100644 --- a/Makefile +++ b/Makefile @@ -1172,6 +1172,8 @@ rpm: include/config/kernel.release FORCE boards := $(wildcard $(srctree)/arch/$(ARCH)/configs/*_defconfig) boards := $(notdir $(boards)) +board-dirs := $(dir $(wildcard $(srctree)/arch/$(ARCH)/configs/*/*_defconfig)) +board-dirs := $(sort $(notdir $(board-dirs:/=))) help: @echo 'Cleaning targets:' @@ -1225,6 +1227,11 @@ help: $(foreach b, $(boards), \ printf " %-24s - Build for %s\\n" $(b) $(subst _defconfig,,$(b));) \ echo '') + @$(if $(board-dirs), \ + $(foreach b, $(board-dirs), \ + printf " %-16s - Show %s-specific targets\\n" help-$(b) $(b);) \ + printf " %-16s - Show all of the above\\n" help-boards; \ + echo '') @echo ' make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build' @echo ' make V=2 [targets] 2 => give reason for rebuild of target' @@ -1236,6 +1243,20 @@ help: @echo 'For further info see the ./README file' +help-board-dirs := $(addprefix help-,$(board-dirs)) + +help-boards: $(help-board-dirs) + +boards-per-dir = $(notdir $(wildcard $(srctree)/arch/$(ARCH)/configs/$*/*_defconfig)) + +$(help-board-dirs): help-%: + @echo 'Architecture specific targets ($(ARCH) $*):' + @$(if $(boards-per-dir), \ + $(foreach b, $(boards-per-dir), \ + printf " %-24s - Build for %s\\n" $*/$(b) $(subst _defconfig,,$(b));) \ + echo '') + + # Documentation targets # --- %docs: scripts_basic FORCE -- 1.5.3.4.208.g805a ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC] tqm8560.dts: add local bus devices
Wolfgang Grandegger wrote:
> Segher Boessenkool wrote:
>>> +[EMAIL PROTECTED] {
>>> +label = "fs";
>>> +reg = <0x0030 0x07c0>;
>>> +};
>>> +[EMAIL PROTECTED] {
>>> +label = "firmware";
>>> +reg = <0x0770 0x0010>;
>> These two overlap; should the latter be @7f0?
>
> Yes, of course.
>
>>> +[EMAIL PROTECTED],0 {
>>> +device_type = "can";
>> No device_type please.
>
> OK, but then I better use a more descriptive name for the compatible
> property, e.g.:
>
> compatible = "can-i82527"; // Intel 82527 or Bosch CC770
>
>>> +[EMAIL PROTECTED],0 {
>>> +#address-cells = <1>;
>>> +#size-cells = <1>;
>>> +compatible = "fsl,mpc8560-fcm-nand",
>>> + "fsl,elbc-fcm-nand";
>>> +reg = <0x3 0x0 0x8000>;
>>> +
>>> +[EMAIL PROTECTED] {
>>> +label = "kernel";
>>> +reg = <0x00 0x030>;
>>> +};
>>> +[EMAIL PROTECTED] {
>>> +label = "fs";
>>> +reg = <0x30 0x7d0>;
>>> +};
>>> +};
>>> +};
>> There should be a node that describes the nand chip between the nand
>> controller node and the partition nodes.
>
> I took the mpc8378_*.dts files of 2.6.25-rc8 as example and there is no
> such node. Could you point me please to a more appropriate example.
In the meantime I realized, that the upcoming FSL UPM driver seems to be
appropriate for that board:
http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052890.html
What is the status of this driver? Are there already some boards using
it (including DTS file)?
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC] tqm8560.dts: add local bus devices
Segher Boessenkool wrote:
>> +[EMAIL PROTECTED] {
>> +label = "fs";
>> +reg = <0x0030 0x07c0>;
>> +};
>> +[EMAIL PROTECTED] {
>> +label = "firmware";
>> +reg = <0x0770 0x0010>;
>
> These two overlap; should the latter be @7f0?
Yes, of course.
>
>> +[EMAIL PROTECTED],0 {
>> +device_type = "can";
>
> No device_type please.
OK, but then I better use a more descriptive name for the compatible
property, e.g.:
compatible = "can-i82527"; // Intel 82527 or Bosch CC770
>
>> +[EMAIL PROTECTED],0 {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +compatible = "fsl,mpc8560-fcm-nand",
>> + "fsl,elbc-fcm-nand";
>> +reg = <0x3 0x0 0x8000>;
>> +
>> +[EMAIL PROTECTED] {
>> +label = "kernel";
>> +reg = <0x00 0x030>;
>> +};
>> +[EMAIL PROTECTED] {
>> +label = "fs";
>> +reg = <0x30 0x7d0>;
>> +};
>> +};
>> +};
>
> There should be a node that describes the nand chip between the nand
> controller node and the partition nodes.
I took the mpc8378_*.dts files of 2.6.25-rc8 as example and there is no
such node. Could you point me please to a more appropriate example.
>
>> Do these entries make sense?
>
> Looks good otherwise :-)
Thanks.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx defconfig reorg
Unless someone screams loudly and has reasons why this shouldn't go in, These configs won't show up for "make help" anymore, which of course is nice because that list was too long, but we need a way to get that back since it was useful. I'll see what I can do. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
4xx defconfig reorg
Hi All,
Unless someone screams loudly and has reasons why this shouldn't go in,
the following commit should hit the 4xx next branch in the next day or
so.
josh
commit eaf997b847be3c351eb9d0107e0562035dc58095
Author: Josh Boyer <[EMAIL PROTECTED]>
Date: Sun Apr 6 08:01:21 2008 -0500
[POWERPC] 4xx: Reorganize 4xx defconfigs
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs directory
Move the 4xx board specific defconfigs to individual directories under
arch/powerpc/configs.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
arch/powerpc/configs/{ => 40x}/ep405_defconfig |0
arch/powerpc/configs/{ => 40x}/kilauea_defconfig |0
arch/powerpc/configs/{ => 40x}/makalu_defconfig|0
arch/powerpc/configs/{ => 40x}/walnut_defconfig|0
arch/powerpc/configs/{ => 44x}/bamboo_defconfig|0
.../configs/{ => 44x}/canyonlands_defconfig|0
arch/powerpc/configs/{ => 44x}/ebony_defconfig |0
arch/powerpc/configs/{ => 44x}/katmai_defconfig|0
arch/powerpc/configs/{ => 44x}/rainier_defconfig |0
arch/powerpc/configs/{ => 44x}/sequoia_defconfig |0
arch/powerpc/configs/{ => 44x}/taishan_defconfig |0
arch/powerpc/configs/{ => 44x}/warp_defconfig |0
12 files changed, 0 insertions(+), 0 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull 'for-2.6.26' branch of 4xx tree
Hi Paul, Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.26 to pick up a handful of additional commits for 2.6.26. Most of these are bug fixes. Grant adds a helpful make target for building dtb files, which is quite useful for some newer 4xx boards as well as other platforms in general. josh Grant Likely (2): [POWERPC] add target for building .dtb files [POWERPC] bootwrapper: Add a firmware-independent simpleboot target. Josh Boyer (1): [POWERPC] 4xx: Add Canyonlands and Yosemite to multi-board defconfig Stefan Roese (5): [POWERPC] 4xx: Only reset PCIe PHY on 405EX systems when no link is detect [POWERPC] 4xx: Fix PESDRn_UTLSET1 register setup on 460EX/GT [POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c [POWERPC] 4xx: Some EMAC related changes in Canyonlands & Glacier dts file [POWERPC] 4xx: Change dts files to support jumbo frames Stephen Neuendorffer (1): [POWERPC] of_serial: Fix possible null dereference. Valentine Barshak (1): [POWERPC] 4xx: Use machine_device_initcall() for warp_nand arch/powerpc/Makefile|2 +- arch/powerpc/boot/Makefile | 36 + arch/powerpc/boot/dts/canyonlands.dts| 19 +-- arch/powerpc/boot/dts/glacier.dts|5 ++- arch/powerpc/boot/dts/haleakala.dts |2 +- arch/powerpc/boot/dts/katmai.dts |2 +- arch/powerpc/boot/dts/kilauea.dts|4 +- arch/powerpc/boot/dts/makalu.dts |4 +- arch/powerpc/boot/dts/rainier.dts|4 +- arch/powerpc/boot/dts/sequoia.dts|4 +- arch/powerpc/boot/dts/taishan.dts|4 +- arch/powerpc/boot/simpleboot.c | 84 ++ arch/powerpc/boot/virtex405-head.S | 30 +++ arch/powerpc/boot/wrapper|4 ++ arch/powerpc/configs/ppc44x_defconfig| 14 -- arch/powerpc/platforms/40x/ep405.c |2 + arch/powerpc/platforms/40x/kilauea.c |4 +- arch/powerpc/platforms/40x/makalu.c |2 + arch/powerpc/platforms/40x/virtex.c |2 + arch/powerpc/platforms/40x/walnut.c |4 +- arch/powerpc/platforms/44x/44x.h |1 - arch/powerpc/platforms/44x/Kconfig |1 - arch/powerpc/platforms/44x/bamboo.c | 15 +++--- arch/powerpc/platforms/44x/canyonlands.c |5 +- arch/powerpc/platforms/44x/ebony.c |5 +- arch/powerpc/platforms/44x/katmai.c |5 +- arch/powerpc/platforms/44x/misc_44x.S| 11 arch/powerpc/platforms/44x/rainier.c |4 +- arch/powerpc/platforms/44x/sequoia.c |4 +- arch/powerpc/platforms/44x/taishan.c |5 +- arch/powerpc/platforms/44x/warp-nand.c |3 +- arch/powerpc/platforms/44x/warp.c|6 +-- arch/powerpc/platforms/Kconfig.cputype |2 + arch/powerpc/sysdev/ppc4xx_pci.c | 18 ++- arch/powerpc/sysdev/ppc4xx_soc.c | 11 drivers/serial/of_serial.c |4 +- include/asm-powerpc/ppc4xx.h | 18 ++ 37 files changed, 257 insertions(+), 93 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH RFC] tqm8560.dts: add local bus devices
Hello,
this is my first attempt to add local bus nodes to the DTS file
of the TQM8560 for the following devices:
CS1: 128 MB NOR FLASH at 0xf800
CS2: Two Intel 82527 CAN controller at 0xe300
CS3: 128 MB NAND FLASH at 0xe301
Index: linux-2.6-denx/arch/powerpc/boot/dts/tqm8560.dts
===
--- linux-2.6-denx.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6-denx/arch/powerpc/boot/dts/tqm8560.dts
@@ -221,6 +221,77 @@
};
};
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8560-localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0xe0005000 0x100>; // BRx, ORx, etc.
+
+ ranges = <
+ 0x0 0x0 0xfc00 0x0400 // NOR FLASH bank 1
+ 0x1 0x0 0xf800 0x0800 // NOR FLASH bank 0
+ 0x2 0x0 0xe300 0x8000 // CAN (2 x i82527)
+ 0x3 0x0 0xe301 0x8000 // NAND FLASH
+ >;
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x1 0x0 0x800>;
+ bank-width = <4>;
+ device-width = <1>;
+
+ [EMAIL PROTECTED] {
+label = "kernel";
+reg = <0x 0x0030>;
+};
+[EMAIL PROTECTED] {
+label = "fs";
+reg = <0x0030 0x07c0>;
+};
+[EMAIL PROTECTED] {
+label = "firmware";
+reg = <0x0770 0x0010>;
+read-only;
+};
+
+ };
+
+ [EMAIL PROTECTED],0 {
+ device_type = "can";
+ compatible = "i82527"; // Intel 82527 or Bosch CC770
+ reg = <0x2 0x0 0x100>;
+ interrupts = <0x9 0x2>;
+ interrupt-parent = <&mpic>;
+ }
+
+ [EMAIL PROTECTED],100 {
+ device_type = "can";
+ compatible = "i82527"; // Intel 82527 or Bosch CC770
+ reg = <0x2 0x100 0x100>;
+ interrupts = <0x9 0x2>;
+ interrupt-parent = <&mpic>;
+ }
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8560-fcm-nand",
+"fsl,elbc-fcm-nand";
+ reg = <0x3 0x0 0x8000>;
+
+ [EMAIL PROTECTED] {
+label = "kernel";
+ reg = <0x00 0x030>;
+ };
+ [EMAIL PROTECTED] {
+label = "fs";
+ reg = <0x30 0x7d0>;
+ };
+ };
+ };
+
pci0: [EMAIL PROTECTED] {
cell-index = <0>;
#interrupt-cells = <1>;
Do these entries make sense?
TIA.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
