Received: by 10.223.185.116 with SMTP id b49csp5722119wrg; Wed, 7 Mar 2018 17:19:42 -0800 (PST) X-Google-Smtp-Source: AG47ELtdlUMXVXPhmeKGlj5B55At/ZKp4psp+w2yC4NtyfzWLH50cjgxx/G4afCduG9Y6jaFD5tn X-Received: by 2002:a17:902:a511:: with SMTP id s17-v6mr22050044plq.206.1520471982269; Wed, 07 Mar 2018 17:19:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520471982; cv=none; d=google.com; s=arc-20160816; b=BW6x8JKfvaTIYHAk8yCgwItMhlJHzqI5BJjh13URXXmezg8CM3kWJY86yGtUnG3NKe gqVLuLSVowFzJmjLS0Hrmgzs7gI52Z+a9VXNb2a6XFvXFTYOBP7nGe5N8DdXY2skq2Nq +4zU5jd1T2AuymA068S/a3POaUhjSqVwcdkmF+HSpOYivgnBT3tFy2gzVLQjhp0TaEZx 2Y2AXKkMANklng7+VS0O0Oyt1bJB6nQttuUvn4xLmSRaPEpGQYOIrqMhxao2+mJaKJ20 RwirvljSgLLED8mBiR0GjGju9Rj4tu++ygan2iUmyJBx9IeL4paIJcwvJbL+2Llo+1/Q 2/sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=4K+y1Z5s2tcUd75y+tizjnUcSxQU0zbonR/0Z33k7HQ=; b=j2dvjbtLNAZW9mWBhmsDXSxJd/6Q3ElsGUvw9AK8A7QkhF4HhN0OoMrXRGabIgXp8b oRtiVMhdkhU6j8rtxQqnafDIyV0Kpy6KutXxxQ06Wmr9qp7q4r5FXnyVbouwm56COcuI VwtX94R5z+x/WxLQtjqmp9Rbnynk0S9sTzgRA6zu+bBn6wPtLVmQOgt0XXZ0DTQKEmAr TyBGw4sdStWsumaNnUtFrJ6zjw8ElDJo+gFzoSQ+updkE0eQx9Q7dzOAacjRr6s0YzQa Yr0FA6/8D9GxrkCeIZpN5+9gYnIhuGK5wxjrAAQGL4JEIWRoTpK7d6cVQ4fm75dMpg8j scIw== 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 l137si12095804pga.525.2018.03.07.17.19.27; Wed, 07 Mar 2018 17:19:42 -0800 (PST) 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 S1755152AbeCHBSc (ORCPT + 99 others); Wed, 7 Mar 2018 20:18:32 -0500 Received: from mga01.intel.com ([192.55.52.88]:45875 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754963AbeCHBSb (ORCPT ); Wed, 7 Mar 2018 20:18:31 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2018 17:18:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,438,1515484800"; d="scan'208";a="32184272" Received: from dph9ls1.fm.intel.com ([10.80.209.182]) by FMSMGA003.fm.intel.com with ESMTP; 07 Mar 2018 17:18:30 -0800 Message-ID: <1520471460.55728.73.camel@intel.com> Subject: Re: [PATCH v4 3/4] of: Documentation: Add x86 local APIC ID property From: Ivan Gorinov To: Rob Herring Cc: Thomas Gleixner , Linux Kernel Mailing List , Ingo Molnar , Mark Rutland Date: Wed, 07 Mar 2018 17:11:00 -0800 In-Reply-To: References: <3a0359afad71abc0c0d682bfcd0dd66055f5d7e5.1520450752.git.ivan.gorinov@intel.com> Organization: Intel Corporation Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-03-07 at 14:23 -0600, Rob Herring wrote: > > Add new "intel,apic-id" property to allow using CPU descriptions > > in Device Tree data provided by the U-Boot loader. > > Address specified in 'reg' to be used as default local APIC ID > > to avoid breaking existing systems with DTB provided by firmware. > Is there some reason to not always use reg? For when the numbering of > cpus and timers is different? Yes, local APIC ID may differ from CPU number. For example, in Atom E38xx (u-boot/arch/x86/dts/minnowmax.dts): cpus { #address-cells = <1>; #size-cells = <0>; cpu@0 { device_type = "cpu"; compatible = "intel,baytrail-cpu"; reg = <0>; intel,apic-id = <0>; }; cpu@1 { device_type = "cpu"; compatible = "intel,baytrail-cpu"; reg = <1>; intel,apic-id = <4>; }; }; > Of course, we do have the situation on ARM with the GIC that the GIC > CPU IDs may be > > > > > > Signed-off-by: Ivan Gorinov > > --- > > ?Documentation/devicetree/bindings/x86/ce4100.txt | 6 ++++++ > > ?1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/x86/ce4100.txt b/Documentation/devicetree/bindings/x86/ce4100.txt > > index b49ae59..d15de48 100644 > > --- a/Documentation/devicetree/bindings/x86/ce4100.txt > > +++ b/Documentation/devicetree/bindings/x86/ce4100.txt > > @@ -14,11 +14,17 @@ The CPU node > > ????????????????compatible = "intel,ce4100"; > > ????????????????reg = <0>; > > ????????????????lapic = <&lapic0>; > Isn't this enough? I can't tell because whatever this points to has no > binding documentation. Local APIC is a part of CPU, not an external device (except for 486 and early Pentium). Every CPU has access to its own local APIC registers at the same base address (0xfee00000). Therefore, one "lapic" device node can work for all processors in the system. With more changes in the code, the local APIC description could be made optional because every processor can always read its local APIC base address from MSR 0x1b. And when x2APIC mode is enabled, the local APIC registers are accessed as model specific registers instead of memory-mapped I/O. > You could perhaps extend it and add a cell with the id value. This may require different DT data for Linux and U-Boot, or changes in the latter.