* RE: Help with device tree binding for SMC serial
From: Rune Torgersen @ 2008-01-11 14:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03D9A042@ismail.innsys.innovsys.com>
> From: Rune Torgersen
> Finally got it (sort-of) working.
> Turned out that for some reason the console init is setting=20
> the baudrate
> to 9600
> the options string passed in to the console init fuunction is NULL.
>=20
> Any idea oon how this should be passed in from u-boot?
Ok, needed a valid console=3D line on the command line. WHen we tried
that, we had a typo, so it was not recognized.
Our old 2.6.18 arch/ppc kernel didn't need a console parameter, it got
the baudrate from u-boot somehow.
Anyway of doing that here too?
^ permalink raw reply
* Re: libfdt: Add fdt_set_name() function
From: Jon Loeliger @ 2008-01-11 13:44 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080111035505.GB25055@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch adds an fdt_set_name() function to libfdt, mirroring
> fdt_get_name(). This is a r/w function which alters the name of a
> given device tree node.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* [PATCH 2/2] ps3fb: fix deadlock on kexec()
From: Geert Uytterhoeven @ 2008-01-11 13:28 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Frame Buffer Device Development, Linux Kernel Development,
Linux/PPC Development, Jeremy Kerr,
Cell Broadband Engine OSS Development
In-Reply-To: <Pine.LNX.4.64.0801111417450.12038@vixen.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3570 bytes --]
From: Jeremy Kerr <jk@ozlabs.org>
Since the introduction of the acquire_console_sem calls in
0333d83509c7d8496c8965b5ba9bc0c98e83c259, kexecing can cause the
kernel to deadlock:
ps3fb_shutdown()
-> unregister_framebuffer()
-> fb_notifier_call_chain(FB_EVENT_FB_UNBIND)
-> fbcon_fb_unbind()
-> unbind_con_driver()
-> bind_con_driver()
[ acquires console_sem ]
-> fbcon_deinit()
-> fbops->fb_release(newinfo, 0)
-> ps3fb_release()
-> ps3fb_sync()
[ acquires console_sem ]
This change avoids the deadlock by moving the acquire_console_sem()
out of ps3fb_sync(), and puts it into the two other callsites, leaving
ps3fb_release() to call ps3fb_sync() without the console semaphore.
[Geert]
- Corrected call sequence above
- ps3fb_release() may be called with and without console_sem held. This is an
inconsistency that should be fixed at the fb level, but for now, try to
acquire console_sem in ps3fb_release().
I think it's safer to let ps3fb_release() try to acquire console_sem and
not refresh the screen if it fails, than to call ps3fb_sync() without
holding console_sem, as ps3fb_par may be modified at the same time, causing
crashes or lockups.
Besides, ps3fb_release() only calls ps3fb_sync() to refresh the screen
when display flipping is disabled, which is an uncommon case (except during
shutdown/kexec).
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/video/ps3fb.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -443,8 +443,6 @@ static int ps3fb_sync(struct fb_info *in
u32 ddr_line_length, xdr_line_length;
u64 ddr_base, xdr_base;
- acquire_console_sem();
-
if (frame > par->num_frames - 1) {
dev_dbg(info->device, "%s: invalid frame number (%u)\n",
__func__, frame);
@@ -464,7 +462,6 @@ static int ps3fb_sync(struct fb_info *in
xdr_line_length);
out:
- release_console_sem();
return error;
}
@@ -479,7 +476,10 @@ static int ps3fb_release(struct fb_info
if (atomic_dec_and_test(&ps3fb.f_count)) {
if (atomic_read(&ps3fb.ext_flip)) {
atomic_set(&ps3fb.ext_flip, 0);
- ps3fb_sync(info, 0); /* single buffer */
+ if (!try_acquire_console_sem()) {
+ ps3fb_sync(info, 0); /* single buffer */
+ release_console_sem();
+ }
}
}
return 0;
@@ -865,7 +865,9 @@ static int ps3fb_ioctl(struct fb_info *i
break;
dev_dbg(info->device, "PS3FB_IOCTL_FSEL:%d\n", val);
+ acquire_console_sem();
retval = ps3fb_sync(info, val);
+ release_console_sem();
break;
default:
@@ -885,7 +887,9 @@ static int ps3fbd(void *arg)
set_current_state(TASK_INTERRUPTIBLE);
if (ps3fb.is_kicked) {
ps3fb.is_kicked = 0;
+ acquire_console_sem();
ps3fb_sync(info, 0); /* single buffer */
+ release_console_sem();
}
schedule();
}
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH 1/2] ps3fb: prevent use after free of fb_info
From: Geert Uytterhoeven @ 2008-01-11 13:27 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
Jeremy Kerr, Cell Broadband Engine OSS Development
In-Reply-To: <Pine.LNX.4.64.0801111417450.12038@vixen.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1869 bytes --]
From: Jeremy Kerr <jk@ozlabs.org>
In ps3fb_shutdown, freeing the framebuffer will cause fb_info (in
dev->core.driver_data) to be free()ed, which we potentially access
from the ps3fbd kthread.
This change frees the framebuffer after stopping the ps3fbd kthread.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/video/ps3fb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -1234,12 +1234,6 @@ static int ps3fb_shutdown(struct ps3_sys
ps3fb_flip_ctl(0, &ps3fb); /* flip off */
ps3fb.dinfo->irq.mask = 0;
- if (info) {
- unregister_framebuffer(info);
- fb_dealloc_cmap(&info->cmap);
- framebuffer_release(info);
- }
-
ps3av_register_flip_ctl(NULL, NULL);
if (ps3fb.task) {
struct task_struct *task = ps3fb.task;
@@ -1250,6 +1244,12 @@ static int ps3fb_shutdown(struct ps3_sys
free_irq(ps3fb.irq_no, &dev->core);
ps3_irq_plug_destroy(ps3fb.irq_no);
}
+ if (info) {
+ unregister_framebuffer(info);
+ fb_dealloc_cmap(&info->cmap);
+ framebuffer_release(info);
+ info = dev->core.driver_data = NULL;
+ }
iounmap((u8 __iomem *)ps3fb.dinfo);
status = lv1_gpu_context_free(ps3fb.context_handle);
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH 0/2] ps3fb fixes for 2.6.24
From: Geert Uytterhoeven @ 2008-01-11 13:26 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
Jeremy Kerr, Cell Broadband Engine OSS Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 989 bytes --]
Hi Linus, Andrew,
Here are 2 more fixes for ps3fb:
[1] ps3fb: prevent use after free of fb_info
[2] ps3fb: fix deadlock on kexec()
The first one fixes a potential use after free.
The second one fixes a lockup when using kexec or shutdown while /dev/fb0 is
open (e.g. when using the petitboot graphical bootloader to load the second
stage kernel).
Can we please get these in 2.6.24? Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* PPC vs POWERPC
From: samppa @ 2008-01-11 12:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I want to port a board ( WRS SBC8265 ) from the PPC branch to the POWERPC
branch in the Linux Kernel -- do you have any good starting points that
describes what I need to pay attention to?
I've already made a port of U-boot-1.3.1 and enabled CONFIG_OF_LIBFDT.
So I need to create a DTS file, compile it with the DTC compiler and port
the current PPC branch to the POWERPC branch to my understanding.
Cheers // Matias
^ permalink raw reply
* Re: Please pull linux-2.6-virtex.git
From: Josh Boyer @ 2008-01-11 13:09 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801090703m5f411795j890bfa714a128b1e@mail.gmail.com>
On Wed, 9 Jan 2008 08:03:31 -0700
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> Gah; teach me to pick up patches right before bed. I shouldn't have
> picked up the ulite console changes patch just yet. I've dropped it
> from the series until I have a chance to rework it. Sorry.
>
> Here's the new pull request
>
> The following changes since commit 4f43143f9fbbb679c38d2ff99e44d3aaa00d0fe1:
> Paul Mackerras (1):
> Merge branch 'for-2.6.25' of git://git.kernel.org/.../olof/pasemi
>
> are available in the git repository at:
>
> git://git.secretlab.ca/git/linux-2.6-virtex.git virtex-for-2.6.25
>
> Stephen Neuendorffer (5):
> [POWERPC] Xilinx: update compatible list for interrupt controller
> [POWERPC] Xilinx: Add correct compatible list for device tree
> bus bindings.
> [POWERPC] Xilinx: Update booting-without-of.
> [POWERPC] Xilinx: updated device tree compatibility to match
> uboot bsp generator.
> [POWERPC] Xilinx uartlite: Section type fixups
Pulled and pushed out. I'll ask Paul to pull after I finish chasing
the Warp patches Sean is working on, and the RTC patch from David.
josh
^ permalink raw reply
* Re: Linux for ml310
From: Enno Lübbers @ 2008-01-11 11:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi Joachim,
I haven't tried the XUP or the ML310 yet, but I just managed to get
Linux 2.4.26 from Bitkeeper running on a ML403 board (a Virtex-4FX12).
However, I'm seriously considering moving to the 2.6 kernel, for
various reasons.
Your problems seem to be related to the BSP configuration. Have you
set the corerct options in the Software Platform Settings of the EDK?
In particular, you need to set the clock frequency and the attached
peripherals in the "OS and Libraries" section.
Regards
- Enno
--
Dipl.-Ing. Enno Luebbers
Computer Science Department
University of Paderborn
Warburger Str. 100
33098 Paderborn
http://wwwcs.upb.de/cs/ag-platzner
phone: 05251 / 60-5397
fax: 05251 / 60-5377
^ permalink raw reply
* Re: [PATCH 1/5] Warp Base Platform
From: Stephen Rothwell @ 2008-01-11 10:02 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <47871675.6030602@pikatech.com>
[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]
Hi Sean,
On Fri, 11 Jan 2008 02:10:45 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
> Stephen Rothwell wrote:
> > On Wed, 09 Jan 2008 15:19:13 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
> >
> >> No comments? I really thought I would get raked over the coals for this one.
> >
> > Ah ha! A challenge! :-)
> >
> I hoped somebody would respond to that ;)
Glad to oblige.
> >> +static int pika_dtm_thread(void *fpga)
> >> +{
> >> + extern int ad7414_get_temp(int index);
> >
> > no externs in C code - put it in a header file.
>
> I didn't know where to put this extern. It is fairly specific to this
> driver, although a generic function... if that makes sense. It returns
> the exact contents of the register rather than doing any conversion.
>
> Any recommendations for a location gladly accepted.
I don't where that function is actually defined - I assume it is in one
of the other recent patch sets.
/me searches ...
/me reads "ad7414 driver" email ...
/me notes spaces missing there as well :-)
Tricky. You have something that can only be built in (pika_dtm_thread in
warp.c) calling something that might be a module ... I think you need to
think of a new way of organizing these pieces.
While I am looking, the return type of ioremap is "void __iomem *", so
you need to annotate your "fpga" variable appropriately and the parameter
to pika_dtm_thread.
> And below has all the above mentioned fixes, except the extern.
You seem to have forgotten some of the spaces after "if"s, "switch"s and
"while"s.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH, ppc64] improve dedotify()
From: Jan Beulich @ 2008-01-11 9:13 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
This completely untested patch is intended to be a suggestion only:
Code inspection for an entirely different purpose made me stumble
across this, and I think that modifying the string table of an ELF
object is a bad idea, since there's nothing disallowing a linker to
merge strings inside the table, which would result in this code
possibly, but unintentionally screwing up other symbol names.
Besides that, the presented alternative is both smaller and faster.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
---
arch/powerpc/kernel/module_64.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
--- linux-2.6.24-rc7/arch/powerpc/kernel/module_64.c 2007-02-04 =
19:44:54.000000000 +0100
+++ 2.6.24-rc7-ppc64-dedotify/arch/powerpc/kernel/module_64.c 2008-01-08 =
13:32:33.000000000 +0100
@@ -154,16 +154,14 @@ static void dedotify_versions(struct mod
}
=20
/* Undefined symbols which refer to .funcname, hack to funcname */
-static void dedotify(Elf64_Sym *syms, unsigned int numsyms, char *strtab)
+static void dedotify(Elf64_Sym *syms, unsigned int numsyms, const char =
*strtab)
{
unsigned int i;
=20
for (i =3D 1; i < numsyms; i++) {
- if (syms[i].st_shndx =3D=3D SHN_UNDEF) {
- char *name =3D strtab + syms[i].st_name;
- if (name[0] =3D=3D '.')
- memmove(name, name+1, strlen(name));
- }
+ if (syms[i].st_shndx =3D=3D SHN_UNDEF
+ && strtab[syms[i].st_name] =3D=3D '.')
+ syms[i].st_name++;
}
}
=20
^ permalink raw reply
* Re: [PATCH] ps3: vuart: semaphore to mutex
From: Daniel Walker @ 2008-01-11 9:17 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, mingo
In-Reply-To: <Pine.LNX.4.64.0801110919500.10759@vixen.sonytel.be>
On Fri, 2008-01-11 at 09:20 +0100, Geert Uytterhoeven wrote:
> On Thu, 10 Jan 2008, Daniel Walker wrote:
> > This probe_mutex conforms to the new struct mutex type.
> > This patch converts it from the old semaphore to the new struct mutex.
>
> The PS3 tree already has this change.
>
> With kind regards,
Ok, thanks..
Daniel
^ permalink raw reply
* Re: PCI Failed to allocate mem for PCI ROM
From: Jiri Slaby @ 2008-01-11 9:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: Greg KH, linux-pci, LKML, linuxppc-dev list
In-Reply-To: <0119CD93-D9F1-42E0-9F6A-A50B2C63B19D@kernel.crashing.org>
On 01/11/2008 10:07 AM, Kumar Gala wrote:
>
> On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote:
>
>> On 01/11/2008 09:29 AM, Kumar Gala wrote:
>>> Greg,
>>> I'm getting the following message from the kernel on an embedded
>>> ppc32 system:
>>> PCI: Failed to allocate mem resource #9:100000@e0000000 for 0000:00:00.0
>>> The HW setup is a PCIe host controller and an e1000 NIC card. It
>>> appears that pci_bus_assign_resources() is trying to call
>>> pci_assign_resource() for the ROM and the resource for the ROM is
>>> [100000:1fffff] where the PHB is [c0000000:dfffffff].
>>> It seems like the resno that pci_assign_resource is getting called
>>> with is wrong and thus pci_update_resource() doesn't get called.
>>> any ideas?
>>
>> Kernel version, please.
>
> Sorry, its 2.6.24-rc7 + some ppc patches queued for 2.6.25
Could you try this patch?
http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob_plain;f=pci/pci-remove-default-pci-expansion-rom-memory-allocation.patch
Greg: is this 2.6.25 material, please? We need this for SP2.
thanks,
--
Jiri Slaby
Faculty of Informatics, Masaryk University
Suse Labs
^ permalink raw reply
* Re: PCI Failed to allocate mem for PCI ROM
From: Kumar Gala @ 2008-01-11 9:07 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Greg KH, linux-pci, LKML, linuxppc-dev list
In-Reply-To: <47872BC8.2040204@gmail.com>
On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote:
> On 01/11/2008 09:29 AM, Kumar Gala wrote:
>> Greg,
>> I'm getting the following message from the kernel on an embedded
>> ppc32 system:
>> PCI: Failed to allocate mem resource #9:100000@e0000000 for
>> 0000:00:00.0
>> The HW setup is a PCIe host controller and an e1000 NIC card. It
>> appears that pci_bus_assign_resources() is trying to call
>> pci_assign_resource() for the ROM and the resource for the ROM is
>> [100000:1fffff] where the PHB is [c0000000:dfffffff].
>> It seems like the resno that pci_assign_resource is getting called
>> with is wrong and thus pci_update_resource() doesn't get called.
>> any ideas?
>
> Kernel version, please.
Sorry, its 2.6.24-rc7 + some ppc patches queued for 2.6.25
- k
^ permalink raw reply
* Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
From: Jean Delvare @ 2008-01-11 8:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20071220044136.20091.70984.stgit@terra.home>
Hi Jon,
On Wed, 19 Dec 2007 23:41:36 -0500, Jon Smirl wrote:
> Since copying i2c-mpc.c to maintain support for the ppc architecture seems to be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to support both the ppc and powerpc architecture. When ppc is deleted in six months these #ifdefs will need to be removed.
>
> Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in.
>
> The follow on patch to module-init-tools is also needed since the i2c subsystem has never implemented dynamic loading.
>
> The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing.
Now that I have read all the previous versions of this patch series
and, more importantly, all objections that were raised on the way, I
can start reviewing the latest iteration of your patches. I'll also do
some testing, although I have no powerpc stuff here, but at least I
want to make sure that there are no regressions introduced by your
patches on x86.
--
Jean Delvare
^ permalink raw reply
* Re: 2.6.22-ppc8xx fec.c bugs
From: raul.moreno @ 2008-01-11 8:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <47865A80.7050205@freescale.com>
>>raul.moreno@telvent.abengoa.com wrote:
>> Hello everyone,
>>
>> I don't know who the maintainer of the FEC (Fast Ethernet Controller=
) in
>> the ppc8xx achitecture is, so I am writing this email here.
>arch/ppc is deprecated, and arch/ppc/8xx_io especially so.
>Please use drivers/net/fs_enet (and also note that arch/ppc will be
>going away in a few months).
I didn't know ppc was deprecated. Why is it so? Could you tell me where=
can
I read anything about this issue?
I have been using this architecture since I started with Linux (not too=
long ago) because I manage a mpc866 processor.
Do you mean that I should port to arch/powerpc?
>> I've seen that some bugs were fixed in the latest kernel but others
haven't
>> been addressed (possibly undetected yet). The following is a diff wi=
th
>> corrections I made to the 2.6.22 'fec.c' file (currently seems to wo=
rk
>> fine).
>Please post patches against the latest head-of-tree, and in unified di=
ff
>format (diff -u).
I'll do it in this way for next patches.
Ra=FAl
=
^ permalink raw reply
* Re: PCI Failed to allocate mem for PCI ROM
From: Jiri Slaby @ 2008-01-11 8:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: Greg KH, linux-pci, LKML, linuxppc-dev list
In-Reply-To: <1B75C5A8-E512-40CB-A6F3-351640701D0D@kernel.crashing.org>
On 01/11/2008 09:29 AM, Kumar Gala wrote:
> Greg,
>
> I'm getting the following message from the kernel on an embedded ppc32
> system:
>
> PCI: Failed to allocate mem resource #9:100000@e0000000 for 0000:00:00.0
>
> The HW setup is a PCIe host controller and an e1000 NIC card. It
> appears that pci_bus_assign_resources() is trying to call
> pci_assign_resource() for the ROM and the resource for the ROM is
> [100000:1fffff] where the PHB is [c0000000:dfffffff].
>
> It seems like the resno that pci_assign_resource is getting called with
> is wrong and thus pci_update_resource() doesn't get called.
>
> any ideas?
Kernel version, please.
^ permalink raw reply
* PCI Failed to allocate mem for PCI ROM
From: Kumar Gala @ 2008-01-11 8:29 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev list, linux-pci, LKML
Greg,
I'm getting the following message from the kernel on an embedded ppc32
system:
PCI: Failed to allocate mem resource #9:100000@e0000000 for 0000:00:00.0
The HW setup is a PCIe host controller and an e1000 NIC card. It
appears that pci_bus_assign_resources() is trying to call
pci_assign_resource() for the ROM and the resource for the ROM is
[100000:1fffff] where the PHB is [c0000000:dfffffff].
It seems like the resno that pci_assign_resource is getting called
with is wrong and thus pci_update_resource() doesn't get called.
any ideas?
- k
^ permalink raw reply
* Re: [PATCH] ps3: vuart: semaphore to mutex
From: Geert Uytterhoeven @ 2008-01-11 8:20 UTC (permalink / raw)
To: Daniel Walker; +Cc: linuxppc-dev, mingo
In-Reply-To: <20080111042137.378247237@mvista.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 803 bytes --]
On Thu, 10 Jan 2008, Daniel Walker wrote:
> This probe_mutex conforms to the new struct mutex type.
> This patch converts it from the old semaphore to the new struct mutex.
The PS3 tree already has this change.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 1/5] Warp Base Platform
From: Sean MacLennan @ 2008-01-11 7:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080111174259.b749f1f0.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Wed, 09 Jan 2008 15:19:13 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
>> I have split up the patches slightly differently based on Josh's comments.
>>
>> The first patch is basically the platform/44x files.
>>
>> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
>>
>
>
>> No comments? I really thought I would get raked over the coals for this one.
>>
>
> Ah ha! A challenge! :-)
>
I hoped somebody would respond to that ;)
>
>> +static int pika_dtm_thread(void *fpga)
>> +{
>> + extern int ad7414_get_temp(int index);
>>
>
> no externs in C code - put it in a header file.
>
I didn't know where to put this extern. It is fairly specific to this
driver, although a generic function... if that makes sense. It returns
the exact contents of the register rather than doing any conversion.
Any recommendations for a location gladly accepted.
And if anybody is wondering, the NAND code *does* work. It is commented
out because it requires u-boot 1.3.0 and most of the tacos have an
earlier u-boot. This is just a short term hack while we switch everybody
over to the new kernel.
And below has all the above mentioned fixes, except the extern.
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED && (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x && !CPM2 && !8xx && !PPC_83xx \
&& !PPC_85xx && !PPC_86xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool "PIKA Warp"
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
+ Telephony Developers" link for more information.
+
#config LUAN
# bool "Luan"
# depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..c1733c0 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_BAMBOO) += bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
+obj-$(CONFIG_WARP) += warp.o
--- /dev/null 2005-11-20 22:22:37.000000000 -0500
+++ arch/powerpc/platforms/44x/warp.c 2008-01-11 02:08:20.000000000 -0500
@@ -0,0 +1,244 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include <linux/init.h>
+#include <linux/of_platform.h>
+#include <linux/kthread.h>
+
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+
+#include "44x.h"
+
+#define WARP_GPIO_BASE 0xEF600B00ULL
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "pika,warp"))
+ return 0;
+
+ return 1;
+}
+
+define_machine(warp) {
+ .name = "Warp",
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void *gpio_base = NULL;
+ unsigned leds;
+
+ if (gpio_base == NULL) {
+ gpio_base = ioremap(WARP_GPIO_BASE, 0x148);
+ if (gpio_base == NULL) {
+ printk("ERROR: Unable to remap GPIO base.\n");
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
+
+ switch(green) {
+ case 0: leds &= ~0x80; break;
+ case 1: leds |= 0x80; break;
+ }
+ switch(red) {
+ case 0: leds &= ~0x40; break;
+ case 1: leds |= 0x40; break;
+ }
+
+ writel(leds, gpio_base + 0x100);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+static int pika_dtm_thread(void *fpga)
+{
+ extern int ad7414_get_temp(int index);
+
+ while(!kthread_should_stop()) {
+ int temp = ad7414_get_temp(0);
+
+ out_be32(fpga, temp);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+ return 0;
+}
+
+
+static int __devinit warp_fpga_init(void)
+{
+ struct device_node *np;
+ void *fpga;
+ int irq;
+ struct resource res;
+ struct task_struct *dtm_thread;
+
+ np = of_find_compatible_node(NULL, NULL, "pika,fpga");
+ if (np == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find fpga\n");
+ return -ENOENT;
+ }
+
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
+ return -EBUSY;
+ }
+
+ /* We do not call of_iomap here since it would map in the entire
+ * fpga space, which is over 8k.
+ */
+ if (of_address_to_resource(np, 0, &res)) {
+ printk(KERN_ERR __FILE__ ": Unable to get FPGA address\n");
+ return -ENOENT;
+ }
+ fpga = ioremap(res.start, 0x24);
+ if(fpga == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to map FPGA\n");
+ return -ENOENT;
+ }
+
+ /* Turn off the line LEDs */
+ out_be32(fpga + 8, 0);
+
+ dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, "pika-dtm");
+ if (IS_ERR(dtm_thread)) {
+ iounmap(fpga);
+ printk(KERN_ERR __FILE__ ": Unable to start PIKA DTM thread\n");
+ return PTR_ERR(dtm_thread);
+ }
+
+ return 0;
+}
+device_initcall(warp_fpga_init);
+
+// SAM not yet #define NAND_FLASH
+#ifdef NAND_FLASH
+/* --- All of this code is for the NAND flash */
+
+#include <linux/platform_device.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/ndfc.h>
+
+
+#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
+
+#define WARP_NAND_FLASH_REG_ADDR 0xD0000000UL
+#define WARP_NAND_FLASH_REG_SIZE 0x2000
+
+static struct resource warp_ndfc = {
+ .start = WARP_NAND_FLASH_REG_ADDR,
+ .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct mtd_partition nand_parts[] = {
+ {
+ .name = "nand",
+ .offset = 0,
+ .size = MTDPART_SIZ_FULL,
+ }
+};
+
+struct ndfc_controller_settings warp_ndfc_settings = {
+ .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1),
+ .ndfc_erpn = 0,
+};
+
+static struct ndfc_chip_settings warp_chip0_settings = {
+ .bank_settings = 0x80002222,
+};
+
+struct platform_nand_ctrl warp_nand_ctrl = {
+ .priv = &warp_ndfc_settings,
+};
+
+static struct platform_device warp_ndfc_device = {
+ .name = "ndfc-nand",
+ .id = 0,
+ .dev = {
+ .platform_data = &warp_nand_ctrl,
+ },
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+};
+
+static struct nand_ecclayout nand_oob_16 = {
+ .eccbytes = 3,
+ .eccpos = { 0, 1, 2, 3, 6, 7 },
+ .oobfree = { {.offset = 8, .length = 16} }
+};
+
+static struct platform_nand_chip warp_nand_chip0 = {
+ .nr_chips = 1,
+ .chip_offset = CS_NAND_0,
+ .nr_partitions = ARRAY_SIZE(nand_parts),
+ .partitions = nand_parts,
+ .chip_delay = 50,
+ .ecclayout = &nand_oob_16,
+ .priv = &warp_chip0_settings,
+};
+
+static struct platform_device warp_nand_device = {
+ .name = "ndfc-chip",
+ .id = 0,
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+ .dev = {
+ .platform_data = &warp_nand_chip0,
+ .parent = &warp_ndfc_device.dev,
+ }
+};
+
+static int warp_setup_flash(void)
+{
+ platform_device_register(&warp_ndfc_device);
+ platform_device_register(&warp_nand_device);
+
+ return 0;
+}
+device_initcall(warp_setup_flash);
+
+#endif /* NAND_FLASH */
^ permalink raw reply related
* Re: [PATCH 1/5] Warp Base Platform
From: Stephen Rothwell @ 2008-01-11 6:42 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <47852C41.8000506@pikatech.com>
[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]
On Wed, 09 Jan 2008 15:19:13 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
> I have split up the patches slightly differently based on Josh's comments.
>
> The first patch is basically the platform/44x files.
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> No comments? I really thought I would get raked over the coals for this one.
Ah ha! A challenge! :-)
> +++ arch/powerpc/platforms/44x/warp.c 2008-01-08 17:59:48.000000000 -0500
> +void warp_set_power_leds(int green, int red)
> +{
> + static void *gpio_base = NULL;
> + unsigned leds;
> +
> + if(gpio_base == NULL) {
^
space, please
> + if((gpio_base = ioremap(WARP_GPIO_BASE, 0x148)) == NULL) {
and again. Also split the assignment from the test.
> + printk("ERROR: Unable to remap GPIO base.\n");
> + return;
> + }
> + }
> +
> + leds = readl(gpio_base + 0x100);
> +
> + switch(green) {
space
> + case 0: leds &= ~0x80; break;
> + case 1: leds |= 0x80; break;
> + }
> + switch(red) {
again
> + case 0: leds &= ~0x40; break;
> + case 1: leds |= 0x40; break;
> + }
> +
> + writel(leds, gpio_base + 0x100);
> +}
> +EXPORT_SYMBOL(warp_set_power_leds);
> +
> +
> +static int pika_dtm_thread(void *fpga)
> +{
> + extern int ad7414_get_temp(int index);
no externs in C code - put it in a header file.
> +
> + while(!kthread_should_stop()) {
space
> +static int __devinit warp_fpga_init(void)
> +{
> + struct device_node *np;
> + void *fpga;
> + int irq;
> + struct resource res;
> + struct task_struct *dtm_thread;
> +
> + if((np = of_find_compatible_node(NULL, NULL, "pika,fpga")) == NULL) {
space and split the assignment from the test.
> + printk(KERN_ERR __FILE__ ": Unable to find fpga\n");
> + return -ENOENT;
> + }
> +
> + if((irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
again
> + printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
> + return -EBUSY;
> + }
> +
> + /* We do not call of_iomap here since it would map in the entire
> + * fpga space, which is over 8k.
> + */
> + if(of_address_to_resource(np, 0, &res) ||
> + (fpga = ioremap(res.start, 0x24)) == NULL) {
and again
> + printk(KERN_ERR __FILE__ ": Unable to map FPGA\n");
> + return -ENOENT;
> + }
> +
> + /* Turn off the line LEDs */
> + out_be32(fpga + 8, 0);
> +
> + dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, "pika-dtm");
> +
> + if(IS_ERR(dtm_thread)) {
space
enough? :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Is it required to develope new hub class driver for MPC8272 in Montavista ?
From: Smily santhosh @ 2008-01-11 6:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi Friends,
I have few queries ,
before that let me give details
Kernel : 2.6.10_mvl401-8272ads - Montavista - MPC8272,
USB HUB controller : ISP1520BD (Externally Connected - 1- Up Stream port
and 4- Down Stream ports ).
I am familiar with mass storage driver.
In kernel source code (drivers/usb/core/hub), huc.c is present which does
core functionality of hub. And ISP1520 descriptors says it is Class specific
driver not Vendor specific one. So i hope i can use same source hub.c file.
Am i need to develope any specific driver for it ? (Hope: No) .
Any thing else i need to do ? Currently i am going through the code(hub.c).
What are the possible test cases to validate hub connection and hub working
?
Any response from you appreciated ?
Santhosh
Sharing the knowledge .. always makes you good. :-)
--
View this message in context: http://www.nabble.com/Is-it-required-to-develope-new-hub-class-driver-for-MPC8272-in-Montavista---tp14750580p14750580.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Enable RTC for Ebony and Walnut (v2)
From: Stephen Rothwell @ 2008-01-11 6:29 UTC (permalink / raw)
To: David Gibson; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20080111032534.GA25055@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
On Fri, 11 Jan 2008 14:25:34 +1100 David Gibson <dwg@au1.ibm.com> wrote:
>
> +++ working-2.6/arch/powerpc/sysdev/of_rtc.c 2008-01-11 14:17:03.000000000 +1100
> +static __initdata struct {
> + const char *compatible;
If you make this an array, then the string will become __initdata as well.
> + char *plat_name;
> +} of_rtc_table[] = {
> + { "ds1743-nvram", "rtc-ds1742" },
> +};
> + platform_device_register_simple(plat_name, -1, res, 1);
Do we care if this fails?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] Warp Base Platform
From: Sean MacLennan @ 2008-01-11 6:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47852C41.8000506@pikatech.com>
No comments? I really thought I would get raked over the coals for this one.
Cheers,
Sean
^ permalink raw reply
* Re: ibm4xx_quiesce_eth?
From: Sean MacLennan @ 2008-01-11 6:19 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801110715.00058.sr@denx.de>
Stefan Roese wrote:
>> There are firmwares that do not reset the EMAC and MAL before passing
>> control to the client program (Linux in our case). This can cause
>> weird things to happen, like spurious interrupts or DMAs from the
>> hardware overwriting kernel memory. So we quiesce the hardware really
>> early on those.
>>
>> I don't believe U-Boot has that problem. If it does, it should be
>> fixed :)
>>
>
> No, U-Boot doesn't have this problem.
>
> Best regards,
> Stefan
>
Thanks for the confirmation! One less thing to worry about.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 3/5] Warp Base Platform
From: Sean MacLennan @ 2008-01-11 6:17 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <4786B295.3000501@pikatech.com>
Update based on fixes to warp.dts.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..cd83c4f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,7 +62,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c \
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c
+ cuboot-katmai.c cuboot-rainier.c cuboot-warp.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -206,6 +206,7 @@ image-$(CONFIG_RAINIER) += cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN) += cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
+image-$(CONFIG_WARP) += cuImage.warp
endif
# For 32-bit powermacs, build the COFF and miboot images
--- /dev/null 2005-11-20 22:22:37.000000000 -0500
+++ arch/powerpc/boot/cuboot-warp.c 2008-01-11 01:08:54.000000000 -0500
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "4xx.h"
+#include "cuboot.h"
+
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+static void warp_fixups(void)
+{
+ unsigned long sysclk = 66000000;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
+ ibm4xx_sdram_fixup_memsize();
+ ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
+ dt_fixup_mac_addresses(&bd.bi_enetaddr);
+}
+
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+
+ platform_ops.fixups = warp_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
^ permalink raw reply related
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