1. 23 2月, 2019 5 次提交
    • D
      Merge branch 'dsa-vlan' · 2fce40a5
      David S. Miller 提交于
      Florian Fainelli says:
      
      ====================
      net: dsa: VLAN devices w/ filtering
      
      This patch series supports having VLAN devices on top of DSA/switch
      ports while the switch has VLAN filtering globally turned on (as is the
      case with Broadcom switches). Whether the switch does global or per-port
      VLAN filtering, having VLAN entries for these VLAN devices is
      beneficial.
      
      We take care of a few possibly problematic cases:
      
      - adding a VLAN device while there is an existing VLAN entry created by
        a VLAN aware bridge. The entire bridge's VLAN database and not just
        the specific bridge port is being checked to be safe and conserative
      
      - adding a bridge VLAN entry when there is an existing VLAN device
        created is also not possible because that would lead to the bridge
        being able to manipulate the VLAN device's VID/attributes under its feet
      
      - enslaving a VLAN device into a VLAN aware bridge since that duplicates
        functionality already offered by the VLAN aware bridge
      
      Here are the different test cases that were run to exercise this:
      
      ip addr flush dev gphy
      ip link add dev br0 type bridge
      echo 1 > /sys/class/net/br0/bridge/vlan_filtering
      ip link set dev gphy master br0
      udhcpc -i br0
      
      vconfig add rgmii_1 100
      ifconfig rgmii_1.100 192.168.100.10
      ping -c 2 192.168.100.1
      
      vconfig add br0 42
      bridge vlan add vid 42 dev gphy
      bridge vlan add vid 42 dev br0 self
      ifconfig br0.42 192.168.42.2
      ping -c 2 192.168.42.1
      
      ip link del rgmii_1.100
      vconfig add rgmii_1 100
      ifconfig rgmii_1.100 192.168.100.10
      ping -c 2 192.168.100.1
      echo 0 > /sys/class/net/br0/bridge/vlan_filtering
      ping -c 2 192.168.100.1
      
      ip link del rgmii_1.100
      echo 1 > /sys/class/net/br0/bridge/vlan_filtering
      
      vconfig add rgmii_1 100
      brctl addif br0 rgmii_1
      bridge vlan add vid 100 dev rgmii_1
      
      vconfig rem rgmii_1.100
      bridge vlan add vid 100 dev rgmii_1
      vconfig add rgmii_1 100
      
      bridge vlan del vid 100 dev rgmii_1
      vconfig add rgmii_1 100
      brctl addif br0 rgmii_1.100
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2fce40a5
    • F
      net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation · 061f6a50
      Florian Fainelli 提交于
      In order to properly support VLAN filtering being enabled/disabled on a
      bridge, while having other ports being non bridge port members, we need
      to support the ndo_vlan_rx_{add,kill}_vid callbacks in order to make
      sure the non-bridge ports can continue receiving VLAN tags, even when
      the switch is globally configured to do ingress/egress VID checking.
      
      Since we can call dsa_port_vlan_{add,del} with a bridge_dev pointer
      NULL, we now need to check that in these two functions.
      
      We specifically deal with two possibly problematic cases:
      
      - creating a bridge VLAN entry while there is an existing VLAN device
        claiming that same VID
      
      - creating a VLAN device while there is an existing bridge VLAN entry
        with that VID
      
      Those are both resolved with returning -EBUSY back to user-space.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      061f6a50
    • F
      net: dsa: Deny enslaving VLAN devices into VLAN aware bridge · cc1d5bda
      Florian Fainelli 提交于
      VLAN devices on top of a DSA network device which is already part of a
      bridge and with said bridge being VLAN aware should not be allowed to be
      enslaved into that bridge. For one, this duplicates functionality
      offered by the VLAN aware bridge which supports tagged and untagged VLAN
      frames processing and it would make things needlessly complex to e.g.:
      propagate FDB/MDB accordingly.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc1d5bda
    • G
      isdn_common: Mark expected switch fall-throughs · 6d20faec
      Gustavo A. R. Silva 提交于
      In preparation to enabling -Wimplicit-fallthrough, mark switch
      cases where we are expecting to fall through.
      
      This patch fixes the following warnings:
      
      drivers/isdn/i4l/isdn_common.c: In function ‘isdn_wildmat’:
      drivers/isdn/i4l/isdn_common.c:173:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
          p++;
          ~^~
      drivers/isdn/i4l/isdn_common.c:174:3: note: here
         default:
         ^~~~~~~
        CC [M]  drivers/leds/leds-lp8788.o
        CC [M]  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu10_smumgr.o
      drivers/isdn/i4l/isdn_common.c: In function ‘isdn_status_callback’:
      drivers/isdn/i4l/isdn_common.c:729:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (divert_if)
            ^
      drivers/isdn/i4l/isdn_common.c:732:2: note: here
        default:
        ^~~~~~~
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      Notice that, in this particular case, the code comment is modified
      in accordance with what GCC is expecting to find.
      
      This patch is part of the ongoing efforts to enable
      -Wimplicit-fallthrough.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d20faec
    • A
      net: phy: aquantia: Use get_features for the PHYs abilities · 023fb4b5
      Andrew Lunn 提交于
      Use the new PHY driver call to get the PHYs supported features.
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      [hkallweit1@gmail.com: removed new config_init callback from patch]
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      023fb4b5
  2. 22 2月, 2019 35 次提交