The implicit presence of module.h lured several users into
incorrectly thinking that they only needed/used modparam.h
but once we clean up the module.h presence, these will show
up as build failures, so fix 'em now.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
This header file exists only for some hacks to adapt alsa-driver
tree. It's useless for building in the kernel. Let's move a few
lines in it to sound/core.h and remove it.
With this patch, sound/driver.h isn't removed but has just a single
compile warning to include it. This should be really killed in
future.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there. Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.
To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.
Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm. I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix __devinit and __devexit issues with sound drivers.
Resolves MODPOST warnings similar to:
WARNING: sound/drivers/snd-dummy.o - Section mismatch: reference to .init.text:snd_dummy_probe from .data.rel.local between 'snd_dummy_driver' (at offset 0x0) and 'snd_dummy_controls'
WARNING: sound/drivers/snd-mtpav.o - Section mismatch: reference to .init.text:snd_mtpav_probe from .data.rel.local between 'snd_mtpav_driver' (at offset 0x0) and 'snd_mtpav_input'
WARNING: sound/drivers/snd-virmidi.o - Section mismatch: reference to .init.text:snd_virmidi_probe from .data.rel.local after 'snd_virmidi_driver' (at offset 0x0)
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
The last patch that tried to remove zero initializations of static
variables accidentally removed a not-quite-zero initialization too.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
This second one unregisters the platform device again when the probe is
unsuccesful for sound/drivers, sound/arm/sa11xx-uda1341.c and
sound/ppc/powermac.c. This gets them all.
Signed-off-by: Rene Herman <rene.herman@keyaccess.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
I previously only concerned myself with sound/isa. When I now checked
for more platform_device_register_simple() usages in ALSA I found a
couple more drivers that needed the same patches as already submitted
for all the ISA drivers.
This first one is the continue-on-iserr patch for sound/drivers. This
gets them all.
Signed-off-by: Rene Herman <rene.herman@keyaccess.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix the check of enable module option in probe of platform_device drivers.
It shouldn't break the loop but just ignore if enable[i] is false.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Modules: ALSA sequencer,Generic drivers
To allow increasing the maximum number of sound cards, we have to limit
the number of sequencer clients per card because client numbers are
still allocated statically.
Reducing the number of clients to four limits the number of sequencer
MIDI ports to 1024 per card.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
