[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170713074628.GA3877@kroah.com>
Date: Thu, 13 Jul 2017 09:46:28 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc: Bjorn Andersson <bjorn.andersson@...aro.org>,
Daniel Wagner <wagi@...om.org>,
David Woodhouse <dwmw2@...radead.org>, rafal@...ecki.pl,
Arend van Spriel <arend.vanspriel@...adcom.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>, yi1.li@...ux.intel.com,
atull@...nel.org, Moritz Fischer <moritz.fischer@...us.com>,
pmladek@...e.com, Johannes Berg <johannes.berg@...el.com>,
emmanuel.grumbach@...el.com, luciano.coelho@...el.com,
Kalle Valo <kvalo@...eaurora.org>, luto@...nel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
"AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
David Howells <dhowells@...hat.com>, pjones@...hat.com,
Hans de Goede <hdegoede@...hat.com>, alan@...ux.intel.com,
tytso@....edu, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: remove request_firmware_into_buf()
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
Powered by blists - more mailing lists