diff mbox

[net-next,RFC,08/12] net: dsa: Remove support for bypass bridge port attributes/vlan set

Message ID 1499268990-19251-9-git-send-email-arkadis@mellanox.com
State RFC, archived
Delegated to: David Miller
Headers show

Commit Message

Arkadi Sharshevsky July 5, 2017, 3:36 p.m. UTC
The bridge port attributes/vlan for DSA devices should be set only
from bridge code. Furthermore, The vlans are synced totally with the
bridge so there is no need for special dump support.

Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
---
 drivers/net/dsa/b53/b53_common.c       | 44 --------------------------
 drivers/net/dsa/b53/b53_priv.h         |  3 --
 drivers/net/dsa/bcm_sf2.c              |  1 -
 drivers/net/dsa/dsa_loop.c             | 38 -----------------------
 drivers/net/dsa/microchip/ksz_common.c | 41 -------------------------
 drivers/net/dsa/mv88e6xxx/chip.c       | 56 ----------------------------------
 include/net/dsa.h                      |  4 ---
 net/dsa/dsa_priv.h                     |  4 ---
 net/dsa/port.c                         | 12 --------
 net/dsa/slave.c                        |  6 ----
 10 files changed, 209 deletions(-)

Comments

Florian Fainelli July 5, 2017, 7:45 p.m. UTC | #1
On 07/05/2017 08:36 AM, Arkadi Sharshevsky wrote:
> The bridge port attributes/vlan for DSA devices should be set only
> from bridge code. Furthermore, The vlans are synced totally with the
> bridge so there is no need for special dump support.
> 
> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>

I would be more comfortable if we still had a way to dump HW entries by
calling into drivers, because it's useful for debugging, and doing that
using standard tools plus an additional flag for instance:

bridge fdb show

would dump the SW-maintained VLANs, but:

bridge fdb show hw

would dump the HW-maintained VLANs, or any flag name really, but the
point is that we can keep using a standard tool to expose debugging
features. debugfs (or something else) could be used, but was rejected by
David.

Also, technically, it ought to be possible to configure a port's VLAN
membership (although using poor semantics) through e.g: vconfig add
sw0p0 1, which would call ndo_vlan_rx_add_vid() (DSA does not support it
but mlxsw does), and so being able to dump that configuration would be
somehow helpful.
Arkadi Sharshevsky July 6, 2017, 11 a.m. UTC | #2
On 07/05/2017 10:45 PM, Florian Fainelli wrote:
> On 07/05/2017 08:36 AM, Arkadi Sharshevsky wrote:
>> The bridge port attributes/vlan for DSA devices should be set only
>> from bridge code. Furthermore, The vlans are synced totally with the
>> bridge so there is no need for special dump support.
>>
>> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
> 
> I would be more comfortable if we still had a way to dump HW entries by
> calling into drivers, because it's useful for debugging, and doing that
> using standard tools plus an additional flag for instance:
> 
> bridge fdb show
> 
> would dump the SW-maintained VLANs, but:
> 
> bridge fdb show hw
> 

I agree that in your case, the FDBs are exception because they cannot be
synced with the sw bridge due to lack of interrupt per learned entry,
but note that this ability of bypass dump should not be supported by
switchdev code because its contradicts the model. That is why I moved it
inside DSA in one of the following patches (another reason is that
nobody is using it beside you so there is no reason to leave it there).

This is especially true for vlans which are synced completely with the
software bridge.

Regarding debugging, if you want to see the hardware tables you can
easily use dpipe for that. For example you can add table which does
match on vlan and mac and set the output port, or some table that
matches port and incoming packets vlan into internal metadata (FID)
that can be used for lookup.

I just don't think it is good idea for mixing this tools together.

> would dump the HW-maintained VLANs, or any flag name really, but the
> point is that we can keep using a standard tool to expose debugging
> features. debugfs (or something else) could be used, but was rejected by
> David.
> 
> Also, technically, it ought to be possible to configure a port's VLAN
> membership (although using poor semantics) through e.g: vconfig add
> sw0p0 1, which would call ndo_vlan_rx_add_vid() (DSA does not support it
> but mlxsw does), and so being able to dump that configuration would be

Yeah, in mlxsw the vlan devices are used mainly for vlan unaware bridge,
so the vlans will not be visible by the bridge, but the correct API to
see this is via:

$ip -d link show sw1p7.8

> somehow helpful.
>
Florian Fainelli July 6, 2017, 9:36 p.m. UTC | #3
On 07/06/2017 04:00 AM, Arkadi Sharshevsky wrote:
> 
> 
> On 07/05/2017 10:45 PM, Florian Fainelli wrote:
>> On 07/05/2017 08:36 AM, Arkadi Sharshevsky wrote:
>>> The bridge port attributes/vlan for DSA devices should be set only
>>> from bridge code. Furthermore, The vlans are synced totally with the
>>> bridge so there is no need for special dump support.
>>>
>>> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
>>
>> I would be more comfortable if we still had a way to dump HW entries by
>> calling into drivers, because it's useful for debugging, and doing that
>> using standard tools plus an additional flag for instance:
>>
>> bridge fdb show
>>
>> would dump the SW-maintained VLANs, but:
>>
>> bridge fdb show hw
>>
> 
> I agree that in your case, the FDBs are exception because they cannot be
> synced with the sw bridge due to lack of interrupt per learned entry,
> but note that this ability of bypass dump should not be supported by
> switchdev code because its contradicts the model. That is why I moved it
> inside DSA in one of the following patches (another reason is that
> nobody is using it beside you so there is no reason to leave it there).

Sure, I agree with that, no need to clutter switchdev and other
switchdev only drivers like mlxsw with FDB dumping code that they don't
need.

> 
> This is especially true for vlans which are synced completely with the
> software bridge.
> 
> Regarding debugging, if you want to see the hardware tables you can
> easily use dpipe for that. For example you can add table which does
> match on vlan and mac and set the output port, or some table that
> matches port and incoming packets vlan into internal metadata (FID)
> that can be used for lookup.
> 
> I just don't think it is good idea for mixing this tools together.

Well, that is once again debatable, ethtool for instance contains a
collection of debug and functional information about your hardware.
Having the ability to dump the VLAN tables using the standard bridge
vlan output has a lot of value in that you can easily correlated whether
the SW representation matches the HW representation (as fed by the
driver back into bridge's netlink messages).

> 
>> would dump the HW-maintained VLANs, or any flag name really, but the
>> point is that we can keep using a standard tool to expose debugging
>> features. debugfs (or something else) could be used, but was rejected by
>> David.
>>
>> Also, technically, it ought to be possible to configure a port's VLAN
>> membership (although using poor semantics) through e.g: vconfig add
>> sw0p0 1, which would call ndo_vlan_rx_add_vid() (DSA does not support it
>> but mlxsw does), and so being able to dump that configuration would be
> 
> Yeah, in mlxsw the vlan devices are used mainly for vlan unaware bridge,
> so the vlans will not be visible by the bridge, but the correct API to
> see this is via:
> 
> $ip -d link show sw1p7.8

Since the VLAN-aware device is visible to user-space, my comment does
not really make sense in that this very interface existence indicates
that the port has been properly set up with a VLAN tag
Arkadi Sharshevsky July 9, 2017, 1:56 p.m. UTC | #4
On 07/07/2017 12:36 AM, Florian Fainelli wrote:
> On 07/06/2017 04:00 AM, Arkadi Sharshevsky wrote:
>>
>>
>> On 07/05/2017 10:45 PM, Florian Fainelli wrote:
>>> On 07/05/2017 08:36 AM, Arkadi Sharshevsky wrote:
>>>> The bridge port attributes/vlan for DSA devices should be set only
>>>> from bridge code. Furthermore, The vlans are synced totally with the
>>>> bridge so there is no need for special dump support.
>>>>
>>>> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
>>>
>>> I would be more comfortable if we still had a way to dump HW entries by
>>> calling into drivers, because it's useful for debugging, and doing that
>>> using standard tools plus an additional flag for instance:
>>>
>>> bridge fdb show
>>>
>>> would dump the SW-maintained VLANs, but:
>>>
>>> bridge fdb show hw
>>>
>>
>> I agree that in your case, the FDBs are exception because they cannot be
>> synced with the sw bridge due to lack of interrupt per learned entry,
>> but note that this ability of bypass dump should not be supported by
>> switchdev code because its contradicts the model. That is why I moved it
>> inside DSA in one of the following patches (another reason is that
>> nobody is using it beside you so there is no reason to leave it there).
> 
> Sure, I agree with that, no need to clutter switchdev and other
> switchdev only drivers like mlxsw with FDB dumping code that they don't
> need.
> 
>>
>> This is especially true for vlans which are synced completely with the
>> software bridge.
>>
>> Regarding debugging, if you want to see the hardware tables you can
>> easily use dpipe for that. For example you can add table which does
>> match on vlan and mac and set the output port, or some table that
>> matches port and incoming packets vlan into internal metadata (FID)
>> that can be used for lookup.
>>
>> I just don't think it is good idea for mixing this tools together.
> 
> Well, that is once again debatable, ethtool for instance contains a
> collection of debug and functional information about your hardware.
> Having the ability to dump the VLAN tables using the standard bridge
> vlan output has a lot of value in that you can easily correlated whether
> the SW representation matches the HW representation (as fed by the
> driver back into bridge's netlink messages).
>

In my opinion all of this is very confusing. When the user does:

$bridge vlan show dev sw1p5
port    vlan ids
sw1p5    1 PVID Egress Untagged

sw1p5    1 PVID Egress Untagged

and sees two set of identical vlans its just confusing, Furthermore
if the hw/sw are different it even more weird. For example in what
scenario would a user want to configure different PVID only for hw?

I think that for switchdev device, in case the bridge wants to add
a vlan and hardware fails, the operation should fail as well (done
under rtnl so it can sleep). By this the user gains:

1. No confusion due to mismatched behavior hw/sw. Vlans should be
   synced!.
2. Indication about successful offload. So user knows if its in
   hardware or not.

It seems that you already discussed it:
https://www.mail-archive.com/netdev@vger.kernel.org/msg147067.html

It even seems you have a bug here so deleting this bypass add/del
/dump makes the API more consistent and fixes a bug.

>>
>>> would dump the HW-maintained VLANs, or any flag name really, but the
>>> point is that we can keep using a standard tool to expose debugging
>>> features. debugfs (or something else) could be used, but was rejected by
>>> David.
>>>
>>> Also, technically, it ought to be possible to configure a port's VLAN
>>> membership (although using poor semantics) through e.g: vconfig add
>>> sw0p0 1, which would call ndo_vlan_rx_add_vid() (DSA does not support it
>>> but mlxsw does), and so being able to dump that configuration would be
>>
>> Yeah, in mlxsw the vlan devices are used mainly for vlan unaware bridge,
>> so the vlans will not be visible by the bridge, but the correct API to
>> see this is via:
>>
>> $ip -d link show sw1p7.8
> 
> Since the VLAN-aware device is visible to user-space, my comment does
> not really make sense in that this very interface existence indicates
> that the port has been properly set up with a VLAN tag
>
Vivien Didelot July 10, 2017, 5:13 p.m. UTC | #5
Hi Florian, Arkadi,

Florian Fainelli <f.fainelli@gmail.com> writes:

> I would be more comfortable if we still had a way to dump HW entries by
> calling into drivers, because it's useful for debugging, and doing that
> using standard tools plus an additional flag for instance:
>
> bridge fdb show
>
> would dump the SW-maintained VLANs, but:
>
> bridge fdb show hw

I don't think this makes much sense because the network hardware
architecture must be abstracted to the user, who only deals with user
network interfaces. This is also only needed for development and debug.

> would dump the HW-maintained VLANs, or any flag name really, but the
> point is that we can keep using a standard tool to expose debugging
> features. debugfs (or something else) could be used, but was rejected by
> David.

IIRC, what David is opposed to is having a *driver specific* debugfs
interface, i.e. debugfs for only mv88e6xxx. But he was opened to having
a *generic* debugfs interface in net/dsa/ from which any DSA chip
(e.g. lan9303, b53, qca8k, etc.) would benefit.

That makes even more sense for CPU and DSA ports which are not exposed
to userspace. Andrew played with dpipe but that wasn't quite satisfying
if I'm not mistaken. What we need for development and debug is a compile
time enableable interface to simply call into dsa_switch_ops directly.

So far here's what I have: port's VLAN, FDB, MDB, regs, stats, and
switch fabric topology (symlinks between interfaces): http://ix.io/yq0

I can split and submit this as RFC and see if I get slapped.


Thanks,

        Vivien
diff mbox

Patch

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index c414b43..6020e88 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1053,49 +1053,6 @@  int b53_vlan_del(struct dsa_switch *ds, int port,
 }
 EXPORT_SYMBOL(b53_vlan_del);
 
-int b53_vlan_dump(struct dsa_switch *ds, int port,
-		  struct switchdev_obj_port_vlan *vlan,
-		  switchdev_obj_dump_cb_t *cb)
-{
-	struct b53_device *dev = ds->priv;
-	u16 vid, vid_start = 0, pvid;
-	struct b53_vlan *vl;
-	int err = 0;
-
-	if (is5325(dev) || is5365(dev))
-		vid_start = 1;
-
-	b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), &pvid);
-
-	/* Use our software cache for dumps, since we do not have any HW
-	 * operation returning only the used/valid VLANs
-	 */
-	for (vid = vid_start; vid < dev->num_vlans; vid++) {
-		vl = &dev->vlans[vid];
-
-		if (!vl->valid)
-			continue;
-
-		if (!(vl->members & BIT(port)))
-			continue;
-
-		vlan->vid_begin = vlan->vid_end = vid;
-		vlan->flags = 0;
-
-		if (vl->untag & BIT(port))
-			vlan->flags |= BRIDGE_VLAN_INFO_UNTAGGED;
-		if (pvid == vid)
-			vlan->flags |= BRIDGE_VLAN_INFO_PVID;
-
-		err = cb(&vlan->obj);
-		if (err)
-			break;
-	}
-
-	return err;
-}
-EXPORT_SYMBOL(b53_vlan_dump);
-
 /* Address Resolution Logic routines */
 static int b53_arl_op_wait(struct b53_device *dev)
 {
@@ -1552,7 +1509,6 @@  static const struct dsa_switch_ops b53_switch_ops = {
 	.port_vlan_prepare	= b53_vlan_prepare,
 	.port_vlan_add		= b53_vlan_add,
 	.port_vlan_del		= b53_vlan_del,
-	.port_vlan_dump		= b53_vlan_dump,
 	.port_fdb_dump		= b53_fdb_dump,
 	.port_fdb_add		= b53_fdb_add,
 	.port_fdb_del		= b53_fdb_del,
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index f29c892..af5d6c1 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -393,9 +393,6 @@  void b53_vlan_add(struct dsa_switch *ds, int port,
 		  struct switchdev_trans *trans);
 int b53_vlan_del(struct dsa_switch *ds, int port,
 		 const struct switchdev_obj_port_vlan *vlan);
-int b53_vlan_dump(struct dsa_switch *ds, int port,
-		  struct switchdev_obj_port_vlan *vlan,
-		  switchdev_obj_dump_cb_t *cb);
 int b53_fdb_add(struct dsa_switch *ds, int port,
 		const unsigned char *addr, u16 vid);
 int b53_fdb_del(struct dsa_switch *ds, int port,
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 648f91b..f0d2dc4 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1033,7 +1033,6 @@  static const struct dsa_switch_ops bcm_sf2_ops = {
 	.port_vlan_prepare	= b53_vlan_prepare,
 	.port_vlan_add		= b53_vlan_add,
 	.port_vlan_del		= b53_vlan_del,
-	.port_vlan_dump		= b53_vlan_dump,
 	.port_fdb_prepare	= b53_fdb_prepare,
 	.port_fdb_dump		= b53_fdb_dump,
 	.port_fdb_add		= b53_fdb_add,
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index fdd8f38..76d6660 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -257,43 +257,6 @@  static int dsa_loop_port_vlan_del(struct dsa_switch *ds, int port,
 	return 0;
 }
 
-static int dsa_loop_port_vlan_dump(struct dsa_switch *ds, int port,
-				   struct switchdev_obj_port_vlan *vlan,
-				   switchdev_obj_dump_cb_t *cb)
-{
-	struct dsa_loop_priv *ps = ds->priv;
-	struct mii_bus *bus = ps->bus;
-	struct dsa_loop_vlan *vl;
-	u16 vid, vid_start = 0;
-	int err = 0;
-
-	dev_dbg(ds->dev, "%s\n", __func__);
-
-	/* Just do a sleeping operation to make lockdep checks effective */
-	mdiobus_read(bus, ps->port_base + port, MII_BMSR);
-
-	for (vid = vid_start; vid < DSA_LOOP_VLANS; vid++) {
-		vl = &ps->vlans[vid];
-
-		if (!(vl->members & BIT(port)))
-			continue;
-
-		vlan->vid_begin = vlan->vid_end = vid;
-		vlan->flags = 0;
-
-		if (vl->untagged & BIT(port))
-			vlan->flags |= BRIDGE_VLAN_INFO_UNTAGGED;
-		if (ps->pvid == vid)
-			vlan->flags |= BRIDGE_VLAN_INFO_PVID;
-
-		err = cb(&vlan->obj);
-		if (err)
-			break;
-	}
-
-	return err;
-}
-
 static struct dsa_switch_ops dsa_loop_driver = {
 	.get_tag_protocol	= dsa_loop_get_protocol,
 	.setup			= dsa_loop_setup,
@@ -310,7 +273,6 @@  static struct dsa_switch_ops dsa_loop_driver = {
 	.port_vlan_prepare	= dsa_loop_port_vlan_prepare,
 	.port_vlan_add		= dsa_loop_port_vlan_add,
 	.port_vlan_del		= dsa_loop_port_vlan_del,
-	.port_vlan_dump		= dsa_loop_port_vlan_dump,
 };
 
 static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index b55f364..a53ce59 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -638,46 +638,6 @@  static int ksz_port_vlan_del(struct dsa_switch *ds, int port,
 	return 0;
 }
 
-static int ksz_port_vlan_dump(struct dsa_switch *ds, int port,
-			      struct switchdev_obj_port_vlan *vlan,
-			      switchdev_obj_dump_cb_t *cb)
-{
-	struct ksz_device *dev = ds->priv;
-	u16 vid;
-	u16 data;
-	struct vlan_table *vlan_cache;
-	int err = 0;
-
-	mutex_lock(&dev->vlan_mutex);
-
-	/* use dev->vlan_cache due to lack of searching valid vlan entry */
-	for (vid = vlan->vid_begin; vid < dev->num_vlans; vid++) {
-		vlan_cache = &dev->vlan_cache[vid];
-
-		if (!(vlan_cache->table[0] & VLAN_VALID))
-			continue;
-
-		vlan->vid_begin = vid;
-		vlan->vid_end = vid;
-		vlan->flags = 0;
-		if (vlan_cache->table[2] & BIT(port)) {
-			if (vlan_cache->table[1] & BIT(port))
-				vlan->flags |= BRIDGE_VLAN_INFO_UNTAGGED;
-			ksz_pread16(dev, port, REG_PORT_DEFAULT_VID, &data);
-			if (vid == (data & 0xFFFFF))
-				vlan->flags |= BRIDGE_VLAN_INFO_PVID;
-
-			err = cb(&vlan->obj);
-			if (err)
-				break;
-		}
-	}
-
-	mutex_unlock(&dev->vlan_mutex);
-
-	return err;
-}
-
 struct alu_struct {
 	/* entry 1 */
 	u8	is_static:1;
@@ -1124,7 +1084,6 @@  static const struct dsa_switch_ops ksz_switch_ops = {
 	.port_vlan_prepare	= ksz_port_vlan_prepare,
 	.port_vlan_add		= ksz_port_vlan_add,
 	.port_vlan_del		= ksz_port_vlan_del,
-	.port_vlan_dump		= ksz_port_vlan_dump,
 	.port_fdb_dump		= ksz_port_fdb_dump,
 	.port_fdb_add		= ksz_port_fdb_add,
 	.port_fdb_del		= ksz_port_fdb_del,
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index fba68c8..9cc6269 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1040,61 +1040,6 @@  static int mv88e6xxx_vtu_loadpurge(struct mv88e6xxx_chip *chip,
 	return chip->info->ops->vtu_loadpurge(chip, entry);
 }
 
-static int mv88e6xxx_port_vlan_dump(struct dsa_switch *ds, int port,
-				    struct switchdev_obj_port_vlan *vlan,
-				    switchdev_obj_dump_cb_t *cb)
-{
-	struct mv88e6xxx_chip *chip = ds->priv;
-	struct mv88e6xxx_vtu_entry next = {
-		.vid = chip->info->max_vid,
-	};
-	u16 pvid;
-	int err;
-
-	if (!chip->info->max_vid)
-		return -EOPNOTSUPP;
-
-	mutex_lock(&chip->reg_lock);
-
-	err = mv88e6xxx_port_get_pvid(chip, port, &pvid);
-	if (err)
-		goto unlock;
-
-	do {
-		err = mv88e6xxx_vtu_getnext(chip, &next);
-		if (err)
-			break;
-
-		if (!next.valid)
-			break;
-
-		if (next.member[port] ==
-		    MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER)
-			continue;
-
-		/* reinit and dump this VLAN obj */
-		vlan->vid_begin = next.vid;
-		vlan->vid_end = next.vid;
-		vlan->flags = 0;
-
-		if (next.member[port] ==
-		    MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNTAGGED)
-			vlan->flags |= BRIDGE_VLAN_INFO_UNTAGGED;
-
-		if (next.vid == pvid)
-			vlan->flags |= BRIDGE_VLAN_INFO_PVID;
-
-		err = cb(&vlan->obj);
-		if (err)
-			break;
-	} while (next.vid < chip->info->max_vid);
-
-unlock:
-	mutex_unlock(&chip->reg_lock);
-
-	return err;
-}
-
 static int mv88e6xxx_atu_new(struct mv88e6xxx_chip *chip, u16 *fid)
 {
 	DECLARE_BITMAP(fid_bitmap, MV88E6XXX_N_FID);
@@ -3858,7 +3803,6 @@  static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
 	.port_vlan_prepare	= mv88e6xxx_port_vlan_prepare,
 	.port_vlan_add		= mv88e6xxx_port_vlan_add,
 	.port_vlan_del		= mv88e6xxx_port_vlan_del,
-	.port_vlan_dump		= mv88e6xxx_port_vlan_dump,
 	.port_fdb_add           = mv88e6xxx_port_fdb_add,
 	.port_fdb_del           = mv88e6xxx_port_fdb_del,
 	.port_fdb_dump          = mv88e6xxx_port_fdb_dump,
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 4835b0e..9171b11 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -384,10 +384,6 @@  struct dsa_switch_ops {
 				 struct switchdev_trans *trans);
 	int	(*port_vlan_del)(struct dsa_switch *ds, int port,
 				 const struct switchdev_obj_port_vlan *vlan);
-	int	(*port_vlan_dump)(struct dsa_switch *ds, int port,
-				  struct switchdev_obj_port_vlan *vlan,
-				  switchdev_obj_dump_cb_t *cb);
-
 	/*
 	 * Forwarding database
 	 */
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 2b2f124..421df4f 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -138,10 +138,6 @@  int dsa_port_vlan_add(struct dsa_port *dp,
 		      struct switchdev_trans *trans);
 int dsa_port_vlan_del(struct dsa_port *dp,
 		      const struct switchdev_obj_port_vlan *vlan);
-int dsa_port_vlan_dump(struct dsa_port *dp,
-		       struct switchdev_obj_port_vlan *vlan,
-		       switchdev_obj_dump_cb_t *cb);
-
 /* slave.c */
 extern const struct dsa_device_ops notag_netdev_ops;
 void dsa_slave_mii_bus_init(struct dsa_switch *ds);
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 86e0585..ce19216 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -246,15 +246,3 @@  int dsa_port_vlan_del(struct dsa_port *dp,
 
 	return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
 }
-
-int dsa_port_vlan_dump(struct dsa_port *dp,
-		       struct switchdev_obj_port_vlan *vlan,
-		       switchdev_obj_dump_cb_t *cb)
-{
-	struct dsa_switch *ds = dp->ds;
-
-	if (ds->ops->port_vlan_dump)
-		return ds->ops->port_vlan_dump(ds, dp->index, vlan, cb);
-
-	return -EOPNOTSUPP;
-}
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 53326ba..7393b36 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -302,9 +302,6 @@  static int dsa_slave_port_obj_dump(struct net_device *dev,
 	case SWITCHDEV_OBJ_ID_PORT_MDB:
 		err = dsa_port_mdb_dump(dp, SWITCHDEV_OBJ_PORT_MDB(obj), cb);
 		break;
-	case SWITCHDEV_OBJ_ID_PORT_VLAN:
-		err = dsa_port_vlan_dump(dp, SWITCHDEV_OBJ_PORT_VLAN(obj), cb);
-		break;
 	default:
 		err = -EOPNOTSUPP;
 		break;
@@ -926,9 +923,6 @@  static const struct net_device_ops dsa_slave_netdev_ops = {
 	.ndo_netpoll_cleanup	= dsa_slave_netpoll_cleanup,
 	.ndo_poll_controller	= dsa_slave_poll_controller,
 #endif
-	.ndo_bridge_getlink	= switchdev_port_bridge_getlink,
-	.ndo_bridge_setlink	= switchdev_port_bridge_setlink,
-	.ndo_bridge_dellink	= switchdev_port_bridge_dellink,
 	.ndo_get_phys_port_name	= dsa_slave_get_phys_port_name,
 	.ndo_setup_tc		= dsa_slave_setup_tc,
 };