On Mon, Mar 12, 2018 at 12:10:47AM +0100, Arend van Spriel wrote: > On 3/11/2018 5:05 PM, Andres Rodriguez wrote: > > > Your patch series then should also have the driver callers who you > > > want to modify to use this new API. Collect from the 802.11 folks the > > > other drivers which I think they wanted changed as well. > > > > Arend, Kalle, would love to hear your feedback. > > I am not sure if it was ath10k, but Kalle will surely know. The other driver > firing a whole batch of firmware requests is iwlwifi. These basically try to > get latest firmware version and if not there try an older one. Ah I recall now. At least for iwlwifi its that it requests firmware with a range of api files, and we don't need information about files in the middle not found, given all we need to know if is if at lest one file was found or not. I have future code to also enable use of a range request which would replace the recursive nature of iwlwifi's firmware API request, so it simplifies it considerably. Once we get this flag to be silent in, this can be used later. Ie, the new API I'd add would replace the complex api revision thing for an internal set. > The brcmfmac driver I maintain is slightly different. It downloads two > distinct pieces of firmware of which one is optional for certain > configurations. Currently, my driver does two asynchronous requests for it, > but I consider changing it and only make the first request asynchronous and > the second request synchronous. You can look at the current code in > drivers/net/wireless/broadcom/brcmfmac/firmware.c. However, I did quite some > restructuring last week. Anyway, I probably will end up using the "optional" > api where appropriate. Thanks for the details. Luis
