* Re: Simple question about powerpc asm.
From: Valentine @ 2009-07-18 13:55 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: HongWoo Lee, linuxppc-dev
In-Reply-To: <20090718125452.3760D832E416@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Valentine,
>
> In message <4A61A48D.8060601@ru.mvista.com> you wrote:
>> PowerPC instructions are 32-bit long. So, there are only 16 bits
>> available within the instruction for constant values. Since address can
>> be up to 64 bits, we have to load it a piece at a time. The "@" within
>> the assembler instruct it to give a specially-processed form of a symbol
>> value:
>>
>> @highest -- refers to bits 48-63 of a constant
>> @higher -- refers to bits 32-47 of a constant
>> @h -- refers to bits 16-31 of a constant
>> @l -- refers to bits 0-15 of a constant
>
> Actually these bit numbers are wrong, as bit 0 is the MSB for PowerPC
> ;-)
All right, you got me ;)
Even copy-pasting from the IBM docs, one has to double-check :)
Regards,
Val.
>
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* [PATCH] viotape: Fix memory and semaphore leak
From: Michael Buesch @ 2009-07-18 13:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dave Boutcher, Ryan Arnold, Colin Devilbiss
This patch fixes a memory and semaphore leak in the viotape driver's
char device write op. It leaks the DMA memory and the semaphore lock
in case the device was opened with O_NONBLOCK.
This patch is only compile tested, because I do not have the hardware.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
drivers/char/viotape.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
--- linux-2.6.orig/drivers/char/viotape.c
+++ linux-2.6/drivers/char/viotape.c
@@ -401,30 +401,31 @@ static ssize_t viotap_write(struct file
viopath_targetinst(viopath_hostLp),
(u64)(unsigned long)op, VIOVERSION << 16,
((u64)devi.devno << 48) | op->dmaaddr, count, 0, 0);
if (hvrc != HvLpEvent_Rc_Good) {
printk(VIOTAPE_KERN_WARN "hv error on op %d\n",
(int)hvrc);
ret = -EIO;
goto free_dma;
}
- if (noblock)
- return count;
-
- wait_for_completion(&op->com);
+ if (noblock) {
+ ret = count;
+ } else {
+ wait_for_completion(&op->com);
- if (op->rc)
- ret = tape_rc_to_errno(op->rc, "write", devi.devno);
- else {
- chg_state(devi.devno, VIOT_WRITING, file);
- ret = op->count;
+ if (op->rc)
+ ret = tape_rc_to_errno(op->rc, "write", devi.devno);
+ else {
+ chg_state(devi.devno, VIOT_WRITING, file);
+ ret = op->count;
+ }
}
free_dma:
dma_free_coherent(op->dev, count, op->buffer, op->dmaaddr);
up_sem:
up(&reqSem);
free_op:
free_op_struct(op);
return ret;
}
--
Greetings, Michael.
^ permalink raw reply
* how do linux active the ppc405 cache?
From: Li Jun (Aaron) @ 2009-07-18 12:55 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Hi all,
I have a question about cache activation on the Xilinx Virtex4 ML403 board.
I know that PowerPC instruction and data caches have to be activated
manually with the command
XCache_EnableICache();
XCache_EnableDCache();
It works well with the standalone application, but how about it in Linux
system?
When porting a linux 2.6 on the board, how the cache can be activated by
the OS?
Thanks
[-- Attachment #2: Type: text/html, Size: 2542 bytes --]
^ permalink raw reply
* Re: Simple question about powerpc asm.
From: Wolfgang Denk @ 2009-07-18 12:54 UTC (permalink / raw)
To: Valentine; +Cc: HongWoo Lee, linuxppc-dev
In-Reply-To: <4A61A48D.8060601@ru.mvista.com>
Dear Valentine,
In message <4A61A48D.8060601@ru.mvista.com> you wrote:
>
> PowerPC instructions are 32-bit long. So, there are only 16 bits
> available within the instruction for constant values. Since address can
> be up to 64 bits, we have to load it a piece at a time. The "@" within
> the assembler instruct it to give a specially-processed form of a symbol
> value:
>
> @highest -- refers to bits 48-63 of a constant
> @higher -- refers to bits 32-47 of a constant
> @h -- refers to bits 16-31 of a constant
> @l -- refers to bits 0-15 of a constant
Actually these bit numbers are wrong, as bit 0 is the MSB for PowerPC
;-)
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: wd@denx.de
Emotions are alien to me. I'm a scientist.
-- Spock, "This Side of Paradise", stardate 3417.3
^ permalink raw reply
* Re: [PATCH RFC 1/2] Makefile: Never use -fno-omit-frame-pointer
From: Ingo Molnar @ 2009-07-18 12:01 UTC (permalink / raw)
To: Anton Vorontsov, Sam Ravnborg
Cc: linuxppc-dev, Steven Rostedt, Sam Ravnborg, linux-kernel
In-Reply-To: <20090714133716.GC28970@oksana.dev.rtsoft.ru>
* Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Wed, Jun 17, 2009 at 12:16:30AM +0400, Anton Vorontsov wrote:
> > According to Segher Boessenkool and GCC manual, -fomit-frame-pointer
> > is only the default when optimising on archs/ABIs where it doesn't
> > hinder debugging and -pg. So, we do not get it by default on x86,
> > not at any optimisation level.
> >
> > On the other hand, *using* -fno-omit-frame-pointer causes gcc to
> > produce buggy code on PowerPC targets.
> >
> > If Segher and GCC manual are right, this patch should be a no-op
> > for all arches except PowerPC, where the patch fixes gcc issues.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> >
> > See this thread for more discussion:
> > http://osdir.com/ml/linux-kernel/2009-05/msg01754.html
> >
> > p.s.
> > Obviously, I didn't test this patch on anything else but PPC32. ;-)
> >
> > Segher, do you know if all GCC versions that we support for
> > building Linux are behaving the way that GCC manual describe?
>
> No news is good news... Ingo, can we merge this into -tip for
> testing?
Changes to the top level Makefile should really go via Sam's kbuild
tree.
Ingo
^ permalink raw reply
* Re: Simple question about powerpc asm.
From: Valentine @ 2009-07-18 10:31 UTC (permalink / raw)
To: HongWoo Lee; +Cc: linuxppc-dev
In-Reply-To: <4A6194D8.9090602@gmail.com>
HongWoo Lee wrote:
> Hi all,
>
> I was reading kernel level source and found this macro.
>
> #define SET_REG_TO_LABEL(reg, label) \
> lis reg,(label)@highest; \
> ori reg,reg,(label)@higher; \
> rldicr reg,reg,32,31; \
> oris reg,reg,(label)@h; \
> ori reg,reg,(label)@l;
>
> But, I couldn't find any clue related with @highest, @higher, @h, @l.
>
> If anybody know about this directives(?), please explain it.
> Or just let me know the keyword, so I can search with those keyword.
>
PowerPC instructions are 32-bit long. So, there are only 16 bits
available within the instruction for constant values. Since address can
be up to 64 bits, we have to load it a piece at a time. The "@" within
the assembler instruct it to give a specially-processed form of a symbol
value:
@highest -- refers to bits 48-63 of a constant
@higher -- refers to bits 32-47 of a constant
@h -- refers to bits 16-31 of a constant
@l -- refers to bits 0-15 of a constant
> Thanks in advance.
>
> HongWoo.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ingo Molnar @ 2009-07-18 10:41 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, Ian.Campbell,
linuxppc-dev, joerg.roedel
In-Reply-To: <20090713181558B.fujita.tomonori@lab.ntt.co.jp>
* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> On Mon, 13 Jul 2009 13:20:22 +0900
> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>
> > On Fri, 10 Jul 2009 16:12:48 +0200
> > Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > > functionality and reimplemented the surrounding infrastructure in
> > > > terms of that (and incorporating our additional requirements). I
> > > > prototyped this (it is currently unworking, in fact it seems to
> > > > have developed rather a taste for filesystems :-() but the
> > > > diffstat of my WIP patch is:
> > > >
> > > > arch/x86/kernel/pci-swiotlb.c | 6
> > > > arch/x86/xen/pci-swiotlb.c | 2
> > > > drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> > > > include/linux/swiotlb.h | 12 +
> > > > lib/swiotlb.c | 10 -
> > > > 5 files changed, 385 insertions(+), 30 deletions(-)
> > > >
> > > > where a fair number of the lines in xen-iommu.c are copies of
> > > > functions from swiotlb.c with minor modifications. As I say it
> > > > doesn't work yet but I think it's roughly indicative of what such
> > > > an approach would look like. I don't like it much but am happy to
> > > > run with it if it looks to be the most acceptable approach. [...]
> > >
> > > +400 lines of code to avoid much fewer lines of generic code impact
> > > on the lib/swiotlb.c side sounds like a bad technical choice to me.
> >
> > The amount of code is not the point. The way to impact on the
> > lib/swiotlb.c is totally wrong from the perspective of the kernel
> > design; it uses architecture code in the very original (xen) way.
>
> btw, '+400 lines of code to avoid much fewer lines of generic code
> impact on the lib/swiotlb.c' doesn't sound true to me.
>
> Here is a patch in the way that Xen people want to do:
>
> http://patchwork.kernel.org/patch/26343/
>
> ---
> arch/x86/Kconfig | 4 +
> arch/x86/include/asm/io.h | 2 +
> arch/x86/include/asm/pci_x86.h | 1 +
> arch/x86/include/asm/xen/iommu.h | 12 ++
> arch/x86/kernel/pci-dma.c | 3 +
> arch/x86/pci/Makefile | 1 +
> arch/x86/pci/init.c | 6 +
> arch/x86/pci/xen.c | 51 +++++++
> drivers/pci/Makefile | 2 +
> drivers/pci/xen-iommu.c | 271 ++++++++++++++++++++++++++++++++++++++
>
> Even with the way that Xen people want to do,
> drivers/pci/xen-iommu.c is about 300 lines. And my patchset
> removes the nice amount of lines for dom0 support. I don't see
> much difference wrt lines.
ok, that kind of impact looks reasonable. If we are wrong and the
Xen model becomes duplicated anywhere else it can still be
generalized into core swiotlb code.
Ingo
^ permalink raw reply
* Simple question about powerpc asm.
From: HongWoo Lee @ 2009-07-18 9:24 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I was reading kernel level source and found this macro.
#define SET_REG_TO_LABEL(reg, label) \
lis reg,(label)@highest; \
ori reg,reg,(label)@higher; \
rldicr reg,reg,32,31; \
oris reg,reg,(label)@h; \
ori reg,reg,(label)@l;
But, I couldn't find any clue related with @highest, @higher, @h, @l.
If anybody know about this directives(?), please explain it.
Or just let me know the keyword, so I can search with those keyword.
Thanks in advance.
HongWoo.
^ permalink raw reply
* [PATCH] prom_init: evaluate mem kernel parameter for early allocation
From: Benjamin Krill @ 2009-07-17 20:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman; +Cc: linuxppc-dev
Evaluate mem kernel parameter for early memory allocations. If mem is set
no allocation in the region above the given boundary is allowed. The current
code doesn't take care about this and allocate memory above the given mem
boundary.
Signed-off-by: Benjamin Krill <ben@codiert.org>
---
arch/powerpc/kernel/prom_init.c | 100 +++++++++++++++++++++++++++++++++++++++
1 files changed, 100 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index a538824..7c5b618 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -190,6 +190,8 @@ static int __initdata of_platform;
static char __initdata prom_cmd_line[COMMAND_LINE_SIZE];
+static unsigned long __initdata prom_memory_limit;
+
static unsigned long __initdata alloc_top;
static unsigned long __initdata alloc_top_high;
static unsigned long __initdata alloc_bottom;
@@ -484,6 +486,67 @@ static int __init prom_setprop(phandle node, const char *nodename,
return call_prom("interpret", 1, 1, (u32)(unsigned long) cmd);
}
+/* We can't use the standard versions because of RELOC headaches. */
+#define isxdigit(c) (('0' <= (c) && (c) <= '9') \
+ || ('a' <= (c) && (c) <= 'f') \
+ || ('A' <= (c) && (c) <= 'F'))
+
+#define isdigit(c) ('0' <= (c) && (c) <= '9')
+#define islower(c) ('a' <= (c) && (c) <= 'z')
+#define toupper(c) (islower(c) ? ((c) - 'a' + 'A') : (c))
+
+unsigned long prom_strtoul(const char *cp, const char **endp)
+{
+ unsigned long result = 0, base = 10, value;
+
+ if (*cp == '0') {
+ base = 8;
+ cp++;
+ if (toupper(*cp) == 'X') {
+ cp++;
+ base = 16;
+ }
+ }
+
+ while (isxdigit(*cp) &&
+ (value = isdigit(*cp) ? *cp - '0' : toupper(*cp) - 'A' + 10) < base) {
+ result = result * base + value;
+ cp++;
+ }
+
+ if (endp)
+ *endp = cp;
+
+ return result;
+}
+
+unsigned long prom_memparse(const char *ptr, const char **retptr)
+{
+ unsigned long ret = prom_strtoul(ptr, retptr);
+ int shift = 0;
+
+ /*
+ * We can't use a switch here because GCC *may* generate a
+ * jump table which won't work, because we're not running at
+ * the address we're linked at.
+ */
+ if ('G' == **retptr || 'g' == **retptr)
+ shift = 30;
+
+ if ('M' == **retptr || 'm' == **retptr)
+ shift = 20;
+
+ if ('K' == **retptr || 'k' == **retptr)
+ shift = 10;
+
+ if (shift) {
+ ret <<= shift;
+ (*retptr)++;
+ }
+
+ return ret;
+}
+
/*
* Early parsing of the command line passed to the kernel, used for
* "mem=x" and the options that affect the iommu
@@ -521,6 +584,15 @@ static void __init early_cmdline_parse(void)
RELOC(prom_iommu_force_on) = 1;
}
#endif
+ opt = strstr(RELOC(prom_cmd_line), RELOC("mem="));
+ if (opt) {
+ opt += 4;
+ RELOC(prom_memory_limit) = prom_memparse(opt, (const char **)&opt);
+#ifdef CONFIG_PPC64
+ /* Align to 16 MB == size of ppc64 large page */
+ RELOC(prom_memory_limit) = ALIGN(RELOC(prom_memory_limit), 0x1000000);
+#endif
+ }
}
#ifdef CONFIG_PPC_PSERIES
@@ -1027,6 +1099,29 @@ static void __init prom_init_mem(void)
}
/*
+ * If prom_memory_limit is set we reduce the upper limits *except* for
+ * alloc_top_high. This must be the real top of RAM so we can put
+ * TCE's up there.
+ */
+
+ RELOC(alloc_top_high) = RELOC(ram_top);
+
+ if (RELOC(prom_memory_limit)) {
+ if (RELOC(prom_memory_limit) <= RELOC(alloc_bottom)) {
+ prom_printf("Ignoring mem=%x <= alloc_bottom.\n",
+ RELOC(prom_memory_limit));
+ RELOC(prom_memory_limit) = 0;
+ } else if (RELOC(prom_memory_limit) >= RELOC(ram_top)) {
+ prom_printf("Ignoring mem=%x >= ram_top.\n",
+ RELOC(prom_memory_limit));
+ RELOC(prom_memory_limit) = 0;
+ } else {
+ RELOC(ram_top) = RELOC(prom_memory_limit);
+ RELOC(rmo_top) = min(RELOC(rmo_top), RELOC(prom_memory_limit));
+ }
+ }
+
+ /*
* Setup our top alloc point, that is top of RMO or top of
* segment 0 when running non-LPAR.
* Some RS64 machines have buggy firmware where claims up at
@@ -1041,6 +1136,7 @@ static void __init prom_init_mem(void)
RELOC(alloc_top_high) = RELOC(ram_top);
prom_printf("memory layout at init:\n");
+ prom_printf(" memory_limit : %x (16 MB aligned)\n", RELOC(prom_memory_limit));
prom_printf(" alloc_bottom : %x\n", RELOC(alloc_bottom));
prom_printf(" alloc_top : %x\n", RELOC(alloc_top));
prom_printf(" alloc_top_hi : %x\n", RELOC(alloc_top_high));
@@ -2399,6 +2495,10 @@ unsigned long __init prom_init(unsigned long r3, unsigned long r4,
/*
* Fill in some infos for use by the kernel later on
*/
+ if (RELOC(prom_memory_limit))
+ prom_setprop(_prom->chosen, "/chosen", "linux,memory-limit",
+ &RELOC(prom_memory_limit),
+ sizeof(prom_memory_limit));
#ifdef CONFIG_PPC64
if (RELOC(prom_iommu_off))
prom_setprop(_prom->chosen, "/chosen", "linux,iommu-off",
--
1.5.4.5
^ permalink raw reply related
* Re: [PATCH 2/2 v4] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Grant Likely @ 2009-07-17 18:31 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, netdev
In-Reply-To: <20090717175138.97CB2832E416@gemini.denx.de>
On Fri, Jul 17, 2009 at 11:51 AM, Wolfgang Denk<wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa40907170745h6c5fae6bia0cff0926c93393c@mail.gmail.com> =
you wrote:
>>
>> > =A0drivers/net/fec_mpc52xx.c =A0 =A0 | =A0 25 ++++++++++++++++++++++--=
-
>> > =A0drivers/net/fec_mpc52xx_phy.c | =A0 23 ++++++++++++++++++++---
>>
>> Blech. =A0now this block of duplicated code I don't like. =A0This is all
>> one device, so surely the mdio speed can be calculated once and used
>> for both drivers.... let me think about this for a bit. =A0'course this
>> problem is all rolled up in the nastiness of having two drivers
>> working on the same device. =A0I suspect is was a mistake to split up
>> all the powerpc ethernet drivers into separate of_platform drivers.
>
> If you like, I can re-introduce the mpc5xxx_get_mii_speed() I unrolled
> upon your request (with or without re-using it for the MPC512x case).
No, there's a deeper issues here. I'm bothered that the mac driver is
impacting the mdio driver. I'd like to find a way for this whole
thing to be handled cleaner, and not have two different drivers
calculate it.
g.
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, =A0 =A0 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: wd@denx.de
> What is mind? =A0No matter. =A0What is matter? =A0Never mind.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0-- Thomas Hewitt Key, 1799-1875
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: kernel2.6.30 can not boot on my mpc8260 board using u-boot2009.06
From: Scott Wood @ 2009-07-17 18:15 UTC (permalink / raw)
To: jerry_dw; +Cc: linuxppc-dev
In-Reply-To: <6174944.80871247795632146.JavaMail.coremail@bj126app32.126.com>
On Fri, Jul 17, 2009 at 09:53:52AM +0800, jerry_dw wrote:
> Updating property 'current-speed' = 00 00 25 80
> Updating property 'clock-frequency' = 01 79 a7 b0
> Updating property 'bus-frequency' = 03 ef 14 80
> Updating property 'timebase-frequency' = 00 00 00 00
That timebase-frequency doesn't look right...
> BDI2000 console:
> MPC8260|:=>halt
> Target CPU : MPC82xx (G2H4)
> Target state : debug mode
> Debug entry cause : COP halt
> Current PC : 0xc000c5f0
> Current CR : 0x42022088
> Current MSR : 0x00001032
> Current LR : 0xc001cfa8
>
> 0xc000c5f0: in hardwareinterrupt vector table.
Which vector (that address looks a little high to be in the exception
vectors)? Is there anything in the log buffer?
-Scott
^ permalink raw reply
* Re: [PATCH 2/2 v4] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Wolfgang Denk @ 2009-07-17 17:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, netdev
In-Reply-To: <fa686aa40907170745h6c5fae6bia0cff0926c93393c@mail.gmail.com>
Dear Grant Likely,
In message <fa686aa40907170745h6c5fae6bia0cff0926c93393c@mail.gmail.com> you wrote:
>
> > drivers/net/fec_mpc52xx.c | 25 ++++++++++++++++++++++---
> > drivers/net/fec_mpc52xx_phy.c | 23 ++++++++++++++++++++---
>
> Blech. now this block of duplicated code I don't like. This is all
> one device, so surely the mdio speed can be calculated once and used
> for both drivers.... let me think about this for a bit. 'course this
> problem is all rolled up in the nastiness of having two drivers
> working on the same device. I suspect is was a mistake to split up
> all the powerpc ethernet drivers into separate of_platform drivers.
If you like, I can re-introduce the mpc5xxx_get_mii_speed() I unrolled
upon your request (with or without re-using it for the MPC512x case).
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: wd@denx.de
What is mind? No matter. What is matter? Never mind.
-- Thomas Hewitt Key, 1799-1875
^ permalink raw reply
* Re: [PATCH 1/2 v5] fs_enet/mii-fec.c: fix MII speed calculation
From: David Miller @ 2009-07-17 16:48 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, netdev, wd
In-Reply-To: <fa686aa40907170741n121d3e4cqdfddaf4d23d4d1fc@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Fri, 17 Jul 2009 08:41:08 -0600
> On Fri, Jul 17, 2009 at 6:27 AM, Wolfgang Denk<wd@denx.de> 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 <wd@denx.de>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> Cc: <netdev@vger.kernel.org>
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/2 v5] fs_enet/mii-fec.c: fix MII speed calculation
From: David Miller @ 2009-07-17 16:21 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, netdev, wd
In-Reply-To: <fa686aa40907170741n121d3e4cqdfddaf4d23d4d1fc@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Fri, 17 Jul 2009 08:41:08 -0600
> David, this isn't a critical bug fix or a regression, so I think it
> should be merged for -next.
Ok.
^ permalink raw reply
* Re: [PATCH] powerpc/cell: strncpy does not null terminate string
From: Arnd Bergmann @ 2009-07-17 15:56 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton, cbe-oss-dev
In-Reply-To: <4A608A69.4060204@gmail.com>
On Friday 17 July 2009, Roel Kluin wrote:
>
> static int __init celleb_machine_type_hack(char *ptr)
> {
> - strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> + strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
> return 0;
This still is pointless as long as you keep the explicit null-termination
in the next line, the patch still doesn't change anything significant.
The file is maintained by Ishizaki Kou, if he would prefer to take a
patch replacing the two lines with one, that's fine with me, otherwise
I just wouldn't bother. You still only gain a few bytes of inittext, but
that is discarded at boot time.
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc/cell: strncpy does not null terminate string
From: roel kluin @ 2009-07-17 15:19 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Andrew Morton, linuxppc-dev, cbe-oss-dev
In-Reply-To: <200907171705.18578.arnd@arndb.de>
>> With `sizeof(string) - 1` strncpy() will null terminate the string.
>
> No, it won't.
> See the line after the strncpy. This is still required for proper zero-termination.
You're right, sorry for the noise.
Roel
^ permalink raw reply
* Re: [PATCH] powerpc/cell: strncpy does not null terminate string
From: Arnd Bergmann @ 2009-07-17 15:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, Andrew Morton, Roel Kluin, cbe-oss-dev
In-Reply-To: <4A607185.6020302@gmail.com>
On Friday 17 July 2009, Roel Kluin wrote:
> With `sizeof(string) - 1` strncpy() will null terminate the string.
No, it won't. See the 'Warning' part of the strncpy man page.
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> To test this:
>
> #include <stdio.h>
> #include <string.h>
>
> char a[10];
> char b[10];
>
> int main()
> {
> const char* str = "0123456789012";
> strncpy(a, str, sizeof(a));
> strncpy(b, str, sizeof(b) - 1);
> printf("String a was %s, b was %s\n", a, b);
>
> return 0;
> }
>
> Output:
> String a was 0123456789012345678, b was 012345678
This is an invalid test case, it relies on b being zero-filled by the
compiler, which is not true for programs in general.
> diff --git a/arch/powerpc/platforms/cell/celleb_setup.c b/arch/powerpc/platforms/cell/celleb_setup.c
> index 07c234f..cfdbadb 100644
> --- a/arch/powerpc/platforms/cell/celleb_setup.c
> +++ b/arch/powerpc/platforms/cell/celleb_setup.c
> @@ -80,7 +80,7 @@ static void celleb_show_cpuinfo(struct seq_file *m)
>
> static int __init celleb_machine_type_hack(char *ptr)
> {
> - strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> + strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type) - 1);
> celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
> return 0;
> }
See the line after the strncpy. This is still required for proper zero-termination.
Your patch tries to address a problem that doesn't exist, and does not have any
effect at all after celleb_machine_type_hack has completed.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/2 v4] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Grant Likely @ 2009-07-17 14:45 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, netdev
In-Reply-To: <1247835545-18650-1-git-send-email-wd@denx.de>
On Fri, Jul 17, 2009 at 6:59 AM, Wolfgang Denk<wd@denx.de> 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 <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: <netdev@vger.kernel.org>
> ---
> v3: - use maximum divider in case MPC512x IPS clock is unknown
> v4: - use the same code in the probe-function, too
>
> =A0drivers/net/fec_mpc52xx.c =A0 =A0 | =A0 25 ++++++++++++++++++++++---
> =A0drivers/net/fec_mpc52xx_phy.c | =A0 23 ++++++++++++++++++++---
Blech. now this block of duplicated code I don't like. This is all
one device, so surely the mdio speed can be calculated once and used
for both drivers.... let me think about this for a bit. 'course this
problem is all rolled up in the nastiness of having two drivers
working on the same device. I suspect is was a mistake to split up
all the powerpc ethernet drivers into separate of_platform drivers.
g.
> =A02 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index cc78633..eed8d2b 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 *de=
v)
> =A0 =A0 =A0 =A0/* set phy speed.
> =A0 =A0 =A0 =A0 * this can't be done in phy driver, since it needs to be =
called
> =A0 =A0 =A0 =A0 * before fec stuff (even on resume) */
> - =A0 =A0 =A0 out_be32(&fec->mii_speed, priv->mdio_speed);
> + =A0 =A0 =A0 clrsetbits_be32(&fec->mii_speed, 0x7E, priv->mdio_speed);
> =A0}
>
> =A0/**
> @@ -863,7 +863,7 @@ mpc52xx_fec_probe(struct of_device *op, const struct =
of_device_id *match)
> =A0 =A0 =A0 =A0struct mpc52xx_fec_priv *priv =3D NULL;
> =A0 =A0 =A0 =A0struct resource mem;
> =A0 =A0 =A0 =A0const u32 *prop;
> - =A0 =A0 =A0 int prop_size;
> + =A0 =A0 =A0 int prop_size, clock, speed;
>
> =A0 =A0 =A0 =A0phys_addr_t rx_fifo;
> =A0 =A0 =A0 =A0phys_addr_t tx_fifo;
> @@ -948,7 +948,26 @@ mpc52xx_fec_probe(struct of_device *op, const struct=
of_device_id *match)
> =A0 =A0 =A0 =A0/* Start with safe defaults for link connection */
> =A0 =A0 =A0 =A0priv->speed =3D 100;
> =A0 =A0 =A0 =A0priv->duplex =3D DUPLEX_HALF;
> - =A0 =A0 =A0 priv->mdio_speed =3D ((mpc5xxx_get_bus_frequency(op->node) =
>> 20) / 5) << 1;
> +
> + =A0 =A0 =A0 /* MII speed */
> + =A0 =A0 =A0 clock =3D mpc5xxx_get_bus_frequency(op->node);
> + =A0 =A0 =A0 if (!clock) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Use maximum divider if clock is unknown =
*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&op->dev, "could not determine IPB =
clock\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock =3D 0x3F * 5000000;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0* Scale for a MII clock <=3D 2.5 MHz
> + =A0 =A0 =A0 =A0* Note that only 6 bits (25:30) are available for MII sp=
eed.
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 speed =3D (clock + 4999999) / 5000000;
> + =A0 =A0 =A0 if (speed > 0x3F) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 speed =3D 0x3F;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&op->dev, "MII clock (%d Hz) exceed=
s max (2.5 MHz)\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock / speed);
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 priv->mdio_speed =3D speed << 1;
>
> =A0 =A0 =A0 =A0/* The current speed preconfigures the speed of the MII li=
nk */
> =A0 =A0 =A0 =A0prop =3D of_get_property(op->node, "current-speed", &prop_=
size);
> diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.=
c
> index 31e6d62..d3537e1 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,
> =A0 =A0 =A0 =A0struct mpc52xx_fec_mdio_priv *priv;
> =A0 =A0 =A0 =A0struct resource res =3D {};
> =A0 =A0 =A0 =A0int err;
> - =A0 =A0 =A0 int i;
> + =A0 =A0 =A0 int i, clock, speed;
>
> =A0 =A0 =A0 =A0bus =3D mdiobus_alloc();
> =A0 =A0 =A0 =A0if (bus =3D=3D NULL)
> @@ -105,8 +105,25 @@ static int mpc52xx_fec_mdio_probe(struct of_device *=
of,
> =A0 =A0 =A0 =A0dev_set_drvdata(dev, bus);
>
> =A0 =A0 =A0 =A0/* set MII speed */
> - =A0 =A0 =A0 out_be32(&priv->regs->mii_speed,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((mpc5xxx_get_bus_frequency(of->node) >> 20=
) / 5) << 1);
> + =A0 =A0 =A0 clock =3D mpc5xxx_get_bus_frequency(of->node);
> + =A0 =A0 =A0 if (!clock) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Use maximum divider if clock is unknown =
*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&of->dev, "could not determine IPB =
clock\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock =3D 0x3F * 5000000;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0* Scale for a MII clock <=3D 2.5 MHz
> + =A0 =A0 =A0 =A0* Note that only 6 bits (25:30) are available for MII sp=
eed.
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 speed =3D (clock + 4999999) / 5000000;
> + =A0 =A0 =A0 if (speed > 0x3F) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 speed =3D 0x3F;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&of->dev, "MII clock (%d Hz) exceed=
s max (2.5 MHz)\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock / speed);
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 clrsetbits_be32(&priv->regs->mii_speed, 0x7E, speed << 1);
>
> =A0 =A0 =A0 =A0err =3D of_mdiobus_register(bus, np);
> =A0 =A0 =A0 =A0if (err)
> --
> 1.6.0.6
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2 v5] fs_enet/mii-fec.c: fix MII speed calculation
From: Grant Likely @ 2009-07-17 14:41 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, David Miller, netdev
In-Reply-To: <1247833628-15952-1-git-send-email-wd@denx.de>
On Fri, Jul 17, 2009 at 6:27 AM, Wolfgang Denk<wd@denx.de> 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 <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: <netdev@vger.kernel.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
David, this isn't a critical bug fix or a regression, so I think it
should be merged for -next.
g.
> ---
> v5: - fix divider so we really use 2.5 MHz (instead of 1.25)
> =A0 =A0- use maximum divider in case MPC512x IPS clock is unknown
>
> =A0drivers/net/fs_enet/mii-fec.c | =A0 37 +++++++++++++++++++++++++++++++=
++----
> =A01 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.=
c
> index 75a0999..5176986 100644
> --- a/drivers/net/fs_enet/mii-fec.c
> +++ b/drivers/net/fs_enet/mii-fec.c
> @@ -36,6 +36,7 @@
> =A0#include <asm/pgtable.h>
> =A0#include <asm/irq.h>
> =A0#include <asm/uaccess.h>
> +#include <asm/mpc5xxx.h>
>
> =A0#include "fs_enet.h"
> =A0#include "fec.h"
> @@ -103,11 +104,11 @@ static int fs_enet_fec_mii_reset(struct mii_bus *bu=
s)
> =A0static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 const struct of_device_id *match)
> =A0{
> - =A0 =A0 =A0 struct device_node *np =3D NULL;
> =A0 =A0 =A0 =A0struct resource res;
> =A0 =A0 =A0 =A0struct mii_bus *new_bus;
> =A0 =A0 =A0 =A0struct fec_info *fec;
> - =A0 =A0 =A0 int ret =3D -ENOMEM, i;
> + =A0 =A0 =A0 int (*get_bus_freq)(struct device_node *) =3D match->data;
> + =A0 =A0 =A0 int ret =3D -ENOMEM, clock, speed;
>
> =A0 =A0 =A0 =A0new_bus =3D mdiobus_alloc();
> =A0 =A0 =A0 =A0if (!new_bus)
> @@ -133,13 +134,35 @@ static int __devinit fs_enet_mdio_probe(struct of_d=
evice *ofdev,
> =A0 =A0 =A0 =A0if (!fec->fecp)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_fec;
>
> - =A0 =A0 =A0 fec->mii_speed =3D ((ppc_proc_freq + 4999999) / 5000000) <<=
1;
> + =A0 =A0 =A0 if (get_bus_freq) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock =3D get_bus_freq(ofdev->node);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!clock) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Use maximum divider if c=
lock is unknown */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_warn(&ofdev->dev, "coul=
d not determine IPS clock\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock =3D 0x3F * 5000000;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 } else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock =3D ppc_proc_freq;
> +
> + =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0* Scale for a MII clock <=3D 2.5 MHz
> + =A0 =A0 =A0 =A0* Note that only 6 bits (25:30) are available for MII sp=
eed.
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 speed =3D (clock + 4999999) / 5000000;
> + =A0 =A0 =A0 if (speed > 0x3F) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 speed =3D 0x3F;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&ofdev->dev,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "MII clock (%d Hz) exceeds =
max (2.5 MHz)\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock / speed);
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 fec->mii_speed =3D speed << 1;
>
> =A0 =A0 =A0 =A0setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
> =A0 =A0 =A0 =A0setbits32(&fec->fecp->fec_ecntrl, FEC_ECNTRL_PINMUX |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0FEC_ECNTRL_ETHER_EN);
> =A0 =A0 =A0 =A0out_be32(&fec->fecp->fec_ievent, FEC_ENET_MII);
> - =A0 =A0 =A0 out_be32(&fec->fecp->fec_mii_speed, fec->mii_speed);
> + =A0 =A0 =A0 clrsetbits_be32(&fec->fecp->fec_mii_speed, 0x7E, fec->mii_s=
peed);
>
> =A0 =A0 =A0 =A0new_bus->phy_mask =3D ~0;
> =A0 =A0 =A0 =A0new_bus->irq =3D kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_K=
ERNEL);
> @@ -188,6 +211,12 @@ static struct of_device_id fs_enet_mdio_fec_match[] =
=3D {
> =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.compatible =3D "fsl,pq1-fec-mdio",
> =A0 =A0 =A0 =A0},
> +#if defined(CONFIG_PPC_MPC512x)
> + =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .compatible =3D "fsl,mpc5121-fec-mdio",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .data =3D mpc5xxx_get_bus_frequency,
> + =A0 =A0 =A0 },
> +#endif
> =A0 =A0 =A0 =A0{},
> =A0};
>
> --
> 1.6.0.6
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/cell: strncpy does not null terminate string
From: Roel Kluin @ 2009-07-17 14:27 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, Andrew Morton, cbe-oss-dev
In-Reply-To: <4A607185.6020302@gmail.com>
strlcpy() will always null terminate the string.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Please use this one instead
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c b/arch/powerpc/platforms/cell/celleb_setup.c
index 07c234f..1896cd8 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -80,7 +80,7 @@ static void celleb_show_cpuinfo(struct seq_file *m)
static int __init celleb_machine_type_hack(char *ptr)
{
- strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
+ strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
return 0;
}
^ permalink raw reply related
* [PATCH 2/2 v4] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Wolfgang Denk @ 2009-07-17 12:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, Wolfgang Denk
In-Reply-To: <1247833628-15952-2-git-send-email-wd@denx.de>
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 <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: <netdev@vger.kernel.org>
---
v3: - use maximum divider in case MPC512x IPS clock is unknown
v4: - use the same code in the probe-function, too
drivers/net/fec_mpc52xx.c | 25 ++++++++++++++++++++++---
drivers/net/fec_mpc52xx_phy.c | 23 ++++++++++++++++++++---
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cc78633..eed8d2b 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);
}
/**
@@ -863,7 +863,7 @@ mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
struct mpc52xx_fec_priv *priv = NULL;
struct resource mem;
const u32 *prop;
- int prop_size;
+ int prop_size, clock, speed;
phys_addr_t rx_fifo;
phys_addr_t tx_fifo;
@@ -948,7 +948,26 @@ mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
/* Start with safe defaults for link connection */
priv->speed = 100;
priv->duplex = DUPLEX_HALF;
- priv->mdio_speed = ((mpc5xxx_get_bus_frequency(op->node) >> 20) / 5) << 1;
+
+ /* MII speed */
+ clock = mpc5xxx_get_bus_frequency(op->node);
+ if (!clock) {
+ /* Use maximum divider if clock is unknown */
+ dev_err(&op->dev, "could not determine IPB clock\n");
+ clock = 0x3F * 5000000;
+ }
+
+ /*
+ * Scale for a MII clock <= 2.5 MHz
+ * Note that only 6 bits (25:30) are available for MII speed.
+ */
+ speed = (clock + 4999999) / 5000000;
+ if (speed > 0x3F) {
+ speed = 0x3F;
+ dev_err(&op->dev, "MII clock (%d Hz) exceeds max (2.5 MHz)\n",
+ clock / speed);
+ }
+ priv->mdio_speed = speed << 1;
/* The current speed preconfigures the speed of the MII link */
prop = of_get_property(op->node, "current-speed", &prop_size);
diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c
index 31e6d62..d3537e1 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,25 @@ 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) {
+ /* Use maximum divider if clock is unknown */
+ dev_err(&of->dev, "could not determine IPB clock\n");
+ clock = 0x3F * 5000000;
+ }
+
+ /*
+ * Scale for a MII clock <= 2.5 MHz
+ * Note that only 6 bits (25:30) are available for MII speed.
+ */
+ speed = (clock + 4999999) / 5000000;
+ 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
^ permalink raw reply related
* [PATCH] powerpc/cell: strncpy does not null terminate string
From: Roel Kluin @ 2009-07-17 12:41 UTC (permalink / raw)
To: arnd, linuxppc-dev, cbe-oss-dev, Andrew Morton
With `sizeof(string) - 1` strncpy() will null terminate the string.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
To test this:
#include <stdio.h>
#include <string.h>
char a[10];
char b[10];
int main()
{
const char* str = "0123456789012";
strncpy(a, str, sizeof(a));
strncpy(b, str, sizeof(b) - 1);
printf("String a was %s, b was %s\n", a, b);
return 0;
}
Output:
String a was 0123456789012345678, b was 012345678
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c b/arch/powerpc/platforms/cell/celleb_setup.c
index 07c234f..cfdbadb 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -80,7 +80,7 @@ static void celleb_show_cpuinfo(struct seq_file *m)
static int __init celleb_machine_type_hack(char *ptr)
{
- strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
+ strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type) - 1);
celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
return 0;
}
^ permalink raw reply related
* [PATCH] mtd/maps: add mtd-ram support to physmap_of
From: Wolfram Sang @ 2009-07-17 12:39 UTC (permalink / raw)
To: linux-mtd
Cc: devicetree-discuss, Vitaly Wool, Artem Bityutskiy,
Albrecht Dreß, linuxppc-dev, Ken MacLeod, David Woodhouse
Use physmap_of to access RAMs as mtd and add documenation for it. This approach
is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
device tree anyhow, extending physmap_of seems to be the cleanest approach.
Tested with a phyCORE-MPC5121e.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Vitaly Wool <vwool@ru.mvista.com>
Cc: Artem Bityutskiy <dedekind@infradead.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ken MacLeod <ken@bitsko.slc.ut.us>
Cc: Albrecht Dreß <albrecht.dress@arcor.de>
---
Documentation/powerpc/dts-bindings/mtd-physmap.txt | 42 ++++++++++++-------
drivers/mtd/maps/physmap_of.c | 4 ++
2 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
index 667c9bd..80152cb 100644
--- a/Documentation/powerpc/dts-bindings/mtd-physmap.txt
+++ b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
@@ -1,18 +1,19 @@
-CFI or JEDEC memory-mapped NOR flash
+CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...)
Flash chips (Memory Technology Devices) are often used for solid state
file systems on embedded devices.
- - compatible : should contain the specific model of flash chip(s)
- used, if known, followed by either "cfi-flash" or "jedec-flash"
- - reg : Address range(s) of the flash chip(s)
+ - compatible : should contain the specific model of mtd chip(s)
+ used, if known, followed by either "cfi-flash", "jedec-flash"
+ or "mtd-ram".
+ - reg : Address range(s) of the mtd chip(s)
It's possible to (optionally) define multiple "reg" tuples so that
- non-identical NOR chips can be described in one flash node.
- - bank-width : Width (in bytes) of the flash bank. Equal to the
+ non-identical chips can be described in one node.
+ - bank-width : Width (in bytes) of the bank. Equal to the
device width times the number of interleaved chips.
- - device-width : (optional) Width of a single flash chip. If
+ - device-width : (optional) Width of a single mtd chip. If
omitted, assumed to be equal to 'bank-width'.
- - #address-cells, #size-cells : Must be present if the flash has
+ - #address-cells, #size-cells : Must be present if the device has
sub-nodes representing partitions (see below). In this case
both #address-cells and #size-cells must be equal to 1.
@@ -22,24 +23,24 @@ are defined:
- vendor-id : Contains the flash chip's vendor id (1 byte).
- device-id : Contains the flash chip's device id (1 byte).
-In addition to the information on the flash bank itself, the
+In addition to the information on the mtd bank itself, the
device tree may optionally contain additional information
-describing partitions of the flash address space. This can be
+describing partitions of the address space. This can be
used on platforms which have strong conventions about which
-portions of the flash are used for what purposes, but which don't
+portions of a flash are used for what purposes, but which don't
use an on-flash partition table such as RedBoot.
-Each partition is represented as a sub-node of the flash device.
+Each partition is represented as a sub-node of the mtd device.
Each node's name represents the name of the corresponding
-partition of the flash device.
+partition of the mtd device.
Flash partitions
- - reg : The partition's offset and size within the flash bank.
- - label : (optional) The label / name for this flash partition.
+ - reg : The partition's offset and size within the mtd bank.
+ - label : (optional) The label / name for this partition.
If omitted, the label is taken from the node name (excluding
the unit address).
- read-only : (optional) This parameter, if present, is a hint to
- Linux that this flash partition should only be mounted
+ Linux that this partition should only be mounted
read-only. This is usually used for flash partitions
containing early-boot firmware images or data which should not
be clobbered.
@@ -78,3 +79,12 @@ Here an example with multiple "reg" tuples:
reg = <0 0x04000000>;
};
};
+
+An example using SRAM:
+
+ sram@2,0 {
+ compatible = "samsung,k6f1616u6a", "mtd-ram";
+ reg = <2 0 0x00200000>;
+ bank-width = <2>;
+ };
+
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 39d357b..45eee20 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -360,6 +360,10 @@ static struct of_device_id of_flash_match[] = {
.data = (void *)"jedec_probe",
},
{
+ .compatible = "mtd-ram",
+ .data = (void *)"map_ram",
+ },
+ {
.type = "rom",
.compatible = "direct-mapped"
},
--
1.6.3.1
^ permalink raw reply related
* Re: [PATCH 2/2 v2] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Wolfgang Denk @ 2009-07-17 12:35 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, netdev
In-Reply-To: <20090717094725.GC3150@pengutronix.de>
Dear Wolfram Sang,
In message <20090717094725.GC3150@pengutronix.de> you wrote:
>
> In the probe-function when mdio_speed is set, there is still the old formula
> used. Wouldn't that be better in sync?
Good point. Next version of patch following soon.
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: wd@denx.de
Prof: So the American government went to IBM to come up with a
data encryption standard and they came up with ...
Student: EBCDIC!
^ permalink raw reply
* Re: [PATCH 1/2 v4] fs_enet/mii-fec.c: fix MII speed calculation
From: Wolfgang Denk @ 2009-07-17 12:32 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, netdev
In-Reply-To: <20090717093307.GB3150@pengutronix.de>
Dear Wolfram Sang,
In message <20090717093307.GB3150@pengutronix.de> you wrote:
>
...
> > @@ -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
>
> Grepping through 'drivers/*' I see that #ifdefing compatible-entries is highly
> uncommon (just 3 hits). I think a guideline would be useful. Most people like
> to avoid #ifdefs at any cost, while I personally think it doesn't spoil
> readability too much here. Other opinions?
An older version of the patch tried to "hide" the ifdef in a 512x
specific header, so at least common code would remain clean, but I
agree with Grant that this current version looks cleaner globally.
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: wd@denx.de
"You can have my Unix system when you pry it from my cold, dead
fingers." - Cal Keegan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox