Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751614AbbGMQ1R (ORCPT ); Mon, 13 Jul 2015 12:27:17 -0400 Received: from mail-yk0-f179.google.com ([209.85.160.179]:35227 "EHLO mail-yk0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792AbbGMQ1P (ORCPT ); Mon, 13 Jul 2015 12:27:15 -0400 MIME-Version: 1.0 In-Reply-To: References: <1436711211-18223-1-git-send-email-robh@kernel.org> <1436711211-18223-7-git-send-email-robh@kernel.org> From: Rob Herring Date: Mon, 13 Jul 2015 11:26:55 -0500 X-Google-Sender-Auth: jswsQjgd0s8mzHU8J534AcrhAPw Message-ID: Subject: Re: [PATCH v2 06/13] irqchip: kill off set_irq_flags usage To: Thomas Gleixner Cc: "linux-arm-kernel@lists.infradead.org" , Russell King , "linux-kernel@vger.kernel.org" , "arm@kernel.org" , Jason Cooper , Kukjin Kim , Krzysztof Kozlowski , Stephen Warren , Lee Jones , Alexander Shiyan , Maxime Ripard , "linux-samsung-soc@vger.kernel.org" , linux-rpi-kernel@lists.infradead.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3257 Lines: 103 On Sun, Jul 12, 2015 at 11:43 AM, Thomas Gleixner wrote: > On Sun, 12 Jul 2015, Rob Herring wrote: > >> set_irq_flags is ARM specific with custom flags which have genirq >> equivalents. Convert drivers to use the genirq interfaces directly, so we >> can kill off set_irq_flags. The translation of flags is as follows: >> >> IRQF_VALID -> !IRQ_NOREQUEST >> IRQF_PROBE -> !IRQ_NOPROBE >> IRQF_NOAUTOEN -> IRQ_NOAUTOEN >> >> For IRQs managed by an irqdomain, the irqdomain core code handles clearing >> and setting IRQ_NOREQUEST already, so there is no need to do this in >> .map() functions and we can simply remove the set_irq_flags calls. Some >> users also set IRQ_NOPROBE and this has been maintained although it is not > > clear IRQ_NOPROBE, right? Both set and clear really. The state of IRQ_NOPROBE is a don't care in most cases as you have outlined below. Are the cases of setting IRQ_NOPROBE really needed or simply a bunch of copy and paste? I've noticed I have a few places wrong with probe setting though, so I'll be sending a v3. >> clear that is really needed. There appears to be a great deal of blind >> copy and paste of this code. > > Looking at the irq probe users: > > drivers/input/touchscreen/ucb1400_ts.c > drivers/mfd/ucb1x00-core.c > > The probe function was added in the initial implementation of the > driver (2006), so it predates device tree. We still have lots of platforms which are not (and probably never will be) DT. Certainly, DT only irqchips should be easy to make consistent. The older stuff is harder and not frequently tested. > drivers/net/appletalk/ltpc.c > drivers/net/arcnet/com20020-isa.c > drivers/net/arcnet/com90io.c > drivers/net/arcnet/com90xx.c > > Surely not stuff you find on todays ARM systems > > drivers/net/ethernet/8390/ne.c > drivers/net/ethernet/8390/wd.c > drivers/net/ethernet/amd/lance.c > drivers/net/ethernet/amd/ni65.c > drivers/net/ethernet/amd/pcnet32.c > > Ditto > > drivers/net/ethernet/smsc/smc911x.c > drivers/net/ethernet/smsc/smc9194.c > drivers/net/ethernet/smsc/smc91x.c > > Those might still be, but on the DT based boards the probing should be > completely irrelevant Yes, these are quite common on ARM boards, and probably few if any rely on irq probing regardless of DT. > drivers/net/hamradio/dmascc.c > drivers/net/wan/cosa.c > drivers/net/wan/sbni.c > drivers/parport/parport_pc.c > > Surely not stuff you find on todays ARM systems > > drivers/pcmcia/yenta_socket.c > > Russell might still use that. > > drivers/scsi/NCR53c406a.c > drivers/scsi/sym53c416.c > drivers/tty/cyclades.c > > Surely not stuff you find on todays ARM systems > > drivers/tty/serial/8250/8250_core.c > > The irq probing is used by > > mach-imx/mach-mx31ads.c > mach-iop32x/n2100.c > > and X86 > > So in most of the irqchip drivers, this is irrelevant. Agreed, but that's a separate series I think. I'm trying not to change behavior with this series. Are you proposing I do something different with this patch? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/