From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Jones Subject: Re: [PATCH v4 05/10] mfd: max77650: new core mfd driver Date: Tue, 12 Feb 2019 13:20:16 +0000 Message-ID: <20190212132016.GA4781@dell> References: <20190205091237.6448-1-brgl@bgdev.pl> <20190205091237.6448-6-brgl@bgdev.pl> <20190212083642.GT20638@dell> <20190212095457.GA20638@dell> <20190212101835.GB20638@dell> <20190212111403.GC20638@dell> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Bartosz Golaszewski Cc: Bartosz Golaszewski , Rob Herring , Mark Rutland , Linus Walleij , Dmitry Torokhov , Jacek Anaszewski , Pavel Machek , Sebastian Reichel , Liam Girdwood , Greg Kroah-Hartman , Linux Kernel Mailing List , "open list:GPIO SUBSYSTEM" , devicetree , Linux Input , Linux LED Subsystem , Linux PM list List-Id: linux-gpio@vger.kernel.org On Tue, 12 Feb 2019, Bartosz Golaszewski wrote: > wt., 12 lut 2019 o 12:14 Lee Jones napisał(a): > > > > On Tue, 12 Feb 2019, Bartosz Golaszewski wrote: > > > > > wt., 12 lut 2019 o 11:18 Lee Jones napisał(a): > > > > > > > > On Tue, 12 Feb 2019, Bartosz Golaszewski wrote: > > > > > > > > > wt., 12 lut 2019 o 10:55 Lee Jones napisał(a): > > > > > > > > > > > > * The declaration of a superfluous struct > > > > > > * 100 lines of additional/avoidable code > > > > > > * Hacky hoop jumping trying to fudge VIRQs into resources > > > > > > * Resources were designed for HWIRQs (unless a domain is present) > > > > > > * Loads of additional/avoidable CPU cycles setting all this up > > > > > > > > > > While the above may be right, this one is negligible and you know it. :) > > > > > > > > You have nested for() loops. You *are* wasting lots of cycles. > > > > > > > > > > Need I go on? :) > > > > > > > > > > > > Surely the fact that you are using both sides of an API > > > > > > (devm_regmap_init_i2c and regmap_irq_get_*) in the same driver, must > > > > > > set some alarm bells ringing? > > > > > > > > > > > > This whole HWIRQ setting, VIRQ getting, resource hacking is a mess. > > > > > > > > > > > > And for what? To avoid passing IRQ data to a child driver? > > > > > > > > > > What do you propose? Should I go back to the approach in v1 and pass > > > > > the regmap_irq_chip_data to child drivers? > > > > > > > > I'm saying you should remove all of this hackery and pass IRQs as they > > > > are supposed to be passed (like everyone else does). > > > > > > I'm not sure what you mean by "like everyone else does" - different > > > mfd drivers seem to be doing different things. Is a simple struct > > > containing virtual irq numbers passed to sub-drivers fine? > > > > How do you plan on deriving the VIRQs to place into the struct? > > Exampe: > > struct max77650_gpio_pdata { > int gpi_irq; > }; > > In MFD driver: > > struct max77650_gpio_pdata *gpio_data = devm_kmalloc(dev, sizeof(*gpio_data)); > > gpio_data->gpi_irq = regmap_irq_get_virq(irqchip_data, GPI_NUM); > > gpio_cell.platform_data = gpio_data; > > In GPIO driver: > > struct max77650_gpio_pdata *gpio_data = pdev->dev.platform_data; > > int irq = gpio_data->gpi_irq; Definitely not. What you're trying to do is a hack. If you're using Regmap to handle your IRQs, then you should use Regmap in the client to pull them out. Setting them via Regmap, then pulling them out again in the *same driver*, only to store them in platform data to be passed to a child device is bonkers. *Either* use the MFD provided platform-data helpers *or* pass and handle them via the Regmap APIs, *not* both. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog