Re: [discuss] Re: RFC: let x86_64 no longer define X86

David Woodhouse
2004-11-19T14:00:02Z

On Fri, 2004-11-19 at 13:05 +0100, Andi Kleen wrote:
> I don't know details about the driver, but it's not enabled on x86-64
> because x86-64 doesn't have ISA set.

That looks bogus actually -- I think it should only depend on the
existence of parport_pc style hardware. CONFIG_ISA is definitely a
digression. But still, either way the example is wrong. It shouldn't be
limited to X86 and X86_64.

I still haven't found good examples of cases where X86 is used and we
would want to change that to X86 || X86_64. Could this be one?

config HW_RANDOM
tristate "Intel/AMD/VIA HW Random Number Generator support"
depends on (X86 || IA64) && PCI

...or this?

config FTAPE
tristate "Ftape (QIC-80/Travan) support"
depends on BROKEN_ON_SMP && (ALPHA || X86)

I also see some which already have it:

config NVRAM
tristate "/dev/nvram support"
depends on ATARI || X86 || X86_64 || ARM || GENERIC_NVRAM
config HANGCHECK_TIMER
tristate "Hangcheck timer"
depends on X86_64 || X86

And some which seem to be wrong because they want only X86 not X86_64:

config SONYPI
tristate "Sony Vaio Programmable I/O Control Device support (EXPERIMENTAL)"
depends on EXPERIMENTAL && X86 && PCI && INPUT && !64BIT
config MWAVE
tristate "ACP Modem (Mwave) support"
depends on X86
select SERIAL_8250

Using X86 to include X86_64 is bizarre and inconsistent, and it's
already leading to errors in Kconfig. Let's fix it.

--
dwmw2