| Message ID | 20250324-dt-bindings-network-class-v5-0-f5c3fe00e8f0@ixit.cz |
|---|---|
| Headers | show |
| Series | dt-bindings: net: Add network-class.yaml schema | expand |
On Mon, Mar 24, 2025 at 12:41 PM David Heidelberg via B4 Relay <devnull+david.ixit.cz@kernel.org> wrote: > > From: Janne Grunau <j@jannau.net> > > The ethernet-controller schema specifies "mac-address" and > "local-mac-address" but other network devices such as wireless network > adapters use mac addresses as well. > The Devicetree Specification, Release v0.3 specifies in section 4.3.1 > a generic "Network Class Binding" with "address-bits", "mac-address", > "local-mac-address" and "max-frame-size". This schema specifies the > "address-bits" property and moves the remaining properties over from > the ethernet-controller.yaml schema. > > The "max-frame-size" property is used to describe the maximal payload > size despite its name. Keep the description from ethernet-controller > specifying this property as MTU. The contradictory description in the > Devicetree Specification is ignored. > > Signed-off-by: Janne Grunau <j@jannau.net> > Signed-off-by: David Heidelberg <david@ixit.cz> > --- > .../bindings/net/ethernet-controller.yaml | 25 +----------- > .../devicetree/bindings/net/network-class.yaml | 46 ++++++++++++++++++++++ > 2 files changed, 47 insertions(+), 24 deletions(-) Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
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