When a monitor stream is active, the next PCM stream access results in
EBUSY error because of the check in line6_stream_start().  Fix this by
just skipping the submission of pending URBs when the stream is
already running instead.

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

The usages of clamp() macro in sound/usb/line6/playback.c are just
wrong, the low and high values are swapped.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The address cannot be negative so make it unsigned.  Also, an unsigned
int is always sufficient for the length, so no need to overdo it with a
size_t.  Finally, add in range checks to see if the values passed in
actually fit where they are used.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The firmware version is a single byte so have the variable type agree.
Since the address to this member is passed to the read function, using
an int is not even portable.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The serial number (aka ESN) is a 32-bit value.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Put an upper bound on how long we will wait for the device to respond to
a read/write request (i.e., 100 milliseconds) and return an error if
this is reached.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The device indicates the result of a read/write operation by making the
status available on a subsequent request from the driver.  This is not
ready immediately, though, so the driver is currently slamming the
device with hundreds of pointless requests before getting the expected
response.  Add a two millisecond delay before each attempt.  This is
approximately the behavior observed with version 4.2.7.1 of the Windows
driver.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Provide a unique name for each driver instead of using "line6usb" for
all of them.  This will allow for different configurations based on the
driver type.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It is unlikely this function would ever be used in a context without a
pointer to a `struct usb_line6_toneport', so grab the device type from
it rather than having the caller do it.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a predicate for testing if the device supports source selection to
make the conditional logic around this a bit cleaner.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

Use the new helper function to create sysfs entries in the card more
gracefully without races.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

line6_start_timer passes an unsigned int as argument to be used in mod_timer
which is then used by mod_timer as unsigned long, this just fixes up the
argument type. This change helps make static code checkers happy.
Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is only an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var).
Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use of this function ended with commits 3e58c868 ("staging: line6:
drop midi_mask_receive") and af89d289 ("staging: line6: drop
midi_mask_transmit".)

[Removed the corresponding line in midibuf.h, too -- tiwai]
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This function has not been used since merging the driver into the kernel
(and a good while before that.)

[Removed the corresponding line in midibuf.h, too -- tiwai]
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It's just superfluous and doesn't give any better readability.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

PODxt Live Variax doesn't have PCM and HWMON but only MIDI.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It's identical with struct usb_line6.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Most of them are rather relevant with the definitions in driver.h,
and there are only a few lines, so just rip it off.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The definition is no longer used.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just reformatting the comments and typos fixed, no functional
changes.  Particularly,
- avoid the kerneldoc marker "/**",
- reduce multiple comment lines into single lines,
- corrected wrongly referred function names
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Both playback and capture callbacks are identical, so let's merge
them.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current code deals with the stream start / stop solely via
line6_pcm_acquire() and line6_pcm_release().  This was (supposedly)
intended to avoid the races, but it doesn't work as expected.  The
concurrent acquire and release calls can be performed without proper
protections, thus this might result in memory corruption.
Furthermore, we can't take a mutex to protect the whole function
because it can be called from the PCM trigger callback that is an
atomic context.  Also spinlock isn't appropriate because the function
allocates with kmalloc with GFP_KERNEL.  That is, these function just
lead to singular problems.

This is an attempt to reduce the existing races.  First off, separate
both the stream buffer management and the stream URB management.  The
former is protected via a newly introduced state_mutex while the
latter is protected via each line6_pcm_stream lock.

Secondly, the stream state are now managed in opened and running bit
flags of each line6_pcm_stream.  Not only this a bit clearer than
previous combined bit flags, this also gives a better abstraction.
These rewrites allows us to make common hw_params and hw_free
callbacks for both playback and capture directions.

For the monitor and impulse operations, still line6_pcm_acquire() and
line6_pcm_release() are used.  They call internally the corresponding
functions for both playback and capture streams with proper lock or
mutex.  Unlike the previous versions, these function don't take the
bit masks but the only single type value.  Also they are supposed to
be applied only as duplex operations.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Clearing prev_fsize in line6_pcm_acquire() is pretty racy.
This can be called at any time while the stream is being played.
Rather better to clear prev_fbuf and prev_fsize at the proper place
like the stream stop for capture, and just after copying the monitor /
impulse data inside the spinlock.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The impulse and monitor handling in submit_audio_out_urb() isn't
protected thus this can be racy with the capture stream handling.
This patch extends the range to protect via each stream's spinlock
(now the whole submit_audio_*_urb() are covered), and take the capture
stream lock additionally for the impulse and monitor handling part.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Move the check of multi configurations before snd_card_new() as a
short path, and reduce superfluous pointer references.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of allocating the private data individually in each driver's
probe at first, let snd_card_new() allocate the data that is called in
line6_probe().  This simplifies the primary probe functions.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The interface argument is used just for retrieving the assigned
device, which can be already found in line6->ifcdev.  Drop them from
the callbacks.  Also, pass the usb id to private_init so that the
driver can deal with it there.  This is a preliminary work for the
further cleanup to move the whole allocation into driver.c.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A minor optimization; while pausing, the driver just copies the zero
that doesn't need any volume changes.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The PCM stream buffer allocation and free are identical for both
playback and capture streams.  Provide single helper functions.
These are used only in pcm.c, thus they can be even static.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is the last remaining snd_printk() usage in this driver.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The codes to unlink and sync URBs are identical for both playback and
capture streams.  Consolidate to single helper functions.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Introduce a new line6_pcm_stream structure and group individual
fields of snd_line6_pcm struct to playback and capture groups.

This patch itself just does rename and nothing else.  More
meaningful cleanups based on these fields shuffling will follow.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

If the problem still really remains, we should fix it instead of
papering over it like this...
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Using a decremental loop without particular reasons worsens the
readability a lot.  Use incremental loops instead.
Tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>