OpenBSD Journal

Developer blog: cnst@: wbng(4) and how it was written

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 dmesg@openbsd.org 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)


Comments
  1. By Anonymous Coward (24.37.242.64) on

    Cool, I never knew about that dmesglog archive and if it can help out in any way, it's no trouble for me to email it.

    I'll send one once 4.2 is out and installed on this ASUS system, along with 4.2 from my WRAP box too (if it's worth it?).

    Comments
    1. By cnst (cnst) on

      > Cool, I never knew about that dmesglog archive and if it can help out in any way, it's no trouble for me to email it.
      >
      > I'll send one once 4.2 is out and installed on this ASUS system, along with 4.2 from my WRAP box too (if it's worth it?).

      Yes, please do so! It is always helpful to see which devices are out there, so even if all devices in your system are configured and detected properly, it is still helpful for us to see how things work out and what hardware most people have.

      And in case you have an unsupported device or two, mailing in a dmesg to our private dmesg archive is a polite way of saying, "I have this hardware, and it'll be nice if it is supported one day". :)

      So feel free to mail in dmesgs from all of your systems every release (and even dmesgs from snapshots from time to time)! It is also nice if people include `sysctl hw.sensors` output, too. ;)

      Comments
      1. By sthen (85.158.45.32) on

        > And in case you have an unsupported device or two, mailing in a dmesg to our private dmesg archive is a polite way of saying, "I have this hardware, and it'll be nice if it is supported one day". :)
        >
        > So feel free to mail in dmesgs from all of your systems every release (and even dmesgs from snapshots from time to time)! It is also nice if people include `sysctl hw.sensors` output, too. ;)

        Try and setup your email system first (or at least include a reachable email address somewhere), since developers may see something they'd like to ask a question about. These are only seen by OpenBSD developers.

        And don't forget, if your dmesg is full of errors/warnings pushing the device list off the top, you should be able to find a clean one in /var/run/dmesg.boot.

        The really useful format is an un-mangled, non-word-wrapped dmesg as plain ASCII text in the message body.

        This might all seem obvious, but experience shows that sometimes it isn't. (-:

        Also be aware that the message may get greylisted, so please keep the machine switched on for a while (watch mailq), or send it from/through another machine.

        Comments
        1. By Anonymous Coward (24.37.242.64) on

          > > And in case you have an unsupported device or two, mailing in a dmesg to our private dmesg archive is a polite way of saying, "I have this hardware, and it'll be nice if it is supported one day". :)
          > >
          > > So feel free to mail in dmesgs from all of your systems every release (and even dmesgs from snapshots from time to time)! It is also nice if people include `sysctl hw.sensors` output, too. ;)
          >
          > Try and setup your email system first (or at least include a reachable email address somewhere), since developers may see something they'd like to ask a question about. These are only seen by OpenBSD developers.
          >
          > And don't forget, if your dmesg is full of errors/warnings pushing the device list off the top, you should be able to find a clean one in /var/run/dmesg.boot.
          >
          > The really useful format is an un-mangled, non-word-wrapped dmesg as plain ASCII text in the message body.
          >
          > This might all seem obvious, but experience shows that sometimes it isn't. (-:
          >
          > Also be aware that the message may get greylisted, so please keep the machine switched on for a while (watch mailq), or send it from/through another machine.

          Excellent stuff!

          This is great if I can help, while not being a developer myself.

          By 4.2, I'll have at least 4 systems I can email. AMD64-X2 with nForce 570 Ultra on SATA 300 with nfe(4) Gb NIC (if supported), two other i386 based (Intel / AMD) systems and of course my WRAP box (Geode SC1100) + I can boot off of a USB attached HD on other systems that are currently running Windows.

          Is it also worth sending the dmesg for both 32bit and 64bit mode of the AMD64-X2, running both bsd and bsd.mp in each mode or port or would that be redundant information?

          Thanks!

          Comments
          1. By sthen (85.158.45.32) on

            > By 4.2, I'll have at least 4 systems I can email. AMD64-X2 with nForce 570 Ultra on SATA 300 with nfe(4) Gb NIC (if supported), two other i386 based (Intel / AMD) systems and of course my WRAP box (Geode SC1100) + I can boot off of a USB attached HD on other systems that are currently running Windows.
            >
            > Is it also worth sending the dmesg for both 32bit and 64bit mode of the AMD64-X2, running both bsd and bsd.mp in each mode or port or would that be redundant information?

            As far as I'm aware, the more the better. -current snapshots would be better still (especially if you have anything with exotic RAM, to help test out the new spdmem driver). You can boot a -current kernel on a system with 4.2 binaries, but in that case you probably won't have working network (due to data structure changes for 64-bit counters), in which case you'd need to write dmesg to disk and reboot to 4.2 to mail it.

  2. By vext01 (194.66.64.120) on

    Great, this has encouraged me to send the dmesg's of my machines to dmesg@.

  3. By Anonymous Coward (75.118.13.31) on

    will send my dmesg also for an NVIDIA nForce 570 SLI MCP, amd64 x2 with 4G ddr2, and HDA audio

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]