On Mon, Feb 16, 2015 at 09:56:21AM +0000, Sudeep Holla wrote:
> Hi Mark,
>
> On 12/02/15 14:07, Mark Rutland wrote:
> > Hi,
> >
> > On Wed, Jan 21, 2015 at 04:46:32PM +0000, Mark Rutland wrote:
> >> On Wed, Jan 21, 2015 at 12:02:30PM +0000, Sudeep Holla wrote:
> >>> Commit 5d425c18653731af6 ("arm64: kernel: add support for cpu
> >>> cache information") adds cacheinfo support for ARM64. Since
> >>> there's no architectural way of detecting the cpus that share
> >>> particular cache, device tree can be used and the core cacheinfo
> >>> already supports the same.
> >>
> >> This still leaves the possibility that misleading information is
> >> exposed for systems from other vendors. I've made a quick attempt
> >> to Cc the authors of other arm64 dts here.
> >>
> >> Given that in the absence of these nodes we can't derive a complete
> >> view of the cache hierarchy, shouldn't we only expose the cacheinfo
> >> when we have these nodes and can therefore produce correct values?
> >
> > I'm still rather concerned about exposing misleading cache info in
> > this manner. Is there no way we can limit the exposure of this
> > information to those cases where we actually have the information?
> >
>
> Yes I have a patch to check all the device nodes in the cache hierarchy
> before initializing the sysfs. So cacheinfo won't be setup if all the
> device nodes aren't found(at-least on architecture like ARM/ARM64 which
> depends on DT). I will post it soon, was waiting for a week so that it's
> not lost during merge window.
Great, that's exactly what I was hoping for!
> > Do we know if/how this will work for ACPI systems?
> >
>
> It should be similar to DT i.e. the hierarchy must be completely
> detected through ACPI tables/methods, but I have not thought of
> implementation specifics yet.
Ok.
Thanks,
Mark
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
