[PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture - Kernel

This is a discussion on [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture - Kernel ; From: Hans J Koch
To: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.arm.linux.org.uk
Cc: Greg KH
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 ...

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

On Thu, Feb 07, 2008 at 07:58:24AM -0500, Christoph Hellwig wrote:
> On Thu, Feb 07, 2008 at 01:38:05PM +0100, Hans-J??rgen Koch wrote:
> > From: Hans J Koch
> > To: linux-kernel@vger.kernel.org
> > Cc: linux-arm-kernel@lists.arm.linux.org.uk
> > Cc: Greg KH
> > 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.
>
> 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.

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

Dnia Thursday, 7 of February 2008, Sam Ravnborg napisa³:
> On Thu, Feb 07, 2008 at 07:58:24AM -0500, Christoph Hellwig wrote:
> > 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.

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".

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

On Thu, Feb 07, 2008 at 04:09:34PM +0100, Marcin Juszkiewicz wrote:
> Dnia Thursday, 7 of February 2008, Sam Ravnborg napisaÅ‚:
> > On Thu, Feb 07, 2008 at 07:58:24AM -0500, Christoph Hellwig wrote:
>
> > > 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.
>
> I looked at it and 'arch/arm/Kconfig' does not source few entries:

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
order as drivers/Kconfig.
> Including of 'drivers/mtd' depends on "ALIGNMENT_TRAP || !CPU_CP15_MMU".

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

On Thu, Feb 07, 2008 at 04:05:58PM +0000, Russell King - ARM Linux wrote:
> On Thu, Feb 07, 2008 at 04:09:34PM +0100, Marcin Juszkiewicz wrote:
> > Dnia Thursday, 7 of February 2008, Sam Ravnborg napisaÅ‚:
> > > On Thu, Feb 07, 2008 at 07:58:24AM -0500, Christoph Hellwig wrote:
> >
> > > > 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.
> >
> > I looked at it and 'arch/arm/Kconfig' does not source few entries:
>
> 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
> order as drivers/Kconfig.
>
> > Including of 'drivers/mtd' depends on "ALIGNMENT_TRAP || !CPU_CP15_MMU".
>
> It's this which is the main issue.
>
> > 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.
>
> 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.

config ARCH_LH7A40X
bool "Sharp LH7A40X"
+ select HAVE_IDE
help
Say Y here for systems based on one of the Sharp LH7A40X
System on a Chip processors. These CPUs include an ARM922T
@@ -1076,9 +1100,7 @@ source "drivers/base/Kconfig"

+# select if MTD is supported
+config HAVE_MTD
+ def_bool n
+
menuconfig MTD
tristate "Memory Technology Device (MTD) support"
- depends on HAS_IOMEM
help
Memory Technology Devices are flash, RAM and similar chips, often
used for solid state file systems on embedded devices. This option
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

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_una ligned().

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

On Fri, 2008-02-08 at 09:45 +0000, Russell King - ARM Linux wrote:
> 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.

That makes some sense. Currently you have:

if ALIGNMENT_TRAP || !CPU_CP15_MMU
source "drivers/mtd/Kconfig"
endif
> Later, if there's a need to improve it (as you're suggesting) that should
> be a *separate* change.

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.

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

On Fri, Feb 08, 2008 at 10:18:31AM +0000, David Woodhouse wrote:
> 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.

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

On Fri, 2008-02-08 at 10:23 +0000, Russell King - ARM Linux wrote:
> 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?

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

On Fri, Feb 08, 2008 at 10:43:42AM +0000, David Woodhouse wrote:
> On Fri, 2008-02-08 at 10:23 +0000, Russell King - ARM Linux wrote:
> > 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?

Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture

On Fri, Feb 08, 2008 at 10:58:29AM +0000, David Woodhouse wrote:
> On Fri, 2008-02-08 at 09:04 +0000, David Woodhouse wrote:
> > We could add get_unaligned() in certain places in the code, but that
> > isn't ideal for the majority of architectures.
>
> 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.
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?