Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2602894rwd; Wed, 17 May 2023 11:49:57 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7trM3u3SGH/Hl+9z5YauaCs2Z+aI3ZZyZ712Ygj2lyfXyZQTEmr4DfN0Ujm7oXtp58dDna X-Received: by 2002:a05:6a21:9997:b0:104:7a4c:6c97 with SMTP id ve23-20020a056a21999700b001047a4c6c97mr25384179pzb.13.1684349397578; Wed, 17 May 2023 11:49:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684349397; cv=none; d=google.com; s=arc-20160816; b=rjqAsHowDxoy+P633HY3DQsCfDG8MP7K6ekSV2knpXMTOS30G+O45vVm9XmB5IDS/y nqHwnQh063p/P5Mt11OGLmoAmRH+bzLdqJzYLwxPaTXT9GBT2jRqn+kbQS8abRFNMsau FZpClSuiPTs8ftEoI4gTDmzlDCyNorYvwaKKf4zagxZ9S4MPEOWmyrcA/Z/zYb+WNdzW ZQiklOMSAZ0j6X3YA45Mb4z9h8Jn6rNnKmcthn4b5TOCIENc5pONA/6p0JQfcWckdHnX 4dDhDonsw3veOX6yHjU4S5ZXovRH8gdsj7ht0KipabcqAJ/4nzbJkHkpJmbzRP239k+f DZvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=FuipT8N9AIZhPuetrFCf6nkInGjCzh1d3K2+VTwrcZI=; b=pkZH9RD2phF4xKvqOe3nfAYxT4T0gXF/M1eAILdkLTeaQnf2GBVMJ8/vUBV/porfVa SgTzPmW0G6q2j8br6sObqYcuNkTqKWQz+eBZSr0/ti891iAutRiU/FIu3/t8dYyYmxW5 0ujfOJkaj19kRz4/uDmr64JqsXTzFblT7yrqvLgmmZYE7S1+c8nHdfDW5uc7ueguEAxr UuR43/DhN4LaDZyUX0FBsmuDIVApjpLywyCaSoQXj2TMNqks8SvNCPnHqCgMok88cXYF Hl7lyZ7fl4VvJ0JIc5UejdrTzt2hvymyWASnzSK/fjzPhESTgae+U7Jy8ajjWKvswTm5 xbBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=gC+vtXye; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k12-20020aa7998c000000b0063b843131b1si21745679pfh.324.2023.05.17.11.49.42; Wed, 17 May 2023 11:49:57 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=gC+vtXye; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229574AbjEQSiX (ORCPT + 99 others); Wed, 17 May 2023 14:38:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229533AbjEQSiH (ORCPT ); Wed, 17 May 2023 14:38:07 -0400 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CDFB524E; Wed, 17 May 2023 11:38:05 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2ac89e6a5a1so11830611fa.0; Wed, 17 May 2023 11:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684348684; x=1686940684; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=FuipT8N9AIZhPuetrFCf6nkInGjCzh1d3K2+VTwrcZI=; b=gC+vtXyeAJ6dSdPO9ckA5gFbeFI6fhGGVE+IeeHLh/LIpDM3DveIKb2PnQypN3RyCI GfrhzjmpK1KfNaTuYgFK0AiYvAeNAQM2tB05rFKDaNFtuS6HyjITY7bNHQkaczRUo10E oSYee6FmENAWY0/rtA93xOVPTLBwIqbm+salh6EXh0oIQqRIlKIFNOrt/3F8+wRTF+9N lyo7L7pIuyoLah1EDY3ZNBdRbOI2jnalHE6bCfmTMzXspCtMt9OkIXr3jERyGocoVZ6Z NPj/L+zzFiprF7/Mq7m2YpzbTh+pRGQ1YAIGKDp1OnV+822undYgBeyjgdWWz2xL2L3r nAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684348684; x=1686940684; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=FuipT8N9AIZhPuetrFCf6nkInGjCzh1d3K2+VTwrcZI=; b=mFa/sx9XQn8Yu2saLDBQ+o12+bfvlJ9fzUOkUBjn5tX9dX6vssqjdgmjkL6zHft1ZN 2ujyskQo16xFK+RBtX/EJ/Vi+xAgz5zTqdSeb0k653wmuRtE0S+Ua/7SrEQ5sH7pzBhY l9I7UiQfJ+pXnFafQXzKCJrnt6ekKvH/Co9bUz/zbCndEZkJGcgOiNGeYOL4NnOWCDlP PUSfLw5lkseztgwkFSKqkmmvUL6rBpZLlWe73dyY14K0p8bASqdaUDjlcn+fBeyAa60h vPGQ/Kz57qs0xJiY0C3FtnfdoM8RYvkThn2gDA3jRyIlCXnZUkz/m3Eb4Z76fHPXMj0T oNlQ== X-Gm-Message-State: AC+VfDz6AjiSMzdmiJfFGtqixz4j6fp5zHYzjDzpTg7ruDf6zyqE+hRy bbGap5mUDYgt+WVzEFOL4Ag= X-Received: by 2002:a2e:800a:0:b0:2a7:96bd:9eb3 with SMTP id j10-20020a2e800a000000b002a796bd9eb3mr10581246ljg.3.1684348683477; Wed, 17 May 2023 11:38:03 -0700 (PDT) Received: from [100.119.125.242] (95-31-187-187.broadband.corbina.ru. [95.31.187.187]) by smtp.gmail.com with ESMTPSA id t20-20020ac25494000000b004db0d26adb4sm3451405lfk.182.2023.05.17.11.38.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 May 2023 11:38:02 -0700 (PDT) Message-ID: <5d7421b6a419a9645f97e6240b1dfbf47ffcab4e.camel@gmail.com> Subject: Re: [PATCH v2 3/5] dt-bindings: net: add mac-address-increment option From: Ivan Mikhaylov To: Krzysztof Kozlowski , Samuel Mendoza-Jonas , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org, Paul Fertser Date: Wed, 17 May 2023 21:38:02 +0000 In-Reply-To: <38ae4ceb-da21-d73e-9625-1918b4ab4e16@linaro.org> References: <20230509143504.30382-1-fr0st61te@gmail.com> <20230509143504.30382-4-fr0st61te@gmail.com> <6b5be71e-141e-c02a-8cba-a528264b26c2@linaro.org> <8de01e81-43dc-71af-f56f-4fba957b0b0b@linaro.org> <5b826dc7-2d02-d4ed-3b6a-63737abe732b@linaro.org> <38ae4ceb-da21-d73e-9625-1918b4ab4e16@linaro.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.1 MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2023-05-17 at 10:36 +0200, Krzysztof Kozlowski wrote: > 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. > > > > >=20 > > > >=20 > > > > Krzysztof, okay then to which DT subsystem it should belong? To > > > > ftgmac100 after conversion? > > >=20 > > > 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? > > >=20 > > > Anyway, commit msg also lacks any justification for this. > > >=20 > > > Best regards, > > > Krzysztof > > >=20 > >=20 > > 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 >=20 > Who makes the assumption that next MAC should differ by 1 or 2? Krzysztof, in this above case BMC does, BMC should care about changing it and doing it with current codebase without any options just by some hardcoded numbers which is wrong. >=20 > > automatically use the next MAC. So it's the property of the > > hardware as > > the vendor designs it, not a matter of usage policy. > >=20 > > Also at the nvmem binding tree is "nvmem-cell-cells" which is > > literally > > the same as what was proposed but on different level. > >=20 > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm= it/Documentation/devicetree/bindings/nvmem?id=3D7e2805c203a6c8dc85c1cfda205= 161ed39ae82d5 >=20 > 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. It's not the points the location, this particular option provides this increment for mac addresses to make use of them with multiple interfaces. Just part of above commit: "It's used as a base for calculating addresses for multiple interfaces. It's done by adding proper values. Actual offsets are picked by manufacturers and vary across devices." It is same as we talked before about mac-address-increment in openwrt project, if you want examples, you can look into their github. And same as we trying to achieve here. https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending= -5.15/682-of_net-add-mac-address-increment-support.patch "Lots of embedded devices use the mac-address of other interface extracted from nvmem cells and increments it by one or two. Add two bindings to integrate this and directly use the right mac-address for the interface. Some example are some routers that use the gmac mac-address stored in the art partition and increments it by one for the wifi. mac-address-increment-byte bindings is used to tell what byte of the mac-address has to be increased (if not defined the last byte is increased) and mac-address-increment tells how much the byte decided early has to be increased." Don't you see similarity with nvmem commit? >=20 > I might be missing the context but there is no DTS example nor user > of > this property, so how can I get such? >=20 I don't see it either in linux kernel DTS tree but it in DTS doc. Also, just a little bit history about older propositions https://lore.kernel.org/all/?q=3Dmac-address-increment https://lore.kernel.org/all/20200919214941.8038-5-ansuelsmth@gmail.com/ Thanks.