The ALSA snd_card driver[] field is 16 bytes (including the NUL
terminator), leaving 15 usable characters. The SOF framework
prepends a "sof-" prefix when registering the card, so
card->name = "amd-soundwire" becomes driver name "sof-amd-soundwire"
which is 17 characters and overflows the driver[16] buffer, triggering
a kernel warning.

Fix by shortening the card name to "amd-sdw"; the resulting driver
name "sof-amd-sdw" fits within the 15-character limit.

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260910161728.1452808-5-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ffs(link_mask - 1) computes ffs on (link_mask - 1) instead of
subtracting 1 from the result of ffs(link_mask). For a typical
power-of-2 link_mask this returns the wrong link ID, causing cpu_pin_id
lookup to select the incorrect SoundWire manager.

Fix the operator precedence to ffs(link_mask) - 1 in both
acp-sdw-sof-mach.c and acp-sdw-legacy-mach.c.

Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code")
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260910161728.1452808-4-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>

num_devs was used both as the endpoint count and as the output for
asoc_sdw_parse_sdw_endpoints(), which overwrites it with the codec
configuration count. Introduce a separate num_confs variable to hold
the codec conf count so the two values remain distinct across
codec_conf allocation and card->num_configs assignment.

Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code")
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260910161728.1452808-3-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Add a bounds check in create_sdw_dailink() to validate that the
SoundWire link ID derived from link_mask does not exceed the maximum
supported by the platform. If the link ID is out of range or link_mask
is zero, log an error and return -EINVAL to prevent accessing invalid
CPU pin ID tables.

Applied to both acp-sdw-sof-mach.c and acp-sdw-legacy-mach.c.

Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code")
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260910161728.1452808-2-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Add matching DMI table entry for the ES83xx machine driver, so the
HUAWEI HVY-WXX9 / M1060 board (MateBook D16 2021, Ryzen 5 4600H) can
successfully probe its ES8316 codec via the acp3x-es83xx machine
driver, consistent with the existing M1010/M1020/M1040 entries for
the same board name.

Signed-off-by: Mehmet Aysel <mehmet4ysel@gmail.com>
Link: https://patch.msgid.link/20260825092432.56292-2-mehmet4ysel@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Ville Saarinen <wiza@saarinenkoti.fi> says:

The HP OmniBook X Flip 14-kc0xxx (board 8EA1, Strix Point, ACP 7.2) has no
usable audio on mainline at all. Its BIOS reports an ACP configuration flag
of FLAG_AMD_LEGACY_ONLY_DMIC, which binds the legacy ACP driver and
registers a PDM-only card, so the SoundWire links are never scanned. The
two TAS2783 speaker amplifiers on link 0 and the RT712-VB jack codec on
link 1 never enumerate, and the machine has no playback path whatsoever.

Patch 1 adds a DMI quirk overriding the flag so snd_pci_ps probes. Patch 2
adds the machine entry describing the link topology.

With both applied the card comes up and every path on the machine works:
internal speakers, headphone jack with detection, headset microphone and
the internal DMIC array. Two further patches are needed for the speakers
to render stereo rather than mono, and to survive a system resume; those
are in the TAS2783 codec driver and are being sent separately to the TI
maintainers, since they have no build dependency on this pair.

Related reports for the same root cause on other machines:

  - kernel bugzilla #221226 (ASUS Zenbook S16)
  - CachyOS linux-cachyos#820 (HP OmniBook X Flip 16, board 8EA2 -- the
    sibling board, which would need its own entry; I have no access to
    one and have not added it)

Tested on the affected machine only. I do not have any other ACP 7.2
board, so the gating on patch 2 is written to be conservative rather than
broad.

Testing
=======

The hardware testing was done on v7.1.6, where an equivalent version of
this pair is what makes audio work on the machine. Against the master
commit named below, both patches have been compile-tested only (gcc, W=1,
no new warnings, no new external symbol references).

Patch 2 has been reworked slightly relative to the tested build: the
RT712-VB entry now reuses the existing jack_dmic_endpoints array, which
already describes exactly the AIF1 jack + AIF3 DMIC pairing this board
needs, instead of adding a second identical copy of it. That was a
mechanical substitution, but it has not been through hardware.

Tool disclosure, per Documentation/process/generated-content.rst
================================================================

This work was done in extended interactive sessions with Claude (Anthropic,
model claude-opus-5) acting as a coding and debugging assistant, and a
substantial amount of the analysis and of the patch text originated with
it. Both patches carry an Assisted-by tag as described in
Documentation/process/coding-assistants.rst.

The division of work:

  - The assistant read the DMI data and ACP configuration flag off the
    running machine, identified the flag override as the fix, derived the
    SoundWire topology from the enumerated peripherals, and drafted both
    patches and both changelogs.
  - I ran everything that needed root or physical access, rebooted into
    each build, and did the listening tests. The left/right ordering in
    patch 2 is set by the order of the two amplifier entries; the first
    version had the sides reversed and that was caught by ear, not by the
    assistant.
  - No single prompt generated these patches. The session was iterative
    over roughly a day: inspect state, form a hypothesis, build, reboot,
    measure, discard the hypothesis if the measurement disagreed. Several
    confident intermediate conclusions were wrong and were only caught by
    measurement.

I have reviewed both patches, I understand what they do, and I take
responsibility for them.

Link: https://patch.msgid.link/20260809101439.4798-1-wiza@saarinenkoti.fi

Describe the SoundWire topology of the HP OmniBook X Flip 14-kc0xxx
(board 8EA1): two TAS2783 smart amplifiers aggregated on link 0 (unique
IDs 0xC and 0x9, group_position 0 and 1, name prefixes tas2783-1 and
tas2783-2) driving the left and right internal speakers, and an RT712-VB
on link 1 providing the headset jack on AIF1 and the internal DMIC array
on AIF3. The RT712 amplifier path (AIF2) is left unused because the
speakers are driven by the external TAS2783 pair, so the existing
jack_dmic_endpoints array describes it exactly.

The entry is gated on snd_soc_acpi_amd_sdca_is_device_rt712_vb() so it
does not capture a board carrying a different link 1 codec.

Developed with AI assistance. The assistant derived the link topology
from the enumerated peripherals and drafted the table entry. The order
of the two amplifier entries, which is what assigns the physical sides,
was corrected after a listening test by the submitter.

All hardware measurements quoted above were run by the submitter on the
affected machine. The submitter has reviewed the change, understands it
and takes responsibility for it.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Ville Saarinen <wiza@saarinenkoti.fi>
Link: https://patch.msgid.link/20260809101439.4798-3-wiza@saarinenkoti.fi
Signed-off-by: Mark Brown <broonie@kernel.org>

Convert acp-pci to the pcim-managed PCI life-cycle. Replace
pci_enable_device() with pcim_enable_device() and fold the
open-coded pci_request_regions() + devm_ioremap() pair into a single
pcim_iomap_region() call for BAR0, which reserves and iomaps the
register window.

This lets the driver drop the manual pci_release_regions() and
pci_disable_device() calls from the probe error path; pcim releases
the device and region automatically on detach or probe failure. The
error check moves from a NULL test to IS_ERR(), since pcim_iomap_region()
returns an IOMEM_ERR_PTR on failure.

The child platform devices only use devm_ioremap() on their sub-range
of BAR0 (no request_mem_region), so reserving the full BAR0 here does
not conflict with them.

Assisted-by: opencode:hy3-free
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260720001054.1439409-1-rosenp@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> says:

the objective of this series is still to prepare making struct
platform_device_id::driver_data an anonymous union. See
https://lore.kernel.org/all/cover.1780048925.git.u.kleine-koenig@baylibre.com/
for the details about that.

Link: https://patch.msgid.link/cover.1784528081.git.u.kleine-koenig@baylibre.com

 - Add a trailing comma for initializers unless the closing brace is on
   the same line and for the list terminator;
 - Use a single space in the list terminator;

Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://patch.msgid.link/08137cf5b3cdd0cc2e00da32256664f3cb9b1e4e.1784528081.git.u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>