19 Jul, 2019
1 commit
-
walk_memory_range() was once used to iterate over sections. Now, it
iterates over memory blocks. Rename the function, fixup the
documentation.Also, pass start+size instead of PFNs, which is what most callers
already have at hand. (we'll rework link_mem_sections() most probably
soon)Follow-up patches will rework, simplify, and move walk_memory_blocks()
to drivers/base/memory.c.Note: walk_memory_blocks() only works correctly right now if the
start_pfn is aligned to a section start. This is the case right now,
but we'll generalize the function in a follow up patch so the semantics
match the documentation.[akpm@linux-foundation.org: remove unused variable]
Link: http://lkml.kernel.org/r/20190614100114.311-5-david@redhat.com
Signed-off-by: David Hildenbrand
Reviewed-by: Andrew Morton
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Greg Kroah-Hartman
Cc: David Hildenbrand
Cc: Rashmica Gupta
Cc: Pavel Tatashin
Cc: Anshuman Khandual
Cc: Michael Neuling
Cc: Thomas Gleixner
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: Wei Yang
Cc: Juergen Gross
Cc: Qian Cai
Cc: Arun KS
Cc: Nick Desaulniers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
21 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose good title or non infringement see the gnu general public
license for more detailsextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 7 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Steve Winslow
Reviewed-by: Jilayne Lovejoy
Reviewed-by: Kate Stewart
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190519154041.727898173@linutronix.de
Signed-off-by: Greg Kroah-Hartman
31 Oct, 2018
2 commits
-
add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.In general, we should hold the device_hotplug_lock when adding memory to
synchronize against online/offline request (e.g. from user space) - which
already resulted in lock inversions due to device_lock() and
mem_hotplug_lock - see 30467e0b3be ("mm, hotplug: fix concurrent memory
hot-add deadlock"). add_memory()/add_memory_resource() will create memory
block devices, so this really feels like the right thing to do.Holding the device_hotplug_lock makes sure that a memory block device
can really only be accessed (e.g. via .online/.state) from user space,
once the memory has been fully added to the system.The lock is not held yet in
drivers/xen/balloon.c
arch/powerpc/platforms/powernv/memtrace.c
drivers/s390/char/sclp_cmd.c
drivers/hv/hv_balloon.c
So, let's either use the locked variants or take the lock.Don't export add_memory_resource(), as it once was exported to be used by
XEN, which is never built as a module. If somebody requires it, we also
have to export a locked variant (as device_hotplug_lock is never
exported).Link: http://lkml.kernel.org/r/20180925091457.28651-3-david@redhat.com
Signed-off-by: David Hildenbrand
Reviewed-by: Pavel Tatashin
Reviewed-by: Rafael J. Wysocki
Reviewed-by: Rashmica Gupta
Reviewed-by: Oscar Salvador
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Greg Kroah-Hartman
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Nathan Fontenot
Cc: John Allen
Cc: Michal Hocko
Cc: Dan Williams
Cc: Joonsoo Kim
Cc: Vlastimil Babka
Cc: Mathieu Malaterre
Cc: Pavel Tatashin
Cc: YASUAKI ISHIMATSU
Cc: Balbir Singh
Cc: Haiyang Zhang
Cc: Heiko Carstens
Cc: Jonathan Corbet
Cc: Kate Stewart
Cc: "K. Y. Srinivasan"
Cc: Martin Schwidefsky
Cc: Michael Neuling
Cc: Philippe Ombredanne
Cc: Stephen Hemminger
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Patch series "mm: online/offline_pages called w.o. mem_hotplug_lock", v3.
Reading through the code and studying how mem_hotplug_lock is to be used,
I noticed that there are two places where we can end up calling
device_online()/device_offline() - online_pages()/offline_pages() without
the mem_hotplug_lock. And there are other places where we call
device_online()/device_offline() without the device_hotplug_lock.While e.g.
echo "online" > /sys/devices/system/memory/memory9/state
is fine, e.g.
echo 1 > /sys/devices/system/memory/memory9/online
Will not take the mem_hotplug_lock. However the device_lock() and
device_hotplug_lock.E.g. via memory_probe_store(), we can end up calling
add_memory()->online_pages() without the device_hotplug_lock. So we can
have concurrent callers in online_pages(). We e.g. touch in
online_pages() basically unprotected zone->present_pages then.Looks like there is a longer history to that (see Patch #2 for details),
and fixing it to work the way it was intended is not really possible. We
would e.g. have to take the mem_hotplug_lock in device/base/core.c, which
sounds wrong.Summary: We had a lock inversion on mem_hotplug_lock and device_lock().
More details can be found in patch 3 and patch 6.I propose the general rules (documentation added in patch 6):
1. add_memory/add_memory_resource() must only be called with
device_hotplug_lock.
2. remove_memory() must only be called with device_hotplug_lock. This is
already documented and holds for all callers.
3. device_online()/device_offline() must only be called with
device_hotplug_lock. This is already documented and true for now in core
code. Other callers (related to memory hotplug) have to be fixed up.
4. mem_hotplug_lock is taken inside of add_memory/remove_memory/
online_pages/offline_pages.To me, this looks way cleaner than what we have right now (and easier to
verify). And looking at the documentation of remove_memory, using
lock_device_hotplug also for add_memory() feels natural.This patch (of 6):
remove_memory() is exported right now but requires the
device_hotplug_lock, which is not exported. So let's provide a variant
that takes the lock and only export that one.The lock is already held in
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
arch/powerpc/platforms/powernv/memtrace.cApart from that, there are not other users in the tree.
Link: http://lkml.kernel.org/r/20180925091457.28651-2-david@redhat.com
Signed-off-by: David Hildenbrand
Reviewed-by: Pavel Tatashin
Reviewed-by: Rafael J. Wysocki
Reviewed-by: Rashmica Gupta
Reviewed-by: Oscar Salvador
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Rashmica Gupta
Cc: Michael Neuling
Cc: Balbir Singh
Cc: Nathan Fontenot
Cc: John Allen
Cc: Michal Hocko
Cc: Dan Williams
Cc: Joonsoo Kim
Cc: Vlastimil Babka
Cc: Greg Kroah-Hartman
Cc: YASUAKI ISHIMATSU
Cc: Mathieu Malaterre
Cc: Boris Ostrovsky
Cc: Haiyang Zhang
Cc: Heiko Carstens
Cc: Jonathan Corbet
Cc: Juergen Gross
Cc: Kate Stewart
Cc: "K. Y. Srinivasan"
Cc: Martin Schwidefsky
Cc: Philippe Ombredanne
Cc: Stephen Hemminger
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Jul, 2015
1 commit
-
There is no need to carry potentially outdated Free Software Foundation
mailing address in file headers since the COPYING file includes it.Signed-off-by: Jarkko Nikula
Signed-off-by: Rafael J. Wysocki
26 Jan, 2015
1 commit
-
struct acpi_resource_address and struct acpi_resource_extended_address64 share substracts
just at different offsets. To unify the parsing functions, OSPMs like Linux
need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
extract the shared data.This patch also synchronizes the structure changes to the Linux kernel.
The usages are searched by matching the following keywords:
1. acpi_resource_address
2. acpi_resource_extended_address
3. ACPI_RESOURCE_TYPE_ADDRESS
4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
And we found and fixed the usages in the following files:
arch/ia64/kernel/acpi-ext.c
arch/ia64/pci/pci.c
arch/x86/pci/acpi.c
arch/x86/pci/mmconfig-shared.c
drivers/xen/xen-acpi-memhotplug.c
drivers/acpi/acpi_memhotplug.c
drivers/acpi/pci_root.c
drivers/acpi/resource.c
drivers/char/hpet.c
drivers/pnp/pnpacpi/rsparser.c
drivers/hv/vmbus_drv.cBuild tests are passed with defconfig/allnoconfig/allyesconfig and
defconfig+CONFIG_ACPI=n.Original-by: Thomas Gleixner
Original-by: Jiang Liu
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
30 May, 2014
1 commit
-
Prevent platform devices from being created for ACPI memory device
objects if CONFIG_ACPI_HOTPLUG_MEMORY is unset by compiling out the
memory hotplug scan handler's callbacks only in that case and still
compiling its device ID list in and registering the scan handler in
either case.Also unset the memory hotplug scan handler's .attach() callback
if acpi_no_memhotplug is set, but still register the scan handler to
avoid creating platform devices for ACPI memory devices in that case
too.This change is based on a prototype from Zhang Rui.
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
16 Jan, 2014
1 commit
-
When booting a kexec/kdump kernel on a system that has specific memory
hotplug regions the boot will fail with warnings like:swapper/0: page allocation failure: order:9, mode:0x84d0
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-65.el7.x86_64 #1
Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
0000000000000000 ffff8800341bd8c8 ffffffff815bcc67 ffff8800341bd950
ffffffff8113b1a0 ffff880036339b00 0000000000000009 00000000000084d0
ffff8800341bd950 ffffffff815b87ee 0000000000000000 0000000000000200
Call Trace:
[] dump_stack+0x19/0x1b
[] warn_alloc_failed+0xf0/0x160
[] ? __alloc_pages_direct_compact+0xac/0x196
[] __alloc_pages_nodemask+0x7ff/0xa00
[] vmemmap_alloc_block+0x62/0xba
[] vmemmap_alloc_block_buf+0x15/0x3b
[] vmemmap_populate+0xb4/0x21b
[] sparse_mem_map_populate+0x27/0x35
[] sparse_add_one_section+0x7a/0x185
[] __add_pages+0xaf/0x240
[] arch_add_memory+0x59/0xd0
[] add_memory+0xb9/0x1b0
[] acpi_memory_device_add+0x18d/0x26d
[] acpi_bus_device_attach+0x7d/0xcd
[] acpi_ns_walk_namespace+0xc8/0x17f
[] ? acpi_bus_type_and_status+0x90/0x90
[] ? acpi_bus_type_and_status+0x90/0x90
[] acpi_walk_namespace+0x95/0xc5
[] acpi_bus_scan+0x8b/0x9d
[] acpi_scan_init+0x63/0x160
[] acpi_init+0x25d/0x2a6
[] ? acpi_sleep_proc_init+0x2a/0x2a
[] do_one_initcall+0xe2/0x190
[] kernel_init_freeable+0x17c/0x207
[] ? do_early_param+0x88/0x88
[] ? rest_init+0x80/0x80
[] kernel_init+0xe/0x180
[] ret_from_fork+0x7c/0xb0
[] ? rest_init+0x80/0x80
Mem-Info:
Node 0 DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Node 0 DMA32 per-cpu:
CPU 0: hi: 42, btch: 7 usd: 0
active_anon:0 inactive_anon:0 isolated_anon:0
active_file:0 inactive_file:0 isolated_file:0
unevictable:0 dirty:0 writeback:0 unstable:0
free:872 slab_reclaimable:13 slab_unreclaimable:1880
mapped:0 shmem:0 pagetables:0 bounce:0
free_cma:0because the system has run out of memory at boot time. This occurs
because of the following sequence in the boot:Main kernel boots and sets E820 map. The second kernel is booted with a
map generated by the kdump service using memmap= and memmap=exactmap.
These parameters are added to the kernel parameters of the kexec/kdump
kernel. The kexec/kdump kernel has limited memory resources so as not
to severely impact the main kernel.The system then panics and the kdump/kexec kernel boots (which is a
completely new kernel boot). During this boot ACPI is initialized and the
kernel (as can be seen above) traverses the ACPI namespace and finds an
entry for a memory device to be hotadded.ie)
[] __add_pages+0xaf/0x240
[] arch_add_memory+0x59/0xd0
[] add_memory+0xb9/0x1b0
[] acpi_memory_device_add+0x18d/0x26d
[] acpi_bus_device_attach+0x7d/0xcd
[] acpi_ns_walk_namespace+0xc8/0x17f
[] ? acpi_bus_type_and_status+0x90/0x90
[] ? acpi_bus_type_and_status+0x90/0x90
[] acpi_walk_namespace+0x95/0xc5
[] acpi_bus_scan+0x8b/0x9d
[] acpi_scan_init+0x63/0x160
[] acpi_init+0x25d/0x2a6At this point the kernel adds page table information and the the kexec/kdump
kernel runs out of memory.This can also be reproduced by using the memmap=exactmap and mem=X
parameters on the main kernel and booting.This patchset resolves the problem by adding a kernel parameter,
acpi_no_memhotplug, to disable ACPI memory hotplug.Signed-off-by: Prarit Bhargava
Acked-by: Vivek Goyal
Acked-by: Toshi Kani
Acked-by: David Rientjes
Signed-off-by: Rafael J. Wysocki
07 Dec, 2013
1 commit
-
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
28 Oct, 2013
1 commit
-
* acpi-hotplug:
ACPI / memhotplug: Use defined marco METHOD_NAME__STA
ACPI / hotplug: Use kobject_init_and_add() instead of _init() and _add()
ACPI / hotplug: Don't set kobject parent pointer explicitly
ACPI / hotplug: Set kobject name via kobject_add(), not kobject_set_name()
hotplug, powerpc, x86: Remove cpu_hotplug_driver_lock()
hotplug / x86: Disable ARCH_CPU_PROBE_RELEASE on x86
hotplug / x86: Add hotplug lock to missing places
hotplug / x86: Fix online state in cpu0 debug interface
10 Oct, 2013
1 commit
-
We already have predefined marco for method name "_STA', so
using the marco instead of directly using the string.Signed-off-by: Zhang Yanfei
Signed-off-by: Rafael J. Wysocki
24 Sep, 2013
1 commit
-
Use more appropriate NUMA_NO_NODE instead of -1
Signed-off-by: Jianguo Wu
Acked-by: David Rientjes
Signed-off-by: Rafael J. Wysocki
15 Jul, 2013
1 commit
-
device->driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory. A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.Signed-off-by: Toshi Kani
Reviewed-by: Yasuaki Ishimatsu
Cc: 2.6.32+
Signed-off-by: Rafael J. Wysocki
02 Jun, 2013
1 commit
-
Now that the memory offlining should be taken care of by the
companion device offlining code in acpi_scan_hot_remove(), the
ACPI memory hotplug driver doesn't need to offline it in
remove_memory() any more. Moreover, since the return value of
remove_memory() is not used, it's better to make it be a void
function and trigger a BUG() if the memory scheduled for removal is
not offline.Change the code in accordance with the above observations.
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Toshi Kani
12 May, 2013
1 commit
-
During ACPI memory hotplug configuration bind memory blocks residing
in modules removable through the standard ACPI mechanism to struct
acpi_device objects associated with ACPI namespace objects
representing those modules. Accordingly, unbind those memory blocks
from the struct acpi_device objects when the memory modules in
question are being removed.When "offline" operation for devices representing memory blocks is
introduced, this will allow the ACPI core's device hot-remove code to
use it to carry out remove_memory() for those memory blocks and check
the results of that before it actually removes the modules holding
them from the system.Since walk_memory_range() is used for accessing all memory blocks
corresponding to a given ACPI namespace object, it is exported from
memory_hotplug.c so that the code in acpi_memhotplug.c can use it.Signed-off-by: Rafael J. Wysocki
Tested-by: Vasilis Liaskovitis
Reviewed-by: Toshi Kani
25 Mar, 2013
2 commits
-
acpi_memory_info has enabled bit and failed bit for controlling memory
hotplug. But we don't need to keep both bits.The patch removes acpi_memory_info->failed bit.
Signed-off-by: yasuaki ishimatsu
Acked-by: Toshi Kani
Signed-off-by: Rafael J. Wysocki -
At http://marc.info/?l=linux-acpi&m=135769405622667&w=2 thread,
Toshi Kani mentioned as follows:"I have a question about the change you made in commit 65479472 in
acpi_memhotplug.c. This change seems to require that
acpi_memory_enable_device() calls add_memory() to add all memory ranges
represented by memory device objects at boot-time, and keep the results
be used for hot-remove.If I understand it right, this add_memory() call fails with EEXIST at
boot-time since all memory ranges should have been added from EFI memory
table (or e820) already. This results all memory ranges be marked as !
enabled & !failed. I think this means that we cannot hot-delete any
memory ranges presented at boot-time since acpi_memory_remove_memory()
only calls remove_memory() when the enabled flag is set. Is that
correct?"Above mention is correct. Thus even if memory device supports hotplug,
memory presented at boot-time cannot be hot removed since the memory
device's acpi_memory_info->enabled is always 0.This patch changes to set 1 to "acpi_memory_info->enabled" of memory
device presented at boot-time for hot removing the memory device.Signed-off-by: Yasuaki Ishimatsu
Acked-by: Toshi Kani
Signed-off-by: Rafael J. Wysocki
04 Mar, 2013
1 commit
-
Make the ACPI memory hotplug driver use struct acpi_scan_handler
for representing the object used to set up ACPI memory hotplug
functionality and to remove hotplug memory ranges and data
structures used by the driver before unregistering ACPI device
nodes representing memory. Register the new struct acpi_scan_handler
object with the help of acpi_scan_add_handler_with_hotplug() to allow
user space to manipulate the attributes of the memory hotplug
profile.This results in a significant reduction of the drvier's code size
and removes some ACPI hotplug code duplication.Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Tested-by: Toshi Kani
24 Feb, 2013
1 commit
-
Introduce a new function try_offline_node() to remove sysfs file of node
when all memory sections of this node are removed. If some memory
sections of this node are not removed, this function does nothing.Signed-off-by: Wen Congyang
Signed-off-by: Tang Chen
Cc: KOSAKI Motohiro
Cc: Jiang Liu
Cc: Jianguo Wu
Cc: Kamezawa Hiroyuki
Cc: Lai Jiangshan
Cc: Wu Jianguo
Cc: Yasuaki Ishimatsu
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Feb, 2013
1 commit
-
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
26 Jan, 2013
2 commits
-
The second argument of ACPI driver .remove() operation is only used
by the ACPI processor driver and the value passed to that driver
through it is always available from the given struct acpi_device
object's removal_type field. For this reason, the second ACPI driver
.remove() argument is in fact useless, so drop it.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Jiang Liu
Acked-by: Toshi Kani
Acked-by: Yinghai Lu -
The following commits depend on the 'acpi-scan' material.
19 Jan, 2013
1 commit
-
The only difference between acpi_bus_scan() and acpi_bus_add() is the
invocation of acpi_update_all_gpes() in the latter which in fact is
unnecessary, because acpi_update_all_gpes() has already been called
by acpi_scan_init() and the way it is implemented guarantees the next
invocations of it to do nothing.For this reason, drop acpi_bus_add() and make all its callers use
acpi_bus_scan() directly instead of it. Additionally, rearrange the
code in acpi_scan_init() slightly to improve the visibility of the
acpi_update_all_gpes() call in there.Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
15 Jan, 2013
1 commit
-
Should use acpi_device pointer directly instead of use handle and
get the device pointer again later.Signed-off-by: Yinghai Lu
Signed-off-by: Rafael J. Wysocki
03 Jan, 2013
3 commits
-
When memory hotadd, acpi_memory_enable_device has already been done
at drv->ops.add (acpi_memory_device_add), no need to do it again
at notify callback.At acpi_memory_enable_device, acpi_memory_get_device_resources
is also a redundant action, since it has been done at drv->ops.add.Signed-off-by: Liu Jinsong
Signed-off-by: Rafael J. Wysocki -
The callers of acpi_bus_add() usually assume that if it has
succeeded, then a struct acpi_device object has been attached to
the handle passed as the first argument. Unfortunately, however,
this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add()
too as a result, may return a pointer to a different struct
acpi_device object on success (it may be an object corresponding to
one of the descendant ACPI nodes in the namespace scope below that
handle).For this reason, the callers of acpi_bus_add() who care about
whether or not a struct acpi_device object has been created for
its first argument need to check that using acpi_bus_get_device()
anyway, so the second argument of acpi_bus_add() is not really
useful for them. The same observation applies to acpi_bus_scan()
executed directly from acpi_scan_init().Therefore modify the relevant callers of acpi_bus_add() to check the
existence of the struct acpi_device in question with the help of
acpi_bus_get_device() and drop the no longer necessary second
argument of acpi_bus_add(). Accordingly, modify acpi_scan_init() to
use acpi_bus_get_device() to get acpi_root and drop the no longer
needed second argument of acpi_bus_scan().Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
Acked-by: Toshi Kani -
Notice that acpi_bus_add() uses only 2 of its 4 arguments and
redefine its header to match the body. Update all of its callers as
necessary and observe that this leads to quite a number of removed
lines of code (Linus will like that).Add a kerneldoc comment documenting acpi_bus_add() and wonder how
its callers make wrong assumptions about the second argument (make
note to self to take care of that later).Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
Acked-by: Toshi Kani
22 Nov, 2012
1 commit
-
Updated Memory hotplug error messages with acpi_handle_(),
dev_() and pr_(). Added missing "\n".Signed-off-by: Toshi Kani
Signed-off-by: Rafael J. Wysocki
16 Nov, 2012
6 commits
-
We had introduced acpi_hotmem_initialized to avoid strange add_memory fail
message. But the memory device may not be used by the kernel, and the
device should be bound when the driver is being loaded. Remove
acpi_hotmem_initialized to allow that the device can be bound when the
driver is being loaded.Signed-off-by: Wen Congyang
Reviewed-by: Yasuaki Ishimatsu
Acked-by: David Rientjes
Signed-off-by: Rafael J. Wysocki -
We eject the memory device even if it is in use. It is very dangerous,
and it will cause the kernel to be panicked.Signed-off-by: Wen Congyang
Reviewed-by: Yasuaki Ishimatsu
Acked-by: David Rientjes
Signed-off-by: Rafael J. Wysocki -
If acpi_memory_enable_device() fails, acpi_memory_enable_device() will
return a non-zero value, which means we fail to bind the memory device to
this driver. So we should free memory device before
acpi_memory_device_add() returns.Signed-off-by: Wen Congyang
Reviewed-by: Yasuaki Ishimatsu
Acked-by: David Rientjes
Signed-off-by: Rafael J. Wysocki -
We allocate memory to store acpi_memory_info, so we should free it before
freeing mem_device.Signed-off-by: Wen Congyang
Reviewed-by: Yasuaki Ishimatsu
Acked-by: David Rientjes
Signed-off-by: Rafael J. Wysocki -
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/ejectWe handle the 1st case in the module acpi_memhotplug, and handle
the 2nd case in ACPI eject notification. This 2 events may happen
at the same time, so we may touch acpi_memory_device.res_list at
the same time. This patch reimplements memory-hotremove support
through an ACPI eject notification. Now the memory device is
offlined and hotremoved only in the function acpi_memory_device_remove()
which is protected by device_lock().Signed-off-by: Wen Congyang
Reviewed-by: Yasuaki Ishimatsu
Reviewed-by: Toshi Kani
Signed-off-by: Rafael J. Wysocki -
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/ejectIn the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be called.
acpi_memory_device_remove() will also be called when we unbind the
memory device from the driver acpi_memhotplug or a driver initialization
fails.acpi_memory_disable_device() has already implemented a code which
offlines memory and releases acpi_memory_info struct. But
acpi_memory_device_remove() has not implemented it yet.So the patch move offlining memory and releasing acpi_memory_info struct
codes to a new function acpi_memory_remove_memory(). And it is used by both
acpi_memory_device_remove() and acpi_memory_disable_device().Signed-off-by: Yasuaki Ishimatsu
Signed-off-by: Wen Congyang
Acked-by: David Rientjes
Signed-off-by: Rafael J. Wysocki
15 Nov, 2012
1 commit
-
The memory device has been ejected and powoffed, so we can call
acpi_bus_trim() to remove the memory device from acpi bus.Signed-off-by: Wen Congyang
Signed-off-by: Rafael J. Wysocki
04 Jun, 2012
1 commit
-
Changed acpi_memory_device_notify() to call ACPI _OST method
when ACPI memory hotplug operation has completed.Signed-off-by: Toshi Kani
Signed-off-by: Len Brown
30 Mar, 2010
1 commit
-
…it 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 allmodconfig8. 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>
25 Nov, 2009
1 commit
-
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
Signed-off-by: Bob Moore
Signed-off-by: Len Brown
19 Sep, 2009
1 commit
27 Aug, 2009
1 commit
-
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
Signed-off-by: Lin Ming
Signed-off-by: Len Brown
