From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E01B2FD689 for ; Tue, 10 Feb 2026 22:17:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770761853; cv=none; b=MOvO5P7s9zEVCnOa/x3P523Bu6XfBKr/qPnLlFCIhSHxW8lr7spexlL2VvOtndQVT8wHarcnUVmX86b0A7hcOh3ynpr4cd8jm5K9Bqv7DLsYt2Q5fjLMW2FVnRDBCwP/SHNwUzlUL83+WC+kM5qswQ0QyaEsf+XlB7ckwd5/2xo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770761853; c=relaxed/simple; bh=6HTxtUclJvNaw8DMD6qsJHco496SR2PJCQvvgAIdfto=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KRXbhbBHVAEpZz+1272ucwNTR9D5jI8zBAnqNczXUw1a3Rycr5yL4ELj5rHn/qjti/HIyVd7iCmXo46AfcpXy1rut0kM0dT8fYO9yRDVqAvKwzSU00hpnUkn8oeNgqkqxwFuI80VTQOm96aaHp7CG6ZlQyP652S+PqmpJa8/IlQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=lBtDsljQ; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="lBtDsljQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1770761852; x=1802297852; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=6HTxtUclJvNaw8DMD6qsJHco496SR2PJCQvvgAIdfto=; b=lBtDsljQ7yRUawe/7WZ4U7iKJupl4zN8VyZkGhCOLlRZRwzhUeL3uxa1 2Lx14oUwbm0I5DgwvHCFmLcsQeXn311Abrl9QkRJogSL+PKk6yZAVI5Bb CX6LXUDZ+3TDVSJO7+6HuBqJKJUudFoE7+PvtwmPK2vQi47/DFbnE7JIt nYjnAgaFKqiv8VjVSnxzXFNZYj1O23ZkGXtg0zVa5uhrATpg9o/BFKTir FCyuunmLoiWBLm3fuQNYi3GUYIBzcNxN86f5zcF+GTGj4FHteZmAm6Or0 UctlkA7G1+f2GrhlMNPnn5uA26VbORgJqvwe6bnmnNVfMNXjWAWfjgthj g==; X-CSE-ConnectionGUID: iy5Fb0SAQQONPhGf8bJP+Q== X-CSE-MsgGUID: LlS1fFeRQbi9RvxQYcxCYA== X-IronPort-AV: E=McAfee;i="6800,10657,11697"; a="71796504" X-IronPort-AV: E=Sophos;i="6.21,283,1763452800"; d="scan'208";a="71796504" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2026 14:17:31 -0800 X-CSE-ConnectionGUID: 2u3ssOOXTOeLXDVJFAxCPA== X-CSE-MsgGUID: Z1iKspWGTICD96893j4zwQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,283,1763452800"; d="scan'208";a="216559032" Received: from unknown (HELO [10.24.81.14]) ([10.24.81.14]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2026 14:17:30 -0800 Message-ID: Date: Tue, 10 Feb 2026 14:17:29 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header To: Sohil Mehta , Dave Hansen Cc: zhao1.liu@intel.com, Borislav Petkov , "H. Peter Anvin" , Ingo Molnar , Jon Kohler , Pawan Gupta , "Peter Zijlstra (Intel)" , Thomas Gleixner , Tony Luck , x86@kernel.org, Iwona Winiarska , LKML References: <20260206231438.720FF4E3@davehans-spike.ostc.intel.com> <20260206231440.C35AD1C5@davehans-spike.ostc.intel.com> <2d1cd1a3-4447-41e7-9af8-6cf80876247d@intel.com> From: Dave Hansen Content-Language: en-US Autocrypt: addr=dave.hansen@intel.com; keydata= xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzUVEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs LmNvbT7CwXgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lczsFNBFRjzmoBEACyAxbvUEhd GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/ vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci FCRl0Bvyj1YZUql+ZkptgGjikQARAQABwsFfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y In-Reply-To: <2d1cd1a3-4447-41e7-9af8-6cf80876247d@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/10/26 14:13, Sohil Mehta wrote: > On 2/6/2026 3:14 PM, Dave Hansen wrote: >> The intel-family.h header uses Vendor/Family/Model macros but it does not >> #include the header where they are defined. If that header is included, >> the build blows up in #include hell. >> > > Is the cause of the #include hell the single line in peci-cpu.h? > > #include "../../arch/x86/include/asm/intel-family.h" Maybe. I didn't investigate too deeply because the fix here at least moved the needle in the right direction. ... > AFAIU, the PECI driver is the only user of this VFM stuff in non-x86 > code. Are we expecting other generic usages for it? Definitely not. PECI is weird. > The VFM macros and the VFM model defines usually go hand-in-hand. Is > there a reason for keeping intel-family header in arch/x86 but the VFM > one in asm-generic/? We should just move the Intel header as long as it's used in generic code. > I wonder if it would more consistent to move the VFM macros into > arch/x86/include/asm/vfm.h? > > And then let the PECI driver do: > > #include "../../arch/x86/include/asm/vfm.h" > > Though, intel-family.h would probably need: > > #ifdef CONFIG_X86 > #include > #endif The reality is that we have non-x86 code using an x86 header. That's crazy and it's very very unusual and we're probably going to keep accidentally breaking it. Our only hope is to just move all that gunk to generic code for _real_.