Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Thu, Aug 03, 2017 at 05:55:18AM +0000, Coelho, Luciano wrote:
> On Thu, 2017-08-03 at 08:23 +0300, Kalle Valo wrote:
> > "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
> > 
> > > > +int request_firmware_nowait(struct module *module, bool uevent,
> > > > +			    const char *name, struct device *device, gfp_t gfp,
> > > > +			    void *context,
> > > > +			    void (*cont)(const struct firmware *fw, void *context))
> > > > +{
> > > > +	unsigned int opt_flags = FW_OPT_FALLBACK |
> > > > +		(uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
> > > > +
> > > > +	return __request_firmware_nowait(module, opt_flags, name, device, gfp,
> > > > +					 context, cont);
> > > > +}
> > > >  EXPORT_SYMBOL(request_firmware_nowait);
> > > >  
> > > > +int __request_firmware_async(struct module *module, const char *name,
> > > > +			     struct firmware_opts *fw_opts, struct device *dev,
> > > > +			     void *context,
> > > > +			     void (*cont)(const struct firmware *fw, void *context))
> > > > +{
> > > > +	unsigned int opt_flags = FW_OPT_UEVENT;
> > > 
> > > This exposes a long issue. Think -- why do we want this enabled by default? Its
> > > actually because even though the fallback stuff is optional and can be, the uevent
> > > internal flag *also* provides caching support as a side consequence only. We
> > > don't want to add a new API without first cleaning up that mess.
> > > 
> > > This is a slipery slope and best to clean that up before adding any new API.
> > > 
> > > That and also Greg recently stated he would like to see at least 3 users of
> > > a feature before adding it. Although I think that's pretty arbitrary, and
> > > considering that request_firmware_into_buf() only has *one* user -- its what
> > > he wishes.
> > 
> > ath10k at least needs a way to silence the warning for missing firmware
> > and I think iwlwifi also.
> 
> Yes, iwlwifi needs to silence the warning.  It the feature (only one,
> really) that I've been waiting for.

Luca,

can you confirm? The API revision thing is one thing but as I noted to
Kalle that can be done using a different API scheme as I had proposed on
the driver data API.

Other than that are there specific firmware requests which are async which
are not API revision style (min...max) for which an async request is optional?

 Luis