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? John -- John W. Linville Someday the world will need a hero, and you linville@xxxxxxxxxxxxx might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
