Mainlining the module delta?

[iam-TJ]

Are you aware of any attempts, or impediments, to getting the delta between this and the mainline it87 module merged into main-line? It would obviously be beneficial to everyone.

If there are impediments (possibly documented in historic mailing lists) it'd be good to collect them here and see if we can address them so changes can eventually go directly into mainline.

[frankcrawford]

@iam-TJ I'm working on it but it is a long process. You will see some minor updates probably in 6.2, but as pretty much every line needs to be justified, and I didn't develop them, it takes a long, long time.

In fact the biggest issues with any real changes is that they were developed through guess-work and interpolation, with no formal documentation from Gigabyte or ITE to back it up, and hence even more difficult to justify.

[goc9000]

I've been thinking about this as well... New versions of the ITx chips pop up seemingly every year, and each time the driver would need to be modified. And support for each individual chip will include guesswork for a long time, possibly forever, and the conservative kernel guys don't want to sign off on something so unstable. That's why this repo has all these hundreds of clones and why the original author quit in disgust.

One possible solution I've been considering relies on the fact that all these chips have a very similar structure (at least their environment controller part). There are usually only small changes from one to another, e.g. the number of fans, ADC resolution, presence or absence of certain features etc. It makes sense to extract a common model and just apply different parameters to it for each chip. The driver already does that, but the parameters and chip types are hardcoded. What if it exposed an interface (via the module config or maybe even sysfs entries) by which it could be configured for new chips from userspace? Kinda like force_id, except not just the ID but also the features, number of fans etc. That way we can unofficially experiment with new chips as soon as they are available, and maybe with time the configuration can be officialized and added to the driver once it's stood the test of time.

Oh and it also needs to support potentially different configurations for each address (there are already mobos with two different chips, and force_id doesn't work well for them).

[frankcrawford]

@goc9000 that seems like an interesting idea and something we should try, although I'm probably not the best programmer to write it. I'm willing to add in code for this, possibly on a separate branch for the moment. On the other hand given a bit of time I will look at doing something about force_id for multiple chips, as I agree that it is currently a problem.

[frankcrawford]

@goc9000 just a small update, things are progressing to get this into the mainline, and even some recent changes are in either 6.2 or will be in 6.3, such as the ability to use force_id for multiple different chips.

We are gradually getting there.

[sergiotca]

@goc9000 just a small update, things are progressing to get this into the mainline, and even some recent changes are in either 6.2 or will be in 6.3, such as the ability to use force_id for multiple different chips.

We are gradually getting there.

I cannot thank you enough for this buddy, keep up the great work!

[iam-TJ]

@frankcrawford I'm interested in developing code based on @goc9000 idea of using a common model structure if we can thrash out a design that can be iterated on for testing to replace all the hard-coded specifications.

In addition it should have a userspace interface for adding/changing/removing chip specifications. That could be via sysfs but I suspect might be frowned upon by kernel devs since it'd need to be exposing a lot of internals to do it justice, so I wonder about providing a netlink interface and a companion userspace tool it87ctl to use the netlink interface for the required operations.

I'm not intimately familiar with it87 code right now having adopted this out-of-tree driver to support a motherboard I acquired, but I've been hacking on the kernel since 2005 so I know my way around enough to be able to code something that'll pass muster in mainline. I'm also familiar with working with chip level interfacing and interpreting and reverse-engineering opaque interfaces.

[frankcrawford]

TJ,I'm away for a few days, but will get back to you when I get back.ThanksFrankSent from my Galaxy -------- Original message --------From: TJ @.> Date: 29/6/23 8:07 pm (GMT+10:00) To: frankcrawford/it87 @.> Cc: Frank Crawford @.>, Mention @.> Subject: Re: [frankcrawford/it87] Mainlining the module delta? (Issue #3) @frankcrawford I'm interested in developing code based on @goc9000 idea of using a common model structure if we can thrash out a design that can be iterated on for testing to replace all the hard-coded specifications. In addition it should have a userspace interface for adding/changing/removing chip specifications. That could be via sysfs but I suspect might be frowned upon by kernel devs since it'd need to be exposing a lot of internals to do it justice, so I wonder about providing a netlink interface and a companion userspace tool it87ctl to use the netlink interface for the required operations. I'm not intimately familiar with i87 code right now having adopted this out-of-tree driver to support a motherboard I acquired, but I've been hacking on the kernel since 2005 so I know my way around enough to be able to code something that'll pass muster in mainline. I'm also familiar with working with chip level interfacing and interpreting and reverse-engineering opaque interfaces.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[frankcrawford]

@iam-TJ did you ever do anything more about this idea?

[iam-TJ]

@iam-TJ did you ever do anything more about this idea?

No. It needs someone very familiar with it87 devices to do the initial design sketch with real example use-cases that can be used to validate and improve the design. With a skeleton framework in place then others would be able to contribute code both in-kernel and for userspace tools.