Mark M. Hoffman wrote: > Hi Hans: > > * Hans de Goede <j.w.r.degoede at hhs.nl> [2007-04-15 21:46:07 +0200]: >> Hi Mark, All >> >> First of all, Mark great to hear you're stepping in to become the Maintainer >> and many thanks for this. >> >> Mark M. Hoffman wrote: >>> Hi everyone: >>> >>> Here's a list of kernel patches which are not in Jean's queue[1] and which need >>> review. I've only searched the mailing list archives back through March. I'm >>> sure I've missed some, or if there are updated patches available for any of >>> these, please let me know. >>> >> I think you've missed the admXXXX driver backported from 2.4 which was posted a >> while ago. > > Err, I still can't find it. Can you post a link please? > Its here: http://lists.lm-sensors.org/pipermail/lm-sensors/2007-March/019094.html >>> PATCH: hwmon-abituguru3-new-driver.patch: Add support for newer uGuru's >>> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-April/019433.html >>> primary reviewer: Juerg Haefliger >>> >> The biggest problem with this patch currently is the discussion about the >> included chip model/revision/stepping table, which is (somewhat) needed because >> with the uguru being a software solution every motherboard essentially has its >> own version of the chip. >> >> Jean didn't like this much because he believes this kinda info belongs in >> userspace. I've given a long reply to a mail of Jean where I explain why I >> decided to put the table in kernelspace and that I still believe this to be the >> right decision. Unfortunately that mail has gotten 0 replies. > > Yes, I remember skimming those discussions. I will reread that more closely > and reply in the appropriate thread... soonish. Please be patient. I can tell > you now that I am inclined to allow such a patch to spend some time in -mm to > either 1) work out the kinks of that approach, or else 2) demonstrate that > userspace would be better. > Ok, notice though that there are no real kinks either way its just a design decision really. I'm pretty sure there are no kinks with the current table in driver variant, as it has been tested by several people on several different mobo's. As far as I can currently oversee the userspace variant, that shouldn't have any issues either, but IMHO is ugly as it creates sysfs files which aren't there which then will get picked up by the dynfs support, only to finally get ignored by ignore statements in sensor.conf, why create them in the first place then? Anyways this has already been said in the appropriate thread. SO I'm looking forward to your reply there. Notice that the thread is "hidden" under the subject of "xxx_label sysfs file proposal" or something like that. Regards, Hans
