Re: Firmware versioning best practices

["Luis R. Rodriguez" <mcgrof@gmail.com>]

On Mon, Sep 28, 2009 at 4:42 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Mon, Sep 28, 2009 at 04:52:17PM -0700, Marcel Holtmann wrote:
>> Hi Luis,
>>
>> > The ath_hif_usb driver will require the ar9271 firmware file but in
>> > the future an open firmware might become available. The ar9170 driver
>> > already is under the same situation already: a closed firmware is
>> > available but an open firmware can be used, only thing is ar9170 uses
>> > the same firmware name for both. We *could* change ar9170 to use the
>> > Intel practice of tagging a version at the end of each firmware
>> > release, like ar9170-1.fw but ar9170 originally was implemented with a
>> > 2-stage firmware requirement and so ar9170-1.fw is already taken.
>> >
>> > ar9170 still needs a solution for the different firmwares, once we
>> > start supporting the open firmware through some sort of release but
>> > I'd like to address ath_hif_usb now early so that we don't run into
>> > these snags and use some decent convention that is easy to follow.
>> >
>> > As I noted above, Intel seems to use the device-1.fw, device-2.fw
>> > naming convention. Is this the best approach? Or shall we have the
>> > same firmware filename and simply query the firmware for a map of
>> > capabilities? Any other ideas?
>>
>> the general rule of thumb is that if you break the firmware API/ABI or
>> change it then the firmware name should be different. So for example if
>> you have some new driver functionality that requires new firmware then
>> you better use a new firmware name. Otherwise it is just fine to use the
>> same name if the functionality is not changing. If you can actually
>> detect the new firmware features from the firmware filename, then you
>> might not even have to bother with a different name. However keep in
>> mind that you still need to load at least the previous version of the
>> firmware and keep that working.
>>
>> For open source firmware vs binary blobs, we don't really have a good
>> reference. In theory the driver should always try loading both and if
>> one succeeds then go with it. At no point the driver should stop working
>> only because a firmware is missing while either an open source or binary
>> one for that matter would have been available.
>>
>> If you have a binary and an open source available, then you might wanna
>> have a Kconfig option which to try first. Like prefer the open source
>> over the binary one, but at the end of the day most system will ship
>> with only one anyway. And a module parameter would work here as well.
>
> This seems like a good piece of advise (as does Pavel's).  Perhaps
> someone should capture this on the wiki?

I just did that as I had to dig this old e-mail to help someone with
this information. I'll send out another e-mail for wider review on
lkml.

  Luis