[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131014130311.GA1695@gchen.bj.intel.com>
Date: Mon, 14 Oct 2013 09:03:11 -0400
From: Chen Gong <gong.chen@...ux.intel.com>
To: Borislav Petkov <bp@...en8.de>
Cc: tony.luck@...el.com, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org
Subject: Re: [PATCH 3/8] ACPI, x86: Extended error log driver for x86 platform
On Mon, Oct 14, 2013 at 12:26:35PM +0200, Borislav Petkov wrote:
> Date: Mon, 14 Oct 2013 12:26:35 +0200
> From: Borislav Petkov <bp@...en8.de>
> To: Chen Gong <gong.chen@...ux.intel.com>
> Cc: tony.luck@...el.com, linux-kernel@...r.kernel.org,
> linux-acpi@...r.kernel.org
> Subject: Re: [PATCH 3/8] ACPI, x86: Extended error log driver for x86
> platform
> User-Agent: Mutt/1.5.21 (2010-09-15)
>
> On Sun, Oct 13, 2013 at 11:16:33PM -0400, Chen Gong wrote:
> > But this driver can be loaded as a module. If this module is unloaded,
> > extlog_print is gone. I can't keep such a pointer internally.
>
> Sure you can - you define a weak extlog_print() function in a
> compilation unit which is always builtin. Maybe mce.c or so.
>
Oh, yes. Let me do it.
> > This macro is great and I'd loved to use it. But it looks like a
> > litttle bit weird to let eMCA depends on a header file like edac.h.
> > Meanwhile, I found in drivers/video/sis/init.c:3323 we have a very
> > similar macro for this purpose. So how about writing a separate patch
> > to clean it up first?
>
> Actually, you're right. Those macros are much more generic and
> could be exposed to the general public by putting them, say into
> include/include/bitops.h, for example?
>
> Btw, the sis one generates unsigneds (4 byte on x86) while the edac one
> 8 byte ULLs. So you could call them
>
> GENMASK
> and
> GENMASK_ULL
>
> How does that sound?
This kind of mask is often unsigned. So how about following mode:
GENMASKL / GENMASKQ
or
GENMASK_L / GENMASK_Q
>
> > Because I think in theory "CPU < 0" is impossible. When it hits such
> > situation, it should be a very serious H/W or firmware bug. At least,
> > It think it should be a WARN_ON.
>
> Yes, I think a WARN_ON is much better than the heavy hammer. We can
> always turn it into a FW_BUG later if it really starts to trigger
> anywhere...
>
Agree.
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists