kernel/linux.git/drivers/acpi/scan.c, branch v6.1.168

ACPI: scan: Add Intel CVS ACPI HIDs to acpi_ignore_dep_ids[]

2025-12-06T21:12:15+00:00

[ Upstream commit 4405a214df146775338a1e6232701a29024b82e1 ] Some x86/ACPI laptops with MIPI cameras have a INTC10DE or INTC10E0 ACPI device in the _DEP dependency list of the ACPI devices for the camera- sensors (which have flags.honor_deps set). These devices are for an Intel Vision CVS chip for which an out of tree driver is available [1]. The camera sensor works fine without a driver being loaded for this ACPI device on the 2 laptops this was tested on: ThinkPad X1 Carbon Gen 12 (Meteor Lake) ThinkPad X1 2-in-1 Gen 10 (Arrow Lake) For now add these HIDs to acpi_ignore_dep_ids[] so that acpi_dev_ready_for_enumeration() will return true once the other _DEP dependencies are met and an i2c_client for the camera sensor will get instantiated. Link: https://github.com/intel/vision-drivers/ [1] Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250829142748.21089-1-hansg@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: scan: Fix device check notification handling

2024-03-26T22:20:38+00:00

[ Upstream commit 793551c965116d9dfaf0550dacae1396a20efa69 ] It is generally invalid to fail a Device Check notification if the scan handler has not been attached to the given device after a bus rescan, because there may be valid reasons for the scan handler to refuse attaching to the device (for example, the device is not ready). For this reason, modify acpi_scan_device_check() to return 0 in that case without printing a warning. While at it, reduce the log level of the "already enumerated" message in the same function, because it is only interesting when debugging notification handling Fixes: 443fc8202272 ("ACPI / hotplug: Rework generic code to handle suprise removals") Signed-off-by: Rafael J. Wysocki Reviewed-by: Jonathan Cameron Signed-off-by: Sasha Levin

iommu: Avoid more races around device probe

2023-12-13T17:39:17+00:00

commit a2e7e59a94269484a83386972ca07c22fd188854 upstream. It turns out there are more subtle races beyond just the main part of __iommu_probe_device() itself running in parallel - the dev_iommu_free() on the way out of an unsuccessful probe can still manage to trip up concurrent accesses to a device's fwspec. Thus, extend the scope of iommu_probe_device_lock() to also serialise fwspec creation and initial retrieval. Reported-by: Zhenhua Huang Link: https://lore.kernel.org/linux-iommu/e2e20e1c-6450-4ac5-9804-b0000acdf7de@quicinc.com/ Fixes: 01657bc14a39 ("iommu: Avoid races around device probe") Signed-off-by: Robin Murphy Acked-by: Greg Kroah-Hartman Reviewed-by: André Draszik Tested-by: André Draszik Link: https://lore.kernel.org/r/16f433658661d7cadfea51e7c65da95826112a2b.1700071477.git.robin.murphy@arm.com Cc: stable@vger.kernel.org Signed-off-by: Joerg Roedel Signed-off-by: Robin Murphy Signed-off-by: Greg Kroah-Hartman

ACPI: scan: Create platform device for CS35L56

2023-08-16T16:27:31+00:00

commit 1cd0302be5645420f73090aee26fa787287e1096 upstream. The ACPI device CSC3556 is a Cirrus Logic CS35L56 mono amplifier which is used in multiples, and can be connected either to I2C or SPI. There will be multiple instances under the same Device() node. Add it to ignore_serial_bus_ids and handle it in the serial-multi-instantiate driver. There can be a 5th I2cSerialBusV2, but this is an alias address and doesn't represent a real device. Ignore this by having a dummy 5th entry in the serial-multi-instantiate instance list with the name of a non-existent driver, on the same pattern as done for bsg2150. Signed-off-by: Simon Trimmer Signed-off-by: Richard Fitzgerald Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20230728111345.7224-1-rf@opensource.cirrus.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

ACPI: Fix selecting wrong ACPI fwnode for the iGPU on some Dell laptops

2023-01-18T10:58:11+00:00

commit f64e4275ef7407d5c3eca20436519bbd1f796e40 upstream. The Dell Latitude E6430 both with and without the optional NVidia dGPU has a bug in its ACPI tables which is causing Linux to assign the wrong ACPI fwnode / companion to the pci_device for the i915 iGPU. Specifically under the PCI root bridge there are these 2 ACPI Device()s : Scope (_SB.PCI0) { Device (GFX0) { Name (_ADR, 0x00020000) // _ADR: Address } ... Device (VID) { Name (_ADR, 0x00020000) // _ADR: Address ... Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching { VDP8 = Arg0 VDP1 (One, VDP8) } Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices { ... } ... } } The non-functional GFX0 ACPI device is a problem, because this gets returned as ACPI companion-device by acpi_find_child_device() for the iGPU. This is a long standing problem and the i915 driver does use the ACPI companion for some things, but works fine without it. However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device and that is set on the wrong acpi_device because of the wrong acpi_find_child_device() return. This breaks the ACPI video code, leading to non working backlight control in some cases. Add a type.backlight flag, mark ACPI video bus devices with this and make find_child_checks() return a higher score for children with this flag set, so that it picks the right companion-device. Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") Co-developed-by: Rafael J. Wysocki Signed-off-by: Hans de Goede Cc: 6.1+ # 6.1+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: scan: Add LATT2021 to acpi_ignore_dep_ids[]

2022-10-26T11:44:13+00:00

Some x86/ACPI laptops with MIPI cameras have a LATT2021 ACPI device in the _DEP dependency list of the ACPI devices for the camera-sensors (which have flags.honor_deps set). The _DDN for the LATT2021 device is "Lattice FW Update Client Driver", suggesting that this is used for firmware updates of something. There is no Linux driver for this and if Linux gets support for updates it will likely be in userspace through fwupd. For now add the LATT2021 HID to acpi_ignore_dep_ids[] so that acpi_dev_ready_for_enumeration() will return true once the other _DEP dependencies are met. Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki

ACPI: scan: Fix DMA range assignment

2022-10-19T18:27:31+00:00

Assigning the device's dma_range_map from the iterator variable after the loop means it always points to the empty terminator at the end of the map, which is not what we want. Similarly, freeing the iterator on error when it points to somwhere in the middle of the allocated array won't work either. Fix this. Fixes: bf2ee8d0c385 ("ACPI: scan: Support multiple DMA windows with different offsets") Signed-off-by: Robin Murphy Reviewed-by: Jianmin Lv Tested-by: Jeremy Linton Tested-by: Yicong Yang Reviewed-by: Lorenzo Pieralisi Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi-scan', 'acpi-bus' and 'acpi-platform'

2022-09-30T18:28:22+00:00

Merge changes related to ACPI device enumeration and ACPI support for platform devices for 6.1-rc1: - Clean up ACPI platform devices support code (Andy Shevchenko, John Garry). - Clean up ACPI bus management code (Andy Shevchenko, ye xingchen). - Add support for multiple DMA windows with different offsets to the ACPI device enumeration code and use it on LoongArch (Jianmin Lv). * acpi-scan: LoongArch: Use acpi_arch_dma_setup() and remove ARCH_HAS_PHYS_TO_DMA ACPI: scan: Support multiple DMA windows with different offsets * acpi-bus: ACPI: bus: Refactor ACPI matching functions for better readability ACPI: bus: Drop kernel doc annotation from acpi_bus_notify() ACPI: bus: Remove the unneeded result variable * acpi-platform: ACPI: platform: Use PLATFORM_DEVID_NONE in acpi_create_platform_device() ACPI: platform: Sort forbidden_id_list[] in ascending order ACPI: platform: Use sizeof(*pointer) instead of sizeof(type) ACPI: platform: Remove redundant print on -ENOMEM ACPI: platform: Get rid of redundant 'else'

ACPI: scan: Add acpi_dev_get_next_consumer_dev()

2022-09-24T17:12:32+00:00

In commit b83e2b306736 ("ACPI: scan: Add function to fetch dependent of ACPI device") we added a means of fetching the first device to declare itself dependent on another ACPI device in the _DEP method. One assumption in that patch was that there would only be a single consuming device, but this has not held. Replace that function with a new function that fetches the next consumer of a supplier device. Where no "previous" consumer is passed in, it behaves identically to the original function. Reviewed-by: Hans de Goede Signed-off-by: Daniel Scally Signed-off-by: Rafael J. Wysocki

ACPI: scan: Support multiple DMA windows with different offsets

2022-09-24T16:39:21+00:00

In DT systems configurations, of_dma_get_range() returns struct bus_dma_region DMA regions; they are used to set-up devices DMA windows with different offset available for translation between DMA address and CPU address. In ACPI systems configuration, acpi_dma_get_range() does not return DMA regions yet and that precludes setting up the dev->dma_range_map pointer and therefore DMA regions with multiple offsets. Update acpi_dma_get_range() to return struct bus_dma_region DMA regions like of_dma_get_range() does. After updating acpi_dma_get_range(), acpi_arch_dma_setup() is changed for ARM64, where the original dma_addr and size are removed as these arguments are now redundant, and pass 0 and U64_MAX for dma_base and size of arch_setup_dma_ops; this is a simplification consistent with what other ACPI architectures also pass to iommu_setup_dma_ops(). Reviewed-by: Robin Murphy Signed-off-by: Jianmin Lv Reviewed-by: Lorenzo Pieralisi Signed-off-by: Rafael J. Wysocki