When OSS emulation is loaded on ISA SB AWE32 chip, we get now kernel
warnings like:
  WARNING: CPU: 0 PID: 2791 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x51/0x80()
  sysfs: cannot create duplicate filename '/devices/isa/sbawe.0/sound/card0/seq-oss-0-0'

It's because both emux synth and opl3 drivers try to register their
OSS device object with the same static index number 0.  This hasn't
been a big problem until the recent rewrite of device management code
(that exposes sysfs at the same time), but it's been an obvious bug.

This patch works around it just by using a different index number of
emux synth object.  There can be a more elegant way to fix, but it's
enough for now, as this code won't be touched so often, in anyway.

Reported-and-tested-by: Michael Shell <list1@michaelshell.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Build emux_proc.o and drop the unneeded ifdefs.
Replace the left CONFIG_PROC with the new CONFIG_SND_PROC_FS.

Along with this, fix the build of emux_oss.o in Makefile, too.

Signed-off-by: Takashi Iwai <tiwai@suse.de>

The OSS emulation in synth-emux helper has a potential AB/BA deadlock
at the simultaneous closing and opening:

  close ->
    snd_seq_release() ->
      sne_seq_free_client() ->
        snd_seq_delete_all_ports(): takes client->ports_mutex ->
	  port_delete() ->
	    snd_emux_unuse(): takes emux->register_mutex

  open ->
    snd_seq_oss_open() ->
      snd_emux_open_seq_oss(): takes emux->register_mutex ->
        snd_seq_event_port_attach() ->
	  snd_seq_create_port(): takes client->ports_mutex

This patch addresses the deadlock by reducing the rance taking
emux->register_mutex in snd_emux_open_seq_oss().  The lock is needed
for the refcount handling, so move it locally.  The calls in
emux_seq.c are already with the mutex, thus they are replaced with the
version without mutex lock/unlock.

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The emux-synth driver has a possible AB/BA mutex deadlock at unloading
the emu10k1 driver:

  snd_emux_free() ->
    snd_emux_detach_seq(): mutex_lock(&emu->register_mutex) ->
      snd_seq_delete_kernel_client() ->
        snd_seq_free_client(): mutex_lock(&register_mutex)

  snd_seq_release() ->
    snd_seq_free_client(): mutex_lock(&register_mutex) ->
      snd_seq_delete_all_ports() ->
        snd_emux_unuse(): mutex_lock(&emu->register_mutex)

Basically snd_emux_detach_seq() doesn't need a protection of
emu->register_mutex as it's already being unregistered.  So, we can
get rid of this for avoiding the deadlock.

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Signed-off-by: Takashi Iwai <tiwai@suse.de>

No functional change, refactoring with the standard helpers.

Signed-off-by: Takashi Iwai <tiwai@suse.de>

The snd_sf_free() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

There is a risk for memory leak in when something unexpected happens
and the function returns.

This was largely found by using a static code analysis program called cppcheck.

[fixed a typo of kfree() by tiwai]

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

These aren't modules, but they do make use of these macros, so
they will need export.h to get that definition.  Previously,
they got it via the implicit module.h inclusion.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Lots of sound drivers were getting module.h via the implicit presence
of it in <linux/device.h> but we are going to clean that up.  So
fix up those users now.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>