login
Search
From: Hans J Koch <hjk@linutronix.de> To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.arm.linux.org.uk Cc: Greg KH <greg@kroah.com> Subject: arch/arm/Kconfig: Make UIO available on ARM architecture Source drivers/uio/Kconfig to make UIO available in menuconfig if ARCH=arm. I already posted this a few months ago, but it got lost somehow. Signed-off-by: Hans J Koch <hjk@linutronix.de> --- arch/arm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/arch/arm/Kconfig =================================================================== --- linux-2.6.orig/arch/arm/Kconfig 2008-02-07 13:01:45.000000000 +0100 +++ linux-2.6/arch/arm/Kconfig 2008-02-07 13:18:22.000000000 +0100 @@ -1066,6 +1066,8 @@ config ARCH_SUSPEND_POSSIBLE def_bool y +source "drivers/uio/Kconfig" + endmenu source "net/Kconfig" --
Any chance to make arm finally use drivers/Kconfig? It's a bit silly that arm still is crapping around while even s390 uses it. --
rmk said that it should be easy to check the amount of work needed to do so. But I have not had time to look into it yet - hopefully someone in ARM land could fix it. Sam --
I looked at it and 'arch/arm/Kconfig' does not source few entries:
- of - does not appear on ARM if enabled
- macintosh - does not appear on ARM if enabled
- telephony - drivers for ISA/PCI/PCMCIA so can probably be used on some
ARM platforms
- infiniband - like above(?)
- edac - does not appear on ARM if enabled
- auxdisplay - basically it is for one LCD controller connected to x86
parallel port - safe to have it sourced on ARM
- uio
Including of 'drivers/mtd' depends on "ALIGNMENT_TRAP || !CPU_CP15_MMU".
Including of 'drivers/ide' depends on "PCMCIA || ARCH_CLPS7500 ||
ARCH_IOP32X || ARCH_IOP33X || ARCH_IXP4XX || ARCH_L7200 ||
ARCH_LH7A40X || ARCH_PXA || ARCH_RPC || ARCH_S3C2410 || ARCH_SA1100 ||
ARCH_SHARK || FOOTBRIDGE || ARCH_IXP23XX" but 'drivers/ata' (which can be
used instead on PCMCIA enabled platforms) does not depend on such set.
Does it look like 'drivers/mtd' require extra check 'if ARM then check for
ALIGNMENT_TRAP || !CPU_CP15_MMU' and probably extra check
in 'drivers/ide'?
I hope this info will help (test in 2.6.24-git
488b5ec871191359b9b79262a3d48456dae7ea5f).
--
JID: hrw-jabber.org
OpenEmbedded developer/consultant
"To be or not to be that is the question.":
every programmer knows the answer $2b or (not $2b) is $ff.
--
diff -u arch/arm/Kconfig drivers/Kconfig shows the situation. This is why I insist that new entries to arch/arm/Kconfig should be in the same IDE people insisted that we _will_ have that silly conditional for IDE. I personally do not want it and would be happy to see it go - but I don't have the authority to do that. Take this one up with Bart. --
Both situations are trivially fixable by introducing HAVE_IDE and HAVE_MTD. See attached patch. My quick scan told me that only S390 and UM did not support IDE neither MTD. ARM is the only one where IDE and MTD support is conditional and the rest you select them unconditionally. Does this look acceptable? Sam diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 01b10ab..46049fa 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -5,6 +5,8 @@ config ALPHA bool default y + select HAVE_IDE + select HAVE_MTD select HAVE_OPROFILE help The Alpha is a 64-bit general-purpose processor designed and diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e19e774..58c7eb4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -23,6 +23,16 @@ config ARM config SYS_SUPPORTS_APM_EMULATION bool +# if PCMCIA is selected then we need IDE +config ARM_PCMCIA + depends on PCMCIA + select HAVE_IDE + +# select MTD except in a few corner configuration cases +config ARM_MTD + depends on ALIGNMENT_TRAP || !CPU_CP15_MMU + select HAVE_MTD + config GENERIC_GPIO bool default n @@ -219,6 +229,7 @@ config ARCH_CLPS7500 select TIMER_ACORN select ISA select NO_IOPORT + select HAVE_IDE help Support for the Cirrus Logic PS7500FE system-on-a-chip. @@ -231,6 +242,7 @@ config ARCH_CO285 bool "Co-EBSA285" select FOOTBRIDGE select FOOTBRIDGE_ADDIN + select HAVE_IDE help Support for Intel's EBSA285 companion chip. @@ -255,6 +267,7 @@ config ARCH_EP93XX config ARCH_FOOTBRIDGE bool "FootBridge" select FOOTBRIDGE + select HAVE_IDE help Support for systems based on the DC21285 companion chip ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder. @@ -293,6 +306,7 @@ config ARCH_IOP32X depends on MMU select PLAT_IOP select PCI + select HAVE_IDE help Support for Intel's 80219 and IOP32X (XScale) family of processors. @@ -302,12 +316,14 @@ config ARCH_IOP33X depends ...
Shouldn't this be: def_bool PCMCIA Also, should this be something ARM specific - if you have PCMCIA you could --
So we can replace the above with this:
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index 519b4ff..8b22281 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -38,6 +38,7 @@ config PCMCIA_DEBUG
config PCMCIA
tristate "16-bit PCMCIA support"
select CRC32
+ select HAVE_IDE
default y
---help---
This option enables support for 16-bit PCMCIA cards. Most older
Yes.
Sam
--
HAVE_MTD is wrong. The actual problem we're trying to solve is that when the architecture lacks alignment fixups, certain patterns of write access to 16-bit or 32-bit NOR flash arrays are broken. So it's not 'MTD' which should be conditional -- but only certain configurations of NOR flash, which could perhaps be prevented by disallowing any of the MTD_MAP_BANK_WIDTH_* options other than MTD_MAP_BANK_WIDTH_1 from being set. And it's not just an ARM-specific problem; a number of our MMU-less architectures also lack alignment traps now. It _used_ to be the case that platforms without alignment fixups were simply considered to be broken -- if the hardware didn't support unaligned access, either natively or through traps, it just wasn't supported by Linux. But since that isn't really the case any more, perhaps we should seek a better option than just disabling certain functionality (or _not_ disabling it, in the case of the network stack, and just kind of praying that it works even though we don't really think it does). We could add get_unaligned() in certain places in the code, but that isn't ideal for the majority of architectures. What we really want, I suppose, is get_something_which_may_be_but_probably_is_not_unaligned(). With a better name. -- dwmw2 --
If we are serious about allowing ARM to use drivers/Kconfig, then let's not get distracted by perfection - by trying to do too many changes in one go. If, today, we conditionalise MTD or IDE on a certain set of symbols, then those conditions should be preserved in the first step - it should be a 1:1 translation. Later, if there's a need to improve it (as you're suggesting) that should be a *separate* change. --
That makes some sense. Currently you have: if ALIGNMENT_TRAP || !CPU_CP15_MMU source "drivers/mtd/Kconfig" We can certainly improve the behaviour later, it's true -- it's not the end of the world if we continue to have the whole of the MTD layer turned off on platforms with alignment problems for now. But still, it's HAVE_UNALIGNED_ACCESS which we want to depend on, not a newly-invented HAVE_MTD. And there are other places we really ought to be depending on HAVE_UNALIGNED_ACCESS too. -- dwmw2 --
That would be misleading though - !CPU_CP15_MMU does not mean we support unaligned accesses. It means that we may have no way to support fixing up unaligned accesses. --
Doesn't that mean you should disallow MTD (or at least 16-bit NOR flash) if !CPU_CP15_MMU, then? But at the moment you allow it? -- dwmw2 --
Ask Hyok or Greg Ungerer. --
I would agree that it means disabling 16-bit NOR flash, but the 8-bit case should be fine right? A complete disable of MTD seems like overkill. A more fine grained approach would be better. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com Secure Computing Corporation PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com --
Actually, we already did that, despite the fact that it isn't optimal. So there's no need to omit anything MTD-related from ARM builds whether we have alignment fixup support or not. -- dwmw2 --
Just so I do not get you wrong... What you say above is that the following code: if ALIGNMENT_TRAP || !CPU_CP15_MMU source "drivers/mtd/Kconfig" endif Here we do not need to have the "if ..." and can source drivers/mtd/Kconfig unconditional for arm? Sam --
Quick status on this. I have submitted a corrected patch containing only the HAVE_IDE stuff via kbuild.git and considering the comment from David the mtd bits are trivial done. So I expect someone that better can check the arm stuff to do the final conversion bits to introduce drivers/Kconfig when kbuild.git hits mainline. Sam --
Are we finally going to allow architecture modifications to drivers/Kconfig? The answer to your question is identical to the answer to that question. --
Please place it in the same relative position in arch/arm/Kconfig as it is found in drivers/Kconfig. --
Am Thu, 7 Feb 2008 13:02:23 +0000 Argh, sorry. Here's the correct version: ============ From: Hans J Koch <hjk@linutronix.de> To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.arm.linux.org.uk Cc: Greg KH <greg@kroah.com> Subject: arch/arm/Kconfig: Make UIO available on ARM architecture Source drivers/uio/Kconfig to make UIO available in menuconfig if ARCH=arm. Signed-off-by: Hans J Koch <hjk@linutronix.de> --- arch/arm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/arch/arm/Kconfig =================================================================== --- linux-2.6.orig/arch/arm/Kconfig 2008-02-07 13:57:58.000000000 +0100 +++ linux-2.6/arch/arm/Kconfig 2008-02-07 14:08:46.000000000 +0100 @@ -1159,6 +1159,8 @@ source "drivers/dca/Kconfig" +source "drivers/uio/Kconfig" + endmenu source "fs/Kconfig" --
Am Thu, 7 Feb 2008 14:12:36 +0100 schrieb Hans-Jürgen Koch <hjk@linutronix.de>: AFAICT, this patch was neither rejected nor applied. It generated a long thread about changing the whole ARM Kconfig system. I feel not qualified to do that, but I still want UIO available on ARM ;-) What can I do to help? Thanks, --
Hello, Anything new here? In my eyes this can be sent to the patch system. Russell? Best regards Uwe -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 --
I don't remember anything about this... --
Hi Russell, I don't know how I should understand your statement. Does this only comment on my suggestion to send it to the patch system or on the patch itself? After Hans-Jürgen addressed your concerns about the order in arch/arm/Kconfig compared to drivers/Kconfig there was no addional feedback (apart from the discussion about including drivers/Kconfig in arch/arm/Kconfig). I consider the patch good until arch/arm/Kconfig includes drivers/Kconfig (if ever). As it is a while that the discussion took place, here is the thread in the archive: http://lists.arm.linux.org.uk/lurker/thread/20080207.125824.348cd1bd.en.html and the following post includes the last version of the patch: http://lists.arm.linux.org.uk/lurker/message/20080207.131236.8c4f4569.en.html Best regards Uwe -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 --
Do you want to post the patch to the patch system? If yes you can add an Acked-by: me; if no I can do it, too. Best regards Uwe -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 --
Hi rmk When this topic was last discussed we looked into what prevented ARM from using the generic drivers/Kconfig. The conclusion was that only IDE and MTD did so. The IDE issue was quickly fixed in upstream by introducing HAVE_IDE and the MTD issue were concluded to be a non-issue. So there should not be any problems left to my best knowledge to use the generic drivers/Kconfig for arm. Sam --
