Re: [PATCH] Enable hashdist by default on PowerPC
From: Anton Blanchard an...@samba.org Date: Wed, 18 Feb 2009 16:11:12 +1100 @@ -145,9 +145,10 @@ extern void *alloc_large_system_hash(const char *tablename, #define HASH_EARLY 0x0001 /* Allocating during early boot? */ /* Only NUMA needs hash distribution. - * IA64 and x86_64 have sufficient vmalloc space. + * IA64, x86_64 and PowerPC have sufficient vmalloc space. */ -#if defined(CONFIG_NUMA) (defined(CONFIG_IA64) || defined(CONFIG_X86_64)) +#if defined(CONFIG_NUMA) (defined(CONFIG_IA64) || defined(CONFIG_X86_64) || \ + defined(CONFIG_PPC64)) #define HASHDIST_DEFAULT 1 #else #define HASHDIST_DEFAULT 0 I should probably do this on sparc64 too. Why don't we just change this thing to CONFIG_64BIT? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
net_device_ops support in bridging and fec_mpc52xx.c
Hello,
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
Re: Regarding irq_of_parse_and_map
I checked and read the
Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt and
booting-without-of.txt. It is different then what I read before from
booting-without-of.txt ... perhaps as it is old and came with BSP. Am
I right ? ? ?
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 ? ? ?
Also what would be the problem if I do in the same way as it is given
in BSP mpc8313erdb.dts ? ? ?
And should I use gpio-controller as a gpio device node ? ? ?
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
On 2/17/09, Scott Wood scottw...@freescale.com wrote:
Vijay Nikam wrote:
I added the gpio node as follows to mpc8313erdb.dts;
g...@c00 {
linux,phandle = c00;
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.
device_type = gpio;
No device_type.
The only thing I need to know what should I write at 'compatible' tag
? ? ? the compatible tag format is manufacturer,model the
manufacturer is 'fsl' i.e. I think freescale but the model, as it is
the model number where I can find this model ? ? ? Please let me know
... thanks ...
compatible = fsl,mpc8313-gpio, fsl,mpc8349-gpio;
Also I would like to ask if the above device node is written according
to bindings ... I think it should be right as I referred
'bootingwithout-of.txt' ... but please correct me if I am worng ? ? ?
See also
Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt.
Also note that current Linux has a driver in
arch/powerpc/sysdev/mpc8xxx_gpio.c.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Gianfar tx-babbling-errors
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 ___ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v1] virtio: add virtio-over-PCI driver
On Wed, Feb 18, 2009 at 05:13:03PM +1030, Rusty Russell wrote: On Wednesday 18 February 2009 08:54:25 Ira Snyder wrote: This adds support to Linux for using virtio between two computers linked by a PCI interface. This allows the use of virtio_net to create a familiar, fast interface for communication. It should be possible to use other virtio devices in the future, but this has not been tested. Hi Ira, It's only first glance, but this looks sane. Two things on first note: don't restrict yourself to 32 feature bits (only PCI does this, and they're going to have to hack when we reach feature 32). There isn't any problem adding more feature bits. Do you think 128 bits is enough? Secondly: +You will notice that the algorithm has no way of handling chains that are +not exactly the same on the host and guest system. Without setting any of +the fancier virtio_net features, this is the case. Hmm, I think we can do slightly better than this. I think so too :) I just wasn't able to come up with an algorithm to make it work. And I wanted input from more experienced people. How about prepending a 4 byte length on the host buffers? Allows host to specify length (for host-guest), and guest writes it to allow truncated buffers on guest-host. That won't allow you to transfer *more* than one buffersize to the host, but you could use a different method (perhaps the 4 bytes indicates the *total* length?). I don't understand how this will help. I looked at virtio_net's implemention with VIRTIO_NET_F_MRG_RXBUF, which seems like it could really help performance. The problems with that are: 1) virtio_net doesn't write the merged header's num_buffers field 2) virtio_net doesn't actually split packets in xmit The problem with 1 is that one instance of virtio_net cannot talk to another, if they're using that feature. The sender never sets the field, so the receiver doesn't know how many buffers to expect. I'm using two instances of virtio_net to talk to each other, rather than a special userspace implementation like lguest and kvm use. Is this a good approach? The problem with 2 is that xmit may add the following to the descriptors: (the network stack doesn't have to split the packet) idx address len flags next 0 XXX 12 N1 1 XXX 8000 -2 With VIRTIO_NET_F_MRG_RXBUF, the other side's recv ring will look like the following: idx address len flags next 0 YYY 4096 -1 1 YYY 4096 -2 2 YYY 4096 -3 So how do we pair up buffers to do DMA? Do I munge the header from virtio_net to set the num_headers field, and split the 8000 bytes of data into two parts? (Giving 12 bytes in desc 0, 4096 bytes in desc 1, and 3904 bytes in desc 2) The current implementation only handles something like the following, which would be an ARP: xmit descriptors: idx address len flags next 0 XXX 10 N1 1 XXX 42 -2 recv descriptors: idx address len flags next 0 YYY 10 N1 1 YYY 1518 -2 Then the algorithm is simple, no munging necessary. All chains are the same length (2 entries) and the length of each buffer is suffient to handle the data. The network stack splits the packets into = 1518 byte chunks for us (as long as MTU isn't changed). Do 4-byte DMA's suck for some reason? I don't think it would hurt much. Some of the fancier features might offset any overhead that is added. Thanks, I appreciate the feedback. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v1] virtio: add virtio-over-PCI driver
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Regarding irq_of_parse_and_map
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Gianfar tx-babbling-errors
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Gianfar tx-babbling-errors
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? Scott ___ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Gianfar tx-babbling-errors
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: NFS-boot on PS3, kboot can't mount nfs-dir.s
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] for both tip and powerpc
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 torva...@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 srost...@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 fweis...@gmail.com
Acked-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Steven Rostedt srost...@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(current-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(current-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;
-
-
RE: Gianfar tx-babbling-errors
Kumar, 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 Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
CPU hotplug /sys entries are missing on 2.6.28
/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 root0 9 feb 23:15 .
drwxr-xr-x 7 root root0 9 feb 23:15 ..
drwxr-xr-x 4 root root0 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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: net_device_ops support in bridging and fec_mpc52xx.c
From: Henk Stegeman henk.stege...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: net_device_ops support in bridging and fec_mpc52xx.c
On Wed, 18 Feb 2009 13:48:52 -0800 (PST) David Miller da...@davemloft.net wrote: From: Henk Stegeman henk.stege...@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? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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):
soc8...@e000 {
...
m...@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 24520 20;
/* Vitesse 8201 */
phy1c: ethernet-...@1c {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
tbi0: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
m...@25520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-tbi;
reg = 25520 20;
tbi1: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
ether...@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;
};
ether...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
-Original Message-
From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@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):
soc8...@e000 {
...
m...@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 24520 20;
/* Vitesse 8201 */
phy1c: ethernet-...@1c {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
tbi0: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
m...@25520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-tbi;
reg = 25520 20;
tbi1: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
ether...@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;
};
ether...@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
RE: [RFC v1] virtio: add virtio-over-PCI driver
-Original Message- From: linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs .org] On Behalf Of Ira Snyder Sent: Wednesday, February 18, 2009 6:24 AM To: linux-ker...@vger.kernel.org Cc: linuxppc-dev@ozlabs.org; net...@vger.kernel.org; Rusty 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 If unsure, say M. +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 using virtio + over the PCI bus with a Freescale MPC8349EMDS 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 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) += virtio.o obj-$(CONFIG_VIRTIO_RING) += virtio_ring.o obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o +obj-$(CONFIG_VIRTIO_OVER_PCI_HOST) += vop_host.o +obj-$(CONFIG_VIRTIO_OVER_PCI_FSL) += 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 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC v1] virtio: add virtio-over-PCI driver
-Original Message- From: linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs .org] On Behalf Of Kumar Gala Sent: Thursday, February 19, 2009 0:47 AM To: Ira Snyder Cc: Arnd Bergmann; Jan-Bernd Themann; net...@vger.kernel.org; Rusty Russell; linux-ker...@vger.kernel.org; linuxppc-dev@ozlabs.org Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver 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. why? Roy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
Thanks for the swift response. 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. That fn doesn't exist in the dev tree I'm using (commit 103f194f3ccf46842548eb52e607167b6d4951ef) The driver is now initialised through of_device. I can't figure out how the probe handler is invoked. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
-Original Message-
From: Dushara Jayasinghe [mailto:dusha...@optiscan.com]
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
series device.
Thanks for the swift response.
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.
That fn doesn't exist in the dev tree I'm using (commit
103f194f3ccf46842548eb52e607167b6d4951ef)
The driver is now initialised through of_device. I can't
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[] = {
{ .compatible = fsl,pq2pro-localbus, },
{ .compatible = 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);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to bring up fs_enet on 2.6.27?
On Thu, Jan 29, 2009 at 12:16 PM, Mike Ditto mdi...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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@ozlabs.org
[mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@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@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@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):
soc8...@e000 {
...
m...@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 24520 20;
/* Vitesse 8201 */
phy1c: ethernet-...@1c {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
tbi0: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
m...@25520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-tbi;
reg = 25520 20;
tbi1: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
ether...@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;
};
ether...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
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.aggr...@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@ozlabs.org
[mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@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@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@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):
soc8...@e000 {
...
m...@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 24520 20;
/* Vitesse 8201 */
phy1c: ethernet-...@1c {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
tbi0: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
m...@25520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-tbi;
reg = 25520 20;
tbi1: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
ether...@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;
};
ether...@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
Re: open-pic device tree node and subnodes for additional functionality?
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Newby trying to get Ethernet going on MPC83xx series device.
On Thu, Feb 19, 2009 at 2:58 PM, Dushara Jayasinghe
dusha...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
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@gmail.com [mailto:pku@gmail.com] On Behalf
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
series device.
On Thu, Feb 19, 2009 at 2:58 PM, Dushara Jayasinghe
dusha...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
