On Friday 16 November 2012, James Hogan wrote: > On 09/11/12 14:28, Arnd Bergmann wrote: > > On Wednesday 31 October 2012, James Hogan wrote: > >> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig > >> index 55f2c22..60b2a09 100644 > >> --- a/drivers/input/serio/Kconfig > >> +++ b/drivers/input/serio/Kconfig > >> @@ -22,7 +22,7 @@ config SERIO_I8042 > >> tristate "i8042 PC Keyboard controller" if EXPERT || !X86 > >> default y > >> depends on !PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && \ > >> - (!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN > >> + (!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN && !METAG > >> help > >> i8042 is the chip over which the standard AT keyboard and PS/2 > >> mouse are connected to the computer. If you use these devices, > > > > Maybe you can turn that list around and introduce a new symbol > > ARCH_HAS_SERIO_I8042 or similar that architectures can select. > > I suspect that actually most don't have this, but they have not > > bothered to update this list. > > Hi Arnd, > > I've starting writing some patches along these lines (for the various PC > style devices). They all seem to have slightly different rules though so > I think to be safe we need separate Kconfig symbols for each one. First of all, thank you very much for your investigation so far! I think a lot can be done with one Kconfig symbol, if each of the users lists the difference from the way the generic one is described, e.g. config SERIO_I8042 depends on HAVE_LEGACY_PC_IO && !M68K || ARCH_SHARK || FOOTBRIDGE_HOST to define one that can be set on anything that generally is PC compatible with the exception of all M68K but also including some ARM platforms. > With SERIO_I8042 I'm completely guessing. It defaults to y, but the only > ones I know for certain shouldn't select it are the ones currently > excluded (parisc, arm (unless shark, footbridge), superh (unless > cayman), m68k, blackfin, metag). A few I know should allow it due to > special casing of io operations (mips (jazz, sgi_has_i8042, sni_rm), > ppc, sparc, x86, ia64, unicore32). Is it okay in this case to select it > for pretty much all of the arches not excluded and let the maintainers > NAK if they don't want it? Yes, that sounds good. You can even do that patch to change over the other architectures straight away and let the ones that don't actually want it send a separate patch. Note that S390 and UML can't select SERIO because they disable INPUT altogether. It's probably a good idea to separate the inversion of the logic from any policy change and put those into separate patches. > PARPORT_PC isn't too difficult (and defaults to n), I can select > HAVE_PARPORT_PC from any arch that provides asm/parport.h or > conditionally allowed it before: > alpha, arm, ia64, m68k (if ISA), microblaze, mips, parisc, powerpc, sh, > sparc (if PCI), tile, unicore32, x86 Ok. I think in general, we want to enable this one for anything that has PCI, because the driver also supports parallel ports on an extension card, not just those with a hardwired address. > VGA_CONSOLE isn't too bad either (but it does default to y), I can > select HAVE_VGA_CONSOLE if the arch declares a screen_info struct (which > is the link error I get on metag): > alpha, arm (only ARCH_INTEGRATOR, ARCH_FOOTBRIDGE, ARCH_NETWINDER), > cris, ia64, m32r, mips, PPC (!4xx && !8xx), score, x86, xtensa Ok. I don't think we can actually support it on m32r or score, but it doesn't hurt to enable it. > RTC defaults to n, but I've narrowed it down to alpha, m32r, mips > (MACH_LOONSON), mn10300, and x86 which provide asm/mc146818rtc.h. > > GEN_RTC defaults to n, and I've narrowed to alpha, m68k, mn10300, > parisc, ppc, x86 which provide asm/rtc.h. It's amazing that those are still around after we've had RTC_LIB for so long. The "modern" driver that is supposed to replace these two is RTC_DRV_CMOS, which currently builds for X86 || ALPHA || ARM || M32R || ATARI || PPC || MIPS || SPARC64. There is also the nvram driver that is tightly coupled to the RTC support and that can build only on x86, m68k (atari) and ARM (if RTC_DRV_CMOS is on). I think the baseline should be: config LEGACY_PC_IO bool # selected by X86 || ALPHA || SPARC || M32R || # (PPC && !4xx && !8xx) || # (ARM && (ARCH_FOOTBRIDGE || ARCH_NETWINDER) || # (M68K && (Q40 || SUN3X)) || # (MIPS && (JAZZ || MALTA || SNI_RM)) config ARCH_MAY_HAVE_PC_FDC def_bool LEGACY_PC_IO && !M32R && (!PPC || (PCI && !PPC_PSERIES)) # selected by ARCH_RPC config HAVE_PARPORT_PC def_bool LEGACY_PC_IO || PCI config HAVE_VGA_CONSOLE def_bool LEGACY_PC_IO # selected by ARCH_INTEGRATOR || CRIS || IA64 || MIPS || SCORE || XTENSA config HAVE_RTC_DRV_CMOS def_bool LEGACY_PC_IO # selected by ARM || ATARI || PPC || MIPS || SPARC64 config HAVE_RTC_CMOS_LEGACY bool # selected by MACH_LOONSON || MN10300 || X86 || ALPHA || MN10300 || M32R config HAVE_GEN_RTC_LEGACY def_bool LEGACY_PC_IO && !(ARM || M32R || SPARC) # selected by M68K || MN10300 || PARISC || PPC Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html