public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
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

      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