firmware: add extensible driver data API
The firmware API does not scale well: when new features are added we
either add a new exported symbol or extend the arguments of existing
routines. For the later case this means we need to traverse the kernel
with a slew of collateral evolutions to adjust old driver users. The
firmware API is also now being used for things outside of the scope of
what typically would be considered "firmware". There are other
subsystems which would like to make use of the firmware APIs for similar
things and its clearly not firmware, but have different requirements
and criteria which they'd like to be met for the requested file.
An extensible API is in order. While reviewing the existing API
the firmware fallback mechansism stands out as requiring more
review before folding forward as such it has been kept out of the
new API.
We purposely try to limit the scope of changes in this new API to
enable a flexible API to start off with as base. The driver data
API accepts that there are only two types of requests:
a) synchronous requests
b) asynchronous requests
Both requests may have a different requirements which must be met. These
requirements can be described in the struct driver_data_req_params.
This struct is expected to be extended over time to support different
requirements as the kernel evolves. Other than providing a flexible API
a few minor features are are introduced:
- By default the kernel will free the driver data file for you after
your callbacks are called, you however are allowed to request that
you wish to keep the driver data file on the requirements params. The
new driver data API is able to free the driver data file for you by
requiring a consumer callback for the driver data file.
- Allows both asynchronous and synchronous request to specify that
driver data files are optional. With the old APIs we had added one
full API call, request_firmware_direct() just for this purpose --
the driver data request APIs allow for you to annotate that a driver
data file is optional for both synchronous or asynchronous requests
through the same two basic set of APIs.
- You no longer need to declare and use your own completions, you
can replace your completions with driver_data_synchronize_request()
using the async_cookie given back by the async driver data call.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
6 files changed
