All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeffrey Hugo <jhugo@codeaurora.org>
To: Sudeep Holla <sudeep.holla@arm.com>,
	Jeremy Linton <jeremy.linton@arm.com>,
	rjw@rjwysocki.net, linux-acpi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, vkilari@codeaurora.org
Subject: Re: [PATCH] ACPI/PPTT: Handle architecturally unknown cache types
Date: Wed, 12 Sep 2018 09:57:14 -0600	[thread overview]
Message-ID: <c835027a-9e3e-221b-01da-0e1930c4e58f@codeaurora.org> (raw)
In-Reply-To: <2873c62f-1bf9-5aa0-b3a2-07980ef61d35@arm.com>

On 9/12/2018 9:38 AM, Sudeep Holla wrote:
> 
> 
> On 12/09/18 16:27, Sudeep Holla wrote:
>>
>>
>> On 12/09/18 15:41, Jeffrey Hugo wrote:
> 
> [...]
> 
>>>
>>> Correct.  However, what if you have a NOCACHE (not architecturally
>>> specified), that is fully described in PPTT, as a non-unified cache
>>> (data only)?  Unlikely?  Maybe.  Still seem possible though, therefore I
>>> feel this assumption is suspect.
>>>
>>
>> Yes, we have other issues if the architecturally not specified cache is
>> not unified irrespective of what PPTT says. So we may need to review and
>> see if that assumption is removed everywhere.
>>
>> Until then why can't a simple change fix the issue you have:
>>
>> -->8
>>
>> diff --git i/drivers/acpi/pptt.c w/drivers/acpi/pptt.c
>> index d1e26cb599bf..f74131201f5e 100644
>> --- i/drivers/acpi/pptt.c
>> +++ w/drivers/acpi/pptt.c
>> @@ -406,7 +406,8 @@ static void update_cache_properties(struct cacheinfo
>> *this_leaf,
>>           * update the cache type as well.
>>           */
>>          if (this_leaf->type == CACHE_TYPE_NOCACHE &&
>> -           valid_flags == PPTT_CHECKED_ATTRIBUTES)
>> +           (valid_flags == PPTT_CHECKED_ATTRIBUTES ||
>> +            found_cache->flags & ACPI_PPTT_CACHE_TYPE_VALID))
> 
> Looking at this again, if we are supporting just presence of cache type
> and size(may be), then we can drop the whole valid_flags thing here.
> 
>>                  this_leaf->type = CACHE_TYPE_UNIFIED;
>>   }
>>

Yes, this change fixes my usecase.  I think it invalidates the comment, 
and really, the comment should probably mention that we assume unified 
type because there are other issues in supporting architecturally not 
specified inst/data only caches.

Do you want a V2 with this?  If so, do you want the fixes tag removed 
since you seem to view this as not a bug?

I don't think I clearly understand the purpose of the valid flags, 
therefore I feel as though I'm not sure if it can be dropped or not.  Is 
it fair to say that what the valid flags is accomplishing is identifying 
if we have a sufficient level of information to support this cache?  If 
not, then should the cacheinfo driver not expose any sysfs information 
about the cache?

-- 
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

  reply	other threads:[~2018-09-12 15:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-11 19:32 [PATCH] ACPI/PPTT: Handle architecturally unknown cache types Jeffrey Hugo
2018-09-11 20:16 ` Jeremy Linton
2018-09-11 20:38   ` Jeffrey Hugo
2018-09-11 21:25     ` Jeremy Linton
2018-09-12 14:41       ` Jeffrey Hugo
2018-09-12 15:27         ` Sudeep Holla
2018-09-12 15:38           ` Sudeep Holla
2018-09-12 15:57             ` Jeffrey Hugo [this message]
2018-09-12 16:15               ` Sudeep Holla
2018-09-12 16:25                 ` Jeffrey Hugo
2018-09-12 15:39         ` Jeremy Linton
2018-09-12 16:06           ` Jeffrey Hugo
2018-09-12 10:49     ` Sudeep Holla
2018-09-12 14:48       ` Jeffrey Hugo
2018-09-12 15:32         ` Sudeep Holla
2018-09-13  5:51       ` Brice Goglin
2018-09-13  9:39         ` James Morse
2018-09-13 10:35           ` Sudeep Holla
2018-09-13 11:53             ` Brice Goglin
2018-09-13 15:10               ` Jeffrey Hugo
2018-09-13 15:16               ` Sudeep Holla
2018-09-12 10:37   ` 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=c835027a-9e3e-221b-01da-0e1930c4e58f@codeaurora.org \
    --to=jhugo@codeaurora.org \
    --cc=jeremy.linton@arm.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=sudeep.holla@arm.com \
    --cc=vkilari@codeaurora.org \
    /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.