1. 04 10月, 2012 2 次提交
  2. 03 10月, 2012 13 次提交
  3. 02 10月, 2012 18 次提交
  4. 01 10月, 2012 7 次提交
    • R
      mlx4_core: Disable SENSE_PORT for multifunction devices · aadf4f3f
      Roland Dreier 提交于
      In the current driver, the SENSE_PORT firmware command is issued as a
      "wrapped" command, but the command handling code doesn't have a
      wrapper, so it will never do anything other than log an error message.
      The latest ConnectX-3 2.11.500 firmware reports the SENSE_PORT
      capability even in multi-function (SR-IOV) mode, so the driver will
      try to issue the command.
      
      At least until the driver has a proper wrapper for SENSE_PORT, make
      sure we disable the command for multi-function devices.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      aadf4f3f
    • R
      mlx4_core: Clean up enabling of SENSE_PORT for older (ConnectX-1/-2) HCAs · ca3e57a5
      Roland Dreier 提交于
      Instead of having a hard-coded "PCI device ID != 0x1003" (which
      obviously breaks as newer devices with ID != 0x1003 become available),
      instead let's set a flag in our PCI device table for the older devices
      where we're supposed to force using SENSE_PORT.  This also avoids
      enabling SENSE_PORT for virtual functions by mistake.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      ca3e57a5
    • R
      mlx4_core: Stash PCI ID driver_data in mlx4_priv structure · 839f1243
      Roland Dreier 提交于
      That way we can check flags later on, when we've finished with the
      pci_device_id structure.  Also convert the "is VF" flag to an enum:
      "Never do in the preprocessor what can be done in C."
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      839f1243
    • R
      mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem · f3d4c89e
      Roland Dreier 提交于
      On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
      before mlx4_multi_func_init().  However, for unlucky configurations,
      mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
      that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
      
      However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
      calls into mlx4_slave_cmd(), and that immediately tries to do
      
      	down(&priv->cmd.slave_sem);
      
      but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
      (which we haven't called yet).  The next thing it tries to do is access
      priv->mfunc.vhcr, but that hasn't been allocated yet.
      
      Fix this by moving the initialization of slave_sem and vhcr up into
      mlx4_cmd_init(). Also, since slave_sem is really just being used as a
      mutex, convert it into a slave_cmd_mutex.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      f3d4c89e
    • R
      mlx4_core: Trivial cleanups to driver log messages · 84b1f153
      Roland Dreier 提交于
      Also put format string onto one line.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      84b1f153
    • R
      69612b9f
    • J
      mlx4: Modify proxy/tunnel QP mechanism so that guests do no calculations · 47605df9
      Jack Morgenstein 提交于
      Previously, the structure of a guest's proxy QPs followed the
      structure of the PPF special qps (qp0 port 1, qp0 port 2, qp1 port 1,
      qp1 port 2, ...).  The guest then did offset calculations on the
      sqp_base qp number that the PPF passed to it in QUERY_FUNC_CAP().
      
      This is now changed so that the guest does no offset calculations
      regarding proxy or tunnel QPs to use.  This change frees the PPF from
      needing to adhere to a specific order in allocating proxy and tunnel
      QPs.
      
      Now QUERY_FUNC_CAP provides each port individually with its proxy
      qp0, proxy qp1, tunnel qp0, and tunnel qp1 QP numbers, and these are
      used directly where required (with no offset calculations).
      
      To accomplish this change, several fields were added to the phys_caps
      structure for use by the PPF and by non-SR-IOV mode:
      
          base_sqpn -- in non-sriov mode, this was formerly sqp_start.
          base_proxy_sqpn -- the first physical proxy qp number -- used by PPF
          base_tunnel_sqpn -- the first physical tunnel qp number -- used by PPF.
      
      The current code in the PPF still adheres to the previous layout of
      sqps, proxy-sqps and tunnel-sqps.  However, the PPF can change this
      layout without affecting VF or (paravirtualized) PF code.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      47605df9