From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: 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>
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org,
Paul Fertser <fercerpav@gmail.com>
Subject: Re: [PATCH v2 3/5] dt-bindings: net: add mac-address-increment option
Date: Wed, 17 May 2023 10:36:42 +0200 [thread overview]
Message-ID: <38ae4ceb-da21-d73e-9625-1918b4ab4e16@linaro.org> (raw)
In-Reply-To: <e6247cb39cc16a9328d9432e0595745b67c0aed5.camel@gmail.com>
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?
> 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.
I might be missing the context but there is no DTS example nor user of
this property, so how can I get such?
Best regards,
Krzysztof
next prev parent reply other threads:[~2023-05-17 8:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 14:34 [PATCH v2 0/5] Refactoring for GMA command Ivan Mikhaylov
2023-05-09 14:35 ` [PATCH v2 1/5] net/ncsi: make one oem_gma function for all mfr id Ivan Mikhaylov
2023-05-09 14:29 ` Simon Horman
2023-05-09 14:35 ` [PATCH v2 2/5] net/ncsi: change from ndo_set_mac_address to dev_set_mac_address Ivan Mikhaylov
2023-05-09 14:35 ` [PATCH v2 3/5] dt-bindings: net: add mac-address-increment option Ivan Mikhaylov
2023-05-10 14:48 ` Krzysztof Kozlowski
2023-05-10 23:31 ` Ivan Mikhaylov
2023-05-12 6:22 ` Krzysztof Kozlowski
2023-05-12 11:28 ` Ivan Mikhaylov
2023-05-12 9:24 ` Krzysztof Kozlowski
2023-05-16 11:47 ` Ivan Mikhaylov
2023-05-17 8:36 ` Krzysztof Kozlowski [this message]
2023-05-17 21:38 ` Ivan Mikhaylov
2023-05-17 19:26 ` Krzysztof Kozlowski
2023-05-29 20:59 ` Paul Fertser
2023-06-04 10:23 ` Krzysztof Kozlowski
2023-05-09 14:35 ` [PATCH v2 4/5] net/ncsi: add shift MAC address property Ivan Mikhaylov
2023-05-09 14:34 ` Simon Horman
2023-05-09 14:35 ` [PATCH v2 5/5] dt-bindings: net: ftgmac100: convert to yaml version from txt Ivan Mikhaylov
2023-05-10 14:50 ` Krzysztof Kozlowski
2023-05-11 0:15 ` Ivan Mikhaylov
2023-05-11 8:39 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38ae4ceb-da21-d73e-9625-1918b4ab4e16@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=fercerpav@gmail.com \
--cc=fr0st61te@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
--cc=sam@mendozajonas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).