1. 27 4月, 2009 1 次提交
    • V
      bnx2x: Separated FW from the source. · 94a78b79
      Vladislav Zolotarov 提交于
      >From now on FW will be downloaded from the binary file using request_firmware.
      
      There will be different files for every supported chip. Currently 57710 (e1) and
      57711 (e1h).
      
      File names have the following format: bnx2x-<chip version>-<FW version>.fw.
      ihex versions of current FW files are submitted in the next patch.
      
      Each binary file has a header in the following format:
      
      
      struct bnx2x_fw_file_section {
      	__be32 len;
      	__be32 offset;
      }
      
      struct bnx2x_fw_file_hdr {
      	struct bnx2x_fw_file_section init_ops;
      	struct bnx2x_fw_file_section init_ops_offsets;
      	struct bnx2x_fw_file_section init_data;
      	struct bnx2x_fw_file_section tsem_int_table_data;
      	struct bnx2x_fw_file_section tsem_pram_data;
      	struct bnx2x_fw_file_section usem_int_table_data;
      	struct bnx2x_fw_file_section usem_pram_data;
      	struct bnx2x_fw_file_section csem_int_table_data;
      	struct bnx2x_fw_file_section csem_pram_data;
      	struct bnx2x_fw_file_section xsem_int_table_data;
      	struct bnx2x_fw_file_section xsem_pram_data;
      	struct bnx2x_fw_file_section fw_version;
      }
      
      Each bnx2x_fw_file_section contains the length and the offset of the appropriate
      section in the binary file. Values are stored in the big endian format.
      
      Data types of arrays:
      
      init_data            __be32
      init_ops_offsets     __be16
      XXsem_pram_data         u8
      XXsem_int_table_data    u8
      init_ops             struct raw_op {
                                u8   op;
      			__be24 offset;
                              __be32 data;
      		     }
      fw_version              u8
      
      >From now boundaries of a specific initialization stage are stored in
      init_ops_offsets array instead of being defined by separate macroes. The index 
      in init_ops_offsets is calculated by BLOCK_OPS_IDX macro:
      
      #define BLOCK_OPS_IDX(block, stage, end) \
             (2*(((block)*STAGE_IDX_MAX) + (stage)) + (end))
      
      Security:
      
      In addition to sanity check of array boundaries bnx2x will check a FW version.
      Additional checks might be added in the future.
      Signed-off-by: NVladislav Zolotarov <vladz@broadcom.com>
      Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94a78b79
  2. 10 3月, 2009 1 次提交
  3. 16 2月, 2009 19 次提交
  4. 20 1月, 2009 2 次提交
  5. 16 1月, 2009 4 次提交
  6. 04 9月, 2008 1 次提交
    • E
      bnx2x: Accessing un-mapped page · 437cf2f1
      Eilon Greenstein 提交于
      The allocated RX buffer size was 64 bytes bigger than the PCI mapped
      size with no good reason. If the packet was actually using the buffer up
      to its limit and if the last 64 bytes of the buffer crossed 4KB boundary
      then an unmapped PCI page was accessed. The fix is to use only one
      parameter for the buffer size - there is no need to differentiate
      between the buffer size and the PCI mapping size since the extra 64
      bytes can actually be used by the FW to align the Ethernet payload to
      64 bytes.
      
      Also updating the driver version and date
      Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      437cf2f1
  7. 26 8月, 2008 1 次提交
    • E
      bnx2x: Rx work check · 2772f903
      Eilon Greenstein 提交于
      The has Rx work check was wrong: when the FW was at the end of the page,
      the driver was already at the beginning of the next page. Since the
      check only validated that both driver and FW are pointing to the same
      place, it concluded that there is still work to be done. This caused
      some serious issues including long latency results on ping-pong test and
      lockups while unloading the driver in that condition.
      Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2772f903
  8. 14 8月, 2008 9 次提交
  9. 24 6月, 2008 2 次提交