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

Groups > linux.kernel > #1686130 > unrolled thread

Re: [PATCH] firmware: remove request_firmware_into_buf()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] firmware: remove request_firmware_into_buf() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-07-13 01:50 +0200
    Re: [PATCH] firmware: remove request_firmware_into_buf() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-13 09:50 +0200

#1686130 — Re: [PATCH] firmware: remove request_firmware_into_buf()

On Tue, Jun 27, 2017 at 10:37:11AM -0700, Bjorn Andersson wrote:
> On Mon 26 Jun 23:52 PDT 2017, Greg Kroah-Hartman wrote:
> > Why would we keep it if there is no in-tree user for it?  If you want it
> > sometime in the future, great, we can revert the deletion then, but
> > keeping it around for nothing isn't ok, you know that :)
> > 
> 
> Of course I know that :)
> 
> I did put a patch in the tubes for this yesterday [1], it's late for
> v4.13, but I would be happy to see the API stay and we would have a user
> in v4.14 (and tick this off Qualcomm's "required" list).
> 
> [1] https://lkml.org/lkml/2017/6/26/693

Greg,

What have you decided to do?

Also what is the threshold for number of drivers to use a new feature for us to
add it? Note that there is a bundle of features queued up now and as per your
own preference it would seem you want a new API call for each new feature...

Can you clarify that is what you wish for?
Are you *certain* you want to take this approach?

Note that this patch alone was not sufficient to revert all all the stuff for
request_firmware_into_buf(), there was another patch which added the option to
make caching optional, but it was only used internally. Folks already have a
use case for that though *and* existing upstream drivers already have a use
case for that -- the iwlwifi driver is such a case, as they do their own
caching for its driver.

There are similar features in the pipeline which are minor variations to requests
such as optional requests -- do you *really* expect a new API call then to be
created for minor variations of each major call for say optional requests or
requests for without caching?

I had to think about all these things, so now I ask you to also consider this as well.

I ask how many drivers are needed as users for a feature as I think its important
to be fair for the other features in the pipeline which I did start reviewing
and *do* consider sensible to add support for. This was an example feature which
went in with 0 users at all for a while... and now it seems we only have *one*
user still...

  Luis

[toc] | [next] | [standalone]

#1686333

On Thu, Jul 13, 2017 at 01:44:34AM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 27, 2017 at 10:37:11AM -0700, Bjorn Andersson wrote:
> > On Mon 26 Jun 23:52 PDT 2017, Greg Kroah-Hartman wrote:
> > > Why would we keep it if there is no in-tree user for it?  If you want it
> > > sometime in the future, great, we can revert the deletion then, but
> > > keeping it around for nothing isn't ok, you know that :)
> > > 
> > 
> > Of course I know that :)
> > 
> > I did put a patch in the tubes for this yesterday [1], it's late for
> > v4.13, but I would be happy to see the API stay and we would have a user
> > in v4.14 (and tick this off Qualcomm's "required" list).
> > 
> > [1] https://lkml.org/lkml/2017/6/26/693
> 
> Greg,
> 
> What have you decided to do?

Given that this didn't go in for 4.13-rc1, I figured it was kind of
obvious, I'm waiting to see if a user shows up for this release :)

And it's always trivial to revert a patch to add an api back if someone
does need/want it, so this shouldn't be a big deal to anyone.

> Also what is the threshold for number of drivers to use a new feature for us to
> add it? Note that there is a bundle of features queued up now and as per your
> own preference it would seem you want a new API call for each new feature...

Usually it's a good engineering practice to have 3 users of any
interface to prove that you got the interface correct, right?  But I'm
not making any hard and fast rule here, let's see the patches and judge
it from there...

thanks,

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web