* [PATCH] [POWERPC] pasemi: Move electra-ide to pata_of_platform
From: Olof Johansson @ 2008-01-15 16:40 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Paul Mundt, Jeff Garzik, linux-ide
In-Reply-To: <20080109190852.GA18827@localhost.localdomain>
Move electra-ide glue over to the new pata_of_platform framework, and
add the quirks needed to that driver.
---
Applied with the rest of the patches to pasemi.git for-2.6.25
arch/powerpc/platforms/pasemi/electra_ide.c | 96 ----------------------------
b/arch/powerpc/configs/pasemi_defconfig | 4 -
b/arch/powerpc/platforms/pasemi/Kconfig | 9 --
b/arch/powerpc/platforms/pasemi/Makefile | 1
b/drivers/ata/pata_of_platform.c | 20 ++++-
5 files changed, 17 insertions(+), 113 deletions(-)
diff --git a/arch/powerpc/configs/pasemi_defconfig b/arch/powerpc/configs/pasemi_defconfig
index 9d21b08..797f0df 100644
--- a/arch/powerpc/configs/pasemi_defconfig
+++ b/arch/powerpc/configs/pasemi_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc6
-# Fri Dec 28 11:01:53 2007
+# Tue Jan 15 10:26:10 2008
#
CONFIG_PPC64=y
@@ -152,7 +152,6 @@ CONFIG_PPC_PASEMI=y
CONFIG_PPC_PASEMI_IOMMU=y
# CONFIG_PPC_PASEMI_IOMMU_DMA_FORCE is not set
CONFIG_PPC_PASEMI_MDIO=y
-CONFIG_ELECTRA_IDE=y
# CONFIG_PPC_CELLEB is not set
# CONFIG_PPC_PS3 is not set
# CONFIG_PPC_CELL is not set
@@ -663,6 +662,7 @@ CONFIG_PATA_PCMCIA=y
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
CONFIG_PATA_PLATFORM=y
+CONFIG_PATA_OF_PLATFORM=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig
index b3458a1..348e061 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -37,13 +37,4 @@ config PPC_PASEMI_MDIO
help
Driver for MDIO via GPIO on PWRficient platforms
-config ELECTRA_IDE
- tristate "Electra IDE driver"
- default y
- depends on PPC_PASEMI && ATA
- select PATA_PLATFORM
- help
- This includes driver support for the Electra on-board IDE
- interface.
-
endmenu
diff --git a/arch/powerpc/platforms/pasemi/Makefile b/arch/powerpc/platforms/pasemi/Makefile
index f47fcac..2cd2a4f 100644
--- a/arch/powerpc/platforms/pasemi/Makefile
+++ b/arch/powerpc/platforms/pasemi/Makefile
@@ -1,4 +1,3 @@
obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o
obj-$(CONFIG_PPC_PASEMI_MDIO) += gpio_mdio.o
-obj-$(CONFIG_ELECTRA_IDE) += electra_ide.o
obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += cpufreq.o
diff --git a/arch/powerpc/platforms/pasemi/electra_ide.c b/arch/powerpc/platforms/pasemi/electra_ide.c
deleted file mode 100644
index 12fb0c9..0000000
--- a/arch/powerpc/platforms/pasemi/electra_ide.c
+++ /dev/null
@@ -1,96 +0,0 @@
-/*
- * Copyright (C) 2007 PA Semi, Inc
- *
- * Maintained by: Olof Johansson <olof@lixom.net>
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include <linux/platform_device.h>
-
-#include <asm/prom.h>
-#include <asm/system.h>
-
-/* The electra IDE interface is incredibly simple: Just a device on the localbus
- * with interrupts hooked up to one of the GPIOs. The device tree contains the
- * address window and interrupt mappings already, and the pata_platform driver handles
- * the rest. We just need to hook the two up.
- */
-
-#define MAX_IFS 4 /* really, we have only one */
-
-static struct platform_device *pdevs[MAX_IFS];
-
-static int __devinit electra_ide_init(void)
-{
- struct device_node *np;
- struct resource r[3];
- int ret = 0;
- int i;
-
- np = of_find_compatible_node(NULL, "ide", "electra-ide");
- i = 0;
-
- while (np && i < MAX_IFS) {
- memset(r, 0, sizeof(r));
-
- /* pata_platform wants two address ranges: one for the base registers,
- * another for the control (altstatus). It's located at offset 0x3f6 in
- * the window, but the device tree only has one large register window
- * that covers both ranges. So we need to split it up by hand here:
- */
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto out;
- ret = of_address_to_resource(np, 0, &r[1]);
- if (ret)
- goto out;
-
- r[1].start += 0x3f6;
- r[0].end = r[1].start-1;
-
- r[2].start = irq_of_parse_and_map(np, 0);
- r[2].end = irq_of_parse_and_map(np, 0);
- r[2].flags = IORESOURCE_IRQ;
-
- pr_debug("registering platform device at 0x%lx/0x%lx, irq is %ld\n",
- r[0].start, r[1].start, r[2].start);
- pdevs[i] = platform_device_register_simple("pata_platform", i, r, 3);
- if (IS_ERR(pdevs[i])) {
- ret = PTR_ERR(pdevs[i]);
- pdevs[i] = NULL;
- goto out;
- }
- np = of_find_compatible_node(np, "ide", "electra-ide");
- }
-out:
- return ret;
-}
-module_init(electra_ide_init);
-
-static void __devexit electra_ide_exit(void)
-{
- int i;
-
- for (i = 0; i < MAX_IFS; i++)
- if (pdevs[i])
- platform_device_unregister(pdevs[i]);
-}
-module_exit(electra_ide_exit);
-
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR ("Olof Johansson <olof@lixom.net>");
-MODULE_DESCRIPTION("PA Semi Electra IDE driver");
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index b7bc4e4..938f48a 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -34,11 +34,20 @@ static int __devinit pata_of_platform_probe(struct of_device *ofdev,
return -EINVAL;
}
- ret = of_address_to_resource(dn, 1, &ctl_res);
- if (ret) {
- dev_err(&ofdev->dev, "can't get CTL address from "
- "device tree\n");
- return -EINVAL;
+ if (of_device_is_compatible(dn, "electra-ide")) {
+ /* Altstatus is really at offset 0x3f6 from the primary window
+ * on electra-ide. Adjust ctl_res and io_res accordingly.
+ */
+ ctl_res = io_res;
+ ctl_res.start = ctl_res.start+0x3f6;
+ io_res.end = ctl_res.start-1;
+ } else {
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
}
ret = of_irq_to_resource(dn, 0, &irq_res);
@@ -76,6 +85,7 @@ static int __devexit pata_of_platform_remove(struct of_device *ofdev)
static struct of_device_id pata_of_platform_match[] = {
{ .compatible = "ata-generic", },
+ { .compatible = "electra-ide", },
{},
};
MODULE_DEVICE_TABLE(of, pata_of_platform_match);
^ permalink raw reply related
* Re: [PATCH] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
From: Scott Wood @ 2008-01-15 16:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <BFCCA52A-85B7-4DD5-ACF4-2F3E65CFD7FD@kernel.crashing.org>
On Mon, Jan 14, 2008 at 08:37:27PM -0600, Kumar Gala wrote:
> >diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/
> >fsl_soc.c
> >index 3ace747..7502e03 100644
> >--- a/arch/powerpc/sysdev/fsl_soc.c
> >+++ b/arch/powerpc/sysdev/fsl_soc.c
> >@@ -54,10 +54,18 @@ phys_addr_t get_immrbase(void)
> > soc = of_find_node_by_type(NULL, "soc");
> > if (soc) {
> > int size;
> >- const void *prop = of_get_property(soc, "reg", &size);
> >+ u32 naddr;
> >+ const u32 *prop = of_get_property(soc, "#address-cells",
> >&size);
> >+
> >+ if (prop && size == 4)
> >+ naddr = *prop;
> >+ else
> >+ naddr = 2;
>
> Why default to two?
Because that's what the OF spec says the default is?
> >+ prop = of_get_property(soc, "ranges", &size);
> >+ if (prop && size == 12)
> >+ immrbase = of_translate_address(soc, prop + naddr);
Grr, I thought I removed the size == 12 check...
> >- if (prop)
> >- immrbase = of_translate_address(soc, prop);
>
> why not make your code an else case if we don't have reg?
Why?
> or something like, than we don't have to worry about adjust anything,
> and if you don't have any children its kinda a pointless device tree :)
It's not pointless, it's just incomplete.
> if (soc) {
> struct device_node *child = of_get_next_child(soc, NULL);
> if (child) {
> const void *prop = of_get_property(soc, "ranges",
> NULL);
> if (prop)
> immrbase = of_translate_address(child, prop);
> of_node_put(child);
> }
> of_node_put(soc);
> }
Why go out of our way to fail on a childless soc node?
-Scott
^ permalink raw reply
* Please pull pasemi.git for-2.6.25 branch
From: Olof Johansson @ 2008-01-15 17:01 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Paul,
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/olof/k.org.git for-2.6.25
to receive the following updates:
arch/powerpc/configs/pasemi_defconfig | 4
arch/powerpc/platforms/pasemi/Kconfig | 9 -
arch/powerpc/platforms/pasemi/Makefile | 1
arch/powerpc/platforms/pasemi/electra_ide.c | 96 ------------------
arch/powerpc/platforms/pasemi/idle.c | 5
arch/powerpc/platforms/pasemi/setup.c | 12 --
drivers/ata/Kconfig | 12 ++
drivers/ata/Makefile | 1
drivers/ata/pata_of_platform.c | 114 ++++++++++++++++++++++
drivers/ata/pata_platform.c | 144 ++++++++++++++++------------
include/linux/pata_platform.h | 9 +
11 files changed, 227 insertions(+), 180 deletions(-)
Anton Vorontsov (2):
libata: pata_platform: make probe and remove functions device type neutral
libata: pata_of_platform: OF-Platform PATA device driver
Grant Likely (1):
[POWERPC] pasemi: Use machine_*_initcall() hooks in platform code
Olof Johansson (2):
[POWERPC] pasemi: Fix NMI handling check
[POWERPC] pasemi: Move electra-ide to pata_of_platform
Thanks,
Olof
^ permalink raw reply
* Re: [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: Scott Wood @ 2008-01-15 16:52 UTC (permalink / raw)
To: jdl, linuxppc-dev
In-Reply-To: <20080115001657.GC20649@localhost.localdomain>
On Tue, Jan 15, 2008 at 11:16:57AM +1100, David Gibson wrote:
> On Mon, Jan 14, 2008 at 10:30:04AM -0600, Scott Wood wrote:
> > ft_get_next_node() enumerates children of a given node.
> > ft_get_next_prop() enumerates propreties of a given node.
> >
> > ft_getprop_offset() is like ft_getprop(), but takes a property offset rather
> > than a node offset and property name; it is primarily intended for use
> > with ft_get_next_prop().
>
> Urg... this kind of serves me right for not getting my act together on
> iterator functions yet. I really don't like this approach much. I'll
> see if I can come up with something I prefer this afternoon.
OK.
> The biggest thing I dislike is that I've deliberately avoided having
> any offsets-to-properties exposed to the library user. That's because
> the whole offsets change when you write the tree problem is worse for
> properties than nodes (in that likely idiomatic uses will be bitten by
> changes in property offsets).
We can drop the property iteration for now; I wrote it for an attempt at
node merging which I postponed.
> > + if (depth != 0)
> > + return -FDT_ERR_BADSTRUCTURE;
>
> I think this should be FDT_ERR_TRUNCATED.
I'd expect TRUNCATED when we hit totalsize without an FDT_END, not when
we hit FDT_END in an inappropriate context.
> > + return -FDT_ERR_NOTFOUND;
>
> In fact, so should this. This function should never actually reach
> the FDT_END tag.
No, it's valid if you're iterating over all nodes (node -1, depth -1).
> > +#define FDT_ERR_BADDEPTH 8
> > + /* FDT_ERR_BADDEPTH: Function was passed a negative
> > + * (or otherwise invalid) depth. */
>
> You've added this error code, but you don't actually return it
> anywhere...
Oops, it must have been from the aforementioned node merging code, and I
thought it was from fdt_get_next_node when splitting things up.
> This description is incorrect - you've copied the fdt_getprop()
> description and forgotten to update it.
/me hides in shame
-Scott
^ permalink raw reply
* Re: PPC vs POWERPC
From: Jon Loeliger @ 2008-01-15 17:01 UTC (permalink / raw)
To: Matias Sundman; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <478C8D38.3090602@sundmangroup.com>
On Tue, 2008-01-15 at 04:38, Matias Sundman wrote:
> >>Documentation/powerpc/booting-without-of.txt to find out what is
> >>expected in the device tree.
>
> Is there any more information on how the "of_*" ( e.g. of_node_put ,
> of_find_node_by_type ) functions should be implemented in the
> "arch/powerpc/platforms/myplatform/myboard_setup.c" file
> or is the documentation the existing "*.c" c files under
> arch/powerpc/platforms ?
>
> Since I have a 82xx board I assume that "myboard_setup.c" file shall be
> put under arch/powerpc/platforms/82xx.
Maybe. Which 82xx is it? There is a notable difference
between, say, the 824x boards and the 827x boards. If it
is the latter, perhaps the existing 82xx/ pq2 or mpc8272
parts are already sufficient?
If it is the former group, 824x, perhaps some of the parts
in embedded6xx/ are usable? Also note that I am working on
publishing an 824x StorCenter port under embedded6xx/ at
this time as well. First patches were posted to linuxppc-dev
list at ozlabs.org.
HTH,
jdl
^ permalink raw reply
* MPC5200B SPI codec error when there is a heavy ethernet traffic.
From: Txema Lopez @ 2008-01-15 16:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]
Hi all,
We have a MPC5200B based custom board running a 2.4.25 Denx linux
kernel. We use the PSC6 in SPI-codec mode to exchange some bytes
periodically in full-duplex with a peripheral.
In 'normal' conditions this communication runs fine. But when we start
sending packets over the Ethernet as a background activity, we see on
the oscilloscope that one of the SPI transfers is interrupted. Not only
that the SPI clock stops, something that could happen in the case that
the transmission Fifo is empty, or the reception Fifo is full, but that
the chip select actually goes high for an instant, causing the
peripheral to abort the communication.
We have reproduced the same bug in a Lite5200B using the spi-dev driver
and a user application, so it seams it's not a problem of our hardware.
The problem only arises if there is some heavy Ethernet traffic (a big
file ftp transfer or a big file copy by nfs) , so we think the error is
related with the Bestcomm activity. We have contacted freescale to check
if it's a microprocessor bug and they are looking into it. But we think
it could be also a bug in the Bestcomm programming of the FEC tasks.
Could be it possible? At this point, we really need some help. Any clue
will be welcomed.
Best regards,
Txema
[-- Attachment #2: tlopez.vcf --]
[-- Type: text/x-vcard, Size: 324 bytes --]
begin:vcard
fn:Jose Maria Lopez
n:Lopez;Jose Maria
org:Fagor Automation S. Coop.
adr:;;San Andres 19. Apdo. 144;Arrasate-Mondragon;;20500;Spain
email;internet:tlopez@aotek.es
title:Sotware engineer
tel;work:(34) 943719200
tel;fax:(34) 943791712
x-mozilla-html:FALSE
url:http://www.fagorautomation.es
version:2.1
end:vcard
^ permalink raw reply
* Re: PPC vs POWERPC
From: Scott Wood @ 2008-01-15 17:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Matias Sundman, linuxppc-embedded@ozlabs.org
In-Reply-To: <1200416484.14540.5.camel@ld0161-tx32>
On Tue, Jan 15, 2008 at 11:01:33AM -0600, Jon Loeliger wrote:
> If it is the former group, 824x, perhaps some of the parts
> in embedded6xx/ are usable?
Not all 824x fall into that category; for example, 8248 is pq2. Someone
in marketing should be shot.
-Scott
^ permalink raw reply
* Re: [PATCH] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
From: Kumar Gala @ 2008-01-15 17:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080115164053.GA10812@ld0162-tx32.am.freescale.net>
On Jan 15, 2008, at 10:40 AM, Scott Wood wrote:
> On Mon, Jan 14, 2008 at 08:37:27PM -0600, Kumar Gala wrote:
>>> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/
>>> fsl_soc.c
>>> index 3ace747..7502e03 100644
>>> --- a/arch/powerpc/sysdev/fsl_soc.c
>>> +++ b/arch/powerpc/sysdev/fsl_soc.c
>>> @@ -54,10 +54,18 @@ phys_addr_t get_immrbase(void)
>>> soc = of_find_node_by_type(NULL, "soc");
>>> if (soc) {
>>> int size;
>>> - const void *prop = of_get_property(soc, "reg", &size);
>>> + u32 naddr;
>>> + const u32 *prop = of_get_property(soc, "#address-cells",
>>> &size);
>>> +
>>> + if (prop && size == 4)
>>> + naddr = *prop;
>>> + else
>>> + naddr = 2;
>>
>> Why default to two?
>
> Because that's what the OF spec says the default is?
fair.
>>> + prop = of_get_property(soc, "ranges", &size);
>>> + if (prop && size == 12)
>>> + immrbase = of_translate_address(soc, prop + naddr);
>
> Grr, I thought I removed the size == 12 check...
>
>>> - if (prop)
>>> - immrbase = of_translate_address(soc, prop);
>>
>> why not make your code an else case if we don't have reg?
>
> Why?
I agree (had to think about it a bit more).
>> or something like, than we don't have to worry about adjust anything,
>> and if you don't have any children its kinda a pointless device
>> tree :)
>
> It's not pointless, it's just incomplete.
>
>> if (soc) {
>> struct device_node *child = of_get_next_child(soc, NULL);
>> if (child) {
>> const void *prop = of_get_property(soc, "ranges",
>> NULL);
>> if (prop)
>> immrbase = of_translate_address(child, prop);
>> of_node_put(child);
>> }
>> of_node_put(soc);
>> }
>
> Why go out of our way to fail on a childless soc node?
do we see any case in which we'd have a childless soc node?
I'm just concerned about make sure this works for all the various
cases of #address-cells and #size-cells.
- k
^ permalink raw reply
* Re: PPC vs POWERPC
From: Jon Loeliger @ 2008-01-15 17:14 UTC (permalink / raw)
To: Scott Wood; +Cc: Matias Sundman, linuxppc-embedded@ozlabs.org
In-Reply-To: <20080115170723.GA10988@ld0162-tx32.am.freescale.net>
On Tue, 2008-01-15 at 11:07, Scott Wood wrote:
> On Tue, Jan 15, 2008 at 11:01:33AM -0600, Jon Loeliger wrote:
> > If it is the former group, 824x, perhaps some of the parts
> > in embedded6xx/ are usable?
>
> Not all 824x fall into that category; for example, 8248 is pq2.
Gah. Of course.
> Someone in marketing should be shot.
Photos, bullets or heroin? :-)
jdl
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
From: Mark A. Greer @ 2008-01-15 17:20 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115101936.d186329d.sfr@canb.auug.org.au>
On Tue, Jan 15, 2008 at 10:19:36AM +1100, Stephen Rothwell wrote:
> Hi Mark,
Hi Stephen. Thanks for taking the time to review these patches.
> On Mon, 14 Jan 2008 15:51:50 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > +static inline struct pci_controller *mv64x60_find_hose(u32 idx)
> > +{
> > + struct device_node *phb;
> > + struct pci_controller *hose;
> > + const u32 *prop;
> > + int len;
> > +
> > + for_each_compatible_node(phb, "pci", "marvell,mv64360-pci") {
> > + prop = of_get_property(phb, "cell-index", &len);
> > + if (prop && (len == sizeof(prop)) && (*prop == idx)) {
> > + hose = pci_find_hose_for_OF_device(phb);
> > + of_node_put(phb);
> > + return hose;
> > + }
> > + }
> > +
> > + return NULL;
> > +}
>
> I would think that this is way to big to inline ...
Yeah, I suppose. I'm not sure why I made it an inline, TBH. I'll make
it a "real" routine.
Mark
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-15 18:22 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200801150739.39095.sr@denx.de>
Stefan Roese wrote:
> Bummer! Was worth a try though. I still don't see why this should fail on your
> platform. What error/exception do you get upon 32bit access btw?
>
Ask and Ye Shall RX! Here is a complete trace of the crash including the
NAND debug outputs.
Cheers,
Sean
NDFC NAND Driver initialized. Chip-Rev: 0x00000109
NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bi)
Scanning device for bad blocks
Data machine check in kernel mode.
Oops: Machine check, sig: 7 [#1]
Warp
Modules linked in:
NIP: 00000000 LR: c01559b8 CTR: c0159f64
REGS: c02c2f50 TRAP: 0202 Not tainted (2.6.24-rc6-pika)
MSR: 00000000 <> CR: 42000024 XER: 2000005f
TASK = cf81bba0[1] 'swapper' THREAD: cf81e000
GPR00: 70000000 cf81fd30 cf81bba0 c02daac4 cf9a5280 0000000c 00000240 00000000
GPR08: 122deea8 d1064000 000f4240 c02e0000 121f0cf6 00000000 0ffabe00 c02b0d14
GPR16: 0040044c 0000001f cf9a5080 00000000 00000000 00000010 00000002 00000000
GPR24: 00000010 00000000 00000001 c02daac4 cf81fda8 00000000 c02daac4 c0159f64
NIP [00000000] _start+0x40000000/0x30
LR [c01559b8] nand_read_oob_std+0x54/0x6c
Call Trace:
[cf81fd30] [c01559a0] nand_read_oob_std+0x3c/0x6c (unreliable)
[cf81fd50] [c0155fb4] nand_read_oob+0x204/0x334
[cf81fda0] [c01589c8] create_bbt+0x210/0x2f0
[cf81fe00] [c0159abc] nand_scan_bbt+0x464/0x4c4
[cf81fe50] [c0157a1c] nand_scan_tail+0x4b0/0x4f4
[cf81fe70] [c015a214] ndfc_chip_probe+0x168/0x1d4
[cf81fe90] [c012e014] platform_drv_probe+0x20/0x30
[cf81fea0] [c012bee8] driver_probe_device+0xb8/0x1cc
[cf81fec0] [c012c1d4] __driver_attach+0xcc/0xf8
[cf81fee0] [c012af8c] bus_for_each_dev+0x54/0x90
[cf81ff10] [c012bc14] driver_attach+0x24/0x34
[cf81ff20] [c012b64c] bus_add_driver+0x98/0x1b8
[cf81ff40] [c012c65c] driver_register+0x58/0xa0
[cf81ff50] [c012e190] platform_driver_register+0x98/0xa8
[cf81ff60] [c028c014] ndfc_nand_init+0x38/0x50
[cf81ff70] [c027486c] kernel_init+0xa4/0x290
[cf81fff0] [c000c320] kernel_thread+0x48/0x64
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 99adfcc136bb75fe ]---
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
From: Mark A. Greer @ 2008-01-15 17:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115102129.a4666143.sfr@canb.auug.org.au>
On Tue, Jan 15, 2008 at 10:21:29AM +1100, Stephen Rothwell wrote:
> Hi Mark,
>
> On Mon, 14 Jan 2008 15:51:50 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > +++ b/arch/powerpc/sysdev/mv64x60.h
> > @@ -3,10 +3,32 @@
> >
> > #include <linux/init.h>
> >
> > +#include <asm/prom.h>
>
> You probably meant to include linux/of.h here
Umm, apparently... :)
Mark
^ permalink raw reply
* Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Eugene Surovegin @ 2008-01-15 17:32 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200400809-19720-1-git-send-email-sr@denx.de>
On Tue, Jan 15, 2008 at 01:40:09PM +0100, Stefan Roese wrote:
> Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> xmit. This routine doesn't check if the frame length exceeds the max.
> MAL buffer size.
>
> This patch now changes the driver to call emac_start_xmit_sg() on all
> platforms and not only the TAH equipped ones (440GX). This enables an
> MTU of 9000 instead 4080.
>
> Tested on Kilauea (405EX) with gbit link -> jumbo frames enabled.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> Eugene & Ben, do you see any problems with this patch? If not, then I'll
> send another version for the newemac driver too.
Hmm, so why not make GigE support a condition to hook SG version of
xmit then? I don't like when you change behaviour for chips where it
perefectly legal not to do this check because you cannot change MTU
anyways.
--
Eugene
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Katana750i - Add platform support
From: Mark A. Greer @ 2008-01-15 17:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115103346.30cc3d54.sfr@canb.auug.org.au>
On Tue, Jan 15, 2008 at 10:33:46AM +1100, Stephen Rothwell wrote:
> Hi Mark,
>
> On Mon, 14 Jan 2008 16:00:57 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > +++ b/arch/powerpc/platforms/embedded6xx/katana750i.c
> > @@ -0,0 +1,314 @@
> > +/*
> > + * Board setup routines for the Emerson Katana-750i/752i
> > + *
> > + * Author: Mark A. Greer <mgreer@mvista.com>
> > + *
> > + * Based on code prpmc2800.c by Dale Farnsworth <dale@farnsworth.org>
> > + * and original katana port by Tim Montgomery <timm@artesyncp.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.
>
> A Copyright notice would be nice.
Okay.
> > +static void __init katana750i_setup_arch(void)
> > +{
> > + struct device_node *np;
> > + phys_addr_t paddr;
> > + const unsigned int *reg;
> > +
> > + /*
> > + * ioremap mpp and gpp registers in case they are later
> > + * needed by katana750i_reset_board().
> > + */
> > + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-mpp");
> > + reg = of_get_property(np, "reg", NULL);
>
> What happens if np == NULL?
It'll explode. :D I'll fix.
> > + paddr = of_translate_address(np, reg);
> > + of_node_put(np);
> > + mv64x60_mpp_reg_base = ioremap(paddr, reg[1]);
> > +
> > + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-gpp");
> > + reg = of_get_property(np, "reg", NULL);
>
> Ditto.
>
> > + paddr = of_translate_address(np, reg);
> > + of_node_put(np);
> > + mv64x60_gpp_reg_base = ioremap(paddr, reg[1]);
> > +
> > +#ifdef CONFIG_PCI
> > + mv64x60_pci_init();
> > +#endif
>
> Maybe there should be a stub of mv64x60_pci_init for the non PCI case -
> that would save the ifdefs in C code.
Good idea.
> > + np = of_find_compatible_node(NULL, NULL, "katana750i,cpld");
> > + reg = of_get_property(np, "reg", NULL);
>
> What if np == NULL?
Thanks again, Stephen.
Mark
^ permalink raw reply
* Re: PPC vs POWERPC
From: Matias Sundman @ 2008-01-15 17:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <1200416484.14540.5.camel@ld0161-tx32>
Jon Loeliger skrev:
> On Tue, 2008-01-15 at 04:38, Matias Sundman wrote:
>
>> >>Documentation/powerpc/booting-without-of.txt to find out what is
>> >>expected in the device tree.
>>
>> Is there any more information on how the "of_*" ( e.g. of_node_put ,
>> of_find_node_by_type ) functions should be implemented in the
>> "arch/powerpc/platforms/myplatform/myboard_setup.c" file
>> or is the documentation the existing "*.c" c files under
>> arch/powerpc/platforms ?
>>
>> Since I have a 82xx board I assume that "myboard_setup.c" file shall be
>> put under arch/powerpc/platforms/82xx.
>>
>
> Maybe. Which 82xx is it? There is a notable difference
> between, say, the 824x boards and the 827x boards. If it
> is the latter, perhaps the existing 82xx/ pq2 or mpc8272
> parts are already sufficient?
>
> If it is the former group, 824x, perhaps some of the parts
> in embedded6xx/ are usable? Also note that I am working on
> publishing an 824x StorCenter port under embedded6xx/ at
> this time as well. First patches were posted to linuxppc-dev
> list at ozlabs.org.
>
> HTH,
> jdl
>
>
>
The board is based on PPC8265.
Cheers // Matias
^ permalink raw reply
* RE: MPC5200B SPI codec error when there is a heavy ethernet
From: Albrecht Moll @ 2008-01-15 17:37 UTC (permalink / raw)
To: linuxppc-embedded
> Txema wrote on 15 Jan 2008
> We have a MPC5200B based custom board running a 2.4.25 Denx linux
> kernel. We use the PSC6 in SPI-codec mode to exchange some bytes
> periodically in full-duplex with a peripheral.
>
> In 'normal' conditions this communication runs fine. But when we start
> sending packets over the Ethernet as a background activity, we see on
> the oscilloscope that one of the SPI transfers is interrupted.
Also just a shot in the dark:
I remember someone having similar problems with UART in AC97 mode.
(http://marc.info/?l=linuxppc-embedded&m=117932912618680&w=2)
I associated this with other FEC problems which boiled down to an issue
with
MPC52xx_XLB_CFG_BSDIS.
^ permalink raw reply
* Re: Please pull pasemi.git for-2.6.25 branch
From: Olof Johansson @ 2008-01-15 18:27 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080115170152.GA25749@lixom.net>
On Tue, Jan 15, 2008 at 11:01:52AM -0600, Olof Johansson wrote:
> Paul,
>
> Please pull from 'for-2.6.25' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/olof/k.org.git for-2.6.25
Sorry, new script and I botched it. The link is:
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Scott Wood @ 2008-01-15 18:19 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1200380955-10217-1-git-send-email-sr@denx.de>
On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
> This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
> is a 405EX with only one EMAC and only one PCIe interface.
Sounds like they have the same core... why do they need separate cputable
entries?
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Olof Johansson @ 2008-01-15 18:32 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080115181924.GA3848@loki.buserror.net>
On Tue, Jan 15, 2008 at 12:19:24PM -0600, Scott Wood wrote:
> On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
> > This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
> > is a 405EX with only one EMAC and only one PCIe interface.
>
> Sounds like they have the same core... why do they need separate cputable
> entries?
AMCC has always indicated SoC products by new PVRs. This isn't news,
even though it isn't exactly a clean solution. :)
-Olof
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Scott Wood @ 2008-01-15 18:25 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080115183240.GC25749@lixom.net>
Olof Johansson wrote:
> On Tue, Jan 15, 2008 at 12:19:24PM -0600, Scott Wood wrote:
>> On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
>>> This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
>>> is a 405EX with only one EMAC and only one PCIe interface.
>> Sounds like they have the same core... why do they need separate cputable
>> entries?
>
> AMCC has always indicated SoC products by new PVRs. This isn't news,
> even though it isn't exactly a clean solution. :)
But the old 405EX entry would have matched both chips. Why add a new
significant bit to pvr_mask? For the name in /proc/cpuinfo?
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Olof Johansson @ 2008-01-15 18:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <478CFA96.90009@freescale.com>
On Tue, Jan 15, 2008 at 12:25:26PM -0600, Scott Wood wrote:
> Olof Johansson wrote:
> > On Tue, Jan 15, 2008 at 12:19:24PM -0600, Scott Wood wrote:
> >> On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
> >>> This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
> >>> is a 405EX with only one EMAC and only one PCIe interface.
> >> Sounds like they have the same core... why do they need separate cputable
> >> entries?
> >
> > AMCC has always indicated SoC products by new PVRs. This isn't news,
> > even though it isn't exactly a clean solution. :)
>
> But the old 405EX entry would have matched both chips. Why add a new
> significant bit to pvr_mask? For the name in /proc/cpuinfo?
Presumably, yes.
Again, this is nothing new. Other 405/440 products are doing the same
thing.
-Olof
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Josh Boyer @ 2008-01-15 18:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: Scott Wood, linuxppc-dev, Stefan, Roese
In-Reply-To: <20080115183809.GD25749@lixom.net>
On Tue, 15 Jan 2008 12:38:09 -0600
Olof Johansson <olof@lixom.net> wrote:
> On Tue, Jan 15, 2008 at 12:25:26PM -0600, Scott Wood wrote:
> > Olof Johansson wrote:
> > > On Tue, Jan 15, 2008 at 12:19:24PM -0600, Scott Wood wrote:
> > >> On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
> > >>> This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
> > >>> is a 405EX with only one EMAC and only one PCIe interface.
> > >> Sounds like they have the same core... why do they need separate cputable
> > >> entries?
> > >
> > > AMCC has always indicated SoC products by new PVRs. This isn't news,
> > > even though it isn't exactly a clean solution. :)
> >
> > But the old 405EX entry would have matched both chips. Why add a new
> > significant bit to pvr_mask? For the name in /proc/cpuinfo?
>
> Presumably, yes.
>
> Again, this is nothing new. Other 405/440 products are doing the same
> thing.
Does anyone have an actual problem with this patch? I'm inclined to
take it as it doesn't really cause any problems and may eventually be
needed anyway if there is a chip errata or something.
josh
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Katana750i - Add DTS file
From: Mark A. Greer @ 2008-01-15 19:08 UTC (permalink / raw)
To: Mark A. Greer, linuxppc-dev
In-Reply-To: <20080114233406.GB20649@localhost.localdomain>
On Tue, Jan 15, 2008 at 10:34:06AM +1100, David Gibson wrote:
> On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
> > From: Mark A. Greer <mgreer@mvista.com>
Hi David. Thanks for the review.
> > Add DTS file for the Emerson Katana 750i & 752i platforms.
>
> [snip]
> > +/dts-v1/;
> > +
> > +/ {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + model = "Katana-75xi"; /* Default */
> > + compatible = "emerson,katana-750i";
> > + coherency-off;
>
> Where is this flag used from?
Its used in the bootwrapper if & when you use the mv64x60 code to setup
some of the windows to the I/O ctlrs. This port does use that code
(because firmware doesn't do it properly) so I need the flag.
<snip>
> > + mv64x60@f8100000 { /* Marvell Discovery */
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + model = "mv64360"; /* Default */
> > + compatible = "marvell,mv64360";
> > + clock-frequency = <133333333>;
> > + hs_reg_valid;
> > + reg = <0xf8100000 0x00010000>;
> > + virtual-reg = <0xf8100000>;
>
> You seem to have virtual-reg properties on a *lot* of nodes, are they
> really necessary?
Actually, not all of them for this board. I copied them from prpmc2800
which does need all the ones that are there. I'l remove the ones that
aren't used.
> virtual-reg should be used *only* for things which
> you need to access very early in the bootwrapper. Usually that's only
> the serial port for the console. Come to that, the CPU is a 750 which
> has a real mode, so it seems dubious that you would need any
> virtual-reg values at all.
Well, this came from a discussion about a year ago when we agreed that
this is how it should be done. Just because MSR[IR,DR] can be cleared
doesn't mean that they are cleared when the firmware jumps to the
bootwraper (for all possible firmwares that are out there).
To be able to eliminate virtual-reg, we'd have to add "mmu_off" code to
the bootwrapper which isn't hard but its already in the kernel (for
32-bit anyway). So why duplicate?
I'm not that attached to virtual-reg. In fact, I'd be happy to get rid
of it but only if we can be sure it doesn't cause more mess down the
road.
> [snip]
> > + flash@e8000000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "cfi-flash";
> > + bank-width = <4>;
> > + device-width = <2>;
> > + reg = <0xe8000000 0x04000000>;
> > + monitor@0 {
> > + label = "Monitor";
>
> If you're using the "label" property, it would be normal to name the
> nodes simply "partition@address".
I'm using the partition names that were used in the equivalent code
under arch/ppc. I'm trying to keep things looking the same as they used
to as much as possible. Besides, I don't see any others doing it that
way.
<snip>
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "mdio";
>
> This device_type value should not be here.
Yep. Will fix.
<snip>
> > + multiethernet@2000 {
>
> This needs some sort of "compatible" value.
Okay.
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x2000 0x2000>;
> > + ethernet@0 {
>
> [snip]
> > + CUNIT: cunit@f200 {
>
> What is this device? It needs some sort of "compatible" value.
Does it? Its a separate block of regs but its only used in the mpsc
node--its never looked up on its own by kernel code. Do all nodes need
"compatible" even when it'll never be used? (Just want to know.)
> > + reg = <0xf200 0x200>;
> > + };
> > +
> > + MPSCROUTING: mpscrouting@b400 {
>
> Ditto.
Ditto.
> > + reg = <0xb400 0xc>;
> > + };
> > +
> > + MPSCINTR: mpscintr@b800 {
>
> Ditto.
Ditto.
> > + reg = <0xb800 0x100>;
> > + virtual-reg = <0xf810b800>;
> > + };
>
> [snip]
> > + i2c@c000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "i2c";
>
> This device_type value shouldn't be here either.
Oops, good catch.
<snip>
> > + mpp@f000 {
> > + compatible = "marvell,mv64360-mpp";
> > + reg = <0xf000 0x10>;
> > + };
> > +
> > + gpp@f100 {
> > + compatible = "marvell,mv64360-gpp";
> > + reg = <0xf100 0x20>;
> > + };
>
> What are these two devices?
mpp == multi-purpose pins
gpp == general purpose pins
They're really 2 separate reg blocks and are used for any number of
things including incoming PCI interrupts. I'm not accessing them
currently so I can eliminate them in this dts.
> > + pci@80000000 {
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + #interrupt-cells = <1>;
> > + device_type = "pci";
> > + compatible = "marvell,mv64360-pci";
> > + cell-index = <1>;
> > + reg = <0x0c78 0x8>;
> > + ranges = <0x01000000 0x0 0x0
> > + 0xb0000000 0x0 0x04000000
> > + 0x02000000 0x0 0x80000000
> > + 0x80000000 0x0 0x30000000>;
> > + bus-range = <0x0 0xff>;
<snip>
> > + };
> > +
> > + pci@f8080000 { /* Required to acces Hotswap register */
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + #interrupt-cells = <1>;
> > + device_type = "pci";
> > + compatible = "marvell,mv64360-pci";
> > + cell-index = <0>;
> > + reg = <0x0cf8 0x8>;
> > + ranges = <0x01000000 0x0 0x0
> > + 0xf8080000 0x0 0x00010000
> > + 0x02000000 0x0 0xf8090000
> > + 0xf8090000 0x0 0x00010000>;
> > + bus-range = <0x0 0xff>;
>
> Two PCI bridges with identical bus-range values seems potentially
> problematic...
Will fix.
> > + };
>
> [snip]
> > + chosen {
> > + bootargs = "ip=on";
>
> The dts file should not include a "bootargs" value. The wrapper will
> fill that in from the kernel config.
Actually, the kernel .config CONFIG_CMDLINE is only used by the kernel
when nothing is passed in from the bootwrapper. The bootwrapper gets
the cmdline from either bootargs or from the __builtin_cmdline section.
I prefer to not rely on CONFIG_CMDLINE because it doesn't afford the
user a chance to edit or add to the cmdline when booting. You can always
type in the whole thing at the "Linux/PowerPC load: " prompt but I'd rather
see what is going to be used and then edit it if I want to. With
CONFIG_CMDLINE, it just gets used if nothing was passed in from the
bootwrapper.
That raises an issue that I've for time time (I've tried to get rid of
__builtin_cmdline before but was unsuccessful).
We currently have 3 possible sources for a default cmdline--seems like
at least one too many.
IMHO we need a way to change the default cmdline in the field so
sysadmins can change it per board and not have to type it in every time
they boot. /chosen/bootargs and __builtin_cmdline can both do that.
We don't need both, though. And, since bootargs is specified by OF
and documented in booting-without-of.txt, can we finally get rid of
__builtin_cmdline? I'd sure like to.
We can probably get rid of CONFIG_CMDLINE too since everyone uses DTs
now and they can have a /chosen/bootargs. Anyone have a reason to keep
CONFIG_CMDLINE around?
Would you mind elaborating on why you are opposed to /chosen/bootargs?
Mark
^ permalink raw reply
* Re: [PATCH] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
From: Scott Wood @ 2008-01-15 18:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <17A215CC-EFAE-41B9-8DB7-C6CDB4E708F2@kernel.crashing.org>
Kumar Gala wrote:
>> Why go out of our way to fail on a childless soc node?
>
> do we see any case in which we'd have a childless soc node?
It's possible that it could be used to communicate immrbase and soc
type, but nothing else. Not overly likely, but possible.
> I'm just concerned about make sure this works for all the various cases
> of #address-cells and #size-cells.
It should. We check the soc's #address-cells to skip the child bus
address, and of_translate_address should take care of looking up the
parent #address-cells. The size portion of the ranges is ignored.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] pasemi: Move electra-ide to pata_of_platform
From: Jeff Garzik @ 2008-01-15 19:42 UTC (permalink / raw)
To: Olof Johansson; +Cc: Paul Mundt, linuxppc-dev, linux-ide
In-Reply-To: <20080115164033.GA25328@lixom.net>
Olof Johansson wrote:
> Move electra-ide glue over to the new pata_of_platform framework, and
> add the quirks needed to that driver.
>
> ---
>
> Applied with the rest of the patches to pasemi.git for-2.6.25
>
> arch/powerpc/platforms/pasemi/electra_ide.c | 96 ----------------------------
> b/arch/powerpc/configs/pasemi_defconfig | 4 -
> b/arch/powerpc/platforms/pasemi/Kconfig | 9 --
> b/arch/powerpc/platforms/pasemi/Makefile | 1
> b/drivers/ata/pata_of_platform.c | 20 ++++-
> 5 files changed, 17 insertions(+), 113 deletions(-)
ACK
^ 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