From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751710AbdA0Veq (ORCPT ); Fri, 27 Jan 2017 16:34:46 -0500 Received: from mx2.suse.de ([195.135.220.15]:49054 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616AbdA0Ve2 (ORCPT ); Fri, 27 Jan 2017 16:34:28 -0500 Date: Fri, 27 Jan 2017 22:34:22 +0100 From: "Luis R. Rodriguez" To: Linus Torvalds Cc: "Luis R. Rodriguez" , Greg KH , Ming Lei , Borislav Petkov , Daniel Wagner , Tom Gundersen , Mauro Carvalho Chehab , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , Linux Kernel Mailing List , Vikram Mulukutla , Stephen Boyd , Mark Brown , Mimi Zohar , Takashi Iwai , Johannes Berg , Christian Lamparter , Hauke Mehrtens , Josh Boyer , Dmitry Torokhov , David Woodhouse , Jiri Slaby , Andy Lutomirski , Wu Fengguang , Richard Purdie , Jacek Anaszewski , Abhay_Salunke@dell.com, Julia Lawall , Gilles.Muller@lip6.fr, nicolas.palix@imag.fr, David Howells , Bjorn Andersson , arend.vanspriel@broadcom.com, Kalle Valo Subject: Re: [PATCH v4 3/3] p54: convert to sysdata API Message-ID: <20170127213422.GD24047@wotan.suse.de> References: <20161216114632.22559-1-mcgrof@kernel.org> <20170112150244.12700-1-mcgrof@kernel.org> <20170112150244.12700-4-mcgrof@kernel.org> <20170119113857.GQ28024@kroah.com> <20170119162751.GJ13946@wotan.suse.de> <20170126215005.GU13946@wotan.suse.de> <20170127182333.GB24047@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Fri, Jan 27, 2017 at 12:53:38PM -0800, Linus Torvalds wrote: > On Fri, Jan 27, 2017 at 10:23 AM, Luis R. Rodriguez wrote: > >> So I'm really not seeing why you want to make these conversions that > >> just make code worse. > > > > The real goal here was first to actually provide a flexible API to enable > > more advanced features to be added without having to affect existing > > callers, as has been done before. > > So I've said this before, and I'll say this one more time: > > It's fine if we make the internal implementation of some generic "load > data from the filesystem or user" be this kind of new flexible API > that is internally called "driver_data_request()" or whatever. > > But dammit, that is NOT AN EXCUSE for then making crap patches that > just replace the existing firmware users. Works with me. > If the new interface cannot be wrapped in the old names (and the old > semantics) the new interface is shit and should never ever go > anywhere. There's a few questionable things part of the old API which (UMH lock is one used even if no UMH is used, the fallback mechanism another) so I've taken out what I can truly vouch for and its all being shared on the driver_data API. Extending the old API with yet-more flags is a big concern on my part so will also recommend new functionality to be focused on the newer API. > So leave the existing users alone. Concentrate on _only_ the parts > where there is actual and real need of new features. Don't try to > rename or extend current drivers. Don't send out these patches that > make drivers actively uglier. Really. Right on. Luis