devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).