ALSA update broke Sparc

[David S. Miller]

Each platform uses a different number of arguments for
io_remap_page_range(), so you can't just blindly call it
from generic code.

However, sound/core/pcm_native.c is doing exactly that.

The reason each platform takes a different number of
args is that the "unsigned long" base address argument
is only 32-bits on 32-bit platforms yet on some of
such platforms I/O and physical memory addresses
are larger than 32-bits.

Sparc and Sparc64 use a "space" argument to provide this
upper 32-bits of information.

Also, what this PCM mmap'ing code is trying to do
is take I/O addresses and remap them into the process
address space.  pci_resource_start() values are not necessarily
suitable for passing around as physical addresses.  These
things are well defined when used with ioremap() but
that is it.  I don't know if we've defined it such that
passing these into io_remap_page_range() can be expected
to work.

In fact, because of the sparc 32-bit issue, I know it won't
work.  You'll need to have the full resource structure
available, as that's where we hide the upper 32-bits of
the physical address on sparc32.

This is really non-portable, what the PCM code is doing.
I would suggest, for the time being, to pass resources
around and then have an arch-defined macro which takes
the resource pointer and makes the appropriate io_remap_page_range()
call.

Can I make a small formal request of the ALSA folks?  Can you
at least setup a cross-compiler to make sure your ALSA merges
don't explode on sparc64?  As it stands, 1 out of every 2 ALSA
merges breaks the build on that platform.
-
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/