1. 27 10月, 2017 1 次提交
  2. 18 10月, 2017 1 次提交
  3. 22 9月, 2017 1 次提交
  4. 20 9月, 2017 10 次提交
  5. 08 8月, 2017 4 次提交
  6. 21 7月, 2017 1 次提交
  7. 01 6月, 2017 1 次提交
  8. 31 5月, 2017 1 次提交
  9. 18 5月, 2017 4 次提交
  10. 25 4月, 2017 3 次提交
  11. 31 1月, 2017 2 次提交
  12. 30 1月, 2017 3 次提交
  13. 27 1月, 2017 1 次提交
  14. 25 1月, 2017 1 次提交
  15. 23 1月, 2017 1 次提交
  16. 10 1月, 2017 2 次提交
  17. 07 1月, 2017 1 次提交
  18. 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
  19. 18 10月, 2016 1 次提交
    • J
      net: dsa: b53: Fix module autoload · 03eaae52
      Javier Martinez Canillas 提交于
      If the driver is built as a module, autoload won't work because the module
      alias information is not filled. So user-space can't match the registered
      device with the corresponding module.
      
      Export the module alias information using the MODULE_DEVICE_TABLE() macro.
      
      Before this patch:
      
      $ modinfo drivers/net/dsa/b53/b53_mmap.ko  | grep alias
      $
      
      After this patch:
      
      $ modinfo drivers/net/dsa/b53/b53_mmap.ko  | grep alias
      alias:          of:N*T*Cbrcm,bcm63xx-switchC*
      alias:          of:N*T*Cbrcm,bcm63xx-switch
      alias:          of:N*T*Cbrcm,bcm6368-switchC*
      alias:          of:N*T*Cbrcm,bcm6368-switch
      alias:          of:N*T*Cbrcm,bcm6328-switchC*
      alias:          of:N*T*Cbrcm,bcm6328-switch
      alias:          of:N*T*Cbrcm,bcm3384-switchC*
      alias:          of:N*T*Cbrcm,bcm3384-switch
      Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03eaae52