On Sat, 2022-02-26 at 10:47 -0800, Guenter Roeck wrote: > On 2/26/22 02:38, Frank Crawford wrote: > > Folks, > > > > For sometime there has been no activity to update the it87 module, > > but > > for I've been collecting the various suggested patches and I've > > tested a > > number of them and am keen get these into the official kernel. > > > > In fact the biggest set of patches are the set that seems to have > > come > > from here in late 2016 but never seems to have made it into the > > official > > kernel. > > > > How can I go about getting this moving again? > > > > If you refer to my earlier patches, there are two problems with them. > First, they were not in a form acceptable for upstream submission > (one patch per logical change). > Second, and more severe, a lot of the code is experimental and > sometimes caused problems (restarts) on my systems. This was > especially the case if the hardware had a second device (another > it87xx or an embedded controller) accessing the chip in parallel. > I had tried some workarounds, but never really managed to stabilize > the code. While this is kind of ok for out-of-tree code, it isn't > acceptable for the upstream kernel. Getting support from ITE and/or > from a board vendor was all but impossible. ITE typically doesn't > even admit that a chip exists, and all I got from board vendors > - if anything - was "we don't support Linux". I don't know if it > is even remotely possible to fix those problems without support > from ITE and/or board vendors. Unfortunately, this just leads to the current result where the it87 module is almost useless, as there are no current chips supported and all we get is regular requests to support current chip. We need to work out some way around the support, with or without support by the vendor. I also suspect we can get better support from Gigabyte and ITE if we are trying to do something ourselves.
