[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200705242338.45499.arnd@arndb.de>
Date: Thu, 24 May 2007 23:38:45 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Al Viro <viro@....linux.org.uk>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Introduce CONFIG_VIRT_TO_BUS
On Wednesday 23 May 2007, Al Viro wrote:
>
> On Wed, May 23, 2007 at 05:01:55PM +1000, Stephen Rothwell wrote:
> > Make some offending drivers depend on it and set
> > CONFIG_ARCH_NO_VIRT_TO_BUS for ppc64 so that we don't build those drivers.
>
> Seeing how few targets _do_ have that, I'd invert the that. I.e. have
> HAS_VIRT_TO_BUS in arch/*/Kconfig for the few architectures that have
> that stuff.
Currently, that would mark x86_64 as HAS_VIRT_TO_BUS, while 64 bit powerpc
would be NO_VIRT_TO_BUS. I think they really should be the same, probably
like the other 64 bit targets, which means:
* If CONFIG_IOMMU is disabled, provide a __deprecated inline function that
maps virt_to_bus to virt_to_phys, and allow building drivers that use it.
* If we build with CONFIG_IOMMU enabled, but don't support disabling the
iommu, have no declaration for virt_to_bus at all, and disable the users
in Kconfig
* If the usage of the iommu is determined at run time, warn about users
of virt_to_bus at run time if it is enabled.
It could look like this
/* mm/memory.c or somewhere */
#if defined(CONFIG_HAS_VIRT_TO_BUS) && defined(CONFIG_IOMMU)
unsigned long virt_to_bus(void *virt)
{
WARN_ON(iommu_enabled);
return __virt_to_bus(virt);
}
#endif
/* include/linux/io.h */
#ifndef __virt_to_bus
#define __virt_to_bus virt_to_phys /* some architectures need
their own __virt_to_bus */
#endif
#ifdef CONFIG_HAS_VIRT_TO_BUS
#ifdef CONFIG_IOMMU
extern __deprecated unsigned long virt_to_bus(void *);
#else
static inline __deprecated unsigned long virt_to_bus(void *virt)
{
return __virt_to_bus(virt);
}
#endif
#endif
Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists