Luck, Tony wrote:
> > I would save that work for a clear description of why einj.ko should not
> > be resident.
>
> Personally, it would save me having to type "modprobe einj" to run tests (and
> answer e-mails from validation folks telling they missed this step).
It would only autoload with cxl_core.ko though.
>
> But others might feels this is unwanted. It looks like some distros build kernels
> with CONFIG_ACPI_APEI_EINJ=m.
>
> On the other hand, EINJ should be under control of a BIOS option that
> defaults to "off". So production systems won't enable it.
>
> But perhaps there will be a pr_warn() or pr_err() during boot. One of these will likely trip:
>
> pr_warn("EINJ table not found.\n");
> pr_err("Failed to get EINJ table: %s\n", acpi_format_exception(status));
> pr_warn(FW_BUG "Invalid EINJ table.\n");
> pr_err("Error collecting EINJ resources.\n");
Oh, good point. However, should a debug module really be throwing
pr_err() or pr_warn()? I.e. should those all move to pr_info() or
pr_debug() since the error case is detected by the lack of debugfs files
being published.
At least that would be my preference over creating cxl_einj.ko.
