Skip to content
  1. Mar 24, 2017
    • Mintz, Yuval's avatar
      qed: Correct endian order of MAC passed to MFW · 17991002
      Mintz, Yuval authored
      
      
      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: default avatarYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17991002
    • Tomer Tayar's avatar
      qed: Pass src/dst sizes when interacting with MFW · 2f67af8c
      Tomer Tayar authored
      
      
      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: default avatarTomer Tayar <Tomer.Tayar@cavium.com>
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f67af8c
    • Tomer Tayar's avatar
      qed: Revise MFW command locking · 4ed1eea8
      Tomer Tayar authored
      
      
      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: default avatarTomer Tayar <Tomer.Tayar@cavium.com>
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4ed1eea8
  2. Mar 23, 2017