I know that device drivers are attached to device controllers, which have their own registers and some local buffer storage. I'm wondering if I can think of device drivers as little state machines -- i.e. do they read and write to memory, or not?
Many device drivers do read/write to memory. For instance, consider a network device; it reads the packets to be sent from memory and writes the packets it receives to memory. Or think of a hard disk driver; it does something analogous. So, ultimately, it will depend on the driver.
That said, device drivers often do have a portion of their internal state that can be thought of a state machine. For instance, the states could be something like UNINITIALIZED, ACTIVE, SUSPENDED, where it is initially in UNINITIALIZED state on boot; after it initializes the device registers, it could transition to ACTIVE state; on suspend, it might put the device into suspend mode and switch to the SUSPENDED state, and so on. This only accounts for part of the behavior of the device driver, but it can still be a helpful way to organize the driver. Or, in other words: often, some important aspects of the driver's behavior or state can be thought of as DFAs even though that's only approximately true.
In software engineering, the "state machine" is more of a design tool than anything else. But yes, many device drivers are designed as state machines. This is because many hardware devices, or the protocols by which you speak to them, have distinct states.
Take the SCSI command protocol as an example. You can do SCSI over many devices (parallel, serial, USB, fibre, etc). However, the idea is the same: Send a command, wait for a response, send another command, wait for another response, and so on.
So we have two logical "states":
State 1: The driver is not waiting for a response from the device.
State 2: The driver is waiting for a response from the device.
There are also two kinds of "event":
Event 1: The operating system asks for some operation to be performed.
Event 2: The device sends a response.
In state 1, event 1 causes the driver to issue a command, and enter state 2. If event 2 happens, then something went wrong.
In state 2, event 1 might cause the driver to buffer the operation (say). Event 2 causes the driver to issue a response to the operating system, and then see if any operations are buffered. If so, issue a new command. If not, enter state 1.
This is a fairly simple device, and already we have something that looks pretty much like a state machine. Moreover, this device is fairly "smart", and doesn't require very much intelligence on the part of the driver. A dumber device, such as a floppy drive (which requires low-level commands like "raise the read/write head" and "move the read/write head 5 tracks that way") might require a lot of states simply because of all the moving parts that it's the responsibility of the driver to keep track of.
In general, a driver needs to keep track of the state of the device, and so state machines are often a very good way to design them.