From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 19 Jul 2017 21:15:15 +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: <20170719211515.46a1196c@windsurf> In-Reply-To: <20170719152646.25903-1-p.zabel@pengutronix.de> References: <20170719152646.25903-1-p.zabel@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII List-ID: Hello, On Wed, 19 Jul 2017 17:25:04 +0200, Philipp Zabel wrote: > The reset control API has two modes: exclusive access, where the driver > expects to have full and immediate control over the state of the reset > line, and shared (clock-like) access, where drivers only request reset > deassertion while active, but don't care about the state of the reset line > while inactive. > > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control behavior. > > This series converts all drivers that currently implicitly request > exclusive reset controls to the corresponding explicit API call. It is, > for the most part, generated from the following semantic patch: > > @@ > expression rstc, dev, id; > @@ > -rstc = reset_control_get(dev, id); > +rstc = reset_control_get_exclusive(dev, id); 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. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com