Re: [PATCH] dt-bindings: net: wireless: brcm,bcm4329-fmac: add nvmem-consumer reference

Rob Herring <[email protected]>
Newsgroups org.kernel.vger.linux-wireless,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Sun, Aug 02, 2026 at 10:39:04AM +0200, Arend van Spriel wrote:
> On Mon, 27 Jul 2026 15:53:11 -0700, Rosen Penev <[email protected]> wrote:
> > The brcm,bcm4329-fmac binding has unevaluatedProperties set to false
> > but does not allow nvmem-cells or nvmem-cell-names, which are used by
> > DTS files (e.g. bcm4709-linksys-ea9200.dts) to supply MAC addresses.
> >
> > The driver already supports nvmem-based MAC address retrieval via
> > of_get_mac_address(), so add the nvmem-consumer schema reference to
> > document and allow these properties.
> > ---
> >  .../devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
> 
> The problem is real but I think the fix belongs in network-class.yaml rather
> than the brcmfmac binding specifically. ethernet-controller.yaml already
> defines nvmem-cells and nvmem-cell-names for wired NICs, but the wireless
> binding hierarchy (wireless-controller.yaml -> network-class.yaml) is missing
> them. Fixing it in network-class.yaml would cover all network nodes at once
> instead of requiring each wireless driver to add the same reference
> individually.

It is wrong because nvmem-consumer.yaml does not define how many entries 
and what they are. IOW, the valid names in nvmem-cell-names must be 
defined.

However, expecting all network class devices to use the same 
nvmem-cells/nvmem-cell-names will probably not work long term. Some 
device may use it, but not use "mac-address" entry. Unfortunately, 
there's not a way to override a default in json-schema. So we'll 
probably have to just define this in every user rather than centrally. 

So this should just add the definitions to the brcm,bcm4329-fmac 
binding:

nvmem-cells:
  maxItems: 1

nvmem-cell-names:
  const: mac-address

Rob
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.