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
gianfar.tar.gz
Description: gianfar.tar.gz
_______________________________________________ etherlab-dev mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-dev
