[PATCH 0/3] EDAC/igen6: Add polling support and allow setting edac_op_state

Orange Kao posted 3 patches 2 weeks, 3 days ago
[PATCH 0/3] EDAC/igen6: Add polling support and allow setting edac_op_state
Posted by Orange Kao 2 weeks, 3 days ago
Thank you Qiuxu and Boris.

Here is the updated patch. I would like to propose that we keep the 
edac_op_state as a module parameter. Because it would allow users (regardless of
CPU SKU) to test different options on their machine without compiling their own
kernel. I hope this could lower the entry barrier and make it easier for them to
test IBECC.

Patch 1: Initialize edac_op_state according to the configuration data
Patch 2: Add polling support
Patch 3: Allow setting edac_op_state

Thanks. Please let me know if there is anything I should improve or if anything
does not make sense.
Re: [PATCH 0/3] EDAC/igen6: Add polling support and allow setting edac_op_state
Posted by Tony Luck 2 weeks, 1 day ago
On Wed, Nov 06, 2024 at 11:35:44AM +0000, Orange Kao wrote:
> Thank you Qiuxu and Boris.
> 
> Here is the updated patch. I would like to propose that we keep the 
> edac_op_state as a module parameter. Because it would allow users (regardless of
> CPU SKU) to test different options on their machine without compiling their own
> kernel. I hope this could lower the entry barrier and make it easier for them to
> test IBECC.
> 
> Patch 1: Initialize edac_op_state according to the configuration data
> Patch 2: Add polling support

Applied patches 1 & 2 to RAS tree. Thanks

> Patch 3: Allow setting edac_op_state

As discussed on mailing list, not taking this one as there
is no real use case.

-Tony
Re: [PATCH 0/3] EDAC/igen6: Add polling support and allow setting edac_op_state
Posted by Borislav Petkov 2 weeks, 3 days ago
On Wed, Nov 06, 2024 at 11:35:44AM +0000, Orange Kao wrote:
> I would like to propose that we keep the edac_op_state as a module
> parameter. Because it would allow users (regardless of CPU SKU) to test
> different options on their machine without compiling their own

Are you talking about an actual use case where "users" really will do that
because there actually really is such a use case out there (If so, please do
tell because *no one* is setting that parameter and I'd prefer to remove it
everywhere in favor of automatic detection.)

or

are you talking about a potential,
it-would-be-good-to-but-I-don't-know-yet-whether-it-would-really-get-used
thing?

If latter, that third patch can remain out-of-tree until an actual use case
materializes and justifies it.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette