* Re: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Michael Ellerman @ 2007-12-14 9:40 UTC (permalink / raw)
To: Kumar Gala
Cc: Olof Johansson, linuxppc-dev list, Phillips Kim, Jin Zhengxiong,
Li Tony
In-Reply-To: <90B908AC-E879-4046-AAFC-FE79EB78A932@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
On Fri, 2007-12-14 at 02:52 -0600, Kumar Gala wrote:
> On Dec 14, 2007, at 2:47 AM, Li Tony wrote:
>
> >
> > Hi,
> >
> > I think it is possible to make common code to support both IPIC and
> > MPIC.
> > Currently, the MPIC has already implemented MSI which is different
> > from IPIC and embedded into the mpic code body.
> > If want to unifiy MSI code, we need to remove the current MPIC MSI
> > implementation.
>
> The MPIC is going to have to support several MSI styles (IBM/U3,
> PaSemi, and FSL) since we all seem to handle it differently.
I haven't really looked at the similarities or differences, but I think
Kumar is right, MPIC is going to have to (and already does) support
different styles.
If there's some commonality that can be shared I'm all ears, patches
welcome ;)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Jin Zhengxiong @ 2007-12-14 9:39 UTC (permalink / raw)
To: Kumar Gala, Li Tony; +Cc: linuxppc-dev list, Phillips Kim, Olof Johansson
In-Reply-To: <90B908AC-E879-4046-AAFC-FE79EB78A932@kernel.crashing.org>
=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Friday, December 14, 2007 4:52 PM
> To: Li Tony
> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev list;=20
> Jin Zhengxiong; Olof Johansson
> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support
>=20
>=20
> On Dec 14, 2007, at 2:47 AM, Li Tony wrote:
>=20
> >
> > Hi,
> >
> > I think it is possible to make common code to support both IPIC and=20
> > MPIC.
> > Currently, the MPIC has already implemented MSI which is different=20
> > from IPIC and embedded into the mpic code body.
> > If want to unifiy MSI code, we need to remove the current MPIC MSI=20
> > implementation.
>=20
> The MPIC is going to have to support several MSI styles=20
> (IBM/U3, PaSemi, and FSL) since we all seem to handle it differently.
I enabled the MSI interrrupts on 85xx/86xx board similar to the IBM/U3 =
board.
Did not enable another host as on 83xx board. Put the 256 MSI interrupts =
after the=20
256 system interrupts and use the same mpic host. This can work and can =
reuse most
of the mpic_msi codes. but since the host_map of MSI is something =
different with MPIC.
I also think it's good idea to make a 2 level PIC handling mechanism for =
MSI on 85xx/86xx board and=20
common the code to support for both IPIC and MPIC for fsl board.
=20
> > Micheal, what is your opinion ??
> >
> > Jin is working on 86xx msi now.
>=20
> What PCIe cards are you using to test MSIs?
I used a SysKonnect 1000M PCIe ether card and the SATA driver to test =
the MSI on 85xx/86xx board.
Best Regards,
Jason
> - k
>=20
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: 2007=C4=EA12=D4=C214=C8=D5 13:45
> >> To: Li Tony
> >> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev
> >> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support
> >>
> >>
> >> On Dec 4, 2007, at 4:39 AM, Li Li wrote:
> >>
> >>> Modified based on discussion on list.
> >>>
> >>> 1. Adopt virq_to_hw routine
> >>> 2. Correct a legacy bug
> >>>
> >>> Implements the IPIC MSI as two level interrupt controller.
> >>>
> >>> Signed-off-by: Tony Li <tony.li@freescale.com>
> >>
> >> Tony, have you looked at the 85xx/86xx PCIe MSI mechanism?
> >> The 2nd level PIC handling seems like its pretty similar=20
> between IPIC=20
> >> and MPIC. Would like to see if we could somehow make the=20
> code common=20
> >> for to handle MSIs from both?
> >>
> >> - k
> >>
>=20
>=20
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Li Li @ 2007-12-14 9:13 UTC (permalink / raw)
To: Kumar Gala
Cc: Phillips Kim, linuxppc-dev list, Jin Zhengxiong, Li Tony,
Olof Johansson
In-Reply-To: <90B908AC-E879-4046-AAFC-FE79EB78A932@kernel.crashing.org>
On Fri, 2007-12-14 at 16:52 +0800, Kumar Gala wrote:
>=20
> On Dec 14, 2007, at 2:47 AM, Li Tony wrote:
>=20
> >=20
> > Hi,=20
> >=20
> > I think it is possible to make common code to support both IPIC
> and =20
> > MPIC.=20
> > Currently, the MPIC has already implemented MSI which is different =20
> > from IPIC and embedded into the mpic code body.=20
> > If want to unifiy MSI code, we need to remove the current MPIC MSI =20
> > implementation.
>=20
> The MPIC is going to have to support several MSI styles (IBM/U3, =20
> PaSemi, and FSL) since we all seem to handle it differently.
>=20
Yes, you are right. I misunderstands here.
> > Micheal, what is your opinion ??=20
> >=20
> > Jin is working on 86xx msi now.
>=20
> What PCIe cards are you using to test MSIs?
>=20
Intel PRO1000 PCIE network card and SysKonnect card.
> - k
>=20
> >> -----Original Message-----=20
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> >> Sent: 2007=E5=B9=B412=E6=9C=8814=E6=97=A5 13:45=20
> >> To: Li Tony=20
> >> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev=20
> >> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support=20
> >>=20
> >>=20
> >> On Dec 4, 2007, at 4:39 AM, Li Li wrote:=20
> >>=20
> >>> Modified based on discussion on list.=20
> >>>=20
> >>> 1. Adopt virq_to_hw routine=20
> >>> 2. Correct a legacy bug=20
> >>>=20
> >>> Implements the IPIC MSI as two level interrupt controller.=20
> >>>=20
> >>> Signed-off-by: Tony Li <tony.li@freescale.com>=20
> >>=20
> >> Tony, have you looked at the 85xx/86xx PCIe MSI mechanism?=20
> >> The 2nd level PIC handling seems like its pretty similar=20
> >> between IPIC and MPIC. Would like to see if we could somehow=20
> >> make the code common for to handle MSIs from both?=20
> >>=20
> >> - k=20
> >>
>=20
^ permalink raw reply
* [PATCH] Fix build break caused by "ide: remove ideprobe_init()"
From: Olof Johansson @ 2007-12-14 9:09 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, akpm, linuxppc-dev
In-Reply-To: <200711182325.09262.bzolnier@gmail.com>
Fix build break of powerpc holly_defconfig:
In file included from arch/powerpc/platforms/embedded6xx/holly.c:24:
include/linux/ide.h:1206: error: 'CONFIG_IDE_MAX_HWIFS' undeclared here (not in a function)
There's no need to have a sized array in the prototype, might as well
turn it into a pointer.
It could probably be argued that large parts of the include file can be
covered under #ifdef CONFIG_IDE, but that's a larger undertaking.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
On Sun, Nov 18, 2007 at 11:25:09PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> * Rename ide_device_add() to ide_device_add_all() and make it accept
> 'u8 idx[MAX_HWIFS]' instead of 'u8 idx[4]' as an argument.
>
> * Add ide_device_add() wrapper for ide_device_add_all().
>
> * Convert ide_generic_init() to use ide_device_add_all().
>
> * Remove no longer needed ideprobe_init().
>
> There should be no functionality changes caused by this patch.
This patch broke builds of powerpc holly_defconfig in -mm. It has
CONFIG_EMBEDDED=y, CONFIG_IDE=n but includes linux/ide.h:
Index: mm/drivers/ide/ide-probe.c
===================================================================
--- mm.orig/drivers/ide/ide-probe.c
+++ mm/drivers/ide/ide-probe.c
@@ -1335,7 +1335,7 @@ static void hwif_register_devices(ide_hw
}
}
-int ide_device_add_all(u8 idx[MAX_HWIFS])
+int ide_device_add_all(u8 *idx)
{
ide_hwif_t *hwif;
int i, rc = 0;
Index: mm/include/linux/ide.h
===================================================================
--- mm.orig/include/linux/ide.h
+++ mm/include/linux/ide.h
@@ -1203,7 +1203,7 @@ void ide_unregister_region(struct gendis
void ide_undecoded_slave(ide_drive_t *);
-int ide_device_add_all(u8 idx[MAX_HWIFS]);
+int ide_device_add_all(u8 *idx);
int ide_device_add(u8 idx[4]);
static inline void *ide_get_hwifdata (ide_hwif_t * hwif)
^ permalink raw reply
* Re: [PATCH 4/15] [POWERPC] pci32: Add flags modifying the PCI code behaviour
From: Benjamin Herrenschmidt @ 2007-12-14 9:00 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071214084343.GC28118@lixom.net>
> On Fri, Dec 14, 2007 at 03:56:05PM +1100, Benjamin Herrenschmidt wrote:
>
> > --- linux-merge.orig/arch/powerpc/kernel/pci_32.c 2007-12-14 15:49:28.000000000 +1100
> > +++ linux-merge/arch/powerpc/kernel/pci_32.c 2007-12-14 15:49:29.000000000 +1100
> > @@ -48,7 +51,7 @@ static u8* pci_to_OF_bus_map;
> > /* By default, we don't re-assign bus numbers. We do this only on
> > * some pmacs
> > */
> > -int pci_assign_all_buses;
> > +static int pci_assign_all_buses;
> >
>
> Why not remove it alltogether, there's still the function to test the
> flag that's just as cheap (load + test + branch).
I don't remember... felt like I had a good reason back then but I don't
remember it :-) I'll have another look.
> > Index: linux-merge/include/asm-powerpc/pci-bridge.h
> > ===================================================================
> > --- linux-merge.orig/include/asm-powerpc/pci-bridge.h 2007-12-14 15:49:01.000000000 +1100
> > +++ linux-merge/include/asm-powerpc/pci-bridge.h 2007-12-14 15:49:29.000000000 +1100
> > @@ -13,6 +13,26 @@
> >
> > struct device_node;
> >
> > +extern unsigned int ppc_pci_flags;
>
> Should the below be a named enum and the type for the above be the same
> for nicer decode in gdb?
>
> > +enum {
> > + /* Force re-assigning all resources (ignore firmware
> > + * setup completely)
> > + */
> > + PPC_PCI_REASSIGN_ALL_RSRC = 0x00000001,
>
> This should be ..._RSRCS (resources, not resource)
>
> > + /* Re-assign all bus numbers */
> > + PPC_PCI_REASSIGN_ALL_BUS = 0x00000002,
>
> And this should be ..._BUSSES
>
> > + /* Do not try to assign, just use existing setup */
> > + PPC_PCI_PROBE_ONLY = 0x00000004,
>
> My first reaction was "what's the difference between setting this and
> keeping the two other cleared". Looks like the difference is the
> assignment of unassigned resources. Not sure how to better represent
> that so it's obvious from the naming (without doing something as
> excessive as PPC_PCI_REASSIGN_UNASSIGNED_RSRCS :)
Well... hence "RE" in "REASSIGN" ...
By default, we assign only unassigned resources... (or the ones that
collide). I could add a comment to that effect.
> > +
> > + /* Don't bother with ISA alignment unless the bridge has
> > + * ISA forwarding enabled
> > + */
> > + PPC_PCI_CAN_SKIP_ISA_ALIGN = 0x00000008,
> > +};
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Kumar Gala @ 2007-12-14 8:52 UTC (permalink / raw)
To: Li Tony; +Cc: linuxppc-dev list, Phillips Kim, Olof Johansson, Jin Zhengxiong
In-Reply-To: <995B09A8299C2C44B59866F6391D2635DB0633@zch01exm21.fsl.freescale.net>
On Dec 14, 2007, at 2:47 AM, Li Tony wrote:
>
> Hi,
>
> I think it is possible to make common code to support both IPIC and =20=
> MPIC.
> Currently, the MPIC has already implemented MSI which is different =20
> from IPIC and embedded into the mpic code body.
> If want to unifiy MSI code, we need to remove the current MPIC MSI =20
> implementation.
The MPIC is going to have to support several MSI styles (IBM/U3, =20
PaSemi, and FSL) since we all seem to handle it differently.
> Micheal, what is your opinion ??
>
> Jin is working on 86xx msi now.
What PCIe cards are you using to test MSIs?
- k
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: 2007=C4=EA12=D4=C214=C8=D5 13:45
>> To: Li Tony
>> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev
>> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support
>>
>>
>> On Dec 4, 2007, at 4:39 AM, Li Li wrote:
>>
>>> Modified based on discussion on list.
>>>
>>> 1. Adopt virq_to_hw routine
>>> 2. Correct a legacy bug
>>>
>>> Implements the IPIC MSI as two level interrupt controller.
>>>
>>> Signed-off-by: Tony Li <tony.li@freescale.com>
>>
>> Tony, have you looked at the 85xx/86xx PCIe MSI mechanism?
>> The 2nd level PIC handling seems like its pretty similar
>> between IPIC and MPIC. Would like to see if we could somehow
>> make the code common for to handle MSIs from both?
>>
>> - k
>>
^ permalink raw reply
* RE: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Li Tony @ 2007-12-14 8:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Phillips Kim, Jin Zhengxiong
In-Reply-To: <97EB3576-6952-4F36-A243-4EBF981A117F@kernel.crashing.org>
=20
Hi,
I think it is possible to make common code to support both IPIC and =
MPIC.
Currently, the MPIC has already implemented MSI which is different from =
IPIC and embedded into the mpic code body.
If want to unifiy MSI code, we need to remove the current MPIC MSI =
implementation.
Micheal, what is your opinion ??
Jin is working on 86xx msi now.=20
Tony
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: 2007=C4=EA12=D4=C214=C8=D5 13:45
> To: Li Tony
> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev
> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support
>=20
>=20
> On Dec 4, 2007, at 4:39 AM, Li Li wrote:
>=20
> > Modified based on discussion on list.
> >
> > 1. Adopt virq_to_hw routine
> > 2. Correct a legacy bug
> >
> > Implements the IPIC MSI as two level interrupt controller.
> >
> > Signed-off-by: Tony Li <tony.li@freescale.com>
>=20
> Tony, have you looked at the 85xx/86xx PCIe MSI mechanism? =20
> The 2nd level PIC handling seems like its pretty similar=20
> between IPIC and MPIC. Would like to see if we could somehow=20
> make the code common for to handle MSIs from both?
>=20
> - k
>=20
^ permalink raw reply
* Re: [PATCH 1/7] bootwrapper: Add a firmware-independent "raw" target.
From: Milton Miller @ 2007-12-14 8:05 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: ppcdev
In-Reply-To: <20071213234221.B0BC27D0054@mail142-sin.bigfish.com>
On Fri Dec 14 10:43:27 EST 2007, Stephen Neuendorffer wrote:
> From: Grant Likely <grant.likely at secretlab.ca>
>
> This target produces a flat binary rather than an ELF file,
> fixes the entry point at the beginning of the image, and takes
> a complete device tree with no fixups needed.
>
> The device tree must have labels on /#address-cells, the timebase
> frequency, and the memory size.
>
> Signed-off-by: Grant Likely <grant.likely at secretlab.ca>
> ---
You indicated in the intro in 0/ that this was not ready, and you
didn't include your own s-o-b, but you did not put any statements to
that effect in the header. The intro is not copied into patchwork,
which maintainers often use when deciding what to push.
Now on to why this should not be merged:
In addition to the above, it changes the build rules. It tries to
change wrapper to assemble the .dtb into a .o from a .S file, but
doesn't set any flags to force the assembler into the right mode. In
contrast the linker is controlled by the .lds linker script.
In addition, the requirement for assembly labels can easily be
eliminated. As mentioned above, they are used for 3 properties. With
the existing library (in 2.6.24 and earlier), call simple_malloc_init
with a small bss array (like BSS_STACK does to allocate stack), and
then read the properties out of the device tree. At that point, call
simple_malloc_init a second time using the found memory size. As I
said the last time this was posted, my patches to boot from kexec
implemented this strategy.
However, with the new libfdt, which is already in for-2.6.25, we should
no longer need malloc() to simple read the tree. At least that is
what was advertised.
> +$(obj)/zImage.raw: vmlinux $(dts) $(wrapperbits)
> + $(call if_changed,wrap,raw,$(dts))
>
This should be handled by the standard zImage% rule.
> +void platform_init(unsigned long r3, unsigned long r4, unsigned long
> r5,
> + unsigned long r6, unsigned long r7)
>
The calling convention of platform_init is controlled by head, and
doesn't have a global prototype. Since you use none of these
arguments, this implementation should take void.
In general, serial_console_init is not safe to call, as the wrapper has
no access mode change for its io access macros and instead requires
firmware to setup a mapping. That and the fact the wrapper uses the
same properties to choose the console as the kernel means even
kexec-tools can't add or delete a property to kill that call. (This
statement is made from the viewpoint that this raw image should be
suitable for kexec in addition to being loaded by a dumb firmware).
I'm not sure exactly what platform you are using this on. Apparently
it is a legacy firmware that loads the image and jumps to it leaving
interrupts on and not invalidating the cache.
I was going to suggest this platform_init be turned into a helper like
simple_platform_init or so. However, that brings up a philosophy
question on what the directory should look like (I was going for a
modular library with lots of small routines loaded on demand, but
others are going for fewer files that tend to drag sometimes used
routines. They later resist features with "thats a lot of code"). And
with the read_only libfdt pending, the remaining code maybe considered
too trivial not to replicate in the platforms that need it.
milton
^ permalink raw reply
* Re: [PATCH 4/15] [POWERPC] pci32: Add flags modifying the PCI code behaviour
From: Olof Johansson @ 2007-12-14 8:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071214045612.3A7E6DE2E2@ozlabs.org>
Hi,
Minor nitpicks:
On Fri, Dec 14, 2007 at 03:56:05PM +1100, Benjamin Herrenschmidt wrote:
> --- linux-merge.orig/arch/powerpc/kernel/pci_32.c 2007-12-14 15:49:28.000000000 +1100
> +++ linux-merge/arch/powerpc/kernel/pci_32.c 2007-12-14 15:49:29.000000000 +1100
> @@ -48,7 +51,7 @@ static u8* pci_to_OF_bus_map;
> /* By default, we don't re-assign bus numbers. We do this only on
> * some pmacs
> */
> -int pci_assign_all_buses;
> +static int pci_assign_all_buses;
>
Why not remove it alltogether, there's still the function to test the
flag that's just as cheap (load + test + branch).
> Index: linux-merge/include/asm-powerpc/pci-bridge.h
> ===================================================================
> --- linux-merge.orig/include/asm-powerpc/pci-bridge.h 2007-12-14 15:49:01.000000000 +1100
> +++ linux-merge/include/asm-powerpc/pci-bridge.h 2007-12-14 15:49:29.000000000 +1100
> @@ -13,6 +13,26 @@
>
> struct device_node;
>
> +extern unsigned int ppc_pci_flags;
Should the below be a named enum and the type for the above be the same
for nicer decode in gdb?
> +enum {
> + /* Force re-assigning all resources (ignore firmware
> + * setup completely)
> + */
> + PPC_PCI_REASSIGN_ALL_RSRC = 0x00000001,
This should be ..._RSRCS (resources, not resource)
> + /* Re-assign all bus numbers */
> + PPC_PCI_REASSIGN_ALL_BUS = 0x00000002,
And this should be ..._BUSSES
> + /* Do not try to assign, just use existing setup */
> + PPC_PCI_PROBE_ONLY = 0x00000004,
My first reaction was "what's the difference between setting this and
keeping the two other cleared". Looks like the difference is the
assignment of unassigned resources. Not sure how to better represent
that so it's obvious from the naming (without doing something as
excessive as PPC_PCI_REASSIGN_UNASSIGNED_RSRCS :)
> +
> + /* Don't bother with ISA alignment unless the bridge has
> + * ISA forwarding enabled
> + */
> + PPC_PCI_CAN_SKIP_ISA_ALIGN = 0x00000008,
> +};
-Olof
^ permalink raw reply
* RE: [PATCH] add MPC837x MDS board default device tree
From: Li Yang @ 2007-12-14 8:33 UTC (permalink / raw)
To: Kumar Gala, David Gibson; +Cc: linuxppc-dev
In-Reply-To: <4A496992-9B46-427D-8F40-447E92F8CA3D@kernel.crashing.org>
> >> + device_type =3D "serial";
> >> + compatible =3D "ns16550";
> >> + reg =3D <4600 100>;
> >> + clock-frequency =3D <0>;
> >> + interrupts =3D <a 8>;
> >> + interrupt-parent =3D < &ipic >;
> >> + };
> >> +
> >> + crypto@30000 {
> >> + model =3D "SEC3";
> >> + compatible =3D "talitos";
> >
> > This driver, also, needs fixing to recognize a better formatted=20
> > compatible property.
>=20
> Can you respin with David's changes as well as mirror my=20
> cleanup of the other 83xx/85xx .dts
Sure, but I'm taking one week off. Will send you the updated one after
Christmas though.
- Leo
^ permalink raw reply
* Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
From: Olof Johansson @ 2007-12-14 8:23 UTC (permalink / raw)
To: Scott Wood
Cc: linux-ide, Paul Mundt, Arnd Bergmann, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071205183912.GA4516@loki.buserror.net>
On Wed, Dec 05, 2007 at 12:39:12PM -0600, Scott Wood wrote:
> On Wed, Dec 05, 2007 at 09:48:41AM +0900, Paul Mundt wrote:
> > On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> > > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > > > tristate "Generic platform device PATA support"
> > > > - depends on EMBEDDED || ARCH_RPC
> > > > + depends on EMBEDDED || ARCH_PPC
> > >
> > > It needs to be || PPC, not || ARCH_PPC.
> > >
> > Wrong. It needs to be EMBEDDED || ARCH_RPC || PPC.
>
> Why is it dependent on anything other than platform bus support and ATA?
There's no way to specify dependency on platform bus as a config option,
that's likely what EMBEDDED was meant to do. Some platforms have platform
bus in spite of being !EMBEDDED, arch/arm/configs/rpc_defconfig seems
to be among those. PPC too.
-Olof
^ permalink raw reply
* Re: [PATCH] add MPC837x MDS board default device tree
From: Kumar Gala @ 2007-12-14 8:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Li Yang
In-Reply-To: <20071207020130.GA26412@localhost.localdomain>
On Dec 6, 2007, at 8:01 PM, David Gibson wrote:
> On Wed, Dec 05, 2007 at 06:37:53PM +0800, Li Yang wrote:
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> Update SATA nodes; remove serdes nodes; add aliases and labels.
>>
>> arch/powerpc/boot/dts/mpc8377_mds.dts | 270 +++++++++++++++++++++++
>> ++++++++
>> arch/powerpc/boot/dts/mpc8378_mds.dts | 256 +++++++++++++++++++++++
>> ++++++
>> arch/powerpc/boot/dts/mpc8379_mds.dts | 284 +++++++++++++++++++++++
>> ++++++++++
>> 3 files changed, 810 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts
>> create mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts
>> create mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts
>>
>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/
>> boot/dts/mpc8377_mds.dts
>> new file mode 100644
>> index 0000000..919ffd0
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
> [snip]
>> + aliases {
>> + ethernet0 = "/soc@e0000000/ethernet@24000";
>> + ethernet1 = "/soc@e0000000/ethernet@25000";
>> + serial0 = "/soc@e0000000/serial@4500";
>> + serial1 = "/soc@e0000000/serial@4600";
>> + pci0 = "/pci@e0008500";
>
> You can use path references for these now.
>
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + PowerPC,837x@0 {
>
> This should absolutely not have a "x" in it. Either have an exact
> model, or just use "cpu@9" (in which case you can put the model in
> "compatible").
>
> [snip]
>> + i2c@3000 {
>> + device_type = "i2c";
>
> Drop the device_type. No "i2c" device_type class is defined.
>
> [snip]
>> + /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
>> + usb@23000 {
>> + device_type = "usb";
>
> Drop device_type here too.
>
>> + compatible = "fsl-usb2-dr";
>> + reg = <23000 1000>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + interrupt-parent = < &ipic >;
>> + interrupts = <26 8>;
>> + phy_type = "utmi_wide";
>> + };
>> +
>> + mdio@24520 {
>> + device_type = "mdio";
>> + compatible = "gianfar";
>
> Grr... not your fault, but this crap in the gianfar driver where it
> uses the same compatible property for the mdio and MAC has to be
> fixed.
I've fixed this now. Look at my tree/patch.
> [snip]
>
>> + serial1:serial@4600 {
>
> Standard style puts a space after the colon.
>
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <4600 100>;
>> + clock-frequency = <0>;
>> + interrupts = <a 8>;
>> + interrupt-parent = < &ipic >;
>> + };
>> +
>> + crypto@30000 {
>> + model = "SEC3";
>> + compatible = "talitos";
>
> This driver, also, needs fixing to recognize a better formatted
> compatible property.
Can you respin with David's changes as well as mirror my cleanup of
the other 83xx/85xx .dts
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Olof Johansson @ 2007-12-14 8:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <77815911-B0FA-4FFD-AC50-5C9A8FED90C4@kernel.crashing.org>
On Fri, Dec 14, 2007 at 02:08:14AM -0600, Kumar Gala wrote:
> I'd say wait for Paul to pickup my 2.6.25 request. Than the base will
> have the isel emulation as well.
It was spotting the isel patch in your queue that made me go back and
look at the thread. :)
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Olof Johansson @ 2007-12-14 8:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <20071214081210.GB27284@lixom.net>
On Fri, Dec 14, 2007 at 02:12:10AM -0600, Olof Johansson wrote:
> Care to resubmit a clean patch under a fresh subject? Paul didn't chime
> in but hopefully he can pick it up for 2.6.25.
Next time I will take the time to re-read the whole thread. :)
Seems like the open question was how to warn only for excessive
amounts of emulated ops. Maybe a simple count/threshold per process
(+ printk_ratelimit)? Warning on every power of 10 occurrances was also
suggested, either works for me.
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-12-14 8:08 UTC (permalink / raw)
To: Olof Johansson; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <20071214081210.GB27284@lixom.net>
On Dec 14, 2007, at 2:12 AM, Olof Johansson wrote:
> On Thu, Nov 29, 2007 at 04:13:14PM +0100, Geert Uytterhoeven wrote:
>> On Wed, 28 Nov 2007, Geert Uytterhoeven wrote:
>>> +static inline void warn_emulated_sysctl_register(void)
>>> +{
>>> + int res = register_sysctl_table(warn_emulated_sysctl_root);
>> ^^^^^^^^^^
>>> + printk("@@@ register_sysctl_table() returned %d\n", res);
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> +}
>>
>> Woops, that part shouldn't have been there...
>
> Care to resubmit a clean patch under a fresh subject? Paul didn't
> chime
> in but hopefully he can pick it up for 2.6.25.
I'd say wait for Paul to pickup my 2.6.25 request. Than the base will
have the isel emulation as well.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Olof Johansson @ 2007-12-14 8:12 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711291612290.24058@pademelon.sonytel.be>
On Thu, Nov 29, 2007 at 04:13:14PM +0100, Geert Uytterhoeven wrote:
> On Wed, 28 Nov 2007, Geert Uytterhoeven wrote:
> > +static inline void warn_emulated_sysctl_register(void)
> > +{
> > + int res = register_sysctl_table(warn_emulated_sysctl_root);
> ^^^^^^^^^^
> > + printk("@@@ register_sysctl_table() returned %d\n", res);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +}
>
> Woops, that part shouldn't have been there...
Care to resubmit a clean patch under a fresh subject? Paul didn't chime
in but hopefully he can pick it up for 2.6.25.
Thanks,
Olof
^ permalink raw reply
* [PATCH] [POWERPC] pasemi: export pasemi_dma_init()
From: Olof Johansson @ 2007-12-14 8:06 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev
Forgot to export this one. Needed when pasemi_mac is compiled as a module.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Jeff, since the dma_lib stuff went up through netdev-2.6, please apply and
feed this one up with the rest.
Thanks,
Olof
Index: 2.6.24/arch/powerpc/platforms/pasemi/dma_lib.c
===================================================================
--- 2.6.24.orig/arch/powerpc/platforms/pasemi/dma_lib.c
+++ 2.6.24/arch/powerpc/platforms/pasemi/dma_lib.c
@@ -485,3 +485,4 @@ out:
spin_unlock(&init_lock);
return err;
}
+EXPORT_SYMBOL(pasemi_dma_init);
^ permalink raw reply
* Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2007-12-14 7:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
Documentation/powerpc/booting-without-of.txt | 19
arch/powerpc/boot/dts/kuroboxHD.dts | 16
arch/powerpc/boot/dts/kuroboxHG.dts | 16
arch/powerpc/boot/dts/lite5200.dts | 6
arch/powerpc/boot/dts/lite5200b.dts | 6
arch/powerpc/boot/dts/mpc8313erdb.dts | 36 -
arch/powerpc/boot/dts/mpc832x_mds.dts | 45 -
arch/powerpc/boot/dts/mpc832x_rdb.dts | 47 -
arch/powerpc/boot/dts/mpc8349emitx.dts | 54 -
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 32
arch/powerpc/boot/dts/mpc834x_mds.dts | 51 -
arch/powerpc/boot/dts/mpc836x_mds.dts | 47 -
arch/powerpc/boot/dts/mpc8540ads.dts | 59 -
arch/powerpc/boot/dts/mpc8541cds.dts | 41 -
arch/powerpc/boot/dts/mpc8544ds.dts | 59 +
arch/powerpc/boot/dts/mpc8548cds.dts | 68 +-
arch/powerpc/boot/dts/mpc8555cds.dts | 41 -
arch/powerpc/boot/dts/mpc8560ads.dts | 59 -
arch/powerpc/boot/dts/mpc8568mds.dts | 80 +-
arch/powerpc/boot/dts/mpc8572ds.dts | 59 +
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 28
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 80 +-
arch/powerpc/boot/dts/mpc866ads.dts | 156 ++--
arch/powerpc/configs/mpc837x_mds_defconfig | 878 +++++++++++++++++++++++++++
arch/powerpc/kernel/cputable.c | 13
arch/powerpc/kernel/traps.c | 25
arch/powerpc/platforms/82xx/pq2fads.c | 2
arch/powerpc/platforms/83xx/Kconfig | 11
arch/powerpc/platforms/83xx/Makefile | 1
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 4
arch/powerpc/platforms/83xx/mpc832x_mds.c | 4
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 2
arch/powerpc/platforms/83xx/mpc834x_mds.c | 21
arch/powerpc/platforms/83xx/mpc836x_mds.c | 4
arch/powerpc/platforms/83xx/mpc837x_mds.c | 104 +++
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4
arch/powerpc/platforms/8xx/Kconfig | 1
arch/powerpc/platforms/8xx/mpc86xads.h | 44 -
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 289 ++------
arch/powerpc/sysdev/commproc.c | 47 +
arch/powerpc/sysdev/cpm2_common.c | 25
arch/powerpc/sysdev/fsl_soc.c | 23
arch/powerpc/sysdev/ipic.c | 219 ++++--
arch/powerpc/sysdev/ipic.h | 13
arch/powerpc/sysdev/qe_lib/qe.c | 46 +
drivers/net/fs_enet/mac-fcc.c | 10
drivers/net/fs_enet/mac-scc.c | 11
drivers/net/ucc_geth.c | 55 +
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 6
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 8
include/asm-powerpc/cpm.h | 1
include/asm-powerpc/immap_86xx.h | 25
include/asm-powerpc/ipic.h | 12
include/asm-powerpc/qe.h | 95 +-
include/asm-powerpc/reg_booke.h | 13
55 files changed, 2214 insertions(+), 907 deletions(-)
Jochen Friedrich (2):
[POWERPC] Add support for PORTA and PORTB odr registers
[POWERPC] Move CPM command handling into the cpm drivers
Jon Loeliger (2):
[POWERPC] 8xxx: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
[POWERPC] 86xx: Add aliases node to 8641hpcn DTS file.
Kumar Gala (5):
[POWERPC] Add SPRN for Embedded registers specified in PowerISA 2.04
[POWERPC] Emulate isel (Integer Select) instruction
[POWERPC] FSL: I2C device tree cleanups
[POWERPC] FSL: enet device tree cleanups
[POWERPC] FSL: Added aliases node to device trees
Li Yang (5):
[POWERPC] add e300c4 entry to cputable
[POWERPC] ipic: add new interrupts introduced by new chip
[POWERPC] 83xx: Add platform support for MPC837x MDS board
[POWERPC] 83xx: Add MPC837x MDS default kernel configuration
[POWERPC] ipic: ack only for edge interrupts
Scott Wood (3):
[POWERPC] 8xx: Convert mpc866ads to the new device binding.
[POWERPC] 83xx: mpc834x_mds: Fix whitespace and call of_platform_bus_probe().
[POWERPC] 83xx: mpc8313erdb: Fix whitespace.
Timur Tabi (4):
[POWERPC] 86xx: fix guts_set_dmacr() and add guts_set_pmuxcr_dma() to immap_86xx.h
[POWERPC] QE: change qe_setbrg() to take an enum qe_clock instead of an integer
[POWERPC] qe: add function qe_clock_source()
[POWERPC] ucc_geth: use rx-clock-name and tx-clock-name device tree properties
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: use rx-clock-name and tx-clock-name device tree properties
From: Kumar Gala @ 2007-12-14 7:19 UTC (permalink / raw)
To: Timur Tabi; +Cc: netdev, linuxppc-dev
In-Reply-To: <1196716685975-git-send-email-timur@freescale.com>
On Dec 3, 2007, at 3:17 PM, Timur Tabi wrote:
> Updates the ucc_geth device driver to check the new rx-clock-name and
> tx-clock-name properties first. If present, it uses the new function
> qe_clock_source() to obtain the clock source. Otherwise, it checks
> the
> deprecated rx-clock and tx-clock properties.
>
> Update the device trees for 832x, 836x, and 8568 to contain the new
> property
> names only.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> This patch applies to Kumar's for-2.6.25 branch. ucc_geth will
> compile but not
> run if my other patch, "qe: add function qe_clock_source" has not
> also been
> applied.
>
> arch/powerpc/boot/dts/mpc832x_mds.dts | 8 ++--
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 8 ++--
> arch/powerpc/boot/dts/mpc836x_mds.dts | 8 ++--
> arch/powerpc/boot/dts/mpc8568mds.dts | 8 ++--
> drivers/net/ucc_geth.c | 55 ++++++++++++++++++++++++
> ++++++--
> 5 files changed, 67 insertions(+), 20 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: use rx-clock-name and tx-clock-name device tree properties
From: Jeff Garzik @ 2007-12-14 6:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, Timur Tabi, linuxppc-dev list
In-Reply-To: <4373ED4B-5EDD-4725-9D99-BE39B0656E19@kernel.crashing.org>
Kumar Gala wrote:
>
> On Dec 3, 2007, at 3:17 PM, Timur Tabi wrote:
>
>> Updates the ucc_geth device driver to check the new rx-clock-name and
>> tx-clock-name properties first. If present, it uses the new function
>> qe_clock_source() to obtain the clock source. Otherwise, it checks the
>> deprecated rx-clock and tx-clock properties.
>>
>> Update the device trees for 832x, 836x, and 8568 to contain the new
>> property
>> names only.
>>
>> Signed-off-by: Timur Tabi <timur@freescale.com>
>> ---
>>
>> This patch applies to Kumar's for-2.6.25 branch. ucc_geth will
>> compile but not
>> run if my other patch, "qe: add function qe_clock_source" has not also
>> been
>> applied.
>
> Jeff, I'll take this patch via powerpc.git if you don't have any issue
> since its just touching probe/setup bits.
ACK
^ permalink raw reply
* Re: [PATCH] Fix rounding bug in emulation for double floatoperating
From: Kumar Gala @ 2007-12-14 6:14 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Liu Yu, David Gibson
In-Reply-To: <1197612373.10259.9.camel@localhost.localdomain>
On Dec 14, 2007, at 12:06 AM, Zang Roy-r61911 wrote:
> On Fri, 2007-12-14 at 13:46, Kumar Gala wrote:
>>>> When I run this on a G5 (w/HW FP) I get:
>>>>
>>>> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
>>>> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
>>>> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
>>>>
>>>> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
>>>>
>>>> and on the 85xx w/FP emu:
>>>>
>>>> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
>>>> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
>>>> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
>>>>
>>>> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
>>>>
>>>> Maybe I'm missing where the error is.
>>> I am missing ...
>>> It is supposed to run based on previous IEEE 754 patch.
>>> http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031351.html
>>
>> I'd really like to see to see a testcase show the issue with "classic
>> FP emu" on a 85xx system.
> I can understand.
> You know, For a 85xx system without the previous patch or other
> 'classic' powerpc, it is hard to trigger this issue. Although I
> believe
> it is a problem fixed up.
> Do you have any idea?
maybe I'm missing it, but can we not do the same operation w/classic
FP that you are doing w/SPE fp?
is this in standard rounding mode, etc?
- k
^ permalink raw reply
* Re: [PATCH] Fix rounding bug in emulation for double floatoperating
From: Zang Roy-r61911 @ 2007-12-14 6:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Liu Yu, David Gibson
In-Reply-To: <BB2AC24A-6336-4270-9124-734BCC09F7DA@kernel.crashing.org>
On Fri, 2007-12-14 at 13:46, Kumar Gala wrote:
> >> When I run this on a G5 (w/HW FP) I get:
> >>
> >> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
> >> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
> >> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
> >>
> >> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
> >>
> >> and on the 85xx w/FP emu:
> >>
> >> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
> >> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
> >> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
> >>
> >> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
> >>
> >> Maybe I'm missing where the error is.
> > I am missing ...
> > It is supposed to run based on previous IEEE 754 patch.
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031351.html
>
> I'd really like to see to see a testcase show the issue with "classic
> FP emu" on a 85xx system.
I can understand.
You know, For a 85xx system without the previous patch or other
'classic' powerpc, it is hard to trigger this issue. Although I believe
it is a problem fixed up.
Do you have any idea?
Roy
^ permalink raw reply
* Re: [DTC][PATCH] Fix cross-compile building
From: Kumar Gala @ 2007-12-14 5:57 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger, stuarth
In-Reply-To: <20071208003604.GH566@localhost.localdomain>
On Dec 7, 2007, at 6:36 PM, David Gibson wrote:
> On Fri, Dec 07, 2007 at 12:28:20PM -0600, Kumar Gala wrote:
>> From: Stuart Hughes <stuarth@freescale.com>
>>
>> This patch allows you to build the DTC source without making the
>> tests directory. This is necessary when cross compiling as the
>> dumptest (and other) files cannot be run/used on the host system.
>> To use this use: 'make TESTS='
>
> I think this is a silly way of doing this. Instead create a new
> target which builds everything but the tests.
>
> Say,
>
> all: cross tests
>
> cross: dtc ftdump libfdt
shouldn't we do this the other way around, it seems odd to build the
tests always or at least as part of the all target.
- k
^ permalink raw reply
* Re: [PATCH 19/20] [POWERPC] pci32: 4xx embedded platforms want to reassign all PCI resources
From: Stefan Roese @ 2007-12-14 5:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071213155946.0e0c39a0@weaponx>
On Thursday 13 December 2007, Josh Boyer wrote:
> > Keeping your embedded design tiny (and thus your own BSP) is one thing,
> > but adding ifdef's all over the place so that somebody can tinify an
> > eval board, I'm less sure about this... but if you want, you can fixup
> > my patches.
>
> I'm not really advocating for ifdefs. If it annoys me enough (which I
> doubt it will), then I'd try to come up with some way to avoid those
> too. For now, I think selecting PCI in Kconfig for those boards is OK.
Yes, I think it is OK to select it this way an those boards since they are
evaluation boards with PCI slots.
Ciao,
Stefan
^ permalink raw reply
* Re: Please pull linux-2.6-8xx.git for-paulus branch
From: Kumar Gala @ 2007-12-14 5:47 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071209115353.1ae09ee1@kernel.crashing.org>
On Dec 9, 2007, at 2:53 AM, Vitaly Bordug wrote:
> On Sat, 8 Dec 2007 09:17:06 -0600
> Kumar Gala wrote:
>
>>
>> On Dec 8, 2007, at 4:09 AM, Vitaly Bordug wrote:
>>
>>> On Sat, 8 Dec 2007 13:00:25 +0300
>>> Vitaly Bordug wrote:
>>>
>>>> Paul,
>>>>
>>>> please do
>>>> git-pull
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/vitb/
>>>> linux-2.6-8xx.git
>>>> for-paulus
>>>>
>>>> to receive the following updates:
>>>>
>>> Forgot to tell that this is .25 material...
>>
>> Vitaly, if you don't mind I'll pull these into my tree for Paul to
>> collect all the FSL stuff in one place.
>>
> I'm ok with either way.
I've pulled this and split the patches between for-2.6.24 (sent pull
request to paulus) and for-2.6.25
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox