Received: by 10.213.65.68 with SMTP id h4csp638010imn; Tue, 20 Mar 2018 11:28:09 -0700 (PDT) X-Google-Smtp-Source: AG47ELsW6+c3K4S+VpLfoOepebovjBwvN08jg0MN0PzW1yyfUJv6zlWsBEb3gfZ1Hx5wq1/3ou6S X-Received: by 10.98.16.131 with SMTP id 3mr14589960pfq.188.1521570489034; Tue, 20 Mar 2018 11:28:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521570488; cv=none; d=google.com; s=arc-20160816; b=bWKCIdxCgiVejhtAj3XawKyVsWHVVIBzpBBewPw8lS70NI53McC7qbPaHOAQtt/3BE 9CK/EBtt7/LpkqZlxoo3kPq7nUVy484ALSs1kp02rXpY9NNVVr4wmea1JQkJ3KrqBOJi jd5Vy2zrtDY3EBSOWxNtRtled4O8JI17N3RFzWofFDYMa++NcrpmDbz1L30R94JwJe7n 1rMhhNJC48QbjDsmQDLOS6ifLKP6hShtKOhl0Erj59sJdsQshtaUBVO27UYLp0TQEzWY hZT1umIgxHhGeJIrry6WCGtWsqEt4TRUM/IuzYvUN1fPtC5j0K2hLKx4hdCOfbZdit2V I/4Q== 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 :arc-authentication-results; bh=RYBWLj+bdLTAY8wgltyTJmb2/LuDf0JBrNw/vcverTU=; b=vBe8ma85glLalSdOzpeLmx9a6crNHL97FxOnompnbhicTBlVGDxzYcZm2i2q4Tdowg l1AfIRsqRrX7ZDeLXnn3/bUyRYLlQpoVQZENa/EAxHggGG3BswarNNek+SXY5byjcoko sOr3lPZu8CL4YACe/Wu6o0B/tFcVyZt8xLOPciZOQMb0dKKErk4sUxu4GO3ah5G4bsIC wbZR0RBsUhS8dRCACiiW1nYDJ8nk4JsSMkDbW9Iahl3VkUjBCefx3yEP6m1L9Y/qqe3N 4HmPnwx7idUNYWUiD5fSP6WXXH8iDc54hvF9ukHU4KI351V8MiQH5vkRxt3GoUspPqul rexQ== 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 s78si1667945pfa.374.2018.03.20.11.27.54; Tue, 20 Mar 2018 11:28:08 -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 S1751676AbeCTS0V (ORCPT + 99 others); Tue, 20 Mar 2018 14:26:21 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:35488 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751472AbeCTS0U (ORCPT ); Tue, 20 Mar 2018 14:26:20 -0400 Received: from p4fea5f09.dip0.t-ipconnect.de ([79.234.95.9] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eyLxc-00029p-TG; Tue, 20 Mar 2018 19:26:13 +0100 Date: Tue, 20 Mar 2018 19:26:12 +0100 (CET) From: Thomas Gleixner To: Ivan Gorinov cc: Rob Herring , Frank Rowand , Andy Shevchenko , Linux Kernel Mailing List , Ingo Molnar , Mark Rutland Subject: Re: [PATCH v6 1/2] of: Documentation: Specify local APIC ID in "reg" In-Reply-To: <20180320181018.GA8670@intel.com> Message-ID: References: <20180320181018.GA8670@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 20 Mar 2018, Ivan Gorinov wrote: > On Mon, Mar 19, 2018 at 07:39:52PM -0500, Rob Herring wrote: > > On Tue, Mar 13, 2018 at 5:05 PM, Ivan Gorinov wrote: > > > Use the "reg" property to specify the processor's local APIC ID. > > > Local APIC ID is assigned by hardware and may differ from CPU number. > > > > Is "CPU number" a s/w visible h/w number or has it just been an index > > for DT? In the latter case, I'm okay with this change. In the former > > case, you should stick to the existing numbering. For example on ARM, > > the number here corresponds to a core ID number in a register called > > MPIDR. > > The latter case. Apparently, "CPU number" was just an index in the list. > Local APIC ID is the s/w visible h/w assigned number. > Some processor models allow local APIC ID to be changed by software, but > CPUID instruction executed with %eax = 0x0b always returns the initial ID > assigned by hardware in %edx. > > APIC ID does not match index in the list in many systems. Please document that in the changelog. Thanks, tglx