From: Sudeep Holla <sudeep.holla@arm.com>
To: Jeremy Linton <jeremy.linton@arm.com>,
Jeffrey Hugo <jhugo@codeaurora.org>,
rjw@rjwysocki.net, linux-acpi@vger.kernel.org
Cc: Sudeep Holla <sudeep.holla@arm.com>,
linux-kernel@vger.kernel.org, vkilari@codeaurora.org
Subject: Re: [PATCH] ACPI/PPTT: Handle architecturally unknown cache types
Date: Wed, 12 Sep 2018 11:37:35 +0100 [thread overview]
Message-ID: <3eef4199-f99e-2d1d-0d1f-98b30cafb5bf@arm.com> (raw)
In-Reply-To: <f62f22a6-2dd8-f254-dbaf-b9e224099afd@arm.com>
On 11/09/18 21:16, Jeremy Linton wrote:
> Hi Jeffrey,
>
> (+Sudeep)
>
Thanks for looping me in.
>
> If you look at the next line of code following this comment its going to
> update the cache type for fully populated PPTT nodes. Although with the
> suggested change its only going to activate if someone completely fills
> out the node and fails to set the valid flag on the cache type.
>
> What I suspect is happening in the reported case is that the nodes in
> the PPTT table are missing fields we consider to be important. Since
> that data isn't being filled out anywhere else, so we leave the cache
> type alone too. This has the effect of hiding sysfs nodes with
> incomplete information.
>
> Also, the lack of the DATA/INST fields is based on the assumption that
> the only nodes which need their type field updated are outside of the
> CPU core itself so they are pretty much guaranteed to be UNIFIED. Are
> you hitting this case?
>
Completely agree with you.
--
Regards,
Sudeep
prev parent reply other threads:[~2018-09-12 10:37 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
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 [this message]
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=3eef4199-f99e-2d1d-0d1f-98b30cafb5bf@arm.com \
--to=sudeep.holla@arm.com \
--cc=jeremy.linton@arm.com \
--cc=jhugo@codeaurora.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox