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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250504-acoustic-skink-of-greatness-1e90ac@kuoka>
Date: Sun, 4 May 2025 19:51:02 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Alireza Sanaee <alireza.sanaee@...wei.com>
Cc: devicetree@...r.kernel.org, robh@...nel.org, 
	jonathan.cameron@...wei.com, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linuxarm@...wei.com, mark.rutland@....com, 
	shameerali.kolothum.thodi@...wei.com
Subject: Re: [PATCH v2 6/6] of: of_cpu_phandle_to_id to support SMT threads

On Fri, May 02, 2025 at 05:13:00PM GMT, Alireza Sanaee wrote:
> Enhance the API to support SMT threads, this will allow sharing resources among
> multiple SMT threads.

<form letter>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC (and consider --no-git-fallback argument, so you will
not CC people just because they made one commit years ago). It might
happen, that command when run on an older kernel, gives you outdated
entries. Therefore please be sure you base your patches on recent Linux
kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about 'b4 prep --auto-to-cc' if you added new
patches to the patchset.
</form letter>	

> 
> Enabled the sharing of resources, such as L1 Cache and clocks, between SMT
> threads. It introduces a fix that uses thread IDs to match each CPU thread in
> the register array within the cpu-node. This ensures that the cpu-map or any
> driver relying on this API is fine even when SMT threads share resources.
> 
> Additionally, I have tested this for CPU based on the discussions in [1], I
> adopted the new cpu-map layout, where the first parameter is a phandle and the
> second is the local thread index, as shown below:
> 
> In the CPU map, there are two cases that only one occurs at at time.
>     1) "cpu" = <phandle>
>     2) "cpus" = <phandle> <index>
> 
> The first case addresses non-SMTs and the second case addresses SMTs
> that the variable must be cpu(s) with an index where we later look up
> the reg array with that.
> 
>     core0 {
>       thread0 {
>         cpus = <&cpu0 0>;

Not so sure, dtschema says only one item is allowed in the phandle and I
do not see here binding change.

Although this wasn't even sent to me, so I'll just ignore your patchset.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ