1. 20 9月, 2017 3 次提交
  2. 08 8月, 2017 4 次提交
  3. 21 7月, 2017 1 次提交
  4. 01 6月, 2017 1 次提交
  5. 31 5月, 2017 1 次提交
  6. 18 5月, 2017 3 次提交
  7. 25 4月, 2017 3 次提交
  8. 31 1月, 2017 1 次提交
  9. 30 1月, 2017 3 次提交
  10. 27 1月, 2017 1 次提交
  11. 23 1月, 2017 1 次提交
  12. 10 1月, 2017 2 次提交
  13. 07 1月, 2017 1 次提交
  14. 17 11月, 2016 1 次提交
    • F
      net: dsa: b53: Fix VLAN usage and how we treat CPU port · e47112d9
      Florian Fainelli 提交于
      We currently have a fundamental problem in how we treat the CPU port and
      its VLAN membership. As soon as a second VLAN is configured to be
      untagged, the CPU automatically becomes untagged for that VLAN as well,
      and yet, we don't gracefully make sure that the CPU becomes tagged in
      the other VLANs it could be a member of. This results in only one VLAN
      being effectively usable from the CPU's perspective.
      
      Instead of having some pretty complex logic which tries to maintain the
      CPU port's default VLAN and its untagged properties, just do something
      very simple which consists in neither altering the CPU port's PVID
      settings, nor its untagged settings:
      
      - whenever a VLAN is added, the CPU is automatically a member of this
        VLAN group, as a tagged member
      - PVID settings for downstream ports do not alter the CPU port's PVID
        since it now is part of all VLANs in the system
      
      This means that a typical example where e.g: LAN ports are in VLAN1, and
      WAN port is in VLAN2, now require having two VLAN interfaces for the
      host to properly terminate and send traffic from/to.
      
      Fixes: Fixes: a2482d2c ("net: dsa: b53: Plug in VLAN support")
      Reported-by: NHartmut Knaack <knaack.h@gmx.de>
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e47112d9
  15. 23 9月, 2016 1 次提交
  16. 20 9月, 2016 1 次提交
  17. 02 9月, 2016 1 次提交
  18. 27 8月, 2016 4 次提交
  19. 25 8月, 2016 1 次提交
    • V
      net: dsa: rename switch operations structure · 9d490b4e
      Vivien Didelot 提交于
      Now that the dsa_switch_driver structure contains only function pointers
      as it is supposed to, rename it to the more appropriate dsa_switch_ops,
      uniformly to any other operations structure in the kernel.
      
      No functional changes here, basically just the result of something like:
      s/dsa_switch_driver *drv/dsa_switch_ops *ops/g
      
      However keep the {un,}register_switch_driver functions and their
      dsa_switch_drivers list as is, since they represent the -- likely to be
      deprecated soon -- legacy DSA registration framework.
      
      In the meantime, also fix the following checks from checkpatch.pl to
      make it happy with this patch:
      
          CHECK: Comparison to NULL could be written "!ops"
          #403: FILE: net/dsa/dsa.c:470:
          +	if (ops == NULL) {
      
          CHECK: Comparison to NULL could be written "ds->ops->get_strings"
          #773: FILE: net/dsa/slave.c:697:
          +		if (ds->ops->get_strings != NULL)
      
          CHECK: Comparison to NULL could be written "ds->ops->get_ethtool_stats"
          #824: FILE: net/dsa/slave.c:785:
          +	if (ds->ops->get_ethtool_stats != NULL)
      
          CHECK: Comparison to NULL could be written "ds->ops->get_sset_count"
          #835: FILE: net/dsa/slave.c:798:
          +		if (ds->ops->get_sset_count != NULL)
      
          total: 0 errors, 0 warnings, 4 checks, 784 lines checked
      Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d490b4e
  20. 23 8月, 2016 1 次提交
  21. 10 8月, 2016 1 次提交
  22. 12 7月, 2016 1 次提交
  23. 24 6月, 2016 1 次提交
  24. 10 6月, 2016 2 次提交