Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
On Tue, Jul 21, 2009 at 10:02:26AM +1000, Benjamin Herrenschmidt wrote: On Mon, 2009-07-20 at 12:38 +0200, Nick Piggin wrote: On Mon, Jul 20, 2009 at 08:00:41PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote: Maybe I don't understand your description correctly. The TLB contains PMDs, but you say the HW still logically performs another translation step using entries in the PMD pages? If I understand that correctly, then generic mm does not actually care and would logically fit better if those entries were linux ptes. They are :-) The pte invalidation routines give the virtual address, which you could use to invalidate the TLB. For PTEs, yes, but not for those PMD entries. IE. I need the virtual address when destroying PMDs so that I can invalidate those indirect pages. PTEs are already taken care of by existing mechanisms. Hmm, so even after having invalidated all the pte translations then you still need to invalidate the empty indirect page? (or maybe you don't even invalidate the ptes if they're not cached in a TLB). The PTEs are cached in the TLB (ie, they turn into normal TLB entries). We need to invalidate the indirect entries when the PMD value change (ie, when the PTE page is freed) or the TLB would potentially continue loading PTEs from a stale PTE page :-) Hence my patch adding the virtual address to pte_free_tlb() which is the freeing of a PTE page. I'm adding it to the pmd/pud variants too for consistency and because I believe there's no cost. Yes I think we're on the same page now. So as I said, the patch is quite OK with me. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
DMA Engine on MPC8270
Hi, Can Freescale DMA engine driver can be used on MPC2870 ? If not, what driver should I use instead ? The goal to to speed up transfers to some storage device (M-Systems DoC H3). Thanks a lot. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/cell: strncpy does not null terminate string
Arnd-san, Roel-san,
Thanks for pointing us to the redundant cord portion.
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.
We prefer to take the patch which is replacing the two lines with one.
- 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;
Thanks,
Ken Kawakami
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: DMA Engine on MPC8270
Hi, Can Freescale DMA engine driver can be used on MPC2870 ? No, the driver is only used on 83xx and 85xx cpus. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Best hardware platform for native compiling...
Hi all, This might sound as a stupid question (and maybe sligtly off-topic), but I have not found an (easy) answer and I suspect many on this list will have a good suggestion to make: We are developing (and maintaining) different embedded linux systems based on different PowerPC processors. From small MPC852T with little RAM and Flash, up to 400MHz MPC5200- and MPC5121e based systems that resemble more a PC or netbook than an embedded system in terms of RAM and storage. For smaller systems we use a customized ELDK-based OS and cross-compile almost everything on a PC. For bigger systems we often run a debian-derived OS like Ubuntu, and many pieces are compiled natively on the target... just because it is easy and quick to do, and cross-compiling certain packages can be a real pain. But, a 400 MHz e300 core is not really fast for compiling, so I have been considering buying some sort of PowerPC-based system with a faster processor, just as a build-server (a G5 would do wonders I guess). It seems like the only real option is one of the smaller IBM Power servers, but that seems overkill to me. We also don't feel like buying some old second-hand Apple gear. Is there any other available and affordable platform that can be used to run linux and compile software natively for 32-bit PowerPC? Any suggestion is welcome! Best regards, P.S.: I am writing this while running dpkg-buildpackage -rfakeroot on the package xserver-xfbdev from ubuntu 9.04 on a MPC5121e it will take 40 minutes ;-) -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause
kernel crashes when using the mdio-ofgpio driver.
The following patch replicates similar changes made to the fs_enet mii-bitbang
drivers.
---
This version attempts to address Grant's comments below:
Grant Likely wrote:
You should refactor mdio_gpio_bus_init() to not call
mdiobus_register() at all, and instead just return a pointer to the
unregistered new_bus. Then mdio_gpio_probe() and mdio_ofgpio_probe()
can call the correct register variant directly. Fewer ugly #ifdefs
this way. It also eliminates the need to cast the void* pointer.
drivers/net/phy/mdio-gpio.c | 77 ---
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include linux/of_gpio.h
+#include linux/of_mdio.h
#include linux/of_platform.h
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data *pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
new_bus-name = GPIO Bitbanged MDIO,
- ret = -ENODEV;
-
new_bus-phy_mask = pdata-phy_mask;
new_bus-irq = pdata-irqs;
new_bus-parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang-mdio);
out_free_mdc:
gpio_free(bitbang-mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus-priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang-mdc);
gpio_free(bitbang-mdio);
+ gpio_free(bitbang-mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev-dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(pdev-dev, pdata, pdev-id);
+ new_bus = mdio_gpio_bus_init(pdev-dev, pdata, pdev-id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(pdev-dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, reg, len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata-phy_mask = ~(1 id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata-irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct mdio_gpio_platform_data *pdata;
+ struct mii_bus *new_bus;
int ret;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
@@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct of_device
*ofdev,
ret = of_get_gpio(ofdev-node, 1);
if (ret 0)
-goto out_free;
+ goto out_free;
pdata-mdio = ret;
- while ((np = of_get_next_child(ofdev-node, np)))
- if (!strcmp(np-type, ethernet-phy))
-
[PATCH] powerpc/cell: replace strncpy by strlcpy
Replace strncpy() and explicit null-termination by strlcpy()
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Arnd-san, Ken-san,
Thanks for reviewing,
We prefer to take the patch which is replacing the two lines with one.
Doozo.
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c
b/arch/powerpc/platforms/cell/celleb_setup.c
index 07c234f..e538455 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -80,8 +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));
- celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
+ strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
msgctl10 fails on Powerpc Linux-2.6.29.6
The LTP test case *msgctl10.c* fails on linux-2.6.29.6 for PowerPC architecture (ppc440) msgctl101 B[ cut here ] kernel BUG at arch/powerpc/kernel/traps.c:904! Oops: Exception in kernel mode, sig: 5 [#9] PREEMPT LTT NESTING LEVEL : 0 Virtex440 Modules linked in: NIP: c038178c LR: c0381640 CTR: c02650bc REGS: cafbbe70 TRAP: 0700 Tainted: G D (2.6.29.6) MSR: 00029000 EE,ME,CE CR: 48004224 XER: 2008 TASK = cafa17f0[6435] 'msgctl10' THREAD: cafba000 GPR00: 0001 cafbbf20 cafa17f0 ffda 0800 0001 0037 GPR08: cafa17f0 c04a 00021002 c0381594 28004222 1001f4bc bf93d950 100b GPR16: 0007 bf93d95c 100012a0 10005b84 0067 100174e8 10017500 100174f8 GPR24: 0001 103eaa50 0800 cafbbf50 NIP [c038178c] program_check_exception+0x1f8/0x5f4 LR [c0381640] program_check_exception+0xac/0x5f4 Call Trace: [cafbbf20] [c0381640] program_check_exception+0xac/0x5f4 (unreliable) [cafbbf40] [c000e78c] ret_from_except_full+0x0/0x4c Instruction dump: 7d808120 4bc8ac20 2f830001 41beff38 2f83fff2 419e0024 77c00804 4182004c 3d20c04a 8809207c 2f80 419e0080 0fe0 4800 80010024 3ca3 ---[ end trace fd0893c7d8cee1bd ]--- ROK : Unexpected signal 11 received. msgctl101 FAIL : in read # = 21245,key = 533a msgctl100 WARN : Verify error in child 13, *buf = f1, val = 6d, size = 3 msgctl101 BROK : Unexpected signal 11 received. msgctl101 BROK : Msgsnd error in child 14, key = d344 errno = 43 msgctl100 WARN : tst_rmdir(): rmobj(/tmp/msgNjyTEb) failed: lstat(/tmp/msgNjyTEb) failed; errno=2: No such file or directory msgctl100 WARN : tst_rmdir(): rmobj(/tmp/msgNjyTEb) failed: lstat(/tmp/msgNjyTEb) failed; errno=2: No such file or directory msgctl101 FAIL : in read # = 54260,key = d46d msgctl101 B[ cut here ] Any clue ? Thanks in Advance ! -- Srikanth Krishnakar ** ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Best hardware platform for native compiling...
On Tuesday 21 July 2009 11:52:51 you wrote: On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote: For bigger systems we often run a debian-derived OS like Ubuntu, and many pieces are compiled natively on the target... just because it is easy and quick to do, and cross-compiling certain packages can be a real pain. But, a 400 MHz e300 core is not really fast for compiling, so I have been considering buying some sort of PowerPC-based system with a faster processor, just as a build-server (a G5 would do wonders I guess). It seems like the only real option is one of the smaller IBM Power servers, but that seems overkill to me. We also don't feel like buying some old second-hand Apple gear. Is there any other available and affordable platform that can be used to run linux and compile software natively for 32-bit PowerPC? Have a look at the YDL PowerStation: http://us.fixstars.com/products/powerstation/ It is more or less a quad G5. This looks great! Thanks a lot for the tip. I still have to figure out how to get one of these delivered to Europe, but that shouldn't be such a big deal... Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Best hardware platform for native compiling...
On Tue, Jul 21, 2009 at 12:31:36PM +0200, David Jander wrote: On Tuesday 21 July 2009 11:52:51 you wrote: On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote: For bigger systems we often run a debian-derived OS like Ubuntu, and many pieces are compiled natively on the target... just because it is easy and quick to do, and cross-compiling certain packages can be a real pain. But, a 400 MHz e300 core is not really fast for compiling, so I have been considering buying some sort of PowerPC-based system with a faster processor, just as a build-server (a G5 would do wonders I guess). It seems like the only real option is one of the smaller IBM Power servers, but that seems overkill to me. We also don't feel like buying some old second-hand Apple gear. Is there any other available and affordable platform that can be used to run linux and compile software natively for 32-bit PowerPC? Have a look at the YDL PowerStation: http://us.fixstars.com/products/powerstation/ It is more or less a quad G5. This looks great! Thanks a lot for the tip. I still have to figure out how to get one of these delivered to Europe, but that shouldn't be such a big deal... Well, I got one recently here in Spain. Shipping charges are fairly large (it's not exactly a light and compact machine). But the current dollar exchange rate helps ;-) Now I have not yet found the way to install Debian on it (it refuses to boot Debian's CDROM), but I have not had time to investigate either. Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Best hardware platform for native compiling...
On Tue, 2009-07-21 at 14:00 +0200, Gabriel Paubert wrote: Well, I got one recently here in Spain. Shipping charges are fairly large (it's not exactly a light and compact machine). But the current dollar exchange rate helps ;-) Now I have not yet found the way to install Debian on it (it refuses to boot Debian's CDROM), but I have not had time to investigate either. It uses SLOF which should be capable of decent netbooting, so it should be possible to either netboot yaboot and have it load the kernel and initramfs, or maybe make a zImage with both included and netboot that. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Best hardware platform for native compiling...
On Tuesday 21 July 2009 14:00:07 you wrote: On Tue, Jul 21, 2009 at 12:31:36PM +0200, David Jander wrote: On Tuesday 21 July 2009 11:52:51 you wrote: On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote: For bigger systems we often run a debian-derived OS like Ubuntu, and many pieces are compiled natively on the target... just because it is easy and quick to do, and cross-compiling certain packages can be a real pain. But, a 400 MHz e300 core is not really fast for compiling, so I have been considering buying some sort of PowerPC-based system with a faster processor, just as a build-server (a G5 would do wonders I guess). It seems like the only real option is one of the smaller IBM Power servers, but that seems overkill to me. We also don't feel like buying some old second-hand Apple gear. Is there any other available and affordable platform that can be used to run linux and compile software natively for 32-bit PowerPC? Have a look at the YDL PowerStation: http://us.fixstars.com/products/powerstation/ It is more or less a quad G5. This looks great! Thanks a lot for the tip. I still have to figure out how to get one of these delivered to Europe, but that shouldn't be such a big deal... Well, I got one recently here in Spain. Shipping charges are fairly large (it's not exactly a light and compact machine). But the current dollar exchange rate helps ;-) Now I have not yet found the way to install Debian on it (it refuses to boot Debian's CDROM), but I have not had time to investigate either. If nothing else helps, try (manually) installing debootstrap from ubuntu sources and start from there with debootstrap jaunty /mnt/partition ;-) Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] PowerPC 440EPx: Sequoia bootwrapper
The system clock frequency on the Sequoia board is 33.00 MHz not
33.33 MHz; this causes the system time to drift more than 30 seconds
per hour.
diff -ruN a/arch/powerpc/boot/cuboot-sequoia.c
b/arch/powerpc/boot/cuboot-sequoia.c
--- a/arch/powerpc/boot/cuboot-sequoia.c2009-05-18
19:52:34.0 -0400
+++ b/arch/powerpc/boot/cuboot-sequoia.c2009-07-21
09:13:13.0 -0400
@@ -37,7 +37,7 @@
static void sequoia_fixups(void)
{
- unsigned long sysclk = ;
+ unsigned long sysclk = 3300;
ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
ibm4xx_fixup_ebc_ranges(/plb/opb/ebc);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx: Sequoia bootwrapper
On Tuesday 21 July 2009 15:33:20 Bob Burke wrote:
The system clock frequency on the Sequoia board is 33.00 MHz not
33.33 MHz; this causes the system time to drift more than 30 seconds
per hour.
diff -ruN a/arch/powerpc/boot/cuboot-sequoia.c
b/arch/powerpc/boot/cuboot-sequoia.c
--- a/arch/powerpc/boot/cuboot-sequoia.c2009-05-18
19:52:34.0 -0400
+++ b/arch/powerpc/boot/cuboot-sequoia.c2009-07-21
09:13:13.0 -0400
@@ -37,7 +37,7 @@
static void sequoia_fixups(void)
{
- unsigned long sysclk = ;
+ unsigned long sysclk = 3300;
ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
ibm4xx_fixup_ebc_ranges(/plb/opb/ebc);
Unfortunately it's not that easy. Earlier Sequoia board revisions are equipped
with an 33.333MHz oscillator. This can be detected via a CPLD register though.
Here the code from U-Boot (just as an example):
/* Detect Sequoia PLL input clock automatically via CPLD bit*/
#define CONFIG_SYS_BCSR_BASE0xc000
#define CONFIG_SYS_CLK_FREQ((in8(CONFIG_SYS_BCSR_BASE + 3) 0x80) ? \
: 3300)
But why are you using the boot wrapper? If your U-Boot isn't too old, you can
boot uImage directly (with dtb of course). No need for the wrapper.
Thanks,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] PowerPC 440EPx: Sequoia bootwrapper
On Tue, 21 Jul 2009 16:06:53 Stefan Roese wrote: Unfortunately it's not that easy. Earlier Sequoia board revisions are equipped with an 33.333MHz oscillator. This can be detected via a CPLD register though. Thanks, I didn't realize that. FYI our deployed platform is similar to Sequoia, but is a custom design. It has a 33 MHz system clock. But why are you using the boot wrapper? If your U-Boot isn't too old, you can boot uImage directly (with dtb of course). No need for the wrapper. Since we have deployed product, using a non OF kernel, we have made the decision not to upgrade U-Boot in the field. Thanks, Bob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx: Sequoia bootwrapper
On Tuesday 21 July 2009 17:56:40 Bob Burke wrote: On Tue, 21 Jul 2009 16:06:53 Stefan Roese wrote: Unfortunately it's not that easy. Earlier Sequoia board revisions are equipped with an 33.333MHz oscillator. This can be detected via a CPLD register though. Thanks, I didn't realize that. FYI our deployed platform is similar to Sequoia, but is a custom design. It has a 33 MHz system clock. OK. Then you should add a new target for your custom board (cuboot-namexyz.c). But why are you using the boot wrapper? If your U-Boot isn't too old, you can boot uImage directly (with dtb of course). No need for the wrapper. Since we have deployed product, using a non OF kernel, we have made the decision not to upgrade U-Boot in the field. OK, understood. Thanks, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
On Tue, Jul 21, 2009 at 3:50 AM, Mark Waremw...@elphinstone.net wrote:
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c)
cause kernel crashes when using the mdio-ofgpio driver.
The following patch replicates similar changes made to the fs_enet
mii-bitbang drivers.
This looks good to me. I've not tested it though (no hardware that
uses it). You should specify the testing you've done in the commit
log. Your signed-off-by: line is also missing.
Acked-by: Grant Likely grant.lik...@secretlab.ca
David, once the above issues are solved, this one needs to be merged for 2.6.31.
Cheers,
g.
---
This version attempts to address Grant's comments below:
Grant Likely wrote:
You should refactor mdio_gpio_bus_init() to not call
mdiobus_register() at all, and instead just return a pointer to the
unregistered new_bus. Then mdio_gpio_probe() and mdio_ofgpio_probe()
can call the correct register variant directly. Fewer ugly #ifdefs
this way. It also eliminates the need to cast the void* pointer.
drivers/net/phy/mdio-gpio.c | 77
---
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include linux/of_gpio.h
+#include linux/of_mdio.h
#include linux/of_platform.h
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data
*pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device
*dev,
new_bus-name = GPIO Bitbanged MDIO,
- ret = -ENODEV;
-
new_bus-phy_mask = pdata-phy_mask;
new_bus-irq = pdata-irqs;
new_bus-parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device
*dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang-mdio);
out_free_mdc:
gpio_free(bitbang-mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus-priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang-mdc);
gpio_free(bitbang-mdio);
+ gpio_free(bitbang-mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev-dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(pdev-dev, pdata, pdev-id);
+ new_bus = mdio_gpio_bus_init(pdev-dev, pdata, pdev-id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(pdev-dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, reg, len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata-phy_mask = ~(1 id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata-irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct
mpc5121 Power Managment errata.
I have a bit of a problem with arch/powerpc/platforms/512x/mpc512x_pm.c Since this one is not included in mainline (yet) I have attached it Now I have a number of questions and one mystery. 1: why relocate the code ?? is there a reason why the code must be located at address 0 http://www.bitshrine.org/gpp/linux-2.6.24.6-mpc5121-99-PM-alternate-external-int-vector.patch say that this is due to a bug in the PMC module with status bits. Could this not be worked around by avoiding modifying the exception handler and just taken care of by C code in ipic.c 2: does it work ??? I ask since it do self modifying code but no invalidation of the instruction cache. Mystery: If I fix the cache issue with the code and force store of data with dcbst and invalidate with icbi. I get a very unreliable resume function that often end up in machine check all over the place This machine check also happens on unmodified version but much much more seldom. I'm just now running some test on a system that only patch this in once and thus always run with this workaround without constantly modifying the exception handler . but I wont know if it makes a difference until tomorrow. I have inserted this code in the end of both mpc5121_copy_pmcclr mpc5121_reinstall_handler Is there some reason why this would not work ?? - /* dcbst |update memory sync |wait for update icbi |remove (invalidate) copy in instruction cache isync |remove copy in own instruction buffer */ lis r3, config_kernel_st...@h ori r3, r3, config_kernel_st...@l /* flush and invalidate from 0 to 0x600 */ li r5, 0x0 li r4, 0x600/L1_CACHE_BYTES mtctr r4 1: dcbst r5,r3 sync icbir5,r3 isync addir5, r5, L1_CACHE_BYTES/* Next line, please */ bdnz1b sync isync #include asm/reg.h #include asm/ppc_asm.h #include asm/processor.h #include asm/page.h #include asm/cache.h #define NUM_CACHE_LINES (128*8) /* this variable added to reserve 0x20*4 bytes. * This value has been derived by counting the * number of lines of the function code_atzero. * In case if the size of this function increases * the number of bytes have to increased accordi- * ngly. */ .data mpc5121_data_temp: .space 0x20*4 .text .globl mpc5121_copy_pmcclr mpc5121_copy_pmcclr: /* Coming here with interrupts disabled */ /* storing the content at 0x0 location * to mpc512_data_temp space */ lis r6, config_kernel_st...@h mr r4, r6 li r3, (code_atzero_end - code_atzero)/4 mtctr r3 lis r3, mpc5121_data_t...@h ori r3, r3, mpc5121_data_t...@l /* loops here till the counter is zero */ loop: lwz r5, 0(r4) stw r5, 0(r3) addir3, r3, 4 addir4, r4, 4 bdnzloop /* Copy code to Location 0x0 */ mr r4, r6 li r3, (code_atzero_end - code_atzero)/4 mtctr r3 lis r3, code_atz...@h ori r3, r3, code_atz...@l 1: lwz r5, 0(r3) stw r5, 0(r4) addi r3, r3, 4 addi r4, r4, 4 bdnz 1b /* Copy the jump to 0x0 code at 0x500*/ lwz r5, 0x500(r6) stw r5, 0(r6) lwz r5, 8(r6) stw r5, 0x500(r6) /* Flush the cache */ lis r3, config_kernel_st...@h ori r3, r3, config_kernel_st...@l /* Let us load data starting from 0x600 loc */ addi r3, r3, 0x600 li r4, NUM_CACHE_LINES mtctr r4 1: lwz r4, 0(r3) addi r3, r3, L1_CACHE_BYTES/* Next line, please */ bdnz 1b sync; isync blr .globl mpc5121_reinstall_handler mpc5121_reinstall_handler: /* Rewrite original code at 0x500 */ lis r6, config_kernel_st...@h lwz r5, 0(r6) stw r5, 0x500(r6) /* restoring content at 0x0 location */ mr r4, r6 li r3, (code_atzero_end - code_atzero)/4 mtctr r3 lis r3, mpc5121_data_t...@h ori r3, r3, mpc5121_data_t...@l /* loops here till the counter is zero */ loop1: lwz r5, 0(r3) stw r5, 0(r4) addir3, r3, 4 addir4, r4, 4 bdnzloop1 blr code_atzero: .long 0x0 /*Space reserved for copying first word of code from 0x500 */ ba 0x504 ba 0xc /* This code is not executed. This code is copied to 0x500 */ mtspr SPRN_SPRG0, r3 mtspr SPRN_SPRG1, r4 mfspr r3, 311 addi r3, r3, 0x1000 /* Assuming that MBAR is aligned to this size */ lwz r4, 0x4(r3) stw r4, 0x4(r3) /* clearing GPIO evnet registers */ mfspr r3, 311 /* getting offset of GPIO */ addir3, r3,0x1100 lwz r4, 0xC(r3) stw r4, 0xC(r3) mfspr r3, SPRN_SPRG0 mfspr r4, SPRN_SPRG1 ba 0x0 code_atzero_end: b code_atzero_end /* Should never reach here*/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause
kernel crashes when using the mdio-ofgpio driver.
This patch replicates similar changes made to the fs_enet mii-bitbang drivers. It has been tested on a custom mpc8280 based board using an NFS
mounted root.
Signed-off-by: Mark Ware mw...@elphinstone.net
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
The only changes in v3 are to the commit message.
drivers/net/phy/mdio-gpio.c | 77 ---
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include linux/of_gpio.h
+#include linux/of_mdio.h
#include linux/of_platform.h
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data *pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
new_bus-name = GPIO Bitbanged MDIO,
- ret = -ENODEV;
-
new_bus-phy_mask = pdata-phy_mask;
new_bus-irq = pdata-irqs;
new_bus-parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang-mdio);
out_free_mdc:
gpio_free(bitbang-mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus-priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang-mdc);
gpio_free(bitbang-mdio);
+ gpio_free(bitbang-mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev-dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(pdev-dev, pdata, pdev-id);
+ new_bus = mdio_gpio_bus_init(pdev-dev, pdata, pdev-id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(pdev-dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, reg, len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata-phy_mask = ~(1 id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata-irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct mdio_gpio_platform_data *pdata;
+ struct mii_bus *new_bus;
int ret;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
@@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct of_device
*ofdev,
ret = of_get_gpio(ofdev-node, 1);
if (ret 0)
-goto out_free;
+ goto out_free;
pdata-mdio = ret;
- while ((np = of_get_next_child(ofdev-node, np)))
- if (!strcmp(np-type, ethernet-phy))
- add_phy(pdata, np);
+ new_bus = mdio_gpio_bus_init(ofdev-dev, pdata, pdata-mdc);
+ if (!new_bus)
+ return -ENODEV;
- return mdio_gpio_bus_init(ofdev-dev,
[PATCH] powerpc/mm: Fix definitions of FORCE_MAX_ZONEORDER in Kconfig
The current definitions set ranges and defaults for 32 and 64-bit only using PPC_STD_MMU which means hash based MMU. This uselessly restrict the usefulness for the upcoming 64-bit BookE port, but more than that, it's broken on 32-bit since the only 32-bit platform supporting multiple page sizes currently is 44x which does -not- have PPC_STD_MMU_32 set. This fixes it by using PPC64 and PPC32 instead. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/Kconfig | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) --- linux-work.orig/arch/powerpc/Kconfig2009-07-22 11:22:16.0 +1000 +++ linux-work/arch/powerpc/Kconfig 2009-07-22 11:22:39.0 +1000 @@ -492,16 +492,16 @@ endchoice config FORCE_MAX_ZONEORDER int Maximum zone order - range 9 64 if PPC_STD_MMU_64 PPC_64K_PAGES - default 9 if PPC_STD_MMU_64 PPC_64K_PAGES - range 13 64 if PPC_STD_MMU_64 !PPC_64K_PAGES - default 13 if PPC_STD_MMU_64 !PPC_64K_PAGES - range 9 64 if PPC_STD_MMU_32 PPC_16K_PAGES - default 9 if PPC_STD_MMU_32 PPC_16K_PAGES - range 7 64 if PPC_STD_MMU_32 PPC_64K_PAGES - default 7 if PPC_STD_MMU_32 PPC_64K_PAGES - range 5 64 if PPC_STD_MMU_32 PPC_256K_PAGES - default 5 if PPC_STD_MMU_32 PPC_256K_PAGES + range 9 64 if PPC64 PPC_64K_PAGES + default 9 if PPC64 PPC_64K_PAGES + range 13 64 if PPC64 !PPC_64K_PAGES + default 13 if PPC64 !PPC_64K_PAGES + range 9 64 if PPC32 PPC_16K_PAGES + default 9 if PPC32 PPC_16K_PAGES + range 7 64 if PPC32 PPC_64K_PAGES + default 7 if PPC32 PPC_64K_PAGES + range 5 64 if PPC32 PPC_256K_PAGES + default 5 if PPC32 PPC_256K_PAGES range 11 64 default 11 help ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/cell: replace strncpy by strlcpy
Arnd-san, Roel-san,
It works fine. Thanks.
---
Regards,
Ken Kawakami
Replace strncpy() and explicit null-termination by strlcpy()
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Arnd-san, Ken-san,
Thanks for reviewing,
We prefer to take the patch which is replacing the two lines with one.
Doozo.
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c
b/arch/powerpc/platforms/cell/celleb_setup.c
index 07c234f..e538455 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -80,8 +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));
- celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
+ strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/7] [powerpc] ARRAY_SIZE changes
These changes were a direct result of using a semantic patch
More information can be found at http://www.emn.fr/x-info/coccinelle/
Signed-off-by: Stoyan Gaydarov sgay...@uiuc.edu
---
arch/powerpc/platforms/pasemi/idle.c |2 +-
arch/powerpc/platforms/powermac/feature.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/idle.c
b/arch/powerpc/platforms/pasemi/idle.c
index 43911d8..75b296b 100644
--- a/arch/powerpc/platforms/pasemi/idle.c
+++ b/arch/powerpc/platforms/pasemi/idle.c
@@ -90,7 +90,7 @@ machine_late_initcall(pasemi, pasemi_idle_init);
static int __init idle_param(char *p)
{
int i;
- for (i = 0; i sizeof(modes)/sizeof(struct sleep_mode); i++) {
+ for (i = 0; i ARRAY_SIZE(modes); i++) {
if (!strcmp(modes[i].name, p)) {
current_mode = i;
break;
diff --git a/arch/powerpc/platforms/powermac/feature.c
b/arch/powerpc/platforms/powermac/feature.c
index e6c0040..095de32 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2419,13 +2419,13 @@ static int __init probe_motherboard(void)
dt = of_find_node_by_name(NULL, device-tree);
if (dt != NULL)
model = of_get_property(dt, model, NULL);
- for(i=0; model i(sizeof(pmac_mb_defs)/sizeof(struct pmac_mb_def));
i++) {
+ for(i=0; model iARRAY_SIZE(pmac_mb_defs); i++) {
if (strcmp(model, pmac_mb_defs[i].model_string) == 0) {
pmac_mb = pmac_mb_defs[i];
goto found;
}
}
- for(i=0; i(sizeof(pmac_mb_defs)/sizeof(struct pmac_mb_def)); i++) {
+ for(i=0; iARRAY_SIZE(pmac_mb_defs); i++) {
if (machine_is_compatible(pmac_mb_defs[i].model_string)) {
pmac_mb = pmac_mb_defs[i];
goto found;
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
