Re: [RFC] hwmon: add support for IT8686E to it87.c

[Guenter Roeck <linux@roeck-us.net>]

On Mon, Dec 02, 2019 at 09:07:10AM -0800, Corey Ashford wrote:
> On Mon, Dec 2, 2019 at 6:32 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On 11/29/19 8:48 PM, Corey Ashford wrote:
> > > On Fri, Nov 29, 2019 at 8:17 PM Guenter Roeck <linux@roeck-us.net> 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
> 
> Ah, thank you for your detailed explanation.  How you did as much as
> you did is beyond me.  ITE's web site seems to lack any usable
> information, and doesn't even list the IT8686 as one of their chips.
> Other "supported" chips don't appear to have any documentation easily
> available, other than a very generic-y description of the chip.  Quite
> an uphill battle for marginal gain.
> 
Exactly. The only real recommendation I have at this time is for anyone
running Linux to stay away from boards with ITE chips.

> Is it possible there's a way to access the sensors by using the EC as
> a proxy, rather than trying to gain direct and exclusive access to the
> sensors?  Just a thought.  I have no idea of the architecture of these
> things.  Your mention of EC was the first I had heard of it :/
> 

Not that I know of, sorry. The EC is actually running inside the Super-IO
chip(s). I have no idea if and how it is accessible from Linux. Either case,
that would be even worse, since EC programming is board vendor specific.

Guenter