Received: by 10.213.65.68 with SMTP id h4csp633021imn; Tue, 20 Mar 2018 11:19:56 -0700 (PDT) X-Google-Smtp-Source: AG47ELstfic5BuY7r1Htx6iSVzxb5L6mfnVm1pQ758PwcvkFp/2s5lGKjnxAbBb677zgddJrOpvr X-Received: by 2002:a17:902:9692:: with SMTP id n18-v6mr14296246plp.67.1521569996648; Tue, 20 Mar 2018 11:19:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521569996; cv=none; d=google.com; s=arc-20160816; b=K8gVOKB/HqefkSlnPStoTm+vEd6DRAYV4cdmZgG9fuJuGVCGf4mRoWO3PFYcGiDHh7 /Pes27YMbBZJLrrcLg8Uk0dg9vkCYsFPZdk0egrT+MMbScJKYDPuQcRPFWfbN8rayJL0 DbY9Zall1gLLW4XCjhxEcw/iutdE+gvcDOoJkCgpVdDwbMIivFHgno1fW3hjgP58Ff+9 xpsV/qfoOj+6QQwKQ8+EdcDQCwduAo8ebFcfl1xT4O6X0gsMMuRBU7Ik9TGz40cy2IMN yKd9arPnTKuOJczjs1y5sLvKNKtSV8fo4fEBCpXFGX2+tE2L5hrs58YDwwYuFnvFSDo0 j9TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=/UClJ5V9rWd3x5gCudyHZcRYo9UNKSJemvVF8wJ4fa4=; b=VOWprWhNJHW/9Qn+s90EmbMSEqPkHddsW9Czo7zMLwBZfaH/TrANM9yvEm1YjKfcbK fhfDf6LTfIUNfdvXx3btY4frDo35nD0520FkRoNtrpnW7x97FVJNwi/M4UX3DSu/8kzu 9xtCzlQYK+/lVERbs48rcGEIyFG71h/DG+TBA1MLpvWFsldssud3geQjMFSTrJwkB3fh NDMHNA02rA+0T8BwPxCLUANRggfjZhpsP55l68BOs8pB8piL/axWlJcU/JYRDo8VO7Bv z2ugjuIfMJ2y8lQfLIOyTvaM8qk5K3O+aOSMQ/J2kc70JxSF5j8hfQaKGHi5Koka1sCn MElQ== 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 h187si1543769pgc.294.2018.03.20.11.19.40; Tue, 20 Mar 2018 11:19:56 -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 S1751712AbeCTSSM (ORCPT + 99 others); Tue, 20 Mar 2018 14:18:12 -0400 Received: from mga06.intel.com ([134.134.136.31]:3785 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751615AbeCTSSK (ORCPT ); Tue, 20 Mar 2018 14:18:10 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2018 11:18:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,336,1517904000"; d="scan'208";a="40661602" Received: from dph9ls1.fm.intel.com (HELO intel.com) ([10.80.209.182]) by orsmga001.jf.intel.com with ESMTP; 20 Mar 2018 11:18:09 -0700 Date: Tue, 20 Mar 2018 11:10:18 -0700 From: Ivan Gorinov To: Rob Herring Cc: Thomas Gleixner , 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" Message-ID: <20180320181018.GA8670@intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > > > Signed-off-by: Ivan Gorinov > > --- > > Documentation/devicetree/bindings/x86/ce4100.txt | 37 ++++++++++++++++++------ > > 1 file changed, 28 insertions(+), 9 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/x86/ce4100.txt b/Documentation/devicetree/bindings/x86/ce4100.txt > > index b49ae59..1c41cbd 100644 > > --- a/Documentation/devicetree/bindings/x86/ce4100.txt > > +++ b/Documentation/devicetree/bindings/x86/ce4100.txt > > @@ -7,17 +7,36 @@ Many of the "generic" devices like HPET or IO APIC have the ce4100 > > name in their compatible property because they first appeared in this > > SoC. > > > > -The CPU node > > ------------- > > - cpu@0 { > > - device_type = "cpu"; > > - compatible = "intel,ce4100"; > > - reg = <0>; > > - lapic = <&lapic0>; > > +The CPU nodes > > +------------- > > + > > + cpus { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + cpu@0x00 { > > Drop the '0x' and leading 0s. > > > + device_type = "cpu"; > > + compatible = "intel,ce4100"; > > + reg = <0x00>; > > + }; > > + > > + cpu@0x02 { > > + device_type = "cpu"; > > + compatible = "intel,ce4100"; > > + reg = <0x02>; > > + }; > > }; > > > > -The reg property describes the CPU number. The lapic property points to > > -the local APIC timer. > > +A "cpu" node describes one logical processor (hardware thread). > > + > > +Required properties: > > + > > +- device_type > > + Device type, must be "cpu". > > + > > +- reg > > + Local APIC ID, the unique number assigned to each processor by > > + system hardware. > > > > The SoC node > > ------------ > > -- > > 2.7.4 > >