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;
Date:   Mon, 29 May 2023 23:59:46 +0300
From:   Paul Fertser <fercerpav@gmail.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
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
Subject: Re: [PATCH v2 3/5] dt-bindings: net: add mac-address-increment option
Message-ID: <ZHUSQkXwruFQbvSC@home.paul.comp>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <408ee74c-e6ed-d654-af04-58bd7d1e087b@linaro.org>
Precedence: bulk

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@gmail.com