I'm trying to write use case diagram for a wireless NIC driver. There is no direct interaction of the user with the driver. How can one write use case diagram for drivers?
Extending the previos 2 answers with a bit more info and an example...
The key aspect of the use case model is its context, or the system scope (depicted with a Boundary element on the diagram itself - see example). Everything that is "inside" the scope is abstracted by a UC and everything from the "outside" is modelled by an actor (human or system). Use cases model the interaction, the dialogue, the exchange of information between the two of them.
I see at least two system actors in your case, a controlled device and a client program. Another possible actor has been added in the following example, to show some eventual periodic communication with the device through the driver:
This is a very nice example on how different UML diagrams play together to show the whole truth. UC diagram focuses on the meaningful interactions between the System and its environment, showing no technical info about it.
In order to do this you need another diagram (here component, but classes are also ok, even both). This diagram is the place to define interfaces, APIs, method signatures, dependencies...
You can of course go a step further and use a sequence/interaction diagram to connect the Use cases with the corresponding components (on my example are only shown the "traces" to clear up which actors are implemented by which components). Something like this:
Note that something called "Data" is sent to the Driver (and the Device). This can further be defined in a class diagram, making a whole new point of view on this system.
It is common practice to put all this info in use case description. Although this approach might even be syntatically correct, the full power of UML is released by separating the concerns in different diagrams, keeping each one as simple and clear as possible, focused on only one concern and clean of others.