Re: [PATCH v2 3/5] dt-bindings: net: add mac-address-increment option

[Ivan Mikhaylov]

On Wed, 2023-05-17 at 10:36 +0200, Krzysztof Kozlowski wrote:
> On 16/05/2023 13:47, Ivan Mikhaylov wrote:
> hy this is property of the hardware. I
> > > > > understand
> > > > > that this is something you want Linux to do, but DT is not
> > > > > for
> > > > > that
> > > > > purpose. Do not encode system policies into DT and what above
> > > > > commit
> > > > > says is a policy.
> > > > > 
> > > > 
> > > > Krzysztof, okay then to which DT subsystem it should belong? To
> > > > ftgmac100 after conversion?
> > > 
> > > To my understanding, decision to add some numbers to MAC address
> > > does
> > > not look like DT property at all. Otherwise please help me to
> > > understand
> > > - why different boards with same device should have different
> > > offset/value?
> > > 
> > > Anyway, commit msg also lacks any justification for this.
> > > 
> > > Best regards,
> > > Krzysztof
> > > 
> > 
> > Krzysztof, essentially some PCIe network cards have like an
> > additional
> > *MII interface which connects directly to a BMC (separate SoC for
> > managing a motherboard) and by sending special ethernet type frames
> > over that connection (called NC-SI) the BMC can obtain MAC, get
> > link
> > parameters etc. So it's natural for a vendor to allocate two MACs
> > per
> > such a board with PCIe card intergrated, with one MAC "flashed
> > into"
> > the network card, under the assumption that the BMC should
> 
> Who makes the assumption that next MAC should differ by 1 or 2?

Krzysztof, in this above case BMC does, BMC should care about changing
it and doing it with current codebase without any options just by some
hardcoded numbers which is wrong.

> 
> > automatically use the next MAC. So it's the property of the
> > hardware as
> > the vendor designs it, not a matter of usage policy.
> > 
> > Also at the nvmem binding tree is "nvmem-cell-cells" which is
> > literally
> > the same as what was proposed but on different level.
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/nvmem?id=7e2805c203a6c8dc85c1cfda205161ed39ae82d5
> 
> How is this similar? This points the location of mac address on some
> NV
> storage. You add fixed value which should be added to the Ethernet.

It's not the points the location, this particular option provides this
increment for mac addresses to make use of them with multiple
interfaces. Just part of above commit:
"It's used as a base for calculating addresses for multiple interfaces.
It's done by adding proper values. Actual offsets are picked by
manufacturers and vary across devices."

It is same as we talked before about mac-address-increment in openwrt
project, if you want examples, you can look into their github. And same
as we trying to achieve here.

https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending-5.15/682-of_net-add-mac-address-increment-support.patch

"Lots of embedded devices use the mac-address of other interface
extracted from nvmem cells and increments it by one or two. Add two
bindings to integrate this and directly use the right mac-address for
the interface. Some example are some routers that use the gmac
mac-address stored in the art partition and increments it by one for
the
wifi. mac-address-increment-byte bindings is used to tell what byte of
the mac-address has to be increased (if not defined the last byte is
increased) and mac-address-increment tells how much the byte decided
early has to be increased."

Don't you see similarity with nvmem commit?

> 
> I might be missing the context but there is no DTS example nor user
> of
> this property, so how can I get such?
> 

I don't see it either in linux kernel DTS tree but it in DTS doc.

Also, just a little bit history about older propositions
https://lore.kernel.org/all/?q=mac-address-increment
https://lore.kernel.org/all/20200919214941.8038-5-ansuelsmth@xxxxxxxxx/


Thanks.