![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
hansdegoedePeople who know me, will probably be asking to themselves: Hans, a blog?? Well all the cool kids are doing it, so I thought I should have a go at it too. Don't expect me writing about my personal life much here, this will mostly be a log of my Linux / Fedora hacking activities.
For starters, here's what I've been up to the last week.
Monday the 2nd:
Jean Delvare send a mail to the lm_sensors mailinglist requesting people to convert all hwmon drivers which haven't been converted yet to the new and much better individual alarm files sysfs interface. Since my work machine has an fscher chip I offered todo this for this chip. I worked on this as work permitted.
Since my abituguru3 driver for the 3th revision of Abits custom hardware monitoring chip has been queued for 2.6.23 merging, I decided to also spend some time and energy making sure it would be in perfect condition, resolving this bug, resulting in this patch.
Tuesday:
Despite this being meetings and more meetings day at work (10h-12h, 12h-12h30, 15h-17h), I still managed to get some Linux stuff done in between and mainly in the evening.
I finished converting the lm_sensors / hwmon fscher driver to the new interface, resulting in this patch, or atleast I thought I did. Since the fscpos driver is quite similar to the fscher driver, I did the same for the fscpos driver.
While working on this I discovered some flaws in the new libsensors-3.x code. Thus I also did some hacking on that and committed some simple fixes to svn. I really hope that we can make a release of the 3.x branch soon, as its a huge improvement over 2.x . It drops supports for the 2.4 kernel proc interface, and by doing this it no longer needs to have knowledge of each and every hwmon driver in the kernel, as with the 2.6 sysfs interface the capabilities of a chip can be read from the sysfs interface. This means that people who have just compiled a new kernel to get their hardware monitoring to work, do not need to also get the latest libsensors and sensors, as the new libsensors will "just work" (tm) with any new drivers.
That evening someone was so kind to send me a datasheet for the fscpos and fscher chips, much improving my understanding of these 2 chips, and thus rendering my 2 patches obsolete ...
Wednesday:
Another fun meetings day, yet again I managed to get some Linux stuff done too.
As said my 2 individual alarm file patches where obsolete the day they were posted, so I wrote 2 improved ones: fscher, fscpos. However writing these second versions resulted in an interesting discussion about what todo with hwmon chips who do not clear their alarm flags, which rendered these versions obsolete too (lalala).
In the evening I wrote libsensors-2.x and sensors support for the soon to be upstream abituguru3 driver, so that that will make the lm_sensors-2.10.4 cut.
Thursday:
I finally managed to make a couple of hours free to finish the fintek f71882fg hardware monitoring functions driver I've been working on. If you read this and have a motherboard featuring one of these, any testing you can do is much appreciated. The driver is posted here, with compile instructions (and a Makefile attached) here. libsensors support and sensors support will be available in lm_sensors 2.10.4 which should be released within a couple of days. If you prefer a patch against the full kernel instead of a standalone module compile, that is available here.
Friday:
Time to finally create a final version of the individual alarms support for the fscher driver. Properly implementing the new sysfs API requires resetting the alarms from the driver once the cause for the alarm is gone, thats easier then it sounds though since the threshold above which the fscher raises a temperature alarm, isn't documented in the datasheet (GRRRRR). So it was time for some good old fashion reverse-engineering. i2cdump is your friend in this case. Luckily I immediately saw a couple of registers which looked like temperature limits from their readings and the addresses where in the same range as the temperature status registers, so they looked like good candidates. Thus I not only managed to find the threshold but also exported it to userspace and made it configurable from userspace, with this and auto alarm resetting I'm now done with this.
The weekend:
I've become a co-maintainer of the lm_sensors package in Fedora, so I've spend the weekend merging Fedora's lm_sensors package upstream to both the 2.x and 3.x branches, and all that just before the 2.10.4 svn freeze. So hopefully Fedora's 2.10.4 package will contain no patches.
I also reviewed the first version of an adt7470 driver, did various cleanups and fixes to the lm_sensors 3.x branch and wrote this patch to stop the abituguru driver from loading on non Abit motherboards.
Monday the 9th:
Aka yesterday, as already written above the fscpos is very similar to the fscher hwmon chip, sharp readers may have noticed that I never did create a third and final version of my indiviual alarm files patch for the fscpos. Thats because during the weekend I've written a patch for the fscher driver, to also support the fscpos, this seems the best way forward as they really are 99% identical. Comparing datasheets register by register and driver code line by line is _very_ boring, but was necessary in this case. Yesterday I "tested" this on my work machine with has an fscher, this lead to some minor fixes (mainly to make it compile, oops) with as end result this patch. As noticed in the mail I didn't actually try the fscpos support as I don't have a machine with an fscpos, I merely tested the driver still works on an fscher. If you happen to have a Fujitsu Siemens machine which uses the fscpos driver, any testing you can do would by very much appreciated.
The rest of the day I spend hunting results of students to get an overview for the propedeutic exam. Long live our "fantastic" new student tracking system. If you work in education and someone ever tries to sell you a student tracking system called 'Osiris', you only need to know one word: NO, so in that scenario just say, or preferably yell: NOOO!
Tuesday:
I've been toying with the idea todo a blog for some time now, so here we are. Besides starting a blog I've been working on the open bugs list for the Fedora lm_sensors package and I'm making nice progress. Expect lm_sensors to have 0 open bugs soon.
For starters, here's what I've been up to the last week.
Monday the 2nd:
Jean Delvare send a mail to the lm_sensors mailinglist requesting people to convert all hwmon drivers which haven't been converted yet to the new and much better individual alarm files sysfs interface. Since my work machine has an fscher chip I offered todo this for this chip. I worked on this as work permitted.
Since my abituguru3 driver for the 3th revision of Abits custom hardware monitoring chip has been queued for 2.6.23 merging, I decided to also spend some time and energy making sure it would be in perfect condition, resolving this bug, resulting in this patch.
Tuesday:
Despite this being meetings and more meetings day at work (10h-12h, 12h-12h30, 15h-17h), I still managed to get some Linux stuff done in between and mainly in the evening.
I finished converting the lm_sensors / hwmon fscher driver to the new interface, resulting in this patch, or atleast I thought I did. Since the fscpos driver is quite similar to the fscher driver, I did the same for the fscpos driver.
While working on this I discovered some flaws in the new libsensors-3.x code. Thus I also did some hacking on that and committed some simple fixes to svn. I really hope that we can make a release of the 3.x branch soon, as its a huge improvement over 2.x . It drops supports for the 2.4 kernel proc interface, and by doing this it no longer needs to have knowledge of each and every hwmon driver in the kernel, as with the 2.6 sysfs interface the capabilities of a chip can be read from the sysfs interface. This means that people who have just compiled a new kernel to get their hardware monitoring to work, do not need to also get the latest libsensors and sensors, as the new libsensors will "just work" (tm) with any new drivers.
That evening someone was so kind to send me a datasheet for the fscpos and fscher chips, much improving my understanding of these 2 chips, and thus rendering my 2 patches obsolete ...
Wednesday:
Another fun meetings day, yet again I managed to get some Linux stuff done too.
As said my 2 individual alarm file patches where obsolete the day they were posted, so I wrote 2 improved ones: fscher, fscpos. However writing these second versions resulted in an interesting discussion about what todo with hwmon chips who do not clear their alarm flags, which rendered these versions obsolete too (lalala).
In the evening I wrote libsensors-2.x and sensors support for the soon to be upstream abituguru3 driver, so that that will make the lm_sensors-2.10.4 cut.
Thursday:
I finally managed to make a couple of hours free to finish the fintek f71882fg hardware monitoring functions driver I've been working on. If you read this and have a motherboard featuring one of these, any testing you can do is much appreciated. The driver is posted here, with compile instructions (and a Makefile attached) here. libsensors support and sensors support will be available in lm_sensors 2.10.4 which should be released within a couple of days. If you prefer a patch against the full kernel instead of a standalone module compile, that is available here.
Friday:
Time to finally create a final version of the individual alarms support for the fscher driver. Properly implementing the new sysfs API requires resetting the alarms from the driver once the cause for the alarm is gone, thats easier then it sounds though since the threshold above which the fscher raises a temperature alarm, isn't documented in the datasheet (GRRRRR). So it was time for some good old fashion reverse-engineering. i2cdump is your friend in this case. Luckily I immediately saw a couple of registers which looked like temperature limits from their readings and the addresses where in the same range as the temperature status registers, so they looked like good candidates. Thus I not only managed to find the threshold but also exported it to userspace and made it configurable from userspace, with this and auto alarm resetting I'm now done with this.
The weekend:
I've become a co-maintainer of the lm_sensors package in Fedora, so I've spend the weekend merging Fedora's lm_sensors package upstream to both the 2.x and 3.x branches, and all that just before the 2.10.4 svn freeze. So hopefully Fedora's 2.10.4 package will contain no patches.
I also reviewed the first version of an adt7470 driver, did various cleanups and fixes to the lm_sensors 3.x branch and wrote this patch to stop the abituguru driver from loading on non Abit motherboards.
Monday the 9th:
Aka yesterday, as already written above the fscpos is very similar to the fscher hwmon chip, sharp readers may have noticed that I never did create a third and final version of my indiviual alarm files patch for the fscpos. Thats because during the weekend I've written a patch for the fscher driver, to also support the fscpos, this seems the best way forward as they really are 99% identical. Comparing datasheets register by register and driver code line by line is _very_ boring, but was necessary in this case. Yesterday I "tested" this on my work machine with has an fscher, this lead to some minor fixes (mainly to make it compile, oops) with as end result this patch. As noticed in the mail I didn't actually try the fscpos support as I don't have a machine with an fscpos, I merely tested the driver still works on an fscher. If you happen to have a Fujitsu Siemens machine which uses the fscpos driver, any testing you can do would by very much appreciated.
The rest of the day I spend hunting results of students to get an overview for the propedeutic exam. Long live our "fantastic" new student tracking system. If you work in education and someone ever tries to sell you a student tracking system called 'Osiris', you only need to know one word: NO, so in that scenario just say, or preferably yell: NOOO!
Tuesday:
I've been toying with the idea todo a blog for some time now, so here we are. Besides starting a blog I've been working on the open bugs list for the Fedora lm_sensors package and I'm making nice progress. Expect lm_sensors to have 0 open bugs soon.
