Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mainlining the module delta? #3

Open
iam-TJ opened this issue Nov 5, 2022 · 9 comments
Open

Mainlining the module delta? #3

iam-TJ opened this issue Nov 5, 2022 · 9 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@iam-TJ
Copy link

iam-TJ commented Nov 5, 2022

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
Copy link
Owner

@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
Copy link

goc9000 commented Dec 15, 2022

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
Copy link
Owner

@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
Copy link
Owner

@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
Copy link

@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
Copy link
Author

iam-TJ commented Jun 29, 2023

@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
Copy link
Owner

frankcrawford commented Jun 29, 2023 via email

@frankcrawford frankcrawford self-assigned this Jan 3, 2024
@frankcrawford
Copy link
Owner

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

@iam-TJ
Copy link
Author

iam-TJ commented Jan 10, 2024

@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.

@frankcrawford frankcrawford added enhancement New feature or request help wanted Extra attention is needed labels Apr 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants