From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750991AbbB1J5q (ORCPT ); Sat, 28 Feb 2015 04:57:46 -0500 Received: from smtp02.smtpout.orange.fr ([80.12.242.124]:19134 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750728AbbB1J5i (ORCPT ); Sat, 28 Feb 2015 04:57:38 -0500 X-ME-Helo: beldin X-ME-Date: Sat, 28 Feb 2015 10:57:36 +0100 X-ME-IP: 109.222.213.148 From: Robert Jarzmik To: Greg Kroah-Hartman , Arnd Bergmann , Lee Jones Cc: Nicolas Pitre , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Daniel Mack , Haojian Zhuang , Samuel Ortiz , Grant Likely , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Russell King - ARM Linux , Dmitry Eremin-Solenikov Subject: Re: [PATCH v4 2/4] mfd: lubbock_cplds: add lubbock IO board References: <20150216130549.GF14545@x1> <1170550770.470129293.1424093248596.JavaMail.root@zimbra1-e1.priv.proxad.net> <20150216162712.GR14545@x1> <87fva5a4i2.fsf@free.fr> <20150217074310.GT14545@x1> <20150218080719.GB5781@x1> <87a9088tam.fsf@free.fr> X-URL: http://belgarath.falguerolles.org/ Date: Sat, 28 Feb 2015 10:57:30 +0100 In-Reply-To: <87a9088tam.fsf@free.fr> (Robert Jarzmik's message of "Fri, 20 Feb 2015 17:02:57 +0100") Message-ID: <87mw3y2wad.fsf@free.fr> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Robert Jarzmik writes: > Hi Arnd and Greg, It's been a week, backlog ping ? > > I have this driver I'm upstreaming, which comes out of > arch/arm/mach-pxa/lubbock.c. As for the reason it is extracted, see submitted > commit [1] for reference. > > The main question is : where does it belong in the kernel ? > > The driver is : > - for the CPLDs on the Lubbock development platform, which is more or less an > old motherboard for Intel Xscale pxa255 SoC (see [2] for more details) > - these CPLDs control : > - interrupt muxing towards the SoC > - several leds > - switches read back > For the whole patch, see [4] > > Lee's position is that it doesn't belong to drivers/mfd, see [3]. > > So where should I submit it ? And more generally, where should CPLDs drivers be > pushed in the kernel tree ? > > If there is no solution, I'll fallback through arch/arm/plat-pxa, not very nice, > but it has to land somewhere, I don't want lubbock to remain broken. > > Cheers. > > -- > Robert > > [1] Reason of extraction / commit message > mfd: lubbock_cplds: add lubbock IO board > > Lubbock () board is the IO motherboard of the Intel PXA25x Development > Platform, which supports the Lubbock pxa25x soc board. > > Historically, this support was in arch/arm/mach-pxa/lubbock.c. When > gpio-pxa was moved to drivers/pxa, it became a driver, and its > initialization and probing happened at postcore initcall. The lubbock > code used to install the chained lubbock interrupt handler at init_irq() > time. > > The consequence of the gpio-pxa change is that the installed chained irq > handler lubbock_irq_handler() was overwritten in pxa_gpio_probe(_dt)(), > removing : > - the handler > - the falling edge detection setting of GPIO0, which revealed the > interrupt request from the lubbock IO board. > > As a fix, move the gpio0 chained handler setup to a place where we have > the guarantee that pxa_gpio_probe() was called before, so that lubbock > handler becomes the true IRQ chained handler of GPIO0, demuxing the > lubbock IO board interrupts. > > This patch moves all that handling to a mfd driver. It's only purpose > for the time being is the interrupt handling, but in the future it > should encompass all the motherboard CPLDs handling : > - leds > - switches > - hexleds > > Signed-off-by: Robert Jarzmik > > [2] Board description by Nicolas >>> The Lubbock is an ancient development board (circa 2003) using a CPLD to >>> multiplex a couple things on the board. I really doubt anyone would >>> reprogram this CPLD at this point. So I'd treat it just like another >>> interrupt controller + random peripherals that will never change. And >>> yes, maybe a more appropriate name is needed. > > [3] Lee's position >>> > I don't think this is correct either. CPLD handling would probably be >>> > slightly less out of place in drivers/misc, but perhaps a new >>> > subsystem for PLDs/CPLDs/FPGAs would be more appropriate >>> > drivers/programmables or similar maybe. >>> > > ... >>> > I'm pretty convinced that it doesn't belong in MFD now, but it doesn't >>> > mean I'm going to leave you on the curb. I'd like to help you get it >>> > into a better home. >>> > >>> > [...] >>> > > Is not only a irqchip because, as explained at the bottom of the commit message, >>> > > quoting myself : >>> > > This patch moves all that handling to a mfd driver. It's only purpose >>> > > for the time being is the interrupt handling, but in the future it >>> > > should encompass all the motherboard CPLDs handling : >>> > > - leds >>> > > - switches >>> > > - hexleds >>> > >>> > I had a conversation about this on IRC yesterday and some good >>> > points/questions were posed. This is a difficult area, because you >>> > can program these things to do whatever you like. Depending on the >>> > 'intention' (and it is only an intention -- someone else can come >>> > along and reprogram these devices on a whim), the CPLD code could live >>> > anywhere. If you wanted to put watchdog functionality in there, then >>> > there is an argument for it to live in drivers/watchdog, etc etc. So >>> > just because the plan is to support a few (i.e. more than one) simple >>> > devices, it doesn't necessarily mean that the handling should be done >>> > in MFD. >>> > >>> > Yesterday I was asked "Are you wanting to restrict drivers in >>> > drivers/mfd to those that make use of MFD_CORE functionality?". My >>> > answer to that was "No, however; I only want devices which >>> > _intrinsically_ operate in multiple subsystems", which these >>> > programmables no not do. >>> > >>> > FYI, you're not on your own here. There is at least one of these >>> > devices in the kernel already and upon a short inspection there >>> > appears to be a number of Out-of-Tree (OoT) drivers out there which >>> > will require a home in Mainline sooner or later. >>> > > > [4] Whole patch > https://lkml.org/lkml/2015/1/24/90 -- Robert From mboxrd@z Thu Jan 1 00:00:00 1970 From: robert.jarzmik@free.fr (Robert Jarzmik) Date: Sat, 28 Feb 2015 10:57:30 +0100 Subject: [PATCH v4 2/4] mfd: lubbock_cplds: add lubbock IO board In-Reply-To: <87a9088tam.fsf@free.fr> (Robert Jarzmik's message of "Fri, 20 Feb 2015 17:02:57 +0100") References: <20150216130549.GF14545@x1> <1170550770.470129293.1424093248596.JavaMail.root@zimbra1-e1.priv.proxad.net> <20150216162712.GR14545@x1> <87fva5a4i2.fsf@free.fr> <20150217074310.GT14545@x1> <20150218080719.GB5781@x1> <87a9088tam.fsf@free.fr> Message-ID: <87mw3y2wad.fsf@free.fr> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Robert Jarzmik writes: > Hi Arnd and Greg, It's been a week, backlog ping ? > > I have this driver I'm upstreaming, which comes out of > arch/arm/mach-pxa/lubbock.c. As for the reason it is extracted, see submitted > commit [1] for reference. > > The main question is : where does it belong in the kernel ? > > The driver is : > - for the CPLDs on the Lubbock development platform, which is more or less an > old motherboard for Intel Xscale pxa255 SoC (see [2] for more details) > - these CPLDs control : > - interrupt muxing towards the SoC > - several leds > - switches read back > For the whole patch, see [4] > > Lee's position is that it doesn't belong to drivers/mfd, see [3]. > > So where should I submit it ? And more generally, where should CPLDs drivers be > pushed in the kernel tree ? > > If there is no solution, I'll fallback through arch/arm/plat-pxa, not very nice, > but it has to land somewhere, I don't want lubbock to remain broken. > > Cheers. > > -- > Robert > > [1] Reason of extraction / commit message > mfd: lubbock_cplds: add lubbock IO board > > Lubbock () board is the IO motherboard of the Intel PXA25x Development > Platform, which supports the Lubbock pxa25x soc board. > > Historically, this support was in arch/arm/mach-pxa/lubbock.c. When > gpio-pxa was moved to drivers/pxa, it became a driver, and its > initialization and probing happened at postcore initcall. The lubbock > code used to install the chained lubbock interrupt handler at init_irq() > time. > > The consequence of the gpio-pxa change is that the installed chained irq > handler lubbock_irq_handler() was overwritten in pxa_gpio_probe(_dt)(), > removing : > - the handler > - the falling edge detection setting of GPIO0, which revealed the > interrupt request from the lubbock IO board. > > As a fix, move the gpio0 chained handler setup to a place where we have > the guarantee that pxa_gpio_probe() was called before, so that lubbock > handler becomes the true IRQ chained handler of GPIO0, demuxing the > lubbock IO board interrupts. > > This patch moves all that handling to a mfd driver. It's only purpose > for the time being is the interrupt handling, but in the future it > should encompass all the motherboard CPLDs handling : > - leds > - switches > - hexleds > > Signed-off-by: Robert Jarzmik > > [2] Board description by Nicolas >>> The Lubbock is an ancient development board (circa 2003) using a CPLD to >>> multiplex a couple things on the board. I really doubt anyone would >>> reprogram this CPLD at this point. So I'd treat it just like another >>> interrupt controller + random peripherals that will never change. And >>> yes, maybe a more appropriate name is needed. > > [3] Lee's position >>> > I don't think this is correct either. CPLD handling would probably be >>> > slightly less out of place in drivers/misc, but perhaps a new >>> > subsystem for PLDs/CPLDs/FPGAs would be more appropriate >>> > drivers/programmables or similar maybe. >>> > > ... >>> > I'm pretty convinced that it doesn't belong in MFD now, but it doesn't >>> > mean I'm going to leave you on the curb. I'd like to help you get it >>> > into a better home. >>> > >>> > [...] >>> > > Is not only a irqchip because, as explained at the bottom of the commit message, >>> > > quoting myself : >>> > > This patch moves all that handling to a mfd driver. It's only purpose >>> > > for the time being is the interrupt handling, but in the future it >>> > > should encompass all the motherboard CPLDs handling : >>> > > - leds >>> > > - switches >>> > > - hexleds >>> > >>> > I had a conversation about this on IRC yesterday and some good >>> > points/questions were posed. This is a difficult area, because you >>> > can program these things to do whatever you like. Depending on the >>> > 'intention' (and it is only an intention -- someone else can come >>> > along and reprogram these devices on a whim), the CPLD code could live >>> > anywhere. If you wanted to put watchdog functionality in there, then >>> > there is an argument for it to live in drivers/watchdog, etc etc. So >>> > just because the plan is to support a few (i.e. more than one) simple >>> > devices, it doesn't necessarily mean that the handling should be done >>> > in MFD. >>> > >>> > Yesterday I was asked "Are you wanting to restrict drivers in >>> > drivers/mfd to those that make use of MFD_CORE functionality?". My >>> > answer to that was "No, however; I only want devices which >>> > _intrinsically_ operate in multiple subsystems", which these >>> > programmables no not do. >>> > >>> > FYI, you're not on your own here. There is at least one of these >>> > devices in the kernel already and upon a short inspection there >>> > appears to be a number of Out-of-Tree (OoT) drivers out there which >>> > will require a home in Mainline sooner or later. >>> > > > [4] Whole patch > https://lkml.org/lkml/2015/1/24/90 -- Robert