#
f64e4275 |
|
10-Jan-2023 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: Fix selecting wrong ACPI fwnode for the iGPU on some Dell laptops 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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: 6.1+ <stable@vger.kernel.org> # 6.1+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2f6fe93f |
|
13-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Introduce acpi_find_child_by_adr() Rearrange the ACPI device lookup code used internally by acpi_find_child_device() so it can avoid extra checks after finding one object with a matching _ADR and use it for defining acpi_find_child_by_adr() that will allow the callers to find a given ACPI device's child matching a given bus address without doing any other checks in check_one_child(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
f5122be8 |
|
13-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Introduce acpi_dev_has_children() Define acpi_dev_has_children() as a wrapper around acpi_dev_for_each_child() and use it to check if the given ACPI device has any children instead of checking the children list head in struct acpi_device. This will help to eliminate the children list head from struct acpi_device as it is redundant and it is used in questionable ways in some places (in particular, locking is needed for walking the list pointed to it safely, but it is often missing). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
d21b5700 |
|
13-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Use acpi_dev_for_each_child() Instead of walking the list of children of an ACPI device directly, use acpi_dev_for_each_child() to carry out an action for all of the given ACPI device's children. This will help to eliminate the children list head from struct acpi_device as it is redundant and it is used in questionable ways in some places (in particular, locking is needed for walking the list pointed to it safely, but it is often missing). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
b7fbf4ce |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Rearrange find_child_checks() Notice that it is not necessary to evaluate _STA in find_child_checks() if the device is expected to have children, but there are none, so move the children check to the front of the function. Also notice that FIND_CHILD_MIN_SCORE can be returned right away if _STA is missing, so make the function do so. Finally, replace the ternary operator in the return statement argument with an if () and a standalone return which is somewhat easier to follow. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3b2b49e6 |
|
17-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "ACPI: scan: Release PM resources blocked by unused objects" Revert commit c10383e8ddf4 ("ACPI: scan: Release PM resources blocked by unused objects"), because it causes boot issues to appear on some platforms. Reported-by: Kyle D. Pelton <kyle.d.pelton@intel.com> Reported-by: Saranya Gopal <saranya.gopal@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
61a3c78d |
|
27-Oct-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Use acpi_device_adr() in acpi_find_child_device() Instead of evaluating _ADR in acpi_find_child_device(), use the observation that it has already been evaluated and the value returned by it has been stored in the pnp.type.bus_address field of the ACPI device object at hand. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c10383e8 |
|
09-Oct-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: scan: Release PM resources blocked by unused objects On some systems the ACPI namespace contains device objects that are not used in certain configurations of the system. If they start off in the D0 power state configuration, they will stay in it until the system reboots, because of the lack of any mechanism possibly causing their configuration to change. If that happens, they may prevent some power resources from being turned off or generally they may prevent the platform from getting into the deepest low-power states thus causing some energy to be wasted. Address this issue by changing the configuration of unused ACPI device objects to the D3cold power state one after carrying out the ACPI-based enumeration of devices. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214091 Link: https://lore.kernel.org/linux-acpi/20211007205126.11769-1-mario.limonciello@amd.com/ Reported-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mario Limonciello <mario.limonciello@amd.com>
|
#
2ef52366 |
|
18-Sep-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Look for ACPI bus type only if ACPI companion is not known Notice that it is not necessary to look for the "ACPI bus type" of the device in acpi_device_notify() if the device's ACPI companion is set upfront, so modify the code to do that lookup only if it is necessary to find the ACPI companion. Also notice that if the device's ACPI companion is not set upfront in acpi_device_notify(), the device cannot be either a PCI one or a platform one, so check for these bus types only if the device's ACPI companion is set. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com>
|
#
c4d19838 |
|
18-Sep-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Drop cleanup callback from struct acpi_bus_type Since PCI was the only user of the ->cleanup callback in struct acpi_bus_type and it is not using struct acpi_bus_type any more, drop that callback from there and update acpi_device_notify_remove() accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com>
|
#
47954481 |
|
18-Sep-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: ACPI: Drop acpi_pci_bus The acpi_pci_bus structure was used primarily for running acpi_pci_find_companion() during PCI device objects registration, but after commit 375553a93201 ("PCI: Setup ACPI fwnode early and at the same time with OF") that function is called by pci_setup_device() via pci_set_acpi_fwnode(), which happens before calling pci_device_add() on the new PCI device object, so its ACPI companion has been set already when acpi_device_notify() runs and it will never call ->find_companion() from acpi_pci_bus. For this reason, modify acpi_device_notify() and acpi_device_notify_remove() to call pci_acpi_setup() and pci_acpi_cleanup(), respectively, directly on PCI device objects and drop acpi_pci_bus altogether. While at it, notice that pci_acpi_setup() and pci_acpi_cleanup() can obtain the ACPI companion pointer, which is guaranteed to not be NULL, from their callers and modify them to work that way so as to reduce the number of redundant checks somewhat. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com>
|
#
d0b8e398 |
|
12-Jul-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Eliminate acpi_platform_notify() Get rid of acpi_platform_notify() which is redundant and make device_platform_notify() in the driver core call acpi_device_notify() and acpi_device_notify_remove() directly. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
7d625e5b |
|
12-Jul-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Change return type of two functions to void Since the return values of acpi_device_notify() and acpi_device_notify_remove() are discarded by their only caller, change their return type to void. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
42878a9f |
|
12-Jul-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: glue: Rearrange acpi_device_notify() Make the code flow in acpi_device_notify() more straightforward and make it use dev_dbg() and acpi_handle_debug() for printing debug messages. The only expected functional impact of this change is the content of the debug messages printed by acpi_device_notify(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
e2935abb |
|
02-Jun-2021 |
Hanjun Guo <guohanjun@huawei.com> |
ACPI: glue: Clean up the printing messages Remove the in house ACPI_GLUE_DEBUG and its related debug message printing, using pr_debug() instead. While at it, replace printk() with pr_* to simplify the code. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4cbaba4e |
|
12-Apr-2021 |
Andy Shevchenko <andy.shevchenko@gmail.com> |
ACPI: bus: Introduce acpi_dev_get() and reuse it in ACPI code Introduce acpi_dev_get() to have a symmetrical API with acpi_dev_put() and reuse both in ACPI code in drivers/acpi/. While at it, use acpi_bus_put_acpi_device() in one place instead of the above. Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
55716d26 |
|
01-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 428 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 <tglx@linutronix.de> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190114.292346262@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7847a145 |
|
09-Nov-2018 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
ACPI / glue: Add acpi_platform_notify() function 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 <heikki.krogerus@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
719cf71c |
|
20-Aug-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
ACPI / glue: Split dev_is_platform() out of module for wide use 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 <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
09515ef5 |
|
10-Apr-2017 |
Sricharan R <sricharan@codeaurora.org> |
of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices 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_configure Similarly 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 <m.szyprowski@samsung.com> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci part) Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sricharan R <sricharan@codeaurora.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
fdad4e7a |
|
31-Mar-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / scan: Prefer devices without _HID for _ADR matching 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 <mike@mikewilson.me.uk> Tested-by: Hans de Goede <hdegoede@redhat.com> Cc: 4.10+ <stable@vger.kernel.org> # 4.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d4f54a18 |
|
07-Mar-2017 |
Hanjun Guo <guohanjun@huawei.com> |
ACPI: platform: setup MSI domain for ACPI based platform device 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 <rafael@kernel.org> [for glue.c] Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> [lorenzo.pieralisi@arm.com: rewrote commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Ming Lei <ming.lei@canonical.com> Tested-by: Wei Xu <xuwei5@hisilicon.com> Tested-by: Sinan Kaya <okaya@codeaurora.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com>
|
#
c2a6bbaf |
|
29-Dec-2016 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / scan: Prefer devices without _HID/_CID for _ADR matching 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 <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com>
|
#
709f94ff |
|
16-Dec-2016 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
ACPI: Drop misplaced acpi_dma_deconfigure() call from acpi_bind_one() 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 <lorenzo.pieralisi@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d760a1ba |
|
21-Nov-2016 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
ACPI: Implement acpi_dma_configure 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 <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci] Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Tomasz Nowicki <tn@semihalf.com> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Tomasz Nowicki <tn@semihalf.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
1831eff8 |
|
28-Oct-2015 |
Suthikulpanit, Suravee <Suravee.Suthikulpanit@amd.com> |
device property: ACPI: Make use of the new DMA Attribute APIs 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 <Suravee.Suthikulpanit@amd.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c33cab60 |
|
10-Sep-2015 |
Rami Rosen <ramirose@gmail.com> |
ACPI: change init_acpi_device_notify() to return void 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 <ramirose@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d0562674 |
|
10-Jun-2015 |
Suthikulpanit, Suravee <Suravee.Suthikulpanit@amd.com> |
ACPI / scan: Parse _CCA and setup device coherency 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 <msalter@redhat.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ca5b74d2 |
|
16-Mar-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Introduce has_acpi_companion() 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 <rafael.j.wysocki@intel.com>
|
#
9cb32acf |
|
10-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / scan: Add bind/unbind callbacks to struct acpi_scan_handler 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 <rafael.j.wysocki@intel.com>
|
#
bfecc2b3 |
|
29-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / bind: Move acpi_get_child() to drivers/ide/ide-acpi.c 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 <rafael.j.wysocki@intel.com>
|
#
24dee1fc |
|
29-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / bind: Pass struct acpi_device pointer to acpi_bind_one() 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 <rafael.j.wysocki@intel.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> # for USB/ACPI
|
#
e3f02c52 |
|
29-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / bind: Rework struct acpi_bus_type 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 <rafael.j.wysocki@intel.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> # for USB/ACPI
|
#
9c5ad36d |
|
28-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / bind: Redefine acpi_preset_companion() 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 <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Tested-by: Aaron Lu <aaron.lu@intel.com> # for ATA binding
|
#
11dcc75d |
|
28-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / bind: Redefine acpi_get_child() 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 <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Tested-by: Aaron Lu <aaron.lu@intel.com> # for ATA binding
|
#
5ce79d20 |
|
28-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / ACPI: Use acpi_find_child_device() for child devices lookup 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 <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
|
#
d9fef0c4 |
|
28-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / bind: Simplify child device lookups 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 <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
|
#
a104b4d4 |
|
14-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / bind: Use (put|get)_device() on ACPI device objects too 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 <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Lan Tianyu <tianyu.lan@intel.com>
|
#
7b199811 |
|
11-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node 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 <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
|
#
11b88ee2 |
|
09-Sep-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / bind: Prefer device objects with _STA to those without it 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 <lekensteyn@gmail.com> Tested-by: Felix Lisczyk <felix.lisczyk@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
464c1147 |
|
08-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Print diagnostic messages if device links cannot be created 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 <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
|
#
3342c753 |
|
08-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Drop unnecessary label from acpi_bind_one() 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 <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
|
#
38e88839 |
|
06-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Clean up error code path in acpi_unbind_one() 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 <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
|
#
3e332783 |
|
06-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Use list_for_each_entry() in acpi_unbind_one() 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 <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
|
#
f501b6ec |
|
06-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: acpi_bind_one()/acpi_unbind_one() whitespace cleanups Clean up some inconsistent use of whitespace in acpi_bind_one() and acpi_unbind_one(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
|
#
40055206 |
|
06-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Create symlinks in acpi_bind_one() under physical_node_lock 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 <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
|
#
bdbdbf91 |
|
06-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Reduce acpi_bind_one()/acpi_unbind_one() code duplication 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 <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
|
#
3fe444ad |
|
06-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Do not fail acpi_bind_one() if device is already bound correctly 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 <rafael.j.wysocki@intel.com> Reviewed-by: Lan Tianyu <tianyu.lan@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
|
#
60f75b8e |
|
07-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Try harder to resolve _ADR collisions for bridges 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 <lekensteyn@gmail.com> Tested-by: Vladimir Lalov <mail@vlalov.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
|
#
007ccfcf |
|
06-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Drop physical_node_id_bitmap from struct acpi_device 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 <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
|
#
c7d9ca90 |
|
29-May-2013 |
Jeff Wu <zlinuxkernel@gmail.com> |
ACPI: add _STA evaluation at do_acpi_find_child() 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.DEV2 If 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 <zlinuxkernel@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ac212b69 |
|
02-May-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / processor: Use common hotplug infrastructure Split the ACPI processor driver into two parts, one that is non-modular, resides in the ACPI core and handles the enumeration and hotplug of processors and one that implements the rest of the existing processor driver functionality. The non-modular part uses an ACPI scan handler object to enumerate processors on the basis of information provided by the ACPI namespace and to hook up with the common ACPI hotplug infrastructure. It also populates the ACPI handle of each processor device having a corresponding object in the ACPI namespace, which allows the driver proper to bind to those devices, and makes the driver bind to them if it is readily available (i.e. loaded) when the scan handler's .attach() routine is running. There are a few reasons to make this change. First, switching the ACPI processor driver to using the common ACPI hotplug infrastructure reduces code duplication and size considerably, even though a new file is created along with a header comment etc. Second, since the common hotplug code attempts to offline devices before starting the (non-reversible) removal procedure, it will abort (and possibly roll back) hot-remove operations involving processors if cpu_down() returns an error code for one of them instead of continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove is unset). That is a more desirable behavior than what the current code does. Finally, the separation of the scan/hotplug part from the driver proper makes it possible to simplify the driver's .remove() routine, because it doesn't need to worry about the possible cleanup related to processor removal any more (the scan/hotplug part is responsible for that now) and can handle device removal and driver removal symmetricaly (i.e. as appropriate). Some user-visible changes in sysfs are made (for example, the 'sysdev' link from the ACPI device node to the processor device's directory is gone and a 'physical_node' link is present instead and a corresponding 'firmware_node' is present in the processor device's directory, the processor driver is now visible under /sys/bus/cpu/drivers/ and bound to the processor device), but that shouldn't affect the functionality that users care about (frequency scaling, C-states and thermal management). Tested on my venerable Toshiba Portege R500. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Toshi Kani <toshi.kani@hp.com>
|
#
92414481 |
|
03-Mar-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / glue: Drop .find_bridge() callback from struct acpi_bus_type After PCI and USB have stopped using the .find_bridge() callback in struct acpi_bus_type, the only remaining user of it is SATA, but SATA only pretends to be a user, because it points that callback to a stub always returning -ENODEV. For this reason, drop the SATA's dummy .find_bridge() callback and remove .find_bridge(), which is not used any more, from struct acpi_bus_type entirely. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Jeff Garzik <jgarzik@pobox.com>
|
#
53540098 |
|
03-Mar-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / glue: Add .match() callback to struct acpi_bus_type USB uses the .find_bridge() callback from struct acpi_bus_type incorrectly, because as a result of the way it is used by USB every device in the system that doesn't have a bus type or parent is passed to usb_acpi_find_device() for inspection. What USB actually needs, though, is to call usb_acpi_find_device() for USB ports that don't have a bus type defined, but have usb_port_device_type as their device type, as well as for USB devices. To fix that replace the struct bus_type pointer in struct acpi_bus_type used for matching devices to specific subsystems with a .match() callback to be used for this purpose and update the users of struct acpi_bus_type, including USB, accordingly. Define the .match() callback routine for USB, usb_acpi_bus_match(), in such a way that it will cover both USB devices and USB ports and remove the now redundant .find_bridge() callback pointer from usb_acpi_bus. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Jeff Garzik <jgarzik@pobox.com>
|
#
33f767d7 |
|
10-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Rework acpi_get_child() to be more efficient Observe that acpi_get_child() doesn't need to use the helper struct acpi_find_child structure and change it to work without it. Also, using acpi_get_object_info() to get the output of _ADR for the given device is overkill, because that function does much more than just evaluating _ADR (let alone the additional memory allocation done by it). Moreover, acpi_get_child() doesn't need to loop any more once it has found a matching handle, so make it stop in that case. To prevent the results from changing, make it use do_acpi_find_child() as a post-order callback. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a412a11d |
|
12-Jan-2013 |
Yinghai Lu <yinghai@kernel.org> |
ACPI / glue: Fix build with ACPI_GLUE_DEBUG set If ACPI_GLUE_DEBUG is different from 0 (setting this requires a manual change of glue.c), build breaks because of a leftover reference to dev->acpi_handle in acpi_platform_notify(). Fix this by using ACPI_HANDLE(dev) instead as appropriate. [rjw: Subject and changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
23415eb5 |
|
17-Dec-2012 |
Joe Perches <joe@perches.com> |
ACPI / glue: Update DBG macro to include KERN_DEBUG Currently these DBG statements are emitted at KERN_DEFAULT. Change the macro to emit at KERN_DEBUG. This can help avoid unexpected message interleaving. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
11909ca1 |
|
22-Dec-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Add .setup() and .cleanup() callbacks to struct acpi_bus_type Add two new callbacks,.setup() and .cleanup(), struct acpi_bus_type and modify acpi_platform_notify() to call .setup() after executing acpi_bind_one() successfully and acpi_platform_notify_remove() to call .cleanup() before running acpi_unbind_one(). This will allow the users of struct acpi_bus_type, PCI in particular, to specify operations to be executed right after the given device has been associated with a companion struct acpi_device and right before it's going to be detached from that companion, respectively. The main motivation is to be able to get rid of acpi_pci_bind() and acpi_pci_unbind(), which are horrible horrible stuff. [In short, there are three problems with them: The way they populate the .bind() and .unbind() callbacks of ACPI devices is rather less than straightforward, they require special hotplug-specific paths to be present in the ACPI namespace scanning code and by the time acpi_pci_unbind() is called the PCI device object in question may not exist any more.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
|
#
95f8a082 |
|
20-Nov-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / driver core: Introduce struct acpi_dev_node and related macros To avoid adding an ACPI handle pointer to struct device on architectures that don't use ACPI, or generally when CONFIG_ACPI is not set, in which cases that pointer is useless, define struct acpi_dev_node that will contain the handle pointer if CONFIG_ACPI is set and will be empty otherwise and use it to represent the ACPI device node field in struct device. In addition to that define macros for reading and setting the ACPI handle of a device that don't generate code when CONFIG_ACPI is unset. Modify the ACPI subsystem to use those macros instead of referring to the given device's ACPI handle directly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f3fd0c8a |
|
20-Nov-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Allow ACPI handles of devices to be initialized in advance Currently, the ACPI handles of devices are initialized from within device_add(), by acpi_bind_one() called from acpi_platform_notify() which first uses the .find_device() routine provided by the device's bus type to find the matching device node in the ACPI namespace. This is a source of some computational overhead and, moreover, the correctness of the result depends on the implementation of .find_device() which is known to fail occasionally for some bus types (e.g. PCI). In some cases, however, the corresponding ACPI device node is known already before calling device_add() for the given struct device object and the whole .find_device() dance in acpi_platform_notify() is then simply unnecessary. For this reason, make it possible to initialize the ACPI handles of devices before calling device_add() for them. Modify acpi_platform_notify() to call acpi_bind_one() in advance to check the device's existing ACPI handle and skip the .find_device() search if that is successful. Change acpi_bind_one() accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
06f64c8f |
|
31-Oct-2012 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
driver core / ACPI: Move ACPI support to core device and driver types With ACPI 5 we are starting to see devices that don't natively support discovery but can be enumerated with the help of the ACPI namespace. Typically, these devices can be represented in the Linux device driver model as platform devices or some serial bus devices, like SPI or I2C devices. Since we want to re-use existing drivers for those devices, we need a way for drivers to specify the ACPI IDs of supported devices, so that they can be matched against device nodes in the ACPI namespace. To this end, it is sufficient to add a pointer to an array of supported ACPI device IDs, that can be provided by the driver, to struct device. Moreover, things like ACPI power management need to have access to the ACPI handle of each supported device, because that handle is used to invoke AML methods associated with the corresponding ACPI device node. The ACPI handles of devices are now stored in the archdata member structure of struct device whose definition depends on the architecture and includes the ACPI handle only on x86 and ia64. Since the pointer to an array of supported ACPI IDs is added to struct device_driver in an architecture-independent way, it is logical to move the ACPI handle from archdata to struct device itself at the same time. This also makes code more straightforward in some places and follows the example of Device Trees that have a poiter to struct device_node in there too. This changeset is based on Mika Westerberg's work. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: H. Peter Anvin <hpa@zytor.com> Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2978af54 |
|
22-Oct-2012 |
Jesper Juhl <jj@chaosbits.net> |
ACPI: Fix memory leak in acpi_bind_one() Memory is allocated with kzalloc() and assigned to 'physical_node'. Then 'physical_node->node_id' is initialized with a call to 'find_first_zero_bit()', if that results in a value greater than ACPI_MAX_PHYSICAL_NODE we'll end up jumping to the 'err:' label and there leave the function and let 'physical_node' go out of scope and leak the memory we allocated. This patch fixes the leak by simply freeing the unused/unneeded memory pointed to by 'physical_node' just before we jump to 'err:'. [rjw: The problem has been introduced by commit 1033f90 (ACPI: Allow ACPI binding with USB-3.0 hub), which is new in 3.7-rc.] Signed-off-by: Jesper Juhl <jj@chaosbits.net> Reviewed-by: Toshi Kani <toshi.kani@hp.com> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Acked-by: David Rientjes <rientjes@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1033f904 |
|
17-Aug-2012 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI: Allow ACPI binding with USB-3.0 hub A USB port's position and connectability can't be identified on some boards via USB hub registers. ACPI _UPC and _PLD can help to resolve this issue and so it is necessary to bind USB with ACPI. This patch is to allow ACPI binding with USB-3.0 hub. Current ACPI only can bind one struct-device to one ACPI device node. This can not work with USB-3.0 hub, because the USB-3.0 hub has two logical devices. Each works for USB-2.0 and USB-3.0 devices. In the Linux USB subsystem, those two logical hubs are treated as two seperate devices that have two struct devices. But in the ACPI DSDT, these two logical hubs share one ACPI device node. So there is a requirement to bind multi struct-devices to one ACPI device node. This patch is to resolve such problem. Following is the ACPI device nodes' description under xhci hcd. Device (XHC) Device (RHUB) Device (HSP1) Device (HSP2) Device (HSP3) Device (HSP4) Device (SSP1) Device (SSP2) Device (SSP3) Device (SSP4) Topology in the Linux device XHC USB-2.0 logical hub USB-3.0 logical hub HSP1 SSP1 HSP2 SSP2 HSP3 SSP3 HSP4 SSP4 This patch also modifies the output of /proc/acpi/wakeup. One ACPI node can be associated with multiple devices: XHC S4 *enabled pci:0000:00:14.0 RHUB S0 disabled usb:usb1 disabled usb:usb2 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
91e4d5a1 |
|
25-Jul-2012 |
Jeff Garzik <jeff@garzik.org> |
drivers/acpi/glue: revert accidental license-related 6b66d95895c bits Commit 6b66d95895c149cbc04d4fac5a2f5477c543a8ae should not have changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL. Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
|
#
6b66d958 |
|
25-Jun-2012 |
Matthew Garrett <mjg@redhat.com> |
libata: bind the Linux device tree to the ACPI device tree Associate the ACPI device tree and libata devices. This patch uses the generic ACPI glue framework to do so. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Holger Macht <holger@homac.de> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
|
#
66886d6f |
|
11-May-2012 |
Matthew Garrett <mjg@redhat.com> |
ACPI: Add stubs for (un)register_acpi_bus_type It's unreasonable to have CONFIG_ACPI for these in drivers, so add some stub functions. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
214f2c90 |
|
26-Oct-2011 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
acpi: add export.h to files using THIS_MODULE/EXPORT_SYMBOL These files were relying on module.h to come in via the path in an include/acpi header file, but we don't want to have instances of module.h being included from include/* files if it can be avoided. Have the files include export.h instead. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
#
7fa69baf |
|
06-Jan-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Drop special ACPI wakeup flags Drop special ACPI wakeup flags, wakeup.state.enabled and wakeup.flags.always_enabled, that aren't necessary any more after we've started to use standard device wakeup flags for handling ACPI wakeup devices. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
108029ff |
|
12-Jul-2010 |
Zhao Yakui <yakui.zhao@intel.com> |
ACPI: Add the check of ADR flag in course of finding ACPI handle for PCI device The _ADR object is used to provide OSPM with the address of one device on its parent bus. In course of finding ACPI handle for the corresponding PCI device, we will firstly evaluate the _ADR object and then compare the two addresses to see whether it is the target ACPI device. But for one PCI device(0000:00:00.0) under the PCI root bridge, the corresponding address will be constructed as zero.In such case maybe the ACPI device without _ADR object will be misdetected and then be used to create the relationship between PCI device and ACPI device. https://bugzilla.kernel.org/show_bug.cgi?id=16422 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
439913ff |
|
27-Jan-2010 |
Lin Ming <ming.m.lin@intel.com> |
ACPI: replace acpi_integer by u64 acpi_integer is now obsolete and removed from the ACPICA code base, replaced by u64. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2263576c |
|
12-Nov-2009 |
Lin Ming <ming.m.lin@intel.com> |
ACPICA: Add post-order callback to acpi_walk_namespace The existing interface only has a pre-order callback. This change adds an additional parameter for a post-order callback which will be more useful for bus scans. ACPICA BZ 779. Also update the external calls to acpi_walk_namespace. http://www.acpica.org/bugzilla/show_bug.cgi?id=779 Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a192a958 |
|
28-Jul-2009 |
Len Brown <len.brown@intel.com> |
ACPI: Move definition of PREFIX from acpi_bus.h to internal..h Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #undef PREFIX to define their own. Add GPL commment to internal.h while we are there. This does not change any actual console output, asside from a whitespace fix. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
8e4319c4 |
|
28-Jun-2009 |
Bob Moore <robert.moore@intel.com> |
ACPICA: Fix several acpi_attach_data problems Handler was never invoked. Now invoked if/when host node is deleted. Data object was not automatically deleted when host node was deleted. Interface to handler had an unused parameter, removed it. ACPICA BZ 778. http://acpica.org/bugzilla/show_bug.cgi?id=778 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
15b8dd53 |
|
28-Jun-2009 |
Bob Moore <robert.moore@intel.com> |
ACPICA: Major update for acpi_get_object_info external interface Completed a major update for the acpi_get_object_info external interface. Changes include: - Support for variable, unlimited length HID, UID, and CID strings - Support Processor objects the same as Devices (HID,UID,CID,ADR,STA, etc.) - Call the _SxW power methods on behalf of a device object - Determine if a device is a PCI root bridge - Change the ACPI_BUFFER parameter to ACPI_DEVICE_INFO. These changes will require an update to all callers of this interface. See the ACPICA Programmer Reference for details. Also, update all invocations of acpi_get_object_info interface Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7fe2a6c2 |
|
10-Jun-2009 |
Alexander Chiang <achiang@hp.com> |
ACPI: kill acpi_get_physical_pci_device() acpi_get_pci_dev() is (hopefully) better, and all callers have been converted, so let's get rid of this duplicated functionality. Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: Alex Chiang <achiang@hp.com> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
0e46517d |
|
24-Mar-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: call init_acpi_device_notify() explicitly rather than as initcall This patch makes acpi_init() call init_acpi_device_notify() directly. Previously, init_acpi_device_notify() was an arch_initcall (sequence 3), so it was called before acpi_init() (a subsys_initcall at sequence 4). init_acpi_device_notify() sets the platform_notify and platform_notify_remove function pointers. These pointers are not used until acpi_init() enumerates ACPI devices in this path: acpi_init() acpi_scan_init() acpi_bus_scan() acpi_add_single_object() acpi_device_register() device_add() <use platform_notify> So it is sufficient to have acpi_init() call init_acpi_device_notify() directly before it enumerates devices. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
db1461ad |
|
25-Jan-2009 |
Kay Sievers <kay.sievers@vrfy.org> |
ACPI: struct device - replace bus_id with dev_name(), dev_set_name() Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
22c13f9d |
|
01-Aug-2008 |
Thomas Renninger <trenn@suse.de> |
ACPI: video: Ignore devices that aren't present in hardware This is a reimplemention of commit 0119509c4fbc9adcef1472817fda295334612976 from Matthew Garrett <mjg59@srcf.ucam.org> This patch got removed because of a regression: ThinkPads with a Intel graphics card and an Integrated Graphics Device BIOS implementation stopped working. In fact, they only worked because the ACPI device of the discrete, the wrong one, got used (via int10). So ACPI functions were poking on the wrong hardware used which is a sever bug. The next patch provides support for above ThinkPads to be able to switch brightness via the legacy thinkpad_acpi driver and automatically detect when to use it. Original commit message from Matthew Garrett: Vendors often ship machines with a choice of integrated or discrete graphics, and use the same DSDT for both. As a result, the ACPI video module will locate devices that may not exist on this specific platform. Attempt to determine whether the device exists or not, and abort the device creation if it doesn't. http://bugzilla.kernel.org/show_bug.cgi?id=9614 Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a474aaed |
|
14-Oct-2008 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
rtc-cmos: move wake setup from ACPI glue into RTC driver Move rtc_wake_setup() from drivers/acpi/glue.c into the RTC driver in drivers/rtc/rtc-cmos.c. This removes the ordering constraint between the module_init(acpi_rtc_init) and the cmos_do_probe() code that depends on it. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
1efd325f |
|
12-Oct-2008 |
Linus Torvalds <torvalds@linux-foundation.org> |
Fix RTC wakealarm sysfs interface breakage. Commit ed458df4d2470adc02762a87a9ad665d0b1a2bd4 ("PnP: move pnpacpi/pnpbios_init to after PCI init") moved the PnP RTC discovery later, and now the ACPI RTC glue code doesn't find it any more, breaking the RTC wakealarm sysfs interfaces, as reported by Rafael. This really is fairly messy, and we have several annoying ordering constraints here - the PnP code that sets up the RTC resources wants to run after the PCI resources have to be registered, which in turn needs to run after ACPI has at least enumerated the root PCI buses etc. Our initcall ordering is not fine-grained enough to make this all painless. So this moves the ACPI RTC glue ("acpi_rtc_init()") down to a regular module call, which fixes the problem Rafael has. The reason this isn't wonderful is that we really should do acpi_rtc_init before we do the rtc_cmos init, and now those two are in the same module_init() section. Which happens to work, but only because drivers/rtc is linked after drivers/acpi. In other words, we still have a very subtle ordering issue here. Grr. Reported-and-tested-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: David Brownell <david-b@pacbell.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
76acae04 |
|
03-Oct-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI: Make /proc/acpi/wakeup interface handle PCI devices (again) Make the ACPI /proc/acpi/wakeup interface set the appropriate wake-up bits of physical devices corresponding to the ACPI devices and make those bits be set initially for devices that are enabled to wake up by default. This is needed to restore the 2.6.26 and earlier behavior for the PCI devices that were previously handled correctly with the help of the /proc/acpi/wakeup interface. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
fc3a8828 |
|
01-May-2008 |
Greg Kroah-Hartman <gregkh@suse.de> |
driver core: fix a lot of printk usages of bus_id We have the dev_printk() variants for this kind of thing, use them instead of directly trying to access the bus_id field of struct device. This is done in order to remove bus_id entirely. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
5e248ac9 |
|
17-Jul-2008 |
Thomas Gleixner <tglx@linutronix.de> |
APCI: revert another duplicated patch commit d1857056904d5f313f11184fcfa624652ff9620a ("ACPI: don't walk tables if ACPI was disabled") is another superfluous duplicate commit caused by git -> quilt -> git conversion. Revert it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
725c3a2d |
|
18-Jul-2008 |
Andi Kleen <ak@linux.intel.com> |
Revert "ACPI: don't walk tables if ACPI was disabled" This reverts commit d1857056904d5f313f11184fcfa624652ff9620a. Double commit, noticed by Thomas Gleixner. Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
#
d1857056 |
|
20-Jun-2008 |
Vegard Nossum <vegard.nossum@gmail.com> |
ACPI: don't walk tables if ACPI was disabled Ingo Molnar wrote: > -tip auto-testing started triggering this spinlock corruption message > yesterday: > > [ 3.976213] calling acpi_rtc_init+0x0/0xd3 > [ 3.980213] ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread F7C50000 could not acquire Mutex [3] [20080321] > [ 3.992213] BUG: spinlock bad magic on CPU#0, swapper/1 > [ 3.992213] lock: c2508dc4, .magic: 00000000, .owner: swapper/1, .owner_cpu: 0 This is apparently because some parts of ACPI, including mutexes, are not initialized when acpi=off is passed to the kernel. Reported-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
#
eb9d0fe4 |
|
06-Jul-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI ACPI: Rework PCI handling of wake-up * Introduce function acpi_pm_device_sleep_wake() for enabling and disabling the system wake-up capability of devices that are power manageable by ACPI. * Introduce function acpi_bus_can_wakeup() allowing other (dependent) subsystems to check if ACPI is able to enable the system wake-up capability of given device. * Introduce callback .sleep_wake() in struct pci_platform_pm_ops and for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake(). * Introduce callback .can_wakeup() in struct pci_platform_pm_ops and for the ACPI 'driver' make it use acpi_bus_can_wakeup(). * Move the PME# handlig code out of pci_enable_wake() and split it into two functions, pci_pme_capable() and pci_pme_active(), allowing the caller to check if given device is capable of generating PME# from given power state and to enable/disable the device's PME# functionality, respectively. * Modify pci_enable_wake() to use the new ACPI callbacks and the new PME#-related functions. * Drop the generic .platform_enable_wakeup() callback that is not used any more. * Introduce device_set_wakeup_capable() that will set the power.can_wakeup flag of given device. * Rework PCI device PM initialization so that, if given device is capable of generating wake-up events, either natively through the PME# mechanism, or with the help of the platform, its power.can_wakeup flag is set and its power.should_wakeup flag is unset as appropriate. * Make ACPI set the power.can_wakeup flag for devices found to be wake-up capable by it. * Make the ACPI wake-up code enable/disable GPEs for devices that have the wakeup.flags.prepared flag set (which means that their wake-up power has been enabled). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
4389ed2f |
|
20-Jun-2008 |
Vegard Nossum <vegard.nossum@gmail.com> |
ACPI: don't walk tables if ACPI was disabled Ingo Molnar wrote: > -tip auto-testing started triggering this spinlock corruption message > yesterday: > > [ 3.976213] calling acpi_rtc_init+0x0/0xd3 > [ 3.980213] ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread F7C50000 could not acquire Mutex [3] [20080321] > [ 3.992213] BUG: spinlock bad magic on CPU#0, swapper/1 > [ 3.992213] lock: c2508dc4, .magic: 00000000, .owner: swapper/1, .owner_cpu: 0 This is apparently because some parts of ACPI, including mutexes, are not initialized when acpi=off is passed to the kernel. Reported-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e1094bfa |
|
13-May-2008 |
Zhao Yakui <yakui.zhao@intel.com> |
ACPI: Disable Fixed_RTC event when installing RTC handler The Fixed_RTC event should be disabled when installing RTC handler. Only when RTC alarm is set will it be enabled again. If it is not disabled, maybe some machines will be powered on automatically after the system is shutdown even when the RTC alarm is not set. http://bugzilla.kernel.org/show_bug.cgi?id=10010 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1071695f |
|
22-Feb-2008 |
David Brownell <david-b@pacbell.net> |
ACPI: crosslink ACPI and "real" device nodes Add cross-links between ACPI device and "real" devices in sysfs, exposing otherwise-hidden interrelationships between the various device nodes for ACPI stuff. As a representative example, one hardware device is exposed as two logical devices (PNP and ACPI): .../pnp0/00:06/ .../LNXSYSTM:00/device:00/PNP0A03:00/device:15/PNP0B00:00/ The PNP device gets a "firmware_node" link pointing to the ACPI device, and is what a Linux device driver binds to. The ACPI device has instead a "physical_node" link pointing back to the PNP device. Other firmware frameworks, like OpenFirmware, could do the same thing to couple their firmware tables to the rest of the system. (Based on a patch from Zhang Rui. This version is modified to not depend on the patch makig ACPI initialize driver model wakeup flags.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e5685b9d |
|
24-Oct-2007 |
Adrian Bunk <bunk@kernel.org> |
ACPI: misc cleanups This patch contains the following possible cleanups: - make the following needlessly global code static: - drivers/acpi/bay.c:dev_attr_eject - drivers/acpi/bay.c:dev_attr_present - drivers/acpi/dock.c:dev_attr_docked - drivers/acpi/dock.c:dev_attr_flags - drivers/acpi/dock.c:dev_attr_uid - drivers/acpi/dock.c:dev_attr_undock - drivers/acpi/pci_bind.c:acpi_pci_unbind() - drivers/acpi/pci_link.c:acpi_link_lock - drivers/acpi/sbs.c:acpi_sbs_callback() - drivers/acpi/sbshc.c:acpi_smbus_transaction() - drivers/acpi/sleep/main.c:acpi_sleep_prepare() - #if 0 the following unused global functions: - drivers/acpi/numa.c:acpi_unmap_pxm_to_node() - remove the following unused EXPORT_SYMBOL's: - acpi_register_gsi - acpi_unregister_gsi - acpi_strict - acpi_bus_receive_event - register_acpi_bus_type - unregister_acpi_bus_type - acpi_os_printf - acpi_os_sleep - acpi_os_stall - acpi_os_read_pci_configuration - acpi_os_create_semaphore - acpi_os_delete_semaphore - acpi_os_wait_semaphore - acpi_os_signal_semaphore - acpi_os_signal - acpi_pci_irq_enable - acpi_get_pxm Signed-off-by: Adrian Bunk <bunk@kernel.org> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4ebf83c8 |
|
09-Jul-2007 |
Dave Jones <davej@redhat.com> |
ACPI: fix empty macros found by -Wextra ACPI has a ton of macros which make a bunch of empty if's when configured in non-debug mode. [lenb: The code it complaines about is functionally correct, so this patch is just to make -Wextra happier] #define DBG() if(...) DBG(); next_c_statement which turns into if(...) ; next_c_statement Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
19bfe37c |
|
08-May-2007 |
David Brownell <david-b@pacbell.net> |
workaround rtc-related acpi table bugs This works around a bug seen in some RTC-related ACPI table entries, and tweaks related diagnostics to follow the ACPI convention. The bug prevents misleading boot-time messages: platforms affected by this bug wrongly report they can support alarms up to one year in the future, when in fact the longest alarm is just 24 hours. That will surprise anyone trying to use those extended alarms. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
f5f72b46 |
|
08-May-2007 |
David Brownell <david-b@pacbell.net> |
ACPI wakeup hooks for rtc-cmos Remove /proc/acpi/alarm file when the rtc-cmos "wakealarm" file is available. Instead, provide hooks that rtc-cmos will use. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8d4956c2 |
|
15-Feb-2007 |
Len Brown <len.brown@intel.com> |
ACPI: remove non-PNPACPI version of get_rtc_dev() It isn't needed in ACPI code anymore because now ACPI always includes PNPACPI. Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a74388e2 |
|
05-Feb-2007 |
David Brownell <david-b@pacbell.net> |
ACPI: updates rtc-cmos device platform_data Update ACPI to export its RTC extension information through platform_data to the PNPACPI or platform bus device node used on the system being set up. This will need to be updated later to provide a firmware hook to handle system suspend with an alarm pending. Len notes that "Eventually we may bundle ACPI/PNP/PNPACPI..." but if/when that happens, ACPI can simplify this without my help. And until it does, the separate patch creating a platform_device (on all X86_PC systems, even without ACPI) will be needed. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d91a0078 |
|
06-Dec-2006 |
Justin Chen <justin.chen@hp.com> |
ACPI: Optimize acpi_get_pci_rootbridge_handle() to boot faster Move acpi_get_pci_rootbridge_handle() from glue.c to pci_root.c and get the root bridge ACPI handles by searching the &acpi_pci_roots list instead of walking through the ACPI name space. This significantly reduces boot time on large I/O systems. Signed-off-by: Justin Chen <justin.chen@hp.com> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
465ae641 |
|
10-Nov-2006 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
ACPI: Change ACPI to use dev_archdata instead of firmware_data Change ACPI to use dev_archdata instead of firmware_data This patch changes ACPI to use the new dev_archdata on i386, x86_64 and ia64 (is there any other arch using ACPI ?) to store it's acpi_handle. It also removes the firmware_data field from struct device as this was the only user. Only build-tested on x86 Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
2f000f5c |
|
10-Oct-2006 |
Chen, Justin <justin.chen@hp.com> |
ACPI: optimize pci_rootbridge search acpi_get_pci_rootbridge_handle() walks the ACPI name space searching for seg, bus and the PCI_ROOT_HID_STRING -- returning the handle as soon as if find the match. But the current codes always parses through the whole namespace because the user_function find_pci_rootbridge() returns status=AE_OK when it finds the match. Make the find_pci_rootbridge() return AE_CTRL_TERMINATE when it finds the match. This reduces the ACPI namespace walk for acpi_get_pci_rootbridge_handle(). Signed-off-by: Justin Chen <justin.chen@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
50dd0969 |
|
30-Sep-2006 |
Jan Engelhardt <jengelh@linux01.gwdg.de> |
ACPI: Remove unnecessary from/to-void* and to-void casts in drivers/acpi Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
02438d87 |
|
30-Jun-2006 |
Len Brown <len.brown@intel.com> |
ACPI: delete acpi_os_free(), use kfree() directly Signed-off-by: Len Brown <len.brown@intel.com>
|
#
50eca3eb |
|
30-Sep-2005 |
Bob Moore <robert.moore@intel.com> |
[ACPI] ACPICA 20050930 Completed a major overhaul of the Resource Manager code - specifically, optimizations in the area of the AML/internal resource conversion code. The code has been optimized to simplify and eliminate duplicated code, CPU stack use has been decreased by optimizing function parameters and local variables, and naming conventions across the manager have been standardized for clarity and ease of maintenance (this includes function, parameter, variable, and struct/typedef names.) All Resource Manager dispatch and information tables have been moved to a single location for clarity and ease of maintenance. One new file was created, named "rsinfo.c". The ACPI return macros (return_ACPI_STATUS, etc.) have been modified to guarantee that the argument is not evaluated twice, making them less prone to macro side-effects. However, since there exists the possibility of additional stack use if a particular compiler cannot optimize them (such as in the debug generation case), the original macros are optionally available. Note that some invocations of the return_VALUE macro may now cause size mismatch warnings; the return_UINT8 and return_UINT32 macros are provided to eliminate these. (From Randy Dunlap) Implemented a new mechanism to enable debug tracing for individual control methods. A new external interface, acpi_debug_trace(), is provided to enable this mechanism. The intent is to allow the host OS to easily enable and disable tracing for problematic control methods. This interface can be easily exposed to a user or debugger interface if desired. See the file psxface.c for details. acpi_ut_callocate() will now return a valid pointer if a length of zero is specified - a length of one is used and a warning is issued. This matches the behavior of acpi_ut_allocate(). Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a3a45ec8 |
|
31-Oct-2005 |
Rajesh Shah <rajesh.shah@intel.com> |
[PATCH] pciehp: clean-up how we request control of hotplug hardware This patch further tweaks how we request control of hotplug controller hardware from BIOS. We first search the ACPI namespace corresponding to a specific hotplug controller looking for an _OSC or OSHP method. On failure, we successively move to the ACPI parent object, till we hit the highest level host bridge in the hierarchy. This allows for different types of BIOS's which place the _OSC/OSHP methods at various places in the acpi namespace, while still not encroaching on the namespace of some other root level host bridge. This patch also introduces a new load time option (pciehp_force) that allows us to bypass all _OSC/OSHP checking. Not supporting these methods seems to be be the most common ACPI firmware problem we've run into. This will still _not_ allow the pciehp driver to work correctly if the BIOS really doesn't support pciehp (i.e. if it doesn't generate a hotplug interrupt). Use this option with caution. Some BIOS's may deliberately not build any _OSC/OSHP methods to make sure it retains control the hotplug hardware. Using the pciehp_force parameter for such systems can lead to two separate entities trying to control the same hardware. Signed-off-by: Rajesh Shah <rajesh.shah@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
51b190b3 |
|
19-Oct-2005 |
Peter Chubb <peterc@gelato.unsw.edu.au> |
[PATCH] `unaligned access' in acpi get_root_bridge_busnr() In drivers/acpi/glue.c the address of an integer is cast to the address of an unsigned long. This breaks on systems where a long is larger than an int --- for a start the int can be misaligned; for a second the assignment through the pointer will overwrite part of the next variable. Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au> Acked-by: "Brown, Len" <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
eca008c8 |
|
21-Sep-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] handle ACPICA 20050916's acpi_resource.type rename Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1dadb3da |
|
27-Jul-2005 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
[ACPI] don't complain about PCI root bridges without _SEG There are lots of single-PCI-segment machines that don't supply _SEG for the root bridges. The PCI root bridge driver silently assumes the segment to be zero in this case, so glue.c shouldn't complain either. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4be44fcd |
|
04-Aug-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
|
#
ef7b06cd |
|
18-Apr-2005 |
David Shaohua Li <shaohua.li@intel.com> |
[ACPI] quiet dmesg related to ACPI PM of PCI devices DBG("No ACPI bus support for %s\n", dev->bus_id); http://bugzilla.kernel.org/show_bug.cgi?id=4277 Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4e10d12a |
|
18-Mar-2005 |
David Shaohua Li <shaohua.li@intel.com> |
[ACPI] Bind PCI devices with ACPI devices Implement the framework for binding physical devices with ACPI devices. A physical bus like PCI bus should create a 'acpi_bus_type', with: .find_device: For device which has parent such as normal PCI devices. .find_bridge: It's for special devices, such as PCI root bridge or IDE controller. Such devices generally haven't a parent or ->bus. We use the special method to get an ACPI handle. Uses new field in struct device: firmware_data http://bugzilla.kernel.org/show_bug.cgi?id=4277 Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|