05 Jun, 2019
1 commit
-
Based on 1 normalized pattern(s):
this file is released under the gplv2
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 68 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Armijn Hemel
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190114.292346262@linutronix.de
Signed-off-by: Greg Kroah-Hartman
27 Nov, 2018
1 commit
-
Instead of relying on the "platform_notify" callback hook,
introducing separate notification function
acpi_platform_notify() and calling that directly from
drivers core when device entries are added and removed.Signed-off-by: Heikki Krogerus
Acked-by: Linus Walleij
Reviewed-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
10 Sep, 2018
1 commit
-
There would be useful to have in future the similar API in platform
core, as we have, for example, for PCI subsystem, to check if device
belongs to it.Thus, split out conditional to a macro dev_is_platform() for wide use.
No functional change intended.
Signed-off-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
10 May, 2017
1 commit
-
Pull IOMMU updates from Joerg Roedel:
- code optimizations for the Intel VT-d driver
- ability to switch off a previously enabled Intel IOMMU
- support for 'struct iommu_device' for OMAP, Rockchip and Mediatek
IOMMUs- header optimizations for IOMMU core code headers and a few fixes that
became necessary in other parts of the kernel because of that- ACPI/IORT updates and fixes
- Exynos IOMMU optimizations
- updates for the IOMMU dma-api code to bring it closer to use per-cpu
iova caches- new command-line option to set default domain type allocated by the
iommu core code- another command line option to allow the Intel IOMMU switched off in
a tboot environment- ARM/SMMU: TLB sync optimisations for SMMUv2, Support for using an
IDENTITY domain in conjunction with DMA ops, Support for SMR masking,
Support for 16-bit ASIDs (was previously broken)- various other small fixes and improvements
* tag 'iommu-updates-v4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (63 commits)
soc/qbman: Move dma-mapping.h include to qman_priv.h
soc/qbman: Fix implicit header dependency now causing build fails
iommu: Remove trace-events include from iommu.h
iommu: Remove pci.h include from trace/events/iommu.h
arm: dma-mapping: Don't override dma_ops in arch_setup_dma_ops()
ACPI/IORT: Fix CONFIG_IOMMU_API dependency
iommu/vt-d: Don't print the failure message when booting non-kdump kernel
iommu: Move report_iommu_fault() to iommu.c
iommu: Include device.h in iommu.h
x86, iommu/vt-d: Add an option to disable Intel IOMMU force on
iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
iommu/arm-smmu: Correct sid to mask
iommu/amd: Fix incorrect error handling in amd_iommu_bind_pasid()
iommu: Make iommu_bus_notifier return NOTIFY_DONE rather than error code
omap3isp: Remove iommu_group related code
iommu/omap: Add iommu-group support
iommu/omap: Make use of 'struct iommu_device'
iommu/omap: Store iommu_dev pointer in arch_data
iommu/omap: Move data structures to omap-iommu.h
iommu/omap: Drop legacy-style device support
...
06 May, 2017
1 commit
-
Pull arm64 updates from Catalin Marinas:
- kdump support, including two necessary memblock additions:
memblock_clear_nomap() and memblock_cap_memory_range()- ARMv8.3 HWCAP bits for JavaScript conversion instructions, complex
numbers and weaker release consistency- arm64 ACPI platform MSI support
- arm perf updates: ACPI PMU support, L3 cache PMU in some Qualcomm
SoCs, Cortex-A53 L2 cache events and DTLB refills, MAINTAINERS update
for DT perf bindings- architected timer errata framework (the arch/arm64 changes only)
- support for DMA_ATTR_FORCE_CONTIGUOUS in the arm64 iommu DMA API
- arm64 KVM refactoring to use common system register definitions
- remove support for ASID-tagged VIVT I-cache (no ARMv8 implementation
using it and deprecated in the architecture) together with some
I-cache handling clean-up- PE/COFF EFI header clean-up/hardening
- define BUG() instruction without CONFIG_BUG
* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (92 commits)
arm64: Fix the DMA mmap and get_sgtable API with DMA_ATTR_FORCE_CONTIGUOUS
arm64: Print DT machine model in setup_machine_fdt()
arm64: pmu: Wire-up Cortex A53 L2 cache events and DTLB refills
arm64: module: split core and init PLT sections
arm64: pmuv3: handle pmuv3+
arm64: Add CNTFRQ_EL0 trap handler
arm64: Silence spurious kbuild warning on menuconfig
arm64: pmuv3: use arm_pmu ACPI framework
arm64: pmuv3: handle !PMUv3 when probing
drivers/perf: arm_pmu: add ACPI framework
arm64: add function to get a cpu's MADT GICC table
drivers/perf: arm_pmu: split out platform device probe logic
drivers/perf: arm_pmu: move irq request/free into probe
drivers/perf: arm_pmu: split cpu-local irq request/free
drivers/perf: arm_pmu: rename irq request/free functions
drivers/perf: arm_pmu: handle no platform_device
drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs()
drivers/perf: arm_pmu: factor out pmu registration
drivers/perf: arm_pmu: fold init into alloc
drivers/perf: arm_pmu: define armpmu_init_fn
...
05 May, 2017
1 commit
-
…mu', 'arm/core', 'x86/vt-d', 'x86/amd' and 'core' into next
20 Apr, 2017
1 commit
-
Configuring DMA ops at probe time will allow deferring device probe when
the IOMMU isn't available yet. The dma_configure for the device is
now called from the generic device_attach callback just before the
bus/driver probe is called. This way, configuring the DMA ops for the
device would be called at the same place for all bus_types, hence the
deferred probing mechanism should work for all buses as well.pci_bus_add_devices (platform/amba)(_device_create/driver_register)
| |
pci_bus_add_device (device_add/driver_register)
| |
device_attach device_initial_probe
| |
__device_attach_driver __device_attach_driver
|
driver_probe_device
|
really_probe
|
dma_configureSimilarly on the device/driver_unregister path __device_release_driver is
called which inturn calls dma_deconfigure.This patch changes the dma ops configuration to probe time for
both OF and ACPI based platform/amba/pci bus devices.Tested-by: Marek Szyprowski
Tested-by: Hanjun Guo
Reviewed-by: Robin Murphy
Acked-by: Rob Herring
Acked-by: Bjorn Helgaas (drivers/pci part)
Acked-by: Rafael J. Wysocki
Signed-off-by: Sricharan R
Signed-off-by: Joerg Roedel
01 Apr, 2017
1 commit
-
Commit c2a6bbaf0c5f (ACPI / scan: Prefer devices without _HID/_CID
for _ADR matching) added a list_empty(&adev->pnp.ids) check to
find_child_checks() so as to catch situations in which the ACPI
core attempts to decode _ADR for a device having a _HID too which
is strictly against the spec. However, it overlooked the fact that
the adev->pnp.ids list for the devices taken into account by
find_child_checks() may contain device IDs set internally by the
kernel, like "LNXVIDEO" (thanks to Zhang Rui for that realization),
and it broke the enumeration of those devices as a result.To unbreak it, replace the overly coarse grained list_empty()
check with a much more precise check against the pnp.type.platform_id
flag which is only set for devices having a _HID (that's how it
should be done from the start, as having both _ADR and _CID is
actually permitted).Fixes: c2a6bbaf0c5f (ACPI / scan: Prefer devices without _HID/_CID for _ADR matching)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=194889
Reported-and-tested-by: Mike
Tested-by: Hans de Goede
Cc: 4.10+ # 4.10+
Signed-off-by: Rafael J. Wysocki
30 Mar, 2017
1 commit
-
By allowing platform MSI domain to be created on ACPI platforms,
a platform device MSI domain can be set-up when it is probed.In order to do that, the MSI domain the platform device connects
to should be retrieved, so the iort_get_platform_device_domain() is
introduced to retrieve the domain from the IORT kernel layer.With the domain retrieved, we need a proper way to set the
domain to platform device.Given that some platform devices (irqchips) require the MSI irqdomain
to be their interrupt parent domain, the MSI irqdomain should be
determined before platform device is probed but after the platform
device is allocated which means that the code setting up the MSI
irqdomain, ie acpi_configure_pmsi_domain() should be called in
acpi_platform_notify() (that is triggered after adding a device but
before the respective driver is probed) for the platform MSI domain
code set-up path to work properly.Acked-by: Rafael J. Wysocki [for glue.c]
Signed-off-by: Hanjun Guo
[lorenzo.pieralisi@arm.com: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi
Tested-by: Ming Lei
Tested-by: Wei Xu
Tested-by: Sinan Kaya
Cc: Marc Zyngier
Cc: Lorenzo Pieralisi
Cc: Tomasz Nowicki
03 Jan, 2017
1 commit
-
The way acpi_find_child_device() works currently is that, if there
are two (or more) devices with the same _ADR value in the same
namespace scope (which is not specifically allowed by the spec and
the OS behavior in that case is not defined), the first one of them
found to be present (with the help of _STA) will be returned.This covers the majority of cases, but is not sufficient if some of
the devices in question have a _HID (or _CID) returning some valid
ACPI/PNP device IDs (which is disallowed by the spec) and the
ASL writers' expectation appears to be that the OS will match
devices without a valid ACPI/PNP device ID against a given bus
address first.To cover this special case as well, modify find_child_checks()
to prefer devices without ACPI/PNP device IDs over devices that
have them.Suggested-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
Tested-by: Hans de Goede
27 Dec, 2016
1 commit
-
The acpi_bind_one() error return path can be hit either on physical node
allocation failure or if the device being configured is already
associated with an ACPI node and its ACPI companion does not match the
one acpi_bind_one() is setting it up with. In both cases the error
return path is executed before DMA is configured for a device therefore
there is no need to call acpi_dma_deconfigure() on the function error
return path.Furthermore, if acpi_bind_one() does configure DMA for a device (ie it
successfully executes acpi_dma_configure()) acpi_bind_one() always
completes execution successfully hence there is no need to add an exit
path to deconfigure the DMA set-up (ie by calling acpi_dma_deconfigure()).Remove the misplaced acpi_dma_deconfigure() in acpi_bind_one() to
reinstate its correct error return path behaviour.Fixes: d760a1baf20e (ACPI: Implement acpi_dma_configure)
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Rafael J. Wysocki
29 Nov, 2016
1 commit
-
On DT based systems, the of_dma_configure() API implements DMA
configuration for a given device. On ACPI systems an API equivalent to
of_dma_configure() is missing which implies that it is currently not
possible to set-up DMA operations for devices through the ACPI generic
kernel layer.This patch fills the gap by introducing acpi_dma_configure/deconfigure()
calls that for now are just wrappers around arch_setup_dma_ops() and
arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.Since acpi_dma_configure() is used to configure DMA operations, the
function initializes the dma/coherent_dma masks to sane default values
if the current masks are uninitialized (also to keep the default values
consistent with DT systems) to make sure the device has a complete
default DMA set-up.The DMA range size passed to arch_setup_dma_ops() is sized according
to the device coherent_dma_mask (starting at address 0x0), mirroring the
DT probing path behaviour when a dma-ranges property is not provided
for the device being probed; this changes the current arch_setup_dma_ops()
call parameters in the ACPI probing case, but since arch_setup_dma_ops()
is a NOP on all architectures but ARM/ARM64 this patch does not change
the current kernel behaviour on them.Signed-off-by: Lorenzo Pieralisi
Acked-by: Bjorn Helgaas [pci]
Acked-by: Rafael J. Wysocki
Reviewed-by: Tomasz Nowicki
Tested-by: Hanjun Guo
Tested-by: Tomasz Nowicki
Cc: Bjorn Helgaas
Cc: Robin Murphy
Cc: Tomasz Nowicki
Cc: Joerg Roedel
Cc: "Rafael J. Wysocki"
Signed-off-by: Will Deacon
07 Nov, 2015
2 commits
-
* acpi-pci:
PCI: ACPI: Add support for PCI device DMA coherency
PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()
of/pci: Fix pci_get_host_bridge_device leak
device property: ACPI: Remove unused DMA APIs
device property: ACPI: Make use of the new DMA Attribute APIs
device property: Adding DMA Attribute APIs for Generic Devices
ACPI: Adding DMA Attribute APIs for ACPI Device
device property: Introducing enum dev_dma_attr
ACPI: Honor ACPI _CCA attribute settingConflicts:
drivers/crypto/ccp/ccp-platform.c -
Now that we have the new DMA attribute APIs, we can replace the older
acpi_check_dma() and device_dma_is_coherent().Signed-off-by: Suravee Suthikulpanit
Acked-by: Bjorn Helgaas
Reviewed-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
15 Sep, 2015
1 commit
-
This patch changes the type of the return value of the init_acpi_device_notify()
method to be void, as this method never fails and its return value is never
used.Signed-off-by: Rami Rosen
Signed-off-by: Rafael J. Wysocki
15 Jun, 2015
1 commit
-
This patch implements support for ACPI _CCA object, which is introduced in
ACPIv5.1, can be used for specifying device DMA coherency attribute.The parsing logic traverses device namespace to parse coherency
information, and stores it in acpi_device_flags. Then uses it to call
arch_setup_dma_ops() when creating each device enumerated in DSDT
during ACPI scan.This patch also introduces acpi_dma_is_coherent(), which provides
an interface for device drivers to check the coherency information
similarly to the of_dma_is_coherent().Signed-off-by: Mark Salter
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Rafael J. Wysocki
17 Mar, 2015
1 commit
-
Now that the ACPI companions of devices are represented by pointers
to struct fwnode_handle, it is not quite efficient to check whether
or not an ACPI companion of a device is present by evaluating the
ACPI_COMPANION() macro.For this reason, introduce a special static inline routine for that,
has_acpi_companion(), and update the code to use it where applicable.Signed-off-by: Rafael J. Wysocki
11 Feb, 2014
1 commit
-
In some cases it may be necessary to perform certain setup/cleanup
operations on a device object representing a physical device after
it has been associated with an ACPI companion by acpi_bind_one() or
before disassociating it from that companion by acpi_unbind_one(),
respectively. If there is a struct acpi_bus_type object for the
given device's bus type, the .setup()/.cleanup() callbacks from there
are executed for these purposes. However, an analogous mechanism will
be necessary for devices whose bus types don't have corresponding
struct acpi_bus_type objects and that have specific ACPI scan handlers.For those devices, add new .bind() and .unbind() callbacks to struct
acpi_scan_handler that will be executed by acpi_platform_notify()
right after the given device has been associated with an ACPI
comapnion and by acpi_platform_notify_remove() right before calling
acpi_unbind_one() for that device, respectively.To make that work for scan handlers registering new devices in their
.attach() callbacks, modify acpi_scan_attach_handler() to set the
ACPI device object's handler field before calling .attach() from the
scan handler at hand.This changeset includes a fix from Mika Westerberg.
Signed-off-by: Rafael J. Wysocki
07 Dec, 2013
7 commits
-
Since drivers/ide/ide-acpi.c is the only remaining user of
acpi_get_child(), move that function into that file as a static
routine.Signed-off-by: Rafael J. Wysocki
-
There is no reason to pass an ACPI handle to acpi_bind_one() instead
of a struct acpi_device pointer to the target device object, so
modify that function to take a struct acpi_device pointer as its
second argument and update all code depending on it accordingly.Signed-off-by: Rafael J. Wysocki
Tested-by: Lan Tianyu # for USB/ACPI -
Replace the .find_device function pointer in struct acpi_bus_type
with a new one, .find_companion, that is supposed to point to a
function returning struct acpi_device pointer (instead of an int)
and takes one argument (instead of two). This way the role of
this callback is more clear and the implementation of it can
be more straightforward.Update all of the users of struct acpi_bus_type (PCI, PNP/ACPI and
USB) to reflect the structure change.Signed-off-by: Rafael J. Wysocki
Tested-by: Lan Tianyu # for USB/ACPI -
Modify acpi_preset_companion() to take a struct acpi_device pointer
instead of an ACPI handle as its second argument and redefine it as
a static inline wrapper around ACPI_COMPANION_SET() passing the
return value of acpi_find_child_device() directly as the second
argument to it. Update its users to pass struct acpi_device
pointers instead of ACPI handles to it.This allows some unnecessary acpi_bus_get_device() calls to be
avoided.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Aaron Lu
Tested-by: Aaron Lu # for ATA binding -
Since acpi_get_child() is the only user of acpi_find_child() now,
drop the static inline definition of the former and redefine the
latter as new acpi_get_child().Signed-off-by: Rafael J. Wysocki
Reviewed-by: Aaron Lu
Tested-by: Aaron Lu # for ATA binding -
It is much more efficient to use acpi_find_child_device()
for child devices lookup in acpi_pci_find_device() and pass
ACPI_COMPANION(dev->parent) to it directly instead of obtaining
ACPI_HANDLE() of ACPI_COMPANION(dev->parent) and passing it to
acpi_find_child() which has to run acpi_bus_get_device() to
obtain ACPI_COMPANION(dev->parent) from that again.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Aaron Lu -
Now that we create a struct acpi_device object for every ACPI
namespace node representing a device, it is not necessary to
use acpi_walk_namespace() for child device lookup in
acpi_find_child() any more. Instead, we can simply walk the
list of children of the given struct acpi_device object and
return the matching one (or the one which is the best match if
there are more of them). The checks done during the matching
loop can be simplified too so that the secondary namespace walks
in find_child_checks() are not necessary any more.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Aaron Lu
15 Nov, 2013
2 commits
-
When associating a "physical" device with an ACPI device object
acpi_bind_one() only uses get_device() to increment the reference
counter of the former, but there is no reason not to do that with
the latter too. Among other things, that may help to avoid
use-after-free when an ACPI device object is freed without calling
acpi_unbind_one() for all "physical" devices associated with it
(that only can happen in buggy code, but then it's better if the
kernel doesn't crash as a result of a bug).For this reason, modify acpi_bind_one() to apply get_device() to
the ACPI device object too and update acpi_unbind_one() to drop
that reference using put_device() as appropriate.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
Reviewed-by: Lan Tianyu -
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
Tested-by: Mika Westerberg # on Haswell
Reviewed-by: Mika Westerberg
Reviewed-by: Aaron Lu # for ATA and SDIO part
10 Sep, 2013
1 commit
-
As reported at https://bugzilla.kernel.org/show_bug.cgi?id=60829,
there still are cases in which do_find_child() doesn't choose the
ACPI device object it is "expected" to choose if there are more such
objects matching one PCI device present. This particular problem may
be worked around by making do_find_child() return device obejcts witn
_STA whose result indicates that the device is enabled before device
objects without _STA if there's more than one device object to choose
from.This change doesn't affect the case in which there's only one
matching ACPI device object per PCI device.References: https://bugzilla.kernel.org/show_bug.cgi?id=60829
Reported-by: Peter Wu
Tested-by: Felix Lisczyk
Signed-off-by: Rafael J. Wysocki
09 Aug, 2013
2 commits
-
Although the device links created by acpi_bind_one() are not
essential from the kernel functionality point of view, user space
may be confused when they are missing, so print diagnostic messages
to the kernel log if they can't be created.Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani -
The out_free label in acpi_bind_one() is only jumped to from one
place, so in fact it is not necessary, because the code below it
can be moved to that place directly. Move that code and drop the
label.Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
08 Aug, 2013
7 commits
-
The error code path in acpi_unbind_one() is unnecessarily complicated
(in particular, the err label is not really necessary) and the error
message printed by it is inaccurate (there's nothing called
'acpi_handle' in that function), so clean up those things.Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Acked-by: Yasuaki Ishimatsu -
Since acpi_unbind_one() walks physical_node_list under the ACPI
device object's physical_node_lock mutex and the walk may be
terminated as soon as the matching entry has been found, it is
not necessary to use list_for_each_safe() for that walk, so use
list_for_each_entry() instead and make the code slightly more
straightforward.Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Acked-by: Yasuaki Ishimatsu -
Clean up some inconsistent use of whitespace in acpi_bind_one() and
acpi_unbind_one().Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Acked-by: Yasuaki Ishimatsu -
Put the creation of symlinks in acpi_bind_one() under the
physical_node_lock mutex of the given ACPI device object, because
that is part of the binding operation logically (those links are
already removed under that mutex too).Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Acked-by: Yasuaki Ishimatsu -
Move some duplicated code from acpi_bind_one() and acpi_unbind_one()
into a separate function and make that function use snprintf()
instead of sprintf() for extra safety.Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Acked-by: Yasuaki Ishimatsu -
Modify acpi_bind_one() so that it doesn't fail if the device
represented by its first argument has already been bound to the
given ACPI handle (second argument), because that is not a good
enough reason for returning an error code.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Lan Tianyu
Acked-by: Toshi Kani -
In theory, under a given ACPI namespace node there should be only
one child device object with _ADR whose value matches a given bus
address exactly. In practice, however, there are systems in which
multiple child device objects under a given parent have _ADR matching
exactly the same address. In those cases we use _STA to determine
which of the multiple matching devices is enabled, since some systems
are known to indicate which ACPI device object to associate with the
given physical (usually PCI) device this way.Unfortunately, as it turns out, there are systems in which many
device objects under the same parent have _ADR matching exactly the
same bus address and none of them has _STA, in which case they all
should be regarded as enabled according to the spec. Still, if
those device objects are supposed to represent bridges (e.g. this
is the case for device objects corresponding to PCIe ports), we can
try harder and skip the ones that have no child device objects in the
ACPI namespace. With luck, we can avoid using device objects that we
are not expected to use this way.Although this only works for bridges whose children also have ACPI
namespace representation, it is sufficient to address graphics
adapter detection issues on some systems, so rework the code finding
a matching device ACPI handle for a given bus address to implement
this idea.Introduce a new function, acpi_find_child(), taking three arguments:
the ACPI handle of the device's parent, a bus address suitable for
the device's bus type and a bool indicating if the device is a
bridge and make it work as outlined above. Reimplement the function
currently used for this purpose, acpi_get_child(), as a call to
acpi_find_child() with the last argument set to 'false' and make
the PCI subsystem use acpi_find_child() with the bridge information
passed as the last argument to it. [Lan Tianyu notices that it is
not sufficient to use pci_is_bridge() for that, because the device's
subordinate pointer hasn't been set yet at this point, so use
hdr_type instead.]This change fixes a regression introduced inadvertently by commit
33f767d (ACPI: Rework acpi_get_child() to be more efficient) which
overlooked the fact that for acpi_walk_namespace() "post-order" means
"after all children have been visited" rather than "on the way back",
so for device objects without children and for namespace walks of
depth 1, as in the acpi_get_child() case, the "post-order" callbacks
ordering is actually the same as the ordering of "pre-order" ones.
Since that commit changed the namespace walk in acpi_get_child() to
terminate after finding the first matching object instead of going
through all of them and returning the last one, it effectively
changed the result returned by that function in some rare cases and
that led to problems (the switch from a "pre-order" to a "post-order"
callback was supposed to prevent that from happening, but it was
ineffective).As it turns out, the systems where the change made by commit
33f767d actually matters are those where there are multiple ACPI
device objects representing the same PCIe port (which effectively
is a bridge). Moreover, only one of them, and the one we are
expected to use, has child device objects in the ACPI namespace,
so the regression can be addressed as described above.References: https://bugzilla.kernel.org/show_bug.cgi?id=60561
Reported-by: Peter Wu
Tested-by: Vladimir Lalov
Signed-off-by: Rafael J. Wysocki
Acked-by: Bjorn Helgaas
Cc: 3.9+ # 3.9+
06 Aug, 2013
1 commit
-
The physical_node_id_bitmap in struct acpi_device is only used for
looking up the first currently unused dependent phyiscal node ID
by acpi_bind_one(). It is not really necessary, however, because
acpi_bind_one() walks the entire physical_node_list of the given
device object for sanity checking anyway and if that list is always
sorted by node_id, it is straightforward to find the first gap
between the currently used node IDs and use that number as the ID
of the new list node.This also removes the artificial limit of the maximum number of
dependent physical devices per ACPI device object, which now depends
only on the capacity of unsigend int. As a result, it fixes a
regression introduced by commit e2ff394 (ACPI / memhotplug: Bind
removable memory blocks to ACPI device nodes) that caused
acpi_memory_enable_device() to fail when the number of 128 MB blocks
within one removable memory module was greater than 32.Reported-and-tested-by: Yasuaki Ishimatsu
Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Reviewed-by: Yasuaki Ishimatsu
28 Jun, 2013
1 commit
-
* acpi-assorted:
ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan
ACPI: Add CMOS RTC Operation Region handler support
ACPI: Remove unused flags in acpi_device_flags
ACPI: Remove useless initializers
ACPI / battery: Make sure all spaces are in correct places
ACPI: add _STA evaluation at do_acpi_find_child()
ACPI / EC: access user space with get_user()/put_user()
20 Jun, 2013
1 commit
-
Once do_acpi_find_child() has found the first matching handle, it
makes the acpi_get_child() loop stop and return that handle. On some
platforms, though, there are multiple devices with the same value of
"_ADR" in the same namespace scope, and if one of them is enabled,
the others will be disabled. For example:Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV0
Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV1
Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV2If DEV0 and DEV1 are disabled and DEV2 is enabled, the handle of DEV2
should be returned, but actually the function always returns the
handle of DEV0.To address that issue, make do_acpi_find_child() evaluate _STA to
check the device status. If a matching device object exists, but is
disabled, acpi_get_child() will continue to walk the namespace in the
hope of finding an enabled one. If one is found, its handle will be
returned, but otherwise the function will return the handle of the
disabled object found before (in case it is enabled going forward).[rjw: Changelog]
Signed-off-by: Jeff Wu
Signed-off-by: Rafael J. Wysocki
