Pull soundwire updates from Vinod Koul:

 - CLOCK_STOP_MODE1 support in bus and Intel driver

 - DMI quirks for disabling ghost on Lenovo Yoga 7 Pro, Lenovo Yoga
   Slim 7, Lenovo Pro 9, Lenovo Yoga Slim 7i 14IPH11.

 - Few more codecs as wake capable, tac5xx2 family, rt718, rt766/rt767

 - Qualcomm Shikra SoC support

* tag 'soundwire-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire:
  soundwire: intel_auxdevice: add rt766/rt767 codec to wake_capable_list
  soundwire: dmi-quirks: Disable ghost rt711 on Lenovo Yoga Slim 7
  soundwire: dmi-quirks: Disable ghost Realtek on Lenovo Yoga 7 Pro
  soundwire: intel_auxdevice: add rt718 codec to wake_capable_list
  soundwire: dmi-quirks: drop the ghost RT1320 on the Surface Pro 11 (Intel)
  soundwire: qcom: add EE-aware register layout for Shikra
  dt-bindings: soundwire: qcom: add qcom,shikra-soundwire compatible
  soundwire: Intel: stop sdw clock in system suspend
  soundwire: Intel: add wake_enable parameter to stop_bus ops
  soundwire: bus: add CLOCK_STOP_MODE1 support back
  soundwire: dmi-quirks: Disable ghost Realtek on Lenovo Pro 9
  soundwire: qcom: cache SCP_ADDRPAGE1/2 to preserve MBQ atomicity
  soundwire: bus: iterate DT compatibles for class-ID match
  soundwire: fix repeated words in log messages
  soundwire: intel_auxdevice: add tac5xx2 family to wake_capable_list
  soundwire: bus_type: Use devres to free slave IDA
  soundwire: dmi-quirks: add Lenovo Yoga Slim 7i 14IPH11
  soundwire: intel: initialise quirk_mask before reading it

rt766/rt767 have wake capability. Add it to the wake_capable_list.

Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/20260929-rt766-wake-v3-1-09c0b82c72a6@realtek.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

The device reports both cs42l43 and rt711. But the rt711 codec does not
physically exist. Adding a quirk to disable the ghost device.

Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260928105640.3014318-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

Another Lenovo module that has a Realtek device in the ACPI that
doesn't exist in the physical hardware.

Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260928105640.3014318-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

rt718 has wake capability. Add it to the wake_capable_list.

Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://patch.msgid.link/20260924-rt718fix-v1-1-d92674696e73@realtek.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

The Microsoft Surface Pro 11 for Business (Intel, Lunar Lake) carries a
single physical RT1320 amplifier on link 0 and describes it twice:

  SWRA  _ADR 0x000030025D132000   SDCA class 0
  SWRB  _ADR 0x000030025D132001   SDCA class 1

Identical apart from the class id: same link, same manufacturer, part and
version, same unique id 0. The part reports class 1, so only SWRB
enumerates. SWRA never attaches on any boot or firmware version tested,
including the November 2025 bundle.

The ghost is not harmless. It consumes an amplifier index in
find_acpi_adr_device(), so the real part is named "rt1320-2" and the stock
sof-soundwire UCM profile enables switches on a device that is not there.
Its endpoints also reach create_sdw_dailink(), which builds DAI link names
from link id and function type alone; the ghost declares the same SmartMic
function as the real part, so the card fails to register at all:

  sysfs: cannot create duplicate filename
    '.../sof_sdw/SDW0-Capture-SmartMic'
  kobject_add_internal failed for SDW0-Capture-SmartMic with -EEXIST
  sof_sdw sof_sdw: probe with driver sof_sdw failed with error -12

Remap its _ADR to zero so sdw_acpi_find_slaves() never creates the
peripheral, which is how ghost devices are handled already - see
ghost_realtek and global_ghost_adr in this file. Both failures then
disappear, because neither path is reached.

Matched on DMI_PRODUCT_SKU rather than the product name. A later batch of
the same model could carry a different RT1320 version, which would change
the _ADR; keying on the SKU keeps this remap to the hardware it was
verified on, and follows dell_sku_0A3E above.

Link: https://lore.kernel.org/linux-sound/20260830151516.44629-1-lsa.uz@pm.me/
Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Suggested-by: Bard Liao <bard.liao@intel.com>
Signed-off-by: Sergey Lebedev <lsa.uz@pm.me>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Tested-by: German Pablo Lindo <germanpapulindez@gmail.com>
Link: https://patch.msgid.link/20260913210849.6446-1-lsa.uz@pm.me
Signed-off-by: Vinod Koul <vkoul@kernel.org>

On SoundWire v2.0 and later hardware, FIFO, and status
registers are banked per Execution Environment (EE).
The existing driver assumes the SoundWire controller is
assigned to EE1, which is true for all currently supported
Qualcomm SoCs.

Shikra is an exception and assigns the controller to EE0.
As a result, the relevant register windows are located at
different offsets and cannot be accessed using the default
EE1 register layout.

Add an ee field to the SoC match data and introduce a
dedicated qcom,shikra-soundwire compatible with ee = 0.
The driver uses this information at probe time to select
the correct register layout, while all existing platforms
continue to use the default EE1 configuration.

Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Link: https://patch.msgid.link/20260910-shikra_soundwire_support-v2-2-f98c9a6ea1e1@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

debugfs_create_str() is being made read-only because its generic write
path is hard to make safe without adding more locking to the helper.

Convert the SoundWire firmware_file entry to a local write-only file
operation before removing writable string support from
debugfs_create_str().

Copy the firmware name before request_firmware() so later debugfs writes
cannot replace the string while it is being used.

Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Link: https://patch.msgid.link/20260807100053.1089834-3-chenyichong@uniontech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Perform clock stop with proper mode so that the Peripherals can enter
the deserved power state. And keep the bus unwakeable because there is
no need to wake up the bus in system suspend.

Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260901030311.232823-4-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

Currently, we assume the bus is wakeable when the bus clock stops. But
in some case like system suspend, we want to stop the bus but keep the
bus unwakeable.
No function change in this commit.

Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260901030311.232823-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>