On Tue, Mar 13, 2018 at 03:39:23PM +0200, Kalle Valo wrote:
"Luis R. Rodriguez" <mcgrof@xxxxxxxxxx> writes:
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.
TBH I doubt we would use this kind of "range" request in ath10k,
Well it doesn't have the form to use a range either so it wouldn't make sense.
the
current code works just fine only if we can get rid of the annoying
warning from request_firmware(). Unless if it's significantly faster or
something.
Thanks, I see ath10k uses the sync request_firmware() call, so indeed it
would be a trivial conversion.
Andres can you roll that in for your patch series?
Luis