From: Frank Wunderlich <[email protected]>
This Series add Support for the mt7531 switch on Bananapi R2 Pro board.
This board uses port5 of the switch to conect to the gmac0 of the
rk3568 SoC.
Currently CPU-Port is hardcoded in the mt7530 driver to port 6.
Compared to v1 the reset-Patch was dropped as it was not needed and
CPU-Port-changes are completely rewriten based on suggestions/code from
Vladimir Oltean (many thanks to this).
In DTS Patch i only dropped the status-property that was not
needed/ignored by driver.
Due to the Changes i also made a regression Test on mt7623 bpi-r2 using
mt7530 with cpu-port 6. Tests were done directly (ipv4 config on dsa user
port) and with vlan-aware bridge including vlan that was tagged outgoing
on dsa user port.
Frank Wunderlich (4):
net: dsa: mt7530: rework mt7530_hw_vlan_{add,del}
net: dsa: mt7530: rework mt753[01]_setup
net: dsa: mt7530: get cpu-port via dp->cpu_dp instead of constant
arm64: dts: rockchip: Add mt7531 dsa node to BPI-R2-Pro board
.../boot/dts/rockchip/rk3568-bpi-r2-pro.dts | 48 +++++++++++
drivers/net/dsa/mt7530.c | 81 ++++++++++++-------
drivers/net/dsa/mt7530.h | 1 -
3 files changed, 100 insertions(+), 30 deletions(-)
--
2.25.1
From: Frank Wunderlich <[email protected]>
Add Device Tree node for mt7531 switch connected to gmac0.
Signed-off-by: Frank Wunderlich <[email protected]>
---
v2:
- drop status=disabled
---
.../boot/dts/rockchip/rk3568-bpi-r2-pro.dts | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
index ed2f2bd9a016..f0ffbe818170 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
@@ -437,6 +437,54 @@ &i2c5 {
status = "disabled";
};
+&mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "mediatek,mt7531";
+ reg = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ label = "lan0";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan1";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan2";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "lan3";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
+};
+
&mdio1 {
rgmii_phy1: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.25.1
From: Frank Wunderlich <[email protected]>
Replace last occurences of hardcoded cpu-port by cpu_dp member of
dsa_port struct.
Now the constant can be dropped.
Suggested-by: Vladimir Oltean <[email protected]>
Signed-off-by: Frank Wunderlich <[email protected]>
---
drivers/net/dsa/mt7530.c | 27 ++++++++++++++++++++-------
drivers/net/dsa/mt7530.h | 1 -
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 144c29f8fefc..8bf27937e577 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1033,6 +1033,7 @@ static int
mt7530_port_enable(struct dsa_switch *ds, int port,
struct phy_device *phy)
{
+ struct dsa_port *dp = dsa_to_port(ds, port);
struct mt7530_priv *priv = ds->priv;
mutex_lock(&priv->reg_mutex);
@@ -1041,7 +1042,11 @@ mt7530_port_enable(struct dsa_switch *ds, int port,
* restore the port matrix if the port is the member of a certain
* bridge.
*/
- priv->ports[port].pm |= PCR_MATRIX(BIT(MT7530_CPU_PORT));
+ if (dsa_port_is_user(dp)) {
+ struct dsa_port *cpu_dp = dp->cpu_dp;
+
+ priv->ports[port].pm |= PCR_MATRIX(BIT(cpu_dp->index));
+ }
priv->ports[port].enable = true;
mt7530_rmw(priv, MT7530_PCR_P(port), PCR_MATRIX_MASK,
priv->ports[port].pm);
@@ -1190,7 +1195,8 @@ mt7530_port_bridge_join(struct dsa_switch *ds, int port,
struct netlink_ext_ack *extack)
{
struct dsa_port *dp = dsa_to_port(ds, port), *other_dp;
- u32 port_bitmap = BIT(MT7530_CPU_PORT);
+ struct dsa_port *cpu_dp = dp->cpu_dp;
+ u32 port_bitmap = BIT(cpu_dp->index);
struct mt7530_priv *priv = ds->priv;
mutex_lock(&priv->reg_mutex);
@@ -1267,9 +1273,12 @@ mt7530_port_set_vlan_unaware(struct dsa_switch *ds, int port)
* the CPU port get out of VLAN filtering mode.
*/
if (all_user_ports_removed) {
- mt7530_write(priv, MT7530_PCR_P(MT7530_CPU_PORT),
+ struct dsa_port *dp = dsa_to_port(ds, port);
+ struct dsa_port *cpu_dp = dp->cpu_dp;
+
+ mt7530_write(priv, MT7530_PCR_P(cpu_dp->index),
PCR_MATRIX(dsa_user_ports(priv->ds)));
- mt7530_write(priv, MT7530_PVC_P(MT7530_CPU_PORT), PORT_SPEC_TAG
+ mt7530_write(priv, MT7530_PVC_P(cpu_dp->index), PORT_SPEC_TAG
| PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
}
}
@@ -1307,6 +1316,7 @@ mt7530_port_bridge_leave(struct dsa_switch *ds, int port,
struct dsa_bridge bridge)
{
struct dsa_port *dp = dsa_to_port(ds, port), *other_dp;
+ struct dsa_port *cpu_dp = dp->cpu_dp;
struct mt7530_priv *priv = ds->priv;
mutex_lock(&priv->reg_mutex);
@@ -1335,8 +1345,8 @@ mt7530_port_bridge_leave(struct dsa_switch *ds, int port,
*/
if (priv->ports[port].enable)
mt7530_rmw(priv, MT7530_PCR_P(port), PCR_MATRIX_MASK,
- PCR_MATRIX(BIT(MT7530_CPU_PORT)));
- priv->ports[port].pm = PCR_MATRIX(BIT(MT7530_CPU_PORT));
+ PCR_MATRIX(BIT(cpu_dp->index)));
+ priv->ports[port].pm = PCR_MATRIX(BIT(cpu_dp->index));
/* When a port is removed from the bridge, the port would be set up
* back to the default as is at initial boot which is a VLAN-unaware
@@ -1503,6 +1513,9 @@ static int
mt7530_port_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering,
struct netlink_ext_ack *extack)
{
+ struct dsa_port *dp = dsa_to_port(ds, port);
+ struct dsa_port *cpu_dp = dp->cpu_dp;
+
if (vlan_filtering) {
/* The port is being kept as VLAN-unaware port when bridge is
* set up with vlan_filtering not being set, Otherwise, the
@@ -1510,7 +1523,7 @@ mt7530_port_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering,
* for becoming a VLAN-aware port.
*/
mt7530_port_set_vlan_aware(ds, port);
- mt7530_port_set_vlan_aware(ds, MT7530_CPU_PORT);
+ mt7530_port_set_vlan_aware(ds, cpu_dp->index);
} else {
mt7530_port_set_vlan_unaware(ds, port);
}
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 91508e2feef9..5895bcfc0f7d 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -8,7 +8,6 @@
#define MT7530_NUM_PORTS 7
#define MT7530_NUM_PHYS 5
-#define MT7530_CPU_PORT 6
#define MT7530_NUM_FDB_RECORDS 2048
#define MT7530_ALL_MEMBERS 0xff
--
2.25.1
From: Frank Wunderlich <[email protected]>
Enumerate available cpu-ports instead of using hardcoded constant.
Suggested-by: Vladimir Oltean <[email protected]>
Signed-off-by: Frank Wunderlich <[email protected]>
---
drivers/net/dsa/mt7530.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 46dee0714382..144c29f8fefc 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2087,11 +2087,12 @@ static int
mt7530_setup(struct dsa_switch *ds)
{
struct mt7530_priv *priv = ds->priv;
+ struct device_node *dn = NULL;
struct device_node *phy_node;
struct device_node *mac_np;
struct mt7530_dummy_poll p;
phy_interface_t interface;
- struct device_node *dn;
+ struct dsa_port *cpu_dp;
u32 id, val;
int ret, i;
@@ -2099,7 +2100,19 @@ mt7530_setup(struct dsa_switch *ds)
* controller also is the container for two GMACs nodes representing
* as two netdev instances.
*/
- dn = dsa_to_port(ds, MT7530_CPU_PORT)->master->dev.of_node->parent;
+ dsa_switch_for_each_cpu_port(cpu_dp, ds) {
+ dn = cpu_dp->master->dev.of_node->parent;
+ /* It doesn't matter which CPU port is found first,
+ * their masters should share the same parent OF node
+ */
+ break;
+ }
+
+ if (!dn) {
+ dev_err(ds->dev, "parent OF node of DSA master not found");
+ return -EINVAL;
+ }
+
ds->assisted_learning_on_cpu_port = true;
ds->mtu_enforcement_ingress = true;
@@ -2260,6 +2273,7 @@ mt7531_setup(struct dsa_switch *ds)
{
struct mt7530_priv *priv = ds->priv;
struct mt7530_dummy_poll p;
+ struct dsa_port *cpu_dp;
u32 val, id;
int ret, i;
@@ -2332,8 +2346,11 @@ mt7531_setup(struct dsa_switch *ds)
CORE_PLL_GROUP4, val);
/* BPDU to CPU port */
- mt7530_rmw(priv, MT7531_CFC, MT7531_CPU_PMAP_MASK,
- BIT(MT7530_CPU_PORT));
+ dsa_switch_for_each_cpu_port(cpu_dp, ds) {
+ mt7530_rmw(priv, MT7531_CFC, MT7531_CPU_PMAP_MASK,
+ BIT(cpu_dp->index));
+ break;
+ }
mt7530_rmw(priv, MT753X_BPC, MT753X_BPDU_PORT_FW_MASK,
MT753X_BPDU_CPU_ONLY);
--
2.25.1
From: Frank Wunderlich <[email protected]>
Rework vlan_add/vlan_del functions in preparation for dynamic cpu port.
Currently BIT(MT7530_CPU_PORT) is added to new_members, even though
mt7530_port_vlan_add() will be called on the CPU port too.
Let DSA core decide when to call port_vlan_add for the CPU port, rather
than doing it implicitly.
We can do autonomous forwarding in a certain VLAN, but not add br0 to that
VLAN and avoid flooding the CPU with those packets, if software knows it
doesn't need to process them.
Suggested-by: Vladimir Oltean <[email protected]>
Signed-off-by: Frank Wunderlich <[email protected]>
---
v2: new patch
---
drivers/net/dsa/mt7530.c | 30 ++++++++++++------------------
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 19f0035d4410..46dee0714382 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1522,11 +1522,11 @@ static void
mt7530_hw_vlan_add(struct mt7530_priv *priv,
struct mt7530_hw_vlan_entry *entry)
{
+ struct dsa_port *dp = dsa_to_port(priv->ds, entry->port);
u8 new_members;
u32 val;
- new_members = entry->old_members | BIT(entry->port) |
- BIT(MT7530_CPU_PORT);
+ new_members = entry->old_members | BIT(entry->port);
/* Validate the entry with independent learning, create egress tag per
* VLAN and joining the port as one of the port members.
@@ -1537,22 +1537,20 @@ mt7530_hw_vlan_add(struct mt7530_priv *priv,
/* Decide whether adding tag or not for those outgoing packets from the
* port inside the VLAN.
- */
- val = entry->untagged ? MT7530_VLAN_EGRESS_UNTAG :
- MT7530_VLAN_EGRESS_TAG;
- mt7530_rmw(priv, MT7530_VAWD2,
- ETAG_CTRL_P_MASK(entry->port),
- ETAG_CTRL_P(entry->port, val));
-
- /* CPU port is always taken as a tagged port for serving more than one
+ * CPU port is always taken as a tagged port for serving more than one
* VLANs across and also being applied with egress type stack mode for
* that VLAN tags would be appended after hardware special tag used as
* DSA tag.
*/
+ if (dsa_port_is_cpu(dp))
+ val = MT7530_VLAN_EGRESS_STACK;
+ else if (entry->untagged)
+ val = MT7530_VLAN_EGRESS_UNTAG;
+ else
+ val = MT7530_VLAN_EGRESS_TAG;
mt7530_rmw(priv, MT7530_VAWD2,
- ETAG_CTRL_P_MASK(MT7530_CPU_PORT),
- ETAG_CTRL_P(MT7530_CPU_PORT,
- MT7530_VLAN_EGRESS_STACK));
+ ETAG_CTRL_P_MASK(entry->port),
+ ETAG_CTRL_P(entry->port, val));
}
static void
@@ -1571,11 +1569,7 @@ mt7530_hw_vlan_del(struct mt7530_priv *priv,
return;
}
- /* If certain member apart from CPU port is still alive in the VLAN,
- * the entry would be kept valid. Otherwise, the entry is got to be
- * disabled.
- */
- if (new_members && new_members != BIT(MT7530_CPU_PORT)) {
+ if (new_members) {
val = IVL_MAC | VTAG_EN | PORT_MEM(new_members) |
VLAN_VALID;
mt7530_write(priv, MT7530_VAWD1, val);
--
2.25.1
On Sat, Apr 30, 2022 at 03:03:46PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <[email protected]>
>
> Replace last occurences of hardcoded cpu-port by cpu_dp member of
> dsa_port struct.
>
> Now the constant can be dropped.
>
> Suggested-by: Vladimir Oltean <[email protected]>
> Signed-off-by: Frank Wunderlich <[email protected]>
> ---
Reviewed-by: Vladimir Oltean <[email protected]>
On Sat, Apr 30, 2022 at 03:03:44PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <[email protected]>
>
> Rework vlan_add/vlan_del functions in preparation for dynamic cpu port.
>
> Currently BIT(MT7530_CPU_PORT) is added to new_members, even though
> mt7530_port_vlan_add() will be called on the CPU port too.
>
> Let DSA core decide when to call port_vlan_add for the CPU port, rather
> than doing it implicitly.
>
> We can do autonomous forwarding in a certain VLAN, but not add br0 to that
> VLAN and avoid flooding the CPU with those packets, if software knows it
> doesn't need to process them.
>
> Suggested-by: Vladimir Oltean <[email protected]>
> Signed-off-by: Frank Wunderlich <[email protected]>
> ---
Reviewed-by: Vladimir Oltean <[email protected]>
On Sat, Apr 30, 2022 at 03:03:47PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <[email protected]>
>
> Add Device Tree node for mt7531 switch connected to gmac0.
>
> Signed-off-by: Frank Wunderlich <[email protected]>
> ---
> v2:
> - drop status=disabled
> ---
> .../boot/dts/rockchip/rk3568-bpi-r2-pro.dts | 48 +++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> index ed2f2bd9a016..f0ffbe818170 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> @@ -437,6 +437,54 @@ &i2c5 {
> status = "disabled";
> };
>
> +&mdio0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + switch@0 {
I think the preferable names are the newer "ethernet-switch@0",
"ethernet-ports", "ethernet-port@0".
Otherwise
Reviewed-by: Vladimir Oltean <[email protected]>
> + compatible = "mediatek,mt7531";
> + reg = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> + label = "lan0";
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "lan1";
> + };
> +
> + port@3 {
> + reg = <3>;
> + label = "lan2";
> + };
> +
> + port@4 {
> + reg = <4>;
> + label = "lan3";
> + };
> +
> + port@5 {
> + reg = <5>;
> + label = "cpu";
> + ethernet = <&gmac0>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> + };
> +};
> +
> &mdio1 {
> rgmii_phy1: ethernet-phy@0 {
> compatible = "ethernet-phy-ieee802.3-c22";
> --
> 2.25.1
>
On Wed, May 04, 2022 at 05:33:20PM +0200, Frank Wunderlich wrote:
> Hi,
>
> thanks for review
>
> > Gesendet: Mittwoch, 04. Mai 2022 um 17:24 Uhr
> > Von: "Vladimir Oltean" <[email protected]>
>
> > > +&mdio0 {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + switch@0 {
> >
> > I think the preferable names are the newer "ethernet-switch@0",
> > "ethernet-ports", "ethernet-port@0".
> >
> > Otherwise
> >
> > Reviewed-by: Vladimir Oltean <[email protected]>
>
> current device-tree nodes using "switch" and "ports"
>
> see discussioon here about make it fixed to "ports" property instead of PatternProperties including optional "ethernet-"
>
> https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/#24843155
Hmm, I don't get why Krzysztof said to just keep what is used in
existing device trees. The schema validator should describe what is
valid, and since the mt7530 driver does not care one way or another
(some drivers do explicitly parse the "ports"/"ethernet-ports" node),
then whatever is valid for the DSA core is also valid for the mt7530
bindings. And "ethernet-ports" is valid too, so I think it should be
accepted by mediatek.yaml...
Hi,
thanks for review
> Gesendet: Mittwoch, 04. Mai 2022 um 17:24 Uhr
> Von: "Vladimir Oltean" <[email protected]>
> > +&mdio0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + switch@0 {
>
> I think the preferable names are the newer "ethernet-switch@0",
> "ethernet-ports", "ethernet-port@0".
>
> Otherwise
>
> Reviewed-by: Vladimir Oltean <[email protected]>
current device-tree nodes using "switch" and "ports"
see discussioon here about make it fixed to "ports" property instead of PatternProperties including optional "ethernet-"
https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/#24843155
>
> > + compatible = "mediatek,mt7531";
> > + reg = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@1 {
> > + reg = <1>;
> > + label = "lan0";
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > + label = "lan1";
> > + };
> > +
> > + port@3 {
> > + reg = <3>;
> > + label = "lan2";
> > + };
> > +
> > + port@4 {
> > + reg = <4>;
> > + label = "lan3";
> > + };
> > +
> > + port@5 {
> > + reg = <5>;
> > + label = "cpu";
> > + ethernet = <&gmac0>;
> > + phy-mode = "rgmii";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + pause;
> > + };
> > + };
> > + };
> > + };
On 04/05/2022 17:47, Vladimir Oltean wrote:
>>
>> current device-tree nodes using "switch" and "ports"
>>
>> see discussioon here about make it fixed to "ports" property instead of PatternProperties including optional "ethernet-"
>>
>> https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/#24843155
>
> Hmm, I don't get why Krzysztof said to just keep what is used in
> existing device trees. The schema validator should describe what is
> valid,
These were talks about bindings which describe hardware. The node name,
except Devicetree spec asking for generic names, does not matter here
actually.
> and since the mt7530 driver does not care one way or another
> (some drivers do explicitly parse the "ports"/"ethernet-ports" node),
> then whatever is valid for the DSA core is also valid for the mt7530
> bindings. And "ethernet-ports" is valid too, so I think it should be
> accepted by mediatek.yaml...
You can make it "(ethernet-)?ports" as well. My comment was purely to
make it simpler, for bindings (goes into properties, not
patternProperties) and for us. If you prefer to keep it like DSA core,
also fine.
Best regards,
Krzysztof
On Sat, Apr 30, 2022 at 03:03:45PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <[email protected]>
>
> Enumerate available cpu-ports instead of using hardcoded constant.
>
> Suggested-by: Vladimir Oltean <[email protected]>
> Signed-off-by: Frank Wunderlich <[email protected]>
> ---
Reviewed-by: Vladimir Oltean <[email protected]>
Am 5. Mai 2022 10:46:55 MESZ schrieb Krzysztof Kozlowski <[email protected]>:
>On 04/05/2022 17:47, Vladimir Oltean wrote:
>>>
>>> current device-tree nodes using "switch" and "ports"
>>>
>>> see discussioon here about make it fixed to "ports" property instead
>of PatternProperties including optional "ethernet-"
>>>
>>>
>https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/#24843155
>>
>> Hmm, I don't get why Krzysztof said to just keep what is used in
>> existing device trees. The schema validator should describe what is
>> valid,
>
>These were talks about bindings which describe hardware. The node name,
>except Devicetree spec asking for generic names, does not matter here
>actually.
>
>> and since the mt7530 driver does not care one way or another
>> (some drivers do explicitly parse the "ports"/"ethernet-ports" node),
>> then whatever is valid for the DSA core is also valid for the mt7530
>> bindings. And "ethernet-ports" is valid too, so I think it should be
>> accepted by mediatek.yaml...
>
>You can make it "(ethernet-)?ports" as well. My comment was purely to
>make it simpler, for bindings (goes into properties, not
>patternProperties) and for us. If you prefer to keep it like DSA core,
>also fine.
Ok, i'm also thinking, the dsa-definition will be the right way (pattern-properties with optional "ethernet-") in binding.
Should i use "ethernet-ports" instead of "ports" here? Current dts with mt7530/mt7531 switches using "ports" so i would use it here too. If dsa prefer ethernet-ports now it should be changed in other files too.
>Best regards,
>Krzysztof
Hi,
regards Frank
On 05/05/2022 11:06, Frank Wunderlich wrote:
>> You can make it "(ethernet-)?ports" as well. My comment was purely to
>> make it simpler, for bindings (goes into properties, not
>> patternProperties) and for us. If you prefer to keep it like DSA core,
>> also fine.
>
> Ok, i'm also thinking, the dsa-definition will be the right way (pattern-properties with optional "ethernet-") in binding.
>
> Should i use "ethernet-ports" instead of "ports" here? Current dts with mt7530/mt7531 switches using "ports" so i would use it here too. If dsa prefer ethernet-ports now it should be changed in other files too.
I think bindings allow both, so choose something consistent with
existing DTS sources.
Best regards,
Krzysztof