The Devicetree Specification, Release v0.3 specifies in section 4.3.1
a "Network Class Binding". This covers MAC address and maximal frame
size properties. "local-mac-address" and "mac-address" with a fixed
"address-size" of 48 bits are already in the ethernet-controller.yaml
schema so move those over.

Keep "address-size" fixed to 48 bits as it's unclear if network protocols
using 64-bit mac addresses like ZigBee, 6LoWPAN and others are relevant for
this binding. This allows mac address array size validation for ethernet
and wireless lan devices.

"max-frame-size" in the Devicetree Specification is written to cover the
whole layer 2 ethernet frame but actual use for this property is the
payload size. Keep the description from ethernet-controller.yaml which
specifies the property as MTU.

Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Changes in v5:
- Incorrect DCO chain, missing SoB. (Krzysztof)
- Improved address-bits description. (Krzysztof)
- Link to v4: https://lore.kernel.org/r/20250319-dt-bindings-network-class-v4-0-2329336802b4@ixit.cz

Changes in v4:
- Changed the mailing list address (Rob)
- Copyied the whole description for the max-frame-size, including the
  MTU x max-frame-size contradiction. (Rob)
- Link to v3: https://lore.kernel.org/r/20250318-dt-bindings-network-class-v3-0-4d8d04ddfb61@ixit.cz

Changes in v3:
- Incorporated wireless-controller.yaml suggestion (Andrew)
- Link to v2: https://lore.kernel.org/r/20230203-dt-bindings-network-class-v2-0-499686795073@jannau.net

Changes in v2:
- Added "max-frame-size" with the description from ethernet-controller.yaml
- Restrict "address-size" to 48-bits
- Fix the mac-address array size to 6 bytes
- Drop duplicate default value from "max-frame-size" description
- Link to v1: https://lore.kernel.org/r/20230203-dt-bindings-network-class-v1-0-452e0375200d@jannau.net

---
David Heidelberg (2):
      dt-bindings: net: Add generic wireless controller
      dt-bindings: wireless: qcom,wcnss: Use wireless-controller.yaml

Janne Grunau (3):
      dt-bindings: net: Add network-class schema for mac-address properties
      dt-bindings: wireless: bcm4329-fmac: Use wireless-controller.yaml schema
      dt-bindings: wireless: silabs,wfx: Use wireless-controller.yaml

 .../bindings/net/ethernet-controller.yaml          | 25 +-----------
 .../devicetree/bindings/net/network-class.yaml     | 46 ++++++++++++++++++++++
 .../bindings/net/wireless/brcm,bcm4329-fmac.yaml   |  2 +-
 .../bindings/net/wireless/silabs,wfx.yaml          |  5 +--
 .../bindings/net/wireless/wireless-controller.yaml | 23 +++++++++++
 .../devicetree/bindings/soc/qcom/qcom,wcnss.yaml   |  5 ++-
 6 files changed, 76 insertions(+), 30 deletions(-)
---
base-commit: 882a18c2c14fc79adb30fe57a9758283aa20efaa
change-id: 20230203-dt-bindings-network-class-8367edd679d2

Best regards,
-- 
David Heidelberg <david@ixit.cz>

On Mon, 2025-03-24 at 18:41 +0100, David Heidelberg via B4 Relay wrote:
> The Devicetree Specification, Release v0.3 specifies in section 4.3.1
> a "Network Class Binding". This covers MAC address and maximal frame
> size properties. "local-mac-address" and "mac-address" with a fixed
> "address-size" of 48 bits are already in the ethernet-controller.yaml
> schema so move those over.
> 
> Keep "address-size" fixed to 48 bits as it's unclear if network protocols
> using 64-bit mac addresses like ZigBee, 6LoWPAN and others are relevant for
> this binding. This allows mac address array size validation for ethernet
> and wireless lan devices.
> 
> "max-frame-size" in the Devicetree Specification is written to cover the
> whole layer 2 ethernet frame but actual use for this property is the
> payload size. Keep the description from ethernet-controller.yaml which
> specifies the property as MTU.
> 

I have no idea what tree this should go through, and you CC'ed enough
people that I can't figure it out either ... I'll assume not wifi but DT
for now?

johannes

On Tue, Mar 25, 2025 at 5:33 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Mon, 2025-03-24 at 18:41 +0100, David Heidelberg via B4 Relay wrote:
> > The Devicetree Specification, Release v0.3 specifies in section 4.3.1
> > a "Network Class Binding". This covers MAC address and maximal frame
> > size properties. "local-mac-address" and "mac-address" with a fixed
> > "address-size" of 48 bits are already in the ethernet-controller.yaml
> > schema so move those over.
> >
> > Keep "address-size" fixed to 48 bits as it's unclear if network protocols
> > using 64-bit mac addresses like ZigBee, 6LoWPAN and others are relevant for
> > this binding. This allows mac address array size validation for ethernet
> > and wireless lan devices.
> >
> > "max-frame-size" in the Devicetree Specification is written to cover the
> > whole layer 2 ethernet frame but actual use for this property is the
> > payload size. Keep the description from ethernet-controller.yaml which
> > specifies the property as MTU.
> >
>
> I have no idea what tree this should go through, and you CC'ed enough
> people that I can't figure it out either ... I'll assume not wifi but DT
> for now?

Can you take it via wifi as the main target here is wifi bindings.

Rob

On Tue, 2025-03-25 at 08:02 -0500, Rob Herring wrote:
> > 
> > I have no idea what tree this should go through, and you CC'ed enough
> > people that I can't figure it out either ... I'll assume not wifi but DT
> > for now?
> 
> Can you take it via wifi as the main target here is wifi bindings.

I can do that, but I suppose it's 6.16 material at this point.

johannes

> I can do that, but I suppose it's 6.16 material at this point.

Hi Johannes. 

I assume you meant 6.15? 
This patchset should mainly clarify where these properties can be used and address incorrect warnings regarding device-tree verification. 

David

> johannes

On Wed, 2025-03-26 at 23:08 +0000, David Heidelberg wrote:
> > I can do that, but I suppose it's 6.16 material at this point.
> 
> Hi Johannes. 
> 
> I assume you meant 6.15? 

No. 6.15 merge window just opened.

> This patchset should mainly clarify where these properties can be used and address incorrect warnings regarding device-tree verification. 

I'm not really convinced that makes it a bugfix for the rc series
though?

johannes

Hi Johannes,

from the functionality standpoint this bindings do not change anything.

From validation point, if the `make dtbs_check` will pass as expected, it should yield only better results for integrators and developers. 

Thou if you want to postpone it for 6.16, I'll understand.

Thank you
David

On Wed, 2025-03-26 at 23:08 +0000, David Heidelberg wrote:
> > I can do that, but I suppose it's 6.16 material at this point.
> 
> Hi Johannes. 
> 
> I assume you meant 6.15? 

No. 6.15 merge window just opened.

> This patchset should mainly clarify where these properties can be used and address incorrect warnings regarding device-tree verification. 

I'm not really convinced that makes it a bugfix for the rc series
though?

johannes