Done.
Take your time on ADM1026.
There's a lot more broken then I'd realized. This will take a couple of weeks.
Philip Pokorny wrote:
> Yes, please use the following patch to update w83781d.c to get it ready
> for automatic sensors.h...
>
> Index: kernel/chips/w83781d.c
> ===================================================================
> RCS file: /home/cvs/lm_sensors2/kernel/chips/w83781d.c,v
> retrieving revision 1.99
> diff -u -r1.99 w83781d.c
> --- kernel/chips/w83781d.c 31 Jan 2003 04:00:33 -0000 1.99
> +++ kernel/chips/w83781d.c 2 Jun 2003 06:55:03 -0000
> @@ -426,9 +426,14 @@
> #define W83781D_SYSCTL_IN6 1006
> #define W83781D_SYSCTL_IN7 1007
> #define W83781D_SYSCTL_IN8 1008
> +#define W83781D_SYSCTL_IN9 1009
> +
> #define W83781D_SYSCTL_FAN1 1101 /* Rotations/min */
> #define W83781D_SYSCTL_FAN2 1102
> #define W83781D_SYSCTL_FAN3 1103
> +#define W83781D_SYSCTL_FAN4 1104
> +#define W83781D_SYSCTL_FAN5 1105
> +
> #define W83781D_SYSCTL_TEMP1 1200 /* Degrees Celcius * 10 */
> #define W83781D_SYSCTL_TEMP2 1201 /* Degrees Celcius * 10 */
> #define W83781D_SYSCTL_TEMP3 1202 /* Degrees Celcius * 10 */
>
>
> I should have the ADM1026 patch for you sometime on Monday. To test it
> I'm having to compile on a new machine since my previous development
> machine was a 2.4.7 kernel and it just doesn't work with lm_sensors-cvs...
>
> But I'm finding lots of compile problems with I2C and LM_SENSORS. And
> then even if it does compile, it won't load on the machine I'm testing
> with because of module_put and try_module_get unresolved symbols...
>
> :v)
>
> Mark D. Studebaker wrote:
>
>> I have the answers :)
>>
>> We recently got a patch for adding 791D support to the w83781d driver.
>> The library part of it applied easily and I checked it in.
>> The driver part was against stock 2.7.0 and didn't apply so I asked
>> the person to send us a patch against CVS, which I haven't received yet.
>> So that's why it's in a halfway state.
>>
>> The w83627hf driver is an ISA-only driver for the 627hf and 697hf
>> Super I/O chips.
>> It contains code to find and enable the ISA I/O for the sensors.
>> The support for these chips in w83781d is, for the most part, I2C-only.
>> Many many people have had problems getting these chips to work on the
>> I2C side
>> using w83781d. There's many tickets on helper functions to get the
>> sensors enabled. ISA accesses will be much more dependable.
>> Rather than add more gunk to an already-messy w83781d, I copied
>> it to a new w83627hf driver and cleaned it up.
>>
>> I like your idea about an automatic sensors.h a lot.
>>
>> I guess some of our practices of reusing SYSCTL numbers and other stuff
>> (bmcsensors comes to mind) may be making it more complicated.
>>
>> Do you want me to check the new SYSCTL for 791D into the w83781d driver
>> so that doesn't cause problems for your on-the-fly creation?
>>
>>
>> Philip Pokorny wrote:
>>
>>> I'm working on my ADM1026 patch for CVS and I've decided to work in
>>> something else that was bugging me.
>>>
>>> Namely, the change in kernel/include/sensors.h that means the
>>> #define's are duplicated in sensors.h and in the individual drivers.
>>> It's bugged me since I first heard about it.
>>>
>>> I've modified the Module.mk in kernel/include to create sensors.h on
>>> the fly from the SYSCTL START/END stuff in each of the chips/*.c files.
>>>
>>> It works great, except that the following #defines existed in the
>>> original sensors.h but not in any of the kernel/chips/*.c files. The
>>> real problem though is that they *are* referenced in lib/chips.c!!!
>>>
>>> lib/chips.c:1218: `W83781D_SYSCTL_IN9' undeclared here (not in a
>>> function)
>>> lib/chips.c:1248: `W83781D_SYSCTL_IN9' undeclared here (not in a
>>> function)
>>> lib/chips.c:1278: `W83781D_SYSCTL_IN9' undeclared here (not in a
>>> function)
>>> lib/chips.c:1286: `W83781D_SYSCTL_FAN4' undeclared here (not in a
>>> function)
>>> lib/chips.c:1288: `W83781D_SYSCTL_FAN5' undeclared here (not in a
>>> function)
>>> lib/chips.c:1300: `W83781D_SYSCTL_FAN4' undeclared here (not in a
>>> function)
>>> lib/chips.c:1303: `W83781D_SYSCTL_FAN5' undeclared here (not in a
>>> function)
>>>
>>> These seem to be associated with the W837_9_1D support that was
>>> recently? commited.
>>>
>>> Which leads to the next question which is... Which chip driver
>>> actually implements support for the W83791D? A grep for w83791d
>>> doesn't turn up any *actual* support...
>>>
>>> [root at eng184 lm_sensors2]# find . -type f -print | xargs grep w83791d
>>> ./CHANGES: add lm85 support; add w83791d support
>>> ./CHANGES: Program sensors: add lm85 support; add w83791d support
>>> ./lib/chips.c:static sensors_chip_feature w83791d_features[] =
>>> ./lib/chips.c: { SENSORS_W83791D_PREFIX, w83791d_features },
>>> ./lib/chips.h:#define SENSORS_W83791D_PREFIX "w83791d"
>>> ./prog/sensors/main.c: (!strcmp(name.prefix,"w83791d")) ||
>>>
>>> Which driver is supposed to support this chip?
>>>
>>> And finally, why do both the w83627hf.c and w83781d.c drivers exist.
>>> They use the *same* list of #define entries (W83781D) and appear to
>>> be 80% or more identical. I know that the w83781d driver is
>>> complicated, but when did the w83627hf driver get created and what
>>> does it support? The w83781d driver has "kind" types for the 627hf
>>> and 697hf which are they only kinds in the other driver.
>>>
>>> :v)
>>>
>>
>
>
