[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1246803604.3898.6.camel@deadeye>
Date: Sun, 05 Jul 2009 15:20:04 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Sarveshwar Bandi <sarveshwarb@...verengines.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH] be2net: Implementation of request_firmware interface.
On Sun, 2009-07-05 at 17:46 +0530, Sarveshwar Bandi wrote:
> I understand that most drivers use request_firmware() to load volatile
> firmware. I do see that there are other nic drivers that use this inferface to
> flash persistent firmware.
>
> We have other tools for offline flashing; but there is requirement
> to flash f/w through driver without having to use other proprietary tools.
The firmware blob is proprietary and has to be distributed separately
from the kernel. So does it really matter that you have to distribute a
special tool as well?
(Based on requirements specified by major OEMs, I have implemented
firmware update through the sfc driver (MDIO and MTD interfaces) but
under the control of a separate tool.)
> Since the firmware load happens only when there is a version mismatch with
> f/w in /lib/firmware, Users who want to avoid automatic flashing at boot time
> can choose not to copy the f/w file under /lib/firmware.
[...]
Is there a way of loading the firmware into the controller's RAM but not
writing it to flash? That ought to be the default behaviour.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists