| Message ID | 20110614190850.GA13526@linux-mips.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Tuesday 14 June 2011 21:08:50 Ralf Baechle wrote: > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 9adc278..2968751f 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -21,6 +21,7 @@ config ARM > select HAVE_KERNEL_LZO > select HAVE_KERNEL_LZMA > select HAVE_IRQ_WORK > + select HAVE_PC_PARPORT > select HAVE_PERF_EVENTS > select PERF_USE_VMALLOC > select HAVE_REGS_AND_STACK_ACCESS_API On arm that should only be set on a couple of subarchitectures, but we can fan that out after your patch goes in, just like you do for Mips > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 2729c66..b8328df 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -128,6 +128,7 @@ config PPC > select HAVE_REGS_AND_STACK_ACCESS_API > select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64 > select HAVE_GENERIC_HARDIRQS > + select HAVE_PC_PARPORT > select HAVE_SPARSE_IRQ > select IRQ_PER_CPU > select GENERIC_IRQ_SHOW Similar to ARM and Mips. > index e446bab..ceac9b5 100644 > --- a/arch/microblaze/Kconfig > +++ b/arch/microblaze/Kconfig > @@ -15,6 +15,7 @@ config MICROBLAZE > select OF > select OF_EARLY_FLATTREE > select HAVE_GENERIC_HARDIRQS > + select HAVE_PC_PARPORT > select GENERIC_IRQ_PROBE > select GENERIC_IRQ_SHOW > Highly unlikely, except through PCI. > diff --git a/arch/score/Kconfig b/arch/score/Kconfig > index 288add8..ba078d0 100644 > --- a/arch/score/Kconfig > +++ b/arch/score/Kconfig > @@ -1,9 +1,10 @@ > menu "Machine selection" > > config SCORE > - def_bool y > - select HAVE_GENERIC_HARDIRQS > - select GENERIC_IRQ_SHOW > + def_bool y > + select HAVE_GENERIC_HARDIRQS > + select HAVE_PC_PARPORT > + select GENERIC_IRQ_SHOW > > choice > prompt "System type" Certainly not, no PIO support > diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig > index 0249b8b..3e96eff 100644 > --- a/arch/tile/Kconfig > +++ b/arch/tile/Kconfig > @@ -8,6 +8,7 @@ config TILE > select USE_GENERIC_SMP_HELPERS > select CC_OPTIMIZE_FOR_SIZE > select HAVE_GENERIC_HARDIRQS > + select HAVE_PC_PARPORT > select GENERIC_IRQ_PROBE > select GENERIC_PENDING_IRQ if SMP > select GENERIC_IRQ_SHOW Only through PCI > diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig > index e57dcce..3832e7e 100644 > --- a/arch/unicore32/Kconfig > +++ b/arch/unicore32/Kconfig > @@ -8,6 +8,7 @@ config UNICORE32 > select HAVE_KERNEL_BZIP2 > select HAVE_KERNEL_LZO > select HAVE_KERNEL_LZMA > + select HAVE_PC_PARPORT > select GENERIC_FIND_FIRST_BIT > select GENERIC_IRQ_PROBE > select GENERIC_IRQ_SHOW Probably not. I think you can leave these four out right away, provided you add the section below: > --- a/drivers/parport/Kconfig > +++ b/drivers/parport/Kconfig > @@ -35,8 +35,7 @@ if PARPORT > > config PARPORT_PC > > tristate "PC-style hardware" > > - depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ > - (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN > + depends on HAVE_PC_PARPORT > > ---help--- > > You should say Y here if you have a PC-style parallel port. All > IBM PC compatible computers and some Alphas have PC-style > > @@ -48,6 +47,9 @@ config PARPORT_PC > > If unsure, say Y. > > +config HAVE_PC_PARPORT > + bool > + As you write, anything that has PCI can theoretically take parallel ports, so I would always list PCI here as a way to get it anyway. Probably also ISA and PCMCIA. How about adding this? config HAVE_PC_PARPORT bool default (PCI || ISA || PCMCIA) Arnd
On 06/14/2011 12:08 PM, Ralf Baechle wrote: > The PC parallel port Kconfig as acquired one of those messy terms to > describe it's architecture dependencies: > > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN > > This isn't just ugly - it also almost certainly describes the dependencies > too coarse grainedly. This is an attempt at cleaing the mess up. > > I tried to faithfully aproximate the old behaviour but the existing > behaviour seems inacurate if not wrong for some architectures or platforms. > To improve on this I rely on comments from other arch and platforms > maintainers. Any system that can take PCI multi-IO card or has a PC-style > parallel port on the mainboard should probably should now do a > select HAVE_PC_PARPORT. And some arch Kconfig files should further > restrict the use of HAVE_PC_PARPORT to only those platforms that actually > need it. > Why on earth restrict it like that? It's just a device driver, like more or less any other device driver... -hpa
On Tue, Jun 14, 2011 at 21:08, Ralf Baechle <ralf@linux-mips.org> wrote: > The PC parallel port Kconfig as acquired one of those messy terms to > describe it's architecture dependencies: > > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN > > This isn't just ugly - it also almost certainly describes the dependencies > too coarse grainedly. This is an attempt at cleaing the mess up. > --- a/arch/m68k/Kconfig.mmu > +++ b/arch/m68k/Kconfig.mmu > @@ -399,6 +399,7 @@ config ISA > bool > depends on Q40 || AMIGA_PCMCIA > default y > + select PARPORT_PC Why do you select PARPORT_PC here instead of HAVE_PC_PARPORT? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote: > On 06/14/2011 12:08 PM, Ralf Baechle wrote: > > The PC parallel port Kconfig as acquired one of those messy terms to > > describe it's architecture dependencies: > > > > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ > > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN > > > > This isn't just ugly - it also almost certainly describes the dependencies > > too coarse grainedly. This is an attempt at cleaing the mess up. > > > > I tried to faithfully aproximate the old behaviour but the existing > > behaviour seems inacurate if not wrong for some architectures or platforms. > > To improve on this I rely on comments from other arch and platforms > > maintainers. Any system that can take PCI multi-IO card or has a PC-style > > parallel port on the mainboard should probably should now do a > > select HAVE_PC_PARPORT. And some arch Kconfig files should further > > restrict the use of HAVE_PC_PARPORT to only those platforms that actually > > need it. > > > > Why on earth restrict it like that? It's just a device driver, like > more or less any other device driver... I'd say any other classic ISA/PC driver, including floppy, gameport or serial-8250. One problem with these is that we never fully worked out the dependencies for these, which we probably should. CONFIG_ISA generally means ISA add-on cards, but that might not be enabled for platforms that have a pc-parport but no ISA slots. On the other hand, you have embedded platforms that currently build support for parport-pc but define the inb/outb macros to plain pointer dereferences (otherwise you can't build the 8250 driver). Loading parport-pc on those machines typically results in derefencing user memory in the best case. What I'd love to see is a configuration option for "arch has working PC-style inb/outb instructions", so we can build a kernel without them but still get MMIO based drivers for PCI-less platforms. Arnd
On Tue, Jun 14, 2011 at 01:25:46PM -0700, H. Peter Anvin wrote: > On 06/14/2011 12:08 PM, Ralf Baechle wrote: > > The PC parallel port Kconfig as acquired one of those messy terms to > > describe it's architecture dependencies: > > > > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ > > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN > > > > This isn't just ugly - it also almost certainly describes the dependencies > > too coarse grainedly. This is an attempt at cleaing the mess up. > > > > I tried to faithfully aproximate the old behaviour but the existing > > behaviour seems inacurate if not wrong for some architectures or platforms. > > To improve on this I rely on comments from other arch and platforms > > maintainers. Any system that can take PCI multi-IO card or has a PC-style > > parallel port on the mainboard should probably should now do a > > select HAVE_PC_PARPORT. And some arch Kconfig files should further > > restrict the use of HAVE_PC_PARPORT to only those platforms that actually > > need it. > > > > Why on earth restrict it like that? It's just a device driver, like > more or less any other device driver... Some of the older MIPS systems are based on PC chipsets from Intel, OPTi or others. On those you can expect the parport_pc driver to actually work. The ISA/PCI implementations are often between lackluster and pure brokeness such as with non-functioning I/O port address space. So I don't want to run such drivers on such a platforms, things might turn ugly. Embedded systems often have PCI but no PCI slots or there may even be an apropriate SuperIO chip in the the system but nothing wired to the parallel port bits. And there are systems such as DECstations which have nothing that even at a parsec's distance has a similarity to (E)ISA or PCI - but still PARPORT_PC is offered along with 40 other options that depend on it. There is no point in offering to build something that couldn't possibly be used. It just makes the kernel harder to configure and inflates the test matrix for no good reason. Ralf
On Tue, 2011-06-14 at 20:08 +0100, Ralf Baechle wrote: > The PC parallel port Kconfig as acquired one of those messy terms to > describe it's architecture dependencies: > > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN > > This isn't just ugly - it also almost certainly describes the dependencies > too coarse grainedly. This is an attempt at cleaing the mess up. > > I tried to faithfully aproximate the old behaviour but the existing > behaviour seems inacurate if not wrong for some architectures or platforms. > To improve on this I rely on comments from other arch and platforms > maintainers. Any system that can take PCI multi-IO card or has a PC-style > parallel port on the mainboard should probably should now do a > select HAVE_PC_PARPORT. And some arch Kconfig files should further > restrict the use of HAVE_PC_PARPORT to only those platforms that actually > need it. > > Thanks, > > Ralf > diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig > index e57dcce..3832e7e 100644 > --- a/arch/unicore32/Kconfig > +++ b/arch/unicore32/Kconfig > @@ -8,6 +8,7 @@ config UNICORE32 > select HAVE_KERNEL_BZIP2 > select HAVE_KERNEL_LZO > select HAVE_KERNEL_LZMA > + select HAVE_PC_PARPORT > select GENERIC_FIND_FIRST_BIT > select GENERIC_IRQ_PROBE > select GENERIC_IRQ_SHOW In UniCore32, only some debug-boards need to support parport. So I'd like to add HAVE_PC_PARPORT and related configs to certian *_defconfig, but not in Kconfig. Thanks Ralf. Guan Xuetao
On 06/14/2011 03:34 PM, Ralf Baechle wrote: > > There is no point in offering to build something that couldn't possibly be > used. It just makes the kernel harder to configure and inflates the test > matrix for no good reason. > I see... that's why a bunch of devices that only exist on ARM and MIPS SoCs are offered on x86 platforms? -hpa
On 06/14/2011 02:33 PM, Arnd Bergmann wrote: >> >> Why on earth restrict it like that? It's just a device driver, like >> more or less any other device driver... > > I'd say any other classic ISA/PC driver, including floppy, gameport or > serial-8250. One problem with these is that we never fully worked out > the dependencies for these, which we probably should. CONFIG_ISA > generally means ISA add-on cards, but that might not be enabled for > platforms that have a pc-parport but no ISA slots. > OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs are ubiquitous across just about every platform. Floppy is special (in the short bus sense), since it is closely tied to ISA DMA. Conditionalizing this on ISA DMA makes total sense. Parallel port is an intermediate case... Centronics parallel ports predate the PC ecosystem by quite a bit, and the particular arrangement of ports became popular with the PC and spread to other platforms, but the particular variant of it known as ECP (as opposed to EPP) is ISA DMA specific. > On the other hand, you have embedded platforms that currently build support > for parport-pc but define the inb/outb macros to plain pointer dereferences > (otherwise you can't build the 8250 driver). Loading parport-pc on those > machines typically results in derefencing user memory in the best case. > > What I'd love to see is a configuration option for "arch has working > PC-style inb/outb instructions", so we can build a kernel without them but > still get MMIO based drivers for PCI-less platforms. Now, isn't that was iowrite/ioread was designed for? -hpa
On Wed, Jun 15, 2011 at 12:18:36AM -0400, H. Peter Anvin wrote: > On 06/14/2011 03:34 PM, Ralf Baechle wrote: > > > > There is no point in offering to build something that couldn't possibly be > > used. It just makes the kernel harder to configure and inflates the test > > matrix for no good reason. > > > > I see... that's why a bunch of devices that only exist on ARM and MIPS > SoCs are offered on x86 platforms? > http://en.wikipedia.org/wiki/Two_wrongs_make_a_right Guenter
On 06/14/2011 09:40 PM, Guenter Roeck wrote: > On Wed, Jun 15, 2011 at 12:18:36AM -0400, H. Peter Anvin wrote: >> On 06/14/2011 03:34 PM, Ralf Baechle wrote: >>> >>> There is no point in offering to build something that couldn't possibly be >>> used. It just makes the kernel harder to configure and inflates the test >>> matrix for no good reason. >>> >> >> I see... that's why a bunch of devices that only exist on ARM and MIPS >> SoCs are offered on x86 platforms? >> > http://en.wikipedia.org/wiki/Two_wrongs_make_a_right > Except in this case it's not wrong. It was done that way because it was discovered a long time ago that restricting drivers that were not *inherently* limited to specific platform just resulted in more bitrot and nasty surprises for the users who *did* need specific things after all, even though the maintainers had not thought so. -hpa
On Tue, Jun 14, 2011 at 09:30:47PM -0700, H. Peter Anvin wrote: > On 06/14/2011 02:33 PM, Arnd Bergmann wrote: > >> > >> Why on earth restrict it like that? It's just a device driver, like > >> more or less any other device driver... > > > > I'd say any other classic ISA/PC driver, including floppy, gameport or > > serial-8250. One problem with these is that we never fully worked out > > the dependencies for these, which we probably should. CONFIG_ISA > > generally means ISA add-on cards, but that might not be enabled for > > platforms that have a pc-parport but no ISA slots. > > > > OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs > are ubiquitous across just about every platform. > > Floppy is special (in the short bus sense), since it is closely tied to > ISA DMA. Conditionalizing this on ISA DMA makes total sense. No it doesn't. It depends on the ISA DMA API, not that the machine has ISA DMA. I have a platform which has no ISA DMA but uses the floppy driver. Please don't break it.
2011/6/15 Arnd Bergmann <arnd@arndb.de> > > > config SCORE > > - def_bool y > > - select HAVE_GENERIC_HARDIRQS > > - select GENERIC_IRQ_SHOW > > + def_bool y > > + select HAVE_GENERIC_HARDIRQS > > + select HAVE_PC_PARPORT > > + select GENERIC_IRQ_SHOW > > > > choice > > prompt "System type" > > Certainly not, no PIO support > > Yes, there is no platform of the Score supports PIO. Best, Lennox
On Tue, Jun 14, 2011 at 09:18:36PM -0700, H. Peter Anvin wrote: > On 06/14/2011 03:34 PM, Ralf Baechle wrote: > > > > There is no point in offering to build something that couldn't possibly be > > used. It just makes the kernel harder to configure and inflates the test > > matrix for no good reason. > > > > I see... that's why a bunch of devices that only exist on ARM and MIPS > SoCs are offered on x86 platforms? Well, if you notice one of those, yell. Or send patches. Most of those have been fixed. Ralf
On Wednesday 15 June 2011, H. Peter Anvin wrote: > On 06/14/2011 02:33 PM, Arnd Bergmann wrote: > >> > >> Why on earth restrict it like that? It's just a device driver, like > >> more or less any other device driver... > > > > I'd say any other classic ISA/PC driver, including floppy, gameport or > > serial-8250. One problem with these is that we never fully worked out > > the dependencies for these, which we probably should. CONFIG_ISA > > generally means ISA add-on cards, but that might not be enabled for > > platforms that have a pc-parport but no ISA slots. > > > > OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs > are ubiquitous across just about every platform. Obviously you want to support 8250 uarts with MMIO on most architectures, but the driver can only be built if you define both MMIO and PIO accessors (readb and outb). I would like to make the PIO part of 8250 conditional on having PIO support so that an architecture that doesn't support this no longer has to provide fake accessor functions. > Parallel port is an intermediate case... Centronics parallel ports > predate the PC ecosystem by quite a bit, and the particular arrangement > of ports became popular with the PC and spread to other platforms, but > the particular variant of it known as ECP (as opposed to EPP) is ISA DMA > specific. The driver looks like it can easily be built without support for the ISA DMA API. > > On the other hand, you have embedded platforms that currently build support > > for parport-pc but define the inb/outb macros to plain pointer dereferences > > (otherwise you can't build the 8250 driver). Loading parport-pc on those > > machines typically results in derefencing user memory in the best case. > > > > What I'd love to see is a configuration option for "arch has working > > PC-style inb/outb instructions", so we can build a kernel without them but > > still get MMIO based drivers for PCI-less platforms. > > Now, isn't that was iowrite/ioread was designed for? Yes, it just isn't used consistently. As far as I can tell, this is for multiple number of reasons: * In case of 8250, the driver abstracts the difference between PIO and MMIO itself, because it uses the same method to do indirect accesses and different strides. Using ioread wouldn't really make the driver much simpler. * For parport-pc, the driver really only needs PIO, we don't even try to support the same device on random MMIO addresses, and that might not be necessary. * In case of floppies, the "solution" was to write a driver for every platform that doesn't have PIO, since they tend to have other differences. The amiflop and ataflop drivers are not even use readb(), they just derefence volatile pointers to do MMIO. I doubt we can find volunteers to clean that up. Arnd
On Wed, Jun 15, 2011 at 11:46, Arnd Bergmann <arnd@arndb.de> wrote: > * In case of floppies, the "solution" was to write a driver for every platform that > doesn't have PIO, since they tend to have other differences. The amiflop and > ataflop drivers are not even use readb(), they just derefence volatile pointers > to do MMIO. I doubt we can find volunteers to clean that up. Amiflop drives the Amiga floppy controller, which is completely different from the PC-style floppy controller. Ataflop drives the Atari floppy controller, which seems to be a WD1772 and not related to PC-style floppy controllers neither. So none of them drive PC-style hardware, and both predate the generic readb() infrastructure. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Wed, Jun 15, 2011 at 04:34:37AM -0400, Ralf Baechle wrote: > On Tue, Jun 14, 2011 at 09:18:36PM -0700, H. Peter Anvin wrote: > > > On 06/14/2011 03:34 PM, Ralf Baechle wrote: > > > > > > There is no point in offering to build something that couldn't possibly be > > > used. It just makes the kernel harder to configure and inflates the test > > > matrix for no good reason. > > > > > > > I see... that's why a bunch of devices that only exist on ARM and MIPS > > SoCs are offered on x86 platforms? > > Well, if you notice one of those, yell. Or send patches. Most of those > have been fixed. > I think he was being sarcastic, and wanted to say that it should be that way. Guenter
On 06/15/2011 12:47 AM, Russell King - ARM Linux wrote: >> >> OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs >> are ubiquitous across just about every platform. >> >> Floppy is special (in the short bus sense), since it is closely tied to >> ISA DMA. Conditionalizing this on ISA DMA makes total sense. > > No it doesn't. It depends on the ISA DMA API, not that the machine has > ISA DMA. > > I have a platform which has no ISA DMA but uses the floppy driver. Please > don't break it. OK, even more case in point, then. -hpa
On Wed, Jun 15, 2011 at 08:08:05AM -0700, H. Peter Anvin wrote: > On 06/15/2011 12:47 AM, Russell King - ARM Linux wrote: > >> > >> OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs > >> are ubiquitous across just about every platform. > >> > >> Floppy is special (in the short bus sense), since it is closely tied to > >> ISA DMA. Conditionalizing this on ISA DMA makes total sense. > > > > No it doesn't. It depends on the ISA DMA API, not that the machine has > > ISA DMA. > > > > I have a platform which has no ISA DMA but uses the floppy driver. Please > > don't break it. > > OK, even more case in point, then. It's already been solved - ARCH_MAY_HAVE_PC_FDC is supposed to be defined to y in the cases where architectures have support for it. What we do on ARM for example is: config ARCH_MAY_HAVE_PC_FDC bool and then select that symbol for our platforms which can have the floppy driver. And in any case we already have definitions for the presence of the ISA DMA API vs the common ISA DMA helpers in kernel/. The presence of the ISA DMA API is given by CONFIG_ISA_DMA_API, while the ISA DMA helper CONFIG_GENERIC_ISA_DMA.
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 60219bf..2ba8dd7 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -9,6 +9,7 @@ config ALPHA select HAVE_PERF_EVENTS select HAVE_DMA_ATTRS select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select GENERIC_IRQ_PROBE select AUTO_IRQ_AFFINITY if SMP select GENERIC_IRQ_SHOW diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9adc278..2968751f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -21,6 +21,7 @@ config ARM select HAVE_KERNEL_LZO select HAVE_KERNEL_LZMA select HAVE_IRQ_WORK + select HAVE_PC_PARPORT select HAVE_PERF_EVENTS select PERF_USE_VMALLOC select HAVE_REGS_AND_STACK_ACCESS_API diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig index 17addac..2eda6cf 100644 --- a/arch/cris/Kconfig +++ b/arch/cris/Kconfig @@ -51,6 +51,7 @@ config CRIS default y select HAVE_IDE select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select GENERIC_IRQ_SHOW config HZ diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index 091ed61..da08646 100644 --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -3,6 +3,7 @@ config H8300 default y select HAVE_IDE select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select GENERIC_IRQ_SHOW config SYMBOL_PREFIX diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 38280ef..849805a 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -23,6 +23,7 @@ config IA64 select HAVE_ARCH_TRACEHOOK select HAVE_DMA_API_DEBUG select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select GENERIC_IRQ_PROBE select GENERIC_PENDING_IRQ if SMP select IRQ_PER_CPU diff --git a/arch/m68k/Kconfig.mmu b/arch/m68k/Kconfig.mmu index 16539b1..6db5a3e 100644 --- a/arch/m68k/Kconfig.mmu +++ b/arch/m68k/Kconfig.mmu @@ -399,6 +399,7 @@ config ISA bool depends on Q40 || AMIGA_PCMCIA default y + select PARPORT_PC help Find out whether you have ISA slots on your motherboard. ISA is the name of a bus system, i.e. the way the CPU talks to the other stuff diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index e446bab..ceac9b5 100644 --- a/arch/microblaze/Kconfig +++ b/arch/microblaze/Kconfig @@ -15,6 +15,7 @@ config MICROBLAZE select OF select OF_EARLY_FLATTREE select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 653da62..51170ba 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -39,6 +39,7 @@ config MIPS_ALCHEMY select 64BIT_PHYS_ADDR select CEVT_R4K_LIB select CSRC_R4K_LIB + select HAVE_PC_PARPORT select IRQ_CPU select SYS_HAS_CPU_MIPS32_R1 select SYS_SUPPORTS_32BIT_KERNEL @@ -127,6 +128,7 @@ config MIPS_COBALT select CSRC_R4K select CEVT_GT641XX select DMA_NONCOHERENT + select HAVE_PC_PARPORT select HW_HAS_PCI select I8253 select I8259 @@ -185,6 +187,7 @@ config MACH_JAZZ select CSRC_R4K select DEFAULT_SGI_PARTITION if CPU_BIG_ENDIAN select GENERIC_ISA_DMA + select HAVE_PC_PARPORT select IRQ_CPU select I8253 select I8259 @@ -266,6 +269,7 @@ config MIPS_MALTA select CSRC_R4K select DMA_NONCOHERENT select GENERIC_ISA_DMA + select HAVE_PC_PARPORT select IRQ_CPU select IRQ_GIC select HW_HAS_PCI @@ -421,6 +425,7 @@ config SGI_IP22 select CSRC_R4K select DEFAULT_SGI_PARTITION select DMA_NONCOHERENT + select HAVE_PC_PARPORT select HW_HAS_EISA select I8253 select I8259 @@ -483,6 +488,7 @@ config SGI_IP28 select DEFAULT_SGI_PARTITION select DMA_NONCOHERENT select GENERIC_ISA_DMA_SUPPORT_BROKEN + select HAVE_PC_PARPORT select IRQ_CPU select HW_HAS_EISA select I8253 @@ -517,6 +523,7 @@ config SGI_IP32 select CEVT_R4K select CSRC_R4K select DMA_NONCOHERENT + select HAVE_PC_PARPORT select HW_HAS_PCI select IRQ_CPU select R5000_CPU_SCACHE @@ -535,6 +542,7 @@ config SIBYTE_CRHINE depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT + select HAVE_PC_PARPORT select SIBYTE_BCM1120 select SWAP_IO_SPACE select SYS_HAS_CPU_SB1 @@ -546,6 +554,7 @@ config SIBYTE_CARMEL depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT + select HAVE_PC_PARPORT select SIBYTE_BCM1120 select SWAP_IO_SPACE select SYS_HAS_CPU_SB1 @@ -557,6 +566,7 @@ config SIBYTE_CRHONE depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT + select HAVE_PC_PARPORT select SIBYTE_BCM1125 select SWAP_IO_SPACE select SYS_HAS_CPU_SB1 @@ -569,6 +579,7 @@ config SIBYTE_RHONE depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT + select HAVE_PC_PARPORT select SIBYTE_BCM1125H select SWAP_IO_SPACE select SYS_HAS_CPU_SB1 @@ -580,6 +591,7 @@ config SIBYTE_SWARM select BOOT_ELF32 select DMA_COHERENT select HAVE_PATA_PLATFORM + select HAVE_PC_PARPORT select NR_CPUS_DEFAULT_2 select SIBYTE_SB1250 select SWAP_IO_SPACE @@ -595,6 +607,7 @@ config SIBYTE_LITTLESUR select BOOT_ELF32 select DMA_COHERENT select HAVE_PATA_PLATFORM + select HAVE_PC_PARPORT select NR_CPUS_DEFAULT_2 select SIBYTE_SB1250 select SWAP_IO_SPACE @@ -608,6 +621,7 @@ config SIBYTE_SENTOSA depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT + select HAVE_PC_PARPORT select NR_CPUS_DEFAULT_2 select SIBYTE_SB1250 select SWAP_IO_SPACE @@ -619,6 +633,7 @@ config SIBYTE_BIGSUR bool "Sibyte BCM91480B-BigSur" select BOOT_ELF32 select DMA_COHERENT + select HAVE_PC_PARPORT select NR_CPUS_DEFAULT_4 select SIBYTE_BCM1x80 select SWAP_IO_SPACE @@ -640,6 +655,7 @@ config SNI_RM select DEFAULT_SGI_PARTITION if CPU_BIG_ENDIAN select DMA_NONCOHERENT select GENERIC_ISA_DMA + select HAVE_PC_PARPORT select HW_HAS_EISA select HW_HAS_PCI select IRQ_CPU diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 65adc86..1be72d9 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -13,6 +13,7 @@ config PARISC select HAVE_PERF_EVENTS select GENERIC_ATOMIC64 if !64BIT select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select GENERIC_IRQ_PROBE select IRQ_PER_CPU diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 2729c66..b8328df 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -128,6 +128,7 @@ config PPC select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64 select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select HAVE_SPARSE_IRQ select IRQ_PER_CPU select GENERIC_IRQ_SHOW diff --git a/arch/score/Kconfig b/arch/score/Kconfig index 288add8..ba078d0 100644 --- a/arch/score/Kconfig +++ b/arch/score/Kconfig @@ -1,9 +1,10 @@ menu "Machine selection" config SCORE - def_bool y - select HAVE_GENERIC_HARDIRQS - select GENERIC_IRQ_SHOW + def_bool y + select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT + select GENERIC_IRQ_SHOW choice prompt "System type" diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index f03338c..daa65f3 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -20,6 +20,7 @@ config SUPERH select HAVE_SYSCALL_TRACEPOINTS select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select HAVE_SPARSE_IRQ select IRQ_FORCED_THREADING select RTC_LIB diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 253986b..3679d7c 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -520,6 +520,7 @@ config PCI CONFIG_PCI is needed for all JavaStation's (including MrCoffee), CP-1200, JavaEngine-1, Corona, Red October, and Serengeti SGSC. All of these platforms are extremely obscure, so say N if unsure. + select HAVE_PC_PARPORT if SPARC64 config PCI_DOMAINS def_bool PCI if SPARC64 diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig index 0249b8b..3e96eff 100644 --- a/arch/tile/Kconfig +++ b/arch/tile/Kconfig @@ -8,6 +8,7 @@ config TILE select USE_GENERIC_SMP_HELPERS select CC_OPTIMIZE_FOR_SIZE select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select GENERIC_IRQ_PROBE select GENERIC_PENDING_IRQ if SMP select GENERIC_IRQ_SHOW diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig index e57dcce..3832e7e 100644 --- a/arch/unicore32/Kconfig +++ b/arch/unicore32/Kconfig @@ -8,6 +8,7 @@ config UNICORE32 select HAVE_KERNEL_BZIP2 select HAVE_KERNEL_LZO select HAVE_KERNEL_LZMA + select HAVE_PC_PARPORT select GENERIC_FIND_FIRST_BIT select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index da34972..750f584 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -70,6 +70,7 @@ config X86 select IRQ_FORCED_THREADING select USE_GENERIC_SMP_HELPERS if SMP select HAVE_BPF_JIT if (X86_64 && NET) + select HAVE_PC_PARPORT config INSTRUCTION_DECODER def_bool (KPROBES || PERF_EVENTS) diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig index 5d43c1f..d4c3040 100644 --- a/arch/xtensa/Kconfig +++ b/arch/xtensa/Kconfig @@ -8,6 +8,7 @@ config XTENSA def_bool y select HAVE_IDE select HAVE_GENERIC_HARDIRQS + select HAVE_PC_PARPORT select GENERIC_IRQ_SHOW help Xtensa processors are 32-bit RISC machines designed by Tensilica diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig index d92185a..095a8c7 100644 --- a/drivers/parport/Kconfig +++ b/drivers/parport/Kconfig @@ -35,8 +35,7 @@ if PARPORT config PARPORT_PC tristate "PC-style hardware" - depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ - (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN + depends on HAVE_PC_PARPORT ---help--- You should say Y here if you have a PC-style parallel port. All IBM PC compatible computers and some Alphas have PC-style @@ -48,6 +47,9 @@ config PARPORT_PC If unsure, say Y. +config HAVE_PC_PARPORT + bool + config PARPORT_SERIAL tristate "Multi-IO cards (parallel and serial)" depends on SERIAL_8250_PCI && PARPORT_PC && PCI
The PC parallel port Kconfig as acquired one of those messy terms to describe it's architecture dependencies: depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN This isn't just ugly - it also almost certainly describes the dependencies too coarse grainedly. This is an attempt at cleaing the mess up. I tried to faithfully aproximate the old behaviour but the existing behaviour seems inacurate if not wrong for some architectures or platforms. To improve on this I rely on comments from other arch and platforms maintainers. Any system that can take PCI multi-IO card or has a PC-style parallel port on the mainboard should probably should now do a select HAVE_PC_PARPORT. And some arch Kconfig files should further restrict the use of HAVE_PC_PARPORT to only those platforms that actually need it. Thanks, Ralf Signed-off-by: Ralf Baechle <ralf@linux-mips.org> arch/alpha/Kconfig | 1 + arch/arm/Kconfig | 1 + arch/cris/Kconfig | 1 + arch/h8300/Kconfig | 1 + arch/ia64/Kconfig | 1 + arch/m68k/Kconfig.mmu | 1 + arch/microblaze/Kconfig | 1 + arch/mips/Kconfig | 16 ++++++++++++++++ arch/parisc/Kconfig | 1 + arch/powerpc/Kconfig | 1 + arch/score/Kconfig | 7 ++++--- arch/sh/Kconfig | 1 + arch/sparc/Kconfig | 1 + arch/tile/Kconfig | 1 + arch/unicore32/Kconfig | 1 + arch/x86/Kconfig | 1 + arch/xtensa/Kconfig | 1 + drivers/parport/Kconfig | 6 ++++-- 18 files changed, 39 insertions(+), 5 deletions(-)