On Sat, Mar 10, 2018 at 6:35 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > You also I take it have users in > mind? I'd like to see at least one user of the API or this fixing a > reported issue. Ie, if users have reported this as issues incorrectly, > referring to those incorrect posts as issues and how this created > confusion would help. 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. The old up on that front was that the firmware API was in a huge state of flux and debate about *how* we'd evolve the API, either through a data driven API or functional driven API, ie whether or not we'd add a flexible one API call with a set of options, or keep extending functionality with new exported symbols per use case. The later is how we'd keep evolving the API as such the way you are doing it is fine. Ie, if there is a use case for an optional firmware also for the async case a new API call will have to be made. As stupid as this sounds. Also please take a look at lib/test_firmware.c -- I don't think it makes sense to add a new test case for this API call, so at least worth documenting why somewhere if you find a suitable place for that. Also - I forgot to ask you to extend the Documentation/driver-api/firmware/ documentation accordingly. Please do that. Luis
