* use of aliases in device trees
From: Kumar Gala @ 2007-11-04 1:02 UTC (permalink / raw)
To: linux-ppc list; +Cc: U-Boot Users List
In some discussion on the u-boot dev list it became clear that having
aliases in the device tree might be useful as a common way to deal
with finding specific nodes that need fixing up by the firmware.
This problem also exists in the kernel bootwrappers.
The common example is how to associate a given MAC address with the
proper ethernet node. In u-boot an explicit path is hard coded into
the u-boot build for each ethernet device. In the bootwrapper we use
"linux,network-index = <N>" in the given ethernet node.
One common solution would be having a top level aliases like the pmac
tree's have:
aliases {
enet0 = "...";
enet1 = "...";
pci0 = "...";
pci1 = "...";
};
I wanted to see what people think of this idea and about trying to
use common names for the aliases? If nothing else I believe we will
look at doing this on the FSL boards/parts.
- k
^ permalink raw reply
* [PATCH] [POWERPC] iSeries_init_IRQ non-PCI tidy
From: Stephen Rothwell @ 2007-11-04 2:22 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
ppc_md.init_IRQ is not called if it is NULL, so we don't need an empty
routine in the non PCI case.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/irq.h | 4 ++++
arch/powerpc/platforms/iseries/setup.c | 4 ----
2 files changed, 4 insertions(+), 4 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/irq.h b/arch/powerpc/platforms/iseries/irq.h
index 69f1b43..a1c2360 100644
--- a/arch/powerpc/platforms/iseries/irq.h
+++ b/arch/powerpc/platforms/iseries/irq.h
@@ -1,9 +1,13 @@
#ifndef _ISERIES_IRQ_H
#define _ISERIES_IRQ_H
+#ifdef CONFIG_PCI
extern void iSeries_init_IRQ(void);
extern int iSeries_allocate_IRQ(HvBusNumber, HvSubBusNumber, u32);
extern void iSeries_activate_IRQs(void);
+#else
+#define iSeries_init_IRQ NULL
+#endif
extern unsigned int iSeries_get_irq(void);
#endif /* _ISERIES_IRQ_H */
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 37ae07e..0877a88 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -617,10 +617,6 @@ static void iseries_dedicated_idle(void)
}
}
-#ifndef CONFIG_PCI
-void __init iSeries_init_IRQ(void) { }
-#endif
-
static void __iomem *iseries_ioremap(phys_addr_t address, unsigned long size,
unsigned long flags)
{
--
1.5.3.5
^ permalink raw reply related
* [PATCH] [POWERPC] Fix link errors for allyesconfig
From: Stephen Rothwell @ 2007-11-04 2:28 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, David S. Miller
An allyesconfig build creates a .text section that is so big that the
.text.init.refok and .fixup sections are too far away for the relocations
to be fixed up correctly. This patch fixes that by linking all the
relevent text sections for each file together.
Suggested by Paul Mackerras.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/vmlinux.lds.S | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
This still leaves us with the problem that the TOC overflows.
Dave, would something like this help as an alternative to the .fixup
change you committed recently?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 823a8cb..f66fa5d 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -37,11 +37,10 @@ SECTIONS
ALIGN_FUNCTION();
*(.text.head)
_text = .;
- TEXT_TEXT
+ *(.text .fixup .text.init.refok .exit.text.refok)
SCHED_TEXT
LOCK_TEXT
KPROBES_TEXT
- *(.fixup)
#ifdef CONFIG_PPC32
*(.got1)
--
1.5.3.5
^ permalink raw reply related
* Re: 2.6.24-rc1 freezes on powerbook at first boot stage
From: Nathan Lynch @ 2007-11-04 3:20 UTC (permalink / raw)
To: Elimar Riesebieter; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <20071024124109.GA9442@frodo.home.lxtec.de>
(cc'ing linuxppc-dev, see
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg221770.html
for original post and .config)
Elimar Riesebieter wrote:
> On Wed, 24 Oct 2007 the mental interface of
> Elimar Riesebieter told:
>
> [...]
> > The kernel is loaded from firmware but freezes at the moment to load
> > the radeon framebuffer. I can't get any debug info (don't know
> > how?).
>
> Screen dump till freeze:
>
> Using PowerMac machine description
> Total memory = 1024MB; using 2048kB for hash table (at cfe00000)
> Linux version 2.6.24-rc1-aragorn (riesebie@aragorn) (gcc version 4.2.3 20071014 (prelelease) (Debian 4.2.2-3)) #1 Wed Oct 24 12:48:27 CEST 2007
> Found UniNorth memory controller & host bridge @ 0xf8000000 revision: 0xd2
> Mapped at 0xfdfc0000
> Found a Intrepid mac-io controller, rev: 0, mapped at 0xfdf40000
> PowerMac motherboard: PowerBook G4 15"
> console [udbg0] enabled
> setup_arch: bootmem
> Found UniNorth PCI host bridge at 0x00000000f0000000. Firmware bus number: 0->1
> Found UniNorth PCI host bridge at 0x00000000f2000000. Firmware bus number: 0->1
> Found UniNorth PCI host bridge at 0x00000000f4000000. Firmware bus number: 0->1
> via-pmu: Server Mode is disabled
> PMU driver v2 initialized for Core99, firmware: 0c
> nvram: Checking bank 0...
> nvram: gen0=741, gen1=740
> nvram: Active bank is: 0
> nvram: OF partition at 0x410
> nvram: XP partition at 0x1020
> nvram: NR partition at 0x1120
> arch: exit
> Zone PFN ranges:
> DMA 0 -> 196608
> Normal 196608 -> 196608
> HighMem 196608 -> 262144
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0 -> 262144
> Built 1 zonelists in Zone order. Total pages: 260096
> Kernel command line: root=/pci@f4000000/ata-6@d/disk@0:5 root=/dev/hda5
> mpic: Setting up MPIC " MPIC 1 " version 1.2 at 80040000, max 4 CPUs
> mpic: ISU size: 64, shift: 6, mask: 3f
> mpic: Initializing for 64 sources
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> GMT Delta read from XPRAM: 0 minutes, DST: off
> clocksource: timebase mult[d9038e4] shift [22] registered
> clockevent: decremeter mult[4b7] shift[16] cpu[0]
> Console: colour dummy device 80x25
> console handover: boot [udbg0] -> real [tty0]
Does 2.6.23 (or any earlier kernel) work?
^ permalink raw reply
* Re: [U-Boot-Users] use of aliases in device trees
From: Grant Likely @ 2007-11-04 3:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ppc list, David Gibson, U-Boot Users List
In-Reply-To: <DD2A9B2C-5D35-4F53-8542-3470C6FA5265@kernel.crashing.org>
On 11/3/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> In some discussion on the u-boot dev list it became clear that having
> aliases in the device tree might be useful as a common way to deal
> with finding specific nodes that need fixing up by the firmware.
> This problem also exists in the kernel bootwrappers.
>
> The common example is how to associate a given MAC address with the
> proper ethernet node. In u-boot an explicit path is hard coded into
> the u-boot build for each ethernet device. In the bootwrapper we use
> "linux,network-index = <N>" in the given ethernet node.
>
> One common solution would be having a top level aliases like the pmac
> tree's have:
>
> aliases {
> enet0 = "...";
> enet1 = "...";
> pci0 = "...";
> pci1 = "...";
> };
One question to ask is do we use full paths or phandles to point at nodes?
OF, of course, uses full paths, but that does require more memory and
processing power, but it might not be significant enough to worry
about.
If we use phandles, then we should use names that don't conflict with
full path alias names. It would also be desirable to be able to
generate a phandle alias from the full path alias in order to maintain
some level of compatibility with OF. It also think it will make
maintaining aliases in .dts files simpler because trivial changes to
node paths won't break the phandle alias.
Maybe something like:
aliases {
enet0,phandle = <&enet0>;
enet1,phandle = <&enet1>;
...
};
Cheers,
g.
>
> I wanted to see what people think of this idea and about trying to
> use common names for the aliases? If nothing else I believe we will
> look at doing this on the FSL boards/parts.
>
> - k
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Benjamin Herrenschmidt @ 2007-11-04 3:37 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <20071102160304.GA5277@lixom.net>
On Fri, 2007-11-02 at 11:03 -0500, Olof Johansson wrote:
> On Fri, Nov 02, 2007 at 08:14:43AM +0100, Stefan Roese wrote:
> > This patch adds support for the 405EX to the new EMAC driver. Some as on
> > AXON, the 405EX handles the MDIO via the RGMII bridge.
>
> Hi,
>
> This isn't feedback on your patch as much as on "new-emac" in general:
>
> Isn't this the case where there should really be device tree properties
> instead? If you had an "ibm,emac-has-axon-stacr" property in the device
> node, then you don't have to modify the driver for every new board out
> there. Same for the other device properties, of course.
>
> I thought this was what having the device tree was all about. :(
Somewhat yeah. There are subtle variations here or there we haven't
totally indenfified... It might be a better option in our case here to
add "has-mdio" to the rgmii nodes indeed.
Part of the problem with those cells is that the chip folks keep
changing things subtly from one rev to another though, it's not even
totally clear to me yet whether the RGMII registers are totally
compatible betwee axon and 405ex, which is why I've pretty much stuck to
"compatible" properties to identify the variants.
The device-tree can do both. It's still better than no device-tree since
at least you know what cell variant is in there.
As for the STACR, Axon isn't the first one to have that bit flipped, I
think we should name the property differently, something like
"stacr-oc-inverted".
We can still use properties that way for new things in fact. As for EMAC
on cell, well, I can always put some fixup somewhere.
Ben.
^ permalink raw reply
* Re: radeon boot "hot-crash"
From: Benjamin Herrenschmidt @ 2007-11-04 3:39 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev
In-Reply-To: <200711021955.49169.mb@bu3sch.de>
On Fri, 2007-11-02 at 19:55 +0100, Michael Buesch wrote:
> Hi,
>
> I'm wondering how we are finally going to fix my radeon
> "hot-crash" issue.
> Fact is, applying the patch below fixes the issue.
And will break somebody else ...
> Though, I see that this is not the correct patch to fix it.
> Other devices might need the register write which is removed here.
> So what about the following:
> We add a specialcase for the exact type (and revision and so on)
> for my chip here.
> How do find out what's my chiprevision?
> What exactly should be checked for here, so that only this chip
> is affected by the workaround?
I think best is to check for the specific machine. What powerbook model
is this ?
Ben.
>
> Index: wireless-2.6/drivers/video/aty/radeon_i2c.c
> ===================================================================
> --- wireless-2.6.orig/drivers/video/aty/radeon_i2c.c 2007-10-17 18:03:10.000000000 +0200
> +++ wireless-2.6/drivers/video/aty/radeon_i2c.c 2007-10-17 18:18:52.000000000 +0200
> @@ -137,13 +137,7 @@ void radeon_delete_i2c_busses(struct rad
> int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
> u8 **out_edid)
> {
> - u32 reg = rinfo->i2c[conn-1].ddc_reg;
> - u8 *edid;
> -
> - OUTREG(reg, INREG(reg) &
> - ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
> -
> - edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
> + u8 *edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
>
> if (out_edid)
> *out_edid = edid;
>
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix link errors for allyesconfig
From: David Miller @ 2007-11-04 3:47 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071104132839.ea04cf6b.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sun, 4 Nov 2007 13:28:39 +1100
> An allyesconfig build creates a .text section that is so big that the
> .text.init.refok and .fixup sections are too far away for the relocations
> to be fixed up correctly. This patch fixes that by linking all the
> relevent text sections for each file together.
>
> Suggested by Paul Mackerras.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/kernel/vmlinux.lds.S | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> This still leaves us with the problem that the TOC overflows.
>
> Dave, would something like this help as an alternative to the .fixup
> change you committed recently?
It might, I'll make some tests when I get a chance.
Thanks for pointing this out Stephen.
^ permalink raw reply
* Re: [PATCH v2 05/12] [POWERPC] Export mpc52xx_map_node() routine symbol
From: Stephen Rothwell @ 2007-11-04 4:09 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071103235240.31906.93311.stgit@hekate.izotz.org>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
Hi Marian,
On Sun, 04 Nov 2007 00:52:40 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>
> -static void __iomem *
> +void __iomem *
> mpc52xx_map_node(struct device_node *ofn)
> {
> const u32 *regaddr_p;
> @@ -48,6 +48,8 @@ mpc52xx_map_node(struct device_node *ofn)
> return ioremap((u32)regaddr64, (u32)size64);
> }
>
> +EXPORT_SYMBOL(mpc52xx_map_node);
> +
We generally don't leave a blank line between a function an its
EXPORT_SYMBOL(). Also, any reason not to use EXPORT_SYMBOL_GPL?
--
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 v2 10/12] [POWERPC] Motion-PRO: Add LED support.
From: Stephen Rothwell @ 2007-11-04 4:27 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071103235311.31906.23754.stgit@hekate.izotz.org>
[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]
Hi Marian,
On Sun, 04 Nov 2007 00:53:11 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>
> +++ b/drivers/leds/leds-motionpro.c
> @@ -0,0 +1,240 @@
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/leds.h>
> +#include <linux/vmalloc.h>
> +
> +#include <asm/mpc52xx.h>
> +#include <asm/io.h>
> +#include <asm/of_platform.h>
You want <linux/of_platform.h> instead of <asm/..> and probably not
<linux/platform_device.h> above.
> +static void mpled_timer_toggle(unsigned long data)
> +{
> + struct motionpro_led *mpled = (struct motionpro_led *) data;
^
Unnecessary space.
> +static int __devinit mpled_probe(struct of_device *op, const struct of_device_id *match)
Split this line.
> +{
> + struct motionpro_led *mpled;
> + const unsigned int *of_blink_delay = NULL;
You don't need to initialise this as you assign it before you use it.
> + int err = 0;
Same here.
> + if ((err = led_classdev_register(NULL, &mpled->mpled_cdev))) {
We would normally do the assignment separately from the check, so:
err = led_classdev_register(NULL, &mpled->mpled_cdev);
if (err) {
> +static struct of_platform_driver mpled_driver = {
> + .owner = THIS_MODULE,
> + .name = "leds-motionpro",
> + .match_table = mpled_match,
> + .probe = mpled_probe,
> + .remove = mpled_remove,
> +};
You should now use the name and owner fields of the embedded struct
device_driver, so:
static struct of_platform_driver mpled_driver = {
.match_table = mpled_match,
.probe = mpled_probe,
.remove = mpled_remove,
.driver = {
.owner = THIS_MODULE,
.name = "leds-motionpro",
},
};
--
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 v2] pcmcia: Remove replace kio_addr_t with unsigned int everywhere
From: Komuro @ 2007-11-04 9:11 UTC (permalink / raw)
To: Olof Johansson
Cc: Matthew Wilcox, linux-pcmcia, linux-kernel, linuxppc-dev,
Andrew Morton, Christoph Hellwig, Alan Cox
In-Reply-To: <20071028201858.GA10048@lixom.net>
Hi,
It should be "unsigned long" instead of "unsigned int".
64bit architecture uses 64bit-Memory-mapped-IO.
Best Regards
Komuro
>
>
>pcmcia: Remove replace kio_addr_t with unsigned int everywhere
>
>Remove kio_addr_t, and replace it with unsigned int. No known architecture
>needs more than 32 bits for IO addresses and ports and having a separate
>type for it is just messy.
>
>This goes on top of the patch switching the io_req_t members from ioaddr_t
>to unsigned int.
>
>
>Signed-off-by: Olof Johansson <olof@lixom.net>
>
>---
>
>On Sun, Oct 28, 2007 at 03:10:34PM -0500, Olof Johansson wrote:
>
>> This goes on top of the patch switching the io_req_t members from ioaddr_t
>> to unsigned int.
>
>Crap, I had an old version of that patch as base in my local tree when I did
>these edits. Here's a proper version.
>
>-Olof
>
^ permalink raw reply
* Re: use of aliases in device trees
From: Segher Boessenkool @ 2007-11-04 9:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ppc list, U-Boot Users List
In-Reply-To: <DD2A9B2C-5D35-4F53-8542-3470C6FA5265@kernel.crashing.org>
> In some discussion on the u-boot dev list it became clear that having
> aliases in the device tree might be useful as a common way to deal
> with finding specific nodes that need fixing up by the firmware.
> One common solution would be having a top level aliases like the pmac
> tree's have:
>
> aliases {
> enet0 = "...";
> enet1 = "...";
> pci0 = "...";
> pci1 = "...";
> };
It's not just Apple that uses this; this is standard OF stuff.
> I wanted to see what people think of this idea and about trying to
> use common names for the aliases?
I'm obviously all for it, having suggested it myself a few times.
For common names, I think a good starting point would be to use
the generic names (as defined in the "generic names" recommended
practice; this should be the name of the nodes pointed to as well),
followed by a number; and/or a generic name without any suffix,
which points to the "main" device of that type.
This is a lot like your example, except that "enet" isn't a generic
name (that would be "network" I believe). It is perfectly fine to
have to or more aliases pointing to the same node though.
This won't solve all identification problems of course, it only gives
an ordering per class of devices, but in most cases this will be enough,
esp. when platform code uses this. We'll likely need a few extra names
for special cases, but let's use some restraint there, and esp. not
define something as a generic solution when it isn't.
Segher
^ permalink raw reply
* Re: [PATCH v2] Restore deterministic CPU accounting on powerpc
From: Ingo Molnar @ 2007-11-04 9:55 UTC (permalink / raw)
To: Paul Mackerras
Cc: Peter Zijlstra, linuxppc-dev, linux-kernel, Christian Borntraeger,
Martin Schwidefsky, Thomas Gleixner
In-Reply-To: <18220.26005.778223.84644@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> account_process_tick now takes the task_struct * as an argument.
> Tested both with and without CONFIG_VIRT_CPU_ACCOUNTING.
thanks, applied.
Ingo
^ permalink raw reply
* Re: 2.6.24-rc1 freezes on powerbook at first boot stage
From: Elimar Riesebieter @ 2007-11-04 10:38 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <20071104032006.GG9695@localdomain>
On Sat, 03 Nov 2007 the mental interface of
Nathan Lynch told:
> (cc'ing linuxppc-dev, see
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg221770.html
> for original post and .config)
[...]
> > console handover: boot [udbg0] -> real [tty0]
>=20
> Does 2.6.23 (or any earlier kernel) work?
The powerbook runs Linux since 2.6.12. The config is generated
always by make oldconfig and checking new options for meaningful
use. If I have time, I test rc versions.
Thanks for cooperation :)
Elimar
--=20
Experience is something you don't get until=20
just after you need it!
^ permalink raw reply
* Re: [PATCH] Restore deterministic CPU accounting on powerpc
From: Michael Neuling @ 2007-11-04 12:11 UTC (permalink / raw)
To: Balbir Singh
Cc: Peter Zijlstra, Christian Borntraeger, linux-kernel, linuxppc-dev,
Paul Mackerras, Martin Schwidefsky, Ingo Molnar, Thomas Gleixner
In-Reply-To: <661de9470711030202x24d0186cuc96a70156ecfa23f@mail.gmail.com>
> > +#ifndef CONFIG_VIRT_CPU_ACCOUNTING
> > +void account_process_tick(int user_tick)
> > +{
> > + if (user_tick) {
> > + account_user_time(p, jiffies_to_cputime(1));
> > + account_user_time_scaled(p, jiffies_to_cputime(1));
> > + } else {
> > + account_system_time(p, HARDIRQ_OFFSET, jiffies_to_cputime(1
));
> > + account_system_time_scaled(p, jiffies_to_cputime(1));
> > + }
> > +}
> > +#endif
> > +
>
> Hi, Paul,
>
> So, scaled accounting will not be available if
> CONFIG_VIRT_CPU_ACCOUNTING is defined? Am I reading this correctly
Balbir,
Paulus' patch will have merge issues with the scaled time cleanup patch
I posted a week or so back. My cleanup patch is only in akpm's tree at
this stage.
Mikey
^ permalink raw reply
* Problem replacing a Samsung K9F1208U0M NAND flash chip with ST NAND512W3A
From: Santanu Sen @ 2007-11-04 14:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
Facing some trouble replacing a SAMSUNG K9F1208U0M
with an ST NAND512W3A. I know it is criminal, but we
are still using the 2.4 kernel. The excuse is, it is
impossible to port all our code/drivers to 2.6 within
the project deadline.
Here is the story. We could successfully install JFFS2
on a Samsung K9F1208U0M NAND chip mounted on a board
running linux-2.4.20 on a ppc852 processor. But when
we replaced the Samsung chip with an ST NAND512W3A,
creating a JFFS2 partition will no longer work. Raw
read/write to the device is fine. We could even copy a
squashfs image to one of the partitions and mount it
without trouble. But whenever we create a JFFS2
partition, mount it, create a file on it, unmount it
and mount it again the file goes missing. Attaching a
screen-shot of the entire procedure. Note that, the
same steps work fine with Samsung chips. Also, neither
"eraseall" nor "eraseall --jffs2" is of much help in
case of ST. We found some document on the ST site
stating what to do to replace a Samsung chip with an
ST one. The chips are claimed to be equivalent except
that Samsung supports some additional multi-plane
commands. But we could not see those commands being
used anywhere in the mtd code.
Are there anything special to be done for ST NAND
chips?
Any help will be appreciated.
Thanks and Regards,
Santanu
NB: Posting this message here afetr several
unsuccessful attempts to post it on the "jffs2-dev"
mailing list.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[-- Attachment #2: 1173074946-st_jffs2_error --]
[-- Type: application/octet-stream, Size: 7705 bytes --]
Tejas U-Boot PrivateBuild:santanu (Oct 10 2007 - 00:35:55)
CPU: XPC852TxxZPnn-VR66 at 50 MHz: 4 kB I-Cache 4 kB D-Cache FEC present
DRAM: (64 MB SDRAM) 64 MB
I2C: ready
Eeprom header mismatch ...
Board: ..? 00:+0x
Ethernet Address: 00:04:95:00:00:01
Date: 0/00/2000 0:00:00
Reserving 4096k for protected RAM at 03c00000
Top of RAM usable for U-Boot at: 03c00000
Reserving 178k for U-Boot at: 03bd3000
Reserving 2064k for malloc() at: 039cf000
Reserving 444 Bytes for Board Info at: 039cee44
Reserving 48 Bytes for Global Data at: 039cedf0
Stack Pointer at: 039cedd8
Eeprom header mismatch ...
New Stack Pointer is: 039cedd8
Now running in RAM - U-Boot at: 03bd3000
FLASH: 2 MB
Using default environment
In: serial
Out: serial
Err: serial
U-Boot relocated to 03bd3000
NAND: Probing at 0xf8000000
Flash chip found:
Manufacturer ID: 0x20, Chip ID: 0x76 (ST Micro 512W3A2BN6)
1 flash chips found. Total nand_chip size: 64 MB
NAND Flash: 64 MB
Net: FEC ETHERNET
Hit'a' to stop, any other key to autoboot: 0
Tejas-pxat-uboot> boot initrd
Loading from device 0: <NULL> at 0xf8000000 (offset 0x0)
Image Name: Linux Multiboot-Image
Image Type: PowerPC Linux Multi-File Image (gzip compressed)
Data Size: 1509590 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 700108 Bytes = 683.7 kB
Image 1: 809470 Bytes = 790.5 kB
Automatic boot of image at addr 0x00200000 ...
## Booting image at 00200000 ...
Image Name: Linux Multiboot-Image
Image Type: PowerPC Linux Multi-File Image (gzip compressed)
Data Size: 1509590 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 700108 Bytes = 683.7 kB
Image 1: 809470 Bytes = 790.5 kB
Verifying Checksum ... OK
Uncompressing Multi-File Image ... OK
Loading Ramdisk to 03908000, end 039cd9fe ... OK
Linux version 2.4.20-denx-PrivateBuild:santanu (santanu@sephia) (gcc version 2.95.4 20010319 (prerelease/franzo/20011204)) #2 Tue Oct 9 20:50:51 IST 2007
On node 0 totalpages: 15359
zone(0): 15359 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: slram=mtd_tjram01,0x3C00000,+0x400000 console=ttyS0,57600 init=/etc/rc.sh root=/dev/ram rw mtdsize0=0x00040000 mtdparts=a initrd
Decrementer Frequency = 187500000/60
Warning: real time clock seems stuck!
Calibrating delay loop... 49.66 BogoMIPS
Memory: 57584k available (1332k kernel code, 432k data, 56k init, 0k highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
WDT_8xx: SWT not enabled by firmware, SYPCR=0xffffff89
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis Communications AB.
squashfs: version 3.1 (2006/08/19) Phillip Lougher
CPM UART driver version 0.04
ttyS0 on SMC1 at 0x0280, BRG1
pty: 256 Unix98 ptys configured
eth0: FEC ENET Version 0.3, FEC irq 11, with MDIO, addr 00:04:95:00:00:01
eth0: Phy @ 0x0, type RTL8201 (0x00008201)
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
tn100map flash device: 00200000 at 40000000
Amd/Fujitsu Extended Query Table v1.0 at 0x0040
Physically mapped flash: JEDEC Device ID is 0xC4. Assuming broken CFI table.
Physically mapped flash: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
Using tn100_map partition definition
Creating 1 MTD partitions on "Physically mapped flash":
0x00000000-0x00040000 : "uboot"
NAND device: Manufacture ID: 0x20, Chip ID: 0x76 (ST Micro NAND 64MiB 3,3V)
Creating 10 MTD partitions on "NAND 64MiB 3,3V":
0x00000000-0x00200000 : "linux_initrd"
0x00200000-0x00600000 : "rootfs"
0x00600000-0x00a00000 : "backroot"
0x00a00000-0x01e00000 : "software"
0x01e00000-0x03200000 : "backsoft"
0x03200000-0x03600000 : "tejas"
0x03600000-0x03e00000 : "log"
0x03e00000-0x03f00000 : "diag"
0x03f00000-0x03f40000 : "mapper"
0x03f40000-0x03fc0000 : "tomfpga"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
IPv4 over IPv4 tunneling driver
Linux IP multicast router 0.06 plus PIM-SM
ip_conntrack version 2.1 (479 buckets, 3832 max) - 292 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
arp_tables: (C) 2002 David S. Miller
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 790k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 56k init
/bin/mount -t proc proc /proc
mount -t ramfs none /var && mkdir /var/cron /var/lock /var/lock/subsys /var/log /var/run /var/tmp /var/dumps && touch /var/log/wtmp /var/run/utmp
cp -a /dev/* /tmp && mount -t ramfs none /dev && mv /tmp/* /dev
eth0: config: auto-negotiation on, 100HDX, 10HDX.
slram=mtd_tjram01,0x3C00000,+0x400000 console=ttyS0,57600 init=/etc/rc.sh root=/dev/ram rw mtdsize0=0x00040000 mtdparts=a initrd
init started: BusyBox v0.60.5 (2006.05.15-11:55+0000) multi-call
BusyBox v0.60.5 (2006.06.02-06:31+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
source: not found
(none)> eth0: status: link up, 100 Mbps Half Duplex, auto-negotiation complete.
(none)>
(none)> eraseall /dev/mtd8
Erasing 16 Kibyte @ 7fc000 -- 99 % complete.
(none)> mount -t jffs2 /dev/mtdblock8 /tmp/drive1
(none)> cd /tmp/drive1
(none)> echo "aa" > txt
(none)> cat txt
aa
(none)> sync
(none)> cd ..
(none)> umount drive1
(none)> mount -t jffs2 /dev/mtdblock8 drive1
Node header CRC failed at 007f8244. But it must have been OK earlier.
Node was: { ffff, ffff, ffffffff, ffffffff }
Eep. Unknown node type ffff at 007f8270 was marked REF_UNCHECKED
Node header CRC failed at 007f8270. But it must have been OK earlier.
Node was: { ffff, ffff, ffffffff, ffffffff }
(none)> Eep. Unknown node type ffff at 007f8200 was marked REF_UNCHECKED
Node header CRC failed at 007f8200. But it must have been OK earlier.
Node was: { ffff, ffff, ffffffff, ffffffff }
(none)> cd drive1
(none)> ls
(none)>
^ permalink raw reply
* mpc852t boot question!
From: Kugel @ 2007-11-04 16:18 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 277 bytes --]
I made a MPC852T board. I set the HW config word to 0x04600000(D5,D9,D10
pulled up).So the [ISB]=00,
and the IMMR = 0x00000000.
When the CPU is power up, can it boot from external boot flash(39vf040)? Or
just run from internal
memory space(because the IMMR=0x0)?
[-- Attachment #2: Type: text/html, Size: 1306 bytes --]
^ permalink raw reply
* [PATCH] Balance alloc/free and ioremap/iounmap in gpio_mdio_probe (powerpc/platforms/pasemi/gpio_mdio.c)
From: Roel Kluin @ 2007-11-04 16:53 UTC (permalink / raw)
To: linuxppc-dev
I think this is how it should be done, but
please review: it was not tested.
--
Balance alloc/free and ioremap/iounmap
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index dae9f65..f250ba4 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -208,95 +208,116 @@ static int gpio_mdio_write(struct mii_bus *bus, int phy_id, int location, u16 va
}
static int gpio_mdio_reset(struct mii_bus *bus)
{
/*nothing here - dunno how to reset it*/
return 0;
}
-
-static int __devinit gpio_mdio_probe(struct of_device *ofdev,
- const struct of_device_id *match)
+static int __devinit __gpio_mdio_register_bus(struct of_device *ofdev,
+ const struct of_device_id *match)
{
struct device *dev = &ofdev->dev;
struct device_node *np = ofdev->node;
- struct device_node *gpio_np;
struct mii_bus *new_bus;
struct resource res;
struct gpio_priv *priv;
const unsigned int *prop;
- int err = 0;
int i;
- gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
-
- if (!gpio_np)
- return -ENODEV;
-
- err = of_address_to_resource(gpio_np, 0, &res);
- of_node_put(gpio_np);
-
- if (err)
- return -EINVAL;
-
- if (!gpio_regs)
- gpio_regs = ioremap(res.start, 0x100);
-
- if (!gpio_regs)
- return -EPERM;
-
priv = kzalloc(sizeof(struct gpio_priv), GFP_KERNEL);
- if (priv == NULL)
+ if (unlikely(priv == NULL))
return -ENOMEM;
new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
- if (new_bus == NULL)
- return -ENOMEM;
+ if (unlikely(new_bus == NULL))
+ goto free_priv;
new_bus->name = "pasemi gpio mdio bus",
new_bus->read = &gpio_mdio_read,
new_bus->write = &gpio_mdio_write,
new_bus->reset = &gpio_mdio_reset,
prop = of_get_property(np, "reg", NULL);
new_bus->id = *prop;
new_bus->priv = priv;
new_bus->phy_mask = 0;
new_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
+ if (unlikely(new_bus->irq == NULL))
+ goto free_new_bus;
+
for(i = 0; i < PHY_MAX_ADDR; ++i)
new_bus->irq[i] = irq_create_mapping(NULL, 10);
prop = of_get_property(np, "mdc-pin", NULL);
priv->mdc_pin = *prop;
prop = of_get_property(np, "mdio-pin", NULL);
priv->mdio_pin = *prop;
new_bus->dev = dev;
dev_set_drvdata(dev, new_bus);
err = mdiobus_register(new_bus);
- if (0 != err) {
+ if (unlikely(0 != err)) {
printk(KERN_ERR "%s: Cannot register as MDIO bus, err %d\n",
new_bus->name, err);
goto bus_register_fail;
}
return 0;
bus_register_fail:
+ kfree(new_bus->irq);
+free_new_bus:
kfree(new_bus);
+free_priv:
+ kfree(priv);
+
+ return -ENOMEM;
+}
+
+
+static int __devinit gpio_mdio_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *gpio_np;
+ int err;
+
+ gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
+
+ if (!gpio_np)
+ return -ENODEV;
+
+ err = of_address_to_resource(gpio_np, 0, &res);
+ of_node_put(gpio_np);
+
+ if (err)
+ return -EINVAL;
+
+ if (!gpio_regs) {
+
+ gpio_regs = ioremap(res.start, 0x100);
+ if (unlikely(!gpio_regs))
+ return -EPERM;
+
+ err = __gpio_mdio_register_bus(ofdev, match);
+ if (err < 0)
+ iounmap(gpio_regs);
+ } else
+ err = __gpio_mdio_register_bus(ofdev, match);
return err;
+
}
static int gpio_mdio_remove(struct of_device *dev)
{
struct mii_bus *bus = dev_get_drvdata(&dev->dev);
mdiobus_unregister(bus);
^ permalink raw reply related
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Olof Johansson @ 2007-11-04 17:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <1194147479.6511.11.camel@pasglop>
On Sun, Nov 04, 2007 at 02:37:59PM +1100, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-02 at 11:03 -0500, Olof Johansson wrote:
> > On Fri, Nov 02, 2007 at 08:14:43AM +0100, Stefan Roese wrote:
> > > This patch adds support for the 405EX to the new EMAC driver. Some as on
> > > AXON, the 405EX handles the MDIO via the RGMII bridge.
> >
> > Hi,
> >
> > This isn't feedback on your patch as much as on "new-emac" in general:
> >
> > Isn't this the case where there should really be device tree properties
> > instead? If you had an "ibm,emac-has-axon-stacr" property in the device
> > node, then you don't have to modify the driver for every new board out
> > there. Same for the other device properties, of course.
> >
> > I thought this was what having the device tree was all about. :(
>
> Somewhat yeah. There are subtle variations here or there we haven't
> totally indenfified... It might be a better option in our case here to
> add "has-mdio" to the rgmii nodes indeed.
>
> Part of the problem with those cells is that the chip folks keep
> changing things subtly from one rev to another though, it's not even
> totally clear to me yet whether the RGMII registers are totally
> compatible betwee axon and 405ex, which is why I've pretty much stuck to
> "compatible" properties to identify the variants.
>
> The device-tree can do both. It's still better than no device-tree since
> at least you know what cell variant is in there.
Well, it's better than compile-time ifdefs. Providing what version of
the device you have CAN be done without a device tree too. :-)
> As for the STACR, Axon isn't the first one to have that bit flipped, I
> think we should name the property differently, something like
> "stacr-oc-inverted".
Sure, it was the habit of having to modify the driver for platforms that
don't add any new features I was against. I don't really care what the
properties are called :-)
> We can still use properties that way for new things in fact. As for EMAC
> on cell, well, I can always put some fixup somewhere.
Sounds good (with s/can still/should/).
-Olof
^ permalink raw reply
* Re: [PATCH] Balance alloc/free and ioremap/iounmap in gpio_mdio_probe (powerpc/platforms/pasemi/gpio_mdio.c)
From: Nathan Lynch @ 2007-11-04 17:18 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev
In-Reply-To: <472DF914.7020601@tiscali.nl>
Hi,
Roel Kluin wrote:
> I think this is how it should be done, but
> please review: it was not tested.
> --
> Balance alloc/free and ioremap/iounmap
It would be more helpful if your changelog identified the objects
which could be leaked. More comments below.
> -static int __devinit gpio_mdio_probe(struct of_device *ofdev,
> - const struct of_device_id *match)
> +static int __devinit __gpio_mdio_register_bus(struct of_device *ofdev,
> + const struct of_device_id *match)
> {
> struct device *dev = &ofdev->dev;
> struct device_node *np = ofdev->node;
> - struct device_node *gpio_np;
> struct mii_bus *new_bus;
> struct resource res;
> struct gpio_priv *priv;
> const unsigned int *prop;
> - int err = 0;
> int i;
>
> - gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
> -
> - if (!gpio_np)
> - return -ENODEV;
> -
> - err = of_address_to_resource(gpio_np, 0, &res);
> - of_node_put(gpio_np);
> -
> - if (err)
> - return -EINVAL;
> -
> - if (!gpio_regs)
> - gpio_regs = ioremap(res.start, 0x100);
> -
> - if (!gpio_regs)
> - return -EPERM;
> -
> priv = kzalloc(sizeof(struct gpio_priv), GFP_KERNEL);
> - if (priv == NULL)
> + if (unlikely(priv == NULL))
> return -ENOMEM;
Please don't add likely/unlikely to non-hot paths such as this.
> new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
>
> - if (new_bus == NULL)
> - return -ENOMEM;
> + if (unlikely(new_bus == NULL))
> + goto free_priv;
again
>
> new_bus->name = "pasemi gpio mdio bus",
> new_bus->read = &gpio_mdio_read,
> new_bus->write = &gpio_mdio_write,
> new_bus->reset = &gpio_mdio_reset,
>
> prop = of_get_property(np, "reg", NULL);
> new_bus->id = *prop;
> new_bus->priv = priv;
>
> new_bus->phy_mask = 0;
>
> new_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
> + if (unlikely(new_bus->irq == NULL))
> + goto free_new_bus;
> +
again
> for(i = 0; i < PHY_MAX_ADDR; ++i)
> new_bus->irq[i] = irq_create_mapping(NULL, 10);
>
>
> prop = of_get_property(np, "mdc-pin", NULL);
> priv->mdc_pin = *prop;
>
> prop = of_get_property(np, "mdio-pin", NULL);
> priv->mdio_pin = *prop;
>
> new_bus->dev = dev;
> dev_set_drvdata(dev, new_bus);
>
> err = mdiobus_register(new_bus);
>
> - if (0 != err) {
> + if (unlikely(0 != err)) {
again
> printk(KERN_ERR "%s: Cannot register as MDIO bus, err %d\n",
> new_bus->name, err);
> goto bus_register_fail;
> }
>
> return 0;
>
> bus_register_fail:
> + kfree(new_bus->irq);
> +free_new_bus:
> kfree(new_bus);
> +free_priv:
> + kfree(priv);
> +
> + return -ENOMEM;
> +}
> +
> +
> +static int __devinit gpio_mdio_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct device_node *gpio_np;
> + int err;
> +
> + gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
> +
> + if (!gpio_np)
> + return -ENODEV;
> +
> + err = of_address_to_resource(gpio_np, 0, &res);
Hmm, where is "res" defined?
> + of_node_put(gpio_np);
> +
> + if (err)
> + return -EINVAL;
> +
> + if (!gpio_regs) {
> +
Unneeded newline
> + gpio_regs = ioremap(res.start, 0x100);
> + if (unlikely(!gpio_regs))
> + return -EPERM;
> +
> + err = __gpio_mdio_register_bus(ofdev, match);
> + if (err < 0)
> + iounmap(gpio_regs);
> + } else
> + err = __gpio_mdio_register_bus(ofdev, match);
>
> return err;
> +
again
> }
>
>
> static int gpio_mdio_remove(struct of_device *dev)
> {
> struct mii_bus *bus = dev_get_drvdata(&dev->dev);
>
> mdiobus_unregister(bus);
>
^ permalink raw reply
* Re: [PATCH] Balance alloc/free and ioremap/iounmap in gpio_mdio_probe (powerpc/platforms/pasemi/gpio_mdio.c)
From: Olof Johansson @ 2007-11-04 17:47 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev
In-Reply-To: <472DF914.7020601@tiscali.nl>
On Sun, Nov 04, 2007 at 05:53:40PM +0100, Roel Kluin wrote:
> I think this is how it should be done, but
> please review: it was not tested.
Hi,
Thanks for the bug report. The mdio driver needs a set of other cleanups
as well. I have a more comprehensive patch that I'll post tomorrow after
I have a chance to test them.
-Olof
^ permalink raw reply
* Re: [PATCH] Balance alloc/free and ioremap/iounmap in gpio_mdio_probe (powerpc/platforms/pasemi/gpio_mdio.c)
From: Roel Kluin @ 2007-11-04 17:44 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20071104171814.GI9695@localdomain>
Nathan Lynch wrote:
> Hi,
I moved res to the wrong function, that's fixed as well as the unlikely's and
the extra new lines.
Thanks for your quick response. Here is an updated version:
--
Upon errors gpio_regs was not iounmapped, and later priv nor new_bus->irq was
freed. Testing succes of the allocation of new_bus->irq was missing as well.
This patch creates a new function __gpio_mdio_register_bus to allow the
iounmapping after an ioremap.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index dae9f65..af5b241 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -208,68 +208,50 @@ static int gpio_mdio_write(struct mii_bus *bus, int phy_id, int location, u16 va
}
static int gpio_mdio_reset(struct mii_bus *bus)
{
/*nothing here - dunno how to reset it*/
return 0;
}
-
-static int __devinit gpio_mdio_probe(struct of_device *ofdev,
- const struct of_device_id *match)
+static int __devinit __gpio_mdio_register_bus(struct of_device *ofdev,
+ const struct of_device_id *match)
{
struct device *dev = &ofdev->dev;
struct device_node *np = ofdev->node;
- struct device_node *gpio_np;
struct mii_bus *new_bus;
- struct resource res;
struct gpio_priv *priv;
const unsigned int *prop;
- int err = 0;
int i;
- gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
-
- if (!gpio_np)
- return -ENODEV;
-
- err = of_address_to_resource(gpio_np, 0, &res);
- of_node_put(gpio_np);
-
- if (err)
- return -EINVAL;
-
- if (!gpio_regs)
- gpio_regs = ioremap(res.start, 0x100);
-
- if (!gpio_regs)
- return -EPERM;
-
priv = kzalloc(sizeof(struct gpio_priv), GFP_KERNEL);
if (priv == NULL)
return -ENOMEM;
new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
if (new_bus == NULL)
- return -ENOMEM;
+ goto free_priv;
new_bus->name = "pasemi gpio mdio bus",
new_bus->read = &gpio_mdio_read,
new_bus->write = &gpio_mdio_write,
new_bus->reset = &gpio_mdio_reset,
prop = of_get_property(np, "reg", NULL);
new_bus->id = *prop;
new_bus->priv = priv;
new_bus->phy_mask = 0;
new_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
+ if (new_bus->irq == NULL)
+ goto free_new_bus;
+
for(i = 0; i < PHY_MAX_ADDR; ++i)
new_bus->irq[i] = irq_create_mapping(NULL, 10);
prop = of_get_property(np, "mdc-pin", NULL);
priv->mdc_pin = *prop;
prop = of_get_property(np, "mdio-pin", NULL);
@@ -284,17 +266,54 @@ static int __devinit gpio_mdio_probe(struct of_device *ofdev,
printk(KERN_ERR "%s: Cannot register as MDIO bus, err %d\n",
new_bus->name, err);
goto bus_register_fail;
}
return 0;
bus_register_fail:
+ kfree(new_bus->irq);
+free_new_bus:
kfree(new_bus);
+free_priv:
+ kfree(priv);
+
+ return -ENOMEM;
+}
+
+
+static int __devinit gpio_mdio_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *gpio_np;
+ struct resource res;
+ int err;
+
+ gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
+
+ if (!gpio_np)
+ return -ENODEV;
+
+ err = of_address_to_resource(gpio_np, 0, &res);
+ of_node_put(gpio_np);
+
+ if (err)
+ return -EINVAL;
+
+ if (!gpio_regs) {
+ gpio_regs = ioremap(res.start, 0x100);
+ if (unlikely(!gpio_regs))
+ return -EPERM;
+
+ err = __gpio_mdio_register_bus(ofdev, match);
+ if (err < 0)
+ iounmap(gpio_regs);
+ } else
+ err = __gpio_mdio_register_bus(ofdev, match);
return err;
}
static int gpio_mdio_remove(struct of_device *dev)
{
struct mii_bus *bus = dev_get_drvdata(&dev->dev);
^ permalink raw reply related
* Re: [PATCH] Balance alloc/free and ioremap/iounmap in gpio_mdio_probe (powerpc/platforms/pasemi/gpio_mdio.c)
From: Roel Kluin @ 2007-11-04 17:46 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071104174701.GB10191@lixom.net>
Olof Johansson wrote:
> On Sun, Nov 04, 2007 at 05:53:40PM +0100, Roel Kluin wrote:
>> I think this is how it should be done, but
>> please review: it was not tested.
>
> Hi,
>
> Thanks for the bug report. The mdio driver needs a set of other cleanups
> as well. I have a more comprehensive patch that I'll post tomorrow after
> I have a chance to test them.
Ok, that's fine with me,
Roel
^ permalink raw reply
* Re: [PATCH 0/3] Add device-tree aware NDFC driver
From: Thomas Gleixner @ 2007-11-04 20:48 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, sr, linux-mtd
In-Reply-To: <47273BF4.80001@ru.mvista.com>
Valentine,
On Tue, 30 Oct 2007, Valentine Barshak wrote:
> Thomas Gleixner wrote:
> > On Mon, 29 Oct 2007, Valentine Barshak wrote:
> >
> > > This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
> > > The code is based on the original NDFC driver by Thomas Gleixner, but
> > > since it's been changed much and has initialization/clean-up completely
> > > reworked it's been put into a separate ndfc_of.c file. This version
> > > supports both separate mtd devices on each chip attached to NDFC banks and
> > > single mtd device spread across identical chips (not using mtdconcat) as
> > > well.
> > > The choice is selected with device tree settings. This has been tested
> > > on PowerPC 440EPx Sequoia board.
> > > Any comments are greatly appreciated.
> >
> > Did I express myself not clear enough in my first reply or is this
> > just a repeated epiphany in my inbox ?
> > You got plenty of comments to your patches, but you decided to ignore
> > them silently.
> >
> > Darn, fix it the right way once and forever and please don't try to
> > tell me another heartrending "why I did it my way" story.
> >
> > This all can be done with a nice series of incremental patches
> > including a fixup to the existing users.
> >
> > We have enough dump and run shit in the kernel already.
> >
> > No thanks,
> >
> > tglx
>
> You know, you're really too tense Thomas. I'm not sure of the reason why
> you're being a complete nerve, but I'm feeling sorry for you.
You have a perception problem. I'm not tense, I'm grumpy.
Rest assured, that my nerves are completely fine despite of the fact
that you try to rack them.
> I'm not saying my approach is the best, but I was hoping for a discussion.
> I've reworked the patches according to the comments to the previous version
> and used my arguments to explain why I don't see much reason to mess with the
> code we currently have and added a separate _of version.
This is the exact point. You were asked to fix up the existing driver
instead of replacing it and to do it with a series of incremental
patches. You copied the old code anyway and modified it, so we want to
have this documented in the history. This is not my obsession, it's
common kernel coding practise. The fact that you do not see much
reason to do it does not change this at all.
> I'm sure you'd find some time to do it yourself "the right way once and
> forever" with a "nice series of incremental patches" to fix what we currently
> have (call it a "dump" or anything you like) and even maybe add new device
> tree support.
It might be time for you to try to understand how OSS development
works.
> I'm sorry if for some reason I've made you feel bad.
What do you expect, after you abused my Signed-off-by in a way which
might have tricked David into pulling your code as is? This was
pointed out to you and you did not even bother to apologize.
> This is the last time I disturb you with my e-mail, so please, forget it.
Interesting. I thought you wanted to get the patch in, so you probably
should ask yourself whether it is a good idea _not_ to talk to the
responsible maintainer.
If you gave up on that, it just makes it more obvious that you do not
want to work with the community and just wanted to dump your patch and
move along.
tglx
^ permalink raw reply
* [PATCH] pasemi: clean up gpio_mdio init
From: Olof Johansson @ 2007-11-04 21:37 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev
In-Reply-To: <472E0569.7070601@tiscali.nl>
pasemi: clean up mdio_gpio driver init
Misc cleanups of mdio_gpio:
* Better error handling/unrolling in case of init/alloc failures
* Go through child nodes and get their interrupts instead of using
hardcoded values
* Remap the GPIO registers at module load/driver init instead of during probe
* Coding style and other misc cleanups
Signed-off-by: Olof Johansson <olof@lixom.net>
---
On Sun, Nov 04, 2007 at 06:46:17PM +0100, Roel Kluin wrote:
> Olof Johansson wrote:
> > On Sun, Nov 04, 2007 at 05:53:40PM +0100, Roel Kluin wrote:
> >> I think this is how it should be done, but
> >> please review: it was not tested.
> >
> > Hi,
> >
> > Thanks for the bug report. The mdio driver needs a set of other cleanups
> > as well. I have a more comprehensive patch that I'll post tomorrow after
> > I have a chance to test them.
>
> Ok, that's fine with me,
This is what I'll queue up for 2.6.25.
-Olof
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index dae9f65..2254091 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -218,45 +218,27 @@ static int __devinit gpio_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
struct device *dev = &ofdev->dev;
- struct device_node *np = ofdev->node;
- struct device_node *gpio_np;
+ struct device_node *phy_dn, *np = ofdev->node;
struct mii_bus *new_bus;
- struct resource res;
struct gpio_priv *priv;
const unsigned int *prop;
- int err = 0;
+ int err;
int i;
- gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
-
- if (!gpio_np)
- return -ENODEV;
-
- err = of_address_to_resource(gpio_np, 0, &res);
- of_node_put(gpio_np);
-
- if (err)
- return -EINVAL;
-
- if (!gpio_regs)
- gpio_regs = ioremap(res.start, 0x100);
-
- if (!gpio_regs)
- return -EPERM;
-
+ err = -ENOMEM;
priv = kzalloc(sizeof(struct gpio_priv), GFP_KERNEL);
- if (priv == NULL)
- return -ENOMEM;
+ if (!priv)
+ goto out;
new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
- if (new_bus == NULL)
- return -ENOMEM;
+ if (!new_bus)
+ goto out_free_priv;
- new_bus->name = "pasemi gpio mdio bus",
- new_bus->read = &gpio_mdio_read,
- new_bus->write = &gpio_mdio_write,
- new_bus->reset = &gpio_mdio_reset,
+ new_bus->name = "pasemi gpio mdio bus";
+ new_bus->read = &gpio_mdio_read;
+ new_bus->write = &gpio_mdio_write;
+ new_bus->reset = &gpio_mdio_reset;
prop = of_get_property(np, "reg", NULL);
new_bus->id = *prop;
@@ -265,9 +247,24 @@ static int __devinit gpio_mdio_probe(struct of_device *ofdev,
new_bus->phy_mask = 0;
new_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
- for(i = 0; i < PHY_MAX_ADDR; ++i)
- new_bus->irq[i] = irq_create_mapping(NULL, 10);
+ if (!new_bus->irq)
+ goto out_free_bus;
+
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ new_bus->irq[i] = NO_IRQ;
+
+ for (phy_dn = of_get_next_child(np, NULL);
+ phy_dn != NULL;
+ phy_dn = of_get_next_child(np, phy_dn)) {
+ const int *ip, *regp;
+
+ ip = of_get_property(phy_dn, "interrupts", NULL);
+ regp = of_get_property(phy_dn, "reg", NULL);
+ if (!ip || !regp)
+ continue;
+ new_bus->irq[*regp] = irq_create_mapping(NULL, *ip);
+ }
prop = of_get_property(np, "mdc-pin", NULL);
priv->mdc_pin = *prop;
@@ -280,17 +277,21 @@ static int __devinit gpio_mdio_probe(struct of_device *ofdev,
err = mdiobus_register(new_bus);
- if (0 != err) {
+ if (err != 0) {
printk(KERN_ERR "%s: Cannot register as MDIO bus, err %d\n",
new_bus->name, err);
- goto bus_register_fail;
+ goto out_free_irq;
}
return 0;
-bus_register_fail:
+out_free_irq:
+ kfree(new_bus->irq);
+out_free_bus:
kfree(new_bus);
-
+out_free_priv:
+ kfree(priv);
+out:
return err;
}
@@ -330,12 +331,23 @@ static struct of_platform_driver gpio_mdio_driver =
int gpio_mdio_init(void)
{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
+ if (!np)
+ return -ENODEV;
+ gpio_regs = of_iomap(np, 0);
+ if (!gpio_regs)
+ return -ENODEV;
+
return of_register_platform_driver(&gpio_mdio_driver);
}
+module_init(gpio_mdio_init);
void gpio_mdio_exit(void)
{
of_unregister_platform_driver(&gpio_mdio_driver);
+ if (gpio_regs)
+ iounmap(gpio_regs);
}
-device_initcall(gpio_mdio_init);
-
+module_exit(gpio_mdio_exit);
^ 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