* Re: [PATCH] balance ioremap/iounmap in {sycamore, walnut}_setup_arch()
From: Roel Kluin @ 2007-11-09 12:32 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <47333EDA.4080907@ru.mvista.com>
Valentine Barshak wrote:
> Roel Kluin wrote:
>> I guess it should be done after the last usage of kb_data or fpga_status?
>
> I think no iounmap(kb_data) needed. Looks like the pointer kn_cs (kb_cs
> = kb_data + 1) is used by the serio driver
> (drivers/input/serio/i8042-ppcio.h).
> Please note that we just ioremap and assign pointers here, not actually
> reading the registers.
> Also, looks like you unmap the fpga registers too early.
> Thanks,
> Valentine.
Thanks for your pointers. I'm new, so I'm not sure how this should be done. I
have removed the iounmap(kb_data), and moved the iounmap(fpga_status) lower.
possibly the latter could be done before the sycamore_rtc_base assignment?
--
Balance ioremap/iounmap
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c
index 8689f3e..6ce4815 100644
--- a/arch/ppc/platforms/4xx/sycamore.c
+++ b/arch/ppc/platforms/4xx/sycamore.c
@@ -132,6 +132,7 @@ sycamore_setup_arch(void)
sycamore_rtc_base = (void *) SYCAMORE_RTC_VADDR;
TODC_INIT(TODC_TYPE_DS1743, sycamore_rtc_base, sycamore_rtc_base,
sycamore_rtc_base, 8);
+ iounmap(fpga_status);
/* Identify the system */
printk(KERN_INFO "IBM Sycamore (IBM405GPr) Platform\n");
^ permalink raw reply related
* RE: Bootloader & Flash
From: MingLiu @ 2007-11-09 12:51 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <47344D70.4050308@fz-juelich.de>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
Hi,
> - I have download the zImage.elf via the EDK flash loader> - The flash loader creates a bootloader, this is also running on start up :)
What you need to store in flash memory, is not the .elf file. Before you use EDK flash loader to burn your linux kernel in flash, .elf file should be transfered into .srec file, just like the below reminds you: SREC line is corrupted.
> But ... It stops with an error-message after a few seconds:> > EDK Bootloader:> Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is corrupted> > What now ?
Hopefully it helps.
BR
Ming
_________________________________________________________________
Windows Live Spaces 中最年轻的成员！
http://miaomiaogarden2007.spaces.live.com/
[-- Attachment #2: Type: text/html, Size: 1005 bytes --]
^ permalink raw reply
* Appletouch going wild
From: Andreas Schwab @ 2007-11-09 12:58 UTC (permalink / raw)
To: linux-input; +Cc: linuxppc-dev
Every once in a while the touchpad in my iBook G4 (geyser1, 030B) is
going wild, emitting random movement events even when not being touched.
That started only with 2.6.24-rc1. The only way to stop it is to reload
the appletouch module. My guess would be that reinitializing the
touchpad can result in some kind of race condition.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* auto soft reset after kernel crash?
From: robert lazarski @ 2007-11-09 13:25 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm trying to read the __log_buf after a kernel crash on a custom
board via a software reset. While I'm waiting for the hardware guys to
give me a sw reset button, I've noticed that the particular 2.6.22
kernel I'm using software resets itself around 7 minutes after a
crash. I tried a 2.6.23 kernel to see if my problem was related to
kernel version and it doesn't reset itself. Is this reset indeed a
kernel feature? How do I enable / disable it and set the amount of
time it waits before it resets? I went thru the menuconfig features
and couldn't enable a sw reset. Any ideas?
Thanks,
Robert
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:25 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071108131135.e16a2f9a.kim.phillips@freescale.com>
On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
[...]
> right, but whether it does or not doesn't affect your failure outcome
> either I'm assuming.
>
> > > If it's something like 0x03, the u-boot patch will probably look like:
> > >
> > > if ((bcsr[12] == 0x10) &&
> > > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > > immr->sysconf.spridr == SPR_8360E_REV21))
> > > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > > ...
> > >
> > > but these linux patches would remain the same (the clk and data delay
> > > settings for the UCC's are still valid; it's just the PHY config
> > > that is triggering your problem from what I can tell).
> >
> > Yup, most likely this is not UCC specific, but PHY. For some reason
> > delays making harm here...
And today I was unable to reproduce yesterday's behaviour. Your
patches works fine, with sixth patch and without it. With -rxid
and with just -id.
Though, after few resets I hit on that:
- - - -
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
Reset Status: External/Internal Soft, External/Internal Hard
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM: 256 MB (DDR2, 64-bit, ECC on)
SDRAM: 64 MB (local bus)
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
FSL UEC0: Full Duplex
switching to rgmii 100
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
read wrong value : mii_id 1,mii_reg 2, base e0103120
read wrong value : mii_id 1,mii_reg 3, base e0103120
UEC: PHY is Generic MII (ffffffff)
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 5, base e0103120
FSL UEC1: Full Duplex
switching to rgmii 100
FSL UEC1: Speed 100BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
- - - -
And UCC1 does not work at all. After another reset that message
disappears and it does work again.
So, I think hardware is tricking me in various ways, not your
patches fault.
:-(
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] ehea: Add kdump support
From: Thomas Klein @ 2007-11-09 13:33 UTC (permalink / raw)
To: Jeff Garzik
Cc: Michael Neuling, Jan-Bernd Themann, netdev, linux-kernel,
linux-ppc, Christoph Raisch, Paul Mackerras, Marcus Eder,
Stefan Roscher
To support ehea driver reloading in a kdump kernel the driver has to perform
firmware handle deregistrations when the original kernel crashes. As there's
currently no notifier chain for machine crashes this patch enables kdump support
in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its own
machine crash handler. The original machine_crash_shutdown() fn is called
afterwards. This works fine as long as the ehea driver is the only one which
does so. Problems may occur if other drivers do the same and unload regularly.
This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very
low risk on base kernel. In 2.6.24 we know ehea is the only user of this
mechanism. The next step for 2.6.25 would be to add a proper notifier chain.
The full solution might be that register_reboot_notifier() provides sth
like a SYS_CRASH action. Please apply.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0080"
+#define DRV_VERSION "EHEA_0081"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..40a732e 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -37,6 +37,7 @@
#include <linux/reboot.h>
#include <net/ip.h>
+#include <asm-powerpc/machdep.h>
#include "ehea.h"
#include "ehea_qmr.h"
@@ -98,6 +99,7 @@ static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
struct work_struct ehea_rereg_mr_task;
+static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
struct semaphore dlpar_mem_lock;
@@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
.notifier_call = ehea_reboot_notifier,
};
+void ehea_crash_notifier(struct pt_regs *regs)
+{
+ ehea_info("Machine crash: freeing all eHEA resources");
+ ibmebus_unregister_driver(&ehea_driver);
+ orig_machine_crash_shutdown(regs);
+}
+
+void ehea_register_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ orig_machine_crash_shutdown =
+ (void*)__xchg_u64((unsigned long*)&ppc_md.machine_crash_shutdown,
+ (unsigned long)ehea_crash_notifier);
+#endif
+}
+
+void ehea_unregister_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
+#endif
+}
+
static int check_module_parm(void)
{
int ret = 0;
@@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
goto out;
register_reboot_notifier(&ehea_reboot_nb);
+ ehea_register_crash_notifier();
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
@@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ibmebus_unregister_driver(&ehea_driver);
goto out;
}
@@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ehea_destroy_busmap();
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:33 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> Hello all,
>
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below). Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
>
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me). I'm hoping they're
> trivial enough to go in 2.6.24.
All five patches are
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Let's hope they'll hit 2.6.24.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Grant Likely @ 2007-11-09 13:57 UTC (permalink / raw)
To: Domen Puncer, Jeff Garzik; +Cc: PowerPC dev list, netdev
In-Reply-To: <20071109091245.GA3148@nd47.coderock.org>
On 11/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > This is the reason I couldn't get user space started or connect to my
> > nfs server. Patch is against current linus git.
> >
> > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > where the wrong skb buffer was being referenced.
> >
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Acked-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Jeff, can you please pick this up for .24?
Thanks,
g.
>
> I can't test it at the moment, but the patch is obviously correct,
> mapped buffer should be the _same_ as submitted.
>
> >
> > ---
> >
> > drivers/net/fec_mpc52xx.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> >
> > diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> > index a8a0ee2..ddfcc0b 100644
> > --- a/drivers/net/fec_mpc52xx.c
> > +++ b/drivers/net/fec_mpc52xx.c
> > @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> >
> > rskb =3D bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> > (struct bcom_bd **)&bd);
> > - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FRO=
M_DEVICE);
> > + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FR=
OM_DEVICE);
> >
> > /* Test for errors in received frame */
> > if (status & BCOM_FEC_RX_BD_ERRORS) {
> > @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> > bcom_prepare_next_buffer(priv->rx_dmatsk);
> >
> > bd->status =3D FEC_RX_BUFFER_SIZE;
> > - bd->skb_pa =3D dma_map_single(&dev->dev, rskb->data,
> > + bd->skb_pa =3D dma_map_single(&dev->dev, skb->data,
> > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> >
> > bcom_submit_next_buffer(priv->rx_dmatsk, skb);
> >
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
>
> --
> Domen Puncer | Research & Development
> .........................................................................=
....................
> Telargo d.o.o. | Zagreb=9Aka cesta 20 | 2000 Maribor | Slovenia
> .........................................................................=
....................
> www.telargo.com
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-09 14:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071107133426.63593b98.sfr@canb.auug.org.au>
Hi Stephen,
Stephen Rothwell wrote:
>
> On Tue, 06 Nov 2007 21:05:20 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
>> +
>> +#include <linux/pci.h>
>> +#include <linux/of.h>
>> +#include <asm/time.h>
>> +#include <asm/io.h>
>
> Its not clear to me that you need any of the above four includes.
#include <asm/time.h> is needed for generic_calibrate_decr() but other
few includes are in fact not necessary. Thanks.
Cheers,
m.
^ permalink raw reply
* Re: [PATCH v3 07/13] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-11-09 14:15 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071106223646.GD31367@localhost.localdomain>
David Gibson wrote:
> On Tue, Nov 06, 2007 at 09:05:48PM +0100, Marian Balakowicz wrote:
>> Add device tree source file for TQM5200 board.
> [snip]
>> + usb@1000 {
>> + device_type = "usb-ohci-be";
>
> This device_type is bogus. Remember having a valid device_type is the
> exception not the rule. Really the only common device_type values are
> "cpu", "memory", "network" and "serial".
Ok, rechecked this one, doesn't seem necessary, removed.
>> + serial@2000 { // PSC1
>> + device_type = "serial";
>> + compatible = "mpc5200-psc-uart";
>> + port-number = <0>; // Logical port assignment
>
> I know you said this is still needed, but the driver really needs to
> be fixed. This is not a proper way of using the device tree for
> logical numbering.
True, driver needs fixing, but there are also other boards that use
that driver, and I am not able to test them right now. And, as I
recall Grant mentioned that he's working on straightening this up.
Cheers,
m.
^ permalink raw reply
* Re: Bootloader & Flash
From: schardt @ 2007-11-09 14:16 UTC (permalink / raw)
To: MingLiu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-W21A6D92355C81BE1341628B2840@phx.gbl>
Argl :)
The error was so ... simple.
The Flash device is broken. I take a new MiniModul and all things are
running.
Thanks a lot
Georg
MingLiu wrote:
> Hi,
>
> > - I have download the zImage.elf via the EDK flash loader
> > - The flash loader creates a bootloader, this is also running on
> start up :)
>
> What you need to store in flash memory, is not the .elf file. Before
> you use EDK flash loader to burn your linux kernel in flash, .elf file
> should be transfered into .srec file, just like the below reminds you:
> SREC line is corrupted.
>
>
> > But ... It stops with an error-message after a few seconds:
> >
> > EDK Bootloader:
> > Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is
> corrupted
> >
> > What now ?
>
> Hopefully it helps.
>
> BR
> Ming
>
> -----------------------------------------------------------------------=
-
> =D3=C3 Windows Live Spaces =D5=B9=CA=BE=B8=F6=D0=D4=D7=D4=CE=D2=A3=AC=D3=
=EB=BA=C3=D3=D1=B7=D6=CF=ED=C9=FA=BB=EE=A3=A1 =C1=CB=BD=E2=B8=FC=B6=E0=D0=
=C5=CF=A2=A3=A1
> <http://spaces.live.com/?page=3DHP>
-------------------------------------------------------------------------=
----------------
-------------------------------------------------------------------------=
----------------
Forschungszentrum J=A8=B9lich GmbH
52425 J=A8=B9lich
Sitz der Gesellschaft: J=A8=B9lich
Eingetragen im Handelsregister des Amtsgerichts D=A8=B9ren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in B"arbel Brumme-Bothe
Gesch"aftsf=A8=B9hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich=
Krafft (stellv.=20
Vorsitzender)
-------------------------------------------------------------------------=
----------------
-------------------------------------------------------------------------=
----------------
^ permalink raw reply
* RE: Bootloader & Flash
From: MingLiu @ 2007-11-09 14:19 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <47346BB7.2000009@fz-juelich.de>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
Sometimes the simplest error is the most diffucult one to be found. :)
Have fun.
BR
Ming
> Date: Fri, 9 Nov 2007 15:16:23 +0100> From: g.schardt@fz-juelich.de> To: eemingliu@hotmail.com> CC: linuxppc-embedded@ozlabs.org> Subject: Re: Bootloader & Flash> > Argl :)> > The error was so ... simple.> The Flash device is broken. I take a new MiniModul and all things are> running.> > Thanks a lot> Georg> > MingLiu wrote:> > Hi,> >> > > - I have download the zImage.elf via the EDK flash loader> > > - The flash loader creates a bootloader, this is also running on> > start up :)> >> > What you need to store in flash memory, is not the .elf file. Before> > you use EDK flash loader to burn your linux kernel in flash, .elf file> > should be transfered into .srec file, just like the below reminds you:> > SREC line is corrupted.> >> >> > > But ... It stops with an error-message after a few seconds:> > >> > > EDK Bootloader:> > > Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is> > corrupted> > >> > > What now ?> >> > Hopefully it helps.> >> > BR> > Ming> >> > ------------------------------------------------------------------------> > 用 Windows Live Spaces 展示个性自我，与好友分享生活！ 了解更多信息！> > <http://spaces.live.com/?page=HP>> > > > -----------------------------------------------------------------------------------------> -----------------------------------------------------------------------------------------> Forschungszentrum Jülich GmbH> 52425 Jülich> > Sitz der Gesellschaft: Jülich> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498> Vorsitzende des Aufsichtsrats: MinDirig'in B"arbel Brumme-Bothe> Gesch"aftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. > Vorsitzender)> -----------------------------------------------------------------------------------------> -----------------------------------------------------------------------------------------
_________________________________________________________________
Windows Live Spaces 中最年轻的成员！
http://miaomiaogarden2007.spaces.live.com/
[-- Attachment #2: Type: text/html, Size: 2852 bytes --]
^ permalink raw reply
* Re: [PATCH v3 12/13] [POWERPC] Promess Motion-PRO DTS
From: Marian Balakowicz @ 2007-11-09 14:22 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071106224200.GE31367@localhost.localdomain>
David Gibson wrote:
> On Tue, Nov 06, 2007 at 09:06:34PM +0100, Marian Balakowicz wrote:
>> Add device tree source file for Motion-PRO board.
> [snip]
>> + motionpro-statusled@660 { // Motion-PRO status LED
>> + compatible = "promess,motionpro-statusled";
>> + reg = <660 10>;
>> + interrupts = <1 f 0>;
>> + interrupt-parent = <&mpc5200_pic>;
>> + blink-delay = <64>; // 100 msec
>> + };
>> +
>> + motionpro-readyled@670 { // Motion-PRO ready LED
>> + compatible = "promess,motionpro-readyled";
>> + reg = <670 10>;
>> + interrupts = <1 10 0>;
>> + interrupt-parent = <&mpc5200_pic>;
>> + };
>
> Is there actually any difference in behaviour betweeen the two LEDs?
> If not, they should probably have the same compatible value, and
> perhaps a "label" property or some such to associate them with a
> particular LED.
In fact they are identical, so I have used the same compatible
property and added label property do distinguish them.
> [snip]
>> + spi@f00 {
>> + device_type = "spi";
>
> No device_type!
Removed.
>> + compatible = "mpc5200b-spi","mpc5200-spi";
>> + reg = <f00 20>;
>> + interrupts = <2 d 0 2 e 0>;
>> + interrupt-parent = <&mpc5200_pic>;
>> + };
>> +
>> + usb@1000 {
>> + device_type = "usb-ohci-be";
>
> Nor here.
Removed.
> [snip]
>> + // PSC2 in spi master mode
>> + spi@2200 { // PSC2
>> + compatible = "mpc5200b-psc-spi","mpc5200-psc-spi";
>> + cell-index = <1>;
>
>>From your description, this is an incorrect usage of cell-index - it
> should *only* be used to index into SoC shared registers; never for
> logical numbering.
Again true, but the situation is similar to the one with the "serial"
node.
Cheers,
m.
^ permalink raw reply
* Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
From: Jon Loeliger @ 2007-11-09 14:32 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071109001345.GD18592@localhost.localdomain>
So, like, the other day David Gibson mumbled:
>
> But you do take a hit w.r.t. *minimum* representation size - there's
> no form amongst all the possibilities here more compact than pure hex.
> Especially since spaces are optional in the old form. The fact that
> [ab cd 00] and [abcd00] are equivalent was a deliberate choice in the
> original form.
>
> The point of [] is for random binary data which is neither strings
> (even with the odd strange character) nor sensibly organized into
> 32-bit (or larger) integers. Wanting something other than hex here is
> much rarer than in the < > case.
>
> You're seeing < > and [ ] as basically the same thing - a list of
> values - with the only difference being the size of those values.
> That's not wrong, but it's not the only way to look at it - and it's
> not the way I was thinking of [ ] when I invented it. Your proposal
> makes perfect sense while you think of [] as a list of values - but
> not so much when it's thought of as a direct binary representation.
>
> So I'm thinking perhaps we need two different things here: a "list of
> values" representation, which can accomodate expressions and can also
> have multiple sizes (because expressions which are evaluated to a
> 16-bit or 64-bit value could also be useful under the right
> circumstances), and the [ ] "bytestring
> literal" representation. Perhaps something like:
>
> (32-bit values)
> <0xdeadbeef (1+1)>
> or <.32 0xdeadbeef (1+1)>
>
> (64-bit values)
> <.64 (0xdeadbeef << 32) (-1)>
> (8-bit values)
> <.8 0x00 0x0a 0xe4 0x2c 0x23 (0x10 + n)>
>
> i.e. < > is list of values form, with size of each value as a sort of
> parameter (defaulting to 32-bit, of course). I'm not sure I like that
> particular syntax, it's just the first thing I came up with to
> demonstrate the idea.
Ah ha! I see. You want this, then:
x = <.srec 0000 C001C0DEGE75BABE F1>
OK. That was entirely joking. We all know that
the cool code does NOT get the babe.
Seriously though, I see your point, and I don't really
have a strong opinion here, so in the interest of making
some headway, we can just leave it as is for now.
If it turns out to be a bad decision later, we'll fix it. :-)
And with that issue behind us....
I'm going to post these patches to introduce the new DTS format!
Any last straggler comments?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-09 14:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40711061525y79f9f99eneda32b09a77ddcd5@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> On 11/6/07, Wolfgang Denk <wd@denx.de> wrote:
>>
>> in message <fa686aa40711061304k4779d01cu7fd1b17d1d34e5a2@mail.gmail.com> you wrote:
>>> In other words; make the assumption that it is easier to change the
>>> kernel than it is to change the device tree.
>> Are you serious about this?
>>
>> Reading this from someone with your experience with device trees if
>> feeding my worst fears...
>
> I think I better clarify.
>
> Once a device tree is written and shipped on a deployed board, it may
> never change again. Or, the kernel version may be updated more
> frequently than the device tree.
>
> Say, for example, that in kernel 2.6.25 tqm5200 and cm5200 are both
> handled by the same platform code. And lets say that in 2.6.26 we
> decide that they really need to have separate platform code (perhaps
> due to a firmware bug that needs to be worked around on one board).
> In this case, "mpc5200-simple-platform" has suddenly become useless.
> Or, does mpc5200-simple-platform now describe the cm5200 or the
> tqm5200? (an assumption which cannot be made due to deployed boards
> of both types claiming "mpc5200-simple-platform").
>
> Trying to claim "compatible" at the board level is far more difficult
> than claiming it at the device level.
>
> Segher suggested on IRC: "for boards it is pretty much useless most of
> the time, i think -- use "model" instead"
I can imagine that we may get into various trouble (or at least the
situation is less flexible) if we are unable to update .dts file along
with the kernel image on a deployed board. If so, then in fact there
is little sens in using "mpc5200-simple-platform" compatible.
But how serious is that, does such situation frequently happen in
field? If we are able to update kernel image than what prevents .dts
file update?
Cheers,
m.
^ permalink raw reply
* Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Grant Likely @ 2007-11-09 14:52 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4734721A.6030603@semihalf.com>
On 11/9/07, Marian Balakowicz <m8@semihalf.com> wrote:
> I can imagine that we may get into various trouble (or at least the
> situation is less flexible) if we are unable to update .dts file along
> with the kernel image on a deployed board. If so, then in fact there
> is little sens in using "mpc5200-simple-platform" compatible.
>
> But how serious is that, does such situation frequently happen in
> field? If we are able to update kernel image than what prevents .dts
> file update?
Not everything in the device tree is in the .dts file. U-boot or
other firmware can modify the device tree before passing it to the
kernel. It may not always be possible to update the device tree
without also updating the firmware. I already know of changes that
I'd like to make to the lite5200 tree which I know will break u-boot.
That isn't the situation in this particular case, but we must always
keep it in mind.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
From: Scott Wood @ 2007-11-09 15:59 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4733AF6B.60807@gmail.com>
Jerry Van Baren wrote:
> My concern from the u-boot side is that u-boot has to know exactly
> *where* to put the expanded blob because it has to pass it to linux and
> keep it out of linux' way so it doesn't get "stepped on." Linux has an
> advantage in that it "owns" all of memory and can allocate and
> deallocate whatever and wherever and it won't step on itself (hopefully).
Linux is pretty careful not to step on the device tree; it marks the
area as reserved, and moves it if it really has to. The only scenario I
think would be problematic is if the kernel is started somewhere other
than zero, and has to relocate itself, and the relocation clobbers the
device tree. That's easily avoided by making sure the device tree is at
a higher address than the kernel -- and is really not much different
than the old bd_t mechanism, which didn't use a user provided address AFAIK.
> I'm assuming your boot wedge has the advantage of being able to use
> linux's malloc() and thus don't have to worry about coordinating with
> linux on memory allocation.
No, it uses its own malloc.
> With the current u-boot fdt command, you can resize the blob, and this
> can be done in a script with all the (somewhat limited) capabilities of
> the u-boot shell (an adaptation of hush).
OK, I'm just going by the behavior of the default boot commands on (at
least some of) our boards, which just give you an error if the blob
isn't already enlarged.
Maybe I should just poke Kim et al. about fixing our default environment
-- though I'm guessing it'd still have to know from the script how much
to enlarge the blob.
> In the u-boot world, we fixate on memory maps and putting things in
> specific places.
I've noticed. :-)
-Scott
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Scott Wood @ 2007-11-09 16:03 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <1194608283.8755.10.camel@p60635-ste.ids.de>
Sergej Stepanov wrote:
>> We also need to change the reference to port C in fsl,mdio-pin and
>> fsl,mdc-pin.
> Do you mean this:
> Currently defined compatibles:
> fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
> -> fsl,cpm2-mdio-bitbang (reg is port C registers)
>
> Properties for fsl,cpm2-mdio-bitbang:
> -> fsl,mdio-pin : pin of port C controlling mdio data
> -> fsl,mdc-pin : pin of port C controlling mdio clock
Yes.
> Right. But i thought it would be related to the example,
> and than the reader gets the short comment about I/O ports.
No, the example is the example, and the spec is the spec. :-)
> Or the other variant would be:
> --------------------
> iv) MDIO
>
> Currently defined compatibles:
> fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
> fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s))
>
> Properties for fsl,cpm2-mdio-bitbang:
> The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC.
> fsl,mdio-pin : pin of chosen port for controlling mdio data
> fsl,mdc-pin : pin of chosen port for controlling mdio clock
Looks good. We can eliminate the parenthetical for
fsl,cpm2-mdio-bitbang because reg is now explained below.
-Scott
^ permalink raw reply
* Re: Problems booting custom kernel and device tree on custom 85xx board
From: robert lazarski @ 2007-11-09 16:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <f87675ee0711080832g75c748adjc4f35aa73aefe202@mail.gmail.com>
On Nov 8, 2007 11:32 AM, robert lazarski <robertlazarski@gmail.com> wrote:
> Hi all,
>
> I finished the main part of porting u-boot 1.3 rc3 to our custon 8548
> board and am now trying to boot our 2.6.22 kernel and device tree:
>
I know its bad form to comment to myself, but I moved to a later
kernel - 2.6.23.2 - and I can get much further along. I'm hesitant to
move to 2.6.24 RC2 since we are about to ship the first board as soon
as I can get a bash shell - though I will if it'd attract more
interest in helping me. Its been often suggested here that its either
a serial port issue - seems unlikely here - or a kernel IMAP_ADDR /
u-boot CFG_IMMR mismatch. In the latter case I'm unsure how to confirm
those when using a device tree instead of bd_info.
Here's the new 2.6.23.1 output.
=> md 2acf24 700
002acf24: 3c363e55 73696e67 204d5043 38357878 <6>Using MPC85xx
002acf34: 20415455 4d206d61 6368696e 65206465 ATUM machine de
002acf44: 73637269 7074696f 6e0a3c36 3e4d656d scription.<6>Mem
002acf54: 6f727920 43414d20 6d617070 696e673a ory CAM mapping:
002acf64: 2043414d 303d3235 364d622c 2043414d CAM0=256Mb, CAM
002acf74: 313d3235 364d622c 2043414d 323d304d 1=256Mb, CAM2=0M
002acf84: 62207265 73696475 616c3a20 304d620a b residual: 0Mb.
002acf94: 3c353e4c 696e7578 20766572 73696f6e <5>Linux version
002acfa4: 20322e36 2e32332e 31202869 6b737261 2.6.23.1 (iksra
002acfb4: 7a616c40 6c696e75 782d726f 62657274 zal@linux-robert
002acfc4: 29202867 63632076 65727369 6f6e2034 ) (gcc version 4
002acfd4: 2e302e30 20284445 4e582045 4c444b20 .0.0 (DENX ELDK
002acfe4: 342e3120 342e302e 30292920 23322054 4.1 4.0.0)) #2 T
002acff4: 6875204e 6f762038 2031383a 34323a35 hu Nov 8 18:42:5
002ad004: 38204553 54203230 30370a3c 373e466f 8 EST 2007.<7>Fo
002ad014: 756e6420 6c656761 63792073 65726961 und legacy seria
002ad024: 6c20706f 72742030 20666f72 202f736f l port 0 for /so
002ad034: 63383534 38406530 30303030 30302f73 c8548@e0000000/s
002ad044: 65726961 6c403435 30300a3c 373e2020 erial@4500.<7>
002ad054: 6d656d3d 65303030 34353030 2c207461 mem=e0004500, ta
002ad064: 6464723d 65303030 34353030 2c206972 ddr=e0004500, ir
002ad074: 713d302c 20636c6b 3d333535 35353535 q=0, clk=3555555
002ad084: 34302c20 73706565 643d300a 3c373e46 40, speed=0.<7>F
002ad094: 6f756e64 206c6567 61637920 73657269 ound legacy seri
002ad0a4: 616c2070 6f727420 3120666f 72202f73 al port 1 for /s
002ad0b4: 6f633835 34384065 30303030 3030302f oc8548@e0000000/
002ad0c4: 73657269 616c4034 3630300a 3c373e20 serial@4600.<7>
002ad0d4: 206d656d 3d653030 30343630 302c2074 mem=e0004600, t
002ad0e4: 61646472 3d653030 30343630 302c2069 addr=e0004600, i
002ad0f4: 72713d30 2c20636c 6b3d3335 35353535 rq=0, clk=355555
002ad104: 3534302c 20737065 65643d30 0a3c363e 540, speed=0.<6>
002ad114: 636f6e73 6f6c6520 5b756462 67305d20 console [udbg0]
002ad124: 656e6162 6c65640a 3c373e45 6e746572 enabled.<7>Enter
002ad134: 696e6720 6164645f 61637469 76655f72 ing add_active_r
002ad144: 616e6765 28302c20 302c2031 33313037 ange(0, 0, 13107
002ad154: 32292030 20656e74 72696573 206f6620 2) 0 entries of
002ad164: 32353620 75736564 0a3c363e 6d706963 256 used.<6>mpic
002ad174: 3a205365 7474696e 67207570 204d5049 : Setting up MPI
002ad184: 43202220 4f70656e 50494320 20222076 C " OpenPIC " v
002ad194: 65727369 6f6e2031 2e322061 74206530 ersion 1.2 at e0
002ad1a4: 30343030 30302c20 6d617820 31204350 040000, max 1 CP
002ad1b4: 55730a3c 363e6d70 69633a20 49535520 Us.<6>mpic: ISU
002ad1c4: 73697a65 3a203830 2c207368 6966743a size: 80, shift:
002ad1d4: 20372c20 6d61736b 3a203766 0a3c363e 7, mask: 7f.<6>
002ad1e4: 6d706963 3a20496e 69746961 6c697a69 mpic: Initializi
002ad1f4: 6e672066 6f722038 3020736f 75726365 ng for 80 source
002ad204: 730a3c37 3e546f70 206f6620 52414d3a s.<7>Top of RAM:
002ad214: 20307832 30303030 3030302c 20546f74 0x20000000, Tot
002ad224: 616c2052 414d3a20 30783230 30303030 al RAM: 0x200000
002ad234: 30300a3c 373e4d65 6d6f7279 20686f6c 00.<7>Memory hol
002ad244: 65207369 7a653a20 304d420a 3c343e5a e size: 0MB.<4>Z
002ad254: 6f6e6520 50464e20 72616e67 65733a0a one PFN ranges:.
002ad264: 3c343e20 20444d41 20202020 20202020 <4> DMA
002ad274: 20202020 2030202d 3e202020 31333130 0 -> 1310
002ad284: 37320a3c 343e2020 4e6f726d 616c2020 72.<4> Normal
002ad294: 20202031 33313037 32202d3e 20202031 131072 -> 1
002ad2a4: 33313037 320a3c34 3e4d6f76 61626c65 31072.<4>Movable
002ad2b4: 207a6f6e 65207374 61727420 50464e20 zone start PFN
002ad2c4: 666f7220 65616368 206e6f64 650a3c34 for each node.<4
002ad2d4: 3e656172 6c795f6e 6f64655f 6d61705b >early_node_map[
002ad2e4: 315d2061 63746976 65205046 4e207261 1] active PFN ra
002ad2f4: 6e676573 0a3c343e 20202020 303a2020 nges.<4> 0:
002ad304: 20202020 20203020 2d3e2020 20313331 0 -> 131
002ad314: 3037320a 3c373e4f 6e206e6f 64652030 072.<7>On node 0
002ad324: 20746f74 616c7061 6765733a 20313331 totalpages: 131
002ad334: 3037320a 3c373e20 20444d41 207a6f6e 072.<7> DMA zon
002ad344: 653a2031 30323420 70616765 73207573 e: 1024 pages us
002ad354: 65642066 6f72206d 656d6d61 700a3c37 ed for memmap.<7
002ad364: 3e202044 4d41207a 6f6e653a 20302070 > DMA zone: 0 p
002ad374: 61676573 20726573 65727665 640a3c37 ages reserved.<7
002ad384: 3e202044 4d41207a 6f6e653a 20313330 > DMA zone: 130
002ad394: 30343820 70616765 732c204c 49464f20 048 pages, LIFO
002ad3a4: 62617463 683a3331 0a3c373e 20204e6f batch:31.<7> No
002ad3b4: 726d616c 207a6f6e 653a2030 20706167 rmal zone: 0 pag
002ad3c4: 65732075 73656420 666f7220 6d656d6d es used for memm
002ad3d4: 61700a3c 373e2020 4d6f7661 626c6520 ap.<7> Movable
002ad3e4: 7a6f6e65 3a203020 70616765 73207573 zone: 0 pages us
002ad3f4: 65642066 6f72206d 656d6d61 700a3c34 ed for memmap.<4
002ad404: 3e427569 6c742031 207a6f6e 656c6973 >Built 1 zonelis
002ad414: 74732069 6e205a6f 6e65206f 72646572 ts in Zone order
002ad424: 2e202054 6f74616c 20706167 65733a20 . Total pages:
002ad434: 31333030 34380a3c 353e4b65 726e656c 130048.<5>Kernel
002ad444: 20636f6d 6d616e64 206c696e 653a2060 command line: `
002ad454: 0a3c343e 50494420 68617368 20746162 .<4>PID hash tab
002ad464: 6c652065 6e747269 65733a20 32303438 le entries: 2048
002ad474: 20286f72 6465723a 2031312c 20383139 (order: 11, 819
002ad484: 32206279 74657329 0a3c373e 74696d65 2 bytes).<7>time
002ad494: 5f696e69 743a2064 65637265 6d656e74 _init: decrement
002ad4a4: 65722066 72657175 656e6379 203d2034 er frequency = 4
002ad4b4: 342e3434 34343432 204d487a 0a3c373e 4.444442 MHz.<7>
002ad4c4: 74696d65 5f696e69 743a2070 726f6365 time_init: proce
002ad4d4: 73736f72 20667265 7175656e 63792020 ssor frequency
002ad4e4: 203d2038 38382e38 38383835 30204d48 = 888.888850 MH
002ad4f4: 7a0a3c36 3e44656e 74727920 63616368 z.<6>Dentry cach
002ad504: 65206861 73682074 61626c65 20656e74 e hash table ent
002ad514: 72696573 3a203635 35333620 286f7264 ries: 65536 (ord
002ad524: 65723a20 362c2032 36323134 34206279 er: 6, 262144 by
002ad534: 74657329 0a3c363e 496e6f64 652d6361 tes).<6>Inode-ca
002ad544: 63686520 68617368 20746162 6c652065 che hash table e
002ad554: 6e747269 65733a20 33323736 3820286f ntries: 32768 (o
002ad564: 72646572 3a20352c 20313331 30373220 rder: 5, 131072
002ad574: 62797465 73290a3c 363e4d65 6d6f7279 bytes).<6>Memory
002ad584: 3a203531 36343830 6b2f3532 34323838 : 516480k/524288
002ad594: 6b206176 61696c61 626c6520 28323537 k available (257
002ad5a4: 326b206b 65726e65 6c20636f 64652c20 2k kernel code,
002ad5b4: 37333238 6b207265 73657276 65642c20 7328k reserved,
002ad5c4: 3131366b 20646174 612c2031 30356b20 116k data, 105k
002ad5d4: 6273732c 20313430 6b20696e 6974290a bss, 140k init).
002ad5e4: 3c373e43 616c6962 72617469 6e672064 <7>Calibrating d
002ad5f4: 656c6179 206c6f6f 702e2e2e 2038382e elay loop... 88.
002ad604: 38332042 6f676f4d 49505320 286c706a 83 BogoMIPS (lpj
002ad614: 3d313737 36363429 0a3c343e 4d6f756e =177664).<4>Moun
002ad624: 742d6361 63686520 68617368 20746162 t-cache hash tab
002ad634: 6c652065 6e747269 65733a20 3531320a le entries: 512.
002ad644: 3c373e6b 6f626a65 63742066 733a2072 <7>kobject fs: r
002ad654: 65676973 74657269 6e672e20 70617265 egistering. pare
002ad664: 6e743a20 3c4e554c 4c3e2c20 7365743a nt: <NULL>, set:
002ad674: 203c4e55 4c4c3e0a 3c373e6b 6f626a65 <NULL>.<7>kobje
002ad684: 63745f75 6576656e 745f656e 760a3c37 ct_uevent_env.<7
002ad694: 3e6b6f62 6a656374 20617474 656d7074 >kobject attempt
002ad6a4: 65642074 6f207365 6e642075 6576656e ed to send ueven
002ad6b4: 74207769 74686f75 74206b73 6574210a t without kset!.
002ad6c4: 3c373e6b 6f626a65 63742064 65766963 <7>kobject devic
002ad6d4: 65733a20 72656769 73746572 696e672e es: registering.
002ad6e4: 20706172 656e743a 203c4e55 4c4c3e2c parent: <NULL>,
002ad6f4: 20736574 3a203c4e 554c4c3e 0a3c373e set: <NULL>.<7>
002ad704: 6b6f626a 6563745f 75657665 6e745f65 kobject_uevent_e
002ad714: 6e760a3c 373e6b6f 626a6563 74206174 nv.<7>kobject at
002ad724: 74656d70 74656420 746f2073 656e6420 tempted to send
002ad734: 75657665 6e742077 6974686f 7574206b uevent without k
002ad744: 73657421 0a3c373e 6b6f626a 65637420 set!.<7>kobject
002ad754: 6275733a 20726567 69737465 72696e67 bus: registering
002ad764: 2e207061 72656e74 3a203c4e 554c4c3e . parent: <NULL>
002ad774: 2c207365 743a203c 4e554c4c 3e0a3c37 , set: <NULL>.<7
002ad784: 3e6b6f62 6a656374 5f756576 656e745f >kobject_uevent_
002ad794: 656e760a 3c373e6b 6f626a65 63742061 env.<7>kobject a
002ad7a4: 7474656d 70746564 20746f20 73656e64 ttempted to send
002ad7b4: 20756576 656e7420 77697468 6f757420 uevent without
002ad7c4: 6b736574 210a3c37 3e6b6f62 6a656374 kset!.<7>kobject
002ad7d4: 20636c61 73733a20 72656769 73746572 class: register
002ad7e4: 696e672e 20706172 656e743a 203c4e55 ing. parent: <NU
002ad7f4: 4c4c3e2c 20736574 3a203c4e 554c4c3e LL>, set: <NULL>
002ad804: 0a3c373e 6b6f626a 6563745f 75657665 .<7>kobject_ueve
002ad814: 6e745f65 6e760a3c 373e6b6f 626a6563 nt_env.<7>kobjec
002ad824: 74206174 74656d70 74656420 746f2073 t attempted to s
002ad834: 656e6420 75657665 6e742077 6974686f end uevent witho
002ad844: 7574206b 73657421 0a3c373e 6b6f626a ut kset!.<7>kobj
002ad854: 65637420 6669726d 77617265 3a207265 ect firmware: re
002ad864: 67697374 6572696e 672e2070 6172656e gistering. paren
002ad874: 743a203c 4e554c4c 3e2c2073 65743a20 t: <NULL>, set:
002ad884: 3c4e554c 4c3e0a3c 373e6b6f 626a6563 <NULL>.<7>kobjec
002ad894: 745f7565 76656e74 5f656e76 0a3c373e t_uevent_env.<7>
002ad8a4: 6b6f626a 65637420 61747465 6d707465 kobject attempte
002ad8b4: 6420746f 2073656e 64207565 76656e74 d to send uevent
002ad8c4: 20776974 686f7574 206b7365 74210a3c without kset!.<
002ad8d4: 373e6b6f 626a6563 7420706c 6174666f 7>kobject platfo
002ad8e4: 726d3a20 72656769 73746572 696e672e rm: registering.
002ad8f4: 20706172 656e743a 203c4e55 4c4c3e2c parent: <NULL>,
002ad904: 20736574 3a206465 76696365 730a3c37 set: devices.<7
002ad914: 3e6b6f62 6a656374 5f756576 656e745f >kobject_uevent_
002ad924: 656e760a 3c373e6b 6f626a65 63742066 env.<7>kobject f
002ad934: 696c7465 72206675 6e637469 6f6e2063 ilter function c
002ad944: 61757365 64207468 65206576 656e7420 aused the event
002ad954: 746f2064 726f7021 0a3c373e 6b6f626a to drop!.<7>kobj
002ad964: 65637420 706c6174 666f726d 3a207265 ect platform: re
002ad974: 67697374 6572696e 672e2070 6172656e gistering. paren
002ad984: 743a203c 4e554c4c 3e2c2073 65743a20 t: <NULL>, set:
002ad994: 6275730a 3c373e6b 6f626a65 63745f75 bus.<7>kobject_u
002ad9a4: 6576656e 745f656e 760a3c37 3e66696c event_env.<7>fil
002ad9b4: 6c5f6b6f 626a5f70 6174683a 20706174 l_kobj_path: pat
002ad9c4: 68203d20 272f6275 732f706c 6174666f h = '/bus/platfo
002ad9d4: 726d270a 3c373e6b 6f626a65 63742064 rm'.<7>kobject d
002ad9e4: 65766963 65733a20 72656769 73746572 evices: register
002ad9f4: 696e672e 20706172 656e743a 20706c61 ing. parent: pla
002ada04: 74666f72 6d2c2073 65743a20 3c4e554c tform, set: <NUL
002ada14: 4c3e0a3c 373e6b6f 626a6563 745f7565 L>.<7>kobject_ue
002ada24: 76656e74 5f656e76 0a3c373e 6b6f626a vent_env.<7>kobj
002ada34: 65637420 66696c74 65722066 756e6374 ect filter funct
002ada44: 696f6e20 63617573 65642074 68652065 ion caused the e
002ada54: 76656e74 20746f20 64726f70 210a3c37 vent to drop!.<7
002ada64: 3e6b6f62 6a656374 20647269 76657273 >kobject drivers
002ada74: 3a207265 67697374 6572696e 672e2070 : registering. p
002ada84: 6172656e 743a2070 6c617466 6f726d2c arent: platform,
002ada94: 20736574 3a203c4e 554c4c3e 0a3c373e set: <NULL>.<7>
002adaa4: 6b6f626a 6563745f 75657665 6e745f65 kobject_uevent_e
002adab4: 6e760a3c 373e6b6f 626a6563 74206669 nv.<7>kobject fi
002adac4: 6c746572 2066756e 6374696f 6e206361 lter function ca
002adad4: 75736564 20746865 20657665 6e742074 used the event t
002adae4: 6f206472 6f70210a 3c373e6b 6f626a65 o drop!.<7>kobje
002adaf4: 63742073 79737465 6d3a2072 65676973 ct system: regis
002adb04: 74657269 6e672e20 70617265 6e743a20 tering. parent:
002adb14: 64657669 6365732c 20736574 3a203c4e devices, set: <N
002adb24: 554c4c3e 0a3c373e 6b6f626a 6563745f ULL>.<7>kobject_
002adb34: 75657665 6e745f65 6e760a3c 373e6b6f uevent_env.<7>ko
002adb44: 626a6563 74206174 74656d70 74656420 bject attempted
002adb54: 746f2073 656e6420 75657665 6e742077 to send uevent w
002adb64: 6974686f 7574206b 73657421 0a3c373e ithout kset!.<7>
002adb74: 6b6f626a 65637420 6370753a 20726567 kobject cpu: reg
002adb84: 69737465 72696e67 2e207061 72656e74 istering. parent
002adb94: 3a207379 7374656d 2c207365 743a2073 : system, set: s
002adba4: 79737465 6d0a3c37 3e6b6f62 6a656374 ystem.<7>kobject
002adbb4: 5f756576 656e745f 656e760a 3c373e66 _uevent_env.<7>f
002adbc4: 696c6c5f 6b6f626a 5f706174 683a2070 ill_kobj_path: p
002adbd4: 61746820 3d20272f 64657669 6365732f ath = '/devices/
002adbe4: 73797374 656d2f63 7075270a 3c373e6b system/cpu'.<7>k
002adbf4: 6f626a65 6374206b 65726e65 6c3a2072 object kernel: r
002adc04: 65676973 74657269 6e672e20 70617265 egistering. pare
002adc14: 6e743a20 3c4e554c 4c3e2c20 7365743a nt: <NULL>, set:
002adc24: 203c4e55 4c4c3e0a 3c373e6b 6f626a65 <NULL>.<7>kobje
002adc34: 63745f75 6576656e 745f656e 760a3c37 ct_uevent_env.<7
002adc44: 3e6b6f62 6a656374 20617474 656d7074 >kobject attempt
002adc54: 65642074 6f207365 6e642075 6576656e ed to send ueven
002adc64: 74207769 74686f75 74206b73 6574210a t without kset!.
002adc74: 3c363e4e 45543a20 52656769 73746572 <6>NET: Register
002adc84: 65642070 726f746f 636f6c20 66616d69 ed protocol fami
002adc94: 6c792031 360a3c37 3e6b6f62 6a656374 ly 16.<7>kobject
002adca4: 206f665f 706c6174 666f726d 3a207265 of_platform: re
002adcb4: 67697374 6572696e 672e2070 6172656e gistering. paren
002adcc4: 743a203c 4e554c4c 3e2c2073 65743a20 t: <NULL>, set:
002adcd4: 6275730a 3c373e6b 6f626a65 63745f75 bus.<7>kobject_u
002adce4: 6576656e 745f656e 760a3c37 3e66696c event_env.<7>fil
002adcf4: 6c5f6b6f 626a5f70 6174683a 20706174 l_kobj_path: pat
002add04: 68203d20 272f6275 732f6f66 5f706c61 h = '/bus/of_pla
002add14: 74666f72 6d270a3c 373e6b6f 626a6563 tform'.<7>kobjec
002add24: 74206465 76696365 733a2072 65676973 t devices: regis
002add34: 74657269 6e672e20 70617265 6e743a20 tering. parent:
002add44: 6f665f70 6c617466 6f726d2c 20736574 of_platform, set
002add54: 3a203c4e 554c4c3e 0a3c373e 6b6f626a : <NULL>.<7>kobj
002add64: 6563745f 75657665 6e745f65 6e760a3c ect_uevent_env.<
002add74: 373e6b6f 626a6563 74206669 6c746572 7>kobject filter
002add84: 2066756e 6374696f 6e206361 75736564 function caused
002add94: 20746865 20657665 6e742074 6f206472 the event to dr
002adda4: 6f70210a 3c373e6b 6f626a65 63742064 op!.<7>kobject d
002addb4: 72697665 72733a20 72656769 73746572 rivers: register
002addc4: 696e672e 20706172 656e743a 206f665f ing. parent: of_
002addd4: 706c6174 666f726d 2c207365 743a203c platform, set: <
002adde4: 4e554c4c 3e0a3c37 3e6b6f62 6a656374 NULL>.<7>kobject
002addf4: 5f756576 656e745f 656e760a 3c373e6b _uevent_env.<7>k
002ade04: 6f626a65 63742066 696c7465 72206675 object filter fu
002ade14: 6e637469 6f6e2063 61757365 64207468 nction caused th
002ade24: 65206576 656e7420 746f2064 726f7021 e event to drop!
002ade34: 0a3c373e 6b6f626a 65637420 7063695f .<7>kobject pci_
002ade44: 6275733a 20726567 69737465 72696e67 bus: registering
002ade54: 2e207061 72656e74 3a203c4e 554c4c3e . parent: <NULL>
002ade64: 2c207365 743a2063 6c617373 0a3c373e , set: class.<7>
002ade74: 6b6f626a 6563745f 75657665 6e745f65 kobject_uevent_e
002ade84: 6e760a3c 373e6669 6c6c5f6b 6f626a5f nv.<7>fill_kobj_
002ade94: 70617468 3a207061 7468203d 20272f63 path: path = '/c
002adea4: 6c617373 2f706369 5f627573 270a3c37 lass/pci_bus'.<7
002adeb4: 3e6b6f62 6a656374 20706369 3a207265 >kobject pci: re
002adec4: 67697374 6572696e 672e2070 6172656e gistering. paren
002aded4: 743a203c 4e554c4c 3e2c2073 65743a20 t: <NULL>, set:
002adee4: 6275730a 3c373e6b 6f626a65 63745f75 bus.<7>kobject_u
002adef4: 6576656e 745f656e 760a3c37 3e66696c event_env.<7>fil
002adf04: 6c5f6b6f 626a5f70 6174683a 20706174 l_kobj_path: pat
002adf14: 68203d20 272f6275 732f7063 69270a3c h = '/bus/pci'.<
002adf24: 373e6b6f 626a6563 74206465 76696365 7>kobject device
002adf34: 733a2072 65676973 74657269 6e672e20 s: registering.
002adf44: 70617265 6e743a20 7063692c 20736574 parent: pci, set
002adf54: 3a203c4e 554c4c3e 0a3c373e 6b6f626a : <NULL>.<7>kobj
002adf64: 6563745f 75657665 6e745f65 6e760a3c ect_uevent_env.<
002adf74: 373e6b6f 626a6563 74206669 6c746572 7>kobject filter
002adf84: 2066756e 6374696f 6e206361 75736564 function caused
002adf94: 20746865 20657665 6e742074 6f206472 the event to dr
002adfa4: 6f70210a 3c373e6b 6f626a65 63742064 op!.<7>kobject d
002adfb4: 72697665 72733a20 72656769 73746572 rivers: register
002adfc4: 696e672e 20706172 656e743a 20706369 ing. parent: pci
002adfd4: 2c207365 743a203c 4e554c4c 3e0a3c37 , set: <NULL>.<7
002adfe4: 3e6b6f62 6a656374 5f756576 656e745f >kobject_uevent_
002adff4: 656e760a 3c373e6b 6f626a65 63742066 env.<7>kobject f
002ae004: 696c7465 72206675 6e637469 6f6e2063 ilter function c
002ae014: 61757365 64207468 65206576 656e7420 aused the event
002ae024: 746f2064 726f7021 0a3c373e 6b6f626a to drop!.<7>kobj
002ae034: 65637420 76696465 6f5f6f75 74707574 ect video_output
002ae044: 3a207265 67697374 6572696e 672e2070 : registering. p
002ae054: 6172656e 743a203c 4e554c4c 3e2c2073 arent: <NULL>, s
002ae064: 65743a20 636c6173 730a3c37 3e6b6f62 et: class.<7>kob
002ae074: 6a656374 5f756576 656e745f 656e760a ject_uevent_env.
002ae084: 3c373e66 696c6c5f 6b6f626a 5f706174 <7>fill_kobj_pat
002ae094: 683a2070 61746820 3d20272f 636c6173 h: path = '/clas
002ae0a4: 732f7669 64656f5f 6f757470 7574270a s/video_output'.
002ae0b4: 3c373e6b 6f626a65 63742074 74793a20 <7>kobject tty:
002ae0c4: 72656769 73746572 696e672e 20706172 registering. par
002ae0d4: 656e743a 203c4e55 4c4c3e2c 20736574 ent: <NULL>, set
002ae0e4: 3a20636c 6173730a 3c373e6b 6f626a65 : class.<7>kobje
002ae0f4: 63745f75 6576656e 745f656e 760a3c37 ct_uevent_env.<7
002ae104: 3e66696c 6c5f6b6f 626a5f70 6174683a >fill_kobj_path:
002ae114: 20706174 68203d20 272f636c 6173732f path = '/class/
002ae124: 74747927 0a3c373e 6b6f626a 65637420 tty'.<7>kobject
002ae134: 63707530 3a207265 67697374 6572696e cpu0: registerin
002ae144: 672e2070 6172656e 743a203c 4e554c4c g. parent: <NULL
002ae154: 3e2c2073 65743a20 6370750a 3c373e6b >, set: cpu.<7>k
002ae164: 6f626a65 63745f75 6576656e 745f656e object_uevent_en
002ae174: 760a3c37 3e66696c 6c5f6b6f 626a5f70 v.<7>fill_kobj_p
002ae184: 6174683a 20706174 68203d20 272f6465 ath: path = '/de
002ae194: 76696365 732f7379 7374656d 2f637075 vices/system/cpu
002ae1a4: 2f637075 30270a3c 373e6b6f 626a6563 /cpu0'.<7>kobjec
002ae1b4: 74206673 6c2d6769 616e6661 722e303a t fsl-gianfar.0:
002ae1c4: 20726567 69737465 72696e67 2e207061 registering. pa
002ae1d4: 72656e74 3a20706c 6174666f 726d2c20 rent: platform,
002ae1e4: 7365743a 20646576 69636573 0a3c373e set: devices.<7>
002ae1f4: 6b6f626a 6563745f 75657665 6e745f65 kobject_uevent_e
002ae204: 6e760a3c 373e6b6f 626a6563 74206669 nv.<7>kobject fi
002ae214: 6c746572 2066756e 6374696f 6e206361 lter function ca
002ae224: 75736564 20746865 20657665 6e742074 used the event t
002ae234: 6f206472 6f70210a 3c373e6b 6f626a65 o drop!.<7>kobje
002ae244: 63742066 736c2d67 69616e66 61722e31 ct fsl-gianfar.1
002ae254: 3a207265 67697374 6572696e 672e2070 : registering. p
002ae264: 6172656e 743a2070 6c617466 6f726d2c arent: platform,
002ae274: 20736574 3a206465 76696365 730a3c37 set: devices.<7
002ae284: 3e6b6f62 6a656374 5f756576 656e745f >kobject_uevent_
002ae294: 656e760a 3c373e6b 6f626a65 63742066 env.<7>kobject f
002ae2a4: 696c7465 72206675 6e637469 6f6e2063 ilter function c
002ae2b4: 61757365 64207468 65206576 656e7420 aused the event
002ae2c4: 746f2064 726f7021 0a3c373e 6b6f626a to drop!.<7>kobj
002ae2d4: 65637420 66736c2d 6769616e 6661722e ect fsl-gianfar.
002ae2e4: 323a2072 65676973 74657269 6e672e20 2: registering.
002ae2f4: 70617265 6e743a20 706c6174 666f726d parent: platform
002ae304: 2c207365 743a2064 65766963 65730a3c , set: devices.<
002ae314: 373e6b6f 626a6563 745f7565 00000000 7>kobject_ue....
002ae324: 00000000 00000000 00000000 00000000 ................
002ae334: 00000000 00000000 00000000 00000000 ................
002ae344: 00000000 00000000 00000000 00000000 ................
002ae354: 00000000 00000000 00000000 3e6b6f62 ............>kob
002ae364: 6a656374 2066736c 2d676961 6e666172 ject fsl-gianfar
002ae374: 2e333a20 72656769 73746572 696e672e .3: registering.
002ae384: 20706172 656e743a 20706c61 74666f72 parent: platfor
002ae394: 6d2c2073 65743a20 64657669 6365730a m, set: devices.
002ae3a4: 3c373e6b 6f626a65 63745f75 6576656e <7>kobject_ueven
002ae3b4: 745f656e 760a3c37 3e6b6f62 6a656374 t_env.<7>kobject
002ae3c4: 2066696c 74657220 66756e63 74696f6e filter function
002ae3d4: 20636175 73656420 74686520 6576656e caused the even
002ae3e4: 7420746f 2064726f 70210a3c 373e6b6f t to drop!.<7>ko
002ae3f4: 626a6563 74206673 6c2d6769 616e6661 bject fsl-gianfa
002ae404: 725f6d64 696f2e33 373a2072 65676973 r_mdio.37: regis
002ae414: 74657269 6e672e20 70617265 6e743a20 tering. parent:
002ae424: 706c6174 666f726d 2c207365 743a2064 platform, set: d
002ae434: 65766963 65730a3c 373e6b6f 626a6563 evices.<7>kobjec
002ae444: 745f7565 76656e74 5f656e76 0a3c373e t_uevent_env.<7>
002ae454: 6b6f626a 65637420 66696c74 65722066 kobject filter f
002ae464: 756e6374 696f6e20 63617573 65642074 unction caused t
002ae474: 68652065 76656e74 20746f20 64726f70 he event to drop
002ae484: 210a3c36 3e727374 63722063 6f6d7061 !.<6>rstcr compa
002ae494: 7469626c 65207265 67697374 65722064 tible register d
002ae4a4: 6f657320 6e6f7420 65786973 74210a3c oes not exist!.<
002ae4b4: 363e5043 493a2050 726f6269 6e672050 6>PCI: Probing P
002ae4c4: 43492068 61726477 6172650a 3c373e6b CI hardware.<7>k
002ae4d4: 6f626a65 6374206d 6f64756c 653a2072 object module: r
002ae4e4: 65676973 74657269 6e672e20 70617265 egistering. pare
002ae4f4: 6e743a20 3c4e554c 4c3e2c20 7365743a nt: <NULL>, set:
002ae504: 203c4e55 4c4c3e0a 3c373e6b 6f626a65 <NULL>.<7>kobje
002ae514: 63745f75 6576656e 745f656e 760a3c37 ct_uevent_env.<7
002ae524: 3e6b6f62 6a656374 20617474 656d7074 >kobject attempt
002ae534: 65642074 6f207365 6e642075 6576656e ed to send ueven
002ae544: 74207769 74686f75 74206b73 6574210a t without kset!.
002ae554: 3c373e6b 6f626a65 63742070 72696e74 <7>kobject print
002ae564: 6b3a2072 65676973 74657269 6e672e20 k: registering.
002ae574: 70617265 6e743a20 3c4e554c 4c3e2c20 parent: <NULL>,
002ae584: 7365743a 206d6f64 756c650a 3c373e6b set: module.<7>k
002ae594: 6f626a65 63745f75 6576656e 745f656e object_uevent_en
002ae5a4: 760a3c37 3e66696c 6c5f6b6f 626a5f70 v.<7>fill_kobj_p
002ae5b4: 6174683a 20706174 68203d20 272f6d6f ath: path = '/mo
002ae5c4: 64756c65 2f707269 6e746b27 0a3c373e dule/printk'.<7>
002ae5d4: 6b6f626a 65637420 72637570 64617465 kobject rcupdate
002ae5e4: 3a207265 67697374 6572696e 672e2070 : registering. p
002ae5f4: 6172656e 743a203c 4e554c4c 3e2c2073 arent: <NULL>, s
002ae604: 65743a20 6d6f6475 6c650a3c 373e6b6f et: module.<7>ko
002ae614: 626a6563 745f7565 76656e74 5f656e76 bject_uevent_env
002ae624: 0a3c373e 66696c6c 5f6b6f62 6a5f7061 .<7>fill_kobj_pa
002ae634: 74683a20 70617468 203d2027 2f6d6f64 th: path = '/mod
002ae644: 756c652f 72637570 64617465 270a3c37 ule/rcupdate'.<7
002ae654: 3e6b6f62 6a656374 206c6f63 6b643a20 >kobject lockd:
002ae664: 72656769 73746572 696e672e 20706172 registering. par
002ae674: 656e743a 203c4e55 4c4c3e2c 20736574 ent: <NULL>, set
002ae684: 3a206d6f 64756c65 0a3c373e 6b6f626a : module.<7>kobj
002ae694: 6563745f 75657665 6e745f65 6e760a3c ect_uevent_env.<
002ae6a4: 373e6669 6c6c5f6b 6f626a5f 70617468 7>fill_kobj_path
002ae6b4: 3a207061 7468203d 20272f6d 6f64756c : path = '/modul
002ae6c4: 652f6c6f 636b6427 0a3c373e 6b6f626a e/lockd'.<7>kobj
002ae6d4: 65637420 38323530 3a207265 67697374 ect 8250: regist
002ae6e4: 6572696e 672e2070 6172656e 743a203c ering. parent: <
002ae6f4: 4e554c4c 3e2c2073 65743a20 6d6f6475 NULL>, set: modu
002ae704: 6c650a3c 373e6b6f 626a6563 745f7565 le.<7>kobject_ue
002ae714: 76656e74 5f656e76 0a3c373e 66696c6c vent_env.<7>fill
002ae724: 5f6b6f62 6a5f7061 74683a20 70617468 _kobj_path: path
002ae734: 203d2027 2f6d6f64 756c652f 38323530 = '/module/8250
002ae744: 270a3c37 3e6b6f62 6a656374 2072643a '.<7>kobject rd:
002ae754: 20726567 69737465 72696e67 2e207061 registering. pa
002ae764: 72656e74 3a203c4e 554c4c3e 2c207365 rent: <NULL>, se
002ae774: 743a206d 6f64756c 650a3c37 3e6b6f62 t: module.<7>kob
002ae784: 6a656374 5f756576 656e745f 656e760a ject_uevent_env.
002ae794: 3c373e66 696c6c5f 6b6f626a 5f706174 <7>fill_kobj_pat
002ae7a4: 683a2070 61746820 3d20272f 6d6f6475 h: path = '/modu
002ae7b4: 6c652f72 64270a3c 373e6b6f 626a6563 le/rd'.<7>kobjec
002ae7c4: 74206c6f 6f703a20 72656769 73746572 t loop: register
002ae7d4: 696e672e 20706172 656e743a 203c4e55 ing. parent: <NU
002ae7e4: 4c4c3e2c 20736574 3a206d6f 64756c65 LL>, set: module
002ae7f4: 0a3c373e 6b6f626a 6563745f 75657665 .<7>kobject_ueve
002ae804: 6e745f65 6e760a3c 373e6669 6c6c5f6b nt_env.<7>fill_k
002ae814: 6f626a5f 70617468 3a207061 7468203d obj_path: path =
002ae824: 20272f6d 6f64756c 652f6c6f 6f70270a '/module/loop'.
002ae834: 3c373e6b 6f626a65 63742065 31303030 <7>kobject e1000
002ae844: 3a207265 67697374 6572696e 672e2070 : registering. p
002ae854: 6172656e 743a203c 4e554c4c 3e2c2073 arent: <NULL>, s
002ae864: 65743a20 6d6f6475 6c650a3c 373e6b6f et: module.<7>ko
002ae874: 626a6563 745f7565 76656e74 5f656e76 bject_uevent_env
002ae884: 0a3c373e 66696c6c 5f6b6f62 6a5f7061 .<7>fill_kobj_pa
002ae894: 74683a20 70617468 203d2027 2f6d6f64 th: path = '/mod
002ae8a4: 756c652f 65313030 30270a3c 373e6b6f ule/e1000'.<7>ko
002ae8b4: 626a6563 74206765 6e657269 633a2072 bject generic: r
002ae8c4: 65676973 74657269 6e672e20 70617265 egistering. pare
002ae8d4: 6e743a20 3c4e554c 4c3e2c20 7365743a nt: <NULL>, set:
002ae8e4: 206d6f64 756c650a 3c373e6b 6f626a65 module.<7>kobje
002ae8f4: 63745f75 6576656e 745f656e 760a3c37 ct_uevent_env.<7
002ae904: 3e66696c 6c5f6b6f 626a5f70 6174683a >fill_kobj_path:
002ae914: 20706174 68203d20 272f6d6f 64756c65 path = '/module
002ae924: 2f67656e 65726963 270a3c37 3e6b6f62 /generic'.<7>kob
002ae934: 6a656374 20757362 636f7265 3a207265 ject usbcore: re
002ae944: 67697374 6572696e 672e2070 6172656e gistering. paren
002ae954: 743a203c 4e554c4c 3e2c2073 65743a20 t: <NULL>, set:
002ae964: 6d6f6475 6c650a3c 373e6b6f 626a6563 module.<7>kobjec
002ae974: 745f7565 76656e74 5f656e76 0a3c373e t_uevent_env.<7>
002ae984: 66696c6c 5f6b6f62 6a5f7061 74683a20 fill_kobj_path:
002ae994: 70617468 203d2027 2f6d6f64 756c652f path = '/module/
002ae9a4: 75736263 6f726527 0a3c373e 6b6f626a usbcore'.<7>kobj
002ae9b4: 65637420 6869643a 20726567 69737465 ect hid: registe
002ae9c4: 72696e67 2e207061 72656e74 3a203c4e ring. parent: <N
002ae9d4: 554c4c3e 2c207365 743a206d 6f64756c ULL>, set: modul
002ae9e4: 650a3c37 3e6b6f62 6a656374 5f756576 e.<7>kobject_uev
002ae9f4: 656e745f 656e760a 3c373e66 696c6c5f ent_env.<7>fill_
002aea04: 6b6f626a 5f706174 683a2070 61746820 kobj_path: path
002aea14: 3d20272f 6d6f6475 6c652f68 6964270a = '/module/hid'.
002aea24: 3c373e6b 6f626a65 63742075 73626869 <7>kobject usbhi
002aea34: 643a2072 65676973 74657269 6e672e20 d: registering.
002aea44: 70617265 6e743a20 3c4e554c 4c3e2c20 parent: <NULL>,
002aea54: 7365743a 206d6f64 756c650a 3c373e6b set: module.<7>k
002aea64: 6f626a65 63745f75 6576656e 745f656e object_uevent_en
002aea74: 760a3c37 3e66696c 6c5f6b6f 626a5f70 v.<7>fill_kobj_p
002aea84: 6174683a 20706174 68203d20 272f6d6f ath: path = '/mo
002aea94: 64756c65 2f757362 68696427 0a3c373e dule/usbhid'.<7>
002aeaa4: 6b6f626a 65637420 7463705f 63756269 kobject tcp_cubi
002aeab4: 633a2072 65676973 74657269 6e672e20 c: registering.
002aeac4: 70617265 6e743a20 3c4e554c 4c3e2c20 parent: <NULL>,
002aead4: 7365743a 206d6f64 756c650a 00000000 set: module.....
002aeae4: 00000000 00000000 00000000 00000000 ................
002aeaf4: 00000000 00000000 00000000 00000000 ................
002aeb04: 00000000 00000000 00000000 00000000 ................
^ permalink raw reply
* [PATCH v4 00/13] [POWERPC] Add TQM5200/CM5200/Motion-PRO board support
From: Marian Balakowicz @ 2007-11-09 17:11 UTC (permalink / raw)
To: linuxppc-dev
This is a yet another version of the patches that add arch/powerpc support for
three MPC5200 based boards: TQ-Components TQM5200, Schindler CM5200
and Promess Motion-PRO.
Updates include modifications to mpc5200_simple_probe() routine in the
generic support for simple MPC5200 based boards, changes to
leds-motionpro driver - using common compatility property for both LEDs,
and few other .dts cleanups.
[POWERPC] Promess Motion-PRO defconfig
[POWERPC] Promess Motion-PRO DTS
[POWERPC] Motion-PRO: Add LED support.
[POWERPC] CM5200 defconfig
[POWERPC] CM5200 DTS
[POWERPC] TQM5200 defconfig
[POWERPC] TQM5200 DTS
[POWERPC] Use EXPORT_SYMBOL_GPL for 52xx common routines symbol export
[POWERPC] Export mpc52xx_map_node() routine symbol
[POWERPC] Add generic support for simple MPC5200 based boards
[POWERPC] Add common mpc52xx_setup_pci() routine
[POWERPC] Add 'fsl,lpb' bus type for MPC5200 LocalPlus Bus
[POWERPC] Add 'model: ...' line to common show_cpuinfo()
Please review, and if everything is ok schedule for 2.6.24-rc3.
Cheers,
m.
^ permalink raw reply
* [PATCH v4 01/13] [POWERPC] Add 'model: ...' line to common show_cpuinfo()
From: Marian Balakowicz @ 2007-11-09 17:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071109171137.16289.39575.stgit@hekate.izotz.org>
Print out 'model' property of '/' node as a machine name
in generic show_cpuinfo() routine.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Olof Johansson <olof@lixom.net>
---
arch/powerpc/kernel/setup-common.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 2de00f8..cb291f1 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -165,6 +165,8 @@ static int show_cpuinfo(struct seq_file *m, void *v)
unsigned short min;
if (cpu_id == NR_CPUS) {
+ struct device_node *root;
+ const char *model = NULL;
#if defined(CONFIG_SMP) && defined(CONFIG_PPC32)
unsigned long bogosum = 0;
int i;
@@ -176,6 +178,13 @@ static int show_cpuinfo(struct seq_file *m, void *v)
seq_printf(m, "timebase\t: %lu\n", ppc_tb_freq);
if (ppc_md.name)
seq_printf(m, "platform\t: %s\n", ppc_md.name);
+ root = of_find_node_by_path("/");
+ if (root)
+ model = of_get_property(root, "model", NULL);
+ of_node_put(root);
+ if (model)
+ seq_printf(m, "model\t\t: %s\n", model);
+
if (ppc_md.show_cpuinfo != NULL)
ppc_md.show_cpuinfo(m);
^ permalink raw reply related
* [PATCH v4 02/13] [POWERPC] Add 'fsl, lpb' bus type for MPC5200 LocalPlus Bus
From: Marian Balakowicz @ 2007-11-09 17:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071109171137.16289.39575.stgit@hekate.izotz.org>
Define MPC52xx specific device id list, add new
'fsl,lpb' compatible id for LocalPlus Bus.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/platforms/52xx/mpc52xx_common.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 9850685..2df97c5 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -124,11 +124,18 @@ mpc5200_setup_xlb_arbiter(void)
iounmap(xlb);
}
+static struct of_device_id mpc52xx_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ { .compatible = "fsl,lpb", },
+ {},
+};
+
void __init
mpc52xx_declare_of_platform_devices(void)
{
/* Find every child of the SOC node and add it to of_platform */
- if (of_platform_bus_probe(NULL, NULL, NULL))
+ if (of_platform_bus_probe(NULL, mpc52xx_ids, NULL))
printk(KERN_ERR __FILE__ ": "
"Error while probing of_platform bus\n");
}
^ permalink raw reply related
* [PATCH v4 03/13] [POWERPC] Add common mpc52xx_setup_pci() routine
From: Marian Balakowicz @ 2007-11-09 17:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071109171137.16289.39575.stgit@hekate.izotz.org>
This patch moves a generic pci init code from lite5200
platform file to a common mpc52xx_setup_pci() routine
and adds additional compatibility property verification.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
arch/powerpc/platforms/52xx/lite5200.c | 12 +-----------
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 15 +++++++++++++++
include/asm-powerpc/mpc52xx.h | 5 +++++
3 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 25d2bfa..ce903be 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -131,10 +131,6 @@ static void lite5200_resume_finish(void __iomem *mbar)
static void __init lite5200_setup_arch(void)
{
-#ifdef CONFIG_PCI
- struct device_node *np;
-#endif
-
if (ppc_md.progress)
ppc_md.progress("lite5200_setup_arch()", 0);
@@ -154,13 +150,7 @@ static void __init lite5200_setup_arch(void)
lite5200_pm_init();
#endif
-#ifdef CONFIG_PCI
- np = of_find_node_by_type(NULL, "pci");
- if (np) {
- mpc52xx_add_bridge(np);
- of_node_put(np);
- }
-#endif
+ mpc52xx_setup_pci();
}
/*
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index 4c6c82a..89304f2 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -406,3 +406,18 @@ mpc52xx_add_bridge(struct device_node *node)
return 0;
}
+
+void __init mpc52xx_setup_pci(void)
+{
+ struct device_node *pci;
+
+ pci = of_find_node_by_type(NULL, "pci");
+ if (!pci)
+ return;
+
+ if (of_device_is_compatible(pci, "fsl,mpc5200-pci") ||
+ of_device_is_compatible(pci, "mpc5200-pci"))
+ mpc52xx_add_bridge(pci);
+
+ of_node_put(pci);
+}
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index fcb2ebb..d7efbe0 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -257,7 +257,12 @@ extern void mpc52xx_declare_of_platform_devices(void);
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
+#ifdef CONFIG_PCI
extern int __init mpc52xx_add_bridge(struct device_node *node);
+extern void __init mpc52xx_setup_pci(void);
+#else
+static inline void mpc52xx_setup_pci(void) { }
+#endif
extern void __init mpc52xx_map_wdt(void);
extern void mpc52xx_restart(char *cmd);
^ permalink raw reply related
* [PATCH v4 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-09 17:12 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071109171137.16289.39575.stgit@hekate.izotz.org>
This patch adds support for 'mpc5200-simple-platform' compatible
boards which do not need a platform specific setup. Such boards
are supported assuming the following:
- GPIO pins are configured by the firmware,
- CDM configuration (clocking) is setup correctly by firmware,
- if the 'fsl,has-wdt' property is present in one of the
gpt nodes, then it is safe to use such gpt to reset the board,
- PCI is supported if enabled in the kernel configuration
and if there is a PCI bus node defined in the device tree.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
arch/powerpc/boot/dts/lite5200.dts | 2 -
arch/powerpc/boot/dts/lite5200b.dts | 2 -
arch/powerpc/platforms/52xx/Kconfig | 22 ++++++-
arch/powerpc/platforms/52xx/Makefile | 1
arch/powerpc/platforms/52xx/mpc5200_simple.c | 84 ++++++++++++++++++++++++++
5 files changed, 107 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc5200_simple.c
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index 6731763..5902362 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200";
// revision = "1.0";
- compatible = "fsl,lite5200","generic-mpc5200";
+ compatible = "fsl,lite5200";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index b540388..b509129 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200b";
// revision = "1.0";
- compatible = "fsl,lite5200b","generic-mpc5200";
+ compatible = "fsl,lite5200b";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 2938d49..36e880b 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -19,6 +19,26 @@ config PPC_MPC5200_BUGFIX
It is safe to say 'Y' here
+config PPC_MPC5200_SIMPLE
+ bool "Generic support for simple MPC5200 based boards"
+ depends on PPC_MULTIPLATFORM && PPC32
+ select PPC_MPC5200
+ default n
+ help
+ This option enables support for a simple MPC52xx based boards which
+ do not need a custom platform specific setup. Such boards are
+ supported assuming the following:
+
+ - GPIO pins are configured by the firmware,
+ - CDM configuration (clocking) is setup correctly by firmware,
+ - if the 'fsl,has-wdt' property is present in one of the
+ gpt nodes, then it is safe to use such gpt to reset the board,
+ - PCI is supported if enabled in the kernel configuration
+ and if there is a PCI bus node defined in the device tree.
+
+ Boards that are compatible with this generic platform support
+ are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200'.
+
config PPC_EFIKA
bool "bPlan Efika 5k2. MPC5200B based computer"
depends on PPC_MULTIPLATFORM && PPC32
@@ -34,5 +54,3 @@ config PPC_LITE5200
select WANT_DEVICE_TREE
select PPC_MPC5200
default n
-
-
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index 307dbc1..fe1b81b 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -6,6 +6,7 @@ obj-y += mpc52xx_pic.o mpc52xx_common.o
obj-$(CONFIG_PCI) += mpc52xx_pci.o
endif
+obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
obj-$(CONFIG_PPC_EFIKA) += efika.o
obj-$(CONFIG_PPC_LITE5200) += lite5200.o
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
new file mode 100644
index 0000000..ad50c57
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -0,0 +1,84 @@
+/*
+ * Support for 'mpc5200-simple-platform' compatible boards.
+ *
+ * Written by Marian Balakowicz <m8@semihalf.com>
+ * Copyright (C) 2007 Semihalf
+ *
+ * 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.
+ *
+ * Description:
+ * This code implements support for a simple MPC52xx based boards which
+ * do not need a custom platform specific setup. Such boards are
+ * supported assuming the following:
+ *
+ * - GPIO pins are configured by the firmware,
+ * - CDM configuration (clocking) is setup correctly by firmware,
+ * - if the 'fsl,has-wdt' property is present in one of the
+ * gpt nodes, then it is safe to use such gpt to reset the board,
+ * - PCI is supported if enabled in the kernel configuration
+ * and if there is a PCI bus node defined in the device tree.
+ *
+ * Boards that are compatible with this generic platform support
+ * are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200'.
+ */
+
+#undef DEBUG
+#include <asm/time.h>
+#include <asm/machdep.h>
+#include <asm/mpc52xx.h>
+
+/*
+ * Setup the architecture
+ */
+static void __init mpc5200_simple_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("mpc5200_simple_setup_arch()", 0);
+
+ /* Some mpc5200 & mpc5200b related configuration */
+ mpc5200_setup_xlb_arbiter();
+
+ /* Map wdt for mpc52xx_restart() */
+ mpc52xx_map_wdt();
+
+ mpc52xx_setup_pci();
+}
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init mpc5200_simple_probe(void)
+{
+ unsigned long node = of_get_flat_dt_root();
+ int i = 0;
+
+ /* list of the supported boards */
+ const char *board[] = {
+ "tqc,tqm5200",
+ "promess,motionpro",
+ "schindler,cm5200",
+ NULL
+ };
+
+ while (board[i]) {
+ if (of_flat_dt_is_compatible(node, board[i]))
+ break;
+ i++;
+ }
+
+ return (board[i] != NULL);
+}
+
+define_machine(mpc5200_simple_platform) {
+ .name = "mpc5200-simple-platform",
+ .probe = mpc5200_simple_probe,
+ .setup_arch = mpc5200_simple_setup_arch,
+ .init = mpc52xx_declare_of_platform_devices,
+ .init_IRQ = mpc52xx_init_irq,
+ .get_irq = mpc52xx_get_irq,
+ .restart = mpc52xx_restart,
+ .calibrate_decr = generic_calibrate_decr,
+};
^ permalink raw reply related
* [PATCH v4 05/13] [POWERPC] Export mpc52xx_map_node() routine symbol
From: Marian Balakowicz @ 2007-11-09 17:12 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071109171137.16289.39575.stgit@hekate.izotz.org>
Make, so far static, mpc52xx_map_node() routine
symbol available for general use.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
arch/powerpc/platforms/52xx/mpc52xx_common.c | 3 ++-
include/asm-powerpc/mpc52xx.h | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 2df97c5..7224bfe 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -26,7 +26,7 @@
*/
static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
-static void __iomem *
+void __iomem *
mpc52xx_map_node(struct device_node *ofn)
{
const u32 *regaddr_p;
@@ -47,6 +47,7 @@ mpc52xx_map_node(struct device_node *ofn)
return ioremap((u32)regaddr64, (u32)size64);
}
+EXPORT_SYMBOL_GPL(mpc52xx_map_node);
void __iomem *
mpc52xx_find_and_map(const char *compatible)
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index d7efbe0..1887b13 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -248,6 +248,7 @@ struct mpc52xx_cdm {
#ifndef __ASSEMBLY__
+extern void __iomem * mpc52xx_map_node(struct device_node *);
extern void __iomem * mpc52xx_find_and_map(const char *);
extern void __iomem * mpc52xx_find_and_map_path(const char *path);
extern unsigned int mpc52xx_find_ipb_freq(struct device_node *node);
^ 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