[2.5] Support for W83627THF sensor chip (Was Re: [2.5] Help
PATCH 1/1 [2.5] Support for W83627THF sensor chip (Was Re: [2.5] Help
Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030617/e2ae133b/attachment.bin
PATCH 1/1 [2.5] Support for W83627THF sensor chip (Was Re: [2.5]
Quoted 9 lines · Mark D. Studebaker
About a week ago I worked with
Matthias Hentges <[email protected]>
to determine the device ID for this chip, and he supplied a patch which I worked into CVS, into the w83627hf driver and into sensors-detect. It was checked in last week.This driver is designed for Super I/O chips and includes detection and activation. It uses ISA accesses.
Ok, checked out CVS.
Quoted 9 lines
I would rather not keep adding to the w83781d cruft, especially for Super I/O chips. Not only is the
driver quite unwieldy already, but people have had lots of trouble with the Winbond Super I/O chips because they often aren't initialzed by the bios so the w83781d driver can't find them. ISA accesses are also much more reliable.Please test the w83627hf driver in CVS and give us some feedback.
Well, it is not yet ported to 2.5, and the state this box is in (NPTL, etc), I _cannot_ use a 2.4 kernel. I also do not know if I currently have the time to port it to 2.5.
Finally, what is the plan .. split the w83781d into smaller drivers for each class of chip ? If so, don't you still need i2c support for some w836* chips? Won't then also be better to call the drivers w837xx.c and w836xx.c ?
Regards,
Signature · 11 lines
Martin Schlemmer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030617/4ebe9368/attachment.bin
PATCH 1/1 [2.5] Support for W83627THF sensor chip (Was Re: [2.5]
In reply to Martin SchlemmerQuoted 6 lines · Mark D. Studebaker
If your patch is all that's required and it tests out well (have you tested it?) then sure, why not. It assumes that a w83627thf is exactly the same as a w83627hf. It's when the additional patches come in
(if kind = w83627thf.....) then it's making a bad situation worse in my opinion.
It is the same chip, except for fan control,etc, which I think is more just for bios/board control, but not having (or being able to get) a data sheet, I cannot verify.
Quoted 6 lines
So my preference is to limit the additions to w83781d.
There's no plans to split the existing w83781d driver. We don't rename existing drivers because of CVS limitations and wanting to minimize changes for our users.
Right, but what about 2.5 side ? Will patches to do this in 2.5 be considered ?
Quoted 5 lines
So I'd feel better about your patch after seeing some test results. And as I said before, you will get the best results by using the new 627hf driver, either after porting it yourself or hoping somebody else does.
I will try to make the time, but not in the next week or so.
What kind of tests do you need ?
Quoted 43 lines
mds
Quoted 39 lines · Martin Schlemmer
Quoted 9 lines · Mark D. Studebaker
About a week ago I worked with
Matthias Hentges <[email protected]>
to determine the device ID for this chip, and he supplied a patch which I worked into CVS, into the w83627hf driver and into sensors-detect. It was checked in last week.This driver is designed for Super I/O chips and includes detection and activation. It uses ISA accesses.
Ok, checked out CVS.
Quoted 9 lines
I would rather not keep adding to the w83781d cruft, especially for Super I/O chips. Not only is the
driver quite unwieldy already, but people have had lots of trouble with the Winbond Super I/O chips because they often aren't initialzed by the bios so the w83781d driver can't find them. ISA accesses are also much more reliable.Please test the w83627hf driver in CVS and give us some feedback.
Well, it is not yet ported to 2.5, and the state this box is in (NPTL, etc), I _cannot_ use a 2.4 kernel. I also do not know if I currently have the time to port it to 2.5.
Finally, what is the plan .. split the w83781d into smaller drivers for each class of chip ? If so, don't you still need i2c support for some w836* chips? Won't then also be better to call the drivers
w837xx.candw836xx.c?Regards,
Signature · 11 lines
Martin Schlemmer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030617/5f75b72c/attachment.bin
PATCH 1/1 [2.5] Support for W83627THF sensor chip (Was Re: [2.5]
In reply to Martin SchlemmerQuoted 8 lines · Martin Schlemmer
Hi
Ok, I was wrong in assuming that the W83627THF was on the I2C bus. It is on the ISA bus, id
0x90(thanks to Alex Van Kaam author of MBM who corrected my assumption).Attached is two patches .. one against sources without my previous broken patch, and one that will revert the broken one.
Ok, I've added this to my tree.
thanks,
greg k-h
PATCH 1/1 [2.5] Support for W83627THF sensor chip (Was Re: [2.5]
In reply to Martin SchlemmerQuoted 9 lines · Martin Schlemmer
Quoted 6 lines
So my preference is to limit the additions to w83781d.
There's no plans to split the existing w83781d driver. We don't rename existing drivers because of CVS limitations and wanting to minimize changes for our users.
Right, but what about 2.5 side ? Will patches to do this in 2.5 be considered ?
Sure, I'm always willing to take patches to fix things.
The kernel tree doesn't have the CVS limitations at all, so feel free to split things up, or rename the driver if you need to :)
thanks,
greg k-h
PATCH 1/1 [2.5] Support for W83627THF sensor chip (Was Re: [2.5]
In reply to Martin SchlemmerAbout a week ago I worked with
Matthias Hentges <[email protected]>
to determine the device ID for this chip, and he supplied a patch which I worked into CVS, into the w83627hf driver and into sensors-detect. It was checked in last week.
This driver is designed for Super I/O chips and includes detection and activation. It uses ISA accesses.
I would rather not keep adding to the w83781d cruft, especially for Super I/O chips. Not only is the
driver quite unwieldy already, but people have had lots of trouble with the Winbond Super I/O chips because they often aren't initialzed by the bios so the w83781d driver can't find them. ISA accesses are also much more reliable.
Please test the w83627hf driver in CVS and give us some feedback.
P.S. I try and keep the 'new drivers' page updated with info on new drivers. It also has info on the best way to investigate and test new chips with existing drivers.
thanks
mds
Quoted 9 lines · Martin Schlemmer
Hi
Ok, I was wrong in assuming that the W83627THF was on the I2C bus. It is on the ISA bus, id
0x90(thanks to Alex Van Kaam author of MBM who corrected my assumption).Attached is two patches .. one against sources without my previous broken patch, and one that will revert the broken one.
PATCH 1/1 [2.5] Support for W83627THF sensor chip (Was Re: [2.5]
In reply to Martin SchlemmerIf your patch is all that's required and it tests out well (have you tested it?) then sure, why not. It assumes that a w83627thf is exactly the same as a w83627hf. It's when the additional patches come in
(if kind = w83627thf.....) then it's making a bad situation worse in my opinion.
So my preference is to limit the additions to w83781d.
There's no plans to split the existing w83781d driver. We don't rename existing drivers because of CVS limitations and wanting to minimize changes for our users.
So I'd feel better about your patch after seeing some test results. And as I said before, you will get the best results by using the new 627hf driver, either after porting it yourself or hoping somebody else does.
mds
Quoted 39 lines · Martin Schlemmer
Quoted 9 lines · Mark D. Studebaker
About a week ago I worked with
Matthias Hentges <[email protected]>
to determine the device ID for this chip, and he supplied a patch which I worked into CVS, into the w83627hf driver and into sensors-detect. It was checked in last week.This driver is designed for Super I/O chips and includes detection and activation. It uses ISA accesses.
Ok, checked out CVS.
Quoted 9 lines
I would rather not keep adding to the w83781d cruft, especially for Super I/O chips. Not only is the
driver quite unwieldy already, but people have had lots of trouble with the Winbond Super I/O chips because they often aren't initialzed by the bios so the w83781d driver can't find them. ISA accesses are also much more reliable.Please test the w83627hf driver in CVS and give us some feedback.
Well, it is not yet ported to 2.5, and the state this box is in (NPTL, etc), I _cannot_ use a 2.4 kernel. I also do not know if I currently have the time to port it to 2.5.
Finally, what is the plan .. split the w83781d into smaller drivers for each class of chip ? If so, don't you still need i2c support for some w836* chips? Won't then also be better to call the drivers
w837xx.candw836xx.c?Regards,
PATCH 1/1 [2.5] Support for W83627THF sensor chip (Was Re: [2.5]
In reply to Martin SchlemmerTesting is admittedly more difficult in 2.5 without a working 'sensors' and libsensors, but catting the sysfs files and verifying the values look good,
maybe changing some limits, is a good start.
I'll let Greg answer the 2.5 question.
Quoted 85 lines · Martin Schlemmer
Quoted 6 lines · Mark D. Studebaker
If your patch is all that's required and it tests out well (have you tested it?) then sure, why not. It assumes that a w83627thf is exactly the same as a w83627hf. It's when the additional patches come in
(if kind = w83627thf.....) then it's making a bad situation worse in my opinion.It is the same chip, except for fan control,etc, which I think is more just for bios/board control, but not having (or being able to get) a data sheet, I cannot verify.
Quoted 6 lines
So my preference is to limit the additions to w83781d.
There's no plans to split the existing w83781d driver. We don't rename existing drivers because of CVS limitations and wanting to minimize changes for our users.
Right, but what about 2.5 side ? Will patches to do this in 2.5 be considered ?
Quoted 5 lines
So I'd feel better about your patch after seeing some test results. And as I said before, you will get the best results by using the new 627hf driver, either after porting it yourself or hoping somebody else does.
I will try to make the time, but not in the next week or so.
What kind of tests do you need ?
Quoted 46 lines
mds
Quoted 41 lines · Martin Schlemmer
Quoted 9 lines · Mark D. Studebaker
About a week ago I worked with
Matthias Hentges <[email protected]>
to determine the device ID for this chip, and he supplied a patch which I worked into CVS, into the w83627hf driver and into sensors-detect. It was checked in last week.This driver is designed for Super I/O chips and includes detection and activation. It uses ISA accesses.
Ok, checked out CVS.
Quoted 9 lines
I would rather not keep adding to the w83781d cruft, especially for Super I/O chips. Not only is the
driver quite unwieldy already, but people have had lots of trouble with the Winbond Super I/O chips because they often aren't initialzed by the bios so the w83781d driver can't find them. ISA accesses are also much more reliable.Please test the w83627hf driver in CVS and give us some feedback.
Well, it is not yet ported to 2.5, and the state this box is in (NPTL, etc), I _cannot_ use a 2.4 kernel. I also do not know if I currently have the time to port it to 2.5.
Finally, what is the plan .. split the w83781d into smaller drivers for each class of chip ? If so, don't you still need i2c support for some w836* chips? Won't then also be better to call the drivers
w837xx.candw836xx.c?Regards,