Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a08a3317-7f3d-02d3-adba-f01e78940d16@linaro.org>
Date:   Sun, 4 Jun 2023 12:23:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Subject: Re: [PATCH v2 3/5] dt-bindings: net: add mac-address-increment option
Content-Language: en-US
To:     Paul Fertser <fercerpav@gmail.com>
Cc:     Ivan Mikhaylov <fr0st61te@gmail.com>,
        Samuel Mendoza-Jonas <sam@mendozajonas.com>,
        "David S . Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        netdev@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org
References: <20230509143504.30382-4-fr0st61te@gmail.com>
 <6b5be71e-141e-c02a-8cba-a528264b26c2@linaro.org>
 <fc3dae42f2dfdf046664d964bae560ff6bb32f69.camel@gmail.com>
 <8de01e81-43dc-71af-f56f-4fba957b0b0b@linaro.org>
 <be85bef7e144ebe08f422bf53bb81b59a130cb29.camel@gmail.com>
 <5b826dc7-2d02-d4ed-3b6a-63737abe732b@linaro.org>
 <e6247cb39cc16a9328d9432e0595745b67c0aed5.camel@gmail.com>
 <38ae4ceb-da21-d73e-9625-1918b4ab4e16@linaro.org>
 <5d7421b6a419a9645f97e6240b1dfbf47ffcab4e.camel@gmail.com>
 <408ee74c-e6ed-d654-af04-58bd7d1e087b@linaro.org>
 <ZHUSQkXwruFQbvSC@home.paul.comp>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <ZHUSQkXwruFQbvSC@home.paul.comp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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