Re: [PATCH v2 1/5] dt-bindings: bus: add Broadcom BCM6362 WLAN AXI backplane

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 5662 bytes --]

On Tue, Oct 13, 2026 at 06:09:25PM +0200, Alessio Ferri wrote:
> On Mon, 12 Oct 2026 20:13:46 +0100
> Conor Dooley <conor@kernel.org> wrote:
> 
> > On Mon, Oct 12, 2026 at 12:45:25AM +0200, Alessio Ferri wrote:
> > > The BCM6362 integrates a WLAN macro on its own AXI backplane.
> > > Unlike the backplanes covered by brcm,bus-axi, its cores have no
> > > wrappers: clock gating and reset are driven through a separate
> > > WLAN control register block, and the macro needs a clock, two
> > > resets and the WLAN pads power domain before the backplane can be
> > > accessed. The backplane registers are big-endian.
> > > 
> > > Add a binding describing the ChipCommon and WLAN control register
> > > blocks, the clock, resets and power domain, and the interrupt-map
> > > used to route core interrupts, following the brcm,bus-axi
> > > convention.
> > > 
> > > Assisted-by: LLM
> > > Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it>
> > > ---
> > >  .../bindings/bus/brcm,bcm6362-wlan-bus-axi.yaml    | 100
> > > +++++++++++++++++++++ 1 file changed, 100 insertions(+)
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/bus/brcm,bcm6362-wlan-bus-axi.yaml
> > > b/Documentation/devicetree/bindings/bus/brcm,bcm6362-wlan-bus-axi.yaml
> > > new file mode 100644 index 000000000000..183de28fd032 --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/bus/brcm,bcm6362-wlan-bus-axi.yaml
> > > @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR
> > > BSD-2-Clause) +%YAML 1.2
> > > +---
> > > +$id:
> > > http://devicetree.org/schemas/bus/brcm,bcm6362-wlan-bus-axi.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml# +
> > > +title: Broadcom BCM6362 integrated WLAN AXI backplane
> > > +
> > > +maintainers:
> > > +  - Alessio Ferri <alessio.ferri@mythread.it>
> > > +
> > > +description: |
> > > +  The BCM6362 integrates a WLAN macro on a dedicated AXI backplane
> > > +  (bcma), whose cores are discovered at runtime from the backplane
> > > +  EROM.
> > > +
> > > +  The cores have no DMP wrappers: clock gating and reset of the
> > > +  ChipCommon and 802.11 cores are controlled through a separate
> > > WLAN
> > > +  control register block. The backplane registers are big-endian.
> > > +
> > > +  Interrupts of the cores are described with an interrupt-map,
> > > keyed
> > > +  by the core base address and the core interrupt index, as for
> > > +  brcm,bus-axi.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: brcm,bcm6362-wlan-bus-axi
> > > +
> > > +  reg:
> > > +    items:
> > > +      - description: ChipCommon core registers
> > > +      - description: WLAN control registers
> > > +
> > > +  reg-names:
> > > +    items:
> > > +      - const: chipcommon
> > > +      - const: wlan-ctrl
> > > +
> > > +  clocks:
> > > +    maxItems: 1
> > > +
> > > +  resets:
> > > +    items:
> > > +      - description: WLAN macro reset
> > > +      - description: WLAN UBUS interface reset
> > > +
> > > +  reset-names:
> > > +    items:
> > > +      - const: wlan
> > > +      - const: wlan-ubus
> > > +
> > > +  power-domains:
> > > +    maxItems: 1
> > > +
> > > +  "#address-cells":
> > > +    const: 1
> > > +
> > > +  "#interrupt-cells":
> > > +    const: 1
> > > +
> > > +  interrupt-map-mask: true
> > > +
> > > +  interrupt-map: true  
> > 
> > I'd like to see some constraints on these, particularly since there's
> > a very high chance the mask is fixed and the map has a fixed number of
> > elements.
> 
> Yes, you're right, i'll add them in the next batch. 
> 
> > 
> > I'd also like to see what the child nodes on this bus look like. Do
> > you have some dts examples?
> > 
> 
> the children are enumerated dynamically by bcma itself, so i don't
> expect any. I know that a childless bus is suspect, but bcma seems to
> work this way.

How does the interrupt map work if nothing references the bus node as an
interrupt parent?
I assume there's some code in the driver for the bus that detects what
bus-indexed interrupt the device wants, and the map is used to convert
that into an interrupt number of the interrupt parent of the bus?

> 
> > Thanks,
> > Conor.
> > 
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - reg-names
> > > +  - clocks
> > > +  - resets
> > > +  - reset-names
> > > +  - power-domains
> > > +  - "#address-cells"
> > > +  - "#interrupt-cells"
> > > +  - interrupt-map-mask
> > > +  - interrupt-map
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    #include <dt-bindings/clock/bcm6362-clock.h>
> > > +    #include <dt-bindings/reset/bcm6362-reset.h>
> > > +    #include <dt-bindings/soc/bcm6362-pm.h>
> > > +
> > > +    bus@10004000 {
> > > +        compatible = "brcm,bcm6362-wlan-bus-axi";
> > > +        reg = <0x10004000 0x1000>, <0x10007000 0x100>;
> > > +        reg-names = "chipcommon", "wlan-ctrl";
> > > +
> > > +        #address-cells = <1>;
> > > +        clocks = <&periph_clk BCM6362_CLK_WLAN_OCP>;
> > > +        #interrupt-cells = <1>;
> > > +        interrupt-map = <0x00005000 0 &periph_intc 7>;
> > > +        interrupt-map-mask = <0x000fffff 0xffff>;
> > > +        power-domains = <&periph_pwr
> > > BCM6362_POWER_DOMAIN_WLAN_PADS>;
> > > +        resets = <&periph_rst BCM6362_RST_WLAN_SHIM>,
> > > +                 <&periph_rst BCM6362_RST_WLAN_UBUS>;
> > > +        reset-names = "wlan", "wlan-ubus";
> > > +    };
> > > 
> > > -- 
> > > 2.56.0
> > >   
> 
> Thanks for the inputs,
> Alessio

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]