Skip to content

L
linux
Switch branch/tag
  1. 03 Sep, 2019 3 commits
  3. 02 Sep, 2019 6 commits
  5. 01 Sep, 2019 23 commits
  7. 31 Aug, 2019 8 commits
    • David S. Miller's avatar
      Merge branch 'qed-Enhancements' · ed6e8103
      David S. Miller authored 
      Sudarsana Reddy Kalluru says:

====================
qed*: Enhancements.

The patch series adds couple of enhancements to qed/qede drivers.
  - Support for dumping the config id attributes via ethtool -w/W.
  - Support for dumping the GRC data of required memory regions using
    ethtool -w/W interfaces.

Patch (1) adds driver APIs for reading the config id attributes.
Patch (2) adds ethtool support for dumping the config id attributes.
Patch (3) adds support for configuring the GRC dump config flags.
Patch (4) adds ethtool support for dumping the grc dump.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed6e8103
    • Sudarsana Reddy Kalluru's avatar
      qede: Add support for dumping the grc data. · 849dbf09
      Sudarsana Reddy Kalluru authored 
      This patch adds driver support for configuring grc dump config flags, and
dumping the grc data via ethtool get/set-dump interfaces.
Signed-off-by: default avatarSudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      849dbf09
    • Sudarsana Reddy Kalluru's avatar
      qed: Add APIs for configuring grc dump config flags. · 3b86bd07
      Sudarsana Reddy Kalluru authored 
      The patch adds driver support for configuring the grc dump config flags.
Signed-off-by: default avatarSudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b86bd07
    • Sudarsana Reddy Kalluru's avatar
      qede: Add support for reading the config id attributes. · d44a3ced
      Sudarsana Reddy Kalluru authored 
      Add driver support for dumping the config id attributes via ethtool dump
interfaces.
Signed-off-by: default avatarSudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d44a3ced
    • Sudarsana Reddy Kalluru's avatar
      qed: Add APIs for reading config id attributes. · 2d4c8495
      Sudarsana Reddy Kalluru authored 
      The patch adds driver support for reading the config id attributes from NVM
flash partition.
Signed-off-by: default avatarSudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2d4c8495
    • David S. Miller's avatar
      Merge branch 'Dynamic-toggling-of-vlan_filtering-for-SJA1105-DSA' · b0274eb0
      David S. Miller authored 
      Vladimir Oltean says:

====================
Dynamic toggling of vlan_filtering for SJA1105 DSA

This patchset addresses a limitation in dsa_8021q where this sequence of
commands was causing the switch to stop forwarding traffic:

  ip link add name br0 type bridge vlan_filtering 0
  ip link set dev swp2 master br0
  echo 1 > /sys/class/net/br0/bridge/vlan_filtering
  echo 0 > /sys/class/net/br0/bridge/vlan_filtering

The issue has to do with the VLAN table manipulations that dsa_8021q
does without notifying the bridge layer. The solution is to always
restore the VLANs that the bridge knows about, when disabling tagging.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0274eb0
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: Restore bridge VLANs when enabling vlan_filtering · 5f33183b
      Vladimir Oltean authored 
      The bridge core assumes that enabling/disabling vlan_filtering will
translate into the simple toggling of a flag for switchdev drivers.

That is clearly not the case for sja1105, which alters the VLAN table
and the pvids in order to obtain port separation in standalone mode.

There are 2 parts to the issue.

First, tag_8021q changes the pvid to a unique per-port rx_vid for frame
identification. But we need to disable tag_8021q when vlan_filtering
kicks in, and at that point, the VLAN configured as pvid will have to be
removed from the filtering table of the ports. With an invalid pvid, the
ports will drop all traffic.  Since the bridge will not call any vlan
operation through switchdev after enabling vlan_filtering, we need to
ensure we're in a functional state ourselves. Hence read the pvid that
the bridge is aware of, and program that into our ports.

Secondly, tag_8021q uses the 1024-3071 range privately in
vlan_filtering=0 mode. Had the user installed one of these VLANs during
a previous vlan_filtering=1 session, then upon the next tag_8021q
cleanup for vlan_filtering to kick in again, VLANs in that range will
get deleted unconditionally, hence breaking user expectation. So when
deleting the VLANs, check if the bridge had knowledge about them, and if
it did, re-apply the settings. Wrap this logic inside a
dsa_8021q_vid_apply helper function to reduce code duplication.
Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f33183b
    • Vladimir Oltean's avatar
      net: bridge: Populate the pvid flag in br_vlan_get_info · f40d9b20
      Vladimir Oltean authored 
      Currently this simplified code snippet fails:

	br_vlan_get_pvid(netdev, &pvid);
	br_vlan_get_info(netdev, pvid, &vinfo);
	ASSERT(!(vinfo.flags & BRIDGE_VLAN_INFO_PVID));

It is intuitive that the pvid of a netdevice should have the
BRIDGE_VLAN_INFO_PVID flag set.

However I can't seem to pinpoint a commit where this behavior was
introduced. It seems like it's been like that since forever.

At a first glance it would make more sense to just handle the
BRIDGE_VLAN_INFO_PVID flag in __vlan_add_flags. However, as Nikolay
explains:

  There are a few reasons why we don't do it, most importantly because
  we need to have only one visible pvid at any single time, even if it's
  stale - it must be just one. Right now that rule will not be violated
  by this change, but people will try using this flag and could see two
  pvids simultaneously. You can see that the pvid code is even using
  memory barriers to propagate the new value faster and everywhere the
  pvid is read only once.  That is the reason the flag is set
  dynamically when dumping entries, too.  A second (weaker) argument
  against would be given the above we don't want another way to do the
  same thing, specifically if it can provide us with two pvids (e.g. if
  walking the vlan list) or if it can provide us with a pvid different
  from the one set in the vg. [Obviously, I'm talking about RCU
  pvid/vlan use cases similar to the dumps.  The locked cases are fine.
  I would like to avoid explaining why this shouldn't be relied upon
  without locking]

So instead of introducing the above change and making sure of the pvid
uniqueness under RCU, simply dynamically populate the pvid flag in
br_vlan_get_info().
Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f40d9b20
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7