Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp453787imm; Wed, 17 Oct 2018 03:01:07 -0700 (PDT) X-Google-Smtp-Source: ACcGV63Pst+lxh9/kW1VNyfgGea1gcOfWt5JsqaCgfNoteDUn1m1rbBb/+MYo7hQV02NqsaA+R7x X-Received: by 2002:a63:f848:: with SMTP id v8-v6mr23487293pgj.82.1539770467042; Wed, 17 Oct 2018 03:01:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539770467; cv=none; d=google.com; s=arc-20160816; b=jUxj1IQq7R483cbrAt3rCixxraJZbVQWU+58eGE80U7YHj6tiTJJ+iojS0qLQMvd8o 3wyZa5OiIfKMdyJlQ3Qt5/T8+YFpbF6JPM7dw3Uf7v0oikbaiLutIng5LEDSEQwOn/g5 JGJOxN0Fx2mLvZODKPeYPUGxXCPHBrQmzRyQFm6z2w8/k6kYrPdTEGUEBKfJeM577ohT 7otsAoANKMTGydMHEnXH36xlbCm24ASdOozMM7TQgV+d2Q+KICgWUeZX2QrN3gSrfN5c nypmLF9BcL51dqL4cOuWt618KXi64/g4BjIc8IYxaAF07c8yV9He4m0n5Hwke7wO3HQi K1DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=ZTr24bWVmPdYTnGyh99PTGi7ste0qGGtVunCFZpMTds=; b=V0MM759XqrgjDPgKx2v0MF3WQO1vOJQYoYkG0R0hEg1CckB+62DEfpLy4eQsWYySgz zvzPgcYgiN8x/G56Gp072Q9Eo3zsb7p/yclBljt/OihkMmVJclPLG21IFFybPf8/jRC6 mld4X1nFSSBIUKBWztMlCDOmlrNIqa1fcMbtMNdcUmOw1e/SzMwYeOvgww/MM2vywoHA NYJdClniwR1nsueerHH7SNo85bO4gkvz1a/dw7lwiLugStvo17DA7k97NxdbHxawgQeR EQnyFO6vgzKPlfgi30seNZxlkJ2RbIRz0V9PPcBmkdBD2v07/9xnU730Bz39kjb9ueMT mcrg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w3-v6si1612012pgl.516.2018.10.17.03.00.51; Wed, 17 Oct 2018 03:01:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727129AbeJQRzR (ORCPT + 99 others); Wed, 17 Oct 2018 13:55:17 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:59847 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726727AbeJQRzR (ORCPT ); Wed, 17 Oct 2018 13:55:17 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gCicS-0004xG-97; Wed, 17 Oct 2018 12:00:00 +0200 Date: Wed, 17 Oct 2018 11:59:59 +0200 (CEST) From: Thomas Gleixner To: Andi Kleen cc: peterz@infradead.org, x86@kernel.org, eranian@google.com, kan.liang@intel.com, linux-kernel@vger.kernel.org, Andi Kleen Subject: Re: [PATCH v2 1/2] x86/cpufeature: Add facility to match microcode revisions In-Reply-To: <20181010162608.23899-1-andi@firstfloor.org> Message-ID: References: <20181010162608.23899-1-andi@firstfloor.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 10 Oct 2018, Andi Kleen wrote: > +/* > + * Match specific microcodes > + * > + * vendor/family/model/stepping must be all set. > + * min_ucode is optional and can be 0. Stale comment > + */ > + > +struct x86_ucode_id { > + u8 vendor; > + u8 family; > + u16 model; > + u16 stepping; Still using u16 for no reason. And please make the members aligned in a tabular fashion. > + u32 min_ucode; > +}; > + > +const struct x86_ucode_id *x86_match_ucode(const struct x86_ucode_id *match) What's the point of returning the struct pointer? Shouldn't it be enough to make it return bool? Also the function name really should reflect that this checks whether the minimal required microcode revision is active. > +{ > + struct cpuinfo_x86 *c = &boot_cpu_data; > + const struct x86_ucode_id *m; > + > + for (m = match; m->vendor | m->family | m->model; m++) { VENDOR_INTEL = 0, so this check is obscure to begin with. Either you chose a explicit condition to put at the end of the table, e.g. vendor = U8_MAX or you hand in the array size to the function. > + if (c->x86_vendor != m->vendor) > + continue; > + if (c->x86 != m->family) > + continue; > + if (c->x86_model != m->model) > + continue; > + if (c->x86_stepping != m->stepping) > + continue; > + if (c->microcode < m->min_ucode) > + continue; Why would you continue here? If vendor, family, model, stepping match, then there is no point to continue, really. Assuming that the return type is bool: return c->microcode >= m->min_ucode; is sufficient. Thanks, tglx