Contributed by dwc on from the I-too-see-more dept.
Constantine A. Murenin (cnst@) writes:
Two weeks ago I wrote a new sensor driver, wbng(4). Below is some history on how it was written…
The story started several months ago, when I was having a chat with some Winbond engineers requesting the datasheet to support the W83627DHG chip on my ASUS barebone. The Winbond guys asked me which chips we currently support, and after I've provided them with our extensive list, they've suggested that a new chip called W83793G was released recently, targeted primarily for servers and workstations, and we might want to support it, too. I've put that into my todo list, and after looking at the register set in the datasheet, decided that a new driver had to be written, because the lm-compatibility registers together with the divisor bits “scattered all over the place” are finally all gone (and thank god for that — the new design is just so much cleaner).
As the Winbond W83793G Hardware Monitor chip itself only provides the iic(4), not isa(4), interface, the next step was to look at our dmesglog archive, where users send in their dmesgs. By default in -current since about 3.9, and in releases since 4.1, our i2c_scan.c component automatically outputs the register dump of unsupported i2c devices right into the dmesg. This dump can then be used by developers to identify which I2C chips are present in the machine in question, and to write a probe signature and driver code after confirming details with the datasheets etc.
Grepping through dmesgs in our dmesglog, I've identified that several of our users were in fact having this chip already. So the next step was writing a probe signature and a driver. Having some free time and wanting to write a driver from scratch, I've decided to recreate some of the kernel interfaces in the userland, so that I could use the actual register dump to test the driver without having any hardware.
So that's how the driver was written and tested. A userland programme was used to parse the iic dump and emulate the iic_exec(9) interface, and to call the wbng_ca.ca_attach() function. This resulted in the driver being entirely functional at the time it was committed into OpenBSD, even though it was not tested on real hardware before it was committed. After committing it, I've asked one of our misc@ subscribers, Jon Steel, who previously tried adding a “quick-and-dirty” support for some monitoring capabilities of this chip to the lm(4) driver, to test the new wbng(4) driver, and there it was. :)
As a conclusion, I'd like to thank all of those users that regularly send in their dmesg's to our email@example.com archive. Without them, this and many other drivers would not have been possible. If you, the reader, haven't sent in your dmesg yet, please do try to find a minute to do so — it'll be worth your while in the long run!
(Comments are closed)