Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752927AbdFMLJ4 (ORCPT ); Tue, 13 Jun 2017 07:09:56 -0400 Received: from 1.mo68.mail-out.ovh.net ([46.105.41.146]:53874 "EHLO 1.mo68.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752083AbdFMLJy (ORCPT ); Tue, 13 Jun 2017 07:09:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 13 Jun 2017 12:31:04 +0200 From: =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= To: Greg KH Cc: "Luis R. Rodriguez" , wagi@monom.org, dwmw2@infradead.org, arend.vanspriel@broadcom.com, rjw@rjwysocki.net, yi1.li@linux.intel.com, atull@opensource.altera.com, moritz.fischer@ettus.com, pmladek@suse.com, johannes.berg@intel.com, emmanuel.grumbach@intel.com, luciano.coelho@intel.com, kvalo@codeaurora.org, luto@kernel.org, torvalds@linux-foundation.org, keescook@chromium.org, takahiro.akashi@linaro.org, dhowells@redhat.com, pjones@redhat.com, hdegoede@redhat.com, alan@linux.intel.com, tytso@mit.edu, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 1/5] firmware: add extensible driver data params In-Reply-To: <20170613090548.GA31421@kroah.com> References: <20170605213314.GR8951@wotan.suse.de> <20170605213937.26215-1-mcgrof@kernel.org> <20170605213937.26215-2-mcgrof@kernel.org> <20170613090548.GA31421@kroah.com> Message-ID: <4c7b15d3b9e7853faa0e928a6ab160f2@milecki.pl> User-Agent: Roundcube Webmail/1.2.5 X-Originating-IP: 194.187.74.233 X-Webmail-UserID: rafal@milecki.pl X-Ovh-Tracer-Id: 13763844889764007541 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeljedrjeefgddvlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1667 Lines: 41 On 2017-06-13 11:05, Greg KH wrote: > On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote: >> As the firmware API evolves we keep extending functions with more >> arguments. >> Stop this nonsense by proving an extensible data structure which can >> be used >> to represent both user parameters and private internal parameters. > > Let's take a simple C function interface and make it a more complex > data-driven interface that is impossible to understand and obviously > understand how it is to be used and works! > > :( > > Seriously, why? Why are we extending any of this at all? This series > adds a ton of new "features" and complexity, but for absolutely no > gain. > > Oh, I take it back, you removed 29 lines from the iwlwifi driver. > > That's still not worth it at all, you have yet to sell me on this whole > complex beast. I can't see why we need it, and if I, one of the few > people who thinks they actually understand this kernel interface, can't > see it, how can you sell it to someone else? > > Sorry, but no, I'm still not going to take this series until you show > some _REAL_ benefit for it. FWIW I saw (or maybe still see?) a need to extend request_firmware* API to allow silencing a warning if firmware file is missing. I even sent a trivial patch adding support for this: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function https://patchwork.kernel.org/patch/9588787/ (I think it still applies) but it got rejected due to Luis's big rework. To be honest after seeing this big & more complex driver data API I just gave up and decided I don't care about false problem reports that much :(