Update binding document for HDA support on Tegra234 chip.

Tegra234 has max of 2 clocks and 2 resets which requires to add
minItems and maxItems for clocks and resets as Tegra chips can
now have minimum of 2 and maximum of 3 clocks and reset support.
Signed-off-by: NMohan Kumar <mkumard@nvidia.com>
Link: https://lore.kernel.org/r/20220216092240.26464-6-mkumard@nvidia.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Tegra234 chip scratch register communication between audio
and hdmi driver differs slightly in the way it triggers the
interrupt compared to legacy chips. Interrupt is triggered
by writing non-zero values to verb 0xF80 instead of 31st bit
of scratch register.

DP MST support changed the NID to be used for scratch register
read/write from audio function group NID to Converter widget NID.
Signed-off-by: NMohan Kumar <mkumard@nvidia.com>
Link: https://lore.kernel.org/r/20220216092240.26464-4-mkumard@nvidia.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The GCAP register on Tegra234 implies no Input Streams(ISS)
supported, but the HW output stream descriptor programming
should start with offset 0x20*4 from base stream descriptor
address. This will be a problem while calculating the offset
for output stream descriptor which will be considering input
stream also. So here output stream starts with offset 0 which
is wrong as HW register for output stream offset starts with 4.
So hardcode the input stream numbers to 4 to avoid the issue
in offset calculation.
Signed-off-by: NMohan Kumar <mkumard@nvidia.com>
Link: https://lore.kernel.org/r/20220216092240.26464-3-mkumard@nvidia.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Add hda driver support for the Tegra234 chip. The hdacodec
on this chip now supports DP MST feature, HDA block contains
azalia controller and one hda-codec instance by supporting
4 independent output streams over DP MST mode. There is no
input stream support.
Signed-off-by: NMohan Kumar <mkumard@nvidia.com>
Link: https://lore.kernel.org/r/20220216092240.26464-2-mkumard@nvidia.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

With few changes, snd_hda_codec_set_power_save() and
snd_hda_codec_cleanup_for_unbind() can be re-used by ASoC drivers.
While at it, provide kernel doc for the exposed functions.
Signed-off-by: NCezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220214101404.4074026-5-cezary.rojewski@intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

With few changes, snd_hda_codec_register() and its
unregister-counterpart can be re-used by ASoC drivers. While at it,
provide kernel doc for the exposed functions.

Due to ALSA-device vs ASoC-component organization differences, new
'snddev_managed' argument is specified allowing for better control over
codec registration process.
Signed-off-by: NCezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220214101404.4074026-4-cezary.rojewski@intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

With few changes, snd_hda_codec_device_init() can be re-used by ASoC
drivers. While at it, provide kernel doc for the exposed function.
Signed-off-by: NCezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220214101404.4074026-3-cezary.rojewski@intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

This patch exposes a new helper to directly retrieve the link from the
codec address, and makes use of this helper when retrieving the link
from the codec name.
Signed-off-by: NCezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220214101404.4074026-2-cezary.rojewski@intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Implement HDA keep alive (KAE) support for Intel display codecs. When no
audio stream is active, the display codec will provide a continuous clock
and a valid but silent audio stream to any connected HDMI/DP receiver.
Without this, upon starting a new playback stream, initial samples may be
lost as many receivers require time to initialize for new clock.

This is a new feature in Intel AlderLake-P display codec implementation
and replaces the Intel i915 silent-stream extension that has been used
on older hardware. Main benefit of the new method is that codec no longer
needs to be kept in D0 power state.

This patch depends on commit 112a87c4 ("drm/i915/display: program
audio CDCLK-TS for keepalives").

[ a minor coding-style fix by tiwai ]
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NJyri Sarha <jyri.sarha@intel.com>
Link: https://lore.kernel.org/r/20220216172405.3994959-1-kai.vehmanen@linux.intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Merge tag 'platform-drivers-x86-serial-multi-instantiate-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into for-next

This branch contains 5.17-rc1 + the SPI tree's spi-acpi-helpers tag +
the other patches from the "[PATCH v6 0/9] Support Spi in
i2c-multi-instantiate driver" series.

Merge tag 'asoc-fix-v5.17-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v5.18

More fixes that have arrived in the past few -rcs, plus a MAINTAINERS
update.  The biggest update here is the fix for control change
notifications in ASoC generic controls found by mixer-test.

The recently introduced coef_mutex for Realtek codec seems causing a
deadlock when the relevant code is invoked from the power-off state;
then the HD-audio core tries to power-up internally, and this kicks
off the codec runtime PM code that tries to take the same coef_mutex.

In order to avoid the deadlock, do the temporary power up/down around
the coef_mutex acquisition and release.  This assures that the
power-up sequence runs before the mutex, hence no re-entrance will
happen.

Fixes: b837a9f5 ("ALSA: hda: realtek: Fix race at concurrent COEF updates")
Reported-and-tested-by: NJulian Wollrath <jwollrath@web.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220214132838.4db10fca@schienar
Link: https://lore.kernel.org/r/20220214130410.21230-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The default mixer resume code treats the errors at restoring the
modified mixer items as a fatal error, and it returns back to the
caller.  This ends up in the resume failure, and the device will be
come unavailable, although basically those errors are intermittent and
can be safely ignored.

The problem itself has been present from the beginning, but it didn't
hit usually because the code tries to resume only the modified items.
But now with the recent commit to forcibly initialize each item at the
probe time, the problem surfaced more often, hence it appears as a
regression.

This patch fixes the regression simply by ignoring the errors at
resume.

Fixes: b96681bd ("ALSA: usb-audio: Initialize every feature unit once at probe time")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215561
Link: https://lore.kernel.org/r/20220214125711.20531-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

By some unknown reason, BIOS on Shenker Dock 15 doesn't set up the
codec mask properly for the onboard audio.  Let's set the forced codec
mask to enable the codec discovery.

Reported-by: dmummenschanz@web.de
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/trinity-f018660b-95c9-442b-a2a8-c92a56eb07ed-1644345967148@3c-app-webde-bap22
Link: https://lore.kernel.org/r/20220214100020.8870-2-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The forced probe mask via probe_mask 0x100 bit doesn't work any longer
as expected since the bus init code was moved and it's clearing the
codec_mask value that was set beforehand.  This patch fixes the
long-time regression by moving the check_probe_mask() call.

Fixes: a41d1224 ("ALSA: hda - Embed bus into controller object")
Reported-by: dmummenschanz@web.de
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/trinity-f018660b-95c9-442b-a2a8-c92a56eb07ed-1644345967148@3c-app-webde-bap22
Link: https://lore.kernel.org/r/20220214100020.8870-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Legion Y9000X 2019 has the same speaker with Y9000X 2020,
but with a different quirk address. Add one quirk entry
to make the speaker work on Y9000X 2019 too.
Signed-off-by: NYu Huang <diwang90@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220212160835.165065-1-diwang90@gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Commit 83b7dcbc introduced a generic
implicit feedback parser, which fails to execute for M-Audio FastTrack
Ultra sound cards. The issue is with the ENDPOINT_SYNCTYPE check in
add_generic_implicit_fb() where the SYNCTYPE is ADAPTIVE instead of ASYNC.
The reason is that the sync type of the FastTrack output endpoints are
set to adaptive in the quirks table since commit
65f04443.

Fixes: 83b7dcbc ("ALSA: usb-audio: Add generic implicit fb parsing")
Signed-off-by: NMatteo Martelli <matteomartelli3@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220211224913.20683-2-matteomartelli3@gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Remove the second 'device'.
Signed-off-by: NTom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20220209150133.2291856-1-trix@redhat.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Add a set of HD Audio PCI IDs, and the HDMI codec VID, for
Intel Raptor Lake.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20220210185423.3671603-1-kai.vehmanen@linux.intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

When parsing the compressed stream the whole buffer descriptor is
now read in a single cs_dsp_coeff_read_ctrl; on older firmwares
this descriptor is just 4 bytes but on more modern firmwares it is
24 bytes. The current code reads the full 24 bytes regardless, this
was working but reading junk for the last 20 bytes. However commit
f444da38 ("firmware: cs_dsp: Add offset to cs_dsp read/write")
added a size check into cs_dsp_coeff_read_ctrl, causing the older
firmwares to now return an error.

Update the code to only read the amount of data appropriate for
the firmware loaded.

Fixes: 04ae0859 ("ASoC: wm_adsp: Switch to using wm_coeff_read_ctrl for compressed buffers")
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220210172053.22782-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

In commit da0363f7 ("ASoC: qcom: Fix for DMA interrupt clear reg
overwriting") we changed regmap_write() to regmap_update_bits() so that
we can avoid overwriting bits that we didn't intend to modify.
Unfortunately this change breaks the case where a register is writable
but not readable, which is exactly how the HDMI irq clear register is
designed (grep around LPASS_HDMITX_APP_IRQCLEAR_REG to see how it's
write only). That's because regmap_update_bits() tries to read the
register from the hardware and if it isn't readable it looks in the
regmap cache to see what was written there last time to compare against
what we want to write there. Eventually, we're unable to modify this
register at all because the bits that we're trying to set are already
set in the cache.

This is doubly bad for the irq clear register because you have to write
the bit to clear an interrupt. Given the irq is level triggered, we see
an interrupt storm upon plugging in an HDMI cable and starting audio
playback. The irq storm is so great that performance degrades
significantly, leading to CPU soft lockups.

Fix it by using regmap_write_bits() so that we really do write the bits
in the clear register that we want to. This brings the number of irqs
handled by lpass_dma_interrupt_handler() down from ~150k/sec to ~10/sec.

Fixes: da0363f7 ("ASoC: qcom: Fix for DMA interrupt clear reg overwriting")
Cc: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20220209232520.4017634-1-swboyd@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>

ca0106 driver code uses too generic names for its register definitions
such as PTR, DATA, IPR, etc, which may eventually conflict with other
code.  This patch renames (some of) those register definitions with
CA0106_ prefix to avoid the conflicts.

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

It seems that calling invalidate_kernel_vmap_range() is more correct
to be called before dma_sync_*(), judging from the other thread:
  https://lore.kernel.org/all/20220111085958.GA22795@lst.de/
Although this won't matter much in practice, let's fix the call order
for consistency.

Fixes: a25684a9 ("ALSA: memalloc: Support for non-contiguous page allocation")
Reported-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220210123344.8756-3-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

dma_need_sync() checks each DMA address.  Fix the incorrect usages
for non-contiguous and non-coherent page allocations.
Fortunately, there are no actual call sites that need manual syncs
yet.

Fixes: a25684a9 ("ALSA: memalloc: Support for non-contiguous page allocation")
Fixes: 73325f60 ("ALSA: memalloc: Support for non-coherent page allocation")
Cc: <stable@vger.kernel.org>
Reported-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Link: https://lore.kernel.org/r/20220210123344.8756-2-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Updates cros_ec_codec maintainers.
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Acked-By: NCheng-Yi Chiang <cychiang@chromium.org>
Acked-By: NBenson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20220208031242.227563-1-tzungbi@google.comSigned-off-by: NMark Brown <broonie@kernel.org>

HD-audio driver handles the multiple instances and keeps the static
index that is incremented at each probe.  This becomes a problem when
user tries to re-bind the device via sysfs multiple times; as the
device index isn't cleared unlike rmmod case, it points to the next
element at re-binding, and eventually later you can't probe any more
when it reaches to SNDRV_CARDS_MAX (usually 32).

This patch is an attempt to improve the handling at rebinding.
Instead of a static device index, now we keep a bitmap and assigns to
the first zero bit position.  At the driver remove, in return, the
bitmap slot is cleared again, so that it'll be available for the next
probe.
Reported-by: NAlexander Sergeyev <sergeev917@gmail.com>
Link: https://lore.kernel.org/r/20220209081912.20687-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The current rt5682_jack_detect_handler() assumes the component
and card will always show up and implements an infinite usleep
loop waiting for them to show up.

This does not hold true if a codec interrupt (or other
event) occurs when the card is unbound. The codec driver's
remove  or shutdown functions cannot cancel the workqueue due
to the wait loop. As a result, code can either end up blocking
the workqueue, or hit a kernel oops when the card is freed.

Fix the issue by rescheduling the jack detect handler in
case the card is not ready. In case card never shows up,
the shutdown/remove/suspend calls can now cancel the detect
task.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NPéter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20220207153000.3452802-3-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The current rt5668_jack_detect_handler() assumes the component
and card will always show up and implements an infinite usleep
loop waiting for them to show up.

This does not hold true if a codec interrupt (or other
event) occurs when the card is unbound. The codec driver's
remove  or shutdown functions cannot cancel the workqueue due
to the wait loop. As a result, code can either end up blocking
the workqueue, or hit a kernel oops when the card is freed.

Fix the issue by rescheduling the jack detect handler in
case the card is not ready. In case card never shows up,
the shutdown/remove/suspend calls can now cancel the detect
task.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NPéter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20220207153000.3452802-2-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The current rt5682s_jack_detect_handler() assumes the component
and card will always show up and implements an infinite usleep
loop waiting for them to show up.

This does not hold true if a codec interrupt (or other
event) occurs when the card is unbound. The codec driver's
remove  or shutdown functions cannot cancel the workqueue due
to the wait loop. As a result, code can either end up blocking
the workqueue, or hit a kernel oops when the card is freed.

Fix the issue by rescheduling the jack detect handler in
case the card is not ready. In case card never shows up,
the shutdown/remove/suspend calls can now cancel the detect
task.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NPéter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20220207153000.3452802-1-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Per TAS2770 datasheet there must be a 1 ms delay from reset to first
command. So insert delays into the driver where appropriate.

Fixes: 1a476abc ("tas2770: add tas2770 smart PA kernel driver")
Signed-off-by: NMartin Povišer <povik+lin@cutebit.org>
Link: https://lore.kernel.org/r/20220204095301.5554-1-povik+lin@cutebit.orgSigned-off-by: NMark Brown <broonie@kernel.org>

This reverts commit 9de2b928 ("ASoC: mediatek: Check for error clk
pointer").

With this patch in the tree, Chromebooks running the affected hardware
no longer boot. Bisect points to this patch, and reverting it fixes
the problem.

An analysis of the code with this patch applied shows:

        ret = init_clks(pdev, clk);
        if (ret)
                return ERR_PTR(ret);
...
                for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
                        struct clk *c = clk[data->clk_id[j]];

                        if (IS_ERR(c)) {
                                dev_err(&pdev->dev, "%s: clk unavailable\n",
                                        data->name);
                                return ERR_CAST(c);
                        }

                        scpd->clk[j] = c;
                }

Not all clocks in the clk_names array have to be present. Only the clocks
in the data->clk_id array are actually needed. The code already checks if
the required clocks are available and bails out if not. The assumption that
all clocks have to be present is wrong, and commit 9de2b928 ("ASoC:
mediatek: Check for error clk pointer") needs to be reverted.

Cc: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Cc: Mark Brown <broonie@kernel.org>
Cc: James Liao <jamesjj.liao@mediatek.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Reported-by: NFrank Wunderlich <frank-w@public-files.de>
Reported-by: NDaniel Golle <daniel@makrotopia.org>
Fixes: 9de2b928 ("ASoC: mediatek: Check for error clk pointer")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220207160923.3911501-1-linux@roeck-us.netSigned-off-by: NMark Brown <broonie@kernel.org>

There are some spelling mistakes in some ksft messages. Fix them.
Signed-off-by: NColin Ian King <colin.i.king@gmail.com>
Reviewed-by: NShuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220207092235.240284-1-colin.i.king@gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The variable c is being initialized in an outer for-loop and also
re-initialized inside an inner for-loop. The first initialization
is redundant and can be removed.
Signed-off-by: NColin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20220207140617.341172-1-colin.i.king@gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

This program has only one file so most functions can be static.
Signed-off-by: NMark Brown <broonie@kernel.org>
Reviewed-by: NShuah Khan <skhan@linuxfoundation.org>
Reviewed-by: NJaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220202150902.19563-2-broonie@kernel.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Add some coverage of event generation to mixer-test. Rather than doing a
separate set of writes designed to trigger events we add a step to the
existing write_and_verify() which checks to see if the value we read back
from non-volatile controls matches the value before writing and that an
event is or isn't generated as appropriate. The "tests" for events then
simply check that no spurious or missing events were detected. This avoids
needing further logic to generate appropriate values for each control type
and maximises coverage.

When checking for events we use a timeout of 0. This relies on the kernel
generating any event prior to returning to userspace when setting a control.
That is currently the case and it is difficult to see it changing, if it
does the test will need to be updated. Using a delay of 0 means that we
don't slow things down unduly when checking for no event or when events
fail to be generated.

We don't check behaviour for volatile controls since we can't tell what
the behaviour is supposed to be for any given control.
Signed-off-by: NMark Brown <broonie@kernel.org>
Reviewed-by: NShuah Khan <skhan@linuxfoundation.org>
Reviewed-by: NJaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220202150902.19563-1-broonie@kernel.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Merge series from Mark Brown <broonie@kernel.org>:

The event generation coverage I just wrote shows that the generic ASoC
ops fail to generate events for stereo controls when only the first
channel is changed, we just return the status for the second channel and
discard that for the first.

The ACPI device with CSC3551 or CLSA0100 are sound cards
with multiple instances of CS35L41 connected by I2C or SPI
to the main CPU.

We add an ID to the ignore_serial_bus_ids list to enumerate
all I2C or SPI devices correctly.

The same IDs are also added into serial-multi-instantiate
so that the driver can correctly enumerate the ACPI.
Signed-off-by: NLucas Tanure <tanureal@opensource.cirrus.com>
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220121172431.6876-10-sbinding@opensource.cirrus.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Add support for two and four CS35L41 using the component
binding method
Signed-off-by: NLucas Tanure <tanureal@opensource.cirrus.com>
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20220121172431.6876-9-sbinding@opensource.cirrus.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Add support for spi bus in serial-multi-instantiate driver

Some peripherals can have either a I2C or a SPI connection
to the host (but not both) but use the same HID for both
types. So it is not possible to use the HID to determine
whether it is I2C or SPI. The driver must check the node
to see if it contains I2cSerialBus or SpiSerialBus entries.

For backwards-compatibility with the existing nodes I2C is
checked first and if such entries are found ONLY I2C devices
are created. Since some existing nodes that were already
handled by this driver could also contain unrelated
SpiSerialBus nodes that were previously ignored, and this
preserves that behavior. If there is ever a need to handle
a node where both I2C and SPI devices must be instantiated
this can be added in future.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220121172431.6876-8-sbinding@opensource.cirrus.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>