Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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: >> On 06/14/2011 03:08 PM, Luck, Tony wrote: >>> 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
On Wed, Jun 15, 2011 at 11:46, Arnd Bergmann 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 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
2011/6/15 Arnd Bergmann > > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
On Tue, Jun 14, 2011 at 09:31:27PM -0700, H. Peter Anvin wrote: > On 06/14/2011 03:08 PM, Luck, Tony wrote: > > 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? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
On 06/14/2011 03:08 PM, Luck, Tony wrote: > 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. > 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
On Tue, Jun 14, 2011 at 21:08, 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.
> --- 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 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[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 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
