Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751846AbdGLXon (ORCPT ); Wed, 12 Jul 2017 19:44:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:46529 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751384AbdGLXom (ORCPT ); Wed, 12 Jul 2017 19:44:42 -0400 Date: Thu, 13 Jul 2017 01:44:34 +0200 From: "Luis R. Rodriguez" To: Greg Kroah-Hartman , Bjorn Andersson Cc: "Luis R. Rodriguez" , Daniel Wagner , David Woodhouse , rafal@milecki.pl, Arend van Spriel , "Rafael J. Wysocki" , yi1.li@linux.intel.com, atull@kernel.org, Moritz Fischer , pmladek@suse.com, Johannes Berg , emmanuel.grumbach@intel.com, luciano.coelho@intel.com, Kalle Valo , luto@kernel.org, Linus Torvalds , Kees Cook , "AKASHI, Takahiro" , David Howells , pjones@redhat.com, Hans de Goede , alan@linux.intel.com, tytso@mit.edu, lkml Subject: Re: [PATCH] firmware: remove request_firmware_into_buf() Message-ID: <20170712234434.GA21846@wotan.suse.de> References: <20170623160321.GA19720@kroah.com> <20170627065253.GB29909@kroah.com> <20170627173711.GJ18666@tuxbook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170627173711.GJ18666@tuxbook> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2095 Lines: 47 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