Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 11月, 2012 1 次提交
  3. 27 11月, 2012 1 次提交
    • O
      mlx4: 64-byte CQE/EQE support · 08ff3235
      由 Or Gerlitz 提交于 
      ConnectX-3 devices can use either 64- or 32-byte completion queue
entries (CQEs) and event queue entries (EQEs).  Using 64-byte
EQEs/CQEs performs better because each entry is aligned to a complete
cacheline.  This patch queries the HCA's capabilities, and if it
supports 64-byte CQEs and EQES the driver will configure the HW to
work in 64-byte mode.

The 32-byte vs 64-byte mode is global per HCA and not per CQ or EQ.

Since this mode is global, userspace (libmlx4) must be updated to work
with the configured CQE size, and guests using SR-IOV virtual
functions need to know both EQE and CQE size.

In case one of the 64-byte CQE/EQE capabilities is activated, the
patch makes sure that older guest drivers that use the QUERY_DEV_FUNC
command (e.g as done in mlx4_core of Linux 3.3..3.6) will notice that
they need an update to be able to work with the PPF. This is done by
changing the returned pf_context_behaviour not to be zero any more. In
case none of these capabilities is activated that value remains zero
and older guest drivers can run OK.

The SRIOV related flow is as follows

1. the PPF does the detection of the new capabilities using
   QUERY_DEV_CAP command.

2. the PPF activates the new capabilities using INIT_HCA.

3. the VF detects if the PPF activated the capabilities using
   QUERY_HCA, and if this is the case activates them for itself too.

Note that the VF detects that it must be aware to the new PF behaviour
using QUERY_FUNC_CAP.  Steps 1 and 2 apply also for native mode.

User space notification is done through a new field introduced in
struct mlx4_ib_ucontext which holds device capabilities for which user
space must take action. This changes the binary interface so the ABI
towards libmlx4 exposed through uverbs is bumped from 3 to 4 but only
when **needed** i.e. only when the driver does use 64-byte CQEs or
future device capabilities which must be in sync by user space. This
practice allows to work with unmodified libmlx4 on older devices (e.g
A0, B0) which don't support 64-byte CQEs.

In order to keep existing systems functional when they update to a
newer kernel that contains these changes in VF and userspace ABI, a
module parameter enable_64b_cqe_eqe must be set to enable 64-byte
mode; the default is currently false.
Signed-off-by: NEli Cohen <eli@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      08ff3235
  5. 16 11月, 2012 1 次提交
  7. 15 11月, 2012 4 次提交
    • D
      Revert "drivers/net/phy/mdio-bitbang.c: Call mdiobus_unregister before mdiobus_free" · 80d11788
      由 David S. Miller 提交于 
      This reverts commit aa731872.

As pointed out by Ben Hutchings, this change is not correct.

mdiobus_unregister() can't be called if the bus isn't registered yet,
however this change can result in situations which cause that to
happen.

Part of the confusion here revolves around the fact that the
callers of this module control registration/unregistration,
rather than the module itself.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80d11788
    • K
      net/smsc911x: Fix ready check in cases where WORD_SWAP is needed · 769ce4c9
      由 Kamlakant Patel 提交于 
      The chip ready check added by the commit 3ac3546e [Always wait for
the chip to be ready] does not work when the register read/write
is word swapped. This check has been added before the WORD_SWAP
register is programmed, so we need to check for swapped register
value as well.

Bit 16 is marked as RESERVED in SMSC datasheet, Steve Glendinning
<steve@shawell.net> checked with SMSC and wrote:

  The chip architects have concluded we should be reading PMT_CTRL
  until we see any of bits 0, 8, 16 or 24 set.  Then we should read
  BYTE_TEST to check the byte order is correct (as we already do).

  The rationale behind this is that some of the chip variants have
  word order swapping features too, so the READY bit could actually
  be in any of the 4 possible locations.  The architects have confirmed
  that if any of these 4 positions is set the chip is ready.  The other
  3 locations will either never be set or can only go high after READY
  does (so also indicate the device is ready).

This change will check for the READY bit at the 16th position. We do
not check the other two cases (bit 8 and 24) since the driver does not
support byte-swapped register read/write.
Signed-off-by: NKamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      769ce4c9
    • X
      drivers/net: fix tasklet misuse issue · 71c6c837
      由 Xiaotian Feng 提交于 
      In commit 175c0dff, drivers uses tasklet_kill to avoid put disabled tasklet
on the tasklet vec. But some of the drivers uses tasklet_init & tasklet_disable
in the driver init code, then tasklet_enable when it is opened. This makes
tasklet_enable on a killed tasklet and make ksoftirqd crazy then. Normally,
drivers should use tasklet_init/tasklet_kill on device open/remove, and use
tasklet_disable/tasklet_enable on device suspend/resume.
Reported-by: NPeter Wu <lekensteyn@gmail.com>
Tested-by: NPeter Wu <lekensteyn@gmail.com>
Signed-off-by: NXiaotian Feng <dannyfeng@tencent.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71c6c837
    • H
      brcmfmac: fix typo in CONFIG_BRCMISCAN · d61f978b
      由 Hauke Mehrtens 提交于 
      The old ifdef CONFIG_BRCMFISCAN looks wrong to me and it makes more
sense when CONFIG_BRCMISCAN is used.
This patch was just compile tested by me, but not runtime tested.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d61f978b
  9. 14 11月, 2012 5 次提交
  11. 10 11月, 2012 2 次提交
  13. 08 11月, 2012 3 次提交
  15. 07 11月, 2012 1 次提交
  17. 05 11月, 2012 1 次提交
  19. 04 11月, 2012 5 次提交
  21. 03 11月, 2012 5 次提交
  23. 01 11月, 2012 11 次提交