Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

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

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



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

.clang-format

+0 −1
Original line number Diff line number Diff line
@@ -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'

.mailmap

+12 −0
Original line number Diff line number Diff line
@@ -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>

Documentation/ABI/testing/sysfs-bus-iio

+1 −1
Original line number Diff line number Diff line
@@ -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

Documentation/admin-guide/mm/memory-hotplug.rst

+41 −1
Original line number Diff line number Diff line
@@ -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

===========

Documentation/arm/Samsung/Bootloader-interface.txt

+1 −0
Original line number Diff line number Diff line
@@ -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