On 11/29/19 8:48 PM, Corey Ashford wrote:
On Fri, Nov 29, 2019 at 8:17 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On 11/29/19 6:11 PM, Corey Ashford wrote:
Hello folks. I am running a newly-built system that uses an IT8686E
chip. Currently, the latest kernel from kernel.org doesn't have code
in drivers/hwmon/it87.c to support it, however, I found some source on
the net which has added support for quite a few more variants of that
brand of Super I/O chip:
https://github.com/xdarklight/hwmon-it87/blob/master/it87.c
I tried it out by building the module and "insmod"ing it into my
running system, and it appears to work fine.
It seems the original developer had a difficult time pushing the
changes upstream, so he abandoned the project.
I abandoned the project (and dropped the driver from my github page)
because people started _demanding_ that I push the driver from github
upstream, without offering any assistance whatsoever.
My thought was that I could add support for just the IT8686E chip as a
single patch, and since I can test it locally I would have a better
chance of getting the patch accepted. The changes to the source at
the above git tree have quite a number of changes that aren't really
necessary for supporting the IT8686E chip, so I think the patch could
be pretty small, but will still credit the original author.
IT8686 is a multi-page chip, meaning you'll need the entire protection
against multi-page accesses by the EC in the system. It also supports
the new temperature map. I don't think it is that simple.
Guenter
Thanks for the quick reply!
When you said they didn't offer any assistance, do you mean assistance
with testing? If so, how about if the support is trimmed out for the
newly-added chips that have no available test system volunteers, and
then slowly add those back as people make test systems and testing
time available. Should I presume that you have access to one or more
systems with the added ITnnnn chips? I volunteer my system for
testing the IT8686E support.
Testing and, more importantly, detailed code review. No one but me has
seriously (if at all) scrutinized that code for years. Just picking it
into mainline and hope that it won't cause trouble is, by itself, troublesome.
On top of that, the multi-page access problems are well known by board vendors
using this chip as well as by the chip vendor. Yet, neither board vendors nor
ITE talk with kernel developers. The workarounds I implemented are based on
information I got from one of the Windows tools developers, and are not
validated by any board vendor nor by ITE. Every board vendor I tried to contact
tells me that they don't support Linux, and I never got any reply from ITE.
I do know that the code causes problems on early Gigabyte board using the 8686
and similar multi-page chips. Just accessing the chip from Linux may cause trouble
because the built-in EC tries to access it as well in parallel (I suspect this
causes the board to reset because that access is turned off for a while by
the driver). This is all fine for an out-of-tree driver, but it would be
unacceptable in the upstream kernel.
In summary, you'll not only need to port the code, you'll also need to establish
contact to ITE and/or to board vendors to ensure that the code works as intended
with the EC on the affected boards.
Guenter
