Greg KH wrote:
On Mon, Jan 16, 2012 at 10:19:46PM +0100, Jan Müller wrote:
Dear all,
I try adapting a network driver (net/ethernet/xilinx/ll_temac) for
my needs, but I'm not sure I understand the issues involved.
What are your needs? Specifically please.
In a Xilinx FPGA, I have a hardware wrapper around the ll_temac eth-core.
This wrapper keeps the ll_temac busy most of the time. So, the throughput as
seen by the CPU (microblaze) is quite reduced. (i.e. the driver should be
able to cope with that)
The ll_temac driver from the kernel seems to work fine (for ping, telnet)
but when stress-tested (nc) after a while it 'locks-up'. More precisely, the
tx-buffer does not get cleared by the hw as expected by the driver. Likely,
my interfacing with the wrapper is a little buggy. I'm a bit lost with
debugging, but I think the issue might be some irqs getting lost. I thought
it might be possible to get the driver working even with buggy hardware
(watchdog timer?).
> And why are you modifying
> this specific one?
I wanted to keep/reuse all the house-keeping this driver already does for
its hardware (which is basically the same in my case).
Maybe someone of you could point me in the right directions?
For instance, does the *skb structure passed to the start_xmit
function has to be freed by the network driver in any case? I.e. not
calling dev_kfree_skb(skb) anywhere in the driver is a bug?
I'm a bit confused about the need for locking tx-buffers (for
SG-dma). Somewhere (in the comments for another driver) I've read
the calls to start_xmit are serialised anyway? And then clearing the
dma tx buffer in the tx_irq should be fine because it should not get
interrupted?
Could you maybe recommend a simple "role model" net/ethernet/ driver
I should have a look at? One which implements a locked tx buffer (in
case you think that's needed at all)
Have you looked at the network skeleton driver?
find . -name "*skel*"
Uuhm, in the kernel sources? Where can I find it?
Thanks!
Jan
thanks,
greg k-h
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
