linux-kernel - [PATCH 1/2] arch_topology: support for describing cache topology from DT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 22 Apr 2022 09:48:34 +0000
From:   王擎 <wangqing@...o.com>
To:     Sudeep Holla <sudeep.holla@....com>
CC:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [PATCH 1/2] arch_topology: support for describing cache topology from
 DT

> 
>On Thu, Apr 21, 2022 at 07:55:57AM -0700, Qing Wang wrote:
>> From: Wang Qing <wangqing@...o.com>
>> 
>> When ACPI is not enabled, we can get cache topolopy from DT like:
>> *             cpu0: cpu@000 {
>> *                     next-level-cache = <&L2_1>;
>> *                     L2_1: l2-cache {
>> *                              compatible = "cache";
>> *                             next-level-cache = <&L3_1>;
>> *                      };
>> *                     L3_1: l3-cache {
>> *                              compatible = "cache";
>> *                      };
>> *             };
>> *
>> *             cpu1: cpu@001 {
>> *                     next-level-cache = <&L2_1>;
>> *             };
>> *             ...
>> *             };
>> cache_topology hold the pointer describing "next-level-cache",
>> it can describe the cache topology of every level.
>
>As I mentioned before, I would like to avoid any duplication and see
>what can be reused from drivers/base/cacheinfo.c

I tried, but cacheinfo initialization is too late, 
we can discuss this part after 2/2 is approved.

>
>We can discuss and see how to proceed on that once we settle/agree on
>2/2. I don't want to waste your or my time if we don't end up using this.
>So let us look at this once we agree to push the sched related changes
>as we have used generic ones so far and you want to introduce arm64 specific
>levels. That requires some discussions and thoughts before we can finalise.
>
>Also I have mentioned you to keep Dietmar and Vincent in cc for all sched
>related changes which you failed to do again. I expect you fix that next
>time if you want them to help you in discussions and make any progress on
>this. Otherwise it may get ignored as you don't have all the right
>people in cc.

I found this, and have forwarded it to Dietmar and Vincent, 
I definitely will fix that next time.

Thanks,
Qing
>
>--
>Regards,
>Sudeep