Re: rtas instantiation when commandline contains mem
On Fri, 2009-07-17 at 08:36 +0200, Benjamin Krill wrote: > >> the rtas instantiation (prom_init.c) doesn't work correctly if the > >> kernel parameter "mem=" is used. The current code doesn't evaluate > >> the kernel parameter which causes the issue that alloc_down > >> allocates somewhere in the "real" memory space. So it can > >> happen that the allocation space is above "mem=". > >> > >> Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the > >> evaluation of "mem=". > > > >Ah yes, we don't constraint prom_init.c to mem=, only the kernel > > Is that with intent? Or should I provide a patch to include it again? Well I suppose it makes sense to include it again, not sure about that, there's potentially a similar issue with TCE tables. I understand what you are trying to do (though I told you I don't think it's the right approach ;-) but heh... send a patch we'll see what it looks like. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: rtas instantiation when commandline contains mem
>> the rtas instantiation (prom_init.c) doesn't work correctly if the >> kernel parameter "mem=" is used. The current code doesn't evaluate >> the kernel parameter which causes the issue that alloc_down >> allocates somewhere in the "real" memory space. So it can >> happen that the allocation space is above "mem=". >> >> Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the >> evaluation of "mem=". > >Ah yes, we don't constraint prom_init.c to mem=, only the kernel Is that with intent? Or should I provide a patch to include it again? cheers ben > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Remove use of a second scratch SPRG in STAB code (v2)
The STAB code used on Power3 and RS/64 uses a second scratch SPRG to save a GPR in order to decide whether to go to do_stab_bolted_* or to handle a normal data access exception. This prevents our scheme of freeing SPRG3 which is user visible for user uses since we cannot use SPRG0 which, on RS/64, seems to be read-only for supervisor mode (like POWER4). This reworks the STAB exception entry to use the PACA as temporary storage instead. Signed-off-by: Benjamin Herrenschmidt --- v2. Don't break SLB machines :-) Use alternate CPU features to nicely overlay the code for SLB vs STAB arch/powerpc/include/asm/exception-64s.h |7 +++-- arch/powerpc/include/asm/reg.h |3 -- arch/powerpc/kernel/exceptions-64s.S | 38 +++-- arch/powerpc/platforms/iseries/exception.S | 37 ++-- 4 files changed, 55 insertions(+), 30 deletions(-) --- linux-work.orig/arch/powerpc/include/asm/exception-64s.h2009-07-15 17:42:43.0 +1000 +++ linux-work/arch/powerpc/include/asm/exception-64s.h 2009-07-15 17:42:43.0 +1000 @@ -66,8 +66,7 @@ std r9,area+EX_R13(r13);\ mfcrr9 -#define EXCEPTION_PROLOG_PSERIES(area, label) \ - EXCEPTION_PROLOG_1(area); \ +#define EXCEPTION_PROLOG_PSERIES_1(label) \ ld r12,PACAKBASE(r13); /* get high part of &label */ \ ld r10,PACAKMSR(r13); /* get MSR value for kernel */ \ mfspr r11,SPRN_SRR0; /* save SRR0 */ \ @@ -78,6 +77,10 @@ rfid; \ b . /* prevent speculative execution */ +#define EXCEPTION_PROLOG_PSERIES(area, label) \ + EXCEPTION_PROLOG_1(area); \ + EXCEPTION_PROLOG_PSERIES_1(label); + /* * The common exception prolog is used for all except a few exceptions * such as a segment miss on a kernel address. We have to be prepared Index: linux-work/arch/powerpc/kernel/exceptions-64s.S === --- linux-work.orig/arch/powerpc/kernel/exceptions-64s.S2009-07-15 17:42:43.0 +1000 +++ linux-work/arch/powerpc/kernel/exceptions-64s.S 2009-07-17 12:42:54.0 +1000 @@ -50,18 +50,28 @@ data_access_pSeries: HMT_MEDIUM mtspr SPRN_SPRG_SCRATCH0,r13 BEGIN_FTR_SECTION - mtspr SPRN_SPRG_SCRATCH1,r12 - mfspr r13,SPRN_DAR - mfspr r12,SPRN_DSISR - srdir13,r13,60 - rlwimi r13,r12,16,0x20 - mfcrr12 - cmpwi r13,0x2c + mfspr r13,SPRN_SPRG_PACA + std r9,PACA_EXSLB+EX_R9(r13) + std r10,PACA_EXSLB+EX_R10(r13) + mfspr r10,SPRN_DAR + mfspr r9,SPRN_DSISR + srdir10,r10,60 + rlwimi r10,r9,16,0x20 + mfcrr9 + cmpwi r10,0x2c beq do_stab_bolted_pSeries - mtcrf 0x80,r12 - mfspr r12,SPRN_SPRG_SCRATCH1 -END_FTR_SECTION_IFCLR(CPU_FTR_SLB) + ld r10,PACA_EXSLB+EX_R10(r13) + std r11,PACA_EXGEN+EX_R11(r13) + ld r11,PACA_EXSLB+EX_R9(r13) + std r12,PACA_EXGEN+EX_R12(r13) + mfspr r12,SPRN_SPRG_SCRATCH0 + std r10,PACA_EXGEN+EX_R10(r13) + std r11,PACA_EXGEN+EX_R9(r13) + std r12,PACA_EXGEN+EX_R13(r13) + EXCEPTION_PROLOG_PSERIES_1(data_access_common) +FTR_SECTION_ELSE EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, data_access_common) +ALT_FTR_SECTION_END_IFCLR(CPU_FTR_SLB) . = 0x380 .globl data_access_slb_pSeries @@ -224,9 +234,11 @@ masked_interrupt: .align 7 do_stab_bolted_pSeries: - mtcrf 0x80,r12 - mfspr r12,SPRN_SPRG_SCRATCH1 - EXCEPTION_PROLOG_PSERIES(PACA_EXSLB, .do_stab_bolted) + std r11,PACA_EXSLB+EX_R11(r13) + std r12,PACA_EXSLB+EX_R12(r13) + mfspr r10,SPRN_SPRG_SCRATCH0 + std r10,PACA_EXSLB+EX_R13(r13) + EXCEPTION_PROLOG_PSERIES_1(.do_stab_bolted) #ifdef CONFIG_PPC_PSERIES /* Index: linux-work/arch/powerpc/platforms/iseries/exception.S === --- linux-work.orig/arch/powerpc/platforms/iseries/exception.S 2009-07-15 17:42:43.0 +1000 +++ linux-work/arch/powerpc/platforms/iseries/exception.S 2009-07-17 12:43:01.0 +1000 @@ -128,25 +128,36 @@ iSeries_secondary_smp_loop: data_access_iSeries: mtspr SPRN_SPRG_SCRATCH0,r13 BEGIN_FTR_SECTION - mtspr SPRN_SPRG_SCRATCH1,r12 - mfspr r13,SPRN_DAR - mfspr r12,SPRN_DSISR - srdir13,r13,60 - rlwimi r13,r12,16,0x20 - mfcrr12 - cmpwi r13,0x2c + mfspr r13,SPRN_SPRG_PACA + std r9,PACA_EXSLB+EX_R9(r13) +
Re: [PATCH] Hold reference to device_node during EEH event handling
On Thu, 2009-07-16 at 09:33 -0700, Mike Mason wrote:
> Michael Ellerman wrote:
> > On Wed, 2009-07-15 at 14:43 -0700, Mike Mason wrote:
> >> This patch increments the device_node reference counter when an EEH
> >> error occurs and decrements the counter when the event has been
> >> handled. This is to prevent the device_node from being released until
> >> eeh_event_handler() has had a chance to deal with the event. We've
> >> seen cases where the device_node is released too soon when an EEH
> >> event occurs during a dlpar remove, causing the event handler to
> >> attempt to access bad memory locations.
> >>
> >> Please review and let me know of any concerns.
> >
> > Taking a reference sounds sane, but ...
> >
> >> Signed-off-by: Mike Mason
> >>
> >> --- a/arch/powerpc/platforms/pseries/eeh_event.c 2008-10-09
> >> 15:13:53.0 -0700
> >> +++ b/arch/powerpc/platforms/pseries/eeh_event.c 2009-07-14
> >> 14:14:00.0 -0700
> >> @@ -75,6 +75,14 @@ static int eeh_event_handler(void * dumm
> >>if (event == NULL)
> >>return 0;
> >>
> >> + /* EEH holds a reference to the device_node, so if it
> >> + * equals 1 it's no longer valid and the event should
> >> + * be ignored */
> >> + if (atomic_read(&event->dn->kref.refcount) == 1) {
> >> + of_node_put(event->dn);
> >> + return 0;
> >> + }
> >
> > That's really gross :)
>
> Agreed. I'll look for another way to determine if device is gone and
> the event should be ignored. Suggestions are welcome :-)
Benh and I had a quick chat about it, and were wondering whether what
you really should be doing is taking a reference to the pci device
(perhaps as well as the device node).
@@ -140,7 +149,7 @@ int eeh_send_failure_event (struct devic
if (dev)
pci_dev_get(dev);
- event->dn = dn;
+ event->dn = of_node_get(dn);
event->dev = dev;
pci devs are refcounted too, see pci_dev_get(), so taking a reference
there would be the "right" thing to do - otherwise there's no guarantee
it still exists later, unless there's some other trick in the EEH code.
Taking a reference would presumably block a concurrent hotunplug until
you'd processed the EEH event and dropped your reference. That might be
OK, or you could add a hotplug notifier to the EEH code and drop the
reference there and mark the event as handled or something.
All of that with the caveat that I don't really know the EEH or hotplug
code :D
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
On Thu, 2009-07-16 at 18:52 +0100, Catalin Marinas wrote: > On Thu, 2009-07-16 at 17:43 +1000, Michael Ellerman wrote: > > On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote: > > > Very lightly tested, doesn't crash the kernel. > > > > > > Signed-off-by: Michael Ellerman > > > --- > > > > > > It doesn't look like we actually need to add any support in the > > > arch code - or is there something I'm missing? > > > > Hmm, I think we want to add annotations in lib/lmb.c don't we? That's > > our low-level pre-bootmem allocator. > > Yes, I think so (I'm not using this on ARM or x86 so I can't really test > it). Without these hooks, there kmemleak reports aren't that useful > (probably too many). The wrinkle is that lmb never frees, so by definition it can't leak :) But we could have memory allocated with lmb that has pointers to other objects allocated later, and we want kmemleak to scan the lmb allocated blocks to find those references. So the question is do we need to annotate lmb so that will happen, or does kmemleak scan all kernel memory, regardless of where it's allocated? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v2] MPC52xx FEC: be more conservative when setting MII_SPEED register
On Thu, Jul 16, 2009 at 3:42 PM, Wolfgang Denk wrote:
> This patch adds error checking and prevents clobbering unrelated bits
> (reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
> register on MPC52xx systems.
>
> Signed-off-by: Wolfgang Denk
> Cc: Grant Likely
> Cc: Kumar Gala
> Cc:
Mostly good. One comment below. When it's resolved, feel free to add
my acked-by line. Thanks for getting this done.
> @@ -105,8 +105,23 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
> dev_set_drvdata(dev, bus);
>
> /* set MII speed */
> - out_be32(&priv->regs->mii_speed,
> - ((mpc5xxx_get_bus_frequency(of->node) >> 20) / 5) << 1);
> + clock = mpc5xxx_get_bus_frequency(of->node);
> + if (!clock) {
> + dev_err(&of->dev, "could not determine IPS/IPB clock\n");
> + goto out_unmap;
> + }
Just thought of something. If it cannot find the clock, then wouldn't
it be better to just use the maximum divider and print a warning
instead of bailing completely? This goes for the other patch as well.
> +
> + /* scale for a MII clock <= 2.5 MHz */
> + speed = (clock + 249) / 250;
> +
> + /* only 6 bits (25:30) available for MII speed */
> + if (speed > 0x3F) {
> + speed = 0x3F;
> + dev_err(&of->dev, "MII clock (%d Hz) exceeds max (2.5 MHz)\n",
> + clock / speed);
> + }
> +
> + clrsetbits_be32(&priv->regs->mii_speed, 0x7E, speed << 1);
>
> err = of_mdiobus_register(bus, np);
> if (err)
> --
> 1.6.0.6
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v4] fs_enet/mii-fec.c: fix MII speed calculation
On Thu, Jul 16, 2009 at 3:42 PM, Wolfgang Denk wrote:
> The MII speed calculation was based on the CPU clock (ppc_proc_freq),
> but for MPC512x we must use the bus clock instead.
>
> This patch makes it use the correct clock and makes sure we don't
> clobber reserved bits in the MII_SPEED register.
>
> Signed-off-by: Wolfgang Denk
> Cc: Grant Likely
> Cc: Kumar Gala
> Cc:
Looks good to me. Thanks for the work!
I assume this is tested. I have not tested this on my board, and I've
got one question below, but otherwise I think I can say
Acked-by: Grant Likely
> - fec->mii_speed = ((ppc_proc_freq + 499) / 500) << 1;
> + if (get_bus_freq) {
> + clock = get_bus_freq(ofdev->node);
> +
> + if (!clock) {
> + dev_err(&ofdev->dev, "could not determine IPS/IPB
> clock\n");
> + goto out_unmap_regs;
> + }
> + } else
> + clock = ppc_proc_freq;
> +
> + /* scale for a MII clock <= 2.5 MHz */
> + speed = (clock + 249) / 250;
The calculation has changed here for non mpc5121 users. Shouldn't the
"clock = ppc_proc_freq;" line above be "clock = ppc_proc_freq / 2;"?
Or was this also a bug in the original driver?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v3] fs_enet/mii-fec.c: fix MII speed calculation
On Thu, Jul 16, 2009 at 3:21 PM, Wolfgang Denk wrote: > Dear Grant Likely, > > In message you > wrote: >> On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk wrote: >> > The MII speed calculation was based on the CPU clock (ppc_proc_freq), >> > but for MPC512x we must use the bus clock instead. >> > >> > This patch makes it use the correct clock and makes sure we don't >> > clobber reserved bits in the MII_SPEED register. > ... >> Drop the common code bit. The 5200 and 5121 are different devices and >> it is a tiny bit of code. I don't think there is any benefit to >> having it as a common function. Just roll the get_mii_speed function >> in the mii-fec driver itself. > > I don't like to see the code repeated - it makes maintenance harder > and increases the memory footprint. But if you like it that way I'll > do that. Neither do I, but in this case has some mitigating factors. diff stat is interesting: Old: arch/powerpc/include/asm/mpc5xxx.h | 10 + arch/powerpc/sysdev/mpc5xxx_clocks.c | 37 ++ drivers/net/fs_enet/mii-fec.c| 13 +-- drivers/net/fec_mpc52xx.c |2 +- drivers/net/fec_mpc52xx_phy.c |6 -- 5 files changed, 62 insertions(+), 6 deletions(-) New: drivers/net/fs_enet/mii-fec.c | 35 +++ drivers/net/fec_mpc52xx.c |2 +- drivers/net/fec_mpc52xx_phy.c | 21 ++--- 3 files changed, 50 insertions(+), 8 deletions(-) If the two devices were somewhat related then my opinion might be different. However the combination of the tiny amount of calculation code, the drivers being kept completely separate (or at least as separate as they were before), the smaller code impact, and the lower driver complexity (because the calculation code is inline instead of in a different file) makes me like the second approach is better. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: rtas instantiation when commandline contains mem
On Thu, 2009-07-16 at 15:12 +0200, Benjamin Krill wrote: > Hi, > > the rtas instantiation (prom_init.c) doesn't work correctly if the > kernel parameter "mem=" is used. The current code doesn't evaluate > the kernel parameter which causes the issue that alloc_down > allocates somewhere in the "real" memory space. So it can > happen that the allocation space is above "mem=". > > Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the > evaluation of "mem=". Ah yes, we don't constraint prom_init.c to mem=, only the kernel Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: booting MPC8313 based board with yaffs2 RFS
Rupesh Kumar wrote: Hi I am using MPC8313 board which is currently booting with JFFS2 root file system. I am using linux kernel version 2.6.23 from FreeScale's LTIB for MPC8313. As, I want it to boot with YAFFS2 root file system, I did compile kernel with yaffs2 support, craeted yaffs2 rootfile system and passed yaffs2 partiton of nand in bootargs. However it didnot work. If any one has done it successfully, can please share the steps to be followed ? More detailed info maybe helpful for debugging this issue. 1. What nand flash is on-board? what's the size of the nand flash page size, 512/2048? 2. what's the version of mkyaffs2image you are using? 3. Can you mount an empty nand flash partition using yaffs2 type, mount /dev/mtdblock##x xxx 4. It's better to attatch bootup message. Tony Thanks Rupesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2 v2] MPC52xx FEC: be more conservative when setting MII_SPEED register
This patch adds error checking and prevents clobbering unrelated bits
(reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
register on MPC52xx systems.
Signed-off-by: Wolfgang Denk
Cc: Grant Likely
Cc: Kumar Gala
Cc:
---
drivers/net/fec_mpc52xx.c |2 +-
drivers/net/fec_mpc52xx_phy.c | 21 ++---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cc78633..b69d440 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -639,7 +639,7 @@ static void mpc52xx_fec_hw_init(struct net_device *dev)
/* set phy speed.
* this can't be done in phy driver, since it needs to be called
* before fec stuff (even on resume) */
- out_be32(&fec->mii_speed, priv->mdio_speed);
+ clrsetbits_be32(&fec->mii_speed, 0x7E, priv->mdio_speed);
}
/**
diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c
index 31e6d62..4c33dc5 100644
--- a/drivers/net/fec_mpc52xx_phy.c
+++ b/drivers/net/fec_mpc52xx_phy.c
@@ -70,7 +70,7 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
struct mpc52xx_fec_mdio_priv *priv;
struct resource res = {};
int err;
- int i;
+ int i, clock, speed;
bus = mdiobus_alloc();
if (bus == NULL)
@@ -105,8 +105,23 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
dev_set_drvdata(dev, bus);
/* set MII speed */
- out_be32(&priv->regs->mii_speed,
- ((mpc5xxx_get_bus_frequency(of->node) >> 20) / 5) << 1);
+ clock = mpc5xxx_get_bus_frequency(of->node);
+ if (!clock) {
+ dev_err(&of->dev, "could not determine IPS/IPB clock\n");
+ goto out_unmap;
+ }
+
+ /* scale for a MII clock <= 2.5 MHz */
+ speed = (clock + 249) / 250;
+
+ /* only 6 bits (25:30) available for MII speed */
+ if (speed > 0x3F) {
+ speed = 0x3F;
+ dev_err(&of->dev, "MII clock (%d Hz) exceeds max (2.5 MHz)\n",
+ clock / speed);
+ }
+
+ clrsetbits_be32(&priv->regs->mii_speed, 0x7E, speed << 1);
err = of_mdiobus_register(bus, np);
if (err)
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2 v4] fs_enet/mii-fec.c: fix MII speed calculation
The MII speed calculation was based on the CPU clock (ppc_proc_freq),
but for MPC512x we must use the bus clock instead.
This patch makes it use the correct clock and makes sure we don't
clobber reserved bits in the MII_SPEED register.
Signed-off-by: Wolfgang Denk
Cc: Grant Likely
Cc: Kumar Gala
Cc:
Signed-off-by: Wolfgang Denk
---
drivers/net/fs_enet/mii-fec.c | 35 +++
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 75a0999..62b2d7a 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -103,11 +103,11 @@ static int fs_enet_fec_mii_reset(struct mii_bus *bus)
static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct resource res;
struct mii_bus *new_bus;
struct fec_info *fec;
- int ret = -ENOMEM, i;
+ int (*get_bus_freq)(struct device_node *) = match->data;
+ int ret = -ENOMEM, clock, speed;
new_bus = mdiobus_alloc();
if (!new_bus)
@@ -133,13 +133,34 @@ static int __devinit fs_enet_mdio_probe(struct of_device
*ofdev,
if (!fec->fecp)
goto out_fec;
- fec->mii_speed = ((ppc_proc_freq + 499) / 500) << 1;
+ if (get_bus_freq) {
+ clock = get_bus_freq(ofdev->node);
+
+ if (!clock) {
+ dev_err(&ofdev->dev, "could not determine IPS/IPB
clock\n");
+ goto out_unmap_regs;
+ }
+ } else
+ clock = ppc_proc_freq;
+
+ /* scale for a MII clock <= 2.5 MHz */
+ speed = (clock + 249) / 250;
+
+ /* only 6 bits (25:30) available for MII speed */
+ if (speed > 0x3F) {
+ speed = 0x3F;
+ dev_err(&ofdev->dev,
+ "MII clock (%d Hz) exceeds max (2.5 MHz)\n",
+ clock / speed);
+ }
+
+ fec->mii_speed = speed << 1;
setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
setbits32(&fec->fecp->fec_ecntrl, FEC_ECNTRL_PINMUX |
FEC_ECNTRL_ETHER_EN);
out_be32(&fec->fecp->fec_ievent, FEC_ENET_MII);
- out_be32(&fec->fecp->fec_mii_speed, fec->mii_speed);
+ clrsetbits_be32(&fec->fecp->fec_mii_speed, 0x7E, fec->mii_speed);
new_bus->phy_mask = ~0;
new_bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
@@ -188,6 +209,12 @@ static struct of_device_id fs_enet_mdio_fec_match[] = {
{
.compatible = "fsl,pq1-fec-mdio",
},
+#if defined(CONFIG_PPC_MPC512x)
+ {
+ .compatible = "fsl,mpc5121-fec-mdio",
+ .data = mpc5xxx_get_bus_frequency,
+ },
+#endif
{},
};
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] MPC52xx FEC: be more conservative when setting MII_SPEED register
Dear Grant Likely, In message you wrote: > On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk wrote: > > This patch adds error checking and prevents clobbering unrelated bits > > (reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED > > register on MPC52xx systems. ... > As I mentioned in the other patch, I don't want the 5121 and 5200 FEC > devices using common code for this. It is a tiny block of code and > they are different devices. Just open code the needed calculation > into this driver. OK, will do. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v3] fs_enet/mii-fec.c: fix MII speed calculation
Dear Grant Likely, In message you wrote: > On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk wrote: > > The MII speed calculation was based on the CPU clock (ppc_proc_freq), > > but for MPC512x we must use the bus clock instead. > > > > This patch makes it use the correct clock and makes sure we don't > > clobber reserved bits in the MII_SPEED register. ... > Drop the common code bit. The 5200 and 5121 are different devices and > it is a tiny bit of code. I don't think there is any benefit to > having it as a common function. Just roll the get_mii_speed function > in the mii-fec driver itself. I don't like to see the code repeated - it makes maintenance harder and increases the memory footprint. But if you like it that way I'll do that. > Also, this patch can be quite a bit simpler if you use the .data > pointer in the drivers match table to specify the function used to > return the bus clock speed. Something like this: OK, will do that, too. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Weekends were made for programming. - Karl Lehenbauer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc83xx/usb.c: fix usb mux setup for mpc834x
> "Kumar" == Kumar Gala writes: Hi, Kumar> On Jun 9, 2009, at 6:43 AM, Peter Korsgaard wrote: >> usb0 and usb1 mux settings in the sicrl register were swapped (twice!) >> in mpc834x_usb_cfg(), leading to various strange issues with fsl-ehci >> and full speed devices. >> >> The USB port config on mpc834x is done using 2 muxes: Port 0 is >> always used for MPH port 0, and port 1 can either be used for MPH >> port 1 or DR (unless DR uses TMDI phy or OTG, then it uses both >> ports) - See 8349 RM figure 1-4.. >> >> mpc8349_usb_cfg() had this inverted for the DR, and it also had >> the bit positions of the usb0 / usb1 mux settings swapped. It >> would basically work if you specified port1 instead of port0 for >> the MPH controller (and happened to use ULPI phys), which is what >> all the 834x dts have done, even though that configuration is >> physically invalid. >> >> Instead fix mpc8349_usb_cfg() and adjust the dts files to match >> reality. >> >> Signed-off-by: Peter Korsgaard Kumar> applied.. Please remind me to send this linux-stable for .30 and .29 *Remind* -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
On Thu, 2009-07-16 at 17:43 +1000, Michael Ellerman wrote: > On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote: > > Very lightly tested, doesn't crash the kernel. > > > > Signed-off-by: Michael Ellerman > > --- > > > > It doesn't look like we actually need to add any support in the > > arch code - or is there something I'm missing? > > Hmm, I think we want to add annotations in lib/lmb.c don't we? That's > our low-level pre-bootmem allocator. Yes, I think so (I'm not using this on ARM or x86 so I can't really test it). Without these hooks, there kmemleak reports aren't that useful (probably too many). -- Catalin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: riscwatch shows up core status UNKNOWN for 970mp ppc processor
On Thu, Jul 16, 2009 at 5:32 AM, anil kumar wrote: > Hello > I am newbie to RISCWatch and debugging using JTAG interface .I want to debug > Linux Kernel on target board > using jtag interface provided on board. > > To debug 970MP dual core ppc processor on traget board, I installed > RISCWatch software on my window host. > > My Setup: > -- > Host <--(over ethernet)--> RISCWatch 13H6423 <--(jtag interface)--> 970MP > Processor > > I am able to detect two core on target 970MP processor but it shows both > cores as `UNKNOWN` . I have no idea, > why riscwatch shows up status of both cores as UNKNOWN? You should probably contact ppcs...@us.ibm.com instead of this mailing list. -Hollis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
On Thu, 2009-07-16 at 07:31 -0400, Josh Boyer wrote: > On Thu, Jul 16, 2009 at 05:43:50PM +1000, Michael Ellerman wrote: > >On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote: > >> Very lightly tested, doesn't crash the kernel. > >> > >> Signed-off-by: Michael Ellerman > >> --- > >> > >> It doesn't look like we actually need to add any support in the > >> arch code - or is there something I'm missing? > > > >Hmm, I think we want to add annotations in lib/lmb.c don't we? That's > >our low-level pre-bootmem allocator. > > > >And we have the same problem with _edata as x86. > > I'll point out that the Fedora developers enabled this in the rawhide kernels > for 3 days, and then turned it back off because most of the things found were > false positives. Yes, but with 2.6.31-rc3 the number of false positives dropped considerably. I don't plan to push any new kmemleak patches for 2.6.31 (probably only a bug-fix). Anyway, even when it reports real leaks, it is very time consuming to investigate. I don't have any PPC hardware but as long as someone sorts out things like _edata or other PPC-specific allocators which aren't currently tracked by kmemleak, I'm OK with the original patch: Acked-by: Catalin Marinas -- Catalin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
riscwatch shows up core status UNKNOWN for 970mp ppc processor
Hello I am newbie to RISCWatch and debugging using JTAG interface .I want to debug Linux Kernel on target board using jtag interface provided on board. To debug 970MP dual core ppc processor on traget board, I installed RISCWatch software on my window host. My Setup: -- Host <--(over ethernet)--> RISCWatch 13H6423 <--(jtag interface)--> 970MP Processor I am able to detect two core on target 970MP processor but it shows both cores as `UNKNOWN` . I have no idea, why riscwatch shows up status of both cores as UNKNOWN? I would like to mention: - 1) After attaching JTAG cable & switching on riscwatch box, powered cycle was done on the target board and restart RISCWatch. But still core status is shown `UNKNOWN` 2) For PVR value 0x00440101, I used `REV = 1' in rwppc.env file. Correct us if I am wrong. 3) I am able to ping RISCWatch 13H6423 from host system. 4) When I reset target board, target status changes from "UNKNOWN to HALTED" and "HALTED to UNKNOWN" I noticed that PVR register value is 0x00440101. I am not sure if this confirms that revision of the processor(970mp) is 1. Please find the rwppc.env file (C:\Program Files\RISCWatch\rwppc.env) that I configured: -- -- PROC = 970MP REV = 1 TARGET_TYPE = jtag_eth TARGET_NAME = 192.168.10.5 RWPPC_DIR = . SEARCH_PATH = . LOG_FILE_DIR = . SAVE_LAYOUT = no PRD_FILE = rwppc.prd Please find board information: -- KAT2000 970MP (1.0)=> boardinfo board config data version: 1.0 processor name : 970MP processor PVR value : 0x00440101 timer clock frequency: 11250 total SDRAM memory : 4096MB SDRAM frequency : 5 system clk frequency (Hz): 22500 CPU frequency: 18 CPU frequency ind. est. : 181200 CPU to EI speed ratio: 2:1 frequency scaling divider: 1 serial clk frequency : 1843200 HID0 value : 001100818000 HID1 value : fd3c2000 HID4 value : 0010 HID5 value : 0080 SDR1 value : 00d2 PIR value : Ethernet hardware addr 0 : RISCWatch log: -- 12:37:18 - RISCWatch program start 12:37:18 - RISCWatch v7.1 for Windows XP 12:37:18 - Current directory: C:\Program Files\RISCWatch 12:37:18 - Environment file: RWPPC.ENV 12:37:18 - RWPPC_DIR = . 12:37:18 - TARGET_TYPE = JTAG_Ethernet 12:37:18 - TARGET_NAME = 192.168.10.5 12:37:18 - Requested Processor 970MPRev1:CORE1 12:37:18 - Requested Processor 970MPRev1:CORE2 12:37:18 - Unable to get port number for jtag_eth service, using 6470 default 12:37:30 - Configuring probe 12:37:30 - cf default; jtagch a32,a32 12:37:31 - HPE8130A Series Emulation System 12:37:31 - Version: A.01.20 04Apr02 Unreleased 12:37:31 - Location: Generics 12:37:31 - HPEGPUL PowerPC 970 JTAG Emulator 12:37:31 - Version: A.00.I0 22Jul08 13:48 Proto 12:37:31 - WARNING : Could not read processor status, slowing JTAG clock and retrying 12:37:31 - ERROR : bad status received, see README for possible causes 12:37:36 - Starting MPS mode 12:43:18 - STATUS : CORE1 status changed from UNKNOWN to HALTED 12:43:18 - STATUS : CORE2 status changed from UNKNOWN to HALTED Note---> Status become HALTED because I reset target board 12:43:19 - ERROR : CORE1 status changed from HALTED to UNKNOWN 12:43:19 - ERROR : CORE2 status changed from HALTED to UNKNOWN Thanks in advance. Regards, Anil ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Linux with RAM mapped other than zero.
Hi all, I've a system design (32 bit) with SDRAM mapped at 0xf800 rather
than at 0. what are the changes i should make to successfully boot a kernel..?
my design with SDRAM at 0 (64MB) is working fine with xilinx git line
kernel(2.6.27). i was using 'make simpleImage.xilinx (where xilinx.dts is my
device tree file) i tried to change the link_address in
arch/powerpc/boot/wrapper from 0x40 to 0xf400. when i analysed the dump
with step mode in xmd, it fails in platform_init()function in
arch/powerpc/boot/simpleboot.c may be at /* Only interested in memory based at
0 */
for (i = 0; i < *na; i++)
if (*reg++ != 0)
fatal("Memory range is not based at address 0\n"); can anyone tell what are
the changes i shoud do if my memory ranges from 0xf800 to 0xfbff..?
(64MB)
is it possible to change the physical address of kernel from 0 to any other
location..? is the option provided in menuconfig..? or in any linker script..?
Thanks in advance,Sumesh.
_
Looking for a new car this winter? Let us help with car news, reviews and more
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Hold reference to device_node during EEH event handling
Michael Ellerman wrote:
On Wed, 2009-07-15 at 14:43 -0700, Mike Mason wrote:
This patch increments the device_node reference counter when an EEH
error occurs and decrements the counter when the event has been
handled. This is to prevent the device_node from being released until
eeh_event_handler() has had a chance to deal with the event. We've
seen cases where the device_node is released too soon when an EEH
event occurs during a dlpar remove, causing the event handler to
attempt to access bad memory locations.
Please review and let me know of any concerns.
Taking a reference sounds sane, but ...
Signed-off-by: Mike Mason
--- a/arch/powerpc/platforms/pseries/eeh_event.c2008-10-09
15:13:53.0 -0700
+++ b/arch/powerpc/platforms/pseries/eeh_event.c2009-07-14
14:14:00.0 -0700
@@ -75,6 +75,14 @@ static int eeh_event_handler(void * dumm
if (event == NULL)
return 0;
+ /* EEH holds a reference to the device_node, so if it
+* equals 1 it's no longer valid and the event should
+* be ignored */
+ if (atomic_read(&event->dn->kref.refcount) == 1) {
+ of_node_put(event->dn);
+ return 0;
+ }
That's really gross :)
Agreed. I'll look for another way to determine if device is gone and the event
should be ignored. Suggestions are welcome :-)
And what happens if the refcount goes to 1 just after the check? ie.
here.
/* Serialize processing of EEH events */
mutex_lock(&eeh_event_mutex);
eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for powerpc
Hi We are using Linux kernel 2.6.23 from freescale LTIB (MPC8313E_RDB_K26_20081226-LTIB.iso) on our custom board. JFFS2 is used as RFS and nand write.jffs2 utility in the u-boot is used to burn the image on to the nand flash. When we boot for the first time everything seems to be OK. On subsequent reboots we are seeing following error messages reported by kernel on bootup. In addition we also see Magic bitmask errors being reported. /// mtd->read(0x400 bytes from 0x1b0) returned ECC error jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01b001d0: 0xfffe instead mtd->read(0x400 bytes from 0x250) returned ECC error mtd->read(0x400 bytes from 0x27c) returned ECC error mtd->read(0x400 bytes from 0x2c2) returned ECC error mtd->read(0x400 bytes from 0x2cc) returned ECC error mtd->read(0x400 bytes from 0x2d0) returned ECC error jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x02d00074: 0xfffe instead Empty flash at 0x02d00078 ends at 0x02d003e4 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x02d003e4: 0xffef instead Empty flash at 0x02d003e8 ends at 0x02d00780 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x02d00780: 0xfffb instead mtd->read(0x400 bytes from 0x332) returned ECC error jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03320190: 0x instead Empty flash at 0x03320194 ends at 0x0332047c We verified erase size passed as an argument for creating jffs2 file system (initial googling on the issue). After contacting freescale we came to know that, it is a known issue and they dont have planned to work on this in near future. :( Please give your valuable suggestions so that we can fix this problem and make our board running properly. Thanks Rupesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
rtas instantiation when commandline contains mem
Hi, the rtas instantiation (prom_init.c) doesn't work correctly if the kernel parameter "mem=" is used. The current code doesn't evaluate the kernel parameter which causes the issue that alloc_down allocates somewhere in the "real" memory space. So it can happen that the allocation space is above "mem=". Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the evaluation of "mem=". cheers ben ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
On Thu, Jul 16, 2009 at 05:43:50PM +1000, Michael Ellerman wrote: >On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote: >> Very lightly tested, doesn't crash the kernel. >> >> Signed-off-by: Michael Ellerman >> --- >> >> It doesn't look like we actually need to add any support in the >> arch code - or is there something I'm missing? > >Hmm, I think we want to add annotations in lib/lmb.c don't we? That's >our low-level pre-bootmem allocator. > >And we have the same problem with _edata as x86. I'll point out that the Fedora developers enabled this in the rawhide kernels for 3 days, and then turned it back off because most of the things found were false positives. Might still be worth poking at, but until it gets a bit less buggy itself it could be a timesink. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a couple of fixes for powerpc for 2.6.31. The following changes since commit e9e961c9a818a2f24711af493b907a8e40a69efc: Linus Torvalds (1): Merge branch 'i2c-for-2631-rc3' of git://aeryn.fluff.org.uk/bjdooks/linux are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Andreas Schwab (1): powerpc: Fix another bug in move of altivec code to vector.S Dave Kleikamp (1): powerpc: Fix booke user_disable_single_step() arch/powerpc/kernel/ptrace.c | 17 + arch/powerpc/kernel/vector.S |6 +++--- 2 files changed, 12 insertions(+), 11 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote: > Very lightly tested, doesn't crash the kernel. > > Signed-off-by: Michael Ellerman > --- > > It doesn't look like we actually need to add any support in the > arch code - or is there something I'm missing? Hmm, I think we want to add annotations in lib/lmb.c don't we? That's our low-level pre-bootmem allocator. And we have the same problem with _edata as x86. And I'm seeing lots (~250) of these: unreferenced object 0xc000fcd2e2f0 (size 16): comm "swapper", pid 1, jiffies 4294892393 backtrace: [] .create_object+0x164/0x2a8 [] .kmemleak_alloc+0x74/0x120 [] .__kmalloc+0x20c/0x2ac [] .kvasprintf+0x64/0xb0 [] .kobject_set_name_vargs+0x44/0xb4 [] .dev_set_name+0x50/0x6c [] .scsi_sysfs_device_initialize+0xd0/0x16c [] .scsi_alloc_sdev+0x1c4/0x284 [] .scsi_probe_and_add_lun+0x144/0xbd4 [] .__scsi_scan_target+0xfc/0x658 [] .scsi_scan_channel+0x78/0xe8 [] .scsi_scan_host_selected+0xcc/0x154 [] .do_scsi_scan_host+0xe8/0x10c [] .scsi_scan_host+0x250/0x294 [] .ibmvscsi_probe+0x4f8/0x630 [] .vio_bus_probe+0x360/0x3cc cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
