All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	"liuqi (BA)" <liuqi115@huawei.com>,
	wanghuiqiang <wanghuiqiang@huawei.com>
Subject: Re: About PPTT find_acpi_cpu_topology_package()
Date: Wed, 12 Feb 2020 14:41:04 +0000	[thread overview]
Message-ID: <1a04ddf8-4903-2986-a94e-c070dc2c2160@huawei.com> (raw)
In-Reply-To: <20200212135551.GB36981@bogus>

On 12/02/2020 13:55, Sudeep Holla wrote:
> On Wed, Feb 12, 2020 at 12:48:33PM +0000, John Garry wrote:
>> On 12/02/2020 11:59, Sudeep Holla wrote:
> 
> [...]
> 

Hi Sudeep,

>>> Yes, as mentioned above. We are not going to do extra work for lazy firmware.
>>
>> I don't think it's reasonable to just label this as lazy. The table may just
>> not have the flag set unintentionally. FW and software guys make mistakes,
>> like the mistakes in PPTT, itself.
>>
> 
> We are not talking about flags, it's UID and it is pretty important if
> there are more than one objects of same time.
> 

I am talking about the Processor ID valid flag, which is specifically 
related.

>>> Linux also will be lazy on such platform and provide weird unique numbers
>>> like in the above case you have mentioned.
>>
>> Personally I think that the kernel can be do better than provide meaningless
>> values like this, since it knows the processor IDs and which physical
>> package they belong to.
>>
> 
> This was discussed quite a lot, I can dig and point you to it. That's the
> reason for choosing offset. We are *not going back* to this again. Fix the
> firmware before it gets copied for all future platforms and Linux has to
> deal with that *forever*.

I would liked to have been made aware earlier of the oversight. Quite 
often we only find problems when someone or something complains.

It is a strange API to provide offsets like this, and I did not realize 
that they were actually being exposed to userspace.

> 
>> If not, at least make the user know of potential deficiencies in the table.
>>
> 
> How ? What are your suggestions ? Does adding a warning or note that UID
> is missing and offset is chosen help ? 

I'd say so. I know now, but let's save others the potential hassle. And 
having this debate again.

I am kind of fine with that.

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");
                 return ACPI_PTR_DIFF(cpu_node, table);
         }
         pr_warn_once("PPTT table found, but unable to locate core %d 
(%d)\n",

Thanks,
John

  parent reply	other threads:[~2020-02-12 14:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 11:20 About PPTT find_acpi_cpu_topology_package() John Garry
2020-02-12 11:59 ` Sudeep Holla
2020-02-12 12:48   ` John Garry
2020-02-12 13:55     ` Sudeep Holla
2020-02-11 18:49       ` Jeremy Linton
2020-02-12 15:36         ` Sudeep Holla
2020-02-12 14:41       ` John Garry [this message]
2020-02-11 19:01         ` Jeremy Linton
2020-03-25 11:43           ` John Garry
2020-02-11 19:31         ` Jeremy Linton
2020-02-12 16:41           ` John Garry
2020-02-11 21:12             ` Jeremy Linton
2020-02-13 11:52               ` John Garry
2020-02-13 14:00                 ` Sudeep Holla
2020-02-13 14:33                   ` John Garry
2020-02-13 16:52                     ` Jeremy Linton
2020-02-14 10:35                       ` John Garry
2020-02-14 11:22                         ` Sudeep Holla
2020-02-12 15:32         ` Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a04ddf8-4903-2986-a94e-c070dc2c2160@huawei.com \
    --to=john.garry@huawei.com \
    --cc=guohanjun@huawei.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=liuqi115@huawei.com \
    --cc=sudeep.holla@arm.com \
    --cc=wanghuiqiang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.