1. 02 6月, 2021 1 次提交
    • V
      net: dsa: tag_8021q: fix the VLAN IDs used for encoding sub-VLANs · 4ef8d857
      Vladimir Oltean 提交于
      When using sub-VLANs in the range of 1-7, the resulting value from:
      
      	rx_vid = dsa_8021q_rx_vid_subvlan(ds, port, subvlan);
      
      is wrong according to the description from tag_8021q.c:
      
       | 11  | 10  |  9  |  8  |  7  |  6  |  5  |  4  |  3  |  2  |  1  |  0  |
       +-----------+-----+-----------------+-----------+-----------------------+
       |    DIR    | SVL |    SWITCH_ID    |  SUBVLAN  |          PORT         |
       +-----------+-----+-----------------+-----------+-----------------------+
      
      For example, when ds->index == 0, port == 3 and subvlan == 1,
      dsa_8021q_rx_vid_subvlan() returns 1027, same as it returns for
      subvlan == 0, but it should have returned 1043.
      
      This is because the low portion of the subvlan bits are not masked
      properly when writing into the 12-bit VLAN value. They are masked into
      bits 4:3, but they should be masked into bits 5:4.
      
      Fixes: 3eaae1d0 ("net: dsa: tag_8021q: support up to 8 VLANs per port using sub-VLANs")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ef8d857
  2. 11 5月, 2021 2 次提交
  3. 29 4月, 2021 1 次提交
  4. 28 4月, 2021 5 次提交
  5. 22 4月, 2021 1 次提交
  6. 21 4月, 2021 3 次提交
  7. 17 4月, 2021 1 次提交
  8. 14 4月, 2021 1 次提交
    • M
      of: net: pass the dst buffer to of_get_mac_address() · 83216e39
      Michael Walle 提交于
      of_get_mac_address() returns a "const void*" pointer to a MAC address.
      Lately, support to fetch the MAC address by an NVMEM provider was added.
      But this will only work with platform devices. It will not work with
      PCI devices (e.g. of an integrated root complex) and esp. not with DSA
      ports.
      
      There is an of_* variant of the nvmem binding which works without
      devices. The returned data of a nvmem_cell_read() has to be freed after
      use. On the other hand the return of_get_mac_address() points to some
      static data without a lifetime. The trick for now, was to allocate a
      device resource managed buffer which is then returned. This will only
      work if we have an actual device.
      
      Change it, so that the caller of of_get_mac_address() has to supply a
      buffer where the MAC address is written to. Unfortunately, this will
      touch all drivers which use the of_get_mac_address().
      
      Usually the code looks like:
      
        const char *addr;
        addr = of_get_mac_address(np);
        if (!IS_ERR(addr))
          ether_addr_copy(ndev->dev_addr, addr);
      
      This can then be simply rewritten as:
      
        of_get_mac_address(np, ndev->dev_addr);
      
      Sometimes is_valid_ether_addr() is used to test the MAC address.
      of_get_mac_address() already makes sure, it just returns a valid MAC
      address. Thus we can just test its return code. But we have to be
      careful if there are still other sources for the MAC address before the
      of_get_mac_address(). In this case we have to keep the
      is_valid_ether_addr() call.
      
      The following coccinelle patch was used to convert common cases to the
      new style. Afterwards, I've manually gone over the drivers and fixed the
      return code variable: either used a new one or if one was already
      available use that. Mansour Moufid, thanks for that coccinelle patch!
      
      <spml>
      @a@
      identifier x;
      expression y, z;
      @@
      - x = of_get_mac_address(y);
      + x = of_get_mac_address(y, z);
        <...
      - ether_addr_copy(z, x);
        ...>
      
      @@
      identifier a.x;
      @@
      - if (<+... x ...+>) {}
      
      @@
      identifier a.x;
      @@
        if (<+... x ...+>) {
            ...
        }
      - else {}
      
      @@
      identifier a.x;
      expression e;
      @@
      - if (<+... x ...+>@e)
      -     {}
      - else
      + if (!(e))
            {...}
      
      @@
      expression x, y, z;
      @@
      - x = of_get_mac_address(y, z);
      + of_get_mac_address(y, z);
        ... when != x
      </spml>
      
      All drivers, except drivers/net/ethernet/aeroflex/greth.c, were
      compile-time tested.
      Suggested-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NMichael Walle <michael@walle.cc>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83216e39
  9. 30 3月, 2021 1 次提交
  10. 26 3月, 2021 2 次提交
  11. 25 3月, 2021 2 次提交
  12. 24 3月, 2021 4 次提交
  13. 23 3月, 2021 2 次提交
    • G
      net: dsa: don't assign an error value to tag_ops · e0c755a4
      George McCollister 提交于
      Use a temporary variable to hold the return value from
      dsa_tag_driver_get() instead of assigning it to dst->tag_ops. Leaving
      an error value in dst->tag_ops can result in deferencing an invalid
      pointer when a deferred switch configuration happens later.
      
      Fixes: 357f203b ("net: dsa: keep a copy of the tagging protocol in the DSA switch tree")
      Signed-off-by: NGeorge McCollister <george.mccollister@gmail.com>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0c755a4
    • A
      dsa: simplify Kconfig symbols and dependencies · 227d7206
      Alexander Lobakin 提交于
      1. Remove CONFIG_HAVE_NET_DSA.
      
      CONFIG_HAVE_NET_DSA is a legacy leftover from the times when drivers
      should have selected CONFIG_NET_DSA manually.
      Currently, all drivers has explicit 'depends on NET_DSA', so this is
      no more needed.
      
      2. CONFIG_HAVE_NET_DSA dependencies became CONFIG_NET_DSA's ones.
      
       - dropped !S390 dependency which was introduced to be sure NET_DSA
         can select CONFIG_PHYLIB. DSA migrated to Phylink almost 3 years
         ago and the PHY library itself doesn't depend on !S390 since
         commit 870a2b5e ("phylib: remove !S390 dependeny from Kconfig");
       - INET dependency is kept to be sure we can select NET_SWITCHDEV;
       - NETDEVICES dependency is kept to be sure we can select PHYLINK.
      
      3. DSA drivers menu now depends on NET_DSA.
      
      Instead on 'depends on NET_DSA' on every single driver, the entire
      menu now depends on it. This eliminates a lot of duplicated lines
      from Kconfig with no loss (when CONFIG_NET_DSA=m, drivers also can
      be only m or n).
      This also has a nice side effect that there's no more empty menu on
      configurations without DSA.
      
      4. Kbuild will now descend into 'drivers/net/dsa' only when
         CONFIG_NET_DSA is y or m.
      
      This is safe since no objects inside this folder can be built without
      DSA core, as well as when CONFIG_NET_DSA=m, no objects can be
      built-in.
      Signed-off-by: NAlexander Lobakin <alobakin@pm.me>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      227d7206
  14. 19 3月, 2021 1 次提交
  15. 18 3月, 2021 1 次提交
  16. 17 3月, 2021 3 次提交
  17. 09 3月, 2021 1 次提交
    • V
      net: dsa: fix switchdev objects on bridge master mistakenly being applied on ports · 03cbb870
      Vladimir Oltean 提交于
      Tobias reports that after the blamed patch, VLAN objects being added to
      a bridge device are being added to all slave ports instead (swp2, swp3).
      
      ip link add br0 type bridge vlan_filtering 1
      ip link set swp2 master br0
      ip link set swp3 master br0
      bridge vlan add dev br0 vid 100 self
      
      This is because the fix was too broad: we made dsa_port_offloads_netdev
      say "yes, I offload the br0 bridge" for all slave ports, but we didn't
      add the checks whether the switchdev object was in fact meant for the
      physical port or for the bridge itself. So we are reacting on events in
      a way in which we shouldn't.
      
      The reason why the fix was too broad is because the question itself,
      "does this DSA port offload this netdev", was too broad in the first
      place. The solution is to disambiguate the question and separate it into
      two different functions, one to be called for each switchdev attribute /
      object that has an orig_dev == net_bridge (dsa_port_offloads_bridge),
      and the other for orig_dev == net_bridge_port (*_offloads_bridge_port).
      
      In the case of VLAN objects on the bridge interface, this solves the
      problem because we know that VLAN objects are per bridge port and not
      per bridge. And when orig_dev is equal to the net_bridge, we offload it
      as a bridge, but not as a bridge port; that's how we are able to skip
      reacting on those events. Note that this is compatible with future plans
      to have explicit offloading of VLAN objects on the bridge interface as a
      bridge port (in DSA, this signifies that we should add that VLAN towards
      the CPU port).
      
      Fixes: 99b8202b ("net: dsa: fix SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING getting ignored")
      Reported-by: NTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NTobias Waldekranz <tobias@waldekranz.com>
      Tested-by: NTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03cbb870
  18. 02 3月, 2021 2 次提交
  19. 27 2月, 2021 1 次提交
  20. 23 2月, 2021 1 次提交
  21. 17 2月, 2021 3 次提交
  22. 16 2月, 2021 1 次提交
    • V
      net: mscc: ocelot: avoid type promotion when calling ocelot_ifh_set_dest · 1f778d50
      Vladimir Oltean 提交于
      Smatch is confused by the fact that a 32-bit BIT(port) macro is passed
      as argument to the ocelot_ifh_set_dest function and warns:
      
      ocelot_xmit() warn: should '(((1))) << (dp->index)' be a 64 bit type?
      seville_xmit() warn: should '(((1))) << (dp->index)' be a 64 bit type?
      
      The destination port mask is copied into a 12-bit field of the packet,
      starting at bit offset 67 and ending at 56.
      
      So this DSA tagging protocol supports at most 12 bits, which is clearly
      less than 32. Attempting to send to a port number > 12 will cause the
      packing() call to truncate way before there will be 32-bit truncation
      due to type promotion of the BIT(port) argument towards u64.
      
      Therefore, smatch's fears that BIT(port) will do the wrong thing and
      cause unexpected truncation for "port" values >= 32 are unfounded.
      Nonetheless, let's silence the warning by explicitly passing an u64
      value to ocelot_ifh_set_dest, such that the compiler does not need to do
      a questionable type promotion.
      Reported-by: Nkernel test robot <lkp@intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f778d50
新手
引导
客服 返回
顶部