From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 27 Feb 2019 20:05:02 -0000 Received: from p5492e5b8.dip0.t-ipconnect.de ([84.146.229.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gz5Rt-0002hT-OV for speck@linutronix.de; Wed, 27 Feb 2019 21:05:01 +0100 Date: Wed, 27 Feb 2019 21:05:01 +0100 (CET) From: Thomas Gleixner Subject: Re: [patch V5 00/14] MDS basics 0 In-Reply-To: Message-ID: References: <20190227150939.605235753@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, 27 Feb 2019, speck for Linus Torvalds wrote: > That looks better to me. > > If I had my choice, I'd get rid of the "FAM6" thing entirely from the > intel enumerations, but that's an independent thing Is on that ever growing todo list thingy already. > Although when I look at this, we actually already have a helper macro > for the Intel case, and you could do > > INTEL_CPU_FAM6(ATOM_SALTWELL, NO_SPECULATION), > INTEL_CPU_FAM6(ATOM_SALTWELL_TABLET, NO_SPECULATION), > ... > > using the existing INTEL_CPU_FAM6() helper macro. > > It's clearly not the first case people looked at those nasty model > definitions and went "ugh. that's illegible". Yes, but then I end up with two different macros in that table, which is not helping readability either. Thanks, tglx