* Re: [RFC v1] virtio: add virtio-over-PCI driver
From: Kumar Gala @ 2009-02-18 16:47 UTC (permalink / raw)
To: Ira Snyder
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev
In-Reply-To: <20090217222425.GA18801@ovro.caltech.edu>
On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote:
>
> Documentation/virtio-over-PCI.txt | 61 ++
> arch/powerpc/boot/dts/mpc834x_mds.dts | 7 +
we'll have to review the .dts and expect a documentation update for
the node. But that's pretty minor at this point.
> drivers/virtio/Kconfig | 22 +
> drivers/virtio/Makefile | 2 +
> drivers/virtio/vop.h | 119 ++
> drivers/virtio/vop_fsl.c | 1911 ++++++++++++++++++++++++
> +++++++++
make this vop_fsl_mpc83xx.c or something along those lines.
>
> drivers/virtio/vop_host.c | 1028 ++++++++++++++++++
> drivers/virtio/vop_hw.h | 80 ++
> 8 files changed, 3230 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/virtio-over-PCI.txt
> create mode 100644 drivers/virtio/vop.h
> create mode 100644 drivers/virtio/vop_fsl.c
> create mode 100644 drivers/virtio/vop_host.c
> create mode 100644 drivers/virtio/vop_hw.h
- k
^ permalink raw reply
* Re: Regarding irq_of_parse_and_map
From: Scott Wood @ 2009-02-18 16:57 UTC (permalink / raw)
To: Vijay Nikam; +Cc: linuxppc-dev
In-Reply-To: <f234e2140902180401u40a71642ga4e221f795bc5abd@mail.gmail.com>
On Wed, Feb 18, 2009 at 05:31:34PM +0530, Vijay Nikam wrote:
> > Don't specify this explicitly. Please base new development off of the
> > device tree that is in upstream Linux, not the very old tree in your BSP.
>
> May I know the reason why I should not specify it explicitly ? ? ?
Because dtc will generate phandles automatically when you reference the
node with the & operator.
> Also what would be the problem if I do in the same way as it is given
> in BSP mpc8313erdb.dts ? ? ?
Do you want your changes to ever make it into the upstream kernel?
> And should I use gpio-controller as a gpio device node ? ? ?
Yes, the node should label itself as a gpio controller.
-Scott
^ permalink raw reply
* Re: Gianfar tx-babbling-errors
From: Kumar Gala @ 2009-02-18 17:03 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-dev
In-Reply-To: <43EB80E07C42E1408726E4905FB96B04C0769D@CYBORG3.cyclone.com>
On Feb 18, 2009, at 10:16 AM, Scott Coulter wrote:
>
> Hi all,
>
> As a simple stress test for my board with an MPC8572E and an
> MPC8568E on
> it, I setup both processors to boot linux 2.6.27.6 with an NFS root
> and
> then perform repeated native compiles of a linux kernel over NFS.
> After
> running for 4 days straight or so with between 250-300 build cycles
> per
> processor, I stopped the builds and ran ethtool to look for any odd
> statistics. Both processors reported non-zero values for
> tx-babbling-errors. Both processors reported around 1300
> tx-babbling-errors out of about 80,000,000 Tx packets. Should I be
> concerned about the tx-babbling-errors? What conditions would cause
> these errors to be reported?
>
> Thanks,
> Scott
I'm told this will occur when:
Transmitted frame > MAXFRM and MACCFG2[Huge En] = 0.
- k
^ permalink raw reply
* RE: Gianfar tx-babbling-errors
From: Scott Coulter @ 2009-02-18 17:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <F122E3A2-3054-4BC9-9C06-0ADE590A8AFC@kernel.crashing.org>
Kumar,
> I'm told this will occur when:
> Transmitted frame > MAXFRM and MACCFG2[Huge En] =3D 0.
In the driver it looks like the MACCFG2_HUGEFRAME only gets set if the
mtu > DEFAULT_RX_BUFFER_SIZE (1536 in my kernel). It appears as though
the mtu is set to 1500. Under what conditions would the driver attempt
to send a frame larger than the mtu?
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
^ permalink raw reply
* Re: Gianfar tx-babbling-errors
From: Kumar Gala @ 2009-02-18 17:29 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-dev
In-Reply-To: <43EB80E07C42E1408726E4905FB96B04C076B1@CYBORG3.cyclone.com>
On Feb 18, 2009, at 11:22 AM, Scott Coulter wrote:
> Kumar,
>
>> I'm told this will occur when:
>
>> Transmitted frame > MAXFRM and MACCFG2[Huge En] = 0.
>
> In the driver it looks like the MACCFG2_HUGEFRAME only gets set if the
> mtu > DEFAULT_RX_BUFFER_SIZE (1536 in my kernel). It appears as
> though
> the mtu is set to 1500. Under what conditions would the driver
> attempt
> to send a frame larger than the mtu?
can't think of any. How about adding a BUG_ON() in the tx path to see
if the buffer size > MTU and re-run your tests.
- k
^ permalink raw reply
* Re: NFS-boot on PS3, kboot can't mount nfs-dir.s
From: Geoff Levand @ 2009-02-18 18:05 UTC (permalink / raw)
To: gt bradley; +Cc: linuxppc-dev
In-Reply-To: <5708.94078.qm@web56204.mail.re3.yahoo.com>
On 02/17/2009 03:14 PM, gt bradley wrote:
> I'm trying to set up my PS3 to netboot (with an nfsroot).
>
> I'm using instructions at
> http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-howto/ps3-nfs-root-howto.txt
>
> I've passed section 3 (using tftp) to verify network /dhcp etc. (i.e.
> I'm able to tftp-get a file to ps3 from kboot's ash shell (busybox).
>
> i'm trying to mount the nfs server as per section 4. with
>
> ~# mount -t nfs -o nolock 192.168.99.1:/target /mnt/remote
>
> I get the following error message:
> mount: mounting 192.168.99.1:/target on /mnt/remote failed
>
> if I boot the PS3 from the HD, then I am able to mount the nfs directory.
> Using wireshark, I can see the initial dhcp traffic, (and when present the tftp traffic).
> the mount command doesn't open a network connection to the server,
> So I have pretty much ruled out server
> configuration.
>
> running "strings" on the decompressed kboot image yeilds serveral nfs symbols, so it
> appears to still support nfs mounting. (using version kboot-20080609.bld from geoff's dir at kernel.org)
>
> I have tried googling, and searching the various mailing lists, but am
> stuck.
>
> any help would be appreciated
> GT
Please see my reply to the almost identical post that was sent yesterday (Feb 16).
-Geoff
^ permalink raw reply
* [git pull] for both tip and powerpc
From: Steven Rostedt @ 2009-02-18 19:15 UTC (permalink / raw)
To: Ingo Molnar, Benjamin Herrenschmidt
Cc: Frédéric Weisbecker, Andrew Morton, LKML, linuxppc-dev
Ingo and Benjamin,
As discussed, I made a branch called mainline/function-graph-tracer
based off of Linus's commit:
commit d2f8d7ee1a9b4650b4e43325b321801264f7c37a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri Feb 13 15:31:30 2009 -0800
Linux 2.6.29-rc5
and cherry picked the below change. I added Ingo's Acked-by as well. If
both of you pull this change in (assuming both trees are already based
off of Linus's 2.6.29-rc5) then there should be no conflicts when this
gets merged back to Linus's tree.
I will not touch this branch again, until it is officially in mainline.
Please pull the latest mainline/function-graph tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
mainline/function-graph
Steven Rostedt (1):
tracing/function-graph-tracer: make arch generic push pop functions
----
arch/x86/include/asm/ftrace.h | 25 -----------
arch/x86/kernel/dumpstack.c | 1 +
arch/x86/kernel/ftrace.c | 75 +---------------------------------
include/linux/ftrace.h | 24 +++++++++++
kernel/trace/trace_functions_graph.c | 75 ++++++++++++++++++++++++++++++++++
5 files changed, 101 insertions(+), 99 deletions(-)
---------------------------
commit 712406a6bf59ebf4a00358bb59a4a2a1b2953d90
Author: Steven Rostedt <srostedt@redhat.com>
Date: Mon Feb 9 10:54:03 2009 -0800
tracing/function-graph-tracer: make arch generic push pop functions
There is nothing really arch specific of the push and pop functions
used by the function graph tracer. This patch moves them to generic
code.
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index b55b4a7..db24c22 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -55,29 +55,4 @@ struct dyn_arch_ftrace {
#endif /* __ASSEMBLY__ */
#endif /* CONFIG_FUNCTION_TRACER */
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
-
-#ifndef __ASSEMBLY__
-
-/*
- * Stack of return addresses for functions
- * of a thread.
- * Used in struct thread_info
- */
-struct ftrace_ret_stack {
- unsigned long ret;
- unsigned long func;
- unsigned long long calltime;
-};
-
-/*
- * Primary handler of a function return.
- * It relays on ftrace_return_to_handler.
- * Defined in entry_32/64.S
- */
-extern void return_to_handler(void);
-
-#endif /* __ASSEMBLY__ */
-#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
-
#endif /* _ASM_X86_FTRACE_H */
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 6b1f6f6..c085229 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -10,6 +10,7 @@
#include <linux/kdebug.h>
#include <linux/module.h>
#include <linux/ptrace.h>
+#include <linux/ftrace.h>
#include <linux/kexec.h>
#include <linux/bug.h>
#include <linux/nmi.h>
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 231bdd3..76f7141 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -389,79 +389,6 @@ void ftrace_nmi_exit(void)
#endif /* !CONFIG_DYNAMIC_FTRACE */
-/* Add a function return address to the trace stack on thread info.*/
-static int push_return_trace(unsigned long ret, unsigned long long time,
- unsigned long func, int *depth)
-{
- int index;
-
- if (!current->ret_stack)
- return -EBUSY;
-
- /* The return trace stack is full */
- if (current->curr_ret_stack == FTRACE_RETFUNC_DEPTH - 1) {
- atomic_inc(¤t->trace_overrun);
- return -EBUSY;
- }
-
- index = ++current->curr_ret_stack;
- barrier();
- current->ret_stack[index].ret = ret;
- current->ret_stack[index].func = func;
- current->ret_stack[index].calltime = time;
- *depth = index;
-
- return 0;
-}
-
-/* Retrieve a function return address to the trace stack on thread info.*/
-static void pop_return_trace(struct ftrace_graph_ret *trace, unsigned long *ret)
-{
- int index;
-
- index = current->curr_ret_stack;
-
- if (unlikely(index < 0)) {
- ftrace_graph_stop();
- WARN_ON(1);
- /* Might as well panic, otherwise we have no where to go */
- *ret = (unsigned long)panic;
- return;
- }
-
- *ret = current->ret_stack[index].ret;
- trace->func = current->ret_stack[index].func;
- trace->calltime = current->ret_stack[index].calltime;
- trace->overrun = atomic_read(¤t->trace_overrun);
- trace->depth = index;
- barrier();
- current->curr_ret_stack--;
-
-}
-
-/*
- * Send the trace to the ring-buffer.
- * @return the original return address.
- */
-unsigned long ftrace_return_to_handler(void)
-{
- struct ftrace_graph_ret trace;
- unsigned long ret;
-
- pop_return_trace(&trace, &ret);
- trace.rettime = cpu_clock(raw_smp_processor_id());
- ftrace_graph_return(&trace);
-
- if (unlikely(!ret)) {
- ftrace_graph_stop();
- WARN_ON(1);
- /* Might as well panic. What else to do? */
- ret = (unsigned long)panic;
- }
-
- return ret;
-}
-
/*
* Hook the return address and push it in the stack of return addrs
* in current thread info.
@@ -521,7 +448,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr)
calltime = cpu_clock(raw_smp_processor_id());
- if (push_return_trace(old, calltime,
+ if (ftrace_push_return_trace(old, calltime,
self_addr, &trace.depth) == -EBUSY) {
*parent = old;
return;
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 677432b..a7f8134 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -380,6 +380,30 @@ struct ftrace_graph_ret {
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
/*
+ * Stack of return addresses for functions
+ * of a thread.
+ * Used in struct thread_info
+ */
+struct ftrace_ret_stack {
+ unsigned long ret;
+ unsigned long func;
+ unsigned long long calltime;
+};
+
+/*
+ * Primary handler of a function return.
+ * It relays on ftrace_return_to_handler.
+ * Defined in entry_32/64.S
+ */
+extern void return_to_handler(void);
+
+extern int
+ftrace_push_return_trace(unsigned long ret, unsigned long long time,
+ unsigned long func, int *depth);
+extern void
+ftrace_pop_return_trace(struct ftrace_graph_ret *trace, unsigned long *ret);
+
+/*
* Sometimes we don't want to trace a function with the function
* graph tracer but we want them to keep traced by the usual function
* tracer if the function graph tracer is not configured.
diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
index 930c08e..dce71a5 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -42,6 +42,81 @@ static struct tracer_flags tracer_flags = {
/* pid on the last trace processed */
static pid_t last_pid[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 };
+/* Add a function return address to the trace stack on thread info.*/
+int
+ftrace_push_return_trace(unsigned long ret, unsigned long long time,
+ unsigned long func, int *depth)
+{
+ int index;
+
+ if (!current->ret_stack)
+ return -EBUSY;
+
+ /* The return trace stack is full */
+ if (current->curr_ret_stack == FTRACE_RETFUNC_DEPTH - 1) {
+ atomic_inc(¤t->trace_overrun);
+ return -EBUSY;
+ }
+
+ index = ++current->curr_ret_stack;
+ barrier();
+ current->ret_stack[index].ret = ret;
+ current->ret_stack[index].func = func;
+ current->ret_stack[index].calltime = time;
+ *depth = index;
+
+ return 0;
+}
+
+/* Retrieve a function return address to the trace stack on thread info.*/
+void
+ftrace_pop_return_trace(struct ftrace_graph_ret *trace, unsigned long *ret)
+{
+ int index;
+
+ index = current->curr_ret_stack;
+
+ if (unlikely(index < 0)) {
+ ftrace_graph_stop();
+ WARN_ON(1);
+ /* Might as well panic, otherwise we have no where to go */
+ *ret = (unsigned long)panic;
+ return;
+ }
+
+ *ret = current->ret_stack[index].ret;
+ trace->func = current->ret_stack[index].func;
+ trace->calltime = current->ret_stack[index].calltime;
+ trace->overrun = atomic_read(¤t->trace_overrun);
+ trace->depth = index;
+ barrier();
+ current->curr_ret_stack--;
+
+}
+
+/*
+ * Send the trace to the ring-buffer.
+ * @return the original return address.
+ */
+unsigned long ftrace_return_to_handler(void)
+{
+ struct ftrace_graph_ret trace;
+ unsigned long ret;
+
+ ftrace_pop_return_trace(&trace, &ret);
+ trace.rettime = cpu_clock(raw_smp_processor_id());
+ ftrace_graph_return(&trace);
+
+ if (unlikely(!ret)) {
+ ftrace_graph_stop();
+ WARN_ON(1);
+ /* Might as well panic. What else to do? */
+ ret = (unsigned long)panic;
+ }
+
+ return ret;
+}
+
static int graph_trace_init(struct trace_array *tr)
{
int cpu, ret;
^ permalink raw reply related
* RE: Gianfar tx-babbling-errors
From: Scott Coulter @ 2009-02-18 20:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6BBF4AB4-FFB0-46ED-B591-17DEC3BE547F@kernel.crashing.org>
Kumar,
>=20
> can't think of any. How about adding a BUG_ON() in the tx path to see
> if the buffer size > MTU and re-run your tests.
>
With the following in gfar_start_xmit():
BUG_ON(skb->len > priv->dev->mtu);
I bug checked during the NFS root boot process with skb->len at 1514 and
priv->dev->mtu at 1500. I changed it to:
BUG_ON(skb->len > DEFAULT_RX_BUFFER_SIZE);
Compiling now. Has not failed yet, I'll let you know.
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
^ permalink raw reply
* CPU hotplug /sys entries are missing on 2.6.28
From: Giuliano Pochini @ 2009-02-18 21:18 UTC (permalink / raw)
To: LinuxPPC-dev
/sys/devices/system/cpu/cpu*/online don't exist anymore.
When the kernel is booted with maxcpus=1 /sys/devices/system/cpu/cpu1 is
also missing:
$ ls -la /sys/devices/system/cpu/
totale 0
drwxr-xr-x 3 root root 0 9 feb 23:15 .
drwxr-xr-x 7 root root 0 9 feb 23:15 ..
drwxr-xr-x 4 root root 0 9 feb 23:15 cpu0
-r--r--r-- 1 root root 4096 9 feb 23:15 online
-r--r--r-- 1 root root 4096 9 feb 23:15 possible
-r--r--r-- 1 root root 4096 9 feb 23:15 present
$ cat /sys/devices/system/cpu/online
0
$ cat /sys/devices/system/cpu/possible
0-1
$ cat /sys/devices/system/cpu/present
0-1
$ uname -a
Linux Jay 2.6.28 #1 SMP Sun Jan 11 22:42:31 CET 2009 ppc 7455, altivec supported PowerMac3,6 GNU/Linux
Looking at the 2.6.28 diff, i noticed there is a patch to
setup_32.c::ppc_init() that removes the following:
for_each_possible_cpu(cpu) {
struct cpu *c = &per_cpu(cpu_devices, cpu);
c->hotpluggable = 1;
register_cpu(c, cpu);
}
Reverting it makes the kernel hang at boot.
The only other place where ->hotpluggable is set is in
sysfs.c::topology_init(), but it only happens if ppc_md.cpu_die!=NULL and I
couldn't find where that pointer is set. Any clue ?
TIA,
--
Giuliano.
^ permalink raw reply
* Re: net_device_ops support in bridging and fec_mpc52xx.c
From: David Miller @ 2009-02-18 21:48 UTC (permalink / raw)
To: henk.stegeman; +Cc: linuxppc-dev, bridge, netdev
In-Reply-To: <ae4f76fd0902180241s28458450hd91ebf8da94ceb53@mail.gmail.com>
From: Henk Stegeman <henk.stegeman@gmail.com>
Date: Wed, 18 Feb 2009 11:41:14 +0100
Please CC: netdev, now added, on all networking reports and patches.
Thank you.
> I discovered the hard way that because linux bridging uses
> net_device_ops, bridging only works with network drivers that publish
> their device operations trough net_device_ops.
>
> In my case running:
>
> brctl addif br0 eth0 (where eth0 fec_mpc52xx.c did not yet support
> net_device_ops) gave me a:
>
> Unable to handle kernel paging request...
>
> After changing fec_mpc52xx.c to support net_device_ops the problem was fixed.
>
> If possible some kind of detection in the bridging software is i think
> mostly appreciated for early detection of this problem, as it is
> pretty hard to relate the error message to a not updated driver.
>
> cheers,
>
> Henk
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index cd8e98b..a2841eb 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -888,6 +888,22 @@ static int mpc52xx_fec_ioctl(struct net_device
> *dev, struct ifreq *rq, int cmd)
> /* ======================================================================== */
> /* OF Driver */
> /* ======================================================================== */
> +static const struct net_device_ops mpc52xx_fec_netdev_ops = {
> + .ndo_open = mpc52xx_fec_open,
> + .ndo_stop = mpc52xx_fec_close,
> + .ndo_start_xmit = mpc52xx_fec_hard_start_xmit,
> + .ndo_tx_timeout = mpc52xx_fec_tx_timeout,
> + .ndo_get_stats = mpc52xx_fec_get_stats,
> + .ndo_set_multicast_list = mpc52xx_fec_set_multicast_list,
> + .ndo_validate_addr = eth_validate_addr,
> + .ndo_set_mac_address = mpc52xx_fec_set_mac_address,
> + .ndo_do_ioctl = mpc52xx_fec_ioctl,
> +
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + .ndo_poll_controller = mpc52xx_fec_poll_controller,
> +#endif
> +};
> +
>
> static int __devinit
> mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
> @@ -929,20 +945,7 @@ mpc52xx_fec_probe(struct of_device *op, const
> struct of_device_id *match)
> return -EBUSY;
>
> /* Init ether ndev with what we have */
> - ndev->open = mpc52xx_fec_open;
> - ndev->stop = mpc52xx_fec_close;
> - ndev->hard_start_xmit = mpc52xx_fec_hard_start_xmit;
> - ndev->do_ioctl = mpc52xx_fec_ioctl;
> - ndev->ethtool_ops = &mpc52xx_fec_ethtool_ops;
> - ndev->get_stats = mpc52xx_fec_get_stats;
> - ndev->set_mac_address = mpc52xx_fec_set_mac_address;
> - ndev->set_multicast_list = mpc52xx_fec_set_multicast_list;
> - ndev->tx_timeout = mpc52xx_fec_tx_timeout;
> - ndev->watchdog_timeo = FEC_WATCHDOG_TIMEOUT;
> - ndev->base_addr = mem.start;
> -#ifdef CONFIG_NET_POLL_CONTROLLER
> - ndev->poll_controller = mpc52xx_fec_poll_controller;
> -#endif
> + ndev->netdev_ops = &mpc52xx_fec_netdev_ops;
>
> priv->t_irq = priv->r_irq = ndev->irq = NO_IRQ; /* IRQ are free for now */
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: net_device_ops support in bridging and fec_mpc52xx.c
From: Stephen Hemminger @ 2009-02-18 22:31 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, henk.stegeman, bridge, netdev
In-Reply-To: <20090218.134852.118040610.davem@davemloft.net>
On Wed, 18 Feb 2009 13:48:52 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Henk Stegeman <henk.stegeman@gmail.com>
> Date: Wed, 18 Feb 2009 11:41:14 +0100
>
> Please CC: netdev, now added, on all networking reports and patches.
>
> Thank you.
>
> > I discovered the hard way that because linux bridging uses
> > net_device_ops, bridging only works with network drivers that publish
> > their device operations trough net_device_ops.
> >
> > In my case running:
> >
> > brctl addif br0 eth0 (where eth0 fec_mpc52xx.c did not yet support
> > net_device_ops) gave me a:
> >
> > Unable to handle kernel paging request...
> >
> > After changing fec_mpc52xx.c to support net_device_ops the problem was fixed.
> >
> > If possible some kind of detection in the bridging software is i think
> > mostly appreciated for early detection of this problem, as it is
> > pretty hard to relate the error message to a not updated driver.
> >
> > cheers,
> >
> > Henk
The normal register_netdevice stuff take care of setting up net_device_ops
for old style drivers. Was there something different about how this
device was being setup?
^ permalink raw reply
* Newby trying to get Ethernet going on MPC83xx series device.
From: Dushara Jayasinghe @ 2009-02-19 4:26 UTC (permalink / raw)
To: 'linuxppc-dev@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]
Hi I'm having difficulty getting an Ethernet device up on a dev board with an MPX8349 controller.
The contents of my .dts file are as follows (based on mpc8349emitx.dts):
soc8349@e0000000 {
...
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <24520 20>;
/* Vitesse 8201 */
phy1c: ethernet-phy@1c {
interrupt-parent = <&ipic>;
interrupts = <3 8>;
reg = <0>;
device_type = "ethernet-phy";
};
tbi0: tbi-phy@11 {
reg = <11>;
device_type = "tbi-phy";
};
};
mdio@25520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-tbi";
reg = <25520 20>;
tbi1: tbi-phy@11 {
reg = <11>;
device_type = "tbi-phy";
};
};
ethernet@24000 {
cell-index = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <24000 1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <20 8 21 8 22 8>;
interrupt-parent = <&ipic>;
tbi-handle = <&tbi0>;
phy-handle = <&phy1c>;
linux,network-index = <0>;
};
ethernet@25000 {
cell-index = <1>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <25000 1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <23 8 24 8 25 8>;
interrupt-parent = <&ipic>;
/* Vitesse 7385 isn't on the MDIO bus */
fixed-link = <1 1 1000 0 0>;
linux,network-index = <1>;
tbi-handle = <&tbi1>;
phy-connection-type = "gmii";
};
};
I get the following error during the boot sequence:
IP-Config: Device `eth0' not found
I also found that both gfar_init (in gianfar.c) and gfar_mdio_init (in gianfar_mii.c) are called but the probe handlers of either of these devices are not executed.
What am I missing?
Thanks in advance.
D
[-- Attachment #2: Type: text/html, Size: 11246 bytes --]
^ permalink raw reply
* RE: Newby trying to get Ethernet going on MPC83xx series device.
From: Li Yang-R58472 @ 2009-02-19 5:21 UTC (permalink / raw)
To: Dushara Jayasinghe, linuxppc-dev
In-Reply-To: <DE0CCFFBFF707949BEABD4537A14ACBA0C04B40549@mailsvr>
> -----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 Dushara Jayasinghe
> Sent: Thursday, February 19, 2009 12:27 PM
> To: 'linuxppc-dev@ozlabs.org'
> Subject: Newby trying to get Ethernet going on MPC83xx series device.
>=20
> Hi I'm having difficulty getting an Ethernet device up on a=20
> dev board with an MPX8349 controller.
> =20
> The contents of my .dts file are as follows (based on=20
> mpc8349emitx.dts):
> =20
> soc8349@e0000000 {
> ...
> =20
> mdio@24520 {
> #address-cells =3D <1>;
> #size-cells =3D <0>;
> compatible =3D "fsl,gianfar-mdio";
> reg =3D <24520 20>;
> =20
> /* Vitesse 8201 */
> phy1c: ethernet-phy@1c {
> interrupt-parent =3D <&ipic>;
> interrupts =3D <3 8>;
> reg =3D <0>;
> device_type =3D "ethernet-phy";
> };
> tbi0: tbi-phy@11 {
> reg =3D <11>;
> device_type =3D "tbi-phy";
> };
> };
> =20
> mdio@25520 {
> #address-cells =3D <1>;
> #size-cells =3D <0>;
> compatible =3D "fsl,gianfar-tbi";
> reg =3D <25520 20>;
> =20
> tbi1: tbi-phy@11 {
> reg =3D <11>;
> device_type =3D "tbi-phy";
> };
> };
> =20
> ethernet@24000 {
> cell-index =3D <0>;
> device_type =3D "network";
> model =3D "TSEC";
> compatible =3D "gianfar";
> reg =3D <24000 1000>;
> local-mac-address =3D [ 00 00 00 00 00 00 ];
> interrupts =3D <20 8 21 8 22 8>;
> interrupt-parent =3D <&ipic>;
> tbi-handle =3D <&tbi0>;
> phy-handle =3D <&phy1c>;
> linux,network-index =3D <0>;
> };
> =20
> ethernet@25000 {
> cell-index =3D <1>;
> device_type =3D "network";
> model =3D "TSEC";
> compatible =3D "gianfar";
> reg =3D <25000 1000>;
> local-mac-address =3D [ 00 00 00 00 00 00 ];
> interrupts =3D <23 8 24 8 25 8>;
> interrupt-parent =3D <&ipic>;
> /* Vitesse 7385 isn't on the MDIO bus */
> fixed-link =3D <1 1 1000 0 0>;
> linux,network-index =3D <1>;
> tbi-handle =3D <&tbi1>;
> phy-connection-type =3D "gmii";
> };
> };
> =20
> I get the following error during the boot sequence:
> =20
> IP-Config: Device `eth0' not found
> =20
> I also found that both gfar_init (in gianfar.c) and=20
> gfar_mdio_init (in gianfar_mii.c) are called but the probe=20
> handlers of either of these devices are not executed.
> =20
> What am I missing?
Don't find any obvious problem. I suggest you to debug gfar_of_init()
in arch/powerpc/sysdev/fsl_soc.c to see if it works correctly.
- Leo
^ permalink raw reply
* RE: [RFC v1] virtio: add virtio-over-PCI driver
From: Zang Roy-R61911 @ 2009-02-19 6:10 UTC (permalink / raw)
To: Ira Snyder, linux-kernel
Cc: linuxppc-dev, Jan-Bernd Themann, Rusty Russell, Arnd Bergmann,
netdev
In-Reply-To: <20090217222425.GA18801@ovro.caltech.edu>
=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@ozlabs
> .org] On Behalf Of Ira Snyder
> Sent: Wednesday, February 18, 2009 6:24 AM
> To: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@ozlabs.org; netdev@vger.kernel.org; Rusty=20
> Russell; Arnd Bergmann; Jan-Bernd Themann
> Subject: [RFC v1] virtio: add virtio-over-PCI driver
snip
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 3dd6294..efcf56b 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -33,3 +33,25 @@ config VIRTIO_BALLOON
> =20
> If unsure, say M.
> =20
> +config VIRTIO_OVER_PCI_HOST
> + tristate "Virtio-over-PCI Host support (EXPERIMENTAL)"
> + depends on PCI && EXPERIMENTAL
> + select VIRTIO
> + ---help---
> + This driver provides the host support necessary for=20
> using virtio
> + over the PCI bus with a Freescale MPC8349EMDS=20
> evaluation board.
> +
> + If unsure, say N.
> +
> +config VIRTIO_OVER_PCI_FSL
> + tristate "Virtio-over-PCI Guest support (EXPERIMENTAL)"
> + depends on MPC834x_MDS && EXPERIMENTAL
> + select VIRTIO
> + select DMA_ENGINE
> + select FSL_DMA
> + ---help---
> + This driver provides the guest support necessary for=20
> using virtio
> + over the PCI bus.
> +
> + If unsure, say N.
> +
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> index 6738c44..f31afaa 100644
> --- a/drivers/virtio/Makefile
> +++ b/drivers/virtio/Makefile
> @@ -2,3 +2,5 @@ obj-$(CONFIG_VIRTIO) +=3D virtio.o
> obj-$(CONFIG_VIRTIO_RING) +=3D virtio_ring.o
> obj-$(CONFIG_VIRTIO_PCI) +=3D virtio_pci.o
> obj-$(CONFIG_VIRTIO_BALLOON) +=3D virtio_balloon.o
> +obj-$(CONFIG_VIRTIO_OVER_PCI_HOST) +=3D vop_host.o
> +obj-$(CONFIG_VIRTIO_OVER_PCI_FSL) +=3D vop_fsl.o
I suppose we need to build the kernel twice. one for vop_host (on host
with pci enabled) and the
other is for vop_fsl ( on agent with pci disabled). Is it possible to
build one image for both host and=20
agent. We do not scan the pci bus if the controller is configured to
agent.
Also, is it possible to include mpc85xx architecture? They should be
same.
There is some code for 85xx in Fresscale BSP.
http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8568MDS_PCI_Agent_PCIe_
EP_Drvier.patch
Roy
^ permalink raw reply
* RE: [RFC v1] virtio: add virtio-over-PCI driver
From: Zang Roy-R61911 @ 2009-02-19 6:13 UTC (permalink / raw)
To: Kumar Gala, Ira Snyder
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev
In-Reply-To: <D999D051-E5A2-4915-893D-E3384EC312A4@kernel.crashing.org>
=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@ozlabs
> .org] On Behalf Of Kumar Gala
> Sent: Thursday, February 19, 2009 0:47 AM
> To: Ira Snyder
> Cc: Arnd Bergmann; Jan-Bernd Themann; netdev@vger.kernel.org;=20
> Rusty Russell; linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org
> Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver
>=20
>=20
> On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote:
>=20
> >
> > Documentation/virtio-over-PCI.txt | 61 ++
> > arch/powerpc/boot/dts/mpc834x_mds.dts | 7 +
>=20
> we'll have to review the .dts and expect a documentation update for =20
> the node. But that's pretty minor at this point.
>=20
> > drivers/virtio/Kconfig | 22 +
> > drivers/virtio/Makefile | 2 +
> > drivers/virtio/vop.h | 119 ++
> > drivers/virtio/vop_fsl.c | 1911=20
> ++++++++++++++++++++++++=20
> > +++++++++
>=20
> make this vop_fsl_mpc83xx.c or something along those lines.
why?
Roy
^ permalink raw reply
* RE: Newby trying to get Ethernet going on MPC83xx series device.
From: Dushara Jayasinghe @ 2009-02-19 6:33 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED246F06@zch01exm26.fsl.freescale.net>
Thanks for the swift response.
> > I also found that both gfar_init (in gianfar.c) and=20
> > gfar_mdio_init (in gianfar_mii.c) are called but the probe=20
> > handlers of either of these devices are not executed.
> > =20
> > What am I missing?
> Don't find any obvious problem. I suggest you to debug gfar_of_init()
> in arch/powerpc/sysdev/fsl_soc.c to see if it works correctly.
That fn doesn't exist in the dev tree I'm using (commit 103f194f3ccf4684254=
8eb52e607167b6d4951ef)
The driver is now initialised through of_device. I can't figure out how the=
probe handler is invoked.
^ permalink raw reply
* RE: Newby trying to get Ethernet going on MPC83xx series device.
From: Li Yang-R58472 @ 2009-02-19 6:41 UTC (permalink / raw)
To: Dushara Jayasinghe, linuxppc-dev
In-Reply-To: <DE0CCFFBFF707949BEABD4537A14ACBA0C04B4054A@mailsvr>
> -----Original Message-----
> From: Dushara Jayasinghe [mailto:DusharaJ@optiscan.com]=20
> Sent: Thursday, February 19, 2009 2:33 PM
> To: linuxppc-dev@ozlabs.org
> Cc: Li Yang-R58472
> Subject: RE: Newby trying to get Ethernet going on MPC83xx=20
> series device.
>=20
> Thanks for the swift response.
>=20
> > > I also found that both gfar_init (in gianfar.c) and=20
> gfar_mdio_init=20
> > > (in gianfar_mii.c) are called but the probe handlers of either of=20
> > > these devices are not executed.
> > > =20
> > > What am I missing?
>=20
> > Don't find any obvious problem. I suggest you to debug=20
> gfar_of_init()=20
> > in arch/powerpc/sysdev/fsl_soc.c to see if it works correctly.
>=20
> That fn doesn't exist in the dev tree I'm using (commit=20
> 103f194f3ccf46842548eb52e607167b6d4951ef)
>=20
> The driver is now initialised through of_device. I can't=20
> figure out how the probe handler is invoked.
Well, I was looking at an older tree. If you are using of_device for
TSEC, the most likely cause of this problem is that
of_platform_bus_probe() didn't probe your ethernet nodes.
Refer to the following code in
arch/powerpc/platforms/83xx/mpc834x_itx.c. Make sure it creates
of_platform_device for TSEC.
static struct of_device_id __initdata mpc834x_itx_ids[] =3D {
{ .compatible =3D "fsl,pq2pro-localbus", },
{ .compatible =3D "simple-bus", },
{},
};
static int __init mpc834x_itx_declare_of_platform_devices(void)
{
return of_platform_bus_probe(NULL, mpc834x_itx_ids, NULL);
}
machine_device_initcall(mpc834x_itx,
mpc834x_itx_declare_of_platform_devices);
^ permalink raw reply
* Re: How to bring up fs_enet on 2.6.27?
From: Daniel Ng @ 2009-02-19 6:47 UTC (permalink / raw)
To: Mike Ditto; +Cc: linuxppc-dev
In-Reply-To: <49810367.5000904@consentry.com>
On Thu, Jan 29, 2009 at 12:16 PM, Mike Ditto <mditto@consentry.com> wrote:
> But I can't explain why the driver isn't attaching for you. Did you
> try it built-in instead of as a module?
>
Hi Mike et al,
I am trying it built-in at the moment (ie. not as a module).
I've stuck a whole bunch of printks() in. This is what is happening
during boot-up:
1) fs_init() from fs_enet-main.c is called
2) This in turn calls driver_register() with the 'fs_enet' driver
3) This results in a call to bus_add_driver() with the following parameters:
driver = 'fs_enet' driver
bus = 'of_platform' bus
4) Then, driver_attach() is called with 'fs_enet' driver as the parameter
5) driver_attach() calls bus_for_each_dev() with "__driver_attach()"
and the 'of_platform' bus as the relevant parameters
However, __driver_attach() is never called from bus_for_each_dev() ie.
there seems to be no devices on the 'of_platform' bus.
Hence, is there some way to add an appropriate device to the
'of_platform' bus so that __driver_attach() can be called for that
device?
Or, perhaps it is ok for the 'of_platform' bus to have no devices on
it, and so I might be using the wrong bus?? Why would this be?
Or is it something else??
Either way, I still get the following boot error message:
IP-Config: Device `eth0' not found.
-and fs_enet_probe() is NEVER called.
Cheers,
Daniel
^ permalink raw reply
* RE: Newby trying to get Ethernet going on MPC83xx series device.
From: Aggrwal Poonam-B10812 @ 2009-02-19 6:48 UTC (permalink / raw)
To: Li Yang-R58472, Dushara Jayasinghe, linuxppc-dev
In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED246F06@zch01exm26.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 5053 bytes --]
Can you look into your board specific file
Like board/freescale/mpc8249_mds/mpc8349_mds.c
And check if the buses are getting probed.
For example
static struct of_device_id mpc834x_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .compatible = "simple-bus", },
{},
};
static int __init mpc834x_declare_of_platform_devices(void)
{
of_platform_bus_probe(NULL, mpc834x_ids, NULL);
return 0;
}
machine_device_initcall(mpc834x_mds,
mpc834x_declare_of_platform_devices);
Regards
Poonam
> -----Original Message-----
> From:
> linuxppc-dev-bounces+poonam.aggrwal=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale.com@ozla
> bs.org] On Behalf Of Li Yang-R58472
> Sent: Thursday, February 19, 2009 10:52 AM
> To: Dushara Jayasinghe; linuxppc-dev@ozlabs.org
> Subject: RE: Newby trying to get Ethernet going on MPC83xx
> series device.
>
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> > [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org]
> > On Behalf Of Dushara Jayasinghe
> > Sent: Thursday, February 19, 2009 12:27 PM
> > To: 'linuxppc-dev@ozlabs.org'
> > Subject: Newby trying to get Ethernet going on MPC83xx
> series device.
> >
> > Hi I'm having difficulty getting an Ethernet device up on a
> dev board
> > with an MPX8349 controller.
> >
> > The contents of my .dts file are as follows (based on
> > mpc8349emitx.dts):
> >
> > soc8349@e0000000 {
> > ...
> >
> > mdio@24520 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "fsl,gianfar-mdio";
> > reg = <24520 20>;
> >
> > /* Vitesse 8201 */
> > phy1c: ethernet-phy@1c {
> > interrupt-parent = <&ipic>;
> > interrupts = <3 8>;
> > reg = <0>;
> > device_type = "ethernet-phy";
> > };
> > tbi0: tbi-phy@11 {
> > reg = <11>;
> > device_type = "tbi-phy";
> > };
> > };
> >
> > mdio@25520 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "fsl,gianfar-tbi";
> > reg = <25520 20>;
> >
> > tbi1: tbi-phy@11 {
> > reg = <11>;
> > device_type = "tbi-phy";
> > };
> > };
> >
> > ethernet@24000 {
> > cell-index = <0>;
> > device_type = "network";
> > model = "TSEC";
> > compatible = "gianfar";
> > reg = <24000 1000>;
> > local-mac-address = [ 00 00 00 00 00 00 ];
> > interrupts = <20 8 21 8 22 8>;
> > interrupt-parent = <&ipic>;
> > tbi-handle = <&tbi0>;
> > phy-handle = <&phy1c>;
> > linux,network-index = <0>;
> > };
> >
> > ethernet@25000 {
> > cell-index = <1>;
> > device_type = "network";
> > model = "TSEC";
> > compatible = "gianfar";
> > reg = <25000 1000>;
> > local-mac-address = [ 00 00 00 00 00 00 ];
> > interrupts = <23 8 24 8 25 8>;
> > interrupt-parent = <&ipic>;
> > /* Vitesse 7385 isn't on the MDIO bus */
> > fixed-link = <1 1 1000 0 0>;
> > linux,network-index = <1>;
> > tbi-handle = <&tbi1>;
> > phy-connection-type = "gmii";
> > };
> > };
> >
> > I get the following error during the boot sequence:
> >
> > IP-Config: Device `eth0' not found
> >
> > I also found that both gfar_init (in gianfar.c) and
> gfar_mdio_init (in
> > gianfar_mii.c) are called but the probe handlers of either of these
> > devices are not executed.
> >
> > What am I missing?
>
> Don't find any obvious problem. I suggest you to debug
> gfar_of_init() in arch/powerpc/sysdev/fsl_soc.c to see if it
> works correctly.
>
> - Leo
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
[-- Attachment #2: Type: text/html, Size: 22716 bytes --]
^ permalink raw reply
* RE: Newby trying to get Ethernet going on MPC83xx series device.
From: Dushara Jayasinghe @ 2009-02-19 6:58 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org; +Cc: 'Aggrwal Poonam-B10812'
In-Reply-To: <FD3D453EC8A8D5479E7E063D31E2FA44268653@zin33exm24.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 5569 bytes --]
That did it.
I based my board specific file on mpc834x_itx.c which had
static struct of_device_id __initdata mpc834x_itx_ids[] = {
{ .compatible = "fsl,pq2pro-localbus", },
{ .compatible = "simple-bus", },
{},
};
Don't know if this is broken?
From: Aggrwal Poonam-B10812 [mailto:Poonam.Aggrwal@freescale.com]
Sent: Thursday, 19 February 2009 5:49 PM
To: Li Yang-R58472; Dushara Jayasinghe; linuxppc-dev@ozlabs.org
Subject: RE: Newby trying to get Ethernet going on MPC83xx series device.
Can you look into your board specific file
Like board/freescale/mpc8249_mds/mpc8349_mds.c
And check if the buses are getting probed.
For example
static struct of_device_id mpc834x_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .compatible = "simple-bus", },
{},
};
static int __init mpc834x_declare_of_platform_devices(void)
{
of_platform_bus_probe(NULL, mpc834x_ids, NULL);
return 0;
}
machine_device_initcall(mpc834x_mds, mpc834x_declare_of_platform_devices);
Regards
Poonam
> -----Original Message-----
> From:
> linuxppc-dev-bounces+poonam.aggrwal=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale.com@ozla
> bs.org] On Behalf Of Li Yang-R58472
> Sent: Thursday, February 19, 2009 10:52 AM
> To: Dushara Jayasinghe; linuxppc-dev@ozlabs.org
> Subject: RE: Newby trying to get Ethernet going on MPC83xx
> series device.
>
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> > [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org]
> > On Behalf Of Dushara Jayasinghe
> > Sent: Thursday, February 19, 2009 12:27 PM
> > To: 'linuxppc-dev@ozlabs.org'
> > Subject: Newby trying to get Ethernet going on MPC83xx
> series device.
> >
> > Hi I'm having difficulty getting an Ethernet device up on a
> dev board
> > with an MPX8349 controller.
> >
> > The contents of my .dts file are as follows (based on
> > mpc8349emitx.dts):
> >
> > soc8349@e0000000 {
> > ...
> >
> > mdio@24520 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "fsl,gianfar-mdio";
> > reg = <24520 20>;
> >
> > /* Vitesse 8201 */
> > phy1c: ethernet-phy@1c {
> > interrupt-parent = <&ipic>;
> > interrupts = <3 8>;
> > reg = <0>;
> > device_type = "ethernet-phy";
> > };
> > tbi0: tbi-phy@11 {
> > reg = <11>;
> > device_type = "tbi-phy";
> > };
> > };
> >
> > mdio@25520 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "fsl,gianfar-tbi";
> > reg = <25520 20>;
> >
> > tbi1: tbi-phy@11 {
> > reg = <11>;
> > device_type = "tbi-phy";
> > };
> > };
> >
> > ethernet@24000 {
> > cell-index = <0>;
> > device_type = "network";
> > model = "TSEC";
> > compatible = "gianfar";
> > reg = <24000 1000>;
> > local-mac-address = [ 00 00 00 00 00 00 ];
> > interrupts = <20 8 21 8 22 8>;
> > interrupt-parent = <&ipic>;
> > tbi-handle = <&tbi0>;
> > phy-handle = <&phy1c>;
> > linux,network-index = <0>;
> > };
> >
> > ethernet@25000 {
> > cell-index = <1>;
> > device_type = "network";
> > model = "TSEC";
> > compatible = "gianfar";
> > reg = <25000 1000>;
> > local-mac-address = [ 00 00 00 00 00 00 ];
> > interrupts = <23 8 24 8 25 8>;
> > interrupt-parent = <&ipic>;
> > /* Vitesse 7385 isn't on the MDIO bus */
> > fixed-link = <1 1 1000 0 0>;
> > linux,network-index = <1>;
> > tbi-handle = <&tbi1>;
> > phy-connection-type = "gmii";
> > };
> > };
> >
> > I get the following error during the boot sequence:
> >
> > IP-Config: Device `eth0' not found
> >
> > I also found that both gfar_init (in gianfar.c) and
> gfar_mdio_init (in
> > gianfar_mii.c) are called but the probe handlers of either of these
> > devices are not executed.
> >
> > What am I missing?
>
> Don't find any obvious problem. I suggest you to debug
> gfar_of_init() in arch/powerpc/sysdev/fsl_soc.c to see if it
> works correctly.
>
> - Leo
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
[-- Attachment #2: Type: text/html, Size: 30260 bytes --]
^ permalink raw reply
* Re: open-pic device tree node and subnodes for additional functionality?
From: Benjamin Herrenschmidt @ 2009-02-19 7:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <8330CA5E-0F3B-49D5-AB55-500CD37739C1@kernel.crashing.org>
> For MSI I doubt any. I think on some parts we might have two (or
> more) groups of MSIs.
>
> However I want to be able to handle timers and the slightly more
> generic message interrupts.
You can probably add a reg and a ranges, the reg remains the same
as today as to not inflict any collateral damage, and the ranges
represents downstream addresses to child nodes msi, timers, ...
(ie, it's no big deal if the parent "reg" somewhat overlap the
childs ranges... it's only a problem if the drivers try to request
the resources in ways that collide)
Ben.
^ permalink raw reply
* Re: Newby trying to get Ethernet going on MPC83xx series device.
From: Li Yang @ 2009-02-19 7:19 UTC (permalink / raw)
To: Dushara Jayasinghe; +Cc: linuxppc-dev@ozlabs.org, Aggrwal Poonam-B10812
In-Reply-To: <DE0CCFFBFF707949BEABD4537A14ACBA0C04B4054B@mailsvr>
On Thu, Feb 19, 2009 at 2:58 PM, Dushara Jayasinghe
<DusharaJ@optiscan.com> wrote:
> That did it.
>
>
>
> I based my board specific file on mpc834x_itx.c which had
>
>
>
> static struct of_device_id __initdata mpc834x_itx_ids[] = {
>
> { .compatible = "fsl,pq2pro-localbus", },
>
> { .compatible = "simple-bus", },
>
> {},
>
> };
>
>
>
> Don't know if this is broken?
It's not broken as long as you have compatible = "simple-bus" for your soc node.
- Leo
^ permalink raw reply
* RE: Newby trying to get Ethernet going on MPC83xx series device.
From: Aggrwal Poonam-B10812 @ 2009-02-19 7:25 UTC (permalink / raw)
To: Li Yang-R58472, Dushara Jayasinghe; +Cc: linuxppc-dev
In-Reply-To: <2a27d3730902182319i2c59d68dk98e7975714f80549@mail.gmail.com>
Probably better would be to check the board file for mpc834x_mds.c
I mean just cross that you probe all the buses which are on the device.
What is fsl,pq2pro-localbus? Do u have such node in dts as the
mpc8349_itx has.
> -----Original Message-----
> From: pku.leo@gmail.com [mailto:pku.leo@gmail.com] On Behalf=20
> Of Li Yang-R58472
> Sent: Thursday, February 19, 2009 12:50 PM
> To: Dushara Jayasinghe
> Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812
> Subject: Re: Newby trying to get Ethernet going on MPC83xx=20
> series device.
>=20
> On Thu, Feb 19, 2009 at 2:58 PM, Dushara Jayasinghe=20
> <DusharaJ@optiscan.com> wrote:
> > That did it.
> >
> >
> >
> > I based my board specific file on mpc834x_itx.c which had
> >
> >
> >
> > static struct of_device_id __initdata mpc834x_itx_ids[] =3D {
> >
> > { .compatible =3D "fsl,pq2pro-localbus", },
> >
> > { .compatible =3D "simple-bus", },
> >
> > {},
> >
> > };
> >
> >
> >
> > Don't know if this is broken?
>=20
> It's not broken as long as you have compatible =3D "simple-bus"=20
> for your soc node.
>=20
> - Leo
>=20
>=20
^ permalink raw reply
* Re: net_device_ops support in bridging and fec_mpc52xx.c
From: Henk Stegeman @ 2009-02-19 9:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, bridge
In-Reply-To: <20090218.134852.118040610.davem@davemloft.net>
I must have made a mistake when I tested the previous patch, I
discovered later it still had errors:
- I had accidentally removed the base address in the fec_mpc52xx driver.
- The priv->phydev pointer was sometimes not initialized (NULL) but
still passed by the fec_mpc52xx driver, this pointer is then used
unchecked by the eth_tool_* functions (used by bridging to determine
port priority). As far as I see this depends on whether
mpc52xx_fec_open (or mpc52xx_fec_close) is called which in turn call
mpc52xx_init_phy to initialize priv->phydev. My work around checks the
priv->phydev pointer in the fec_mpc52xx driver and returns -ENODEV to
indicate there's no physical device. Big chance this is not the right
way to handle the problem, but it works, hopefully someone with some
more fundamental Linux network driver experience can pick this up or
give me some hints on this.
At least bridging now works on my board in combination with the
fec_mpc52xx driver.
ifconfig eth0 0.0.0.0 down
ifconfig eth1 0.0.0.0 down
brctl addbr br0
brctl setfd br0 0
brctl stp br0 off
ifconfig br0 192.168.1.30 down
ifconfig br0 up
brctl addif br0 eth0
ifconfig eth0 up
brctl addif br0 eth1
ifconfig eth1 up
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cd8e98b..e228973 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -847,24 +847,40 @@ static void mpc52xx_fec_get_drvinfo(struct
net_device *dev,
static int mpc52xx_fec_get_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv->phydev)
+ return -ENODEV;
+
return phy_ethtool_gset(priv->phydev, cmd);
}
static int mpc52xx_fec_set_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv->phydev)
+ return -ENODEV;
+
return phy_ethtool_sset(priv->phydev, cmd);
}
static u32 mpc52xx_fec_get_msglevel(struct net_device *dev)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv->phydev)
+ return 0;
+
return priv->msg_enable;
}
static void mpc52xx_fec_set_msglevel(struct net_device *dev, u32 level)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv->phydev)
+ return;
+
priv->msg_enable = level;
}
@@ -882,12 +898,31 @@ static int mpc52xx_fec_ioctl(struct net_device
*dev, struct ifreq *rq, int cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ if (!priv->phydev)
+ return -ENODEV;
+
return mpc52xx_fec_phy_mii_ioctl(priv, if_mii(rq), cmd);
}
/* ======================================================================== */
/* OF Driver */
/* ======================================================================== */
+static const struct net_device_ops mpc52xx_fec_netdev_ops = {
+ .ndo_open = mpc52xx_fec_open,
+ .ndo_stop = mpc52xx_fec_close,
+ .ndo_start_xmit = mpc52xx_fec_hard_start_xmit,
+ .ndo_tx_timeout = mpc52xx_fec_tx_timeout,
+ .ndo_get_stats = mpc52xx_fec_get_stats,
+ .ndo_set_multicast_list = mpc52xx_fec_set_multicast_list,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address = mpc52xx_fec_set_mac_address,
+ .ndo_do_ioctl = mpc52xx_fec_ioctl,
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = mpc52xx_fec_poll_controller,
+#endif
+};
+
static int __devinit
mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
@@ -929,20 +964,10 @@ mpc52xx_fec_probe(struct of_device *op, const
struct of_device_id *match)
return -EBUSY;
/* Init ether ndev with what we have */
- ndev->open = mpc52xx_fec_open;
- ndev->stop = mpc52xx_fec_close;
- ndev->hard_start_xmit = mpc52xx_fec_hard_start_xmit;
- ndev->do_ioctl = mpc52xx_fec_ioctl;
ndev->ethtool_ops = &mpc52xx_fec_ethtool_ops;
- ndev->get_stats = mpc52xx_fec_get_stats;
- ndev->set_mac_address = mpc52xx_fec_set_mac_address;
- ndev->set_multicast_list = mpc52xx_fec_set_multicast_list;
- ndev->tx_timeout = mpc52xx_fec_tx_timeout;
ndev->watchdog_timeo = FEC_WATCHDOG_TIMEOUT;
ndev->base_addr = mem.start;
-#ifdef CONFIG_NET_POLL_CONTROLLER
- ndev->poll_controller = mpc52xx_fec_poll_controller;
-#endif
+ ndev->netdev_ops = &mpc52xx_fec_netdev_ops;
priv->t_irq = priv->r_irq = ndev->irq = NO_IRQ; /* IRQ are free for now */
On Wed, Feb 18, 2009 at 10:48 PM, David Miller <davem@davemloft.net> wrote:
> From: Henk Stegeman <henk.stegeman@gmail.com>
> Date: Wed, 18 Feb 2009 11:41:14 +0100
>
> Please CC: netdev, now added, on all networking reports and patches.
>
> Thank you.
>
>> I discovered the hard way that because linux bridging uses
>> net_device_ops, bridging only works with network drivers that publish
>> their device operations trough net_device_ops.
>>
>> In my case running:
>>
>> brctl addif br0 eth0 (where eth0 fec_mpc52xx.c did not yet support
>> net_device_ops) gave me a:
>>
>> Unable to handle kernel paging request...
>>
>> After changing fec_mpc52xx.c to support net_device_ops the problem was fixed.
>>
>> If possible some kind of detection in the bridging software is i think
>> mostly appreciated for early detection of this problem, as it is
>> pretty hard to relate the error message to a not updated driver.
>>
>> cheers,
>>
>> Henk
>>
>> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
>> index cd8e98b..a2841eb 100644
>> --- a/drivers/net/fec_mpc52xx.c
>> +++ b/drivers/net/fec_mpc52xx.c
>> @@ -888,6 +888,22 @@ static int mpc52xx_fec_ioctl(struct net_device
>> *dev, struct ifreq *rq, int cmd)
>> /* ======================================================================== */
>> /* OF Driver */
>> /* ======================================================================== */
>> +static const struct net_device_ops mpc52xx_fec_netdev_ops = {
>> + .ndo_open = mpc52xx_fec_open,
>> + .ndo_stop = mpc52xx_fec_close,
>> + .ndo_start_xmit = mpc52xx_fec_hard_start_xmit,
>> + .ndo_tx_timeout = mpc52xx_fec_tx_timeout,
>> + .ndo_get_stats = mpc52xx_fec_get_stats,
>> + .ndo_set_multicast_list = mpc52xx_fec_set_multicast_list,
>> + .ndo_validate_addr = eth_validate_addr,
>> + .ndo_set_mac_address = mpc52xx_fec_set_mac_address,
>> + .ndo_do_ioctl = mpc52xx_fec_ioctl,
>> +
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> + .ndo_poll_controller = mpc52xx_fec_poll_controller,
>> +#endif
>> +};
>> +
>>
>> static int __devinit
>> mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
>> @@ -929,20 +945,7 @@ mpc52xx_fec_probe(struct of_device *op, const
>> struct of_device_id *match)
>> return -EBUSY;
>>
>> /* Init ether ndev with what we have */
>> - ndev->open = mpc52xx_fec_open;
>> - ndev->stop = mpc52xx_fec_close;
>> - ndev->hard_start_xmit = mpc52xx_fec_hard_start_xmit;
>> - ndev->do_ioctl = mpc52xx_fec_ioctl;
>> - ndev->ethtool_ops = &mpc52xx_fec_ethtool_ops;
>> - ndev->get_stats = mpc52xx_fec_get_stats;
>> - ndev->set_mac_address = mpc52xx_fec_set_mac_address;
>> - ndev->set_multicast_list = mpc52xx_fec_set_multicast_list;
>> - ndev->tx_timeout = mpc52xx_fec_tx_timeout;
>> - ndev->watchdog_timeo = FEC_WATCHDOG_TIMEOUT;
>> - ndev->base_addr = mem.start;
>> -#ifdef CONFIG_NET_POLL_CONTROLLER
>> - ndev->poll_controller = mpc52xx_fec_poll_controller;
>> -#endif
>> + ndev->netdev_ops = &mpc52xx_fec_netdev_ops;
>>
>> priv->t_irq = priv->r_irq = ndev->irq = NO_IRQ; /* IRQ are free for now */
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply related
* Re: [git pull] for both tip and powerpc
From: Ingo Molnar @ 2009-02-19 11:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: linuxppc-dev, Andrew Morton, LKML, Frédéric Weisbecker
In-Reply-To: <alpine.DEB.1.10.0902181408160.11411@gandalf.stny.rr.com>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> Ingo and Benjamin,
>
> As discussed, I made a branch called mainline/function-graph-tracer
> based off of Linus's commit:
>
> commit d2f8d7ee1a9b4650b4e43325b321801264f7c37a
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Fri Feb 13 15:31:30 2009 -0800
>
> Linux 2.6.29-rc5
>
>
> and cherry picked the below change. I added Ingo's Acked-by as well. If
> both of you pull this change in (assuming both trees are already based
> off of Linus's 2.6.29-rc5) then there should be no conflicts when this
> gets merged back to Linus's tree.
>
> I will not touch this branch again, until it is officially in mainline.
>
> Please pull the latest mainline/function-graph tree, which can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> mainline/function-graph
>
>
> Steven Rostedt (1):
> tracing/function-graph-tracer: make arch generic push pop functions
>
> ----
> arch/x86/include/asm/ftrace.h | 25 -----------
> arch/x86/kernel/dumpstack.c | 1 +
> arch/x86/kernel/ftrace.c | 75 +---------------------------------
> include/linux/ftrace.h | 24 +++++++++++
> kernel/trace/trace_functions_graph.c | 75 ++++++++++++++++++++++++++++++++++
> 5 files changed, 101 insertions(+), 99 deletions(-)
Pulled into tip:tracing/function-graph-tracer, thanks Steve!
Ingo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox