From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 19 Mar 2020 15:50:36 -0000 Received: from mga09.intel.com ([134.134.136.24]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jExRK-0004PE-Nr for speck@linutronix.de; Thu, 19 Mar 2020 16:50:35 +0100 Date: Thu, 19 Mar 2020 08:50:28 -0700 From: "Luck, Tony" Subject: [MODERATED] Re: [PATCH 1/3] v4 more sampling fun 1 Message-ID: <20200319155028.GA1277@agluck-desk2.amr.corp.intel.com> References: <5e7296c7.1c69fb81.f9a2f.00ebSMTPIN_ADDED_BROKEN@mx.google.com> <20200319085040.GA3494118@kroah.com> <20200319154046.GB113006@mtg-dev.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20200319154046.GB113006@mtg-dev.jf.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, Mar 19, 2020 at 08:40:46AM -0700, speck for mark gross wrote: > On Thu, Mar 19, 2020 at 09:50:40AM +0100, speck for Greg KH wrote: > > Are you sure about the "avoid churn" stuff? Can't you just fix up the > > X86_FEATURE_MATCH() #define to do that? > I wasn't confident about avoiding churn but I was hoping too. > Yes, I am pretty sure I can fix up that macro. My fault ... I thought it might be easier on the backport to all the stable and long term kernels if we kept this small at this stage. If upstream wants to cleanup all the users in a subsequent patch, then we can do that too. Alternatively there is Thomas' suggestion to encode the range of steppings in the upper bits of driver_data and avoid touching this structure altogether. -Tony