Unfortunately, this patch caused several regressions at au0828 and
snd-usb-audio, like this one:
	https://bugzilla.kernel.org/show_bug.cgi?id=115561

It also showed several troubles at the MC core that handles pretty
poorly the memory protections and data lifetime management.

So, better to revert it and fix the core before reapplying this
change.

This reverts commit aebb2b89 ("[media] sound/usb: Use Media
Controller API to share media resources")'
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Change ALSA driver to use Media Controller API to share media resources
with DVB and V4L2 drivers on a AU0828 media device. Media Controller
specific initialization is done after sound card is registered. ALSA
creates Media interface and entity function graph nodes for Control,
Mixer, PCM Playback, and PCM Capture devices.

snd_usb_hw_params() will call Media Controller enable source handler
interface to request the media resource. If resource request is
granted, it will release it from snd_usb_hw_free(). If resource is
busy, -EBUSY is returned.

Media specific cleanup is done in usb_audio_disconnect().
Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This patch adds a new option "quirk_alias" to snd-usb-audio driver for
allowing user to pass the quirk alias list.  A quirk alias consists of
a string form like 0123abcd:5678beef, which makes to apply a quirk to
a device with USB ID 0123:abcd treated as if it were 5678:beef.
This feature is useful to test an existing quirk, typically for a
newer model of the same vendor, without patching / rebuilding the
kernel driver.

The current implementation is fairly simplistic: since there is no API
for matching a usb_device_id to the given ID pair, it has an open code
to loop over the id table and matches only with vendor:product pair.
So far, this is OK, as all existing entries are with vendor:product
pairs, indeed.  Once when we have another matching entry, however,
we'd need to update get_alias_quirk() as well.

Note that this option is provided only for testing / development.  If
you want to have a proper support, contact to upstream for adding the
matching quirk in the driver code statically.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is a preliminary patch for the later change to allow a better
quirk ID management.  In the current USB-audio code, there are a few
places looking at usb_device idVendor and idProduct fields directly
even though we have already a static member in snd_usb_audio.usb_id.
This patch modifies such codes to refer to the latter field.

For achieving this, two slightly intensive changes have been done:
- The snd_usb_audio object is set/reset via dev_getdrv() for the given
  USB device; it's needed for minimizing the changes for some existing
  quirks that take only usb_device object.

- __snd_usbmidi_create() is introduced to receive the pre-given usb_id
  argument.  The exported snd_usbmidi_create() is unchanged by calling
  this new function internally.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA PCM may still have a leftover instance after disconnection and
it delays its release.  The problem is that the PCM close code path of
USB-audio driver has a call of snd_usb_autosuspend().  This involves
with the call of usb_autopm_put_interface() and it may lead to a
kernel Oops due to the NULL object like:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000190
 IP: [<ffffffff815ae7ef>] usb_autopm_put_interface+0xf/0x30 PGD 0
 Call Trace:
  [<ffffffff8173bd94>] snd_usb_autosuspend+0x14/0x20
  [<ffffffff817461bc>] snd_usb_pcm_close.isra.14+0x5c/0x90
  [<ffffffff8174621f>] snd_usb_playback_close+0xf/0x20
  [<ffffffff816ef58a>] snd_pcm_release_substream.part.36+0x3a/0x90
  [<ffffffff816ef6b3>] snd_pcm_release+0xa3/0xb0
  [<ffffffff816debb0>] snd_disconnect_release+0xd0/0xe0
  [<ffffffff8114d417>] __fput+0x97/0x1d0
  [<ffffffff8114d589>] ____fput+0x9/0x10
  [<ffffffff8109e452>] task_work_run+0x72/0x90
  [<ffffffff81088510>] do_exit+0x280/0xa80
  [<ffffffff8108996a>] do_group_exit+0x3a/0xa0
  [<ffffffff8109261f>] get_signal+0x1df/0x540
  [<ffffffff81040903>] do_signal+0x23/0x620
  [<ffffffff8114c128>] ? do_readv_writev+0x128/0x200
  [<ffffffff810012e1>] prepare_exit_to_usermode+0x91/0xd0
  [<ffffffff810013ba>] syscall_return_slowpath+0x9a/0x120
  [<ffffffff817587cd>] ? __sys_recvmsg+0x5d/0x70
  [<ffffffff810d2765>] ? ktime_get_ts64+0x45/0xe0
  [<ffffffff8115dea0>] ? SyS_poll+0x60/0xf0
  [<ffffffff818d2327>] int_ret_from_sys_call+0x25/0x8f

We have already a check of disconnection in snd_usb_autoresume(), but
the check is missing its counterpart.  The fix is just to put the same
check in snd_usb_autosuspend(), too.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In theory, the device may get suspended even at runtime PM suspend.
Currently we don't save the mixer state for autopm, and it may bring
inconsistency.

This patch removes the special handling for autosuspend.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We can use active refcount for preventing autopm during probe.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

After the recent fix of runtime PM for USB-audio driver, we got a
lockdep warning like:

  =============================================
  [ INFO: possible recursive locking detected ]
  4.2.0-rc8+ #61 Not tainted
  ---------------------------------------------
  pulseaudio/980 is trying to acquire lock:
   (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
  but task is already holding lock:
   (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]

This comes from snd_usb_autoresume() invoking down_read() and it's
used in a nested way.  Although it's basically safe, per se (as these
are read locks), it's better to reduce such spurious warnings.

The read lock is needed to guarantee the execution of "shutdown"
(cleanup at disconnection) task after all concurrent tasks are
finished.  This can be implemented in another better way.

Also, the current check of chip->in_pm isn't good enough for
protecting the racy execution of multiple auto-resumes.

This patch rewrites the logic of snd_usb_autoresume() & co; namely,
- The recursive call of autopm is avoided by the new refcount,
  chip->active.  The chip->in_pm flag is removed accordingly.
- Instead of rwsem, another refcount, chip->usage_count, is introduced
  for tracking the period to delay the shutdown procedure.  At
  the last clear of this refcount, wake_up() to the shutdown waiter is
  called.
- The shutdown flag is replaced with shutdown atomic count; this is
  for reducing the lock.
- Two new helpers are introduced to simplify the management of these
  refcounts; snd_usb_lock_shutdown() increases the usage_count, checks
  the shutdown state, and does autoresume.  snd_usb_unlock_shutdown()
  does the opposite.  Most of mixer and other codes just need this,
  and simply returns an error if it receives an error from lock.

Fixes: 9003ebb1 ('ALSA: usb-audio: Fix runtime PM unbalance')
Reported-and-tested-by: NAlexnader Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The fix for deadlock in PM in commit [1ee23fe0: ALSA: usb-audio:
Fix deadlocks at resuming] introduced a new check of in_pm flag.
However, the brainless patch author evaluated it in a wrong way
(logical AND instead of logical OR), thus usb_autopm_get_interface()
is wrongly called at probing, leading to unbalance of runtime PM
refcount.

This patch fixes it by correcting the logic.
Reported-by: NHans Yang <hansy@nvidia.com>
Fixes: 1ee23fe0 ('ALSA: usb-audio: Fix deadlocks at resuming')
Cc: <stable@vger.kernel.org> [v3.15+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some USB-audio devices show weird sysfs warnings at disconnecting the
devices, e.g.
 usb 1-3: USB disconnect, device number 3
 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 973 at fs/sysfs/group.c:216 device_del+0x39/0x180()
 sysfs group ffffffff8183df40 not found for kobject 'midiC1D0'
 Call Trace:
  [<ffffffff814a3e38>] ? dump_stack+0x49/0x71
  [<ffffffff8103cb72>] ? warn_slowpath_common+0x82/0xb0
  [<ffffffff8103cc55>] ? warn_slowpath_fmt+0x45/0x50
  [<ffffffff813521e9>] ? device_del+0x39/0x180
  [<ffffffff81352339>] ? device_unregister+0x9/0x20
  [<ffffffff81352384>] ? device_destroy+0x34/0x40
  [<ffffffffa00ba29f>] ? snd_unregister_device+0x7f/0xd0 [snd]
  [<ffffffffa025124e>] ? snd_rawmidi_dev_disconnect+0xce/0x100 [snd_rawmidi]
  [<ffffffffa00c0192>] ? snd_device_disconnect+0x62/0x90 [snd]
  [<ffffffffa00c025c>] ? snd_device_disconnect_all+0x3c/0x60 [snd]
  [<ffffffffa00bb574>] ? snd_card_disconnect+0x124/0x1a0 [snd]
  [<ffffffffa02e54e8>] ? usb_audio_disconnect+0x88/0x1c0 [snd_usb_audio]
  [<ffffffffa015260e>] ? usb_unbind_interface+0x5e/0x1b0 [usbcore]
  [<ffffffff813553e9>] ? __device_release_driver+0x79/0xf0
  [<ffffffff81355485>] ? device_release_driver+0x25/0x40
  [<ffffffff81354e11>] ? bus_remove_device+0xf1/0x130
  [<ffffffff813522b9>] ? device_del+0x109/0x180
  [<ffffffffa01501d5>] ? usb_disable_device+0x95/0x1f0 [usbcore]
  [<ffffffffa014634f>] ? usb_disconnect+0x8f/0x190 [usbcore]
  [<ffffffffa0149179>] ? hub_thread+0x539/0x13a0 [usbcore]
  [<ffffffff810669f5>] ? sched_clock_local+0x15/0x80
  [<ffffffff81066c98>] ? sched_clock_cpu+0xb8/0xd0
  [<ffffffff81070730>] ? bit_waitqueue+0xb0/0xb0
  [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
  [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
  [<ffffffff8105973e>] ? kthread+0xce/0xf0
  [<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0
  [<ffffffff814a8b7c>] ? ret_from_fork+0x7c/0xb0
  [<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0
 ---[ end trace 40b1928d1136b91e ]---

This comes from the fact that usb-audio driver may receive the
disconnect callback multiple times, per each usb interface.  When a
device has both audio and midi interfaces, it gets called twice, and
currently the driver tries to release resources at the last call.
At this point, the first parent interface has been already deleted,
thus deleting a child of the first parent hits such a warning.

For fixing this problem, we need to call snd_card_disconnect() and
cancel pending operations at the very first disconnect while the
release of the whole objects waits until the last disconnect call.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80931Reported-and-tested-by: NTomas Gayoso <tgayoso@gmail.com>
Reported-and-tested-by: NChris J Arges <chris.j.arges@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

Some functions in mixer.c and endpoint.c receive list_head instead of
the object itself.  This is not obvious and rather error-prone.  Let's
pass the proper object directly instead.

The functions in midi.c still receive list_head and this can't be
changed since the object definition isn't exposed to the outside of
midi.c, so left as is.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The usb-audio probe and disconnect functions have been split just for
adapting the (new!) API at 2.5 kernel time.  We left them until now,
partly because we wanted to build with the pretty old kernels in the
external alsa-driver tree.  But the support of such old kernels has
been longly stopped, so it's good time to clean up this mess.

One good point by this cleanup is that now the probe function returns
a proper error code instead of only -EIO.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

sound/usb/card.c registers USB suspend and resume but did not previously
kill the input URBs. This means that USB MIDI devices left open across
suspend/resume had non-functional input (output still usually worked,
but it looks like that is another issue). Before this change, we would
get ESHUTDOWN for each of the input URBs at suspend time, killing input.
Signed-off-by: NAdam Goode <agoode@google.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When a USB-audio device is disconnected while PCM is still running, we
still see some race: the disconnect callback calls
snd_usb_endpoint_free() that calls release_urbs() and then kfree()
while a PCM stream would be closed at the same time and calls
stop_endpoints() that leads to wait_clear_urbs().  That is, the EP
object might be deallocated while a PCM stream is syncing with
wait_clear_urbs() with the same EP.

Basically calling multiple wait_clear_urbs() would work fine, also
calling wait_clear_urbs() and release_urbs() would work, too, as
wait_clear_urbs() just reads some fields in ep.  The problem is the
succeeding kfree() in snd_pcm_endpoint_free().

This patch moves out the EP deallocation into the later point, the
destructor callback.  At this stage, all PCMs must have been already
closed, so it's safe to free the objects.
Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent addition of the USB audio mixer suspend/resume may lead to
deadlocks when the driver tries to call usb_autopm_get_interface()
recursively, since the function tries to sync with the finish of the
other calls.  For avoiding it, introduce a flag indicating the resume
operation and avoids the recursive usb_autopm_get_interface() calls
during the resume.
Reported-and-tested-by: NBryan Quigley <gquigs@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The suspend callback of usb-audio driver may be called multiple times
per suspend when multiple USB interfaces are bound to a single sound
card instance.  In such a case, it's superfluous to save the mixer
values multiple times.  This patch fixes it by checking the counter.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Convert with dev_err() and co from snd_printk(), etc.
As there are too deep indirections (e.g. ep->chip->dev->dev),
a few new local macros, usb_audio_err() & co, are introduced.

Also, the device numbers in some messages are dropped, as they are
shown in the prefix automatically.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Also remove superfluous snd_card_set_dev() calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Implement reset_resume callback so that the mixer values are properly
restored.  Still no boot quirks are called, so it might not work well
on some devices.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

module_usb_driver makes code simpler by removing the boilerplate.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch updates snd_usb_audio_create also support devices whose
speed == USB_SPEED_WIRELESS.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch changes the way URBs are allocated and their sizes are
determined for PCM playback in the snd-usb-audio driver.  Currently
the driver allocates too few URBs for endpoints that don't use
implicit sync, making underruns more likely to occur.  This may be a
holdover from before I/O delays could be measured accurately; in any
case, it is no longer necessary.

The patch allocates as many URBs as possible, subject to four
limitations:

	The total number of URBs for the endpoint is not allowed to
	exceed MAX_URBS (which the patch increases from 8 to 12).

	The total number of packets per URB is not allowed to exceed
	MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
	decreased from 20 to 6.

	The total duration of queued data is not allowed to exceed
	MAX_QUEUE, which is decreased from 24 ms to 18 ms.

	The total number of ALSA frames in the output queue is not
	allowed to exceed the ALSA buffer size.

The last requirement is the hardest to implement.  Currently the
number of URBs needed to fill a buffer cannot be determined in
advance, because a buffer contains a fixed number of frames whereas
the number of frames in an URB varies to match shifts in the device's
clock rate.  To solve this problem, the patch changes the logic for
deciding how many packets an URB should contain.  Rather than using as
many as possible without exceeding an ALSA period boundary, now the
driver uses only as many packets as needed to transfer a predetermined
number of frames.  As a result, unless the device's clock has an
exceedingly variable rate, the number of URBs making up each period
(and hence each buffer) will remain constant.

The overall effect of the patch is that playback works better in
low-latency settings.  The user can still specify values for
frames/period and periods/buffer that exceed the capabilities of the
hardware, of course.  But for values that are within those
capabilities, the performance will be improved.  For example, testing
shows that a high-speed device can handle 32 frames/period and 3
periods/buffer at 48 KHz, whereas the current driver starts to get
glitchy at 64 frames/period and 2 periods/buffer.

A side effect of these changes is that the "nrpacks" module parameter
is no longer used.  The patch removes it.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: NDaniel Mack <zonque@gmail.com>
Tested-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the Android firmware enables the audio interfaces in accessory
mode, it always declares in the control interface's baInterfaceNr array
that interfaces 0 and 1 belong to the audio function.  However, the
accessory interface itself, if also enabled, already is at index 0 and
shifts the actual audio interface numbers to 1 and 2, which prevents the
PCM streaming interface from being seen by the host driver.

To get the PCM interface interface to work, detect when the descriptors
point to the (for this driver useless) accessory interface, and redirect
to the correct one.
Reported-by: NJeremy Rosen <jeremy.rosen@openwide.fr>
Tested-by: NJeremy Rosen <jeremy.rosen@openwide.fr>
Cc: <stable@vger.kernel.org>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We've got strange errors in get_ctl_value() in mixer.c during
probing, e.g. on Hercules RMX2 DJ Controller:

  ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4
  ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4
  ....

It turned out that the culprit is autopm: snd_usb_autoresume() returns
-ENODEV when called during card->probing = 1.

Since the call itself during card->probing = 1 is valid, let's fix the
return value of snd_usb_autoresume() as success.
Reported-and-tested-by: NDaniel Schürmann <daschuer@mixxx.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a module param to disable auto clock selection.
This is provided for users that expect the audio stream to
fail when the clock source is invalid (e.g., the word clock
was unintentionally disconnected).
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Minor style fix, following a general code style in the kernel.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Change occurances of list_for_each into list_for_each_entry where
applicable.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The NuForce UDH-100 numbers its interfaces incorrectly, which makes the
interface associations come out wrong, which results in the driver
erroring out with the message "Audio class v2 interfaces need an
interface association".

Work around this by searching for the interface association descriptor
also in some other place where it might have ended up.
Reported-and-tested-by: NDave Helstroom <helstroom@google.com>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NAntonio Ospite <ao2@amarulasolutions.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The async unlink behavior has been working over years.  The option was
provided only as a workaround for 2.4.x kernel.  Let's get rid of it.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent change for USB-audio disconnection race fixes introduced a
mutex deadlock again.  There is a circular dependency between
chip->shutdown_rwsem and pcm->open_mutex, depicted like below, when a
device is opened during the disconnection operation:

A. snd_usb_audio_disconnect() ->
     card.c::register_mutex ->
       chip->shutdown_rwsem (write) ->
         snd_card_disconnect() ->
           pcm.c::register_mutex ->
             pcm->open_mutex

B. snd_pcm_open() ->
     pcm->open_mutex ->
       snd_usb_pcm_open() ->
         chip->shutdown_rwsem (read)

Since the chip->shutdown_rwsem protection in the case A is required
only for turning on the chip->shutdown flag and it doesn't have to be
taken for the whole operation, we can reduce its window in
snd_usb_audio_disconnect().
Reported-by: NJiri Slaby <jslaby@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Replace mutex with rwsem for codec->shutdown protection so that
concurrent accesses are allowed.

Also add the protection to snd_usb_autosuspend() and
snd_usb_autoresume(), too.
Reported-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent fix for USB suspend breakage moved the code to set up EP
from hw_params to prepare, but it means also the EP setup might be
called multiple times unnecessarily because the prepare callback can
be called multiple times without starting the stream (e.g. OSS
emulation).

This patch adds a new flag to struct snd_usb_substream indicating
whether the setup of EP is required, and do it only when necessary,
i.e. right after hw_params or suspend.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_usb_endpoint_free() frees the structure that contains its argument.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Cc: stable@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

With the previous commit that added the new streaming model, all
endpoint and streaming related code is now in endpoint.c, and pcm.c
only acts as a wrapper for handling the packet's payload.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is needed for new card-wide list operations.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NPaul Gortmaker <paul.gortmaker@windriver.com>

Before clearing the probing flag in the error exit path, check that the
chip pointer is not NULL.
Signed-off-by: NThomas Pfaff <tpfaff@gmx.net>
Cc: <stable@kernel.org> [2.6.39+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>