[etherlab-dev] Patching PowerPC Ethernet (Gianfar) Driver

[Daniel Bechter]

Hey guys,

these are my first steps in Linux driver programming, so please be patient
with me ;) . I am modifying the PowerPC Ethernet Driver for EtherLab. The
driver's structure and my modifications look as follows:



*** Initialization and startup ***
System calls 'gfar_probe': allocates and initializes the net_devices
structure incl. private data (with ecdev) and registers it with the kernel
via register_netdev if !ecdev (further call to 'gfar_of_init')
IFF_UP triggers net device operation 'gfar_enet_open': resets registers and
calls 'startup_gfar'
'startup_gfar': calls request_irq for interruptTransmit, interruptReceive and
interruptError, installs thair handler functions (only if !ecdev) and calls
'gfar_start'
'gfar_start': initializes some registers (interrupt mask only initialized if
!ecdev)

So I am not registering any interrupt.

I am not registering the device with NAPI within gfar_probe in case of ecdev.
So priv->napi most likely stays NULL and I will have to verify that I am not
accessing it. But I first want to understand initialization and transmit
direction before heading towards receiving.

Can somebody with some experience skim through those init functions and tell
me if I got things right? This would really be cool.

What happens if I do not register the device via register_netdev and call a
netif_* function afterwards?



*** Transmit data ***
net device operation 'gfar_start_xmit'

Here comes the crucial part. I don't really know what is needed in case of
ecdev. So if ecdev, I am currently mapping all fragments (pages) to DMA
before starting I/O transfer.

Do I need to re-allocate the skb with a FCB (Frame Control Block) in front? I
am currently not doing that, see the if (priv->ecdev) block within
'gfar_start_xmit'. Am I missing something in this block?

Do I have to call gfar_clean_tx_ring at any point? In normal interrupt-driven
operation, completion of transmission would trigger gfar_transmit
(interruptTransmit handler), which then triggers gfar_schedule_cleanup, which
schedules a NAPI call. The stack then calls the gfar_poll NAPI callback.
gfar_poll handles cleaning the TX ring (gfar_clean_tx_ring) and receiving
data from the RX ring. At least this is how I understand that part...



I am attaching the current state of the driver sources. Hope somebody can
help me understand the whole init and transmit mechanisms. This is enough for
the time being, before dealing with receiving data...

 <<gianfar.tar.gz>> 

Greets,
Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gianfar.tar.gz
Type: application/x-gzip
Size: 25499 bytes
Desc: gianfar.tar.gz
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20090430/8b104bee/attachment-0003.bin>