1. 04 Jun, 2016 11 commits
    • Andrew Lunn's avatar
      net: dsa: Refactor selection of tag ops into a function · 39a7f2a4
      Andrew Lunn authored
      Replace the two switch statements with an array lookup, and store the
      result in the dsa tree structure. The drivers no longer need to know
      the selected tag protocol, so remove it from the dsa switch structure.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      39a7f2a4
    • Andrew Lunn's avatar
      net: dsa: mv88e6xxx: Only support EDSA tagging · 5377b802
      Andrew Lunn authored
      The merged driver no longer offers the option to use DSA tagging. So
      remove the code to setup the switch to do DSA tagging and hard code
      the use of EDSA.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>y
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5377b802
    • Andrew Lunn's avatar
      net: dsa: Split up creating/destroying of DSA and CPU ports · 9b8e895c
      Andrew Lunn authored
      Refactor the code to setup a single DSA/CPU port into a function of
      its own, and export it, so it can be used by the new binding.
      
      Similarly, refactor the destroy code into a function.  When destroying
      the ports, don't put the of node. They should be released at the end
      along with the normal ports.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b8e895c
    • Andrew Lunn's avatar
      net: dsa: Copy the routing table into the switch structure · 66472fc0
      Andrew Lunn authored
      The new binding will not have a chip data structure, it will place the
      routing directly into the switch structure. To enable backwards
      compatibility, copy the routing from the chip data into the switch
      structure.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66472fc0
    • Andrew Lunn's avatar
      net: dsa: Remove dynamic allocate of routing table · 4a7704ff
      Andrew Lunn authored
      With a maximum of four switches, the size of the routing table is the
      same as the pointer to it. Removing it makes the code simpler.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a7704ff
    • Andrew Lunn's avatar
      net: dsa: Move port device node into port structure · 189b0d93
      Andrew Lunn authored
      Move the port device node structure into the port structure, from the
      chip data. This information is needed in the next step of implementing
      the new binding.
      
      The chip data structure is used while parsing the whole old binding,
      before the individual switch structures exist. With the new bindings,
      this is reversed, the switches exist first, and the interconnections
      between the switches is derived from the individual switch
      bindings. Thus this chip data structure becomes unneeded.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      eviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      189b0d93
    • Andrew Lunn's avatar
      net: dsa: Add a ports structure and use it in the switch structure · c8b09808
      Andrew Lunn authored
      There are going to be more per-port members added to the switch
      structure. So add a port structure and move the netdev into it.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c8b09808
    • Andrew Lunn's avatar
      net: dsa: tag_{e}dsa.c: Remove dependency on platform data · 149cafd7
      Andrew Lunn authored
      The platform data nr_chips is used when validating a received packet,
      to ensure it comes from a know switch chip. The number of possible
      switches is limited to DSA_MAX_SWITCHES, so use this as the first
      validation step. The new binding allows holes in the dst->ds[] array,
      so also ensure ensure there is a valid dsa_switch for this packet.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      149cafd7
    • Andrew Lunn's avatar
      net: dsa: slave: Remove MDIO address from switch MDIO bus name · 6e8e862d
      Andrew Lunn authored
      The DSA layer should no longer assume the switch is connected to an
      MDIO bus. As a result, we cannot use the address on the MDIO bus when
      forming the name of the switches internal MDIO bus for its builtin and
      possibly external PHYs. The switch index is sufficient to make the
      name unique, so drop the MDIO address.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e8e862d
    • Vivien Didelot's avatar
      net: dsa: mv88e6xxx: fix circular lock in PPU work · 762eb67b
      Vivien Didelot authored
      Lock debugging shows that there is a possible circular lock in the PPU
      work code. Switch the lock order of smi_mutex and ppu_mutex to fix this.
      
      Here's the full trace:
      
          [    4.341325] ======================================================
          [    4.347519] [ INFO: possible circular locking dependency detected ]
          [    4.353800] 4.6.0 #4 Not tainted
          [    4.357039] -------------------------------------------------------
          [    4.363315] kworker/0:1/328 is trying to acquire lock:
          [    4.368463]  (&ps->smi_mutex){+.+.+.}, at: [<8049c758>] mv88e6xxx_reg_read+0x30/0x54
          [    4.376313]
          [    4.376313] but task is already holding lock:
          [    4.382160]  (&ps->ppu_mutex){+.+...}, at: [<8049cac0>] mv88e6xxx_ppu_reenable_work+0x28/0xd4
          [    4.390772]
          [    4.390772] which lock already depends on the new lock.
          [    4.390772]
          [    4.398963]
          [    4.398963] the existing dependency chain (in reverse order) is:
          [    4.406461]
          [    4.406461] -> #1 (&ps->ppu_mutex){+.+...}:
          [    4.410897]        [<806d86bc>] mutex_lock_nested+0x54/0x360
          [    4.416606]        [<8049a800>] mv88e6xxx_ppu_access_get+0x28/0x100
          [    4.422906]        [<8049b778>] mv88e6xxx_phy_read+0x90/0xdc
          [    4.428599]        [<806a4534>] dsa_slave_phy_read+0x3c/0x40
          [    4.434300]        [<804943ec>] mdiobus_read+0x68/0x80
          [    4.439481]        [<804939d4>] get_phy_device+0x58/0x1d8
          [    4.444914]        [<80493ed0>] mdiobus_scan+0x24/0xf4
          [    4.450078]        [<8049409c>] __mdiobus_register+0xfc/0x1ac
          [    4.455857]        [<806a40b0>] dsa_probe+0x860/0xca8
          [    4.460934]        [<8043246c>] platform_drv_probe+0x5c/0xc0
          [    4.466627]        [<804305a0>] driver_probe_device+0x118/0x450
          [    4.472589]        [<80430b00>] __device_attach_driver+0xac/0x128
          [    4.478724]        [<8042e350>] bus_for_each_drv+0x74/0xa8
          [    4.484235]        [<804302d8>] __device_attach+0xc4/0x154
          [    4.489755]        [<80430cec>] device_initial_probe+0x1c/0x20
          [    4.495612]        [<8042f620>] bus_probe_device+0x98/0xa0
          [    4.501123]        [<8042fbd0>] deferred_probe_work_func+0x4c/0xd4
          [    4.507328]        [<8013a794>] process_one_work+0x1a8/0x604
          [    4.513030]        [<8013ac54>] worker_thread+0x64/0x528
          [    4.518367]        [<801409e8>] kthread+0xec/0x100
          [    4.523201]        [<80108f30>] ret_from_fork+0x14/0x24
          [    4.528462]
          [    4.528462] -> #0 (&ps->smi_mutex){+.+.+.}:
          [    4.532895]        [<8015ad5c>] lock_acquire+0xb4/0x1dc
          [    4.538154]        [<806d86bc>] mutex_lock_nested+0x54/0x360
          [    4.543856]        [<8049c758>] mv88e6xxx_reg_read+0x30/0x54
          [    4.549549]        [<8049cad8>] mv88e6xxx_ppu_reenable_work+0x40/0xd4
          [    4.556022]        [<8013a794>] process_one_work+0x1a8/0x604
          [    4.561707]        [<8013ac54>] worker_thread+0x64/0x528
          [    4.567053]        [<801409e8>] kthread+0xec/0x100
          [    4.571878]        [<80108f30>] ret_from_fork+0x14/0x24
          [    4.577139]
          [    4.577139] other info that might help us debug this:
          [    4.577139]
          [    4.585159]  Possible unsafe locking scenario:
          [    4.585159]
          [    4.591093]        CPU0                    CPU1
          [    4.595631]        ----                    ----
          [    4.600169]   lock(&ps->ppu_mutex);
          [    4.603693]                                lock(&ps->smi_mutex);
          [    4.609742]                                lock(&ps->ppu_mutex);
          [    4.615790]   lock(&ps->smi_mutex);
          [    4.619314]
          [    4.619314]  *** DEADLOCK ***
          [    4.619314]
          [    4.625256] 3 locks held by kworker/0:1/328:
          [    4.629537]  #0:  ("events"){.+.+..}, at: [<8013a704>] process_one_work+0x118/0x604
          [    4.637288]  #1:  ((&ps->ppu_work)){+.+...}, at: [<8013a704>] process_one_work+0x118/0x604
          [    4.645653]  #2:  (&ps->ppu_mutex){+.+...}, at: [<8049cac0>] mv88e6xxx_ppu_reenable_work+0x28/0xd4
          [    4.654714]
          [    4.654714] stack backtrace:
          [    4.659098] CPU: 0 PID: 328 Comm: kworker/0:1 Not tainted 4.6.0 #4
          [    4.665286] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
          [    4.671748] Workqueue: events mv88e6xxx_ppu_reenable_work
          [    4.677174] Backtrace:
          [    4.679674] [<8010d354>] (dump_backtrace) from [<8010d5a0>] (show_stack+0x20/0x24)
          [    4.687252]  r6:80fb3c88 r5:80fb3c88 r4:80fb4728 r3:00000002
          [    4.693003] [<8010d580>] (show_stack) from [<803b45e8>] (dump_stack+0x24/0x28)
          [    4.700246] [<803b45c4>] (dump_stack) from [<80157398>] (print_circular_bug+0x208/0x32c)
          [    4.708361] [<80157190>] (print_circular_bug) from [<8015a630>] (__lock_acquire+0x185c/0x1b80)
          [    4.716982]  r10:9ec22a00 r9:00000060 r8:8164b6bc r7:00000040 r6:00000003 r5:8163a5b4
          [    4.724905]  r4:00000003 r3:9ec22de8
          [    4.728537] [<80158dd4>] (__lock_acquire) from [<8015ad5c>] (lock_acquire+0xb4/0x1dc)
          [    4.736378]  r10:60000013 r9:00000000 r8:00000000 r7:00000000 r6:9e5e9c50 r5:80e618e0
          [    4.744301]  r4:00000000
          [    4.746879] [<8015aca8>] (lock_acquire) from [<806d86bc>] (mutex_lock_nested+0x54/0x360)
          [    4.754976]  r10:9e5e9c1c r9:80e616c4 r8:9f685ea0 r7:0000001b r6:9ec22a00 r5:8163a5b4
          [    4.762899]  r4:9e5e9c1c
          [    4.765477] [<806d8668>] (mutex_lock_nested) from [<8049c758>] (mv88e6xxx_reg_read+0x30/0x54)
          [    4.774008]  r10:80e60c5b r9:80e616c4 r8:9f685ea0 r7:0000001b r6:00000004 r5:9e5e9c10
          [    4.781930]  r4:9e5e9c1c
          [    4.784507] [<8049c728>] (mv88e6xxx_reg_read) from [<8049cad8>] (mv88e6xxx_ppu_reenable_work+0x40/0xd4)
          [    4.793907]  r7:9ffd5400 r6:9e5e9c68 r5:9e5e9cb0 r4:9e5e9c10
          [    4.799659] [<8049ca98>] (mv88e6xxx_ppu_reenable_work) from [<8013a794>] (process_one_work+0x1a8/0x604)
          [    4.809059]  r9:80e616c4 r8:9f685ea0 r7:9ffd5400 r6:80e0a1c8 r5:9f5f2e80 r4:9e5e9cb0
          [    4.816910] [<8013a5ec>] (process_one_work) from [<8013ac54>] (worker_thread+0x64/0x528)
          [    4.825010]  r10:9f5f2e80 r9:00000008 r8:80e0dc80 r7:80e0a1fc r6:80e0a1c8 r5:9f5f2e98
          [    4.832933]  r4:80e0a1c8
          [    4.835510] [<8013abf0>] (worker_thread) from [<801409e8>] (kthread+0xec/0x100)
          [    4.842827]  r10:00000000 r9:00000000 r8:00000000 r7:8013abf0 r6:9f5f2e80 r5:9ec15740
          [    4.850749]  r4:00000000
          [    4.853327] [<801408fc>] (kthread) from [<80108f30>] (ret_from_fork+0x14/0x24)
          [    4.860557]  r7:00000000 r6:00000000 r5:801408fc r4:9ec15740
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      762eb67b
    • Andrew Lunn's avatar
      net: dsa: slave: chip data is optional, don't dereference NULL · 0e576044
      Andrew Lunn authored
      The new binding does not make use of dsa_chip_data, a.k.a cd.  When
      retrieving the size of the EEPROM attached to a switch, don't assume
      there is a cd attached to the switch structure.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0e576044
  2. 03 Jun, 2016 20 commits
  3. 02 Jun, 2016 5 commits
  4. 01 Jun, 2016 4 commits
    • Peter Robinson's avatar
      stmmac: make platform drivers depend on their associated SoC · 2e280c18
      Peter Robinson authored
      There's not much point, except compile test, enabling the stmmac
      platform drivers unless their actual SoC is enabled. They're not
      useful without it.
      Signed-off-by: default avatarPeter Robinson <pbrobinson@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e280c18
    • David S. Miller's avatar
      Merge branch 'macvlan-less-mcast-cloning' · 250ba748
      David S. Miller authored
      Herbert Xu says:
      
      ====================
      macvlan: Avoid unnecessary multicast cloning
      
      This patch tries to improve macvlan multicast performance by
      maintaining a filter hash at the macvlan_port level so that we
      can quickly determine whether a given packet is needed or not.
      
      It is preceded by a patch that fixes a potential use-after-free
      bug that I discovered while looking over this.
      
      v2 fixed a bug where promiscuous/allmulti settings weren't handled
      correctly.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      250ba748
    • Herbert Xu's avatar
      macvlan: Avoid unnecessary multicast cloning · 9c127a01
      Herbert Xu authored
      Currently we always queue a multicast packet for further processing,
      even if none of the macvlan devices are subscribed to the address.
      
      This patch optimises this by adding a global multicast filter for
      a macvlan_port.
      
      Note that this patch doesn't handle the broadcast addresses of the
      individual macvlan devices correctly, if they are not all identical
      to vlan->lowerdev.  However, this is already broken because there
      is no mechanism in place to update the individual multicast filters
      when you change the broadcast address.
      
      If someone cares enough they should fix this by collecting all
      broadcast addresses for a macvlan as we do for multicast and unicast.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9c127a01
    • Herbert Xu's avatar
      macvlan: Fix potential use-after free for broadcasts · 260916df
      Herbert Xu authored
      When we postpone a broadcast packet we save the source port in
      the skb if it is local.  However, the source port can disappear
      before we get a chance to process the packet.
      
      This patch fixes this by holding a ref count on the netdev.
      
      It also delays the skb->cb modification until after we allocate
      the new skb as you should not modify shared skbs.
      
      Fixes: 412ca155 ("macvlan: Move broadcasts into a work queue")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      260916df