[patch 3/4] x86: only compile floppy driver if CONFIG_ISA_DMA_API is enabled
David Rientjes
CONFIG_ISA_DMA_API, specifically claim_dma_lock(), release_dma_lock(),
request_dma(), and free_dma(). Thus, there's a strict dependency on the
config option and the driver should only be loaded if the kernel supports
ISA-style DMA.
Signed-off-by: David Rientjes <rien...@google.com>
---
arch/x86/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -139,7 +139,7 @@ config GENERIC_GPIO
bool
config ARCH_MAY_HAVE_PC_FDC
- def_bool y
+ def_bool ISA_DMA_API
config RWSEM_GENERIC_SPINLOCK
def_bool !X86_XADD
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Rientjes
configurable. x86 utilizes the generic ISA DMA allocator from
kernel/dma.c, so require it only when CONFIG_ISA_DMA_API is enabled.
Disabling CONFIG_ISA_DMA_API is dependent on x86_64 since those machines
do not have ISA slots and benefit the most from disabling the option (and
on CONFIG_EXPERT as required by H. Peter Anvin).
When disabled, this also avoids declaring claim_dma_lock(),
release_dma_lock(), request_dma(), and free_dma() since those interfaces
will no longer be provided.
Signed-off-by: David Rientjes <rien...@google.com>
---
arch/x86/Kconfig | 10 +++++++---
arch/x86/include/asm/dma.h | 6 +++++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -119,7 +119,7 @@ config NEED_SG_DMA_LENGTH
def_bool y
config GENERIC_ISA_DMA
- def_bool y
+ def_bool ISA_DMA_API
config GENERIC_IOMAP
def_bool y
@@ -2000,9 +2000,13 @@ source "drivers/pci/pcie/Kconfig"
source "drivers/pci/Kconfig"
-# x86_64 have no ISA slots, but do have ISA-style DMA.
+# x86_64 have no ISA slots, but can have ISA-style DMA.
config ISA_DMA_API
- def_bool y
+ bool "ISA-style DMA support" if (X86_64 && EXPERT)
+ default y
+ help
+ Enables ISA-style DMA support for devices requiring such controllers.
+ If unsure, say Y.
if X86_32
diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h
--- a/arch/x86/include/asm/dma.h
+++ b/arch/x86/include/asm/dma.h
@@ -151,6 +151,7 @@
#define DMA_AUTOINIT 0x10
+#ifdef CONFIG_ISA_DMA_API
extern spinlock_t dma_spin_lock;
static inline unsigned long claim_dma_lock(void)
@@ -164,6 +165,7 @@ static inline void release_dma_lock(unsigned long flags)
{
spin_unlock_irqrestore(&dma_spin_lock, flags);
}
+#endif /* CONFIG_ISA_DMA_API */
/* enable/disable a specific DMA channel */
static inline void enable_dma(unsigned int dmanr)
@@ -303,9 +305,11 @@ static inline int get_dma_residue(unsigned int dmanr)
}
-/* These are in kernel/dma.c: */
+/* These are in kernel/dma.c because x86 uses CONFIG_GENERIC_ISA_DMA */
+#ifdef CONFIG_ISA_DMA_API
extern int request_dma(unsigned int dmanr, const char *device_id);
extern void free_dma(unsigned int dmanr);
+#endif
/* From PCI */
David Rientjes
claim_dma_lock() and release_dma_lock(). Thus, there's a strict
dependency on the config option and the module should only be loaded if
the kernel supports ISA-style DMA.
Signed-off-by: David Rientjes <rien...@google.com>
---
arch/x86/kernel/Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -41,12 +41,13 @@ obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o
obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
obj-$(CONFIG_X86_64) += syscall_64.o vsyscall_64.o
obj-y += bootflag.o e820.o
-obj-y += pci-dma.o quirks.o i8237.o topology.o kdebugfs.o
+obj-y += pci-dma.o quirks.o topology.o kdebugfs.o
obj-y += alternative.o i8253.o pci-nommu.o hw_breakpoint.o
obj-y += tsc.o io_delay.o rtc.o
obj-y += pci-iommu_table.o
obj-y += resource.o
+obj-$(CONFIG_ISA_DMA_API) += i8237.o
obj-$(CONFIG_X86_TRAMPOLINE) += trampoline.o
obj-y += process.o
obj-y += i387.o xsave.o
Arnd Bergmann
>
> Not all 64-bit systems require ISA-style DMA, so allow it to be
> configurable. x86 utilizes the generic ISA DMA allocator from
> kernel/dma.c, so require it only when CONFIG_ISA_DMA_API is enabled.
>
> Disabling CONFIG_ISA_DMA_API is dependent on x86_64 since those machines
> do not have ISA slots and benefit the most from disabling the option (and
> on CONFIG_EXPERT as required by H. Peter Anvin).
But the x86_64 machines can also run 32 bit kernel, and I would expect
that they don't need ISA DMA in that configuration either.
I think it would make sense to let the CONFIG_EXPERT user disable
DMA for 32 bit as well.
Arnd
David Rientjes
> But the x86_64 machines can also run 32 bit kernel, and I would expect
> that they don't need ISA DMA in that configuration either.
>
> I think it would make sense to let the CONFIG_EXPERT user disable
> DMA for 32 bit as well.
>
Hmm, ok, I originally thought that allowing it to be disabled for 32-bit
would cause people to regret it later when using pnp, for instance, and
finding they need to require ISA-style DMA support for their devices. I
agree, though, that allowing CONFIG_EXPERT to disable it even for 32-bit
sounds appropriate since they ultimately know what devices they're
limiting their kernel from using. Thanks!
x86: allow CONFIG_ISA_DMA_API to be disabled
Not all 64-bit systems require ISA-style DMA, so allow it to be
configurable. x86 utilizes the generic ISA DMA allocator from
kernel/dma.c, so require it only when CONFIG_ISA_DMA_API is enabled.
64-bit systems may compile a 32-bit kernel, so allow disabling it for
i386 as well.
Disabling CONFIG_ISA_DMA_API is dependent on CONFIG_EXPERT as required by
H. Peter Anvin.
When disabled, this also avoids declaring claim_dma_lock(),
release_dma_lock(), request_dma(), and free_dma() since those interfaces
will no longer be provided.
Signed-off-by: David Rientjes <rien...@google.com>
---
arch/x86/Kconfig | 10 +++++++---
arch/x86/include/asm/dma.h | 6 +++++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -119,7 +119,7 @@ config NEED_SG_DMA_LENGTH
def_bool y
config GENERIC_ISA_DMA
- def_bool y
+ def_bool ISA_DMA_API
config GENERIC_IOMAP
def_bool y
@@ -2000,9 +2000,13 @@ source "drivers/pci/pcie/Kconfig"
source "drivers/pci/Kconfig"
-# x86_64 have no ISA slots, but do have ISA-style DMA.
+# x86_64 have no ISA slots, but can have ISA-style DMA.
config ISA_DMA_API
- def_bool y
+ bool "ISA-style DMA support" if EXPERT
David Rientjes
provided by CONFIG_ISA_DMA_API, specifically request_dma() and
free_dma(). Thus, there's a strict dependency on the config option and
limits IORESOURCE_DMA only to architectures that support ISA-style DMA.
ia64 is not one of those architectures, so pnp_check_dma() no longer
needs to be special-cased for that architecture.
pnp_assign_resources() will now return -EINVAL if IORESOURCE_DMA is
attempted on such a kernel.
Signed-off-by: David Rientjes <rien...@google.com>
---
drivers/pnp/base.h | 2 ++
drivers/pnp/manager.c | 7 ++++++-
drivers/pnp/resource.c | 7 ++-----
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/pnp/base.h b/drivers/pnp/base.h
--- a/drivers/pnp/base.h
+++ b/drivers/pnp/base.h
@@ -142,7 +142,9 @@ void __pnp_remove_device(struct pnp_dev *dev);
int pnp_check_port(struct pnp_dev *dev, struct resource *res);
int pnp_check_mem(struct pnp_dev *dev, struct resource *res);
int pnp_check_irq(struct pnp_dev *dev, struct resource *res);
+#ifdef CONFIG_ISA_DMA_API
int pnp_check_dma(struct pnp_dev *dev, struct resource *res);
+#endif
char *pnp_resource_type_name(struct resource *res);
void dbg_pnp_show_resources(struct pnp_dev *dev, char *desc);
diff --git a/drivers/pnp/manager.c b/drivers/pnp/manager.c
--- a/drivers/pnp/manager.c
+++ b/drivers/pnp/manager.c
@@ -171,6 +171,7 @@ __add:
return 0;
}
+#ifdef CONFIG_ISA_DMA_API
static int pnp_assign_dma(struct pnp_dev *dev, struct pnp_dma *rule, int idx)
{
struct resource *res, local_res;
@@ -210,6 +211,7 @@ __add:
pnp_add_dma_resource(dev, res->start, res->flags);
return 0;
}
+#endif /* CONFIG_ISA_DMA_API */
void pnp_init_resources(struct pnp_dev *dev)
{
@@ -234,7 +236,8 @@ static void pnp_clean_resource_table(struct pnp_dev *dev)
static int pnp_assign_resources(struct pnp_dev *dev, int set)
{
struct pnp_option *option;
- int nport = 0, nmem = 0, nirq = 0, ndma = 0;
+ int nport = 0, nmem = 0, nirq = 0;
+ int ndma __maybe_unused = 0;
int ret = 0;
pnp_dbg(&dev->dev, "pnp_assign_resources, try dependent set %d\n", set);
@@ -256,9 +259,11 @@ static int pnp_assign_resources(struct pnp_dev *dev, int set)
case IORESOURCE_IRQ:
ret = pnp_assign_irq(dev, &option->u.irq, nirq++);
break;
+#ifdef CONFIG_ISA_DMA_API
case IORESOURCE_DMA:
ret = pnp_assign_dma(dev, &option->u.dma, ndma++);
break;
+#endif
default:
ret = -EINVAL;
break;
diff --git a/drivers/pnp/resource.c b/drivers/pnp/resource.c
--- a/drivers/pnp/resource.c
+++ b/drivers/pnp/resource.c
@@ -409,9 +409,9 @@ int pnp_check_irq(struct pnp_dev *dev, struct resource *res)
return 1;
}
+#ifdef CONFIG_ISA_DMA_API
int pnp_check_dma(struct pnp_dev *dev, struct resource *res)
{
-#ifndef CONFIG_IA64
int i;
struct pnp_dev *tdev;
struct resource *tres;
@@ -466,11 +466,8 @@ int pnp_check_dma(struct pnp_dev *dev, struct resource *res)
}
return 1;
-#else
- /* IA64 does not have legacy DMA */
- return 0;
-#endif
}
+#endif /* CONFIG_ISA_DMA_API */
unsigned long pnp_resource_type(struct resource *res)
{
David Rientjes
> IORESOURCE_DMA cannot be assigned without utilizing the interface
> provided by CONFIG_ISA_DMA_API, specifically request_dma() and
> free_dma(). Thus, there's a strict dependency on the config option and
> limits IORESOURCE_DMA only to architectures that support ISA-style DMA.
>
> ia64 is not one of those architectures, so pnp_check_dma() no longer
> needs to be special-cased for that architecture.
>
> pnp_assign_resources() will now return -EINVAL if IORESOURCE_DMA is
> attempted on such a kernel.
>
> Signed-off-by: David Rientjes <rien...@google.com>
Are there any objections to merging this?