linux-kernel - Re: [PATCH] asm-generic: add a dma-mapping.h file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 May 2009 08:22:34 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	jgarzik@...ox.com
Cc:	arnd@...db.de, hancockrwd@...il.com, htejun@...il.com,
	fujita.tomonori@....ntt.co.jp, alan@...rguk.ukuu.org.uk,
	flar@...andria.com, schmitz@...phys.uni-duesseldorf.de,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	takata@...ux-m32r.org, geert@...ux-m68k.org,
	linux-m68k@...r.kernel.org, ysato@...rs.sourceforge.jp
Subject: Re: [PATCH] asm-generic: add a dma-mapping.h file

On Mon, 18 May 2009 18:54:49 -0400
Jeff Garzik <jgarzik@...ox.com> wrote:

> Arnd Bergmann wrote:
> > h8300 and m32r currently do not provide a DMA mapping API
> > and therefore cannot use the ATA drivers. This adds a
> > generic version of dma-mapping.h for architectures that
> > have none or very minimal actual support for DMA in hardware
> > and makes the two architectures use it.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@...db.de>
> > ---
> > On Sunday 17 May 2009 20:05:54 Jeff Garzik wrote:
> > 
> >> That's what needs to happen.  We provide no-op functions for e.g. PCI 
> >> and x86 DMI, for platforms where this support does not exist.
> >>
> >> Pretty much all architectures support some form of ATA.  m68k, m32r, 
> >> h8300 and microblaze all have IDE interface, which means that libata 
> >> needs to work on that platform.
> >>
> >> The only !ATA arch in the entire kernel is s390, AFAICT.
> > 
> > m68k only defines NO_DMA for Sun3 and Dragonball. Sun3 does
> > not have ATA, Dragonball could probably just enable HAS_DMA.
> > 
> > ---
> >  arch/h8300/Kconfig                   |    2 +-
> >  arch/h8300/include/asm/dma-mapping.h |    1 +
> >  arch/m32r/Kconfig                    |    2 +-
> >  arch/m32r/include/asm/dma-mapping.h  |    1 +
> >  include/asm-generic/dma-mapping.h    |  399 ++++++++++++++++++++++++++++++++++
> >  5 files changed, 403 insertions(+), 2 deletions(-)
> >  create mode 100644 arch/h8300/include/asm/dma-mapping.h
> >  create mode 100644 arch/m32r/include/asm/dma-mapping.h
> >  create mode 100644 include/asm-generic/dma-mapping.h
> 
> My main comment is a bit non-specific...   I tend to think that all 
> no-dma platforms should provide an API whose implementation always 
> returns errors, e.g. an inlined version of dma-mapping-broken.h.
> 
> That sort of setup permits the compiler's dead code elimination to work 
> on these no-dma platforms, while not crapping up the libata code with a 
> bunch of ifdefs.

Just adding one ifdef to libata.h works? What libata needs is just
wrapping dma_map_sg and dma_unmap_sg like the old ide stack does.

I'm not against the idea of an inlined version of dma-mapping-broken.h
but having two ways to handle this issue is a bit confusing; so far
what we done to handle this problem is using NO_DMA, like SCSI-ml
does, not putting the dma code in non-architecture code and having
something like scsi_lib_dma.c.

Is it theoretically correct that the dma mapping API lives in low
level drivers instead of libata-core (like how SCSI-ml does)?
--
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/