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.
