From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=3.0 tests=DATE_IN_PAST_12_24, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 974E1C2BA83 for ; Wed, 12 Feb 2020 17:17:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 765E221739 for ; Wed, 12 Feb 2020 17:17:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726982AbgBLRRr (ORCPT ); Wed, 12 Feb 2020 12:17:47 -0500 Received: from foss.arm.com ([217.140.110.172]:35622 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726728AbgBLRRq (ORCPT ); Wed, 12 Feb 2020 12:17:46 -0500 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 67F7330E; Wed, 12 Feb 2020 09:17:46 -0800 (PST) Received: from [192.168.122.164] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2DB953F68F; Wed, 12 Feb 2020 09:17:46 -0800 (PST) Subject: Re: About PPTT find_acpi_cpu_topology_package() To: John Garry , Sudeep Holla Cc: "Guohanjun (Hanjun Guo)" , ACPI Devel Maling List , "liuqi (BA)" , wanghuiqiang References: <7a888a84-d4c5-2b49-05f3-29876d49cae6@huawei.com> <20200212115945.GA36981@bogus> <20200212135551.GB36981@bogus> <1a04ddf8-4903-2986-a94e-c070dc2c2160@huawei.com> <3c15a54a-18ac-265e-c16c-272577b9dead@arm.com> From: Jeremy Linton Message-ID: Date: Tue, 11 Feb 2020 15:12:42 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi, On 2/12/20 10:41 AM, John Garry wrote: >>> >>> How about something like this: >>> >>> --- a/drivers/acpi/pptt.c >>> +++ b/drivers/acpi/pptt.c >>> @@ -515,6 +515,8 @@ static int topology_get_acpi_cpu_tag(struct >>> acpi_table_header *table, >>>    if (level == 0 || cpu_node->flags & >>> ACPI_PPTT_ACPI_PROCESSOR_ID_VALID) >>>      return cpu_node->acpi_processor_id; >>> +   if (level == PPTT_ABORT_PACKAGE) >>> +    pr_warn_once("ACPI Processor ID valid not set for physical >>> package node, will use node table offset as substitute for UID\n"); >> > > Hi Jeremy, > >> To clarify my other email there, since I can't seem to type clearly.. >> >> Just note that find_acpi_cpu_topology_hetero_id() is also using a >> PPTT_ABORT_PACKAGE termination. > > OK, so I may need to check the flag == ACPI_PPTT_PHYSICAL_PACKAGE also. Without a lot of thought, it probably sufficient to only check the flag. The level is mostly noise, the ==0 check in there was to work around the verbiage in the first PPTT revision. > > BTW, Is the value returned by find_acpi_cpu_topology_hetero_id() also > exposed to userspace some way? Or any other PPTT offsets? Not yet :) > >> >> >>>                  return ACPI_PTR_DIFF(cpu_node, table); >>>          } >>>          pr_warn_once("PPTT table found, but unable to locate core %d >>> (%d)\n", >>> > > I'll validate Sudeep's suggestion to set the Processor ID valid flag and > appropriate processor id for the physical package cpu node with an > experimental firmware before sending any patch. There seems to be a bit > of doubt on your part regarding that. Just pay attention to the definition of _UID/Acpi Processor UID, etc. The MADT says that ACPI processor UID is matched with a processor container with a matching numeric _UID. The processor container definition says that the _UID must be unique in the processor container hierarchy. To me, this says that processor containers/ACPI processors UIDs must all be unique. AKA, you can't have both a processor with _UID=1 and a socket with _UID=1. Given that linux isn't matching the socket _UID, you can create a PPTT+DSDT that does what you want but likely violates the spec.