[RFC,PATCH] 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 && !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 <redacted>

 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(-)

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

On Tuesday 14 June 2011 21:08:50 Ralf Baechle wrote:

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

Similar to ARM and Mips.

Highly unlikely, except through PCI.

Certainly not, no PIO support

Only through PCI

Probably not.

I think you can leave these four out right away, provided you add
the section below:

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 [off-list ref] wrote:

The PC parallel port Kconfig as acquired one of those messy terms to
describe it's architecture dependencies:

=C2=A0 =C2=A0 =C2=A0 depends on (!SPARC64 || PCI) && !SPARC32 && !M32R &&=

 !FRV && \

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (!M68K || ISA) && !MN103=

00 && !AVR32 && !BLACKFIN

This isn't just ugly - it also almost certainly describes the dependencie=

s

too coarse grainedly. =C2=A0This is an attempt at cleaing the mess up.

Why do you select PARPORT_PC here instead of HAVE_PC_PARPORT?

Gr{oetje,eeting}s,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 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. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds

On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:

On 06/14/2011 12:08 PM, Ralf Baechle wrote:

quoted

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

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

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

On Tue, Jun 14, 2011 at 01:25:46PM -0700, H. Peter Anvin wrote:

On 06/14/2011 12:08 PM, Ralf Baechle wrote:

quoted

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

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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

On 06/14/2011 02:33 PM, Arnd Bergmann wrote:

quoted

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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

On 06/14/2011 03:08 PM, Luck, Tony wrote:

If it has PCI slots, it can have a parallel port.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

On Wed, Jun 15, 2011 at 12:18:36AM -0400, H. Peter Anvin wrote:

On 06/14/2011 03:34 PM, Ralf Baechle wrote:

quoted

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:

quoted

On 06/14/2011 03:34 PM, Ralf Baechle wrote:

quoted

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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

On Tue, Jun 14, 2011 at 09:31:27PM -0700, H. Peter Anvin wrote:

On 06/14/2011 03:08 PM, Luck, Tony wrote:

quoted

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?

On Tue, Jun 14, 2011 at 09:30:47PM -0700, H. Peter Anvin wrote:

On 06/14/2011 02:33 PM, Arnd Bergmann wrote:

quoted

quoted

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 [off-list ref]

quoted

 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:

quoted

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:

quoted

quoted

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.

quoted

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 [off-list ref] wrote:

* In case of floppies, the "solution" was to write a driver for every pla=

tform that

=C2=A0doesn't have PIO, since they tend to have other differences. The am=

iflop and

=C2=A0ataflop drivers are not even use readb(), they just derefence volat=

ile pointers

=C2=A0to 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,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 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. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- 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:

quoted

On 06/14/2011 03:34 PM, Ralf Baechle wrote:

quoted

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:

quoted

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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

On 06/15/2011 12:39 AM, Russell King - ARM Linux wrote:

On Tue, Jun 14, 2011 at 09:31:27PM -0700, H. Peter Anvin wrote:

quoted

On 06/14/2011 03:08 PM, Luck, Tony wrote:

quoted

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?

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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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:

quoted

quoted

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.