| Message ID | 1444338557-14988-1-git-send-email-mpe@ellerman.id.au (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
On Friday 09 October 2015 08:09:12 Michael Ellerman wrote: > Currently the NR_IRQS option sits at the top level, which is ugly in > menuconfig. It's not something users will commonly need to worry about > so move it into "Kernel Options". > > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> > Is this option actually still meaningful at all, when you select CONFIG_SPARSE_IRQ unconditionally? Arnd
On Thu, 2015-10-08 at 23:30 +0200, Arnd Bergmann wrote: > On Friday 09 October 2015 08:09:12 Michael Ellerman wrote: > > Currently the NR_IRQS option sits at the top level, which is ugly in > > menuconfig. It's not something users will commonly need to worry about > > so move it into "Kernel Options". > > Is this option actually still meaningful at all, when you select CONFIG_SPARSE_IRQ > unconditionally? It's still used for #define NR_IRQS, which is still used by the generic irq code and also some drivers. So we need some value for that, whether it needs to be user defined or if we could just pick a value I'm not sure. x86 seem to just define it based on NR_CPUs and some other factors. cheers
On Monday 12 October 2015 21:00:25 Michael Ellerman wrote: > On Thu, 2015-10-08 at 23:30 +0200, Arnd Bergmann wrote: > > On Friday 09 October 2015 08:09:12 Michael Ellerman wrote: > > > Currently the NR_IRQS option sits at the top level, which is ugly in > > > menuconfig. It's not something users will commonly need to worry about > > > so move it into "Kernel Options". > > > > Is this option actually still meaningful at all, when you select CONFIG_SPARSE_IRQ > > unconditionally? > > It's still used for #define NR_IRQS, which is still used by the generic irq > code and also some drivers. Drivers shouldn't use it, and I don't see any driver using it that can be enabled on powerpc. The question is rather whether you have any devices on powerpc that get a hardwired IRQ number from a statically defined platform device rather from DT. If there are any ISA devices, the driver might try to use an interrupt number that is hardcoded in the driver as a number from 0 to 15. I guess that could happen on old CHRP or 6xx machines. > So we need some value for that, whether it needs to be user defined or if we > could just pick a value I'm not sure. x86 seem to just define it based on > NR_CPUs and some other factors. What happens if you set it to 16? Arnd
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 9a7057ec2154..c6f1aa1e8d4c 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -33,16 +33,6 @@ config HAVE_SETUP_PER_CPU_AREA config NEED_PER_CPU_EMBED_FIRST_CHUNK def_bool PPC64 -config NR_IRQS - int "Number of virtual interrupt numbers" - range 32 32768 - default "512" - help - This defines the number of virtual interrupt numbers the kernel - can manage. Virtual interrupt numbers are what you see in - /proc/interrupts. If you configure your system to have too few, - drivers will fail to load or worse - handle with care. - config STACKTRACE_SUPPORT bool default y @@ -321,6 +311,16 @@ config HIGHMEM bool "High memory support" depends on PPC32 +config NR_IRQS + int "Number of virtual interrupt numbers" + range 32 32768 + default "512" + help + This defines the number of virtual interrupt numbers the kernel + can manage. Virtual interrupt numbers are what you see in + /proc/interrupts. If you configure your system to have too few, + drivers will fail to load or worse - handle with care. + source kernel/Kconfig.hz source kernel/Kconfig.preempt source "fs/Kconfig.binfmt"
Currently the NR_IRQS option sits at the top level, which is ugly in menuconfig. It's not something users will commonly need to worry about so move it into "Kernel Options". Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> --- arch/powerpc/Kconfig | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)