Fix gcc warnings when -Wextra is used by using an empty do-while
block instead of <nothing>.  Fixes these build warnings:

../sound/pci/korg1212/korg1212.c:674:44: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:708:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:730:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:853:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:1013:44: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:1035:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:1052:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:1066:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:1087:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:1094:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:1208:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../sound/pci/korg1212/korg1212.c:2360:102: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/91fb1e97-a773-5790-3f65-8198403341e1@infradead.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Merging the UAC2 effect unit parser improvement.  As it's based on the
previous usb-audio driver fix, it was deviated from for-next branch.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

During parsing the input source, we currently cut off at the Effect
Unit node without parsing further its source id.  It's no big problem,
so far, but it should be more consistent to parse it properly.

This patch adds the recursive parsing in parse_term_effect_unit().
It doesn't add anything in the audio unit parser itself, and the
effect unit itself is still skipped, though.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206147
Link: https://lore.kernel.org/r/20200213112059.18745-3-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The UAC2 Effect Unit Descriptor has a slightly different definition
from other similar ones like Processing Unit or Extension Unit.
Define it here so that it can be used in USB-audio driver in a later
patch.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200213112059.18745-2-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds support for Presonus Studio 1810c, a usb interface
that's UAC2 compliant with a few quirks and a few extra hw-specific
controls. I've tested all 3 altsettings and the added switch
controls and they work as expected.

More infos on the card:
https://www.presonus.com/products/Studio-1810c

Note that this work is based on packet inspection with
usbmon. I just wanted to get this card to work for using
it on our open-source radio station:
https://github.com/UoC-Radio

v2 address issues reported by Takashi:
* Properly get/set enum type controls
* Prevent race condition on switch_get/set
* Various control naming changes
* Various coding style fixes

v3 improve readability of sample rate filtering
and some other minor changes.
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Link: https://lore.kernel.org/r/5e47481a.1c69fb81.befb3.8dac@mx.google.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA PCM OSS layer calls the generic __snd_pcm_lib_xfer() helper for
the actual transfer of the audio data.  The xfer helper may sleep long
for waiting for the enough space becoming empty for read/write, and
it does unlock/relock for the substream lock.  This works fine, so
far, but a slight problem specific to OSS layer is that OSS layer
wraps yet more mutex (runtime->oss.params_lock) over
__snd_pcm_lib_xfer() call; so this mutex is still locked during a
possible long sleep, and it prevents the whole ioctl and other actions
applied to the given stream.

This patch adds the temporarily unlock and relock of the mutex around
__snd_pcm_lib_xfer() call in the OSS layer to be more friendly to the
concurrent accesses.  The long mutex protection itself shouldn't be a
real issue for the normal systems, and its influence appears only on
strange things like fuzzers.

Link: https://lore.kernel.org/r/20200214171643.26212-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The rawmidi state flags (opened, append, active_sensing) are stored in
bit fields that can be potentially racy when concurrently accessed
without any locks.  Although the current code should be fine, there is
also no any real benefit by keeping the bitfields for this kind of
short number of members.

This patch changes those bit fields flags to the simple bool fields.
There should be no size increase of the snd_rawmidi_substream by this
change.

Reported-by: syzbot+576cc007eb9f2c968200@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200214111316.26939-4-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

snd_seq_check_queue() passes the current tick and time of the given
queue as a pointer to snd_seq_prioq_cell_out(), but those might be
updated concurrently by the seq timer update.

Fix it by retrieving the current tick and time via the proper helper
functions at first, and pass those values to snd_seq_prioq_cell_out()
later in the loops.

snd_seq_timer_get_cur_time() takes a new argument and adjusts with the
current system time only when it's requested so; this update isn't
needed for snd_seq_check_queue(), as it's called either from the
interrupt handler or right after queuing.

Also, snd_seq_timer_get_cur_tick() is changed to read the value in the
spinlock for the concurrency, too.

Reported-by: syzbot+fd5e0eaa1a32999173b2@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200214111316.26939-3-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The queue flags are represented in bit fields and the concurrent
access may result in unexpected results.  Although the current code
should be mostly OK as it's only reading a field while writing other
fields as KCSAN reported, it's safer to cover both with a proper
spinlock protection.

This patch fixes the possible concurrent read by protecting with
q->owner_lock.  Also the queue owner field is protected as well since
it's the field to be protected by the lock itself.

Reported-by: syzbot+65c6c92d04304d0a8efc@syzkaller.appspotmail.com
Reported-by: syzbot+e60ddfa48717579799dd@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200214111316.26939-2-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Some USB-audio descriptors provide a bogus volume range (e.g. volume
min and max are identical), which confuses user-space.
This patch makes the driver skipping such a control element.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206221
Link: https://lore.kernel.org/r/20200214144928.23628-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The commit 66f2d19f ("ALSA: pcm: Fix memory leak at closing a
stream without hw_free") tried to fix the regression wrt the missing
hw_free call at closing without SNDRV_PCM_IOCTL_HW_FREE ioctl.
However, the code change dropped mistakenly the state check, resulting
in calling hw_free twice when SNDRV_PCM_IOCTL_HW_FRE got called
beforehand.  For most drivers, this is almost harmless, but the
drivers like SOF show another regression now.

This patch adds the state condition check before calling do_hw_free()
at releasing the stream for avoiding the double hw_free calls.

Fixes: 66f2d19f ("ALSA: pcm: Fix memory leak at closing a stream without hw_free")
Reported-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Reported-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Tested-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/s5hd0ajyprg.wl-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

It should be safe to ignore clock validity check result if the following
conditions are met:
 - only one single sample rate is supported;
 - the terminal is directly connected to the clock source;
 - the clock type is internal.

This is to deal with some Denon DJ controllers that always reports that
clock is invalid.
Tested-by: NTobias Oszlanyi <toszlanyi@yahoo.de>
Signed-off-by: NAlexander Tsoy <alexander@tsoy.me>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200212235450.697348-1-alexander@tsoy.meSigned-off-by: NTakashi Iwai <tiwai@suse.de>

MSI-GL73 laptop with ALC1220 codec requires a similar workaround for
Clevo laptops to enforce the DAC/mixer connection path.  Set up a
quirk entry for that.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204159
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200212081047.27727-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Add supported Headset Button for ALC215/ALC285/ALC289.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/948f70b4488f4cc2b629a39ce4e4be33@realtek.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200211200739.GA12948@embeddedorSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200211194403.GA10318@embeddedorSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200211194224.GA9383@embeddedorSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200211193910.GA4596@embeddedorSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The Audioengine D1 (0x2912:0x30c8) does support reading the sample rate,
but it returns the rate in byte-reversed order.

When setting sampling rate, the driver produces these warning messages:
[168840.944226] usb 3-2.2: current rate 4500480 is different from the runtime rate 44100
[168854.930414] usb 3-2.2: current rate 8436480 is different from the runtime rate 48000
[168905.185825] usb 3-2.1.2: current rate 30465 is different from the runtime rate 96000

As can be seen from the hexadecimal conversion, the current rate read
back is byte-reversed from the rate that was set.

44100 == 0x00ac44, 4500480 == 0x44ac00
48000 == 0x00bb80, 8436480 == 0x80bb00
96000 == 0x017700,   30465 == 0x007701

Rather than implementing a new quirk to reverse the order, just skip
checking the rate to avoid spamming the log.
Signed-off-by: NArvind Sankar <nivedita@alum.mit.edu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200211162235.1639889-1-nivedita@alum.mit.eduSigned-off-by: NTakashi Iwai <tiwai@suse.de>

We've got a regression report about M-Audio Fast Track C400 device,
and the git bisection resulted in the commit e0ccdef9 ("ALSA:
usb-audio: Clean up check_input_term()").  This commit was about the
rewrite of the input terminal parser, and it's not too obvious from
the change what really broke.  The answer is: it's the interpretation
of UAC2/3 effect units.

In the original code, UAC2 effect unit is as if through UAC1
processing unit because both UAC1 PU and UAC2/3 EU share the same
number (0x07).  The old code went through a complex switch-case
fallthrough, finally bailing out in the middle:

  if (protocol == UAC_VERSION_2 &&
      hdr[2] == UAC2_EFFECT_UNIT) {
         /* UAC2/UAC1 unit IDs overlap here in an
          * uncompatible way. Ignore this unit for now.
          */
         return 0;
   }

... and this special handling was missing in the new code; the new
code treats UAC2/3 effect unit as if it were equivalent with the
processing unit.

Actually, the old code was too confusing.  The effect unit has an
incompatible unit description with the processing unit, so we
shouldn't have dealt with EU in the same way.

This patch addresses the regression by changing the effect unit
handling to the own parser function.  The own parser function makes
the clear distinct with PU, so it improves the readability, too.

The EU parser just sets the type and the id like the old kernels.
Once when the proper effect unit support is added, we can revisit this
parser function, but for now, let's keep this simple setup as is.

Fixes: e0ccdef9 ("ALSA: usb-audio: Clean up check_input_term()")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206147
Link: https://lore.kernel.org/r/20200211160521.31990-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Jabra Evolve 65 headset appears as if supporting lower rates than
48kHz, but it actually doesn't work but with 48kHz for playback.

This patch applies a workaround to enforce the 48kHz like LINE6
devices already did.  The workaround is put in a unified helper
function, set_fixed_rate(), to be called from both places now.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206149
Link: https://lore.kernel.org/r/20200211111419.5895-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Variable c is being assigned with the value -1 that is never read,
it is assigned a new value in a following while-loop. The assignment
is redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200208224206.38540-1-colin.king@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Variable capture_flag is only ever assigned values, it is never read
and hence it is redundant. Remove it.

Addresses-Coverity ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200208223443.38047-1-colin.king@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Variable timeout is being assigned with the value 200 that is never
read, it is assigned a new value in a following do-loop. The assignment
is redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200208222756.37707-1-colin.king@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Variable err is being assigned with a value that is never read, it is
assigned a new value in the next statement. The assignment is redundant
and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200208222006.37376-1-colin.king@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Make a common helper for validating the format type.
This reduces the number of cast in the code that are needed for
suppressing sparse warnings.

No functional changes, just minor refactoring.

Link: https://lore.kernel.org/r/20200206163945.6797-9-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The new macro can fix the sparse warnings gracefully:
  sound/core/pcm_dmaengine.c:429:50: warning: restricted snd_pcm_format_t degrades to integer
  sound/core/pcm_dmaengine.c:429:55: warning: restricted snd_pcm_format_t degrades to integer
  sound/core/pcm_dmaengine.c:429:79: warning: restricted snd_pcm_format_t degrades to integer

No functional changes, just sparse warning fixes.

Link: https://lore.kernel.org/r/20200206163945.6797-8-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The parameter bit mask needs often explicit cast with __force,
e.g. for the PCM subformat type.  Instead of adding __force at each
place, which is error prone, this patch introduces a new macro and
replaces the all bit shift with it.  This fixes the sparse warnings
like the following:
  sound/core/pcm_native.c:2508:30: warning: restricted snd_pcm_access_t degrades to integer

No functional changes, just sparse warning fixes.

Link: https://lore.kernel.org/r/20200206163945.6797-7-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Simplify the code with the new macros for PCM format type iterations.
This fixes the sparse warnings nicely:
  sound/core/pcm_native.c:2302:26: warning: restricted snd_pcm_format_t degrades to integer
  sound/core/pcm_native.c:2306:54: warning: incorrect type in argument 1 (different base types)
  sound/core/pcm_native.c:2306:54:    expected restricted snd_pcm_format_t [usertype] format
  sound/core/pcm_native.c:2306:54:    got unsigned int [assigned] k
  ....

No functional changes, just sparse warning fixes.

Link: https://lore.kernel.org/r/20200206163945.6797-6-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Simplify the code with the new macros for PCM format type iterations.
This fixes the sparse warnings nicely:
  sound/drivers/dummy.c:906:25: warning: restricted snd_pcm_format_t degrades to integer
  sound/drivers/dummy.c:908:25: warning: incorrect type in argument 1 (different base types)
  sound/drivers/dummy.c:908:25:    expected restricted snd_pcm_format_t [usertype] format
  sound/drivers/dummy.c:908:25:    got int [assigned] i

No functional changes, just sparse warning fixes.

Link: https://lore.kernel.org/r/20200206163945.6797-5-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The new macro can fix the sparse warnings gracefully:
  sound/usb/proc.c:73:31: warning: restricted snd_pcm_format_t degrades to integer
  sound/usb/proc.c:73:38: warning: restricted snd_pcm_format_t degrades to integer
  sound/usb/proc.c:73:61: warning: restricted snd_pcm_format_t degrades to integer

No functional changes, just sparse warning fixes.

Link: https://lore.kernel.org/r/20200206163945.6797-4-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

snd_pcm_format_t is a strong-typed integer and requires the explicit
cast with __force if converted or compared with a normal integer
value.  Since most of use cases do iterate over all formats and test /
set the mask, provide a couple of new helper macros that do the
explicit cast.

Link: https://lore.kernel.org/r/20200206163945.6797-3-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Fix sparse warnings about PCM format assignment regarding the strong
typed snd_pcm_format_t:
  sound/drivers/aloop.c:352:45: warning: restricted snd_pcm_format_t degrades to integer
  sound/drivers/aloop.c:355:39: warning: incorrect type in assignment (different base types)
  sound/drivers/aloop.c:355:39:    expected unsigned int format
  sound/drivers/aloop.c:355:39:    got restricted snd_pcm_format_t [usertype] format
  sound/drivers/aloop.c:1435:34: warning: incorrect type in assignment (different base types)
  sound/drivers/aloop.c:1435:34:    expected long max
  sound/drivers/aloop.c:1435:34:    got restricted snd_pcm_format_t [usertype]
  sound/drivers/aloop.c:1565:39: warning: incorrect type in assignment (different base types)
  sound/drivers/aloop.c:1565:39:    expected unsigned int format
  sound/drivers/aloop.c:1565:39:    got restricted snd_pcm_format_t [usertype]

Some code in this driver assigns an integer value to snd_pcm_format_t
via control API, and they need to be with the explicit cast.

No functional changes, just sparse warning fixes.

Link: https://lore.kernel.org/r/20200206163945.6797-2-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Fixes the sparse warnings.  The cast to __user pointer needs __force:
  sound/isa/sb/emu8000_pcm.c:528:9: warning: cast removes address space '<asn:1>' of expression

No functional changes, just sparse warning fixes.

Link: https://lore.kernel.org/r/20200206163152.6073-4-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The internal page tables are little endian, hence they should be
__le32 type.  This fixes the relevant sparse warning:
  sound/pci/emu10k1/emu10k1_main.c:2013:51: warning: incorrect type in assignment (different base types)
  sound/pci/emu10k1/emu10k1_main.c:2013:51:    expected unsigned int [usertype]
  sound/pci/emu10k1/emu10k1_main.c:2013:51:    got restricted __le32 [usertype]

No functional changes, just sparse warning fixes.

Link: https://lore.kernel.org/r/20200206163152.6073-3-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The internal page tables are in little endian, hence they should be
__le32 type.  This fixes the relevant sparse warnings:
  sound/pci/via82xx.c:454:60: warning: incorrect type in assignment (different base types)
  sound/pci/via82xx.c:454:60:    expected unsigned int [usertype]
  sound/pci/via82xx.c:454:60:    got restricted __le32 [usertype]
  ....

No functional changes, just sparse warning fixes.

Link: https://lore.kernel.org/r/20200206163152.6073-2-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

This is a final step of the cleanup series: move the HDMI ELD parser
call into update_eld() function so that we can unify the calls.
The ELD validity check is unified in update_eld(), too.

Along with it, the repoll scheduling is moved to update_eld() as well,
where sync_eld_via_acomp() just passes 0 for skipping it.
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NNikhil Mahale <nmahale@nvidia.com>
Link: https://lore.kernel.org/r/20200206162804.4734-5-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

For improving the readability, move the runtime PM handling code from
hdmi_present_sense() to hdmi_present_sense_via_verbs().  Now
hdmi_present_sense() became symmetric for both audio-component and
legacy cases.

Just a minor code refactoring.
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NNikhil Mahale <nmahale@nvidia.com>
Link: https://lore.kernel.org/r/20200206162804.4734-4-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The current HDMI codec driver code manages the jack detection in two
different ways: for Intel codecs with audio component, the driver
creates snd_jack objects by itself while the standard hda_jack stuff
is used for the rest.  This was basically because the audio component
doesn't need the pin sense reading and the unsol event handling, hence
it just needs to report the corresponding jacks directly.

It was a bit messy but not too messy until the driver got DP-MST
support for Nvidia that re-uses the part of dyn_pcm_assign feature
while keeping the pin sense and the unsol event handling.  Now, for
DP-MST, we use hda_jack for pin sensing and unsol events but use the
own snd_jack objects.  Meanwhile for non-DP-MST, hda_jack is used for
pin sense and unsol events, and the jacks are bound on hda_jack.

Moreover, there is a polling mode support where the unsol event isn't
used.  For those, we also have special handling.

For simplifying those messes, this patch unifies the snd_jack handling
over all generic HDMI codes.  The driver creates snd_jack objects just
like Intel codecs did in the past but now for all devices.  For the
system without audio component binding, we still need the pin sense
and the unsol event handling, and those are still done with the
hda_jack table as before.  But hda_jack is no longer used for the
actual snd_jack handling.

Since the hda_jack is no longer used for jack reporting, we removed
snd_hda_jack_report_sync() calls, which also allowed to simplify the
return type of hda_present_sense() and co.  pin_idx_to_pcm_jack() was
simplified as well because it behaves same for all cases now.

Note that the hda_jack is still used for the simple HDMI codecs; they
are really simple enough, so no big reason to change intrusively.
Reviewed-by: NNikhil Mahale <nmahale@nvidia.com>
Link: https://lore.kernel.org/r/20200206162804.4734-3-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Pass hda_jack_tbl object to hdmi_intrinsic_event() along with res from
hdmi_unsol_event() so that we can reduce the lookup of the same
hda_jack_tbl object again.

Minor code refactoring.
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NNikhil Mahale <nmahale@nvidia.com>
Link: https://lore.kernel.org/r/20200206162804.4734-2-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>