From: "Joerg Roedel" <joerg.roedel@amd.com>
To: "Oleg Verych" <olecom@flower.upol.cz>
Cc: "Andi Kleen" <andi@firstfloor.org>,
"Christoph Egger" <Christoph.Egger@amd.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] i386: mce cleanup part1: functional change
Date: Tue, 9 Oct 2007 18:06:05 +0200 [thread overview]
Message-ID: <20071009160605.GC13205@amd.com> (raw)
In-Reply-To: <E1IfHZg-0003dp-FA@flower>
On Tue, Oct 09, 2007 at 06:04:48PM +0200, Oleg Verych wrote:
> * Tue, 9 Oct 2007 14:49:55 +0200
>
> []
> > @@ -33,9 +33,20 @@ void fastcall (*machine_check_vector)(struct pt_regs *, long error_code) = unexp
> > /* This has to be run for each processor */
> > void mcheck_init(struct cpuinfo_x86 *c)
> > {
> > + uint32_t mca, mce;
> > +
> > if (mce_disabled==1)
> > return;
> >
> > + mca = cpu_has(c, X86_FEATURE_MCA);
> > + mce = cpu_has(c, X86_FEATURE_MCE);
> > +
> > + if (!mca || !mce) {
> > + printk(KERN_INFO "CPU%i: No machine check support available\n",
> > + smp_processor_id());
> > + return;
> > + }
> > +
>
> cpu_has() returns int,
> but would it be better to have something like
>
> if (!mce_disabled &&
> !(c->x86_capability & (X86_FEATURE_MCA | X86_FEATURE_MCE)) {
> printk(KERN_INFO "CPU%i: No machine check support available\n",
> smp_processor_id());
This looks complicated and is harder to read. Its exactly the purpose of the
cpu_has() macro to avoid such constructs.
> return;
> } else
> return;
Return unconditionaly here?
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
next prev parent reply other threads:[~2007-10-09 16:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-09 12:49 [PATCH 0/2] i386: MCE updates Joerg Roedel
2007-10-09 12:49 ` [PATCH 1/2] i386: mce cleanup part1: functional change Joerg Roedel
2007-10-09 16:04 ` Oleg Verych
2007-10-09 16:06 ` Joerg Roedel [this message]
2007-10-09 16:32 ` Oleg Verych
2007-10-09 16:54 ` Joerg Roedel
2007-10-09 20:46 ` Valdis.Kletnieks
2007-10-10 1:58 ` Oleg Verych
2007-10-09 17:33 ` coding for optimizations (Re: [PATCH 1/2] i386: mce cleanup part1: functional change) Oleg Verych
2007-10-09 18:30 ` Joerg Roedel
2007-10-10 23:14 ` Adrian Bunk
2007-10-11 15:26 ` Oleg Verych
2007-10-11 15:21 ` Adrian Bunk
2007-10-11 16:13 ` Oleg Verych
2007-10-09 12:49 ` [PATCH 2/2] i386: mce cleanup part2: conding style cleanups Joerg Roedel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071009160605.GC13205@amd.com \
--to=joerg.roedel@amd.com \
--cc=Christoph.Egger@amd.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olecom@flower.upol.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.