LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Remove unnecessary memset from physmap_of driver
From: Valentine Barshak @ 2007-10-02 15:53 UTC (permalink / raw)
  To: linuxppc-dev

No need for memset to zero memory here, since we use kzalloc.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 drivers/mtd/maps/physmap_of.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index cf75a56..aeed9ea 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -232,7 +232,6 @@ static int __devinit of_flash_probe(struct of_device *dev,
 	info = kzalloc(sizeof(*info), GFP_KERNEL);
 	if (!info)
 		goto err_out;
-	memset(info, 0, sizeof(*info));
 
 	dev_set_drvdata(&dev->dev, info);
 
-- 
1.5.2.4

^ permalink raw reply related

* Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)
From: Grant Likely @ 2007-10-02 15:54 UTC (permalink / raw)
  To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87abr134pc.fsf@macbook.be.48ers.dk>

On 10/2/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> The uartlite driver is ofcause primarily used to drive Xilinx
> OPB_Uartlite IP blocks, but that's not the only use - E.G. we are
> using another simple UART with the same hardware interface but sitting
> on a 16bit bus. With the current driver this works fine, but won't
> with the out_be32.

Ugh.  Alright I'll revert the patch.

Cheers,
g.

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

^ permalink raw reply

* Re: [PATCH] cpm: rounding of brg clockdivider
From: Scott Wood @ 2007-10-02 15:46 UTC (permalink / raw)
  To: Esben Haabendal; +Cc: LinuxPPC-dev
In-Reply-To: <9edac4e26b9461b125012c7e025c847f@127.0.0.1>

Esben Haabendal wrote:
> Do rounding of brg clockdivider instead of truncate to get more precise baudrates

IIRC, the truncated divider produced better results with serial on 
mpc8272ads...

-Scott

^ permalink raw reply

* Re: [PATCH 11/18] Virtex: Port UARTLITE driver to of-platform-bus
From: Peter Korsgaard @ 2007-10-02 15:47 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070928181748.18608.62409.stgit@trillian.cg.shawcable.net>

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

Hi,

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

 Grant>  drivers/serial/uartlite.c |  101 +++++++++++++++++++++++++++++++++++++++++----
 Grant>  1 files changed, 93 insertions(+), 8 deletions(-)

 Grant> diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
 Grant> index ed13b9f..8f742e0 100644
 Grant> --- a/drivers/serial/uartlite.c
 Grant> +++ b/drivers/serial/uartlite.c
 Grant> @@ -1,7 +1,8 @@
 Grant>  /*
 Grant>   * uartlite.c: Serial driver for Xilinx uartlite serial controller
 Grant>   *
 Grant> - * Peter Korsgaard <jacmet@sunsite.dk>
 Grant> + * Copyright (C) 2006 Peter Korsgaard <jacmet@sunsite.dk>
 Grant> + * Copyright (C) 2007 Secret Lab Technologies Ltd.
 Grant>   *
 Grant>   * This file is licensed under the terms of the GNU General Public License
 Grant>   * version 2.  This program is licensed "as is" without any warranty of any
 Grant> @@ -17,6 +18,10 @@
 Grant>  #include <linux/delay.h>
 Grant>  #include <linux/interrupt.h>
 Grant>  #include <asm/io.h>
 Grant> +#if defined(CONFIG_OF)
 Grant> +#include <linux/of_device.h>
 Grant> +#include <linux/of_platform.h>
 Grant> +#endif
 
 Grant>  #define ULITE_NAME		"ttyUL"
 Grant>  #define ULITE_MAJOR		204
 Grant> @@ -382,8 +387,10 @@ static int __init ulite_console_setup(struct console *co, char *options)
 Grant>  	port = &ulite_ports[co->index];
 
 Grant>  	/* not initialized yet? */
 Grant> -	if (!port->membase)
 Grant> +	if (!port->membase) {
 Grant> +		pr_debug("console on ttyUL%i not initialized\n", co->index);
 Grant>  		return -ENODEV;
 Grant> +	}

Unrelated change.
 
 Grant>  	if (options)
 Grant>  		uart_parse_options(options, &baud, &parity, &bits, &flow);
 Grant> @@ -542,6 +549,72 @@ static struct platform_driver ulite_platform_driver = {
 Grant>  };
 
 Grant>  /* ---------------------------------------------------------------------
 Grant> + * OF bus bindings
 Grant> + */
 Grant> +#if defined(CONFIG_OF)
 Grant> +static int __devinit
 Grant> +ulite_of_probe(struct of_device *op, const struct of_device_id *match)
 Grant> +{
 Grant> +	struct resource res;
 Grant> +	const unsigned int *id;
 Grant> +	int irq, rc;
 Grant> +
 Grant> +	dev_dbg(&op->dev, "%s(%p, %p)\n", __FUNCTION__, op, match);
 Grant> +
 Grant> +	rc = of_address_to_resource(op->node, 0, &res);
 Grant> +	if (rc) {
 Grant> +		dev_err(&op->dev, "invalide address\n");
 Grant> +		return rc;
 Grant> +	}
 Grant> +
 Grant> +	irq = irq_of_parse_and_map(op->node, 0);
 Grant> +
 Grant> +	id = of_get_property(op->node, "port-number", NULL);
 Grant> +
 Grant> +	return ulite_assign(&op->dev, id ? *id : -1, res.start, irq);
 Grant> +}
 Grant> +
 Grant> +static int ulite_of_remove(struct of_device *op)
 Grant> +{
 Grant> +	return ulite_release(&op->dev);
 Grant> +}
 Grant> +
 Grant> +/* Match table for of_platform binding */
 Grant> +static struct of_device_id __devinit ulite_of_match[] = {
 Grant> +	{ .type = "serial", .compatible = "xilinx,uartlite", },
 Grant> +	{},
 Grant> +};
 Grant> +MODULE_DEVICE_TABLE(of, ulite_of_match);
 Grant> +
 Grant> +static struct of_platform_driver ulite_of_driver = {
 Grant> +	.owner = THIS_MODULE,
 Grant> +	.name = "uartlite",
 Grant> +	.match_table = ulite_of_match,
 Grant> +	.probe = ulite_of_probe,
 Grant> +	.remove = ulite_of_remove,
 Grant> +	.driver = {
 Grant> +		.name = "uartlite",
 Grant> +	},
 Grant> +};
 Grant> +
 Grant> +/* Registration helpers to keep the number of #ifdefs to a minimum */
 Grant> +static inline int __init ulite_of_register(void)
 Grant> +{
 Grant> +	pr_debug("uartlite: calling of_register_platform_driver()\n");
 Grant> +	return of_register_platform_driver(&ulite_of_driver);
 Grant> +}
 Grant> +
 Grant> +static inline void __init ulite_of_unregister(void)
 Grant> +{
 Grant> +	of_unregister_platform_driver(&ulite_of_driver);
 Grant> +}
 Grant> +#else /* CONFIG_OF */
 Grant> +/* CONFIG_OF not enabled; do nothing helpers */
 Grant> +static inline int __init ulite_of_register(void) { return 0; }
 Grant> +static inline void __init ulite_of_unregister(void) { }
 Grant> +#endif /* CONFIG_OF */
 Grant> +
 Grant> +/* ---------------------------------------------------------------------
 Grant>   * Module setup/teardown
 Grant>   */
 
 Grant> @@ -549,20 +622,32 @@ int __init ulite_init(void)
 Grant>  {
 Grant>  	int ret;
 
 Grant> -	ret = uart_register_driver(&ulite_uart_driver);
 Grant> -	if (ret)
 Grant> -		return ret;
 Grant> +	pr_debug("uartlite: calling uart_register_driver()\n");
 Grant> +	if ((ret = uart_register_driver(&ulite_uart_driver)) != 0)
 Grant> +		goto err_uart;
 
 Grant> -	ret = platform_driver_register(&ulite_platform_driver);
 Grant> -	if (ret)
 Grant> -		uart_unregister_driver(&ulite_uart_driver);
 Grant> +	if ((ret = ulite_of_register()) != 0)
 Grant> +		goto err_of;
 
 Grant> +	pr_debug("uartlite: calling platform_driver_register()\n");
 Grant> +	if ((ret = platform_driver_register(&ulite_platform_driver)) != 0)

I prefer to not have assignments in the if ().
Are all the pr_debug necessary? It looks quite messy.

 Grant> +		goto err_plat;
 Grant> +

 Grant> +	return 0;
 Grant> +
 Grant> +err_plat:
 Grant> +	ulite_of_unregister();
 Grant> +err_of:
 Grant> +	uart_unregister_driver(&ulite_uart_driver);
 Grant> +err_uart:
 Grant> +	printk(KERN_ERR "registering uartlite driver failed: err=%i", ret);
 Grant>  	return ret;
 Grant>  }
 
 Grant>  void __exit ulite_exit(void)
 Grant>  {
 Grant>  	platform_driver_unregister(&ulite_platform_driver);
 Grant> +	ulite_of_unregister();
 Grant>  	uart_unregister_driver(&ulite_uart_driver);
 Grant>  }
 


-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: [RFC PATCH v0.2] net driver: mpc52xx fec
From: Robert Schwebel @ 2007-10-02 15:46 UTC (permalink / raw)
  To: Domen Puncer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20071002143202.GQ32628@nd47.coderock.org>

On Tue, Oct 02, 2007 at 04:32:02PM +0200, Domen Puncer wrote:
> The patch looks ok to me.

Short update: even with the patch, the driver doesn't work on an
rt-preempt enabled kernel, or at least not reliable. It survives normal
traffic and ping -f, but dies when running nmap against the box, with a
set RFIFO_ERROR flag.

More research needs to be done.

Robert
-- 
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de

^ permalink raw reply

* Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)
From: Peter Korsgaard @ 2007-10-02 15:40 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070928181704.18608.40317.stgit@trillian.cg.shawcable.net>

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

 Grant> From: Grant Likely <grant.likely@secretlab.ca>
 Grant> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
 Grant> Acked-by: John Williams <jwilliams@itee.uq.edu.au>

Huh? This seems a bit confused. Microblaze is big endian and out_be32
is only defined in arch/p{,ower}pc.

This has been discussed before. The logical registers are 8bit, but
the OPB implementation (by virtue of it being a 32bit bus) uses
32bit spacing between the registers.

The fact is that the only portable access to non-pci registers in the
kernel is 8 bit.

The uartlite driver is ofcause primarily used to drive Xilinx
OPB_Uartlite IP blocks, but that's not the only use - E.G. we are
using another simple UART with the same hardware interface but sitting
on a 16bit bus. With the current driver this works fine, but won't
with the out_be32.

For a new design wi'll use an AT91 (arm). I don't see any reason why
we shouldn't be able to use the same UART block there.

 Grant> ---

 Grant>  arch/ppc/syslib/virtex_devices.c |    2 +-
 Grant>  drivers/serial/uartlite.c        |   32 ++++++++++++++++----------------
 Grant>  2 files changed, 17 insertions(+), 17 deletions(-)

 Grant> diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
 Grant> index ace4ec0..270ad3a 100644
 Grant> --- a/arch/ppc/syslib/virtex_devices.c
 Grant> +++ b/arch/ppc/syslib/virtex_devices.c
 Grant> @@ -28,7 +28,7 @@
 Grant>  	.num_resources = 2, \
 Grant>  	.resource = (struct resource[]) { \
 Grant>  		{ \
 Grant> -			.start = XPAR_UARTLITE_##num##_BASEADDR + 3, \
 Grant> +			.start = XPAR_UARTLITE_##num##_BASEADDR, \
 Grant>  			.end = XPAR_UARTLITE_##num##_HIGHADDR, \
 Grant>  			.flags = IORESOURCE_MEM, \
 Grant>  		}, \
 Grant> diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
 Grant> index f5051cf..59b674a 100644
 Grant> --- a/drivers/serial/uartlite.c
 Grant> +++ b/drivers/serial/uartlite.c
 Grant> @@ -61,7 +61,7 @@ static int ulite_receive(struct uart_port *port, int stat)
 Grant>  	/* stats */
 Grant>  	if (stat & ULITE_STATUS_RXVALID) {
 port-> icount.rx++;
 Grant> -		ch = readb(port->membase + ULITE_RX);
 Grant> +		ch = in_be32((void*)port->membase + ULITE_RX);
 
 Grant>  		if (stat & ULITE_STATUS_PARITY)
 port-> icount.parity++;
 Grant> @@ -106,7 +106,7 @@ static int ulite_transmit(struct uart_port *port, int stat)
 Grant>  		return 0;
 
 Grant>  	if (port->x_char) {
 Grant> -		writeb(port->x_char, port->membase + ULITE_TX);
 Grant> +		out_be32((void*)port->membase + ULITE_TX, port->x_char);
 port-> x_char = 0;
 port-> icount.tx++;
 Grant>  		return 1;
 Grant> @@ -115,7 +115,7 @@ static int ulite_transmit(struct uart_port *port, int stat)
 Grant>  	if (uart_circ_empty(xmit) || uart_tx_stopped(port))
 Grant>  		return 0;
 
 Grant> -	writeb(xmit->buf[xmit->tail], port->membase + ULITE_TX);
 Grant> +	out_be32((void*)port->membase + ULITE_TX, xmit->buf[xmit->tail]);
 xmit-> tail = (xmit->tail + 1) & (UART_XMIT_SIZE-1);
 port-> icount.tx++;
 
 Grant> @@ -132,7 +132,7 @@ static irqreturn_t ulite_isr(int irq, void *dev_id)
 Grant>  	int busy;
 
 Grant>  	do {
 Grant> -		int stat = readb(port->membase + ULITE_STATUS);
 Grant> +		int stat = in_be32((void*)port->membase + ULITE_STATUS);
 Grant>  		busy  = ulite_receive(port, stat);
 Grant>  		busy |= ulite_transmit(port, stat);
 Grant>  	} while (busy);
 Grant> @@ -148,7 +148,7 @@ static unsigned int ulite_tx_empty(struct uart_port *port)
 Grant>  	unsigned int ret;
 
 Grant>  	spin_lock_irqsave(&port->lock, flags);
 Grant> -	ret = readb(port->membase + ULITE_STATUS);
 Grant> +	ret = in_be32((void*)port->membase + ULITE_STATUS);
 Grant>  	spin_unlock_irqrestore(&port->lock, flags);
 
 Grant>  	return ret & ULITE_STATUS_TXEMPTY ? TIOCSER_TEMT : 0;
 Grant> @@ -171,7 +171,7 @@ static void ulite_stop_tx(struct uart_port *port)
 
 Grant>  static void ulite_start_tx(struct uart_port *port)
 Grant>  {
 Grant> -	ulite_transmit(port, readb(port->membase + ULITE_STATUS));
 Grant> +	ulite_transmit(port, in_be32((void*)port->membase + ULITE_STATUS));
 Grant>  }
 
 Grant>  static void ulite_stop_rx(struct uart_port *port)
 Grant> @@ -200,17 +200,17 @@ static int ulite_startup(struct uart_port *port)
 Grant>  	if (ret)
 Grant>  		return ret;
 
 Grant> -	writeb(ULITE_CONTROL_RST_RX | ULITE_CONTROL_RST_TX,
 Grant> -	       port->membase + ULITE_CONTROL);
 Grant> -	writeb(ULITE_CONTROL_IE, port->membase + ULITE_CONTROL);
 Grant> +	out_be32((void*)port->membase + ULITE_CONTROL,
 Grant> +	         ULITE_CONTROL_RST_RX | ULITE_CONTROL_RST_TX);
 Grant> +	out_be32((void*)port->membase + ULITE_CONTROL, ULITE_CONTROL_IE);
 
 Grant>  	return 0;
 Grant>  }
 
 Grant>  static void ulite_shutdown(struct uart_port *port)
 Grant>  {
 Grant> -	writeb(0, port->membase + ULITE_CONTROL);
 Grant> -	readb(port->membase + ULITE_CONTROL); /* dummy */
 Grant> +	out_be32((void*)port->membase + ULITE_CONTROL, 0);
 Grant> +	in_be32((void*)port->membase + ULITE_CONTROL); /* dummy */
 Grant>  	free_irq(port->irq, port);
 Grant>  }
 
 Grant> @@ -314,7 +314,7 @@ static void ulite_console_wait_tx(struct uart_port *port)
 
 Grant>  	/* wait up to 10ms for the character(s) to be sent */
 Grant>  	for (i = 0; i < 10000; i++) {
 Grant> -		if (readb(port->membase + ULITE_STATUS) & ULITE_STATUS_TXEMPTY)
 Grant> +		if (in_be32((void*)port->membase + ULITE_STATUS) & ULITE_STATUS_TXEMPTY)
 Grant>  			break;
 Grant>  		udelay(1);
 Grant>  	}
 Grant> @@ -323,7 +323,7 @@ static void ulite_console_wait_tx(struct uart_port *port)
 Grant>  static void ulite_console_putchar(struct uart_port *port, int ch)
 Grant>  {
 Grant>  	ulite_console_wait_tx(port);
 Grant> -	writeb(ch, port->membase + ULITE_TX);
 Grant> +	out_be32((void*)port->membase + ULITE_TX, ch);
 Grant>  }
 
 Grant>  static void ulite_console_write(struct console *co, const char *s,
 Grant> @@ -340,8 +340,8 @@ static void ulite_console_write(struct console *co, const char *s,
 Grant>  		spin_lock_irqsave(&port->lock, flags);
 
 Grant>  	/* save and disable interrupt */
 Grant> -	ier = readb(port->membase + ULITE_STATUS) & ULITE_STATUS_IE;
 Grant> -	writeb(0, port->membase + ULITE_CONTROL);
 Grant> +	ier = in_be32((void*)port->membase + ULITE_STATUS) & ULITE_STATUS_IE;
 Grant> +	out_be32((void*)port->membase + ULITE_CONTROL, 0);
 
 Grant>  	uart_console_write(port, s, count, ulite_console_putchar);
 
 Grant> @@ -349,7 +349,7 @@ static void ulite_console_write(struct console *co, const char *s,
 
 Grant>  	/* restore interrupt state */
 Grant>  	if (ier)
 Grant> -		writeb(ULITE_CONTROL_IE, port->membase + ULITE_CONTROL);
 Grant> +		out_be32((void*)port->membase + ULITE_CONTROL, ULITE_CONTROL_IE);
 
 Grant>  	if (locked)
 Grant>  		spin_unlock_irqrestore(&port->lock, flags);


-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: [PATCH 08/18] Uartlite: Add macro for uartlite device name
From: Grant Likely @ 2007-10-02 15:34 UTC (permalink / raw)
  To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87ejgd356y.fsf@macbook.be.48ers.dk>

On 10/2/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
>
> Hi,
>
>  Grant> From: Grant Likely <grant.likely@secretlab.ca>
>  Grant> Changed to make the OF bus binding a wee bit cleaner
>
>  Grant> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>  Grant> ---
>
>  Grant>  arch/powerpc/platforms/40x/Kconfig |    4 ++--
>  Grant>  drivers/serial/uartlite.c          |    5 +++--
>  Grant>  2 files changed, 5 insertions(+), 4 deletions(-)
>
>  Grant> diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
>  Grant> index 1aae0e6..44f08dd 100644
>  Grant> --- a/arch/powerpc/platforms/40x/Kconfig
>  Grant> +++ b/arch/powerpc/platforms/40x/Kconfig
>  Grant> @@ -65,8 +65,8 @@ config XILINX_VIRTEX_GENERIC_BOARD
>  Grant>         bool "Generic Xilinx Virtex board"
>  Grant>         depends on 40x
>  Grant>         default y
>  Grant> -       select VIRTEX_II_PRO
>  Grant> -       select VIRTEX_4_FX
>  Grant> +       select XILINX_VIRTEX_II_PRO
>  Grant> +       select XILINX_VIRTEX_4_FX
>
> Huh? What does this have to do with $SUBJ?

This was a mess up on my part on this version of the patch set.  v3
has it fixed.

g.

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

^ permalink raw reply

* Re: [PATCH 08/18] Uartlite: Add macro for uartlite device name
From: Peter Korsgaard @ 2007-10-02 15:29 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070928181726.18608.73695.stgit@trillian.cg.shawcable.net>

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

Hi,

 Grant> From: Grant Likely <grant.likely@secretlab.ca>
 Grant> Changed to make the OF bus binding a wee bit cleaner

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

 Grant>  arch/powerpc/platforms/40x/Kconfig |    4 ++--
 Grant>  drivers/serial/uartlite.c          |    5 +++--
 Grant>  2 files changed, 5 insertions(+), 4 deletions(-)

 Grant> diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
 Grant> index 1aae0e6..44f08dd 100644
 Grant> --- a/arch/powerpc/platforms/40x/Kconfig
 Grant> +++ b/arch/powerpc/platforms/40x/Kconfig
 Grant> @@ -65,8 +65,8 @@ config XILINX_VIRTEX_GENERIC_BOARD
 Grant>  	bool "Generic Xilinx Virtex board"
 Grant>  	depends on 40x
 Grant>  	default y
 Grant> -	select VIRTEX_II_PRO
 Grant> -	select VIRTEX_4_FX
 Grant> +	select XILINX_VIRTEX_II_PRO
 Grant> +	select XILINX_VIRTEX_4_FX

Huh? What does this have to do with $SUBJ?

 Grant>  	help
 Grant>  	  This option enables generic support for Xilinx Virtex based boards.
 
 Grant> diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
 Grant> index ae05a67..10e0da9 100644
 Grant> --- a/drivers/serial/uartlite.c
 Grant> +++ b/drivers/serial/uartlite.c
 Grant> @@ -18,6 +18,7 @@
 Grant>  #include <linux/interrupt.h>
 Grant>  #include <asm/io.h>
 
 Grant> +#define ULITE_NAME		"ttyUL"
 Grant>  #define ULITE_MAJOR		204
 Grant>  #define ULITE_MINOR		187
 Grant>  #define ULITE_NR_UARTS		4

Otherwise Acked-by: Peter Korsgaard <jacmet@sunsite.dk>

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: [PATCH 07/18] Uartlite: change name of ports to ulite_ports
From: Peter Korsgaard @ 2007-10-02 15:27 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070928181718.18608.60984.stgit@trillian.cg.shawcable.net>

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

 Grant> From: Grant Likely <grant.likely@secretlab.ca>
 Grant> Changed to match naming convention used in the rest of the module

Ok.

Acked-by: Peter Korsgaard <jacmet@sunsite.dk>

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: [PATCH 05/18] Add PowerPC Xilinx Virtex entry to maintainers
From: Peter Korsgaard @ 2007-10-02 15:26 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070928181627.18608.29878.stgit@trillian.cg.shawcable.net>

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

Hi,
 
 Grant> +LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
 Grant> +P:	Grant Likely
 Grant> +M:	grant.likely@secretlab.ca
 Grant> +W:	http://www.secretlab.ca/

That page doesn't have any Xilinx info. What about 
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex instead?

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: [PATCH 10/18] Uartlite: improve in-code comments
From: Peter Korsgaard @ 2007-10-02 15:24 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070928181740.18608.67126.stgit@trillian.cg.shawcable.net>

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

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

Fine by me.

Acked-by: Peter Korsgaard <jacmet@sunsite.dk>

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: [PATCH 01/18] Virtex: Add uartlite bootwrapper driver
From: Grant Likely @ 2007-10-02 15:12 UTC (permalink / raw)
  To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87ve9p36d8.fsf@macbook.be.48ers.dk>

On 10/2/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
>
> Hi,
>
>  Grant> +static int uartlite_open(void)
>  Grant> +{
>  Grant> +       /* Clear the RX FIFO */
>  Grant> +       out_be32(reg_base + 0x0C, 0x2);
>  Grant> +       return 0;
>  Grant> +}
>  Grant> +
>  Grant> +static void uartlite_putc(unsigned char c)
>  Grant> +{
>  Grant> +       while ((in_be32(reg_base + 0x8) & 0x08) != 0); /* spin */
>  Grant> +       out_be32(reg_base + 0x4, c);
>
> RX, TX, STATUS and CONTROL defines for the registers would be nice for
> readability.

Good idea, I'll add a patch for that

g.


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

^ permalink raw reply

* Re: [PATCH 01/18] Virtex: Add uartlite bootwrapper driver
From: Peter Korsgaard @ 2007-10-02 15:04 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070928181551.18608.88418.stgit@trillian.cg.shawcable.net>

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

Hi,

 Grant> +static int uartlite_open(void)
 Grant> +{
 Grant> +	/* Clear the RX FIFO */
 Grant> +	out_be32(reg_base + 0x0C, 0x2);
 Grant> +	return 0;
 Grant> +}
 Grant> +
 Grant> +static void uartlite_putc(unsigned char c)
 Grant> +{
 Grant> +	while ((in_be32(reg_base + 0x8) & 0x08) != 0); /* spin */
 Grant> +	out_be32(reg_base + 0x4, c);

RX, TX, STATUS and CONTROL defines for the registers would be nice for
readability.

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Timur Tabi @ 2007-10-02 14:49 UTC (permalink / raw)
  To: Kumar Gala; +Cc: PowerPC dev list
In-Reply-To: <AD243886-65DE-4285-ADD3-1D4C5ABA2E3C@kernel.crashing.org>

Kumar Gala wrote:
> 
> On Oct 1, 2007, at 11:10 AM, Scott Wood wrote:
> 
>> Kumar Gala wrote:
>>> On Sep 29, 2007, at 1:49 AM, Vitaly Bordug wrote:
>>>> cpms have dpram, qe has muram. these two are the same stuff in fact. 
>>>> Or you are asking about have QE stuff utilize such a binding at the 
>>>> same pass?
>>> I was asking about both these things.
>>
>> As stated in the commit message, QE can use this; it just needs a 
>> compatible entry in the data node.
> 
> can some one look at that.

Scott's proposal says this:

muram@0 {
	#address-cells = <1>;
	#size-cells = <1>;
	ranges = <0 0 10000>;

	data@0 {
		compatible = "fsl,cpm-muram-data";
		reg = <0 2000 9800 800>;
	};

Currently, the QE has this:

muram@10000 {
	device_type = "muram";
	ranges = <0 00010000 0000c000>;

	data-only@0{
		reg = <0 c000>;
	};
};

The code to process this node is qe_muram_init() in 
arch/powerpc/sysdev/qe_lib/qe.c.

	if ((np = of_find_node_by_name(NULL, "data-only")) != NULL) {
		address = *of_get_address(np, 0, &size, &flags);
		of_node_put(np);
		rh_attach_region(&qe_muram_info,
			(void *)address, (int)size);
	}

I think it would be trivial to modify this code to look for a Scott-style 
muram node.  Heck, it could be modified to look for both, and so we'll 
maintain compatibility.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

^ permalink raw reply

* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Kumar Gala @ 2007-10-02 14:43 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070928190616.GB20213@loki.buserror.net>


On Sep 28, 2007, at 2:06 PM, Scott Wood wrote:

> The way the current CPM binding describes available multi-user (a.k.a.
> dual-ported) RAM doesn't work well when there are multiple free  
> regions,
> and it doesn't work at all if the region doesn't begin at the start of
> the muram area (as the hardware needs to be programmed with offsets  
> into
> this area).  The latter situation can happen with SMC UARTs on  
> CPM2, as its
> parameter RAM is relocatable, u-boot puts it at zero, and the  
> kernel doesn't
> support moving it.
>
> It is now described with a muram node, similar to QE.  The current CPM
> binding is sufficiently recent (i.e. never appeared in an official  
> release)
> that compatibility with existing device trees is not an issue.
>
> The code supporting the new binding is shared between cpm1 and  
> cpm2, rather
> than remain separated.  QE should be able to use this code as well,  
> once
> minor fixes are made to its device trees.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>

applied.

- k

^ permalink raw reply

* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Kumar Gala @ 2007-10-02 14:43 UTC (permalink / raw)
  To: Scott Wood; +Cc: Timur Tabi, PowerPC dev list
In-Reply-To: <47011BED.8020206@freescale.com>


On Oct 1, 2007, at 11:10 AM, Scott Wood wrote:

> Kumar Gala wrote:
>> On Sep 29, 2007, at 1:49 AM, Vitaly Bordug wrote:
>>> cpms have dpram, qe has muram. these two are the same stuff in  
>>> fact. Or you are asking about have QE stuff utilize such a  
>>> binding at the same pass?
>> I was asking about both these things.
>
> As stated in the commit message, QE can use this; it just needs a  
> compatible entry in the data node.

can some one look at that.

- k

^ permalink raw reply

* Re: [RFC PATCH v0.2] net driver: mpc52xx fec
From: Domen Puncer @ 2007-10-02 14:32 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20071002124939.GC10481@pengutronix.de>

On 02/10/07 14:49 +0200, Sascha Hauer wrote:
> 
> Hi Domen,

Hi Sascha!


> 
> On Sun, Sep 02, 2007 at 09:41:43AM +0200, Domen Puncer wrote:
>  + */
> > +static void fec_start(struct net_device *dev)
> > +{
> > +	struct fec_priv *priv = netdev_priv(dev);
> > +	struct mpc52xx_fec __iomem *fec = priv->fec;
> > +	u32 rcntrl;
> > +	u32 tcntrl;
> > +	u32 tmp;
> > +
> > +	/* clear sticky error bits */
> > +	tmp = FEC_FIFO_STATUS_ERR | FEC_FIFO_STATUS_UF | FEC_FIFO_STATUS_OF;
> > +	out_be32(&fec->rfifo_status, in_be32(&fec->rfifo_status) & tmp);
> > +	out_be32(&fec->tfifo_status, in_be32(&fec->tfifo_status) & tmp);
> > +
> > +	/* FIFOs will reset on fec_enable */
> > +	out_be32(&fec->reset_cntrl, FEC_RESET_CNTRL_ENABLE_IS_RESET);
> > +
> > +	/* Set station address. */
> > +	fec_set_paddr(dev, dev->dev_addr);
> > +
> > +	fec_set_multicast_list(dev);
> > +
> > +	/* set max frame len, enable flow control, select mii mode */
> > +	rcntrl = FEC_RX_BUFFER_SIZE << 16;	/* max frame length */
> > +	rcntrl |= FEC_RCNTRL_FCE;
> > +	rcntrl |= MII_RCNTL_MODE;
> > +	if (priv->duplex == DUPLEX_FULL)
> > +		tcntrl = FEC_TCNTRL_FDEN;	/* FD enable */
> > +	else {
> > +		rcntrl |= FEC_RCNTRL_DRT;	/* disable Rx on Tx (HD) */
> > +		tcntrl = 0;
> > +	}
> > +	out_be32(&fec->r_cntrl, rcntrl);
> > +	out_be32(&fec->x_cntrl, tcntrl);
> > +
> > +	/* Clear any outstanding interrupt. */
> > +	out_be32(&fec->ievent, 0xffffffff);
> > +
> > +	/* Enable interrupts we wish to service. */
> > +	out_be32(&fec->imask, FEC_IMASK_ENABLE);
> 
> 
> This disables phy interrupts.

Right, oops.

> 
> 
> > +static int fec_mdio_read(struct mii_bus *bus, int phy_id, int reg)
> > +{
> > +	struct fec_mdio_priv *priv = bus->priv;
> > +	int tries = 100;
> > +
> > +	u32 request = FEC_MII_READ_FRAME;
> > +	request |= (phy_id << FEC_MII_DATA_PA_SHIFT) & FEC_MII_DATA_PA_MSK;
> > +	request |= (reg << FEC_MII_DATA_RA_SHIFT) & FEC_MII_DATA_RA_MSK;
> > +
> > +	out_be32(&priv->regs->mii_data, request);
> > +
> > +	/* wait for it to finish, this takes about 23 us on lite5200b */
> > +	while (priv->completed == 0 && tries--)
> > +		udelay(5);
> > +
> > +	priv->completed = 0;
> > +
> > +	if (tries == 0)
> > +		return -ETIMEDOUT;
> 
> This does not work as expected. When a timeout occurs tries is -1 not 0,
> so the test above will never trigger.
> Using --tries instead of tries-- reveals another bug. We get a timeout
> everytime now, because MII interrupts are accidently disabled in
> fec_start().

Oh, double bug made it work! ;-)


> 
> We cannot use a waitqueue or similar for waiting for the mii transfer
> because we are atomic here.
> A simple fix is provided below. It removes the need for the interrupt
> handler in the phy handling routines. Anyway, it might be better to fix
> the phy layer not to use atomic contexts, so this patch might not be the
> way to go.

Doh, looks like this was the problem with wq's, but I forgot to remove
them, when I "fixed" the code.

> 
> 
> Regards, 
>   Sascha
> 
>  +
> > +static int fec_mdio_probe(struct of_device *of, const struct of_device_id *match)
> > +{
> > +	struct device *dev = &of->dev;
> >
> >       [...]
> >
> > +	init_waitqueue_head(&priv->wq);
> 
> This waitqueue is never used. wake_up() is called in the interrupt
> handler, but noone ever sleeps on the queue.
> 
> 
> ---
>  drivers/net/fec_mpc52xx/fec.c     |    7 +---
>  drivers/net/fec_mpc52xx/fec_phy.c |   59 +++++++-------------------------------
>  2 files changed, 15 insertions(+), 51 deletions(-)

The patch looks ok to me.


	Domen

^ permalink raw reply

* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Grant Likely @ 2007-10-02 14:26 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191304386.6310.92.camel@pasglop>

On 10/1/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-09-30 at 16:42 -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Add of_platform bus binding so this driver can be used with arch/powerpc
>
> Another option is to have a "constructor" in the platform code that
> generates the platform device from the DT. It might even become the
> preferred way one of these days, I'm not too sure at this stage. Anyway,
> do what you prefer.

I've looked at both, and I'm not to fond of the 'constructor'
approach.  Here are my reasons:

- Separate constructor code must be written for each driver anyway
(except perhaps for very simple cases which only require 'regs' and
'interrupts' properties).  The device tree data must then be mapped
onto a pdata structure; which the driver immediately turns around and
unmaps from pdata to populate it's driver state structure.  It ends up
being a lot of indirection to follow.
- Many (but perhaps not all) of these devices will be registered as an
of_device anyway.  By having a constructor to generate a
platform_device from that means each device will get probed twice;
once by the of_platform bus and once by the platform bus.
- Writing device drivers with multiple binding is easy and probable
results in smaller simpler code than the two step process of using a
constructor.

For example, here is my of_device binding for the systemace driver:

static int __devinit
ulite_of_probe(struct of_device *op, const struct of_device_id *match)
{
        struct resource res;
        const unsigned int *id;
        int irq, rc;
        dev_dbg(&op->dev, "%s(%p, %p)\n", __FUNCTION__, op, match);
        rc = of_address_to_resource(op->node, 0, &res);
        if (rc) {
                dev_err(&op->dev, "invalide address\n");
                return rc;
        }
        irq = irq_of_parse_and_map(op->node, 0);
        id = of_get_property(op->node, "port-number", NULL);
        return ulite_assign(&op->dev, id ? *id : -1, res.start, irq);
}

That's 3 calls to get data out of the device tree and one call to
setup the device.  The final 'ulite_assign()' call is called by both
the of_device and platform_device bindings.

To do the same thing with a constructor requires an additional
allocation and registration of a platform device structure and a pdata
structure.  Plus it requires the platform code to explicitly call a
set of helper functions to find and create platform devices for nodes
in the device tree.  (Unless you're thinking about leveraging the
of_platform probe code and have the .probe hook to the 'constructor'
bit)

What advantages do you see with the constructor approach?

Cheers,
g.

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

^ permalink raw reply

* Re: [PATCH v2 5/6] Sysace: Move IRQ handler registration to occur after FSM is initialized
From: Grant Likely @ 2007-10-02 13:57 UTC (permalink / raw)
  To: benh; +Cc: axboe, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <1191304521.6310.94.camel@pasglop>

On 10/1/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-09-30 at 16:57 -0600, Grant Likely wrote:
> >         val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
> >         ace_out(ace, ACE_CTRL, val);
> >
> > +       /* Now we can hook up the irq handler */
> > +       if (ace->irq != NO_IRQ) {
> > +               rc = request_irq(ace->irq, ace_interrupt, 0,
> > "systemace", ace);
> > +               if (rc) {
> > +                       /* Failure - fall back to polled mode */
> > +                       dev_err(ace->dev, "request_irq failed\n");
> > +                       ace->irq = NO_IRQ;
> > +               }
> > +       }
> > +
>
> I don't know the HW but from the above, it looks like you enable
> interrupt emission on the HW before you register the handler, which is
> wrong. You should make sure on the contrary that IRQs on the HW are
> disabled until after you have registered a handler.
>
> Only really a problem if you have shared interrupts but still...

Yeah, you're right.  Fortunately all current in-tree platforms which
use this do not have shared interrupts, but I'd like to be correct on
this.

I'll tidy this up and send a fixup patch.

Thanks,
g.

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

^ permalink raw reply

* Re: [PATCH v2 2/6] Sysace: Use the established platform bus api
From: Grant Likely @ 2007-10-02 13:52 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Christoph Hellwig, paulus, linux-kernel, linuxppc-dev
In-Reply-To: <20071002063523.GM5303@kernel.dk>

On 10/2/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Oct 02 2007, Benjamin Herrenschmidt wrote:
> >
> > On Mon, 2007-10-01 at 13:59 +0200, Jens Axboe wrote:
> > > Just send a fixup patch for that, I'll add your series to the block tree
> > > for 2.6.24.
> >
> > It's actually better off living in the powerpc tree I think as it's
> > really about adding support for a new powerpc platform and somewhat
> > needs to sync with other things in there. Unless you really want the
> > whole thing in your tree :-)
>
> I already included it yesterday, it'll go up once 2.6.24 opens. Let me
> know if you want me to rip it out, though.

No, it's safe.  Nothing will break if one goes in before the other.
Please keep it in.

g.

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

^ permalink raw reply

* [PATCH 3/3] [POWERPC] mpc8568mds.dts: fix PCIe I/O address space location and size
From: Anton Vorontsov @ 2007-10-02 13:48 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <20071002134535.GA17913@localhost.localdomain>

According to u-boot/board/mpc8568mds/init.S:

LAW(Local Access Window) configuration:
2)   0xa000_0000   0xbfff_ffff     PCIe MEM                512MB
4)   0xe280_0000   0xe2ff_ffff     PCIe I/O                8M

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 arch/powerpc/boot/dts/mpc8568mds.dts |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index a177dd0..39ec3c2 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -226,8 +226,8 @@
 			interrupt-parent = <&mpic>;
 			interrupts = <1a 2>;
 			bus-range = <0 ff>;
-			ranges = <02000000 0 a0000000 a0000000 0 20000000
-				  01000000 0 00000000 e3000000 0 08000000>;
+			ranges = <02000000 0 a0000000 a0000000 0 10000000
+				  01000000 0 00000000 e2800000 0 00800000>;
 			clock-frequency = <1fca055>;
 			#interrupt-cells = <1>;
 			#size-cells = <2>;
-- 
1.5.0.6

^ permalink raw reply related

* [PATCH 2/3] [POWERPC] MPC8568E-MDS: add support for ds1374 rtc
From: Anton Vorontsov @ 2007-10-02 13:47 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <20071002134535.GA17913@localhost.localdomain>

MPC8568E-MDS have DS1374 chip on the I2C bus, thus let's use it.
This patch also adds #address-cells and #size-cells to the I2C
controllers nodes.

p.s. DS1374 rtc class driver is in the -mm tree, its name is
rtc-rtc-class-driver-for-the-ds1374.patch.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 arch/powerpc/boot/dts/mpc8568mds.dts |    9 +++++++++
 arch/powerpc/sysdev/fsl_soc.c        |    1 +
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 1d082fb..a177dd0 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -72,15 +72,24 @@
 		};
 
 		i2c@3000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
 			device_type = "i2c";
 			compatible = "fsl-i2c";
 			reg = <3000 100>;
 			interrupts = <2b 2>;
 			interrupt-parent = <&mpic>;
 			dfsrr;
+
+			rtc@68 {
+				compatible = "dallas,ds1374";
+				reg = <68>;
+			};
 		};
 
 		i2c@3100 {
+			#address-cells = <1>;
+			#size-cells = <0>;
 			device_type = "i2c";
 			compatible = "fsl-i2c";
 			reg = <3100 100>;
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 91987e0..c765d7a 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -337,6 +337,7 @@ static struct i2c_driver_device i2c_devices[] __initdata = {
 	{"dallas,ds1339",  "rtc-ds1307",  "ds1339",},
 	{"dallas,ds1340",  "rtc-ds1307",  "ds1340",},
 	{"stm,m41t00",     "rtc-ds1307",  "m41t00"},
+	{"dallas,ds1374",  "rtc-ds1374",  "rtc-ds1374",},
 };
 
 static int __init of_find_i2c_driver(struct device_node *node,
-- 
1.5.0.6

^ permalink raw reply related

* [PATCH 1/3] [POWERPC] fsl_soc: fix uninitialized i2c_board_info structure
From: Anton Vorontsov @ 2007-10-02 13:47 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <20071002134535.GA17913@localhost.localdomain>

i2c_board_info used semi-initialized, causing garbage in the
info->flags, and that, in turn, causes various symptoms of i2c
malfunctioning, like PEC mismatches.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 arch/powerpc/sysdev/fsl_soc.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 4a16456..91987e0 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -363,7 +363,7 @@ static void __init of_register_i2c_devices(struct device_node *adap_node,
 	struct device_node *node = NULL;
 
 	while ((node = of_get_next_child(adap_node, node))) {
-		struct i2c_board_info info;
+		struct i2c_board_info info = {};
 		const u32 *addr;
 		int len;
 
@@ -380,7 +380,6 @@ static void __init of_register_i2c_devices(struct device_node *adap_node,
 		if (of_find_i2c_driver(node, &info) < 0)
 			continue;
 
-		info.platform_data = NULL;
 		info.addr = *addr;
 
 		i2c_register_board_info(bus_num, &info, 1);
-- 
1.5.0.6

^ permalink raw reply related

* [PATCH 0/3] Few more mpc8568mds and fsl_soc related patches
From: Anton Vorontsov @ 2007-10-02 13:45 UTC (permalink / raw)
  To: linuxppc-dev

Hi all,

These patches needed to support PCIe and RTC on the MPC8568E-MDS board.
They're against galak/powerpc.git master branch.

Thanks,

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

^ permalink raw reply

* Please pull from 'for-2.6.24' branch of 4xx tree
From: Josh Boyer @ 2007-10-02 12:54 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev

Hi Paul,

Please pull from

 master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24

to pick up a handful of new items for 2.6.24.  Initial Virtex support
from Grant, some cpu setup functions for 4xx from Valentine, a compile
fix for the Walnut wrapper, and a small number of arch/ppc fixes for
Xilinx boards.

Grant Likely (15):
      [POWERPC] Virtex: Add uartlite bootwrapper driver
      [POWERPC] Virtex: Add Kconfig macros for Xilinx Virtex board support
      [POWERPC] Virtex: add xilinx interrupt controller driver
      [POWERPC] Virtex: Add generic Xilinx Virtex board support
      [POWERPC] Add PowerPC Xilinx Virtex entry to maintainers
      [POWERPC] Uartlite: Fix reg io to access documented register size
      [POWERPC] Uartlite: change name of ports to ulite_ports
      [POWERPC] Uartlite: Add macro for uartlite device name
      [POWERPC] Uartlite: Separate the bus binding from the driver proper
      [POWERPC] Uartlite: Comment block tidy
      [POWERPC] Uartlite: Add of-platform-bus binding
      [POWERPC] Uartlite: Let the console be initialized earlier
      [POWERPC] Uartlite: Flush RX fifo in bootwrapper
      [POWERPC] XilinxFB: Move xilinxfb_platform_data definition to a shared hea
      [POWERPC] Setup default eth addr in embed_config for Xilinx Virtex platfor

Josh Boyer (2):
      [POWERPC] 4xx: Fix Walnut wrapper compile errors
      [POWERPC] Add treeImage to .gitignore

Valentine Barshak (3):
      [POWERPC] 4xx: Introduce cpu_setup functionality to 44x platform
      [POWERPC] 4xx: Move 440EP(x) FPU setup from head_44x to cpu_setup_4xx
      [POWERPC] 4xx: 440EPx/GRx incorrect write to DDR SDRAM errata workaround

 MAINTAINERS                          |    7 +
 arch/powerpc/boot/.gitignore         |    1 +
 arch/powerpc/boot/Makefile           |    3 +-
 arch/powerpc/boot/ops.h              |    1 +
 arch/powerpc/boot/serial.c           |    2 +
 arch/powerpc/boot/uartlite.c         |   64 +++++++
 arch/powerpc/kernel/Makefile         |    1 +
 arch/powerpc/kernel/cpu_setup_44x.S  |   56 ++++++
 arch/powerpc/kernel/cputable.c       |   22 ++-
 arch/powerpc/kernel/head_44x.S       |   10 -
 arch/powerpc/platforms/40x/Kconfig   |   38 +++--
 arch/powerpc/platforms/40x/Makefile  |    1 +
 arch/powerpc/platforms/40x/virtex.c  |   50 ++++++
 arch/powerpc/sysdev/Makefile         |    1 +
 arch/powerpc/sysdev/xilinx_intc.c    |  151 ++++++++++++++++
 arch/ppc/boot/simple/embed_config.c  |    8 +
 arch/ppc/boot/simple/misc-embedded.c |    4 +-
 arch/ppc/boot/simple/uartlite_tty.c  |    8 +
 arch/ppc/syslib/virtex_devices.c     |    2 +-
 arch/ppc/syslib/virtex_devices.h     |    8 +-
 drivers/serial/uartlite.c            |  318 +++++++++++++++++++++++++++-------
 drivers/video/xilinxfb.c             |    2 +-
 include/asm-powerpc/xilinx_intc.h    |   20 ++
 include/linux/xilinxfb.h             |   23 +++
 24 files changed, 698 insertions(+), 103 deletions(-)
 create mode 100644 arch/powerpc/boot/uartlite.c
 create mode 100644 arch/powerpc/kernel/cpu_setup_44x.S
 create mode 100644 arch/powerpc/platforms/40x/virtex.c
 create mode 100644 arch/powerpc/sysdev/xilinx_intc.c
 create mode 100644 include/asm-powerpc/xilinx_intc.h
 create mode 100644 include/linux/xilinxfb.h

^ 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