From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 20 Jul 2017 12:36:40 +0200 From: Thomas Petazzoni To: Philipp Zabel Cc: linux-kernel@vger.kernel.org, Andrew Lunn , Prashant Gaikwad , Heiko Stuebner , Peter Chen , Linus Walleij , dri-devel@lists.freedesktop.org, Marc Dietrich , Rakesh Iyer , Peter Meerwald-Stadler , linux-clk@vger.kernel.org, Wim Van Sebroeck , Wolfram Sang , Xinliang Liu , Chanwoo Choi , Alan Stern , Jiri Slaby , Michael Turquette , Guenter Roeck , Ohad Ben-Cohen , linux-pm@vger.kernel.org, Thomas Gleixner , Vincent Abriou , Bin Liu , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, Ralf Baechle , linux-spi@vger.kernel.org, linux-crypto@vger.kernel.org, Tejun Heo , alsa-devel@alsa-project.org, linux-doc@vger.kernel.org, David Airlie , nouveau@lists.freedesktop.org, Philippe Cornu , Kalle Valo , Laxman Dewangan , Corentin Labbe , linux-i2c@vger.kernel.org, linux-watchdog@vger.kernel.org, Boris Brezillon , Lars-Peter Clausen , Emilio =?UTF-8?B?TMOzcGV6?= , Daniel Lezcano , Jon Hunter , linux-rockchip@lists.infradead.org, MyungJoo Ham , Ben Skeggs , Yisen Zhuang , linux-media@vger.kernel.org, Richard Zhu , Alexandre Torgue , Mathias Nyman , linux-arm-msm@vger.kernel.org, Joachim Eastwood , linux-gpio@vger.kernel.org, linux-mips@linux-mips.org, Bjorn Helgaas , Giuseppe Cavallaro , linux-arm-kernel@lists.infradead.org, Patrice Chotard , Stanimir Varbanov , Kyungmin Park , Maxime Coquelin , Hartmut Knaack , Jonathan Cameron , Ulf Hansson , linux-iio@vger.kernel.org, linux-pci@vger.kernel.org, Shawn Lin , linux-tegra@vger.kernel.org, linux-mtd@lists.infradead.org, Benjamin Gaignard , Florian Fainelli , Jonathan Corbet , Xinwei Kong , ath10k@lists.infradead.org, Kishon Vijay Abraham I , Chen-Yu Tsai , linux-input@vger.kernel.org, linux-pwm@vger.kernel.org, Chen Feng , Mark Brown , Dan Williams , Felipe Balbi , Salil Mehta , Dmitry Torokhov , linux-mmc@vger.kernel.org, Liam Girdwood , Thierry Reding , Cyrille Pitchen , Srinivas Kandagatla , Maxime Ripard , Brian Norris , "David S. Miller" , linux-remoteproc@vger.kernel.org, Bjorn Andersson , linux-ide@vger.kernel.org, Lee Jones , devel@driverdev.osuosl.org, Yannick Fertre , Ryder Lee , Herbert Xu , Richard Weinberger , Jaehoon Chung , Marek Vasut , linux-serial@vger.kernel.org, Zhang Rui , Alan Tull , John Youn , Eduardo Valentin , dmaengine@vger.kernel.org, linux-mediatek@lists.infradead.org, Matthias Brugger , Mark Yao , Moritz Fischer , Vivien Didelot , netdev@vger.kernel.org, Peter De Schrijver , Stephen Boyd , Adrian Hunter , Vinod Koul , Rongrong Zou , linux-fpga@vger.kernel.org, David Woodhouse , Lucas Stach Subject: Re: [PATCH 000/102] Convert drivers to explicit reset API Message-ID: <20170720123640.43c2ce01@windsurf> In-Reply-To: <1500543415.2354.37.camel@pengutronix.de> References: <20170719152646.25903-1-p.zabel@pengutronix.de> <20170719211515.46a1196c@windsurf> <1500543415.2354.37.camel@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII List-ID: Hello, On Thu, 20 Jul 2017 11:36:55 +0200, Philipp Zabel wrote: > > I don't know if it has been discussed in the past, so forgive me if it > > has been. Have you considered adding a "int flags" argument to the > > existing reset_control_get_*() functions, rather than introducing > > separate exclusive variants ? > > > > Indeed, with a "int flags" argument you could in the future add more > > variants/behaviors without actually multiplying the number of > > functions. Something like the "flags" argument for request_irq() for > > example. > > I can't find the discussion right now, but I remember we had talked > about this in the past. > Behind the scenes, all the inline API functions already call common > entry points with flags (well, currently separate bool parameters for > shared and optional). > One reason against exposing those as an int flags in the user facing API > is the possibility to accidentally provide a wrong value. This is a quite strange argument. You could also accidentally use the wrong variant of the function, just like you could use the wrong flag. Once again, the next time you have another parameter for those reset functions, beyond the exclusive/shared variant, you will multiply again by two the number of functions ? You already have the exclusive/shared and optional/mandatory variants, so 4 variants. When you'll add a new parameter, you'll have 8 variants. Doesn't seem really good. What about reset_control_get(struct device *, const char *, int flags) to replace all those variants ? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com