Cleanup PC parallel port Kconfig
Subsystems (13)
RFC PATCH 1/1 Cleanup PC parallel port Kconfig
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 && !BLACKFINThis 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
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(-)
arch/alpha/Kconfig +1 -0
@@ -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
arch/arm/Kconfig +1 -0
@@ -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
arch/cris/Kconfig +1 -0
@@ -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
arch/h8300/Kconfig +1 -0
@@ -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
arch/ia64/Kconfig +1 -0
@@ -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
arch/m68k/Kconfig.mmu +1 -0
@@ -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
arch/microblaze/Kconfig +1 -0
@@ -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
arch/mips/Kconfig +16 -0
@@ -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
arch/parisc/Kconfig +1 -0
@@ -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
arch/powerpc/Kconfig +1 -0
@@ -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
arch/score/Kconfig +4 -3
@@ -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"
arch/sh/Kconfig +1 -0
@@ -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
arch/sparc/Kconfig +1 -0
@@ -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
arch/tile/Kconfig +1 -0
@@ -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
arch/unicore32/Kconfig +1 -0
@@ -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
arch/x86/Kconfig +1 -0
@@ -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)
arch/xtensa/Kconfig +1 -0
@@ -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
drivers/parport/Kconfig +4 -2
@@ -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
Arnd Bergmann
maintainerarch/arm/Kconfig config ARM · line 27
Quoted 12 lines · On Tuesday 14 June 2011 21:08:50 Ralf Baechle wrote:
arch/arm/Kconfig +1
-0@@ -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
arch/powerpc/Kconfig config PPC · line 134
Quoted 12 lines
arch/powerpc/Kconfig +1
-0@@ -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.
arch/microblaze/Kconfig config MICROBLAZE · line 21
Quoted 11 lines
index e446bab..ceac9b5 100644
arch/microblaze/Kconfig +1
-0@@ -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.
Quoted 8 lines
arch/score/Kconfig +0
-0@@ -1,9 +1,10 @@ menu "Machine selection" config SCORE
arch/score/Kconfig line 10
Quoted 10 lines
arch/score/Kconfig +4
-3- 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
arch/tile/Kconfig config TILE · line 14
Quoted 12 lines
arch/tile/Kconfig +1
-0@@ -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
arch/unicore32/Kconfig config UNICORE32 · line 14
Quoted 12 lines
arch/unicore32/Kconfig +1
-0@@ -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:
Quoted 18 lines
drivers/parport/Kconfig +1
-2@@ -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
drivers/parport/Kconfig config PARPORT_PC · line 52
Quoted 6 lines
drivers/parport/Kconfig +3
-0@@ -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
2011/6/15 Arnd Bergmann <[email protected]>
Quoted 10 lines
Quoted 10 lines
config SCORE
arch/score/Kconfig +4
-3- 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
Quoted 6 lines
Quoted 2 lines
choice
prompt "System type"Certainly not, no PIO support
Yes, there is no platform of the Score supports PIO.
Best,
Lennox
H. Peter Anvin
reviewerQuoted 9 lines · Ralf Baechle
The PC parallel port
Kconfigas acquired one of those messy terms to describe it's architecture dependencies:depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFINThis isn't just ugly - it also almost certainly describes the dependencies too coarse grainedly. This is an attempt at cleaing the mess up.
Quoted 9 lines
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 archKconfigfiles should further restrict the use ofHAVE_PC_PARPORTto 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
Arnd Bergmann
maintainerQuoted 20 lines · On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:
Quoted 9 lines · Ralf Baechle
The PC parallel port
Kconfigas acquired one of those messy terms to describe it's architecture dependencies:depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFINThis isn't just ugly - it also almost certainly describes the dependencies too coarse grainedly. This is an attempt at cleaing the mess up.
Quoted 9 lines
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 archKconfigfiles should further restrict the use ofHAVE_PC_PARPORTto only those platforms that actually need it.
Quoted 2 lines
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
H. Peter Anvin
reviewerQuoted 10 lines · Arnd Bergmann
Quoted 3 lines
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_ISAgenerally 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.
Quoted 8 lines
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
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 12 lines · H. Peter Anvin
Quoted 10 lines · Arnd Bergmann
Quoted 3 lines
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_ISAgenerally means ISA add-on cards, but that might not be enabled for platforms that have a pc-parport but no ISA slots.
Quoted 5 lines
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.
H. Peter Anvin
reviewerQuoted 4 lines · Russell King - ARM Linux
Quoted 4 lines
OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs are ubiquitous across just about every platform.
Quoted 8 lines
Quoted 2 lines
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
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 8 lines · H. Peter Anvin
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines
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.
Quoted 7 lines
Quoted 5 lines
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.
Arnd Bergmann
maintainerQuoted 12 lines · H. Peter Anvin
Quoted 10 lines · Arnd Bergmann
Quoted 3 lines
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_ISAgenerally means ISA add-on cards, but that might not be enabled for platforms that have a pc-parport but no ISA slots.
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 10 lines
Quoted 8 lines
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
Geert Uytterhoeven
maintainerQuoted 4 lines · Arnd Bergmann
* 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 -- [email protected]
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
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 20 lines · H. Peter Anvin
Quoted 9 lines · Ralf Baechle
The PC parallel port
Kconfigas acquired one of those messy terms to describe it's architecture dependencies:depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFINThis isn't just ugly - it also almost certainly describes the dependencies too coarse grainedly. This is an attempt at cleaing the mess up.
Quoted 9 lines
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 archKconfigfiles should further restrict the use ofHAVE_PC_PARPORTto only those platforms that actually need it.
Quoted 2 lines
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
H. Peter Anvin
reviewerQuoted 5 lines · Ralf Baechle
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
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 10 lines · H. Peter Anvin
Quoted 5 lines · Ralf Baechle
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
H. Peter Anvin
reviewerQuoted 8 lines · Guenter Roeck
Quoted 7 lines · H. Peter Anvin
Quoted 5 lines · Ralf Baechle
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.
Quoted 5 lines
Quoted 3 lines
I see... that's why a bunch of devices that only exist on ARM and MIPS SoCs are offered on x86 platforms?
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
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 9 lines · H. Peter Anvin
Quoted 5 lines · Ralf Baechle
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
Quoted 9 lines · Ralf Baechle
Quoted 7 lines · H. Peter Anvin
Quoted 5 lines · Ralf Baechle
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.
Quoted 6 lines
Quoted 2 lines
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
Geert Uytterhoeven
maintainerQuoted 12 lines · Ralf Baechle
The PC parallel port
Kconfigas acquired one of those messy terms to describe it's architecture dependencies:depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
(!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFINThis isn't just ugly - it also almost certainly describes the dependencies too coarse grainedly. This is an attempt at cleaing the mess up.
arch/m68k/Kconfig.mmu +0
-0@@ -399,6 +399,7 @@ config ISA
Quoted 4 lines
bool
depends on Q40 ||AMIGA_PCMCIA
default y
+ selectPARPORT_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 -- [email protected]
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
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
arch/ia64/Kconfig +1 -0
@@ -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
I took a look at the back of all my ia64 systems - none of them have a parallel port. It seems unlikely that new systems will start adding parallel ports :-)
So even if I had a printer (or other device) that used a parallel port, I have no way to test it.
-Tony
H. Peter Anvin
reviewerQuoted 13 lines · Tony
arch/ia64/Kconfig +1
-0@@ -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
Quoted 7 lines
I took a look at the back of all my ia64 systems - none of them have a parallel port. It seems unlikely that new systems will start adding parallel ports :-)
So even if I had a printer (or other device) that used a parallel port, I have no way to test it.
If it has PCI slots, it can have a parallel port.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 9 lines · H. Peter Anvin
Quoted 6 lines · Tony
I took a look at the back of all my ia64 systems - none of them have a parallel port. It seems unlikely that new systems will start adding parallel ports :-)
So even if I had a printer (or other device) that used a parallel port, I have no way to test it.
If it has PCI slots, it can have a parallel port.
Is that a clue about where a select statement should be?
H. Peter Anvin
reviewerQuoted 6 lines · Russell King - ARM Linux
Quoted 5 lines · H. Peter Anvin
Quoted 4 lines · Tony
I took a look at the back of all my ia64 systems - none of them have a parallel port. It seems unlikely that new systems will start adding parallel ports :-)
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
So even if I had a printer (or other device) that used a parallel port, I have no way to test it.
If it has PCI slots, it can have a parallel port.
Is that a clue about where a select statement should be?
Not really, because it's a sufficient condition, not a required one.
All a platform needs to expose a PC-style parallel port interface is a minimum of 3 contiguous I/O locations, and although in the PC they are I/O mapped, they don't need to be.
The basic (SPP) parallel port interface is really just a glorified set of GPIOs and could at least in theory be implemented as-is on any platform with contiguous GPIO ports. The faster modes (EPP and ECP) do contain logic, and ECP depends on the ISA DMA API (thanks to Russell for pointing out that actual ISA DMA is not required, any slave DMA solution will do.)
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 27 lines · Ralf Baechle
The PC parallel port
Kconfigas acquired one of those messy terms to describe it's architecture dependencies:depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFINThis 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 archKconfigfiles should further restrict the use ofHAVE_PC_PARPORTto only those platforms that actually need it.Thanks,
Ralf
arch/unicore32/Kconfig +0
-0
arch/unicore32/Kconfig config UNICORE32 · line 14
Quoted 7 lines
arch/unicore32/Kconfig +1
-0@@ -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