Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4453036ybi; Tue, 11 Jun 2019 06:58:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqwMJKp3G5iF0lmOyi3RKOQhx6o/kXivnpz8MqowVwWLf3c8bRinPs0dfKMiF7cMw/CNl+Kf X-Received: by 2002:a17:902:7891:: with SMTP id q17mr20174712pll.236.1560261495038; Tue, 11 Jun 2019 06:58:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560261495; cv=none; d=google.com; s=arc-20160816; b=dBzCA1Jl85KCT3f5+EmJa39dKkohxN2BY5E0IaAk4bRollMmZXDDp3kN+zy/Iol0oo k5nqpo2sQnRrXr8/UpQxd/1MrIqWc3ShbF/+rKpd1idoeweLkrTruzEJFDhQvEHNhHNv aW0Bw7U9RdDheIdmkidOjEBv+LFzMxXXR9cys/nKODqJw1o7f0yhvHV9Q266E9TsW0LC IlxNadQrajFkwqz8Vr0/VFmWuGPvmnp+k0JQGTFj70CgATqOg8yYb2NJL00AAsKf61VV cxh6AeuJvn7x1JrSSUHrE5/7iMGAerxeBTqpjM42zAPZ8pDTCvhkjUpR4uttm2qtqavH 8byg== 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; bh=7tu6wEhykHLPsgTnO+Zh7WVY8YKYpKtMlM13vCLLqak=; b=aYlIEJC30uzQSmXQg4r9wwcxB6e7fmae0pu8XU0W7ISYeNl0l7KVCcg+39CBk4KjV5 MXm7zSoNjIy1MTP1PJlwKy3d5dcN31ZGekX/Lgc6q2hA620kLRsyCfSsRl6lASZRcadR zcOMp7GsDFh5dNieqObC1OvylSAtrV0MQ23WLVdu55Utxhv+rV/reEKVHjZZD3aUqb5P wDZfXamSbDUnepOhBlLI9GuVDmuTEDdOa5oVUVvqgMYXP2srssJi0xOfLWeo+Wkl/5iZ 012Q7RWw8lXXVyII/Mgw/shVV0pkdlW+4ybxv1o9oAOBix5/KxefBQRD8fsB0kyEoSvo w/mQ== 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 f17si12294199plr.333.2019.06.11.06.57.07; Tue, 11 Jun 2019 06:58:15 -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 S1728447AbfFKMx2 (ORCPT + 99 others); Tue, 11 Jun 2019 08:53:28 -0400 Received: from foss.arm.com ([217.140.110.172]:60646 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727947AbfFKMx2 (ORCPT ); Tue, 11 Jun 2019 08:53:28 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5CD76344; Tue, 11 Jun 2019 05:53:27 -0700 (PDT) Received: from e107155-lin (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AB0D33F557; Tue, 11 Jun 2019 05:53:26 -0700 (PDT) Date: Tue, 11 Jun 2019 13:53:20 +0100 From: Sudeep Holla To: Al Stone Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Sudeep Holla Subject: Re: [RFC PATCH] ACPI / processors: allow a processor device _UID to be a string Message-ID: <20190611125258.GA16445@e107155-lin> References: <20190610200734.1182-1-ahs3@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190610200734.1182-1-ahs3@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 10, 2019 at 02:07:34PM -0600, Al Stone wrote: > In the ACPI specification, section 6.1.12, a _UID may be either an > integer or a string object. Up until now, when defining processor > Device()s in ACPI (_HID ACPI0007), only integers were allowed even > though this ignored the specification. As a practical matter, it > was not an issue. > > Recently, some DSDTs have shown up that look like this: > > Device (XX00) > { > Name (_HID, "ACPI0007" /* Processor Device */) > Name (_UID, "XYZZY-XX00") > ..... > } > > which is perfectly legal. However, the kernel will report instead: > I am not sure how this can be perfectly legal from specification perspective. It's legal with respect to AML namespace but then the other condition of this matching with entries in static tables like MADT is not possible where there are declared to be simple 4 byte integer/word. Same is true for even ACPI0010, the processor container objects which need to match entries in PPTT, ACPI Processor UID(in MADT): The OS associates this GICC(applies even for APIC and family) Structure with a processor device object in the namespace when the _UID child object of the processor device evaluates to a numeric value that matches the numeric value in this field. So for me that indicates it can't be string unless you have some ways to match those _UID entries to ACPI Processor ID in MADT and PPTT. Let me know if I am missing to consider something here. -- Regards, Sudeep