Skip to content

GitLab

Switch branch/tag
  1. 05 Mar, 2010 1 commit
  3. 17 Jan, 2010 6 commits
  5. 06 Jan, 2010 1 commit
  7. 09 Dec, 2009 1 commit
  9. 30 Oct, 2009 2 commits
  11. 15 Oct, 2009 2 commits
    • Eilon Greenstein's avatar
      bnx2x: Allowing 0 as initial fairness value · 49e4e9da
      Eilon Greenstein authored 
      

Value of zero was used to disable the fairness mechanism. Though the code
(driver and FW) allowed changing the value at run time, it did not allow to do
that if the mechanism was disabled to begin with.
Fixed the FW to allow turning on and off the mechanism at run time. Fixed the
code to read the value from the chip at the right sequence.
Without this fix, if the initial value was set to zero, traffic could not run on
the interface.
Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49e4e9da
    • Eilon Greenstein's avatar
      bnx2x: Allowing 0 as initial fairness value · 1528f320
      Eilon Greenstein authored 
      

Value of zero was used to disable the fairness mechanism. Though the code
(driver and FW) allowed changing the value at run time, it did not allow to do
that if the mechanism was disabled to begin with.
Fixed the FW to allow turning on and off the mechanism at run time. Fixed the
code to read the value from the chip at the right sequence.
Without this fix, if the initial value was set to zero, traffic could not run on
the interface.
Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1528f320
  13. 13 Oct, 2009 1 commit
  15. 05 Oct, 2009 2 commits
  17. 15 Sep, 2009 1 commit
  19. 30 Aug, 2009 2 commits
    • Ben Hutchings's avatar
      radeon: Use request_firmware() · e292590b
      Ben Hutchings authored 
      

Loosely based on a patch by
Jaswinder Singh Rajput <jaswinderlinux@gmail.com>.

KMS support by Dave Airlie <airlied@redhat.com>.

For Radeon 100- to 500-series, firmware blobs look like:
    struct {
        __be32 datah;
        __be32 datal;
    } cp_ucode[256];

For Radeon 600-series, there are two separate firmware blobs:
    __be32 me_ucode[PM4_UCODE_SIZE * 3];
    __be32 pfp_ucode[PFP_UCODE_SIZE];

For Radeon 700-series, likewise:
    __be32 me_ucode[R700_PM4_UCODE_SIZE];
    __be32 pfp_ucode[R700_PFP_UCODE_SIZE];
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      e292590b
    • Ben Hutchings's avatar
      radeon: Use request_firmware() · 9715b36e
      Ben Hutchings authored 
      

Loosely based on a patch by
Jaswinder Singh Rajput <jaswinderlinux@gmail.com>.

KMS support by Dave Airlie <airlied@redhat.com>.

For Radeon 100- to 500-series, firmware blobs look like:
    struct {
        __be32 datah;
        __be32 datal;
    } cp_ucode[256];

For Radeon 600-series, there are two separate firmware blobs:
    __be32 me_ucode[PM4_UCODE_SIZE * 3];
    __be32 pfp_ucode[PFP_UCODE_SIZE];

For Radeon 700-series, likewise:
    __be32 me_ucode[R700_PM4_UCODE_SIZE];
    __be32 pfp_ucode[R700_PFP_UCODE_SIZE];
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      9715b36e
  21. 27 Aug, 2009 4 commits
  23. 21 Aug, 2009 1 commit
  25. 17 Aug, 2009 1 commit
  27. 05 Aug, 2009 1 commit
  29. 09 Jul, 2009 1 commit
  31. 08 Jul, 2009 1 commit
  33. 01 Jul, 2009 1 commit
  35. 04 Jun, 2009 1 commit
  37. 14 May, 2009 2 commits
  39. 02 May, 2009 1 commit
  41. 27 Apr, 2009 1 commit
    • Vladislav Zolotarov's avatar
      bnx2x: Separated FW from the source. · 0eae2a4d
      Vladislav Zolotarov authored 
      

>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: default avatarVladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0eae2a4d
  43. 23 Apr, 2009 1 commit
  45. 22 Apr, 2009 2 commits
  47. 21 Apr, 2009 1 commit
  49. 13 Apr, 2009 1 commit
  51. 07 Apr, 2009 1 commit
    • David Woodhouse's avatar
      firmware: Remove newly-added slicoss and sxg firmware images · ed7331ed
      David Woodhouse authored 
      

These are available elsewhere (for example in the linux-firmware.git
repository); they have no business being added to the kernel source
tree.

We are only putting stuff in the firmware/ directory of the kernel
source when it's extracted from long-standing drivers which used to
include it directly.

We didn't intend to open the floodgates to including megabytes of new
firmware which was previously being distributed separately.
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      ed7331ed