On Mon, 2015-02-16 at 10:53 +0100, Peter Zijlstra wrote: > On Fri, Feb 13, 2015 at 08:02:17AM +0800, Linus Walleij wrote: > > This function does not conform to the irq_domain* namespace and > > makes it a disturbing artifact dating back to a time when irq > > domains were referred to as "hosts". Rename it.
My little coat of paint on that shed... While I agree with the need to rename it, do we really need to adhere to strict namespaces like that ? It would be a lot nicer to call it irq_set_default_domain() :-) Cheers, Ben. > > Signed-off-by: Linus Walleij <[email protected]> > > --- > > ChangeLog v1->v2: > > - Might as well commit changes I have in the working tree so the > > thing compiles like it did in my tests, d'oh. > > --- > > arch/arc/kernel/irq.c | 2 +- > > arch/arm/mach-pxa/irq.c | 2 +- > > arch/c6x/kernel/irq.c | 2 +- > > arch/microblaze/kernel/intc.c | 2 +- > > arch/mips/cavium-octeon/octeon-irq.c | 4 ++-- > > arch/nios2/kernel/irq.c | 2 +- > > arch/powerpc/platforms/52xx/mpc52xx_pic.c | 2 +- > > arch/powerpc/platforms/amigaone/setup.c | 2 +- > > arch/powerpc/platforms/cell/beat_interrupt.c | 2 +- > > arch/powerpc/platforms/cell/interrupt.c | 2 +- > > arch/powerpc/platforms/chrp/setup.c | 2 +- > > arch/powerpc/platforms/embedded6xx/flipper-pic.c | 2 +- > > arch/powerpc/platforms/powermac/pic.c | 2 +- > > arch/powerpc/platforms/ps3/interrupt.c | 2 +- > > arch/powerpc/sysdev/ehv_pic.c | 2 +- > > arch/powerpc/sysdev/ipic.c | 2 +- > > arch/powerpc/sysdev/mpic.c | 2 +- > > arch/powerpc/sysdev/uic.c | 2 +- > > arch/powerpc/sysdev/xics/xics-common.c | 2 +- > > arch/powerpc/sysdev/xilinx_intc.c | 2 +- > > arch/x86/kernel/apic/io_apic.c | 2 +- > > drivers/irqchip/irq-armada-370-xp.c | 2 +- > > drivers/irqchip/irq-clps711x.c | 2 +- > > drivers/irqchip/irq-mmp.c | 8 ++++---- > > drivers/irqchip/irq-xtensa-mx.c | 4 ++-- > > drivers/irqchip/irq-xtensa-pic.c | 4 ++-- > > include/linux/irqdomain.h | 2 +- > > kernel/irq/irqdomain.c | 14 +++++++------- > > 28 files changed, 40 insertions(+), 40 deletions(-) > > Might it make sense to preserve both functions for one release to avoid > flag day changes and broken compiles? > > Mark one __deprecated and point a comment to the new one, then make sure > nobody is still using it by the next release and remove the old > interface? > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
