LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* To post to this list
From: José Luis Añamuro @ 2007-08-31 17:44 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

To post to this list

Jose Luis


       
____________________________________________________________________________________
Sé un Mejor Amante del Cine                         
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
http://advision.webevents.yahoo.com/reto/entretenimiento.html

[-- Attachment #2: Type: text/html, Size: 528 bytes --]

^ permalink raw reply

* [PATCH] mpc5200: add cuimage support for mpc5200 boards
From: Grant Likely @ 2007-08-31 17:34 UTC (permalink / raw)
  To: tnt, scottwood, galak, linuxppc-dev

From: Grant Likely <grant.likely@secretlab.ca>

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 arch/powerpc/boot/Makefile          |    5 ++-
 arch/powerpc/boot/cuboot-52xx.c     |   59 ++++++++++++++++++++++++++++++
 arch/powerpc/boot/mpc52xx-psc.c     |   69 +++++++++++++++++++++++++++++++++++
 arch/powerpc/boot/ops.h             |    1 +
 arch/powerpc/boot/serial.c          |    2 +
 arch/powerpc/platforms/52xx/Kconfig |    1 +
 6 files changed, 135 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index cd7c057..45be0e5 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -45,8 +45,8 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
 		ns16550.c serial.c simple_alloc.c div64.S util.S \
 		gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
 		4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
-		cpm-serial.c
-src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
+		cpm-serial.c mpc52xx-psc.c
+src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
 		cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
 		ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c cuboot-pq2.c
 src-boot := $(src-wlib) $(src-plat) empty.c
@@ -142,6 +142,7 @@ image-$(CONFIG_DEFAULT_UIMAGE)		+= uImage
 ifneq ($(CONFIG_DEVICE_TREE),"")
 image-$(CONFIG_PPC_8xx)			+= cuImage.8xx
 image-$(CONFIG_8260)			+= cuImage.pq2
+image-$(CONFIG_PPC_MPC52xx)		+= cuImage.52xx
 image-$(CONFIG_PPC_83xx)		+= cuImage.83xx
 image-$(CONFIG_PPC_85xx)		+= cuImage.85xx
 image-$(CONFIG_EBONY)			+= treeImage.ebony cuImage.ebony
diff --git a/arch/powerpc/boot/cuboot-52xx.c b/arch/powerpc/boot/cuboot-52xx.c
new file mode 100644
index 0000000..9256a26
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-52xx.c
@@ -0,0 +1,59 @@
+/*
+ * Old U-boot compatibility for MPC5200
+ *
+ * Author: Grant Likely <grant.likely@secretlab.ca>
+ *
+ * Copyright (c) 2007 Secret Lab Technologies Ltd.
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "io.h"
+#include "cuboot.h"
+
+#define TARGET_PPC_MPC52xx
+#include "ppcboot.h"
+
+static bd_t bd;
+
+static void platform_fixups(void)
+{
+	void *soc, *reg;
+	int div;
+	u32 sysfreq;
+
+
+	dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+	dt_fixup_mac_addresses(bd.bi_enetaddr);
+	dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+
+	/* Unfortunately, the specific model number is encoded in the
+	 * soc node name in existing dts files -- once that is fixed,
+	 * this can do a simple path lookup.
+	 */
+	soc = find_node_by_devtype(NULL, "soc");
+	if (soc) {
+		setprop(soc, "bus-frequency", &bd.bi_ipbfreq,
+			sizeof(bd.bi_ipbfreq));
+
+		if (!dt_xlate_reg(soc, 0, (void*)&reg, NULL))
+			return;
+		div = in_8(reg + 0x204) & 0x0020 ? 8 : 4;
+		sysfreq = bd.bi_busfreq * div;
+		setprop(soc, "system-frequency", &sysfreq, sizeof(sysfreq));
+	}
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+                   unsigned long r6, unsigned long r7)
+{
+	CUBOOT_INIT();
+	ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+	serial_console_init();
+	platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/mpc52xx-psc.c b/arch/powerpc/boot/mpc52xx-psc.c
new file mode 100644
index 0000000..1074626
--- /dev/null
+++ b/arch/powerpc/boot/mpc52xx-psc.c
@@ -0,0 +1,69 @@
+/*
+ * MPC5200 PSC serial console support.
+ *
+ * Author: Grant Likely <grant.likely@secretlab.ca>
+ *
+ * Copyright (c) 2007 Secret Lab Technologies Ltd.
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * It is assumed that the firmware (or the platform file) has already set
+ * up the port.
+ */
+
+#include "types.h"
+#include "io.h"
+#include "ops.h"
+
+/* Programmable Serial Controller (PSC) status register bits */
+#define MPC52xx_PSC_SR		0x04
+#define MPC52xx_PSC_SR_RXRDY		0x0100
+#define MPC52xx_PSC_SR_RXFULL		0x0200
+#define MPC52xx_PSC_SR_TXRDY		0x0400
+#define MPC52xx_PSC_SR_TXEMP		0x0800
+
+#define MPC52xx_PSC_BUFFER	0x0C
+
+static void *psc;
+
+static int psc_open(void)
+{
+	/* Assume the firmware has already configured the PSC into
+	 * uart mode */
+	return 0;
+}
+
+static void psc_putc(unsigned char c)
+{
+	while (!(in_be16(psc + MPC52xx_PSC_SR) & MPC52xx_PSC_SR_TXRDY)) ;
+	out_8(psc + MPC52xx_PSC_BUFFER, c);
+}
+
+static unsigned char psc_tstc(void)
+{
+	return (in_be16(psc + MPC52xx_PSC_SR) & MPC52xx_PSC_SR_RXRDY) != 0;
+}
+
+static unsigned char psc_getc(void)
+{
+	while (!(in_be16(psc + MPC52xx_PSC_SR) & MPC52xx_PSC_SR_RXRDY)) ;
+	return in_8(psc + MPC52xx_PSC_BUFFER);
+}
+
+int mpc5200_psc_console_init(void *devp, struct serial_console_data *scdp)
+{
+	int n;
+
+	/* Get the base address of the psc registers */
+	n = getprop(devp, "virtual-reg", &psc, sizeof(psc));
+	if (n != sizeof(psc)) {
+		if (!dt_xlate_reg(devp, 0, (void *)&psc, NULL))
+			return -1;
+	}
+
+	scdp->open = psc_open;
+	scdp->putc = psc_putc;
+	scdp->getc = psc_getc;
+	scdp->tstc = psc_tstc;
+
+	return 0;
+}
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index 45c2268..5ab9b51 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -83,6 +83,7 @@ int serial_console_init(void);
 int ns16550_console_init(void *devp, struct serial_console_data *scdp);
 int mpsc_console_init(void *devp, struct serial_console_data *scdp);
 int cpm_console_init(void *devp, struct serial_console_data *scdp);
+int mpc5200_psc_console_init(void *devp, struct serial_console_data *scdp);
 void *simple_alloc_init(char *base, unsigned long heap_size,
 			unsigned long granularity, unsigned long max_allocs);
 extern void flush_cache(void *, unsigned long);
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index d47f8e0..95e08e4 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -126,6 +126,8 @@ int serial_console_init(void)
 	         dt_is_compatible(devp, "fsl,cpm2-scc-uart") ||
 	         dt_is_compatible(devp, "fsl,cpm2-smc-uart"))
 		rc = cpm_console_init(devp, &serial_cd);
+	else if (dt_is_compatible(devp, "mpc5200-psc-uart"))
+		rc = mpc5200_psc_console_init(devp, &serial_cd);
 
 	/* Add other serial console driver calls here */
 
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 3ffaa06..9ddf251 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -30,6 +30,7 @@ config PPC_EFIKA
 config PPC_LITE5200
 	bool "Freescale Lite5200 Eval Board"
 	depends on PPC_MULTIPLATFORM && PPC32
+	select WANT_DEVICE_TREE
 	select PPC_MPC5200
 	default n
 

^ permalink raw reply related

* to post to this list
From: José Luis Añamuro @ 2007-08-31 17:22 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

to post to this list

José Luis


       
____________________________________________________________________________________
Sé un Mejor Amante del Cine                         
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
http://advision.webevents.yahoo.com/reto/entretenimiento.html

[-- Attachment #2: Type: text/html, Size: 543 bytes --]

^ permalink raw reply

* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Arnd Bergmann @ 2007-08-31 17:08 UTC (permalink / raw)
  To: Joachim Fenkes
  Cc: Thomas Q Klein, Paul Mackerras, Jan-Bernd Themann, LKML,
	linuxppc-dev, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <OFBB1BA4B6.29175A76-ONC1257348.004DBCB3-C1257348.0050161C@de.ibm.com>

On Friday 31 August 2007, Joachim Fenkes wrote:
> > The whole logic of dynamically adding and removing device is rather 
> bogus,
> > and it prevents autoloading of device drivers. of_platform_make_bus_id
> > is the function that is responsible for creating unique names over 
> there.
> 
> The plaintiff makes a valid point. How about a staging approach: We put 
> the patch as it is now into 2.6.23 so the problem is fixed, and I'll post 
> a "nice" version with autoloading support and a generic of_make_bus_id 
> function for 2.6.24. Agree?

Ok, sounds fair. Can you make sure that the resulting bus_id is the same
for the final version then?

	Arnd <><

^ permalink raw reply

* Re: [linux kernel 2.6.19] ethernet driver for Marvell bridge GT-64260
From: Dale Farnsworth @ 2007-08-31 16:43 UTC (permalink / raw)
  To: joachim.bader, Linuxppc-embedded
In-Reply-To: <OF71BAC825.59CE0529-ONC1257348.0056D44E-C1257348.0057BBA0@diehl-gruppe.de>

> 
> I am porting linux kernel 2.6.19 on a platform based on PPC750FX together 
> with a Marvell GT64260.
> I use a patched 643xx driver which is back ported to 64260 by Steven J. 
> Hill.
> I have ethernet now up and running, but only if I switch debug on, which 
> generates a big bunch of screen messages.
> As soon as I switch debug off, I get the message "Virtual device %s asks 
> to queue packet!" on every transmission request.
> 
> This happens on ping an other system.
> 
> Has anyone experience in such an event? Is there anything how I can speed 
> up performance with the 64260?
> Is there a similar problem known with the 64360?

No, this does not happen on the mv64360.  As I recall, that message occurs
when something attempts to queue a packet to a driver that has called
netif_stop_queue() but hasn't yet called netif_wake_queue().  I would
guess that when you turn debug on, you are changing the driver logic
in addition to the timing.

-Dale

^ permalink raw reply

* Help linuxppc-2.4.26
From: José Luis Añamuro @ 2007-08-31 16:20 UTC (permalink / raw)
  To: ammubhai; +Cc: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

Hi 
I am Jose Luis.  I am compilling the kernel linuxppc-2.4.26. First I use the bitkepper to retrieve the version of kernel after I path it with Base Support Package (BSP) generated in EDK 8.2i, after I run "make oldconfig" to import the config file for the ML310, then I run "make menuconfig" when i set specifically changed from ml310, after i run "make dep", "make zImage" and .... appears a strange error that says:

make[1]: se ingresa al directorio `/home/jose/bk-client2.0/linuxppc-2.4.26/arch/ppc/4xx_io'
make all_targets
make[2]: se ingresa al directorio `/home/jose/bk-client2.0/linuxppc-2.4.26/arch/ppc/4xx_io'
make[2]: No se hace nada para `all_targets'.
make[2]: se sale del directorio `/home/jose/bk-client2.0/linuxppc-2.4.26/arch/ppc/4xx_io'
make[1]: se sale del directorio `/home/jose/bk-client2.0/linuxppc-2.4.26/arch/ppc/4xx_io'
powerpc-405-linux-gnu-ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic arch/ppc/kernel/head_4xx.o init/main.o init/version.o init/do_mounts.o \
                --start-group \
                arch/ppc/kernel/kernel.o arch/ppc/platforms/platform.o arch/ppc/mm/mm.o arch/ppc/lib/li b.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
                 drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o  drive rs/macintosh/macintosh.o drivers/media/media.o arch/ppc/4xx_io/4xx_io.o \
                net/network.o \
                /home/jose/bk-client2.0/linuxppc-2.4.26/lib/lib.a \
                --end-group \
                -o vmlinux
drivers/block/block.o(.text.init+0x6c8): In function `xsysace_init':
: undefined reference to `XSysAce_Initialize'
make: *** [vmlinux] Error 1

Please i hope so you can help me, I carry many days with it and I do not know how resolv it

Best Regards
José Luis




      ______________________________________________ 
Sé un Mejor Viajero                                      
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
http://advision.webevents.yahoo.com/reto/viaje.html

[-- Attachment #2: Type: text/html, Size: 2869 bytes --]

^ permalink raw reply

* [linux kernel 2.6.19] ethernet driver for Marvell bridge GT-64260
From: joachim.bader @ 2007-08-31 15:58 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

Hello,

I am porting linux kernel 2.6.19 on a platform based on PPC750FX together 
with a Marvell GT64260.
I use a patched 643xx driver which is back ported to 64260 by Steven J. 
Hill.
I have ethernet now up and running, but only if I switch debug on, which 
generates a big bunch of screen messages.
As soon as I switch debug off, I get the message "Virtual device %s asks 
to queue packet!" on every transmission request.

This happens on ping an other system.

Has anyone experience in such an event? Is there anything how I can speed 
up performance with the 64260?
Is there a similar problem known with the 64360?

Thanks in advance.
Joachim



_______________________________________________________________________________________________________________________
Der Inhalt dieser E-Mail ist für den Absender rechtlich nicht verbindlich. 
Informieren Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise erhalten haben (Fax: +49-69-5805-1399). Bitte löschen Sie in diesem Fall die Nachricht. Jede Form der weiteren Benutzung ist untersagt.

The content of this e-mail is not legally binding upon the sender.
If this e-mail was transmitted to you by error, then please inform us accordingly (Fax: +49-69-5805-1399). In such case you are requested to erase the message. Any use of such e-mail message is strictly prohibited.

[-- Attachment #2: Type: text/html, Size: 2274 bytes --]

^ permalink raw reply

* Re: [PATCH 1/3] bootwrapper: In cuImage, print message for ENET devices not found in tree
From: Grant Likely @ 2007-08-31 15:29 UTC (permalink / raw)
  To: Grant Likely, linuxppc-dev, Scott Wood
In-Reply-To: <20070831042536.GL19271@localhost.localdomain>

On 8/30/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> Sorry, I was misleading.  Scott moved the printf() into the if (devp)
> as you do, but *didn't* add the alternative warning message in the
> else.
>
> The reason for this is that Planetcore only supplies the first MAC
> address, and the bootwrapper must derive the addresses for all the
> ENETs from that.  That in turn means it is much more convenient to
> call fixup_mac_addresses() with more addresses than there are
> ethernets, so we don't want a warning message when that happens.

Okay, that makes sense.  I just found Scott's patch which does the
same, so I'll drop my version.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: [PATCH 1/7] Generic bitbanged MDIO library
From: Scott Wood @ 2007-08-31 15:16 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: netdev, Paul Mackerras, linuxppc-dev
In-Reply-To: <46D81638.6050509@pobox.com>

On Fri, Aug 31, 2007 at 09:23:04AM -0400, Jeff Garzik wrote:
> I cannot ACK this, nor do I want to see it merged, until users appear 
> and have been reviewed alongside this.  I do not see any fs_enet patches 
> that actually use this.

The fs_enet patchset does use it in mii-bitbang.c, in patch 6/7 (or 7/8
in the revised patchset).  I'll also be using it on the ep8248e board
(which is why I factored it out), which I'll attach below.

> * the delay (where you call ndelay()) is not guaranteed without a flush 
> of some sort

Hmm...  I'm inclined to push that into the client's implementation of set
mdc/data, primarily because there's no get mdc to do a read-back
generically.

> * how widely applicable is this "generic" library?

It implements MDIO as described in the ethernet specification; there
should be no implementation dependencies.

>  have you converted any non-embedded drivers over to it?

No; most hardware doesn't need bitbanging.  Sunhme does, but I don't have
hardware to test a conversion.

Here's the ep8248e user of the bitbang code:

/*
 * Embedded Planet EP8248E support
 *
 * Copyright 2007 Freescale Semiconductor, Inc.
 * Author: Scott Wood <scottwood@freescale.com>
 *
 * This program is free software; you can redistribute  it and/or modify
 * it under the terms of version 2 of the GNU General Public License as
 * published by the Free Software Foundation.
 */

#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/fsl_devices.h>
#include <linux/mdio-bitbang.h>
#include <linux/of_platform.h>

#include <asm/io.h>
#include <asm/cpm2.h>
#include <asm/udbg.h>
#include <asm/machdep.h>
#include <asm/time.h>
#include <asm/mpc8260.h>

#include <sysdev/fsl_soc.h>
#include <sysdev/cpm2_pic.h>

#include "pq2.h"

static u8 __iomem *ep8248e_bcsr;
static struct device_node *ep8248e_bcsr_node;

#define BCSR7_SCC2_ENABLE 0x10

#define BCSR8_PHY1_ENABLE 0x80
#define BCSR8_PHY1_POWER  0x40
#define BCSR8_PHY2_ENABLE 0x20
#define BCSR8_PHY2_POWER  0x10
#define BCSR8_MDIO_READ   0x04
#define BCSR8_MDIO_CLOCK  0x02
#define BCSR8_MDIO_DATA   0x01

#define BCSR9_USB_ENABLE  0x80
#define BCSR9_USB_POWER   0x40
#define BCSR9_USB_HOST    0x20
#define BCSR9_USB_FULL_SPEED_TARGET 0x10

static void __init ep8248_pic_init(void)
{
	struct device_node *np = of_find_compatible_node(NULL, NULL, "fsl,pq2-pic");
	if (!np) {
		printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
		return;
	}

	cpm2_pic_init(np);
	of_node_put(np);
}

static void ep8248e_set_mdc(struct mdio_bitbang_ctrl *ctrl, int level)
{
	if (level)
		setbits8(&ep8248e_bcsr[8], BCSR8_MDIO_CLOCK);
	else
		clrbits8(&ep8248e_bcsr[8], BCSR8_MDIO_CLOCK);

	/* Flush the write before delaying. */
	in_8(&ep8248e_bcsr[8]);
}

static void ep8248e_set_mdio_dir(struct mdio_bitbang_ctrl *ctrl, int output)
{
	if (output)
		clrbits8(&ep8248e_bcsr[8], BCSR8_MDIO_READ);
	else
		setbits8(&ep8248e_bcsr[8], BCSR8_MDIO_READ);

	/* Flush the write before delaying. */
	in_8(&ep8248e_bcsr[8]);
}

static void ep8248e_set_mdio_data(struct mdio_bitbang_ctrl *ctrl, int data)
{
	if (data)
		setbits8(&ep8248e_bcsr[8], BCSR8_MDIO_DATA);
	else
		clrbits8(&ep8248e_bcsr[8], BCSR8_MDIO_DATA);

	/* Flush the write before delaying. */
	in_8(&ep8248e_bcsr[8]);
}

static int ep8248e_get_mdio_data(struct mdio_bitbang_ctrl *ctrl)
{
	return in_8(&ep8248e_bcsr[8]) & BCSR8_MDIO_DATA;
}

static struct mdio_bitbang_ops ep8248e_mdio_ops = {
	.set_mdc = ep8248e_set_mdc,
	.set_mdio_dir = ep8248e_set_mdio_dir,
	.set_mdio_data = ep8248e_set_mdio_data,
	.get_mdio_data = ep8248e_get_mdio_data,
	.owner = THIS_MODULE,
};

static struct mdio_bitbang_ctrl ep8248e_mdio_ctrl = {
	.ops = &ep8248e_mdio_ops,
};

static int __devinit ep8248e_mdio_probe(struct of_device *ofdev,
                                        const struct of_device_id *match)
{
	struct mii_bus *bus;
	struct resource res;
	int ret, i;

	if (of_get_parent(ofdev->node) != ep8248e_bcsr_node)
		return -ENODEV;

	ret = of_address_to_resource(ofdev->node, 0, &res);
	if (ret)
		return ret;

	bus = alloc_mdio_bitbang(&ep8248e_mdio_ctrl);
	if (!bus)
		return -ENOMEM;

	bus->phy_mask = 0;
	bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);

	for (i = 0; i < PHY_MAX_ADDR; i++)
		bus->irq[i] = -1;

	bus->name = "ep8248e-mdio-bitbang";
	bus->dev = &ofdev->dev;
	bus->id = res.start;

	return mdiobus_register(bus);
}

static int ep8248e_mdio_remove(struct of_device *ofdev)
{
	BUG();
	return 0;
}

static struct of_device_id ep8248e_mdio_match[] = {
	{
		.compatible = "fsl,ep8248e-mdio-bitbang",
	},
	{},
};

static struct of_platform_driver ep8248e_mdio_driver = {
	.name = "ep8248e-mdio-bitbang",
	.match_table = ep8248e_mdio_match,
	.probe = ep8248e_mdio_probe,
	.remove = ep8248e_mdio_remove,
};

struct cpm_pin {
	int port, pin, flags;
};

static struct cpm_pin ep8248_pins[] = {
	/* SMC1 */
	{2, 4, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{2, 5, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},

	/* SCC1 */
	{2, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{2, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{3, 29, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{3, 30, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
	{3, 31, CPM_PIN_INPUT | CPM_PIN_PRIMARY},

	/* FCC1 */
	{0, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{0, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{0, 16, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{0, 17, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{0, 18, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{0, 19, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{0, 20, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{0, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{0, 26, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
	{0, 27, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
	{0, 28, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
	{0, 29, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
	{0, 30, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
	{0, 31, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
	{2, 21, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{2, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},

	/* FCC2 */
	{1, 18, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{1, 19, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{1, 20, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{1, 21, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{1, 22, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{1, 23, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{1, 24, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{1, 25, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{1, 26, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{1, 27, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{1, 28, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{1, 29, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
	{1, 30, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{1, 31, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{2, 18, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{2, 19, CPM_PIN_INPUT | CPM_PIN_PRIMARY},

	/* I2C */
	{4, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
	{4, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY},

	/* USB */
	{2, 10, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{2, 11, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{2, 20, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{2, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
	{3, 23, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{3, 24, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
	{3, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
};

static void __init init_ioports(void)
{
	int i;

	for (i = 0; i < ARRAY_SIZE(ep8248_pins); i++) {
		struct cpm_pin *pin = &ep8248_pins[i];
		cpm2_set_pin(pin->port, pin->pin, pin->flags);
	}

	cpm2_smc_clk_setup(CPM_CLK_SMC1, CPM_BRG7);
	cpm2_clk_setup(CPM_CLK_SCC1, CPM_BRG1, CPM_CLK_RX);
	cpm2_clk_setup(CPM_CLK_SCC1, CPM_BRG1, CPM_CLK_TX);
	cpm2_clk_setup(CPM_CLK_SCC3, CPM_CLK8, CPM_CLK_TX); /* USB */
	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_RX);
	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_TX);
	cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK13, CPM_CLK_RX);
	cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK14, CPM_CLK_TX);
}

static void __init ep8248_setup_arch(void)
{
	if (ppc_md.progress)
		ppc_md.progress("ep8248_setup_arch()", 0);

	cpm2_reset();

	/* When this is set, snooping CPM DMA from RAM causes
	 * machine checks.  See erratum SIU18.
	 */
	clrbits32(&cpm2_immr->im_siu_conf.siu_82xx.sc_bcr, MPC82XX_BCR_PLDP);

	ep8248e_bcsr_node =
		of_find_compatible_node(NULL, NULL, "fsl,ep8248e-bcsr");
	if (!ep8248e_bcsr_node) {
		printk(KERN_ERR "No bcsr in device tree\n");
		return;
	}

	ep8248e_bcsr = of_iomap(ep8248e_bcsr_node, 0);
	if (!ep8248e_bcsr) {
		printk(KERN_ERR "Cannot map BCSR registers\n");
		return;
	}

	setbits8(&ep8248e_bcsr[7], BCSR7_SCC2_ENABLE);
	setbits8(&ep8248e_bcsr[8], BCSR8_PHY1_ENABLE | BCSR8_PHY1_POWER |
	                           BCSR8_PHY2_ENABLE | BCSR8_PHY2_POWER);

	init_ioports();

	if (ppc_md.progress)
		ppc_md.progress("ep8248_setup_arch(), finish", 0);
}

static struct of_device_id __initdata of_bus_ids[] = {
	{ .name = "soc", },
	{ .name = "cpm", },
	{ .compatible = "fsl,pq2-chipselect", },
	{ .compatible = "fsl,ep8248e-bcsr", },
	{},
};

static int __init declare_of_platform_devices(void)
{
	if (!machine_is(ep8248))
		return 0;

	of_platform_bus_probe(NULL, of_bus_ids, NULL);
	of_register_platform_driver(&ep8248e_mdio_driver);

	return 0;
}
device_initcall(declare_of_platform_devices);

/*
 * Called very early, device-tree isn't unflattened
 */
static int __init ep8248_probe(void)
{
	unsigned long root = of_get_flat_dt_root();
	return of_flat_dt_is_compatible(root, "fsl,ep8248e");
}

define_machine(ep8248)
{
	.name = "Embedded Planet EP8248E",
	.probe = ep8248_probe,
	.setup_arch = ep8248_setup_arch,
	.init_IRQ = ep8248_pic_init,
	.get_irq = cpm2_get_irq,
	.calibrate_decr = generic_calibrate_decr,
	.restart = pq2_restart,
	.progress = udbg_progress,
};

^ permalink raw reply

* Re: Section mismatch in 2.6.23-rc4
From: Josh Boyer @ 2007-08-31 14:41 UTC (permalink / raw)
  Cc: linuxppc-dev
In-Reply-To: <20070831093211.3ad97687@weaponx.rchland.ibm.com>

On Fri, 31 Aug 2007 09:32:11 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:

> On Fri, 31 Aug 2007 14:25:34 +0200
> "Hommel, Thomas (GE Indust, GE Fanuc)" <Thomas.Hommel@gefanuc.com>
> wrote:
> 
> > 
> > When compiling a kernel, I get the warnings below. 
> > I am using ARCH=powerpc and 'make mpc8641_hpcn_defconfig', 'make
> > uImage'. This didn't appear in 2.6.22, but in
> > arch/powerpc/kernel/head_32.S and setup_32.c, the section info
> > apparently didn't change. 
> 
> Kumar Galak has a patch series that clean these warnings up for ppc32.

Er, that would be Kumar Gala.  There I go, defaulting to IRC nicks
again.

josh

^ permalink raw reply

* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Joachim Fenkes @ 2007-08-31 14:34 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Thomas Q Klein, Paul Mackerras, Jan-Bernd Themann, LKML,
	linuxppc-dev, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200708302022.24167.arnd@arndb.de>

Hi, Arnd,

> The whole logic of dynamically adding and removing device is rather 
bogus,
> and it prevents autoloading of device drivers. of_platform_make_bus_id
> is the function that is responsible for creating unique names over 
there.

The plaintiff makes a valid point. How about a staging approach: We put 
the patch as it is now into 2.6.23 so the problem is fixed, and I'll post 
a "nice" version with autoloading support and a generic of_make_bus_id 
function for 2.6.24. Agree?

Regards,
  Joachim

^ permalink raw reply

* Re: Section mismatch in 2.6.23-rc4
From: Josh Boyer @ 2007-08-31 14:32 UTC (permalink / raw)
  To: Hommel, Thomas (GE Indust, GE Fanuc); +Cc: linuxppc-dev, paulus
In-Reply-To: <62DDBB9E5E23CC4A929EE46F9427CEAF295F6F@BUDMLVEM04.e2k.ad.ge.com>

On Fri, 31 Aug 2007 14:25:34 +0200
"Hommel, Thomas (GE Indust, GE Fanuc)" <Thomas.Hommel@gefanuc.com>
wrote:

> 
> When compiling a kernel, I get the warnings below. 
> I am using ARCH=powerpc and 'make mpc8641_hpcn_defconfig', 'make
> uImage'. This didn't appear in 2.6.22, but in
> arch/powerpc/kernel/head_32.S and setup_32.c, the section info
> apparently didn't change. 

Kumar Galak has a patch series that clean these warnings up for ppc32.

josh

^ permalink raw reply

* [PATCH 2/2] IB/ehca: SRQ fixes to enable IPoIB CM
From: Joachim Fenkes @ 2007-08-31 14:03 UTC (permalink / raw)
  To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier
  Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200708311601.42220.fenkes@de.ibm.com>

a) Report max_srq > 0 if SRQ is supported
b) Report "last wqe reached" event when base QP dies

Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
 drivers/infiniband/hw/ehca/ehca_hca.c |   10 +++++--
 drivers/infiniband/hw/ehca/ehca_irq.c |   48 +++++++++++++++++++++-----------
 2 files changed, 38 insertions(+), 20 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_hca.c b/drivers/infiniband/hw/ehca/ehca_hca.c
index fc19ef9..cf22472 100644
--- a/drivers/infiniband/hw/ehca/ehca_hca.c
+++ b/drivers/infiniband/hw/ehca/ehca_hca.c
@@ -93,9 +93,13 @@ int ehca_query_device(struct ib_device *ibdev, struct ib_device_attr *props)
 	props->max_pd          = min_t(int, rblock->max_pd, INT_MAX);
 	props->max_ah          = min_t(int, rblock->max_ah, INT_MAX);
 	props->max_fmr         = min_t(int, rblock->max_mr, INT_MAX);
-	props->max_srq         = 0;
-	props->max_srq_wr      = 0;
-	props->max_srq_sge     = 0;
+
+	if (EHCA_BMASK_GET(HCA_CAP_SRQ, shca->hca_cap)) {
+		props->max_srq         = props->max_qp;
+		props->max_srq_wr      = props->max_qp_wr;
+		props->max_srq_sge     = 3;
+	}
+
 	props->max_pkeys       = 16;
 	props->local_ca_ack_delay
 		= rblock->local_ca_ack_delay;
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
index ee06d8b..a925ea5 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -175,41 +175,55 @@ error_data1:
 
 }
 
-static void qp_event_callback(struct ehca_shca *shca, u64 eqe,
-			      enum ib_event_type event_type, int fatal)
+static void dispatch_qp_event(struct ehca_shca *shca, struct ehca_qp *qp,
+			      enum ib_event_type event_type)
 {
 	struct ib_event event;
-	struct ehca_qp *qp;
-	u32 token = EHCA_BMASK_GET(EQE_QP_TOKEN, eqe);
-
-	read_lock(&ehca_qp_idr_lock);
-	qp = idr_find(&ehca_qp_idr, token);
-	read_unlock(&ehca_qp_idr_lock);
-
-
-	if (!qp)
-		return;
-
-	if (fatal)
-		ehca_error_data(shca, qp, qp->ipz_qp_handle.handle);
 
 	event.device = &shca->ib_device;
+	event.event = event_type;
 
 	if (qp->ext_type == EQPT_SRQ) {
 		if (!qp->ib_srq.event_handler)
 			return;
 
-		event.event = fatal ? IB_EVENT_SRQ_ERR : event_type;
 		event.element.srq = &qp->ib_srq;
 		qp->ib_srq.event_handler(&event, qp->ib_srq.srq_context);
 	} else {
 		if (!qp->ib_qp.event_handler)
 			return;
 
-		event.event = event_type;
 		event.element.qp = &qp->ib_qp;
 		qp->ib_qp.event_handler(&event, qp->ib_qp.qp_context);
 	}
+}
+
+static void qp_event_callback(struct ehca_shca *shca, u64 eqe,
+			      enum ib_event_type event_type, int fatal)
+{
+	struct ehca_qp *qp;
+	u32 token = EHCA_BMASK_GET(EQE_QP_TOKEN, eqe);
+
+	read_lock(&ehca_qp_idr_lock);
+	qp = idr_find(&ehca_qp_idr, token);
+	read_unlock(&ehca_qp_idr_lock);
+
+	if (!qp)
+		return;
+
+	if (fatal)
+		ehca_error_data(shca, qp, qp->ipz_qp_handle.handle);
+
+	dispatch_qp_event(shca, qp, fatal && qp->ext_type == EQPT_SRQ ?
+			  IB_EVENT_SRQ_ERR : event_type);
+
+	/*
+	 * eHCA only processes one WQE at a time for SRQ base QPs,
+	 * so the last WQE has been processed as soon as the QP enters
+	 * error state.
+	 */
+	if (fatal && qp->ext_type == EQPT_SRQBASE)
+		dispatch_qp_event(shca, qp, IB_EVENT_QP_LAST_WQE_REACHED);
 
 	return;
 }
-- 
1.5.2

^ permalink raw reply related

* [PATCH 1/2] IB/ehca: fix Small QP regressions
From: Joachim Fenkes @ 2007-08-31 14:02 UTC (permalink / raw)
  To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier
  Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200708311601.42220.fenkes@de.ibm.com>

From: Stefan Roscher <stefan.roscher@de.ibm.com>

The new Small QP code had a few bugs that would also trigger for non-Small
QPs. Fix them.

Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
 drivers/infiniband/hw/ehca/ehca_qp.c   |   10 ++++++----
 drivers/infiniband/hw/ehca/ipz_pt_fn.c |    2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index b178cba..84d435a 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -600,10 +600,12 @@ static struct ehca_qp *internal_create_qp(
 
 	if (EHCA_BMASK_GET(HCA_CAP_MINI_QP, shca->hca_cap)
 	    && !(context && udata)) { /* no small QP support in userspace ATM */
-		ehca_determine_small_queue(
-			&parms.squeue, max_send_sge, is_llqp);
-		ehca_determine_small_queue(
-			&parms.rqueue, max_recv_sge, is_llqp);
+		if (HAS_SQ(my_qp))
+			ehca_determine_small_queue(
+				&parms.squeue, max_send_sge, is_llqp);
+		if (HAS_RQ(my_qp))
+			ehca_determine_small_queue(
+				&parms.rqueue, max_recv_sge, is_llqp);
 		parms.qp_storage =
 			(parms.squeue.is_small || parms.rqueue.is_small);
 	}
diff --git a/drivers/infiniband/hw/ehca/ipz_pt_fn.c b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
index a090c67..29bd476 100644
--- a/drivers/infiniband/hw/ehca/ipz_pt_fn.c
+++ b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
@@ -172,7 +172,7 @@ static void free_small_queue_page(struct ipz_queue *queue, struct ehca_pd *pd)
 	unsigned long bit;
 	int free_page = 0;
 
-	bit = ((unsigned long)queue->queue_pages[0] & PAGE_MASK)
+	bit = ((unsigned long)queue->queue_pages[0] & ~PAGE_MASK)
 		>> (order + 9);
 
 	mutex_lock(&pd->lock);
-- 
1.5.2

^ permalink raw reply related

* [PATCH 0/2] IB/ehca: Fixes for rc5
From: Joachim Fenkes @ 2007-08-31 14:01 UTC (permalink / raw)
  To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier
  Cc: Stefan Roscher, Christoph Raisch

These two patches fix some ehca issues that should be fixed in 2.6.23.

[1/2] fixes regressions caused by the recent addition of Small QPs.
[2/2] adds missing SRQ-related functionality that would have broken IPoIB C=
M.

The patches should apply cleanly, in order, against Roland's git. Please
review the changes and apply the patches for 2.6.23-rc5 if they are okay.

Regards,
  Joachim

=2D-=20
Joachim Fenkes =A0-- =A0eHCA Linux Driver Developer and Hardware Tamer
IBM Deutschland Entwicklung GmbH =A0-- =A0Dept. 3627 (I/O Firmware Dev. 2)
Schoenaicher Strasse 220 =A0-- =A071032 Boeblingen =A0-- =A0Germany
eMail: fenkes@de.ibm.com

^ permalink raw reply

* Re: [PATCH v2] [02/10] pasemi_mac: Stop using the pci config space accessors for register read/writes
From: Jeff Garzik @ 2007-08-31 13:54 UTC (permalink / raw)
  To: Olof Johansson; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070823181310.GB31882@lixom.net>

Olof Johansson wrote:
> Move away from using the pci config access functions for simple register
> access.  Our device has all of the registers in the config space (hey,
> from the hardware point of view it looks reasonable :-), so we need to
> somehow get to it. Newer firmwares have it in the device tree such that
> we can just get it and ioremap it there (in case it ever moves in future
> products). For now, provide a hardcoded fallback for older firmwares.
> 
> 
> Signed-off-by: Olof Johansson <olof@lixom.net>

applied 2-10

^ permalink raw reply

* RE: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Li Yang-r58472 @ 2007-08-31 13:50 UTC (permalink / raw)
  To: Tabi Timur-B04825, Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <46D73166.6080103@freescale.com>

> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Tabi Timur-B04825
> Sent: Friday, August 31, 2007 5:07 AM
> To: Anton Vorontsov
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts=20
> to use SPI1in QE, register mmc_spi stub
>=20
> Anton Vorontsov wrote:
>=20
> > +static int __init mpc832x_spi_init(void) {
> > +	if (!machine_is(mpc832x_rdb))
> > +		return 0;
> > +
> > +	par_io_config_pin(3,  0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
> > +	par_io_config_pin(3,  1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
> > +	par_io_config_pin(3,  2, 3, 0, 1, 0); /* SPI1 CLK,  I/O */
> > +	par_io_config_pin(3,  3, 2, 0, 1, 0); /* SPI1 SEL,  I   */
> > +
> > +	par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS,    O */
> > +	par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
> > +	par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
>=20
> Why are you doing this here, and not in the device tree?

I saw you used pio node, but later changed to make it hardcoded.  What's
the reason?  IMO, device tree is used to describe the hardware settings,
pio node is a perfect match.  Moreover, changing the device tree is much
easier than changing the code.

- Leo

^ permalink raw reply

* Re: [PATCH] [01/10] pasemi_mac: Abstract out register access
From: Jeff Garzik @ 2007-08-31 13:50 UTC (permalink / raw)
  To: Olof Johansson; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070822141244.GB16830@lixom.net>

applied

^ permalink raw reply

* Re: [PATCH] bmac: add simple ethtool support for network manager
From: Jeff Garzik @ 2007-08-31 13:47 UTC (permalink / raw)
  To: Olaf Hering; +Cc: linuxppc-dev, netdev
In-Reply-To: <20070825183259.GA14478@aepfle.de>

Olaf Hering wrote:
> NetworkManager will not start dhcpd on an interface unless it reports
> link-up state via ethtool.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> ---
>  drivers/net/bmac.c |   13 +++++++++++++
>  1 file changed, 13 insertions(+)

applied

^ permalink raw reply

* Re: dtc: Optimise by default, fix warnings thus uncovered
From: Jon Loeliger @ 2007-08-31 13:38 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070831062123.GC29721@localhost.localdomain>

So, like, the other day David Gibson mumbled:
> This patch turns on optimisation in the Makefile by default.  With the
> optimizer on, some uninitialized variable warnings (one real, two
> bogus) are now generated.  This patch also squashes those again.

Applied.

Thanks,
jdl

^ permalink raw reply

* Re: dtc: Make make print a message when linking testcases
From: Jon Loeliger @ 2007-08-31 13:38 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070831060427.GB29721@localhost.localdomain>

So, like, the other day David Gibson mumbled:
> Currently, dtc relies on make's implicit rule to build the testcases.
> This means that when not making verbosely (V=0, the default) there is
> no message at all while relinking the testsuites.  This can be very
> confusing when updating libfdt.a (upon which the testcases depend) and
> make appears to do nothing.
> 
> This patch corrects the situation, borrowing the rule used to link dtc
> itself to link all the testcases as well.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Applied.

Thanks,
jdl

^ permalink raw reply

* Re: libfdt: Fix use of uninitialized variable in fdt_get_path()
From: Jon Loeliger @ 2007-08-31 13:38 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070831043016.GM19271@localhost.localdomain>

So, like, the other day David Gibson mumbled:
> My recent implemenetation of fdt_get_path() had a bug - the while loop
> tested offset which was unitialized on the first iteration.  Depending
> on code surrounding the call, this could cause fdt_get_path() to
> return incorrect results.
> 
> This patch corrects the problem by applying some more correct thinking
> to the loop condition.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Applied.

Thanks,
jdl

^ permalink raw reply

* Re: [PATCH 1/6] ibmveth: Enable TCP checksum offload
From: Jeff Garzik @ 2007-08-31 13:32 UTC (permalink / raw)
  To: Brian King; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <11873601831813-patch-mail.ibm.com>

Brian King wrote:
> This patchset enables TCP checksum offload support for IPV4
> on ibmveth. This completely eliminates the generation and checking of
> the checksum for packets that are completely virtual and never
> touch a physical network. A simple TCP_STREAM netperf run on
> a virtual network with maximum mtu set yielded a ~30% increase
> in throughput. This feature is enabled by default on systems that
> support it, but can be disabled with a module option.
> 
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>

applied 1-6

^ permalink raw reply

* Re: [PATCH 1/7] Generic bitbanged MDIO library
From: Jeff Garzik @ 2007-08-31 13:23 UTC (permalink / raw)
  To: Scott Wood; +Cc: netdev, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070817175357.GA9218@ld0162-tx32.am.freescale.net>

Scott Wood wrote:
> Previously, bitbanged MDIO was only supported in individual
> hardware-specific drivers.  This code factors out the higher level
> protocol implementation, reducing the hardware-specific portion to
> functions setting direction, data, and clock.
> 
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
>  drivers/net/phy/Kconfig        |    9 ++
>  drivers/net/phy/Makefile       |    1 +
>  drivers/net/phy/mdio-bitbang.c |  187 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/mdio-bitbang.h   |   42 +++++++++
>  4 files changed, 239 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/net/phy/mdio-bitbang.c
>  create mode 100644 include/linux/mdio-bitbang.h

I cannot ACK this, nor do I want to see it merged, until users appear 
and have been reviewed alongside this.  I do not see any fs_enet patches 
that actually use this.

five-second-glance comments:

* "mdio_bitbang_" is a long prefix.  consider "mdiobb_" or somesuch

* the delay (where you call ndelay()) is not guaranteed without a flush 
of some sort

* how widely applicable is this "generic" library?  have you converted 
any non-embedded drivers over to it?

^ permalink raw reply

* Re: [PATCH 2/7] fs_enet: Whitespace cleanup.
From: Jeff Garzik @ 2007-08-31 13:19 UTC (permalink / raw)
  To: Scott Wood; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070817175359.GB9218@ld0162-tx32.am.freescale.net>

Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
>  drivers/net/fs_enet/fs_enet-main.c |   85 ++++++++++++++++-------------------
>  drivers/net/fs_enet/fs_enet.h      |    4 +-
>  drivers/net/fs_enet/mac-fcc.c      |    1 -
>  drivers/net/fs_enet/mii-fec.c      |    1 -
>  4 files changed, 41 insertions(+), 50 deletions(-)

ACK patches 2-7

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox