On Wed, Jun 21, 2017 at 02:46:42PM -0500, Yazen Ghannam wrote: > From: Yazen Ghannam <yazen.ghan...@amd.com> > > The severity gives a hint as to how to handle the error. The notifier > blocks can then use the severity to decide on an action. It's not necessary > for machine_check_poll() to filter errors for the notifier chain, since > each block will check its own set of conditions before handling an error. > Also, there isn't any urgency for machine_check_poll() to make decisions > based on severity like in do_machine_check(). > > If we can assume that a severity is set then we can use them in more > notifier blocks. For example, the CEC block can check for a "KEEP" severity
Hmm, I'm not sure about this. If we did this, we would have to *make* CECCs be always KEEP severity. And they are now but doing that would make that mapping CECC->KEEP imprecise and unnecessary but required.... Yeah, we can talk about that when we have to cross that bridge. So I've left the example but made the above s/can/could/ :) > rather than checking bits in the status. This isn't possible now since the > severity is not set except for "DEFFRRED/UCNA" errors with a valid address. > > Save the severity since we have it, and let the notifier blocks decide if > they want to do anything. > > Signed-off-by: Yazen Ghannam <yazen.ghan...@amd.com> > --- > Link: > https://lkml.kernel.org/r/1497286446-59533-1-git-send-email-yazen.ghan...@amd.com > > v1->v2: > * Expand commit message. > > arch/x86/kernel/cpu/mcheck/mce.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) Applied, thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.