kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: NHimanshu Jha <himanshujha199640@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

sh audio driver prints its presence at probe function but a proper
KERN_ prefix is missing.  Put KERN_INFO there as it's merely an
advertisement.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The usx2y driver has a debug printk code without proper KERN_ prefix.
On recent kernels, KERN_CONT prefix is mandatory for continued output
lines.  Put it properly.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The usb-audio driver has a debug printk code without proper KERN_
prefix.  On recent kernels, KERN_CONT prefix is mandatory for
continued output lines.  Put it properly.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The asihpi driver has a debug printk code without proper KERN_
prefix.  On recent kernels, KERN_CONT prefix is mandatory for
continued output lines.  Put it properly.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The vx driver has a debug printk code without proper KERN_ prefix.
On recent kernels, KERN_CONT prefix is mandatory for continued output
lines.  Put it properly.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The opl3 driver has a debug printk code without proper KERN_ prefix.
On recent kernels, KERN_CONT prefix is mandatory for continued output
lines.  Put it properly.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some ioctl functions are implemented individually for both playback
and capture streams although most of the codes are identical with just
a few different stream-specific function calls.  This patch unifies
these places, removes the superfluous trivial check and flattens the
call paths as a cleanup.  Meanwhile, for better readability, some
codes (e.g. xfer ioctls or forward/rewind ioctls) are factored out as
functions.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently we're taking power_lock at each card component for assuring
the power-up sequence, but it doesn't help anything in the
implementation at the moment: it just serializes unnecessarily the
callers, but it doesn't protect about the power state change itself.
It used to have some usefulness in the early days where we managed the
PM manually.  But now the suspend/resume core procedure is beyond our
hands, and power_lock lost its meaning.

This patch drops the power_lock from allover the places.
There shouldn't be any issues by this change, as it's no helper
regarding the power state change.  Rather we'll get better performance
by removing the serialization; which is the only slight concern of any
behavior change, but it can't be a showstopper, after all.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

PCM OSS emulation issues the drain ioctl without power lock.  It used
to work in the earlier kernels as the power lock was taken inside
snd_pcm_drain() itself.  But since 68b4acd3 ("ALSA: pcm: Apply
power lock globally to common ioctls"), the power lock is taken
outside the function.  Due to that change, the call via OSS emulation
leads to the unbalanced power lock, thus it deadlocks.

As a quick fix, just take the power lock before snd_pcm_drain() call
for OSS emulation path.  A better cleanup will follow later.

Fixes: 68b4acd3 ("ALSA: pcm: Apply power lock globally to common ioctls")
Reported-and-tested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit c8da9be4 ("ALSA: pcm: Adjust nine function calls
together with a variable assignment") contained a badly incorrect
conversion, a "status" PCM procfs creation was replaced with the next
one.  Luckily, this could be spotted easily by the kernel runtime
warning.

Fixes: c8da9be4 ("ALSA: pcm: Adjust nine function calls together...")
Reported-by: NFabio Estevam <fabio.estevam@nxp.com>
Tested-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Not all devices with ACPI and this combination of sound devices will
have the required information provided via ACPI.  Reintroduce the I2C
device ID to restore sound functionality on on the Chromebook 'Samus'
model.

[ More background note:
 the commit a36afb0a ("ASoC: rt5677: Introduce proper table...")
 moved the i2c ID probed via ACPI ("RT5677CE:00") to a proper
 acpi_device_id table.  Although the action itself is correct per se,
 the overseen issue is the reference id->driver_data at
 rt5677_i2c_probe() for retrieving the corresponding chip model for
 the given id.  Since id=NULL is passed for ACPI matching case, we get
 an Oops now.

 We already have queued more fixes for 4.14 and they already address
 the issue, but they are bigger changes that aren't preferable for the
 late 4.13-rc stage.  So, this patch just papers over the bug as a
 once-off quick fix for a particular ACPI matching.  -- tiwai ]

Fixes: a36afb0a ("ASoC: rt5677: Introduce proper table for ACPI enumeration")
Signed-off-by: NTom Rini <trini@konsulko.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For user-defined element set, in its initial state, TLV data is not
registered. It's firstly available when any application register it by
an additional operation. However, in current implementation, it's available
in its initial state. As a result, applications get -ENXIO to read it.

This commit controls its readability to manage info flags properly. In an
initial state, elements don't have SND_CTL_ELEM_ACCESS_TLV_READ flag. Once
TLV write operation is executed, they get the flag.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In a design of user-defined element set, applications allow to change TLV
data on the set. This operation doesn't only affects to a target element,
but also to elements in the set.

This commit generates TLV event for all of elements in the set when the TLV
data is changed.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In a design of ALSA control core, a set of elements is represented by
'struct snd_kcontrol' to share common attributes. The set of elements
shares TLV (Type-Length-Value) data, too.

On the other hand, in ALSA control interface/protocol for applications,
a TLV operation is committed to an element. Totally, the operation can
have sub-effect to the other elements in the set. For example, TLV_WRITE
operation is expected to change TLV data, which returns to applications.
Applications attempt to change the TLV data per element, but in the above
design, they can effect to elements in the same set.

As a default, ALSA control core has no implementation except for TLV_READ
operation. Thus, the above design looks to have no issue. However, in
kernel APIs of ALSA control component, developers can program a handler
for any request of the TLV operation. Therefore, for elements in a set
which has the handler, applications can commit TLV_WRITE and TLV_COMMAND
requests.

For the above scenario, ALSA control core assist notification. When the
handler returns positive value, the core queueing an event for a requested
element. However, this includes design defects that the event is not
queued for the other element in a set. Actually, developers can program
the handlers to keep per-element TLV data, but it depends on each driver.

As of v4.13-rc6, there's no driver in tree to utilize the notification,
except for user-defined element set. This commit delegates the notification
into each driver to prevent developers from the design defects.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_ac97_res_table are not supposed to change at runtime. All functions
working with snd_ac97_res_table provided by <sound/ac97_codec.h> work with
const snd_ac97_res_table. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Make these const as they are only used in a copy operation.
Done using Coccinelle:

@match disable optional_qualifier@
identifier s;
@@
static struct hw s = {...};

@ref@
position p;
identifier match.s;
@@
s@p

@good1@
position ref.p;
identifier match.s,f,c;
expression e;
@@
(
e = s@p
|
e = s@p.f
|
c(...,s@p.f,...)
|
c(...,s@p,...)
)

@bad depends on  !good1@
position ref.p;
identifier match.s;
@@
s@p

@depends on forall !bad disable optional_qualifier@
identifier match.s;
@@
static
+ const
struct hw s;
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ac97_pcm are not supposed to change at runtime. All functions
working with ac97_pcm provided by <sound/ac97_codec.h> work with
const ac97_pcm. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ac97_pcm are not supposed to change at runtime. All functions
working with ac97_pcm provided by <sound/ac97_codec.h> work with
const ac97_pcm. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ac97_pcm are not supposed to change at runtime. All functions
working with ac97_pcm provided by <sound/ac97_codec.h> work with
const ac97_pcm. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ac97_pcm are not supposed to change at runtime. All functions
working with ac97_pcm provided by <sound/ac97_codec.h> work with
const ac97_pcm. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add jump targets so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The script "checkpatch.pl" pointed information out like the following.

ERROR: do not use assignment in if condition

Thus fix the affected source code place.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The script "checkpatch.pl" pointed information out like the following.

ERROR: do not use assignment in if condition

Thus fix the affected source code places.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Lenovo G50-70 (17aa:3978) with Conexant codec chip requires the
similar workaround for the inverted stereo dmic like other Lenovo
models.

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

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Dell laptops have another LED for mic-mute in addition to the master
mute.  The former is tied with the capture switch (in a reverse way)
while the latter is tied with the master playback switch.  We already
have an enum control to change the behavior for the master mute LED in
different ways, e.g. keeping always off or turning off at mute.  But,
the mic-mute LED has no such management but its behavior is
hard-coded.

This patch implements an enum control to change the mic-mute LED
behavior like what we have for the master mute LED.  The ctl provides
four modes: keep-on, keep-off, follow-capture and follow-mute.  The
default mode is the last one, follow-mute, which follows the capture
mute, i.e. LED turning on when the capture is off, and turning off
when the capture is active.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add jump targets so that a bit of exception handling can be better reused
at the end of these functions.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

STAudio ADCIII has the same SSID as Hoontech STDSP24, but requires a
slightly different configuration.  This patch allows user to choose
this model via model=staudio option to set the proper configuration
for the board.

Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=1048934Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Drivers in ALSA firewire stack still includes some symbols which can be
moved to a section for read-only symbols.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Conflicts:
	sound/core/control.c

When user tries to replace the user-defined control TLV, the kernel
checks the change of its content via memcmp().  The problem is that
the kernel passes the return value from memcmp() as is.  memcmp()
gives a non-zero negative value depending on the comparison result,
and this shall be recognized as an error code.

The patch covers that corner-case, return 1 properly for the changed
TLV.

Fixes: 8aa9b586 ("[ALSA] Control API - more robust TLV implementation")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

These headsets reports a lot of: cannot set freq 44100 to ep 0x81
and need a small delay between sample rate settings, just like
Zoom R16/24. Add both headsets to the Zoom R16/24 quirk for
a 1 ms delay between control msgs.
Signed-off-by: NJoakim Tjernlund <joakim.tjernlund@infinera.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

MOTU Audio Express is one of third generation in MOTU FireWire
series, produced in 2011. This model consists of three chips:
 * TI TSB41AB2 (Physical layer for IEEE 1394 bus)
 * Microchip USB3300 (Hi-Speed USB Device with ULPI interface)
 * Xilinx Spartan-3A FPGA, XC3S400A (Link layer for IEEE 1394 bus, packet
   processing and data block processing layer)

This commit adds support for this model. As I expected, it works with
current implementaion of protocol version 3. On the other hand, the unit
has a quirk to request subaction originated by any driver.

11:45:51.287643 firewire_ohci 0000:03:00.0: AT spd 2 tl 1f, ffc1 -> ffc0, -reserved-, QW req, fffff0000b14 = 02000200
11:45:51.289193 firewire_ohci 0000:03:00.0: AR spd 2 tl 1f, ffc0 -> ffc1, ack_complete, W resp
11:45:51.289381 fireire_core 0000:03:00.0: unsolicited response (source ffc0, tlabel 1f)
11:45:51.313071 firewire_ohci 0000:03:00.0: AT spd 2 tl 20, ffc1 -> ffc0, ack_pending , QW req, fffff0000b14 = 02000200
11:45:51.314539 firewire_ohci 0000:03:00.0: AR spd 2 tl 20, ffc0 -> ffc1, ack_complete, W resp

In 1394 OHCI (rev.1.1), after OUTPUT_LAST* descriptors is processed,
'xferStaus' field is filled with 'ContextControl[0:15]' (see clause 7.1.3).
5 bits in LSB side of the field has ack code in acknowledge from the unit
(see clause 7.2.2). A list of the code is shown in Table 3-2.

As long as I investigated, in a case of the '-reserved-' acknowledge
message from the unit, the field has 0x10. On the table, this value is
'Reserved for definition by future 1394 standards'. As long as I know,
any specifications of IEEE 1394 has no such extensions, thus the unit is
out of specification. Besides, I note that the unit does not always
acknowledge with the invalid code. I guess this is a bug of firmware. I
confirmed the bug in firmware version 1.04 and this is the latest one.

$ cd linux-firewire-utils
$ python2 ./src/crpp < /sys/bus/firewire/devices/fw1/config_rom
               ROM header and bus information block
               -----------------------------------------------------------------
400  0410a756  bus_info_length 4, crc_length 16, crc 42838
404  31333934  bus_name "1394"
408  20ff7000  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c  0001f200  company_id 0001f2     |
410  000a8a7b  device_id 00000a8a7b  | EUI-64 0001f200000a8a7b

               root directory
               -----------------------------------------------------------------
414  0004ef04  directory_length 4, crc 61188
418  030001f2  vendor
41c  0c0083c0  node capabilities per IEEE 1394
420  d1000002  --> unit directory at 428
424  8d000005  --> eui-64 leaf at 438

               unit directory at 428
               -----------------------------------------------------------------
428  00031680  directory_length 3, crc 5760
42c  120001f2  specifier id
430  13000033  version
434  17104800  model

               eui-64 leaf at 438
               -----------------------------------------------------------------
438  00025ef3  leaf_length 2, crc 24307
43c  0001f200  company_id 0001f2     |
440  000a8a7b  device_id 00000a8a7b  | EUI-64 0001f200000a8a7b
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>