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

[Arnd Bergmann]

On Monday 18 May 2009, FUJITA Tomonori wrote:
> 
> NACK'ed, sorry.

I had no idea how hard it would get to fix a simple
allyesconfig build error. This is the third time
that a new approach to getting ATA to build on all
platforms is gets a NAK...

> - these idndef tricks are really ugly and wrong.
> - these functions are not generic at all.

I was trying to do two things at once:

- provide a default implementation for each function
  that an architecture can override, therefore the
  #ifdef magic.
- Have a minimal working implementation of the API
  that at least makes sense for architectures that
  do not support DMA, but want to share some of the
  code.

Ten of the existing architectures simply try do a
linear mapping, and that should easily be possible
in a generic way not too different from what I posted.
Would you agree to a patch that works with the same
code on e.g. arm, microblaze, mn10300 and sh and
uses only a few #ifdefs?

> - it's confusing to have two ways to handle this issue;
> dma-mapping-broken.h and dma-mapping.h.

We actually already have three ways to handle this right
now:

- dma-mapping-broken.h:
  only used on Sun3 m68k, i.e. not interesting any more,
  plus it does not solve the question of how to build
  ATA drivers on architectures without DMA.
- selecting NO_DMA:
  This works fine for everything except ATA. All other
  drivers using dma-mapping.h either depend on HAS_DMA
  or sprinkle their files with #ifdef.
- adding a bogus dma-mapping.h: cris, um and microblaze
  currently set HAS_DMA but add a dma-mapping.h that
  allows stuff to compile but cannot actually work.

I think that dma-mapping-broken.h has served its purpose
and we should now have two implementations in asm-generic,
the one you posted recently for ia64, x86, parisc, powerpc
and sparc64 and one for all architectures that only have
linear mappings. The version I posted is certainly not
generic enough for those, but I can keep improving it.

	Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/