* Re: [GIT]: Make LMB code sharable with sparc64.
From: Sam Ravnborg @ 2008-02-13 8:57 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213.004120.22092044.davem@davemloft.net>
On Wed, Feb 13, 2008 at 12:41:20AM -0800, David Miller wrote:
>
> As I mentioned to a few ppc folks at LCA08 I plan to use
> the LMB code from powerpc as a basis for NUMA support on
> sparc64.
>
> There are two changes.
>
> 1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
> interface bits in include/linux/lmb.h, put arch-specific
> bits in asm/lmb.h and add Kconfig machinery to build this
> stuff on sparc64.
>
> 2) Fix a bug in lmb_alloc() wherein the size was not aligned
> so we could easily run out of reserve blocks because
> every aligned allocation would create a tiny hole, and
> secondly the lmb_reserve() call there did not have it's
> return value checked.
>
> Powerpc folks, if there are no objections please pull, thanks!
>
> The following changes since commit 96b5a46e2a72dc1829370c87053e0cd558d58bc0:
> Linus Torvalds (1):
> WMI: initialize wmi_blocks.list even if ACPI is disabled
>
> are available in the git repository at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git master
Review had been easier if the patch was inlined.
Took a quick look at the small Kconfig bits.
>From arch/sparc64/Kconfig:
+config LMB
+ def_bool y
+
Can we plase have this changed to use:
config SPARC64
+ select HAVE_LMB
And then in lib/Kconfig have
+config HAVE_LMB
+ bool
So we avoid creating a new variable each time we introdce LMB support.
You would need to update powerpc Kconfig too of course.
This way of doing it is documented in:
Documenation/kbuild/kconfig.language.txt
Thanks,
Sam
^ permalink raw reply
* [GIT]: Make LMB code sharable with sparc64.
From: David Miller @ 2008-02-13 8:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sparclinux, linux-kernel
As I mentioned to a few ppc folks at LCA08 I plan to use
the LMB code from powerpc as a basis for NUMA support on
sparc64.
There are two changes.
1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
interface bits in include/linux/lmb.h, put arch-specific
bits in asm/lmb.h and add Kconfig machinery to build this
stuff on sparc64.
2) Fix a bug in lmb_alloc() wherein the size was not aligned
so we could easily run out of reserve blocks because
every aligned allocation would create a tiny hole, and
secondly the lmb_reserve() call there did not have it's
return value checked.
Powerpc folks, if there are no objections please pull, thanks!
The following changes since commit 96b5a46e2a72dc1829370c87053e0cd558d58bc0:
Linus Torvalds (1):
WMI: initialize wmi_blocks.list even if ACPI is disabled
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git master
David S. Miller (2):
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
[LMB]: Fix bug in __lmb_alloc_base().
arch/powerpc/Kconfig | 3 +
arch/powerpc/kernel/btext.c | 2 +-
arch/powerpc/kernel/crash.c | 2 +-
arch/powerpc/kernel/crash_dump.c | 2 +-
arch/powerpc/kernel/machine_kexec.c | 2 +-
arch/powerpc/kernel/prom.c | 2 +-
arch/powerpc/kernel/rtas.c | 2 +-
arch/powerpc/kernel/setup-common.c | 2 +-
arch/powerpc/kernel/setup_64.c | 2 +-
arch/powerpc/kernel/vdso.c | 2 +-
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/hash_utils_64.c | 2 +-
arch/powerpc/mm/init_32.c | 2 +-
arch/powerpc/mm/init_64.c | 2 +-
arch/powerpc/mm/mem.c | 2 +-
arch/powerpc/mm/numa.c | 2 +-
arch/powerpc/mm/ppc_mmu_32.c | 2 +-
arch/powerpc/mm/stab.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 2 +-
arch/powerpc/platforms/maple/setup.c | 2 +-
arch/powerpc/platforms/powermac/setup.c | 2 +-
arch/powerpc/platforms/ps3/htab.c | 2 +-
arch/powerpc/platforms/ps3/mm.c | 2 +-
arch/powerpc/platforms/ps3/os-area.c | 2 +-
arch/powerpc/sysdev/dart_iommu.c | 2 +-
arch/sparc64/Kconfig | 3 +
include/asm-powerpc/abs_addr.h | 2 +-
include/asm-powerpc/lmb.h | 82 +++---------------------------
include/asm-sparc64/lmb.h | 10 ++++
include/linux/lmb.h | 83 +++++++++++++++++++++++++++++++
lib/Makefile | 2 +
{arch/powerpc/mm => lib}/lmb.c | 39 ++++++++-------
32 files changed, 155 insertions(+), 117 deletions(-)
create mode 100644 include/asm-sparc64/lmb.h
create mode 100644 include/linux/lmb.h
rename {arch/powerpc/mm => lib}/lmb.c (92%)
^ permalink raw reply
* TEMAC on Virtex FX12: device occupation
From: llandre @ 2008-02-13 8:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'd like to hear some opinions about this post by Massimiliano:
http://article.gmane.org/gmane.linux.ports.ppc.embedded/17568
The results he got are quite impressive. It seems that everybody here
can hardly fit a design with just one hard TEMAC in FX12 while he was
able to fit two! Unfortunately Massimiliano did not say precisely how he
did it. I'd like to hear someone from Xilinx sharing his/her opinion
about this outstanding result. Maybe he used 3rd-party synthesizer or he
discovered some magical command-line parameters for Xilinx synthesizer ...
Any comment will be appreciated.
Regards,
llandre
DAVE Electronics System House - R&D Department
web: http://www.dave.eu
email: r&d2@dave-tech.it
^ permalink raw reply
* Quit the mailling list
From: 조은상 @ 2008-02-13 7:30 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
Thanks for help
Please Let me quit the list
Thank you
[-- Attachment #2: Type: text/html, Size: 301 bytes --]
^ permalink raw reply
* Re: [PATCH 09/18] ide: rework PowerMac media-bay support
From: Michael Ellerman @ 2008-02-13 7:29 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004523.17746.24578.sendpatchset@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]
On Fri, 2008-02-08 at 01:45 +0100, Bartlomiej Zolnierkiewicz wrote:
> Rework PowerMac media-bay support in such way that instead of
> un/registering the IDE interface we un/register IDE devices:
>
> * Add ide_port_scan() helper for probing+registerering devices on a port.
>
> * Rename ide_port_unregister_devices() to __ide_port_unregister_devices().
>
> * Add ide_port_unregister_devices() helper for unregistering devices on a port.
>
> * Add 'ide_hwif_t *cd_port' to 'struct media_bay_info', pass 'hwif' instead
> of hwif->index to media_bay_set_ide_infos() and use it to setup 'cd_port'.
>
> * Use ide_port_unregister_devices() instead of ide_unregister()
> and ide_port_scan() instead of ide_register_hw() in media_bay_step().
>
> * Unexport ide_register_hw() and make it static.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
> drivers/ide/ide-probe.c | 18 ++++++++++++++++++
> drivers/ide/ide.c | 22 ++++++++++++++++------
> drivers/ide/ppc/pmac.c | 3 ++-
> drivers/macintosh/mediabay.c | 17 +++++++----------
> include/asm-powerpc/mediabay.h | 4 +++-
> include/linux/ide.h | 6 ++----
> 6 files changed, 48 insertions(+), 22 deletions(-)
> Index: b/include/asm-powerpc/mediabay.h
> ===================================================================
> --- a/include/asm-powerpc/mediabay.h
> +++ b/include/asm-powerpc/mediabay.h
> @@ -22,10 +22,12 @@ int check_media_bay(struct device_node *
> /* Number of bays in the machine or 0 */
> extern int media_bay_count;
>
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC
> int check_media_bay_by_base(unsigned long base, int what);
> /* called by IDE PMAC host driver to register IDE controller for media bay */
> int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
> - int irq, int index);
> + int irq, ide_hwif_t *hwif);
> +#endif
>
> #endif /* __KERNEL__ */
> #endif /* _PPC_MEDIABAY_H */
This hunk breaks pmac32_defconfig for me.
include2/asm/mediabay.h:29: error: syntax error before 'ide_hwif_t'
make[3]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
make[2]: *** [arch/powerpc/platforms/powermac] Error 2
make[1]: *** [arch/powerpc/platforms] Error 2
make: *** [sub-make] Error 2
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] FIx compile of swim3 as module
From: Benjamin Herrenschmidt @ 2008-02-13 6:03 UTC (permalink / raw)
To: Josh Boyer
Cc: Bartlomiej Zolnierkiewicz, kyle, LinuxPPC-dev, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <20080212204802.18a7a868@zod.rchland.ibm.com>
On Tue, 2008-02-12 at 20:48 -0600, Josh Boyer wrote:
> > The current pmac32_defconfig fails to build with the following
> error:
> >
> > Building modules, stage 2.
> > ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
> > WARNING: modpost: Found 23 section mismatch(es).
> > To see full details build your kernel with:
> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> > make[2]: *** [__modpost] Error 1
> >
> > This patch fixes that.
>
> Kyle posted a slightly different patch that seemed to still keep
> the original intention of ifdefery in tact. I've no idea which is
> better, but the three of you might want to compare notes.
Just remove the bloody ifdef's, they are just a useless pain.
Ben.
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Benjamin Herrenschmidt @ 2008-02-13 3:26 UTC (permalink / raw)
To: Tony Breeds
Cc: LinuxPPC-dev, Andrew Morton, Linus Torvalds,
Bartlomiej Zolnierkiewicz, Paul Mackerras
In-Reply-To: <20080213024019.GX6887@bakeyournoodle.com>
On Wed, 2008-02-13 at 13:40 +1100, Tony Breeds wrote:
> The current pmac32_defconfig fails to build with the following error:
>
> Building modules, stage 2.
> ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
> WARNING: modpost: Found 23 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[2]: *** [__modpost] Error 1
Bart, I told you I didn't want those ifdef's in mediabay ... they are
just cluttering things and causing trouble.
> This patch fixes that.
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> drivers/block/swim3.c | 4 ----
> drivers/macintosh/mediabay.c | 2 --
> 2 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
> index b4e462f..730ccea 100644
> --- a/drivers/block/swim3.c
> +++ b/drivers/block/swim3.c
> @@ -251,10 +251,6 @@ static int floppy_release(struct inode *inode, struct file *filp);
> static int floppy_check_change(struct gendisk *disk);
> static int floppy_revalidate(struct gendisk *disk);
>
> -#ifndef CONFIG_PMAC_MEDIABAY
> -#define check_media_bay(which, what) 1
> -#endif
> -
> static void swim3_select(struct floppy_state *fs, int sel)
> {
> struct swim3 __iomem *sw = fs->swim3;
> diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
> index 9367882..51a1128 100644
> --- a/drivers/macintosh/mediabay.c
> +++ b/drivers/macintosh/mediabay.c
> @@ -416,7 +416,6 @@ static void poll_media_bay(struct media_bay_info* bay)
> }
> }
>
> -#ifdef CONFIG_MAC_FLOPPY
> int check_media_bay(struct device_node *which_bay, int what)
> {
> int i;
> @@ -431,7 +430,6 @@ int check_media_bay(struct device_node *which_bay, int what)
> return -ENODEV;
> }
> EXPORT_SYMBOL(check_media_bay);
> -#endif /* CONFIG_MAC_FLOPPY */
>
> #ifdef CONFIG_BLK_DEV_IDE_PMAC
> int check_media_bay_by_base(unsigned long base, int what)
>
> Yours Tony
>
> linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
> Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Tony Breeds @ 2008-02-13 2:51 UTC (permalink / raw)
To: Josh Boyer
Cc: Bartlomiej Zolnierkiewicz, kyle, LinuxPPC-dev, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <20080212204802.18a7a868@zod.rchland.ibm.com>
On Tue, Feb 12, 2008 at 08:48:02PM -0600, Josh Boyer wrote:
> Kyle posted a slightly different patch that seemed to still keep
> the original intention of ifdefery in tact. I've no idea which is
> better, but the three of you might want to compare notes.
/me checks ....
Hmm Kyle's seem the leave the:
#ifndef CONFIG_PMAC_MEDIABAY
#define check_media_bay(which, what) 1
#endif
in swim3.c, which doesn't seem right.
But I'm easy as long as it gets fixed. :)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Josh Boyer @ 2008-02-13 2:48 UTC (permalink / raw)
To: Tony Breeds
Cc: Bartlomiej Zolnierkiewicz, kyle, LinuxPPC-dev, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <20080213024019.GX6887@bakeyournoodle.com>
On Wed, 13 Feb 2008 13:40:20 +1100
tony@bakeyournoodle.com (Tony Breeds) wrote:
> The current pmac32_defconfig fails to build with the following error:
>
> Building modules, stage 2.
> ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
> WARNING: modpost: Found 23 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[2]: *** [__modpost] Error 1
>
> This patch fixes that.
Kyle posted a slightly different patch that seemed to still keep
the original intention of ifdefery in tact. I've no idea which is
better, but the three of you might want to compare notes.
josh
^ permalink raw reply
* [PATCH] FIx compile of swim3 as module
From: Tony Breeds @ 2008-02-13 2:40 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds, LinuxPPC-dev
Cc: Paul Mackerras, Bartlomiej Zolnierkiewicz
The current pmac32_defconfig fails to build with the following error:
Building modules, stage 2.
ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
WARNING: modpost: Found 23 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[2]: *** [__modpost] Error 1
This patch fixes that.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
drivers/block/swim3.c | 4 ----
drivers/macintosh/mediabay.c | 2 --
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
index b4e462f..730ccea 100644
--- a/drivers/block/swim3.c
+++ b/drivers/block/swim3.c
@@ -251,10 +251,6 @@ static int floppy_release(struct inode *inode, struct file *filp);
static int floppy_check_change(struct gendisk *disk);
static int floppy_revalidate(struct gendisk *disk);
-#ifndef CONFIG_PMAC_MEDIABAY
-#define check_media_bay(which, what) 1
-#endif
-
static void swim3_select(struct floppy_state *fs, int sel)
{
struct swim3 __iomem *sw = fs->swim3;
diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index 9367882..51a1128 100644
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -416,7 +416,6 @@ static void poll_media_bay(struct media_bay_info* bay)
}
}
-#ifdef CONFIG_MAC_FLOPPY
int check_media_bay(struct device_node *which_bay, int what)
{
int i;
@@ -431,7 +430,6 @@ int check_media_bay(struct device_node *which_bay, int what)
return -ENODEV;
}
EXPORT_SYMBOL(check_media_bay);
-#endif /* CONFIG_MAC_FLOPPY */
#ifdef CONFIG_BLK_DEV_IDE_PMAC
int check_media_bay_by_base(unsigned long base, int what)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* RE: [Spam Mail] Re: populate_rootfs fail (This message should be blocked: bkdh372119)
From: jay_chen @ 2008-02-13 1:52 UTC (permalink / raw)
To: linuxppc-embedded-bounces+jay_chen=alphanetworks.com; +Cc: linuxppc-embedded
In-Reply-To: <47B19543.70808@coritel.it>
-----Original Message-----
From: linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org]
Sent: Tuesday, February 12, 2008 8:47 PM
To: jay_chen
Cc: linuxppc-embedded@ozlabs.org
Subject: [Spam Mail] Re: populate_rootfs fail (This message should be
blocked: bkdh372119)
jay_chen ha scritto:
> Hello all:
>
> I am using mpc8548, kernel 2.6.14.5, and uboot as boot loader.
> When I upgrade ram from 512MB to 2G, my kernel can't boot anymore.
> (I pass mem=2048M to kernel in uboot now)
>
> It always dies in exec sys_write( ) in populate_rootfs( ).
> I did more tests about this and I found that sys_write( ) could write
> only about 4MB in 2G ram case.
> (My initrd is about 19MB, initrd_start : 0xCE7C7000, initrd_end :
> 0xCFAAF289, initrd_end - initrd_start : 0x012E8289 ==> about 19MB)
> Could anybody give me some hints?
> Is this issue related to the location of "/initrd.image"? Could I
> control it?
> Is there any size limit in ppc arch about ramdisk/initrd?
>
> Thanks for help.
>
> Jay...
>
> void __init populate_rootfs(void)
> {
> char *err;
> ...
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start) {
> ...
> printk("it isn't (%s); looks like an initrd\n", err);
> fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
> if (fd >= 0) {
> sys_write(fd, (char *)initrd_start,
> initrd_end - initrd_start);
> sys_close(fd);
> free_initrd();
> }
> }
> #endif
> }
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
I think can be a problem with the u-boot initrd_high option. Have you been
enabled the highmem support to use 2G of ram, right? You can try to set this
option to 0x30000000.
Marco
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
0x30000000 doesn't work in my system, but 0x08000000 does.
I am not quiet understand the function of initrd_high and how to set it.
Since it may helps, I will try to figure out the whole story.
Thanks for your help.
Jay...
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-13 0:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B2300B.4060101@freescale.com>
On Feb 12, 2008 4:47 PM, Timur Tabi <timur@freescale.com> wrote:
> David Gibson wrote:
>
> > I can pretty much guarantee you that someone will find that
> > insufficient and want to expand the conditional representation. This
> > way madness lies.
>
> Then let them. We can have version numbers associated with the conditional
> expressions. If they want to make more complex condition expressions, they can
> bump the version number and define a spec and write code to parse it.
You say that as if bumping the version number is cheap to do.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-13 0:10 UTC (permalink / raw)
To: Timur Tabi, Grant Likely, linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080212233548.GE21230@localhost.localdomain>
On Feb 12, 2008 4:35 PM, David Gibson <david@gibson.dropbear.id.au> wrote:
> In fact, in one way of looking at it that's always what happens: the
> dtb format is defined for passing hardware information from the
> bootloader to the kernel; nothing else. Passing a dtb *into* the
> bootloader is just a bootloader implementation convenience, because
> the possible variations on an output tree are small, so it's useful to
> have a skeleton tree built-in. But in order for the bootloader to
> process those variations correctly, the skeleton *must* be in the
> right format. dtb input to a bootloader must match the bootloaders
> expectations. This has always been true, and will continue to be
> true.
Well said.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH rev2] powerpc: Marvell 64x60 EDAC platform devices setup
From: Dave Jiang @ 2008-02-13 0:11 UTC (permalink / raw)
To: paulus; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20080212105113.553659b0.sfr@canb.auug.org.au>
Creating platform devices (memory controller, sram error registers, cpu
error registers, PCI error registers) for Error Detection and Correction
(EDAC) driver.
The platform devices allow the mv64x60 EDAC driver to detect errors from
the memory controller (ECC erorrs), SRAM controller, CPU data path error
registers, and PCI error registers. The errors are reported to syslog.
Software ECC scrubbing is provided. These replace the mv64x60 error handlers
in the ppc branch. They are being moved to EDAC subsystem in order to
centralize error reporting.
The error reporting can be triggered via interrupts from the mv64x60 bridge
chip or via polling mechanism provided by the EDAC core code.
Signed-off-by: Dave Jiang <djiang@mvista.com>
Acked-by: Dale Farnsworth <dale@farnsworth.org>
---
Updated with changes from Stephen Rothwell
mv64x60_dev.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c
index efda002..21bb791 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -17,6 +17,7 @@
#include <linux/platform_device.h>
#include <asm/prom.h>
+#include <asm/io.h>
/*
* These functions provide the necessary setup for the mv64x60 drivers.
@@ -439,6 +440,63 @@ error:
return err;
}
+static int __init mv64x60_edac_pdev_init(struct device_node *np,
+ int id,
+ int num_addr,
+ const char *pdev_name)
+{
+ struct resource *r;
+ struct platform_device *pdev;
+ int i, ret;
+
+ r = kzalloc(num_addr * sizeof(*r) + sizeof(*r), GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+
+ for (i = 0; i < num_addr; i++) {
+ ret = of_address_to_resource(np, i, &r[i]);
+ if (ret) {
+ kfree(r);
+ return ret;
+ }
+ }
+
+ of_irq_to_resource(np, 0, &r[i]);
+
+ pdev = platform_device_register_simple(pdev_name, id, r, num_addr + 1);
+
+ kfree(r);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PCI
+/*
+ * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
+ * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
+ * well. IOW, don't set bit 0.
+ */
+#define MV64X60_PCIx_ERR_MASK_VAL 0x00a50c24
+
+/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
+static int __init mv64x60_pci_fixup(struct device_node *np)
+{
+ void __iomem *pci_serr;
+
+ pci_serr = of_iomap(np, 1);
+ if (!pci_serr)
+ return -ENOMEM;
+
+ out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
+ iounmap(pci_serr);
+
+ return 0;
+}
+#endif /* CONFIG_PCI */
+
static int __init mv64x60_device_setup(void)
{
struct device_node *np = NULL;
@@ -460,6 +518,36 @@ static int __init mv64x60_device_setup(void)
if ((err = mv64x60_i2c_device_setup(np, id++)))
goto error;
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-mem-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_mc_err")))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-cpu-error")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 2,
+ "mv64x60_cpu_err")))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-sram-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_sram_err")))
+ goto error;
+
+#ifdef CONFIG_PCI
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-pci-error") {
+ if ((err = mv64x60_pci_fixup(np)))
+ goto error;
+
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_pci_err")))
+ goto error;
+ }
+#endif
+
/* support up to one watchdog timer */
np = of_find_compatible_node(np, NULL, "marvell,mv64x60-wdt");
if (np) {
^ permalink raw reply related
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-13 0:08 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B2300B.4060101@freescale.com>
On Tue, Feb 12, 2008 at 05:47:23PM -0600, Timur Tabi wrote:
> David Gibson wrote:
>
> > I can pretty much guarantee you that someone will find that
> > insufficient and want to expand the conditional representation. This
> > way madness lies.
>
> Then let them. We can have version numbers associated with the conditional
> expressions. If they want to make more complex condition expressions, they can
> bump the version number and define a spec and write code to parse it.
>
> > No. As Grant says, that's not what the version number is for. It
> > represents the version of the encoding, not the content. If you must
> > version the content (which you should try really hard to avoid) the
> > correct way is to add versioning properties to the root node.
>
> And that's why I prefer updating the DTB format to allow attaching
> conditional expressions to nodes. This would then necessitate
> bumping the version number. Older U-Boots will reject this new DTB.
> We can also modify DTC to support conditional nodes, so that if a
> customer has an older U-Boot he can't update, he can use DTC to
> generate a V17 DTB that has the conditionals already processed.
Well, yes, folding conditionals into the format would mean a version
bump. But I am *not* going to put conditionals into a dtb version,
and I'm pretty sure BenH and Paulus would also reject this notion.
It's simply not what the format is for. dtbs are for parsing by the
kernel, giving a complete device representation. If bootloaders and
other things also find them a useful input format, that's great, but
I'm not going to significantly extend the semantics just to support
other uses.
Now, if you want to define a new binary-level "meta-dtb" format,
designed for representing various conditionals or whatnot, which can
be processed into a final true dtb, go for it. But a) if you base it
on the dtb format, make sure you use a different magic number so as
not to interfere with the actual dtbs version progression and b) I
think you'll find it's more trouble than it's worth, at least at this
stage (feel free to try to prove me wrong on this point, of course).
At present, I think the "meta-dtb" format which makes the most sense,
based on a balance between simplicity and flexibility is C, with one
or more dtb fragments embedded. This can be done now (though if there
are libfdt extensions which would make this usage easier, please
suggest them - fdt_graft() is an obvious one).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B22E98.8040900@freescale.com>
On Tue, Feb 12, 2008 at 05:41:12PM -0600, Timur Tabi wrote:
> David Gibson wrote:
>
> > I'm not sure I'm entirely happy about storing the fragments under a
> > special node - but certainly u-boot could do that if it wants. What
> > would certainly be ok is to store various fragments as separate blobs
> > and fold them together as necessary. Which reminds me, I meant to
> > implement a "graft" function in libfdt.
>
> Most likely, U-Boot would strip out the special node after
> processing it. The idea is for the boot loader to customize the
> device tree based before sending it to the kernel.
Of course. U-boot can use whatever representation it likes
internally, as long as it's all fixed up by the time it reaches the
kernel. I just think using sepa`rate "device tree fragment" blobs
might be a better way of doing it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 23:50 UTC (permalink / raw)
To: Timur Tabi, Grant Likely, linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080212233548.GE21230@localhost.localdomain>
David Gibson wrote:
> You don't. If your agent takes a dtb, dtb layout and agent must
> match.
So what I would like to see is a way for the agent to validate the dtb. U-Boot
could currently validate the SOC's compatible field. However, if we add a
special node that contains rules for modifying the rest of the tree, the only
possible way to block older, incompatible U-Boots from accepting the tree is to
bump the version number. Since that is not the right thing to do, the best
approach is to define a new node type that has conditional expression attached
to it. Then we can bump the version.
> In fact, in one way of looking at it that's always what happens: the
> dtb format is defined for passing hardware information from the
> bootloader to the kernel; nothing else. Passing a dtb *into* the
> bootloader is just a bootloader implementation convenience, because
> the possible variations on an output tree are small, so it's useful to
> have a skeleton tree built-in. But in order for the bootloader to
> process those variations correctly, the skeleton *must* be in the
> right format. dtb input to a bootloader must match the bootloaders
> expectations. This has always been true, and will continue to be
> true.
The problem with this approach is that you're replacing data with code, and that
always makes things more difficult.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 23:47 UTC (permalink / raw)
To: Timur Tabi, Grant Likely, linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080212232639.GD21230@localhost.localdomain>
David Gibson wrote:
> I can pretty much guarantee you that someone will find that
> insufficient and want to expand the conditional representation. This
> way madness lies.
Then let them. We can have version numbers associated with the conditional
expressions. If they want to make more complex condition expressions, they can
bump the version number and define a spec and write code to parse it.
> No. As Grant says, that's not what the version number is for. It
> represents the version of the encoding, not the content. If you must
> version the content (which you should try really hard to avoid) the
> correct way is to add versioning properties to the root node.
And that's why I prefer updating the DTB format to allow attaching conditional
expressions to nodes. This would then necessitate bumping the version number.
Older U-Boots will reject this new DTB. We can also modify DTC to support
conditional nodes, so that if a customer has an older U-Boot he can't update, he
can use DTC to generate a V17 DTB that has the conditionals already processed.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 23:41 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, Timur Tabi, linuxppc-dev
In-Reply-To: <20080212231702.GB21230@localhost.localdomain>
David Gibson wrote:
> I'm not sure I'm entirely happy about storing the fragments under a
> special node - but certainly u-boot could do that if it wants. What
> would certainly be ok is to store various fragments as separate blobs
> and fold them together as necessary. Which reminds me, I meant to
> implement a "graft" function in libfdt.
Most likely, U-Boot would strip out the special node after processing it. The
idea is for the boot loader to customize the device tree based before sending it
to the kernel.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:35 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B1F763.9000404@freescale.com>
On Tue, Feb 12, 2008 at 01:45:39PM -0600, Timur Tabi wrote:
> Grant Likely wrote:
[snip]
> > That's not a dtb version issue. That is a dtb content issue.
>
> Technically, that's true, but ...
>
> > It does
> > not warrant changing the dtb version number.
>
> Then how do you solve the problem of passing a device tree to a boot
> loader that does not know how to parse it properly? A device tree
> with these additional nodes *must* be parsed by a boot loader that
> is aware of them.
Correct. Just as you must give a dtb with the information to the
correct board to a bootloader or things won't work. Changing this is
not within the reasonable scope of what dtbs will do.
> Otherwise, it will pass the device tree as-is to
> the kernel without warning. This is a bad thing, and steps should
> be taken to prevent that. If you can think of a way to make this
> happen without changing the version number, I'd love to hear. All
> I'm hearing from you now is denial that this is a problem.
>
> >>> We've already got that issue. If you pass the device tree for the
> >>> wrong board it will still validate correctly, but the board is not
> >>> going to boot.
> >> There's nothing stopping U-Boot today from scanning the device tree and making
> >> sure the SOC's compatible node is correct. That's not currently done, but it
> >> could be.
> >
> > Fair enough, and it is also reasonable for the boot loader to look for
> > a specific property name to decide how to massage the data structure.
> > This alone does not require a dtb version change.
>
> Current versions of U-Boot do not know how to do this. So again,
> I'm asking you: how do you solve the problem of passing a device
> tree with additional nodes to a boot loader that does not know how
> to parse them properly? How do you prevent that old U-Boot from
> ignoring those nodes?
You don't. If your agent takes a dtb, dtb layout and agent must
match.
> > I'm not missing the point because I disagree entirely with the
> > addition of conditional expressions to the device tree. Instead, I
> > think properties can be added to the device tree that a bootloader can
> > look for and decide to apply conditions against them which means the
> > conditions are encoded in the boot loader, not the device tree. (the
> > device tree simply contains data which supports the boot loaders
> > decision; a rather different thing).
>
> Then why bother passing a DTB to the boot loader at all? Why not
> just have the boot loader create the device tree from scratch?
That's a perfectly acceptable option - and it's what I'd expect if a
real OF decided to add support for flattened device trees (which might
happen with ePAPR). libfdt's serial-write functions are designed for
exactly this use case.
In fact, in one way of looking at it that's always what happens: the
dtb format is defined for passing hardware information from the
bootloader to the kernel; nothing else. Passing a dtb *into* the
bootloader is just a bootloader implementation convenience, because
the possible variations on an output tree are small, so it's useful to
have a skeleton tree built-in. But in order for the bootloader to
process those variations correctly, the skeleton *must* be in the
right format. dtb input to a bootloader must match the bootloaders
expectations. This has always been true, and will continue to be
true.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:26 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B1EEA8.4040904@freescale.com>
[snip]
On Tue, Feb 12, 2008 at 01:08:24PM -0600, Timur Tabi wrote:
> Grant Likely wrote:
> > On Feb 12, 2008 8:44 AM, Timur Tabi <timur@freescale.com> wrote:
> >> Arnd Bergmann wrote:
> > I think it
> > is a slippery slope to try and encode conditionals into the structure;
>
> Perhaps, which is why I said it should be simple conditionals - two
> values and a comparison.
I can pretty much guarantee you that someone will find that
insufficient and want to expand the conditional representation. This
way madness lies.
> > but it is entirely reasonable to encode *data* into the dt that helps
> > make those conditional decisions.
>
> That's okay too, except that if we just add additional nodes that
> describe conditions, then we need to make sure that whatever parses
> that DTB must also parse those additional nodes. The only way to do
> that is create a new version number, like 18, which is marked as
> being incompatible with the current version (17). Otherwise, a
> person could pass that DTB to an old version of U-Boot, and U-boot
> will just pass it on to the kernel as-is.
No. As Grant says, that's not what the version number is for. It
represents the version of the encoding, not the content. If you must
version the content (which you should try really hard to avoid) the
correct way is to add versioning properties to the root node.
> > We've already got that issue. If you pass the device tree for the
> > wrong board it will still validate correctly, but the board is not
> > going to boot.
>
> There's nothing stopping U-Boot today from scanning the device tree
> and making sure the SOC's compatible node is correct. That's not
> currently done, but it could be.
>
> > The device tree must match what the bootloader
> > expects. Changing the version number will do nothing to help this.
> > The version number ensures that the tree is parsable. It does not
> > ensure that it is correct.
>
> I think you're missing the point. If we add conditional expressions
> to the device tree (whether attached to a node or as part of a
> separate node or whatever), we must also add a mechanism to ensure
> that these conditions are parsed by the boot loader. As far as I
> know, the only mechanism that can do this is the version identifier.
No. a) the version identifier is not a mechanism for doing that and b)
the conditional mechanism is inherently agent-specific, therefore in
any case you *must* match an input incomplete tree (by which I mean
*anything* that requires processing before it's ready for consumption
by the kernel) to the specific bootloader or agent that will process
it and pass to the kernel.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:21 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B1BEE7.4050808@freescale.com>
On Tue, Feb 12, 2008 at 09:44:39AM -0600, Timur Tabi wrote:
> Arnd Bergmann wrote:
>
> > On Tuesday 12 February 2008, David Gibson wrote:
> >> Or to expand. It's relatively easy now to just include multiple nodes
> >> in the tree and either delete or nop some of them out conditionally
> >> using libfdt.
>
> Yes, but what better place to store the conditions than in the
> device tree itself? How would libfdt know where the conditions are?
> Do you want to have two binary blobs?
libfdt wouldn't. The conditional logic must be in the agent using
libfdt.
> >> But the conditional logic should be in the manipulating
> >> agent (u-boot or bootwrapper or whatever), there's no way we're going
> >> to require a conditional expression parser to interpret the device
> >> tree blob itself.
>
> I think it's a great feature that solves a lot of problems, and it
> does so in an elegant and efficient manner. I look forward to
> trying to change your mind when I get around to implementing it.
>
> > How about making the logic to nop out nodes a little more generic
> > without changes to the binary format?
> > E.g. you could have a "linux,conditional-node" property in the device
> > tree whose value is compared to a HW configuration specific string.
>
> The problem with this is that if you use a version of libfdt that
> does not understand "linux,conditional-node", then your device tree
> will be wrong, because it could contain nodes that don't belong. We
> would need a new, incompatible version number for the device tree to
> make sure that this doesn't happen, even though nothing has changed
> in the binary layout of the tree.
Passing an incomplete device tree to an agent that doesn't expect it
is always going to cause trouble. This is nothing new. And as you've
said the interpretation of these variables in the conditionals is
already agent specific, so you'd still have to pass these
conditionalised trees to the correct agent in order for them to be
correctly interpreted.
No, this has to be agent-local logic. If you want to annotate your
agent's input device trees with information that will help it do this,
go for it, but don't expect it to be in any way a standardized aspect
of the device tree format.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:17 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi, Arnd Bergmann
In-Reply-To: <20080212185106.GA4042@loki.buserror.net>
On Tue, Feb 12, 2008 at 12:51:06PM -0600, Scott Wood wrote:
> On Tue, Feb 12, 2008 at 11:36:33AM +1100, David Gibson wrote:
> > On Tue, Feb 12, 2008 at 01:21:44AM +0100, Arnd Bergmann wrote:
> > > On Tuesday 12 February 2008, David Gibson wrote:
> > > > Or to expand. It's relatively easy now to just include multiple nodes
> > > > in the tree and either delete or nop some of them out conditionally
> > > > using libfdt. But the conditional logic should be in the manipulating
> > > > agent (u-boot or bootwrapper or whatever), there's no way we're going
> > > > to require a conditional expression parser to interpret the device
> > > > tree blob itself.
> > >
> > > How about making the logic to nop out nodes a little more generic
> > > without changes to the binary format?
> > > E.g. you could have a "linux,conditional-node" property in the device
> > > tree whose value is compared to a HW configuration specific string.
> > > In Sean's example, you can have linux,conditional-node="Rev.A" in
> > > some nodes and linux,conditional-node="Rev.B" in others, then
> > > knock out all devices that have a non-matching linux,conditional-node
> > > property, and finally remove the properties themselves before starting
> > > the kernel.
> >
> > Well, that's basically a u-boot issue. If they want to do their input
> > trees that way, and have helper functions that deal with it...
>
> The actual mechanism that we originially discussed, which Timur later
> morphed into conditions-on-nodes, was to have a separate hwoptions node,
> under which would be described various hwoptions (jumpers and such) whose
> state could be either detected by u-boot or set by environment variable.
> Each hwoption setting would contain a device tree fragment to be merged into
> the main device tree.
I'm not sure I'm entirely happy about storing the fragments under a
special node - but certainly u-boot could do that if it wants. What
would certainly be ok is to store various fragments as separate blobs
and fold them together as necessary. Which reminds me, I meant to
implement a "graft" function in libfdt.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: DTS question - MPC5200b
From: David Gibson @ 2008-02-12 22:49 UTC (permalink / raw)
To: Nick; +Cc: linuxppc-dev
In-Reply-To: <47B1D943.6020708@rogers.com>
On Tue, Feb 12, 2008 at 12:37:07PM -0500, Nick wrote:
> Hi,
>
> I need some help. I am trying to access timer 7 on the MPC5200B
> processor. I have the DTS file setup like this
Others have addressed the most salient points, but some general
corrections for your device tree..
> gpt@670 { // General Purpose Timer
> device_type = "gpt";
device_type shouldn't be here.
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <7>;
You probably don't want cell-index. cell-index should *only* be used
when there is some global register somewhere that's indexed by the
cell number.
> reg = <670 10>;
> interrupts = <1 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> I have timers 0 to 6 defined the same way except the cell-index reflects
> the timer number.
Presumably 'reg' is different for each, as well.
> In my platform file where I am doing my board setup, I tried the following.
>
> timer7 = mpc52xx_find_and_map ("mpc5200b-gpt");
>
> How do I specify the timer based on the cell-index?
You don't. As Grant explains, use reg instead.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Benjamin Herrenschmidt @ 2008-02-12 22:00 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20080212214137.47478e5e@core>
On Tue, 2008-02-12 at 21:41 +0000, Alan Cox wrote:
> On Wed, 13 Feb 2008 08:04:07 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> >
> > On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > > - couple of fixes and preparatory patches
> > > >
> > > > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > > > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> > >
> > > Interesting... I was thinking about doing a full remove of the device at
> > > a higher level instead but I suppose what you propose is easier.
> > >
> > > I'll have a look & test next week hopefully.
> >
> > Also, the above would have the advantage of not relying on drivers/ide
> > infrastructure, and thus working with libata (once somebody has ported
> > pmac ide to libata).
>
> Unfortunately you need a degree in dentistry to open a Macintosh up and
> fix it otherwise we would have support by now.
Heh :-)
Recent powermacs are trivial to open ! But yeah, I do need to produce a
driver for libata one of these days. On my todo list ...
Cheers,
Ben.
^ 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