ACPI power management is still fairly new in Syllable, and few drivers implement support for it. For most modern hardware it's fairly simple to add support though.

There are two additional functions our driver must export to support power management. They are defined in the system header file <atheos/device.h> :

These functions are similar to device_init() and device_uninit() functions. The pPrivateData argument in both of these functions is the pointer that was previously set by calling the function set_device_data() . In our case, it is a pointer to our instance of the net_device structure.

It's a fairly simple task to port the tg3_suspend() and tg3_resume() functions to Syllable. Apart from changing the timer handling to fit Syllable we also have to change the call to tg3_set_power_state() in device_suspend() from:

to

The effect is the same. It seems we do also need the function tg3_restart_hw() , which was previously unused and removed from the driver. Again, it is a simple task to re-add the function to the driver.

We have ignored tasks upto now. The Linux kernel implements the concept of "tasklets", which are essentially kernel threads that can be scheduled by the driver to perform a small piece of work that is required. The tg3 driver has one task, which is performed by the function tg3_reset_task() . That task may be scheduled at two points in the driver with the following function call:

Tasklets are not something Syllable implements. If we wanted too, we could always emulate them with a kernel thread. Instead of calling schedule_work() we would instead unlock a mutex that the thread was waiting on, causing it to run.

For now we'll adopt a simpler aproach of simply calling tg3_reset_task() directly. This has the disadvantage that the task is performed from "inside" the interrupt handler, but it is unlikely to be a problem.

When the driver is unloaded by the kernel it will call the device_uninit() function as a way of informing the driver. Syllable 0.6.2 added a new function:

device_release() is called by the kernel before device_uninit() . It is passed the same data as device_suspend() and device_resume() , that is the drivers DeviceID, the handle returned by claim_device() and the private data set with set_device_data() .

We can use device_release() to shut down the card and clean up instead of device_uninit() . If we do that, we no longer need to store the device handle in a global variable. This means that the driver will able to work with multiple devices in one machine.

Changing our driver is simple. We take the code from device_uninit() and move it to our new device_release() function, with a few additional changes to take advantage of the additional device parameters. The device_release() function looks like this:

We can remove all references to the global g_nDeviceHandle variable.

The device_uninit() function is still required by Syllable but now it has little to do:

We can also make a few smaller tweaks and changes. We'll clean up the defines for DEBUG_LIMIT at the top of the file and enclose them in an #if block so that we can easily "switch on" debugging again should we need to.

We'll also change the name that is passed to claim_device(). Currently the device is claimed as a "Broadcom Tigon3", but most Broadcom users would probably know these cards by the name "Broadcom NetExtreme", so that's what we'll use.

It's also probably a good idea if we move the small piece of code we added to set an MTU value when we were debugging the Rx codepath. We'll move it into tg3_probe() where some other default values are set in our net_device instance.

There are still a handful of places in the driver where we have been forced to comment out blocks of code inside #if blocks. Most of this code deals with scanning the PCI bus using Linux-specific functions. Right now we will not be implementing any support for this code on Syllable. The downside is that the driver may not work correctly on certain motherboard chipsets or with certain configurations, but those are limited. We can revisit these blocks of code at a later date, when we have a suitable solution that will work with Syllable.

We've now ported a network driver to Syllable. We've covered some important topics and shown how to debug your driver in practical terms. Here are some things to remember as you work on your own code:

• You can use the example driver we started with in part 1 as a base for your driver.
• Follow the code path in a logical manner. There are several points during development where the next stage in your port should be obvious.
• Work in small chunks, porting no more than one or two functions at a time. If you try to port 5000 lines in one go you'll quickly sink under the feeling of having bitten off more than you can chew.
• Comment out any code you do not fully understand and comment it to remind yourself why you commented it out, and to help you find it later.
• Refer to this series, existing drivers and the Linux documentation for help on understanding specific functions.
• Test and debug your driver at every available opportunity. You can catch some bugs and fix them even without porting the entire driver.
• Try to change as little of the code as possible. It will make it easier to maintain and update the driver in the future.
• It may be better to add to linux_compat.h instead of changing the code in the driver. If you make any changes, make sure you submit them back to the Syllable developers so that it can be merged back into the main source tree.
• Work on the core functionality first and ensure that it is working before you add support for optional extras. Just remember that sometimes a function that looks optional may be important!
• Check your assumptions. What you thought was correct may be wrong.
• Debugging is hard work but necessary. Just keep at it, and try everything.
• You don't need to port everything. Linux implements functionality that Syllable does not, such as VLAN support and ethertool. Not having to port the code for these can mean the Syllable driver can be thousands or hundreds of lines shorter than the Linux driver.
• If you're stuck, ask. There are people who have been there before you and may be able to help.