Jaswinder Singh wrote:
Firmware blob is big-endian starts with version numbers,
followed by start address and length.
length = end_address_of_bss - start_address_of_text.
Remainder is the blob to be loaded contiguously from start address.
Signed-off-by: Jaswinder Singh <jaswinder@xxxxxxxxxxxxx>
--
drivers/net/Kconfig | 8
drivers/net/tg3.c | 782 ++++-----------------------------------
drivers/net/tg3.h | 4
firmware/Makefile | 2
firmware/WHENCE | 19
firmware/tigon/tg3.bin.ihex | 175 ++++++++
firmware/tigon/tg3_tso.bin.ihex | 446 ++++++++++++++++++++++
firmware/tigon/tg3_tso5.bin.ihex | 252 ++++++++++++
8 files changed, 992 insertions(+), 696 deletions(-)
create mode 100644 firmware/tigon/tg3.bin.ihex
create mode 100644 firmware/tigon/tg3_tso.bin.ihex
create mode 100644 firmware/tigon/tg3_tso5.bin.ihex
Sigh, this has the same problems as the last patch.
* the Kconfig for the firmware should default to 'Y', to make it harder
for users to create a non-working driver.
* request_firmware() capability is clearly and obviously a separate
logical change, and should not be included in the same patch as firmware
separation.
It just makes the patch longer and more difficult to read and review
with the two separate changes mushed together. Having separate patches
also means it is easier to test and validate the loadable firmware approach.
* the firmware should live in the same dir as the driver, just like it
has for its entire lifetime until now. It's silly to create a driver
hierarchy in firmware/ that parallels the rest of the tree
* fedora-rawhide, debian-unstable, and similar targets must already be
prepped for firmware installs (both from the kernel and via external
firmware packages like ipw2200-firmware).
* all net driver patches should get copied to netdev@xxxxxxxxxxxxxxx,
which is where networking changes are discussed
This patch should not create ANY operational differences for users.
Requiring additional steps such as "make firmware_install" in order for
the user to achieve the same working driver as they had in the last
kernel is an example of such a [script-breaking] operational difference.
We have to make it tough for users to screw this up. It's too easy to
create a non-working driver, with request_firmware()... as existing
distro support for firmwares has already proven in the field.
Jeff
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
