1. 04 Jun, 2016 10 commits
    • 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
    • David S. Miller's avatar
    • David S. Miller's avatar
      sctp: Fix warning in sctp_packet_transmit_chunk() · 3b55a537
      David S. Miller authored
      size_t objects should be printed with %Z printf format.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b55a537
    • Yuval Mintz's avatar
      qed: Fix next-ptr chains for BE / 32-bit · 81b1251d
      Yuval Mintz authored
      Commit a91eb52a ("qed: Revisit chain implementation") contains an
      incorrect implementation for BE platforms, as device's regpairs containing
      addresses are LE and they're not converted correctly when read back.
      In addition, it raises a compilation warning for 32-bit platforms where
      dma_addr_t is a 32-bit variable.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81b1251d
    • David S. Miller's avatar
      Merge branch 'qed-roce-iscsi' · 03c7f70b
      David S. Miller authored
      Yuval Mintz says:
      
      ====================
      qed: RocE & iSCSI infrastructure
      
      We plan on sending 2 new protocol drivers in the imminent future -
      both our RoCE [qedr] and iSCSI [qedi] drivers. As both submissions
      would be rather massive and in order to avoid collisions between them,
      the common infrastructure on the qed side was prepared as an independent
      patch-series to be sent ahead of those 2 submissions.
      
      This patch series introduces in QED 2 new 'ids' - one for iscsi and
      one for roce. It then goes and adds logic required for configuring
      said protocols in HW. Notice it *doesn't* actually add any client using
      said ids, but rather only the infrastructure to allow their later usage.
      
      What this patch doesn't contain is the slowpath protocol-configuration
      toward the firmware. I.e., it contains register-setting logic, memory
      allocations, etc., but not actual flow-related configuration specific
      to the protocl. Those would be sent as part of the protocol driver
      submissions.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03c7f70b
    • Yuval Mintz's avatar
      qed: Initialize hardware for new protocols · dbb799c3
      Yuval Mintz authored
      RoCE and iSCSI would require some added/changed hw configuration in order
      to properly run; The biggest single change being the requirement of
      allocating and mapping host memory for several HW blocks that aren't being
      used by qede [SRC, QM, TM, etc.].
      
      In addition, whereas qede is only using context memory for HW blocks, the
      new protocol would also require task memories to be added.
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dbb799c3
    • Yuval Mintz's avatar
      qed: Add iscsi/rdma personalities · c5ac9319
      Yuval Mintz authored
      This patch adds in the ecore 2 new personalities in addition to
      QED_PCI_ETH - QED_PCI_ISCSI and QED_PCI_ETH_ROCE.
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5ac9319
    • Yuval Mintz's avatar
      qed: Add common HSI for new protocols · 7a9b6b8f
      Yuval Mintz authored
      This adds the qed portion of the RoCE & iSCSI firmware HSI,
      as well as adding several new common HSI files which would be required
      by both qed and qed* protocols.
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a9b6b8f
    • Yuval Mintz's avatar
      qed: Revisit chain implementation · a91eb52a
      Yuval Mintz authored
      RoCE driver is going to need a 32-bit chain [current chain implementation
      for qed* currently supports only 16-bit producer/consumer chains].
      
      This patch adds said support, as well as doing other slight tweaks and
      modifications to qed's chain API.
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a91eb52a
  2. 03 Jun, 2016 13 commits
  3. 02 Jun, 2016 9 commits
  4. 01 Jun, 2016 5 commits
  5. 31 May, 2016 3 commits