[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6f7f9bb-547d-3fd3-f3f8-1d55181f63d7@huawei.com>
Date: Tue, 18 Jun 2019 18:23:25 +0100
From: John Garry <john.garry@...wei.com>
To: Valentin Schneider <valentin.schneider@....com>,
Jeremy Linton <jeremy.linton@....com>,
<linux-arm-kernel@...ts.infradead.org>
CC: <linux-acpi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<catalin.marinas@....com>, <will.deacon@....com>,
<rjw@...ysocki.net>, <sudeep.holla@....com>, <lenb@...nel.org>
Subject: Re: [PATCH v2 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
On 18/06/2019 15:40, Valentin Schneider wrote:
> On 18/06/2019 15:21, Jeremy Linton wrote:
> [...]
>>>> + * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found or
>>>> + * the table revision isn't new enough.
>>>> + * Otherwise returns flag value
>>>> + */
>>>
>>> Nit: strictly speaking we're not returning the flag value but its mask
>>> applied to the flags field. I don't think anyone will care about getting
>>> the actual flag value, but it should be made obvious in the doc:
>>
>> Or I clarify the code to actually do what the comments says. Maybe that is what John G was also pointing out too?
>>
No, I was just saying that the kernel topology can be broken without
this series.
>
> Mmm I didn't find any reply from John regarding this in v1, but I wouldn't
> mind either way, as long as the doc & code are aligned.
>
BTW, to me, function acpi_pptt_cpu_is_thread() seems to try to do too
much, i.e. check if the PPTT is new enough to support the thread flag
and also check if it is set for a specific cpu. I'd consider separate
functions here.
thanks,
John
> [...]
>
> .
>
Powered by blists - more mailing lists