Commit 23a12dde authored by Ingo Molnar's avatar Ingo Molnar

Merge branch 'core/urgent' into x86/urgent, to pick up objtool fix

Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
parents 98f76206 bcb6fb5d

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

......@@ -323,7 +323,6 @@ ForEachMacros:
- 'protocol_for_each_card'
- 'protocol_for_each_dev'
- 'queue_for_each_hw_ctx'
- 'radix_tree_for_each_contig'
- 'radix_tree_for_each_slot'
- 'radix_tree_for_each_tagged'
- 'rbtree_postorder_for_each_entry_safe'
......
......@@ -119,6 +119,13 @@ Mark Brown <broonie@sirena.org.uk>
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
Matthew Wilcox <willy@infradead.org> <matthew.r.wilcox@intel.com>
Matthew Wilcox <willy@infradead.org> <matthew@wil.cx>
Matthew Wilcox <willy@infradead.org> <mawilcox@linuxonhyperv.com>
Matthew Wilcox <willy@infradead.org> <mawilcox@microsoft.com>
Matthew Wilcox <willy@infradead.org> <willy@debian.org>
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
Matthieu CASTET <castet.matthieu@free.fr>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
......@@ -153,6 +160,11 @@ Peter Oruba <peter.oruba@amd.com>
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
Praveen BP <praveenbp@ti.com>
Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com>
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
Rajesh Shah <rajesh.shah@intel.com>
Ralf Baechle <ralf@linux-mips.org>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
......
......@@ -199,7 +199,7 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
KernelVersion: 4.18
KernelVersion: 4.19
Contact: linux-iio@vger.kernel.org
Description:
Relative position in direction x or y on a pad (may be
......
......@@ -5,7 +5,7 @@ Memory Hotplug
==============
:Created: Jul 28 2007
:Updated: Add description of notifier of memory hotplug: Oct 11 2007
:Updated: Add some details about locking internals: Aug 20 2018
This document is about memory hotplug including how-to-use and current status.
Because Memory Hotplug is still under development, contents of this text will
......@@ -392,6 +392,46 @@ Need more implementation yet....
- Notification completion of remove works by OS to firmware.
- Guard from remove if not yet.
Locking Internals
=================
When adding/removing memory that uses memory block devices (i.e. ordinary RAM),
the device_hotplug_lock should be held to:
- synchronize against online/offline requests (e.g. via sysfs). This way, memory
block devices can only be accessed (.online/.state attributes) by user
space once memory has been fully added. And when removing memory, we
know nobody is in critical sections.
- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC)
Especially, there is a possible lock inversion that is avoided using
device_hotplug_lock when adding memory and user space tries to online that
memory faster than expected:
- device_online() will first take the device_lock(), followed by
mem_hotplug_lock
- add_memory_resource() will first take the mem_hotplug_lock, followed by
the device_lock() (while creating the devices, during bus_add_device()).
As the device is visible to user space before taking the device_lock(), this
can result in a lock inversion.
onlining/offlining of memory should be done via device_online()/
device_offline() - to make sure it is properly synchronized to actions
via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type)
When adding/removing/onlining/offlining memory or adding/removing
heterogeneous/device memory, we should always hold the mem_hotplug_lock in
write mode to serialise memory hotplug (e.g. access to global/zone
variables).
In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
mode allows for a quite efficient get_online_mems/put_online_mems
implementation, so code accessing memory can protect from that memory
vanishing.
Future Work
===========
......
......@@ -26,6 +26,7 @@ Offset Value Purpose
0x20 0xfcba0d10 (Magic cookie) AFTR
0x24 exynos_cpu_resume_ns AFTR
0x28 + 4*cpu 0x8 (Magic cookie, Exynos3250) AFTR
0x28 0x0 or last value during resume (Exynos542x) System suspend
2. Secure mode
......
......@@ -5,54 +5,23 @@ Boot time memory management
Early system initialization cannot use "normal" memory management
simply because it is not set up yet. But there is still need to
allocate memory for various data structures, for instance for the
physical page allocator. To address this, a specialized allocator
called the :ref:`Boot Memory Allocator <bootmem>`, or bootmem, was
introduced. Several years later PowerPC developers added a "Logical
Memory Blocks" allocator, which was later adopted by other
architectures and renamed to :ref:`memblock <memblock>`. There is also
a compatibility layer called `nobootmem` that translates bootmem
allocation interfaces to memblock calls.
physical page allocator.
The selection of the early allocator is done using
``CONFIG_NO_BOOTMEM`` and ``CONFIG_HAVE_MEMBLOCK`` kernel
configuration options. These options are enabled or disabled
statically by the architectures' Kconfig files.
* Architectures that rely only on bootmem select
``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=n``.
* The users of memblock with the nobootmem compatibility layer set
``CONFIG_NO_BOOTMEM=y && CONFIG_HAVE_MEMBLOCK=y``.
* And for those that use both memblock and bootmem the configuration
includes ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=y``.
Whichever allocator is used, it is the responsibility of the
architecture specific initialization to set it up in
:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions.
A specialized allocator called ``memblock`` performs the
boot time memory management. The architecture specific initialization
must set it up in :c:func:`setup_arch` and tear it down in
:c:func:`mem_init` functions.
Once the early memory management is available it offers a variety of
functions and macros for memory allocations. The allocation request
may be directed to the first (and probably the only) node or to a
particular node in a NUMA system. There are API variants that panic
when an allocation fails and those that don't. And more recent and
advanced memblock even allows controlling its own behaviour.
.. _bootmem:
Bootmem
=======
when an allocation fails and those that don't.
(mostly stolen from Mel Gorman's "Understanding the Linux Virtual
Memory Manager" `book`_)
Memblock also offers a variety of APIs that control its own behaviour.
.. _book: https://www.kernel.org/doc/gorman/
.. kernel-doc:: mm/bootmem.c
:doc: bootmem overview
.. _memblock:
Memblock
========
Memblock Overview
=================
.. kernel-doc:: mm/memblock.c
:doc: memblock overview
......@@ -61,26 +30,6 @@ Memblock
Functions and structures
========================
Common API
----------
The functions that are described in this section are available
regardless of what early memory manager is enabled.
.. kernel-doc:: mm/nobootmem.c
Bootmem specific API
--------------------
These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n``
.. kernel-doc:: include/linux/bootmem.h
.. kernel-doc:: mm/bootmem.c
:functions:
Memblock specific API
---------------------
Here is the description of memblock data structures, functions and
macros. Some of them are actually internal, but since they are
documented it would be silly to omit them. Besides, reading the
......
......@@ -21,6 +21,7 @@ Core utilities
local_ops
workqueue
genericirq
xarray
flexible-arrays
librs
genalloc
......
This diff is collapsed.
......@@ -57,12 +57,17 @@ Boards with the Amlogic Meson AXG A113D SoC shall have the following properties:
Required root node property:
compatible: "amlogic,a113d", "amlogic,meson-axg";
Boards with the Amlogic Meson G12A S905D2 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,g12a";
Board compatible values (alphabetically, grouped by SoC):
- "geniatech,atv1200" (Meson6)
- "minix,neo-x8" (Meson8)
- "endless,ec100" (Meson8b)
- "hardkernel,odroid-c1" (Meson8b)
- "tronfy,mxq" (Meson8b)
......@@ -101,6 +106,8 @@ Board compatible values (alphabetically, grouped by SoC):
- "amlogic,s400" (Meson axg a113d)
- "amlogic,u200" (Meson g12a s905d2)
Amlogic Meson Firmware registers Interface
------------------------------------------
......
......@@ -42,6 +42,14 @@ Raspberry Pi Compute Module
Required root node properties:
compatible = "raspberrypi,compute-module", "brcm,bcm2835";
Raspberry Pi Compute Module 3
Required root node properties:
compatible = "raspberrypi,3-compute-module", "brcm,bcm2837";
Raspberry Pi Compute Module 3 Lite
Required root node properties:
compatible = "raspberrypi,3-compute-module-lite", "brcm,bcm2837";
Raspberry Pi Zero
Required root node properties:
compatible = "raspberrypi,model-zero", "brcm,bcm2835";
......
NXP i.MX System Controller Firmware (SCFW)
--------------------------------------------------------------------
The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).
The AP communicates with the SC using a multi-ported MU module found
in the LSIO subsystem. The current definition of this MU module provides
5 remote AP connections to the SC to support up to 5 execution environments
(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
with the LSIO DSC IP bus. The SC firmware will communicate with this MU
using the MSI bus.
System Controller Device Node:
============================================================