1. 24 3月, 2017 8 次提交
    • A
      qedf: fix wrong le16 conversion · 6f359f99
      Arnd Bergmann 提交于
      gcc points out that we are converting a 16-bit integer into a 32-bit
      little-endian type and assigning that to 16-bit little-endian
      will end up with a zero:
      
      drivers/scsi/qedf/drv_fcoe_fw_funcs.c: In function 'init_initiator_rw_fcoe_task':
      include/uapi/linux/byteorder/big_endian.h:32:26: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
        t_st_ctx->read_write.rx_id = cpu_to_le32(FCOE_RX_ID);
      
      The correct solution appears to be to just use a 16-bit byte swap instead.
      
      Fixes: be086e7c ("qed*: Utilize Firmware 8.15.3.0")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NChad Dupuis <chad.dupuis@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f359f99
    • D
      Merge branch 'qed-management-interaction-and-feature-changes' · 028ba8aa
      David S. Miller 提交于
      Yuval Mintz says:
      
      ====================
      qed: Management interaction & feature changes
      
      All patches in this series either affect direct interaction with the
      management firmware, or changes logic relating to some values retrieved
      from it.
      
      Patch #1 revises the basic logic for sending messages to the management
      firmware and there completion, and is the most significant [at least
      code-wise] of the bunch.
      
      Patch #2 changes infrastrcure in a way that should better protect us form
      mistakes leading to stack corruption such as was fixed in
      bb480242 ("qed: Prevent stack corruption on MFW interaction").
      
      Patch #3 corrects some update API endian issue [sent here as it would
      create conflicts with #2, and because it's lack would create a rather
      insignifcant problem].
      
      Patch #4 removes some unnecessary logging, allowing cleaner forward
      compatibility with future management firmware versions.
      
      Patches #5, #6 slightly change the number of possible L2 queues in some
      scenarios, leading to the possibility of having more queues / VFS.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      028ba8aa
    • M
      qed: Reserve VF feature before PF · dec26533
      Mintz, Yuval 提交于
      Align the driver feature distribution with the flow utilized
      by the management firmware - first reserve L2 queues for
      VFs and use all the remaining for the PF.
      
      The current distribution might lead to PFs with an enormous
      amount of queues, but at the same time leave us with insufficient
      resources for starting all VFs.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dec26533
    • M
      qed: Don't waste SBs unused by RoCE · 810bb1f0
      Mintz, Yuval 提交于
      When RoCE is enabled on a given L2 interface, the interrupt lines
      are divided equally between L2 and RoCE -
      But in case number of lines needed for RoCE is limited by number
      of available CNQs, we can utilize the additional lines for L2.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      810bb1f0
    • M
      qed: Reduce verbosity of unimplemented MFW messages · 39815944
      Mintz, Yuval 提交于
      Management firmware and driver are meant to be both backward and forward
      compatibile with each other.
      
      If a new mangement firmware would work with an older driver,
      it's possible that driver would receive indications which are meaningless
      to it. That's perfectly acceptible from the firmware part - so no need to
      log such messages at default verbosity; That would only serve to confuse
      users.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39815944
    • M
      qed: Correct endian order of MAC passed to MFW · 17991002
      Mintz, Yuval 提交于
      The management firmware is running on a Big Endian processor,
      and when running on LE platform HW is configured to swap access
      to memory shared between management firmware and driver on
      32-bit granulariy.
      
      As a result, for matters of simplicity most of the APIs between
      driver and management firmware are based on 32-bit variables.
      MAC settings are one exception, as driver needs to fill a byte
      array when indicating to management firmware that primary MAC
      has changed.
      Due to the swap, driver must make sure that the mac that was
      provided in byte-order would be translated into native order,
      otherwise after the swap the management firmware would read
      it swapped.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17991002
    • T
      qed: Pass src/dst sizes when interacting with MFW · 2f67af8c
      Tomer Tayar 提交于
      The driver interaction with management firmware involves a union
      of all the data-members relating to the commands the driver prepares.
      
      Current interface assumes the caller always passes such a union -
      but thats cumbersome as well as risky [chancing a stack corruption
      in case caller accidentally passes a smaller member instead of union].
      
      Change implementation so that caller could pass a pointer to any
      of the members instead of the union.
      Signed-off-by: NTomer Tayar <Tomer.Tayar@cavium.com>
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2f67af8c
    • T
      qed: Revise MFW command locking · 4ed1eea8
      Tomer Tayar 提交于
      Interaction of driver -> management firmware is based
      on a one-pending mailbox [per interface], and various
      mailbox commands need to be synchronized.
      
      Current scheme is messy, and there's a difficulty extending
      it as it deals differently with various commands as well as
      making assumption on the required behavior for load/unload
      requests.
      
      Drop the current scheme into a completion-list-based approach;
      Each flow would try sending the command when possible,
      allowing one flow to complete another flow's completion and
      relieve the mailbox before sending its own command.
      Signed-off-by: NTomer Tayar <Tomer.Tayar@cavium.com>
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ed1eea8
  2. 23 3月, 2017 32 次提交