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. > 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? 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. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@xxxxxxxxx
