On 29/05/2023 22:59, Paul Fertser wrote: > Hello Krzysztof, > > Let me try to clarify a bit on the particular usecase and answer your > questions. > > Let's consider a server motherboard manufactured and sold by a single > company. This motherboard includes I210 (Ethernet Controlleer) chip > along with the other necessary parts right there, soldered to the PCB, > non-replaceable. This I210 is connected to the host CPU with a PCIe > lane and acts as a regular network adapter. In addition to that this > chip is connected using NC-SI (management channel) to the BMC SoC > (also permanently soldered to the board). > > There is a separate EEPROM connected directly to I210 which hosts its > firmware and many operational parameters, including the MAC > address. This EEPROM is not anyhow accessible by the BMC (the host can > read/write it using special protocol over PCIe). Intel expects the > board manufacturer to embed a MAC address from the manufacturer's > range in the EEPROM configuration. But in many cases it's desirable to > use a separate MAC address for the BMC (then I210 acts as if it has an > integrated switch), so the board manufacturer can, by its internal > policy, allocate two consecutive MAC addresses to each motherboard. > > The only way BMC can learn the MAC address used by I210 is by a > special vendor-specific NC-SI command, and it can provide just a > single address, the one used by the host. NC-SI is using Ethernet > frames with a special type, so to execute this command the network > driver needs to be (at least partially) functional. I do not really > imagine nvmem getting support to read it this way. > > On Wed, May 17, 2023 at 09:26:35PM +0200, Krzysztof Kozlowski wrote: >> I would like to remind this question. >> "why different boards with same device should have different offset/value?" > > In the usecase we're aiming for the DT is describing a specific board > from manufacturer that guarantees the offset to be correct, as none of > the parts are replaceable and the MAC address is flashed into the > I210 EEPROM during manufacturing. > >> Let me extend this question with one more: >> "Why for all your boards of one type, so using the same DTS, would you >> use one value of incrementing MAC address?" > > Here we assume that for all the boards supported by a particular DT > the board manufacturer guarantees the MAC address offset by internal > production policy, by allocating the addresses from the manufacturer's > pool. OK, embed such information in the commit or property description. > >> But you hard-code the number, just in BMC DTS. How does it differ from >> BMC hard-coding it differently? >> >> You encode policy - or software decisions - into Devicetree. > > But MAC address of an Ethernet equipment is an inherent part of the > hardware. It's just that we can't store it in an nvmem-addressable > cell in this case, unfortunately. > >> Why devices with same board cannot use different values? One board "1" >> and second "2" for MAC increments? I am sure that one customer could >> have it different. > > You assume that the customers might be allocating their own MAC > addresses for the network interface of a motherboard, that might be > true if the customer gets such a board from an ODM. But such a > customer not willing to follow the MAC address offsets policy is not > much different from a customer who e.g. modifies flash partitions or > storage format making the nvmem references invalid, and so requiring a > separate DT. > >> If you want to convince us, please illustrate it in a real world >> upstreamed DTS (or explain why it cannot). Otherwise I don't see >> justification as it is not a hardware property. > > Can you please tell how you would imagine a responsible vendor tackle > the usecase I outlined? I would imagine him to upstream the DTS. I asked yo illustrate it. There is still no DTS user for it so I have doubts it is used as intended. > Guess it's not by a startup script that would > be getting a MAC address from an interface, applying the offset, and > then change it on the same interface? > > Thank you for the review and discussion. > Best regards, Krzysztof
