Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754730AbdFXMkB (ORCPT ); Sat, 24 Jun 2017 08:40:01 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:54066 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751055AbdFXMkA (ORCPT ); Sat, 24 Jun 2017 08:40:00 -0400 Date: Sat, 24 Jun 2017 14:39:51 +0200 From: Greg KH To: "Luis R. Rodriguez" Cc: Linus Torvalds , Julia Lawall , Daniel Wagner , David Woodhouse , rafal@milecki.pl, Arend Van Spriel , "Rafael J. Wysocki" , "Li, Yi" , atull@opensource.altera.com, Moritz Fischer , Petr Mladek , Johannes Berg , Emmanuel Grumbach , "Coelho, Luciano" , Kalle Valo , Andrew Lutomirski , Jiri Kosina , Kees Cook , "AKASHI, Takahiro" , David Howells , Peter Jones , Hans de Goede , Alan Cox , "Theodore Ts'o" , NeilBrown , Christoph Hellwig , Linux Kernel Mailing List Subject: Re: [PATCH v9 1/5] firmware: add extensible driver data params Message-ID: <20170624123951.GA10622@kroah.com> References: <20170605213937.26215-1-mcgrof@kernel.org> <20170605213937.26215-2-mcgrof@kernel.org> <20170613090548.GA31421@kroah.com> <20170613194011.GI27288@wotan.suse.de> <20170617193815.GI2974@kroah.com> <20170619193522.GH21846@wotan.suse.de> <20170623155123.GB3565@kroah.com> <20170623224338.GX21846@wotan.suse.de> <20170624004828.GA21846@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170624004828.GA21846@wotan.suse.de> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2288 Lines: 50 On Sat, Jun 24, 2017 at 02:48:28AM +0200, Luis R. Rodriguez wrote: > On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote: > > On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez wrote: > > > > > > Ah, yes! Here is what I believe seems to be the *crux* issue of these patch > > > series and I'm happy we have finally landed on it. Yes, indeed the new API > > > proposed here provides more flexibility, and it does so by embracing a > > > "data driven" API Vs the traditional procedural APIs we have seen for > > > *the firmware API*. > > > > This has been going on forever. Everybody hates your data-driven one. > > Before you, the only person who had expressed disdain here was Greg. Very few people actually review code, you know that. > > Things like that may be ok as an internal implementation, but even > > there it's questionable if it then means a big disconnect between what > > people actually use (the normal functional model) and the > > implementation. > > A vendor tree implemented their *own* solution and were willing to maintain > it despite this likely making it hard to port stable fixes. That I think says > a lot for a need... What vendor tree? Where was it shipped? Why was it external and how is it different from your patches? Was it used because your version has taken so long to be submitted/reviwed? > There are still other requirements and features in the pipeline for which we > can consider parameters to parse for, rather than adding new API. Case in > point, do we want *one* API just to disable the firmware cache? Specially > knowing that another feature in the pipeline later would make use of this as a > requirement? Again, I do not care! You can not justify patches today with some mythical thing in the future that might never even happen. Again, as it stands, this patch series is unacceptable, and the added complexity of a crazy api that goes against almost all normal in-kernel apis, is only one part of the reason. The other being the loads of added code for no apparent benifit at all. So please both fix the api to be "normal", and show as to why these patches are actually needed _today_, otherwise we can just live with what we have now just fine and muddle along like always. thanks, greg k-h