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>, Taras Chornyi <tchornyi@marvell.com>, Rob Herring <robh@kernel.org> Subject: [PATCH net-next v2 1/7] Revert "dt-bindings: marvell,prestera: Add description for device-tree bindings" Date: Thu, 24 Nov 2022 12:15:50 +0100 [thread overview] Message-ID: <20221124111556.264647-2-miquel.raynal@bootlin.com> (raw) In-Reply-To: <20221124111556.264647-1-miquel.raynal@bootlin.com> This reverts commit 40acc05271abc2852c32622edbebd75698736b9b. marvell,prestera.txt is an old file describing the old Alleycat3 standalone switches. The commit mentioned above actually hacked these bindings to add support for a device tree property for a more modern version of the IP connected over PCI, using only the generic compatible in order to retrieve the device node from the prestera driver to read one static property. The problematic property discussed here is "base-mac-provider". The original intent was to point to a nvmem device which could produce the relevant nvmem-cell. This property has never been acked by DT maintainers and fails all the layering that has been brought with the nvmem bindings by pointing at a nvmem producer, bypassing the existing nvmem bindings, rather than a nvmem cell directly. Furthermore, the property cannot even be used upstream because it expected the ONIE tlv driver to produce a specific cell, driver which used nacked bindings and thus was never merged, replaced by a more integrated concept: the nvmem-layout. So let's forget about this temporary addition, safely avoiding the need for any backward compatibility handling. A new (yaml) binding file will be brought with the prestera bindings, and there we will actually include a description of the modern IP over PCI, including the right way to point to a nvmem cell. Cc: Vadym Kochan <vadym.kochan@plvision.eu> Cc: Taras Chornyi <tchornyi@marvell.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Rob Herring <robh@kernel.org> --- .../bindings/net/marvell,prestera.txt | 34 ------------------- 1 file changed, 34 deletions(-) diff --git a/Documentation/devicetree/bindings/net/marvell,prestera.txt b/Documentation/devicetree/bindings/net/marvell,prestera.txt index e28938ddfdf5..83370ebf5b89 100644 --- a/Documentation/devicetree/bindings/net/marvell,prestera.txt +++ b/Documentation/devicetree/bindings/net/marvell,prestera.txt @@ -45,37 +45,3 @@ dfx-server { ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>; reg = <MBUS_ID(0x08, 0x00) 0 0x100000>; }; - -Marvell Prestera SwitchDev bindings ------------------------------------ -Optional properties: -- compatible: must be "marvell,prestera" -- base-mac-provider: describes handle to node which provides base mac address, - might be a static base mac address or nvme cell provider. - -Example: - -eeprom_mac_addr: eeprom-mac-addr { - compatible = "eeprom,mac-addr-cell"; - status = "okay"; - - nvmem = <&eeprom_at24>; -}; - -prestera { - compatible = "marvell,prestera"; - status = "okay"; - - base-mac-provider = <&eeprom_mac_addr>; -}; - -The current implementation of Prestera Switchdev PCI interface driver requires -that BAR2 is assigned to 0xf6000000 as base address from the PCI IO range: - -&cp0_pcie0 { - ranges = <0x81000000 0x0 0xfb000000 0x0 0xfb000000 0x0 0xf0000 - 0x82000000 0x0 0xf6000000 0x0 0xf6000000 0x0 0x2000000 - 0x82000000 0x0 0xf9000000 0x0 0xf9000000 0x0 0x100000>; - phys = <&cp0_comphy0 0>; - status = "okay"; -}; -- 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>, Taras Chornyi <tchornyi@marvell.com>, Rob Herring <robh@kernel.org> Subject: [PATCH net-next v2 1/7] Revert "dt-bindings: marvell,prestera: Add description for device-tree bindings" Date: Thu, 24 Nov 2022 12:15:50 +0100 [thread overview] Message-ID: <20221124111556.264647-2-miquel.raynal@bootlin.com> (raw) In-Reply-To: <20221124111556.264647-1-miquel.raynal@bootlin.com> This reverts commit 40acc05271abc2852c32622edbebd75698736b9b. marvell,prestera.txt is an old file describing the old Alleycat3 standalone switches. The commit mentioned above actually hacked these bindings to add support for a device tree property for a more modern version of the IP connected over PCI, using only the generic compatible in order to retrieve the device node from the prestera driver to read one static property. The problematic property discussed here is "base-mac-provider". The original intent was to point to a nvmem device which could produce the relevant nvmem-cell. This property has never been acked by DT maintainers and fails all the layering that has been brought with the nvmem bindings by pointing at a nvmem producer, bypassing the existing nvmem bindings, rather than a nvmem cell directly. Furthermore, the property cannot even be used upstream because it expected the ONIE tlv driver to produce a specific cell, driver which used nacked bindings and thus was never merged, replaced by a more integrated concept: the nvmem-layout. So let's forget about this temporary addition, safely avoiding the need for any backward compatibility handling. A new (yaml) binding file will be brought with the prestera bindings, and there we will actually include a description of the modern IP over PCI, including the right way to point to a nvmem cell. Cc: Vadym Kochan <vadym.kochan@plvision.eu> Cc: Taras Chornyi <tchornyi@marvell.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Rob Herring <robh@kernel.org> --- .../bindings/net/marvell,prestera.txt | 34 ------------------- 1 file changed, 34 deletions(-) diff --git a/Documentation/devicetree/bindings/net/marvell,prestera.txt b/Documentation/devicetree/bindings/net/marvell,prestera.txt index e28938ddfdf5..83370ebf5b89 100644 --- a/Documentation/devicetree/bindings/net/marvell,prestera.txt +++ b/Documentation/devicetree/bindings/net/marvell,prestera.txt @@ -45,37 +45,3 @@ dfx-server { ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>; reg = <MBUS_ID(0x08, 0x00) 0 0x100000>; }; - -Marvell Prestera SwitchDev bindings ------------------------------------ -Optional properties: -- compatible: must be "marvell,prestera" -- base-mac-provider: describes handle to node which provides base mac address, - might be a static base mac address or nvme cell provider. - -Example: - -eeprom_mac_addr: eeprom-mac-addr { - compatible = "eeprom,mac-addr-cell"; - status = "okay"; - - nvmem = <&eeprom_at24>; -}; - -prestera { - compatible = "marvell,prestera"; - status = "okay"; - - base-mac-provider = <&eeprom_mac_addr>; -}; - -The current implementation of Prestera Switchdev PCI interface driver requires -that BAR2 is assigned to 0xf6000000 as base address from the PCI IO range: - -&cp0_pcie0 { - ranges = <0x81000000 0x0 0xfb000000 0x0 0xfb000000 0x0 0xf0000 - 0x82000000 0x0 0xf6000000 0x0 0xf6000000 0x0 0x2000000 - 0x82000000 0x0 0xf9000000 0x0 0xf9000000 0x0 0x100000>; - phys = <&cp0_comphy0 0>; - status = "okay"; -}; -- 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 ` Miquel Raynal [this message] 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-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 ` [PATCH net-next v2 7/7] net: mvpp2: Consider NVMEM cells as possible MAC address source Miquel Raynal 2022-11-24 11:15 ` 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-2-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=robh@kernel.org \ --cc=tchornyi@marvell.com \ --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.