On Mon, Sep 28, 2009 at 4:42 PM, John W. Linville <linville@xxxxxxxxxxxxx> 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 -- 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
