Adding brcmstb-hwspinlock bindings.
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
---
.../hwlock/brcm,brcmstb-hwspinlock.yaml | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
diff --git a/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
new file mode 100644
index 000000000000..f45399b4fe0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwlock/brcm,brcmstb-hwspinlock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom settop Hardware Spinlock
+
+maintainers:
+ - Kamal Dasu <kamal.dasu@broadcom.com>
+
+properties:
+ compatible:
+ const: brcm,brcmstb-hwspinlock
+
+ "#hwlock-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#hwlock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ hwlock@8404038 {
+ compatible = "brcm,brcmstb-hwspinlock";
+ reg = <0x8404038 0x40>;
+ #hwlock-cells = <1>;
+ };
+
--
2.34.1On Mon, Sep 29, 2025 at 04:06:24PM -0400, Kamal Dasu wrote:
>Adding brcmstb-hwspinlock bindings.
>
>Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
>---
> .../hwlock/brcm,brcmstb-hwspinlock.yaml | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
>
>+ - |
>+ hwlock@8404038 {
>+ compatible = "brcm,brcmstb-hwspinlock";
>+ reg = <0x8404038 0x40>;
Just have a question:
the base is not 64KB aligned, so just want to know is this module part of
the other ip block?
Thanks,
Peng
>+ #hwlock-cells = <1>;
>+ };
>+
>--
>2.34.1
>
On 9/30/2025 7:58 PM, Peng Fan wrote:
> On Mon, Sep 29, 2025 at 04:06:24PM -0400, Kamal Dasu wrote:
>> Adding brcmstb-hwspinlock bindings.
>>
>> Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
>> ---
>> .../hwlock/brcm,brcmstb-hwspinlock.yaml | 36 +++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
>>
>> + - |
>> + hwlock@8404038 {
>> + compatible = "brcm,brcmstb-hwspinlock";
>> + reg = <0x8404038 0x40>;
>
> Just have a question:
> the base is not 64KB aligned, so just want to know is this module part of
> the other ip block?
The alignment is relevant to determine whether this is part of a larger
IP block or not, though I am not sure why you use 64KB as a criteria.
Our HW rules are to match the highest OS available page size for the
systems, for us it used to be 4KB and is now 16KB alignment.
The block is part of a "sundry" IP which has lots of controls that did
not belong anywhere else, for better or for worse (pin/mux controls, SoC
identification, drive strength, reset controls, and other misc bits).
--
Florian
On Tue, Sep 30, 2025 at 9:46 PM Peng Fan <peng.fan@oss.nxp.com> wrote:
>
> On Mon, Sep 29, 2025 at 04:06:24PM -0400, Kamal Dasu wrote:
> >Adding brcmstb-hwspinlock bindings.
> >
> >Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> >---
> > .../hwlock/brcm,brcmstb-hwspinlock.yaml | 36 +++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
> >
> >+ - |
> >+ hwlock@8404038 {
> >+ compatible = "brcm,brcmstb-hwspinlock";
> >+ reg = <0x8404038 0x40>;
>
> Just have a question:
> the base is not 64KB aligned, so just want to know is this module part of
> the other ip block?
>
Yes this part of other ip block.
> Thanks,
> Peng
>
> >+ #hwlock-cells = <1>;
> >+ };
> >+
> >--
> >2.34.1
> >
On Mon, Sep 29, 2025 at 04:06:24PM -0400, Kamal Dasu wrote:
> Adding brcmstb-hwspinlock bindings.
>
> Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> ---
> .../hwlock/brcm,brcmstb-hwspinlock.yaml | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
> new file mode 100644
> index 000000000000..f45399b4fe0b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
> @@ -0,0 +1,36 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwlock/brcm,brcmstb-hwspinlock.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom settop Hardware Spinlock
> +
> +maintainers:
> + - Kamal Dasu <kamal.dasu@broadcom.com>
> +
> +properties:
> + compatible:
> + const: brcm,brcmstb-hwspinlock
Is "brcmstb" actually the name of a single platform?
Looking at the "brcmstb" pci binding, it looks like there's a whole load
of different devices there and none use "brcmstb":
- brcm,bcm2711-pcie # The Raspberry Pi 4
- brcm,bcm2712-pcie # Raspberry Pi 5
- brcm,bcm4908-pcie
- brcm,bcm7211-pcie # Broadcom STB version of RPi4
- brcm,bcm7216-pcie # Broadcom 7216 Arm
- brcm,bcm7278-pcie # Broadcom 7278 Arm
- brcm,bcm7425-pcie # Broadcom 7425 MIPs
- brcm,bcm7435-pcie # Broadcom 7435 MIPs
- brcm,bcm7445-pcie # Broadcom 7445 Arm
- brcm,bcm7712-pcie # Broadcom STB sibling of Rpi 5
If "stb" means "set top box", it sounds like a catchall for disparate
devices, which isn't permitted.
> +
> + "#hwlock-cells":
> + const: 1
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - "#hwlock-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + hwlock@8404038 {
> + compatible = "brcm,brcmstb-hwspinlock";
> + reg = <0x8404038 0x40>;
> + #hwlock-cells = <1>;
> + };
> +
> --
> 2.34.1
>
On 9/30/25 12:03, Conor Dooley wrote: > On Mon, Sep 29, 2025 at 04:06:24PM -0400, Kamal Dasu wrote: >> Adding brcmstb-hwspinlock bindings. >> >> Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com> >> --- >> .../hwlock/brcm,brcmstb-hwspinlock.yaml | 36 +++++++++++++++++++ >> 1 file changed, 36 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml >> >> diff --git a/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml >> new file mode 100644 >> index 000000000000..f45399b4fe0b >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml >> @@ -0,0 +1,36 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/hwlock/brcm,brcmstb-hwspinlock.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Broadcom settop Hardware Spinlock >> + >> +maintainers: >> + - Kamal Dasu <kamal.dasu@broadcom.com> >> + >> +properties: >> + compatible: >> + const: brcm,brcmstb-hwspinlock > > Is "brcmstb" actually the name of a single platform? > Looking at the "brcmstb" pci binding, it looks like there's a whole load > of different devices there and none use "brcmstb": > - brcm,bcm2711-pcie # The Raspberry Pi 4 > - brcm,bcm2712-pcie # Raspberry Pi 5 > - brcm,bcm4908-pcie > - brcm,bcm7211-pcie # Broadcom STB version of RPi4 > - brcm,bcm7216-pcie # Broadcom 7216 Arm > - brcm,bcm7278-pcie # Broadcom 7278 Arm > - brcm,bcm7425-pcie # Broadcom 7425 MIPs > - brcm,bcm7435-pcie # Broadcom 7435 MIPs > - brcm,bcm7445-pcie # Broadcom 7445 Arm > - brcm,bcm7712-pcie # Broadcom STB sibling of Rpi 5 > > If "stb" means "set top box", it sounds like a catchall for disparate > devices, which isn't permitted. Unlike PCIe, the HW spinlock hardware has been stable across all Set-top box chips ever since it was added, which is why the catch all is IMHO adequate here. -- Florian
On Tue, Sep 30, 2025 at 12:09:01PM -0700, Florian Fainelli wrote: > On 9/30/25 12:03, Conor Dooley wrote: > > On Mon, Sep 29, 2025 at 04:06:24PM -0400, Kamal Dasu wrote: > > > Adding brcmstb-hwspinlock bindings. > > > > > > Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com> > > > --- > > > .../hwlock/brcm,brcmstb-hwspinlock.yaml | 36 +++++++++++++++++++ > > > 1 file changed, 36 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml > > > new file mode 100644 > > > index 000000000000..f45399b4fe0b > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml > > > @@ -0,0 +1,36 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/hwlock/brcm,brcmstb-hwspinlock.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Broadcom settop Hardware Spinlock > > > + > > > +maintainers: > > > + - Kamal Dasu <kamal.dasu@broadcom.com> > > > + > > > +properties: > > > + compatible: > > > + const: brcm,brcmstb-hwspinlock > > > > Is "brcmstb" actually the name of a single platform? > > Looking at the "brcmstb" pci binding, it looks like there's a whole load > > of different devices there and none use "brcmstb": > > - brcm,bcm2711-pcie # The Raspberry Pi 4 > > - brcm,bcm2712-pcie # Raspberry Pi 5 > > - brcm,bcm4908-pcie > > - brcm,bcm7211-pcie # Broadcom STB version of RPi4 > > - brcm,bcm7216-pcie # Broadcom 7216 Arm > > - brcm,bcm7278-pcie # Broadcom 7278 Arm > > - brcm,bcm7425-pcie # Broadcom 7425 MIPs > > - brcm,bcm7435-pcie # Broadcom 7435 MIPs > > - brcm,bcm7445-pcie # Broadcom 7445 Arm > > - brcm,bcm7712-pcie # Broadcom STB sibling of Rpi 5 > > > > If "stb" means "set top box", it sounds like a catchall for disparate > > devices, which isn't permitted. > > Unlike PCIe, the HW spinlock hardware has been stable across all Set-top box > chips ever since it was added, which is why the catch all is IMHO adequate > here. I see. Now that I look more, there are other places where "stb" is used. Sounds like "brcmstb" as generic fallback would probably be okay then. Either way, the duplicate 1/3 patch needs to be sorted out.
© 2016 - 2025 Red Hat, Inc.