In hindsight, there were some crucial subtleties overlooked when moving
{of,acpi}_dma_configure() to driver probe time to allow waiting for
IOMMU drivers with -EPROBE_DEFER, and these have become an
ever-increasing source of problems. The IOMMU API has some fundamental
assumptions that iommu_probe_device() is called for every device added
to the system, in the order in which they are added. Calling it in a
random order or not at all dependent on driver binding leads to
malformed groups, a potential lack of isolation for devices with no
driver, and all manner of unexpected concurrency and race conditions.
We've attempted to mitigate the latter with point-fix bodges like
iommu_probe_device_lock, but it's a losing battle and the time has come
to bite the bullet and address the true source of the problem instead.

The crux of the matter is that the firmware parsing actually serves two
distinct purposes; one is identifying the IOMMU instance associated with
a device so we can check its availability, the second is actually
telling that instance about the relevant firmware-provided data for the
device. However the latter also depends on the former, and at the time
there was no good place to defer and retry that separately from the
availability check we also wanted for client driver probe.

Nowadays, though, we have a proper notion of multiple IOMMU instances in
the core API itself, and each one gets a chance to probe its own devices
upon registration, so we can finally make that work as intended for
DT/IORT/VIOT platforms too. All we need is for iommu_probe_device() to
be able to run the iommu_fwspec machinery currently buried deep in the
wrong end of {of,acpi}_dma_configure(). Luckily it turns out to be
surprisingly straightforward to bootstrap this transformation by pretty
much just calling the same path twice. At client driver probe time,
dev->driver is obviously set; conversely at device_add(), or a
subsequent bus_iommu_probe(), any device waiting for an IOMMU really
should *not* have a driver already, so we can use that as a condition to
disambiguate the two cases, and avoid recursing back into the IOMMU core
at the wrong times.

Obviously this isn't the nicest thing, but for now it gives us a
functional baseline to then unpick the layers in between without many
more awkward cross-subsystem patches. There are some minor side-effects
like dma_range_map potentially being created earlier, and some debug
prints being repeated, but these aren't significantly detrimental. Let's
make things work first, then deal with making them nice.

With the basic flow finally in the right order again, the next step is
probably turning the bus->dma_configure paths inside-out, since all we
really need from bus code is its notion of which device and input ID(s)
to parse the common firmware properties with...

Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci-driver.c
Acked-by: Rob Herring (Arm) <robh@kernel.org> # of/device.c
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/e3b191e6fd6ca9a1e84c5e5e40044faf97abb874.1740753261.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Pull sound updates from Takashi Iwai:
 "This was a relatively calm cycle, and most of changes are rather small
  device-specific fixes. Here are highlights:

  Core:
   - Further enhancements of ALSA rawmidi and sequencer APIs for MIDI
     2.0
   - compress-offload API extensions for ASRC support

  ASoC:
   - Allow clocking on each DAI in an audio graph card to be configured
     separately
   - Improved power management for Renesas RZ-SSI
   - KUnit testing for the Cirrus DSP framework
   - Memory to meory operation support for Freescale/NXP platforms
   - Support for pause operations in SOF
   - Support for Allwinner suinv F1C100s, Awinc AW88083, Realtek
     ALC5682I-VE

  HD- and USB-audio:
   - Add support for Focusrite Scarlett 4th Gen 16i16, 18i16, and 18i20
     interfaces via new FCP driver
   - TAS2781 SPI HD-audio sub-codec support
   - Various device-specific quirks as usual"

* tag 'sound-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (235 commits)
  ALSA: hda: tas2781-spi: Fix bogus error handling in tas2781_hda_spi_probe()
  ALSA: hda: tas2781-spi: Fix error code in tas2781_read_acpi()
  ALSA: hda: tas2781-spi: Delete some dead code
  ALSA: usb: fcp: Fix return code from poll ops
  ALSA: usb: fcp: Fix incorrect resp->opcode retrieval
  ALSA: usb: fcp: Fix meter_levels type to __le32
  ALSA: hda/realtek: Enable Mute LED on HP Laptop 14s-fq1xxx
  ALSA: hda: tas2781-spi: Fix -Wsometimes-uninitialized in tasdevice_spi_switch_book()
  ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions
  ALSA: hda: tas2781-spi: select CRC32 instead of CRC32_SARWATE
  ALSA: usb: fcp: Fix hwdep read ops types
  ALSA: scarlett2: Add device_setup option to use FCP driver
  ALSA: FCP: Add Focusrite Control Protocol driver
  ALSA: hda/tas2781: Add tas2781 hda SPI driver
  ALSA: hda/realtek - Fixed headphone distorted sound on Acer Aspire A115-31 laptop
  ASoC: xilinx: xlnx_spdif: Simpify using devm_clk_get_enabled()
  ALSA: hda: Support for Ideapad hotkey mute LEDs
  ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83JX, 83MC and 83NM
  ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83LC
  ASoC: dapm: add support for preparing streams
  ...

This patch was used to add TAS2781 devices on SPI support in sound/pci/hda.
It use ACPI node descript about parameters of TAS2781 on SPI, it like:
    Scope (_SB.PC00.SPI0)
    {
        Device (GSPK)
        {
            Name (_HID, "TXNW2781")  // _HID: Hardware ID
            Method (_CRS, 0, NotSerialized)
            {
                Name (RBUF, ResourceTemplate ()
                {
                    SpiSerialBusV2 (...)
                    SpiSerialBusV2 (...)
                }
            }
        }
    }

And in platform/x86/serial-multi-instantiate.c, those spi devices will be
added into system as a single SPI device, so TAS2781 SPI driver will
probe twice for every single SPI device. And driver will also parser
mono DSP firmware binary and RCA binary for itself.
The code support Realtek as the primary codec.
In patch version-10, add multi devices firmware binary support,
to compatble with windows driver, they can share same firmware binary.

Signed-off-by: Baojun Xu <baojun.xu@ti.com>
Link: https://patch.msgid.link/20241216122008.15425-1-baojun.xu@ti.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

It generally is not OK to use acpi_status and/or AE_ error codes
without CONFIG_ACPI and they really only should be used in
drivers/acpi/ (and not everywhere in there for that matter).

So acpi_get_physical_device_location() needs to be redefined to return
something different from acpi_status (preferably bool) in order to be
used in !CONFIG_ACPI code.

Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Link: https://patch.msgid.link/20241216-fix-ipu-v5-1-3d6b35ddce7b@chromium.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Replace strcpy() with strscpy() in the ACPI device enumeration code.

strcpy() has been deprecated because it is generally unsafe, so it
is better to eliminate it from the kernel source.

Link: https://github.com/KSPP/linux/issues/88
Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com>
Link: https://patch.msgid.link/20240915183822.34588-9-qasim.majeed20@gmail.com
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Merge an ACPI EC driver update, ACPI sysfs interface updates, an ACPI
library function update, and an ACPI APD driver update for 6.12-rc1:

 - Do not release locks during operation region accesses in the ACPI EC
   driver (Rafael Wysocki).

 - Fix up the _STR handling in the ACPI device object sysfs interface,
   make it represent the device object attributes as an attribute group
   and make it rely on driver core functionality for sysfs attrubute
   management (Thomas Weißschuh).

 - Extend error messages printed to the kernel log when acpi_evaluate_dsm()
   fails to include revision and function number (David Wang).

 - Add a new AMDI0015 platform device ID to the ACPi APD driver for AMD
   SoCs (Shyam Sundar S K).

* acpi-ec:
  ACPI: EC: Do not release locks during operation region accesses

* acpi-sysfs:
  ACPI: sysfs: remove return value of acpi_device_setup_files()
  ACPI: sysfs: manage sysfs attributes through device core
  ACPI: sysfs: manage attributes as attribute_group
  ACPI: sysfs: evaluate _STR on each sysfs access
  ACPI: sysfs: validate return type of _STR method

* acpi-utils:
  ACPI: utils: Add rev/func to message when acpi_evaluate_dsm() fails

* acpi-soc:
  ACPI: APD: Add AMDI0015 as platform device

RISC-V platforms need to use dependencies between PCI host bridge, Link
devices and the interrupt controllers to ensure probe order. The
dependency is like below.

Interrupt controller <-- Link Device <-- PCI Host bridge.

If there is no dependency between Link device and PCI Host Bridge,
then PCI devices may be probed prior to Link devices.  If a PCI
device is probed before its Link device, we won't be able to find
its INTx mapping.

So, add the link device's HID to dependency honor list and clear the
dependency after probe is done so that the dependent devices are
unblocked to probe.

Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-9-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Some architectures like RISC-V need to add dependencies without explicit
_DEP. Define a weak function which can be implemented by the architecture.

Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-7-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

RISC-V PLIC and APLIC will have dependency from devices using GSI. So, add
these devices to the honor list.

Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-6-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Some architectures like RISC-V will use implicit dependencies like GSI
map to create dependencies between interrupt controller and devices. To
support doing that, the function which creates the dependency, is
refactored bit and made public so that dependency can be added from
outside of scan.c as well.

Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-5-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>