linux-kernel - Re: [PATCH v3 1/3] dt-bindings: hwlock: Adding brcmstb-hwspinlock support

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]

Message-ID: <cd174f01-30f6-4a6c-b55e-a15c088eded1@broadcom.com>
Date: Tue, 14 Oct 2025 15:01:53 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
 Kamal Dasu <kamal.dasu@...adcom.com>
Cc: peng.fan@....nxp.com, andersson@...nel.org,
 baolin.wang@...ux.alibaba.com, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, bcm-kernel-feedback-list@...adcom.com,
 linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: hwlock: Adding brcmstb-hwspinlock
 support

On 10/14/25 14:46, Krzysztof Kozlowski wrote:
> On 14/10/2025 17:40, Kamal Dasu wrote:
>> On Thu, Oct 9, 2025 at 10:00 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>>
>>> On 09/10/2025 23:20, Kamal Dasu wrote:
>>>> The broadcom settop SoCs have hardware semaphores as part of "sundry"
>>>> IP block which has other controls that do not belong anywhere else.
>>>> e.g. pin/mux controls, SoC identification, drive strength, reset controls,
>>>> and other misc bits are part of this block.
>>>
>>> This does not explain why this has to be a separate block. Rob comment
>>> stays valid - this belongs to parent node.
>>>
>>
>> We do not have a separate parent node where this will fit in. We have
> 
> 
> So what is the parent? simple bus?

Ultimately yes, there is a parent node which is a "simple-bus" but what 
we effectively did is break up the "sun-top-ctrl" node into register 
ranges that are on 4 byte boundary, because the functionality offered in 
that aggregate is partitioned on a 4 byte boundary.

Now, we could utilize the fact that the node has been exposed in our 
Device Trees using a syson:

                 sun_top_ctrl: syscon@...4000 {
                         compatible = "brcm,brcmstb-sun-top-ctrl",
                                 "syscon";
                         reg = <0x8404000 0x708>;
                 };


> 
>> the DWORD aligned  register defined here as organized in the SUNDRY
>> block.
> 
> 
> I don't know what SUNDRY is.

https://www.merriam-webster.com/dictionary/sundry
-- 
Florian