From: Miquel Raynal <miquel.raynal@bootlin.com> To: "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Eric Dumazet <edumazet@google.com>, netdev@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzk+dt@kernel.org>, devicetree@vger.kernel.org, Robert Marko <robert.marko@sartura.hr>, Luka Perkov <luka.perkov@sartura.hr>, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, Michael Walle <michael@walle.cc>, Marcin Wojtas <mw@semihalf.com>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, Vadym Kochan <vadym.kochan@plvision.eu>, Miquel Raynal <miquel.raynal@bootlin.com> Subject: [PATCH net-next v2 7/7] net: mvpp2: Consider NVMEM cells as possible MAC address source Date: Thu, 24 Nov 2022 12:15:56 +0100 [thread overview] Message-ID: <20221124111556.264647-8-miquel.raynal@bootlin.com> (raw) In-Reply-To: <20221124111556.264647-1-miquel.raynal@bootlin.com> The ONIE standard describes the organization of tlv (type-length-value) arrays commonly stored within NVMEM devices on common networking hardware. Several drivers already make use of NVMEM cells for purposes like retrieving a default MAC address provided by the manufacturer. What made ONIE tables unusable so far was the fact that the information where "dynamically" located within the table depending on the manufacturer wishes, while Linux NVMEM support only allowed statically defined NVMEM cells. Fortunately, this limitation was eventually tackled with the introduction of discoverable cells through the use of NVMEM layouts, making it possible to extract and consistently use the content of tables like ONIE's tlv arrays. Parsing this table at runtime in order to get various information is now possible. So, because many Marvell networking switches already follow this standard, let's consider using NVMEM cells as a new valid source of information when looking for a base MAC address, which is one of the primary uses of these new fields. Indeed, manufacturers following the ONIE standard are encouraged to provide a default MAC address there, so let's eventually use it if no other MAC address has been found using the existing methods. Link: https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> --- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c index eb0fb8128096..12f0b5ad8cee 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -6104,6 +6104,13 @@ static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 *priv, } } + /* Only valid on OF enabled platforms */ + if (!of_get_mac_address_nvmem(to_of_node(fwnode), fw_mac_addr)) { + *mac_from = "nvmem cell"; + eth_hw_addr_set(dev, fw_mac_addr); + return; + } + *mac_from = "random"; eth_hw_addr_random(dev); } -- 2.34.1
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com> To: "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Eric Dumazet <edumazet@google.com>, netdev@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzk+dt@kernel.org>, devicetree@vger.kernel.org, Robert Marko <robert.marko@sartura.hr>, Luka Perkov <luka.perkov@sartura.hr>, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, Michael Walle <michael@walle.cc>, Marcin Wojtas <mw@semihalf.com>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, Vadym Kochan <vadym.kochan@plvision.eu>, Miquel Raynal <miquel.raynal@bootlin.com> Subject: [PATCH net-next v2 7/7] net: mvpp2: Consider NVMEM cells as possible MAC address source Date: Thu, 24 Nov 2022 12:15:56 +0100 [thread overview] Message-ID: <20221124111556.264647-8-miquel.raynal@bootlin.com> (raw) In-Reply-To: <20221124111556.264647-1-miquel.raynal@bootlin.com> The ONIE standard describes the organization of tlv (type-length-value) arrays commonly stored within NVMEM devices on common networking hardware. Several drivers already make use of NVMEM cells for purposes like retrieving a default MAC address provided by the manufacturer. What made ONIE tables unusable so far was the fact that the information where "dynamically" located within the table depending on the manufacturer wishes, while Linux NVMEM support only allowed statically defined NVMEM cells. Fortunately, this limitation was eventually tackled with the introduction of discoverable cells through the use of NVMEM layouts, making it possible to extract and consistently use the content of tables like ONIE's tlv arrays. Parsing this table at runtime in order to get various information is now possible. So, because many Marvell networking switches already follow this standard, let's consider using NVMEM cells as a new valid source of information when looking for a base MAC address, which is one of the primary uses of these new fields. Indeed, manufacturers following the ONIE standard are encouraged to provide a default MAC address there, so let's eventually use it if no other MAC address has been found using the existing methods. Link: https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> --- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c index eb0fb8128096..12f0b5ad8cee 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -6104,6 +6104,13 @@ static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 *priv, } } + /* Only valid on OF enabled platforms */ + if (!of_get_mac_address_nvmem(to_of_node(fwnode), fw_mac_addr)) { + *mac_from = "nvmem cell"; + eth_hw_addr_set(dev, fw_mac_addr); + return; + } + *mac_from = "random"; eth_hw_addr_random(dev); } -- 2.34.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-11-24 11:16 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-24 11:15 [PATCH net-next v2 0/7] Marvell nvmem mac addresses support Miquel Raynal 2022-11-24 11:15 ` Miquel Raynal 2022-11-24 11:15 ` [PATCH net-next v2 1/7] Revert "dt-bindings: marvell,prestera: Add description for device-tree bindings" Miquel Raynal 2022-11-24 11:15 ` Miquel Raynal 2022-11-27 21:15 ` Krzysztof Kozlowski 2022-11-27 21:15 ` Krzysztof Kozlowski 2022-11-24 11:15 ` [PATCH net-next v2 2/7] dt-bindings: net: marvell,dfx-server: Convert to yaml Miquel Raynal 2022-11-24 11:15 ` Miquel Raynal 2022-11-27 21:19 ` Krzysztof Kozlowski 2022-11-27 21:19 ` Krzysztof Kozlowski 2022-11-24 11:15 ` [PATCH net-next v2 3/7] dt-bindings: net: marvell,prestera: " Miquel Raynal 2022-11-24 11:15 ` Miquel Raynal 2022-11-24 11:15 ` [PATCH net-next v2 4/7] dt-bindings: net: marvell,prestera: Describe PCI devices of the prestera family Miquel Raynal 2022-11-24 11:15 ` Miquel Raynal 2022-11-24 11:15 ` [PATCH net-next v2 5/7] of: net: export of_get_mac_address_nvmem() Miquel Raynal 2022-11-24 11:15 ` Miquel Raynal 2022-11-24 11:15 ` [PATCH net-next v2 6/7] net: marvell: prestera: Avoid unnecessary DT lookups Miquel Raynal 2022-11-24 11:15 ` Miquel Raynal 2022-11-24 11:15 ` Miquel Raynal [this message] 2022-11-24 11:15 ` [PATCH net-next v2 7/7] net: mvpp2: Consider NVMEM cells as possible MAC address source Miquel Raynal 2022-11-29 10:10 ` [PATCH net-next v2 0/7] Marvell nvmem mac addresses support patchwork-bot+netdevbpf 2022-11-29 10:10 ` patchwork-bot+netdevbpf
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=20221124111556.264647-8-miquel.raynal@bootlin.com \ --to=miquel.raynal@bootlin.com \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=edumazet@google.com \ --cc=krzk+dt@kernel.org \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luka.perkov@sartura.hr \ --cc=michael@walle.cc \ --cc=mw@semihalf.com \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=robert.marko@sartura.hr \ --cc=robh+dt@kernel.org \ --cc=thomas.petazzoni@bootlin.com \ --cc=vadym.kochan@plvision.eu \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.