Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1708898

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

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH V5 1/2] firmware: add more flexible request_firmware_async function Rafał Miłecki <zajec5@gmail.com> - 2017-07-31 17:20 +0200
  Re: [PATCH V5 1/2] firmware: add more flexible  request_firmware_async function kbuild test robot <lkp@intel.com> - 2017-08-01 01:10 +0200
  Re: [PATCH V5 1/2] firmware: add more flexible  request_firmware_async function "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-08-02 23:40 +0200
    Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function Kalle Valo <kvalo@codeaurora.org> - 2017-08-03 07:30 +0200
      Re: [PATCH V5 1/2] firmware: add more flexible  request_firmware_async function "Coelho, Luciano" <luciano.coelho@intel.com> - 2017-08-03 08:00 +0200
        Re: [PATCH V5 1/2] firmware: add more flexible  request_firmware_async function "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-08-03 18:40 +0200
        Re: [PATCH V5 1/2] firmware: add more flexible  request_firmware_async function "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-08-10 19:10 +0200
      Re: [PATCH V5 1/2] firmware: add more flexible  request_firmware_async function "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-08-10 19:10 +0200

csiph-web