[net-next,v2,1/7] Revert "dt-bindings: marvell,prestera: Add description for device-tree bindings"
Commit Message
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(-)
Comments
On 24/11/2022 12:15, Miquel Raynal wrote:
> 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
It's funnier - it was never sent to DT maintainers nor to the
devicetree@ list. :(
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
@@ -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";
-};