(Sending to your other mail address because there's some temporary resolution
issue:
msmtp: recipient address mchehab@xxxxxxxxxxxxxxxx not accepted by the server
msmtp: server message: 451 4.3.0 <mchehab@xxxxxxxxxxxxxxxx>: Temporary lookup failure
msmtp: could not send mail (account alien8.de from /home/boris/.msmtprc)
Maybe the problem is on my end.)
On Mon, Jul 24, 2017 at 03:10:13PM -0300, Mauro Carvalho Chehab wrote:
> Yeah, having a whitelist is a maintainership's burden, but, on
> the other hand, I suspect that there aren't many systems that
> implement FF, have a reliable BIOS mapping of MB's silkscreen
> and doesn't filters out corrected errors using some sort of
> undocumented mechanism.
>
> So, I guess it is doable.
Right, let's hope.
> Another alternative, with, IMO, is better would be to add a parameter like:
>
> edac=FF - firmware first;
> edac=hw - hardware first;
> edac=auto - honors FF if set in BIOS. Otherwise, hardware first.
Or maybe edac=try_FF or so. But yeah, I guess we'll need something to
tell the EDAC core to try FF first.
> In order to avoid regressions, and to avoid the need of a whitelist,
> I would keep "edac=hw" as default.
So I don't want to break existing users and thus make only explicitly
known platforms load ghes_edac. In the current case, the HPE machines.
All the rest will simply use the platform drivers and nothing will
change for them.
Later we'll probably need to revisit this decision but right now and
with all things considered, the whitelist seems - as ugly as it is - the
most workable solution for all the different use cases and machines...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
