License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
|
* ioport.h Definitions of routines for detecting, reserving and
|
|
|
|
|
* allocating system resources.
|
|
|
|
|
*
|
|
|
|
|
* Authors: Linus Torvalds
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _LINUX_IOPORT_H
|
|
|
|
|
#define _LINUX_IOPORT_H
|
|
|
|
|
|
2008-01-30 15:30:32 +03:00
|
|
|
#ifndef __ASSEMBLY__
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/compiler.h>
|
2006-06-13 02:49:31 +04:00
|
|
|
#include <linux/types.h>
|
2019-04-23 04:30:06 +03:00
|
|
|
#include <linux/bits.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
|
* Resources are tree-like, allowing
|
|
|
|
|
* nesting etc..
|
|
|
|
|
*/
|
|
|
|
|
struct resource {
|
2006-06-13 02:49:31 +04:00
|
|
|
resource_size_t start;
|
|
|
|
|
resource_size_t end;
|
2005-04-17 02:20:36 +04:00
|
|
|
const char *name;
|
|
|
|
|
unsigned long flags;
|
2016-01-26 23:57:19 +03:00
|
|
|
unsigned long desc;
|
2005-04-17 02:20:36 +04:00
|
|
|
struct resource *parent, *sibling, *child;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* IO resources have these defined flags.
|
2016-05-16 23:12:02 +03:00
|
|
|
*
|
|
|
|
|
* PCI devices expose these flags to userspace in the "resource" sysfs file,
|
|
|
|
|
* so don't move them.
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
|
|
|
|
#define IORESOURCE_BITS 0x000000ff /* Bus-specific bits */
|
|
|
|
|
|
2010-03-05 20:47:26 +03:00
|
|
|
#define IORESOURCE_TYPE_BITS 0x00001f00 /* Resource type */
|
2012-08-07 22:42:46 +04:00
|
|
|
#define IORESOURCE_IO 0x00000100 /* PCI/ISA I/O ports */
|
2005-04-17 02:20:36 +04:00
|
|
|
#define IORESOURCE_MEM 0x00000200
|
2012-08-07 22:42:45 +04:00
|
|
|
#define IORESOURCE_REG 0x00000300 /* Register offsets */
|
2005-04-17 02:20:36 +04:00
|
|
|
#define IORESOURCE_IRQ 0x00000400
|
|
|
|
|
#define IORESOURCE_DMA 0x00000800
|
2010-03-05 20:47:42 +03:00
|
|
|
#define IORESOURCE_BUS 0x00001000
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2010-03-05 20:47:26 +03:00
|
|
|
#define IORESOURCE_PREFETCH 0x00002000 /* No side effects */
|
|
|
|
|
#define IORESOURCE_READONLY 0x00004000
|
|
|
|
|
#define IORESOURCE_CACHEABLE 0x00008000
|
|
|
|
|
#define IORESOURCE_RANGELENGTH 0x00010000
|
|
|
|
|
#define IORESOURCE_SHADOWABLE 0x00020000
|
PCI: clean up resource alignment management
Done per Linus' request and suggestions. Linus has explained that
better than I'll be able to explain:
On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
> Actually, before we go any further, there might be a less intrusive
> alternative: add just a couple of flags to the resource flags field (we
> still have something like 8 unused bits on 32-bit), and use those to
> implement a generic "resource_alignment()" routine.
>
> Two flags would do it:
>
> - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
> resources)
>
> - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
> during probing)
>
> and then the case of both flags zero (or both bits set) would actually be
> "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
> actually allocate the resource (so that we don't use the "start" field as
> alignment incorrectly when it no longer indicates alignment).
>
> That wouldn't be totally generic, but it would have the nice property of
> automatically at least add sanity checking for that whole "res->start has
> the odd meaning of 'alignment' during probing" and remove the need for a
> new field, and it would allow us to have a generic "resource_alignment()"
> routine that just gets a resource pointer.
Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-30 19:50:14 +04:00
|
|
|
|
2010-03-05 20:47:26 +03:00
|
|
|
#define IORESOURCE_SIZEALIGN 0x00040000 /* size indicates alignment */
|
|
|
|
|
#define IORESOURCE_STARTALIGN 0x00080000 /* start field is alignment */
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2009-04-24 07:48:32 +04:00
|
|
|
#define IORESOURCE_MEM_64 0x00100000
|
2010-03-05 20:47:47 +03:00
|
|
|
#define IORESOURCE_WINDOW 0x00200000 /* forwarded by bridge */
|
2010-03-29 21:38:00 +04:00
|
|
|
#define IORESOURCE_MUXED 0x00400000 /* Resource is software muxed */
|
2009-04-24 07:48:32 +04:00
|
|
|
|
resource: Add System RAM resource type
The IORESOURCE_MEM I/O resource type is used for all types of
memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
reserved, and so on.
This requires walk_system_ram_range(), walk_system_ram_res(),
and region_intersects() to use strcmp() against string "System
RAM" to search for System RAM ranges in the iomem table, which
is inefficient. __ioremap_caller() and reserve_memtype() on x86,
for instance, call walk_system_ram_range() for every request to
check if a given range is in System RAM ranges.
However, adding a new I/O resource type for System RAM is not a
viable option, see [1]. There are approx. 3800 references to
IORESOURCE_MEM in the kernel/drivers, which makes it very
difficult to distinguish their usages between new type and
IORESOURCE_MEM.
The I/O resource types are also used by the PNP subsystem.
Therefore, introduce an extended I/O resource type,
IORESOURCE_SYSTEM_RAM, which consists of IORESOURCE_MEM and a
new modifier flag IORESOURCE_SYSRAM, see [2].
To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' still
working for System RAM, resource_ext_type() is added for
extracting extended type bits.
Link[1]: http://lkml.kernel.org/r/1449168859.9855.54.camel@hpe.com
Link[2]: http://lkml.kernel.org/r/CA+55aFy4WQrWexC4u2LxX9Mw2NVoznw7p3Yh=iF4Xtf7zKWnRw@mail.gmail.com
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Jakub Sitnicki <jsitnicki@gmail.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-arch@vger.kernel.org
Cc: linux-mm <linux-mm@kvack.org>
Link: http://lkml.kernel.org/r/1453841853-11383-2-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-26 23:57:17 +03:00
|
|
|
#define IORESOURCE_EXT_TYPE_BITS 0x01000000 /* Resource extended types */
|
|
|
|
|
#define IORESOURCE_SYSRAM 0x01000000 /* System RAM (modifier) */
|
|
|
|
|
|
2008-10-23 06:55:31 +04:00
|
|
|
#define IORESOURCE_EXCLUSIVE 0x08000000 /* Userland may not map this resource */
|
resource: Add System RAM resource type
The IORESOURCE_MEM I/O resource type is used for all types of
memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
reserved, and so on.
This requires walk_system_ram_range(), walk_system_ram_res(),
and region_intersects() to use strcmp() against string "System
RAM" to search for System RAM ranges in the iomem table, which
is inefficient. __ioremap_caller() and reserve_memtype() on x86,
for instance, call walk_system_ram_range() for every request to
check if a given range is in System RAM ranges.
However, adding a new I/O resource type for System RAM is not a
viable option, see [1]. There are approx. 3800 references to
IORESOURCE_MEM in the kernel/drivers, which makes it very
difficult to distinguish their usages between new type and
IORESOURCE_MEM.
The I/O resource types are also used by the PNP subsystem.
Therefore, introduce an extended I/O resource type,
IORESOURCE_SYSTEM_RAM, which consists of IORESOURCE_MEM and a
new modifier flag IORESOURCE_SYSRAM, see [2].
To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' still
working for System RAM, resource_ext_type() is added for
extracting extended type bits.
Link[1]: http://lkml.kernel.org/r/1449168859.9855.54.camel@hpe.com
Link[2]: http://lkml.kernel.org/r/CA+55aFy4WQrWexC4u2LxX9Mw2NVoznw7p3Yh=iF4Xtf7zKWnRw@mail.gmail.com
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Jakub Sitnicki <jsitnicki@gmail.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-arch@vger.kernel.org
Cc: linux-mm <linux-mm@kvack.org>
Link: http://lkml.kernel.org/r/1453841853-11383-2-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-26 23:57:17 +03:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
#define IORESOURCE_DISABLED 0x10000000
|
2014-02-26 22:25:56 +04:00
|
|
|
#define IORESOURCE_UNSET 0x20000000 /* No address assigned yet */
|
2005-04-17 02:20:36 +04:00
|
|
|
#define IORESOURCE_AUTO 0x40000000
|
|
|
|
|
#define IORESOURCE_BUSY 0x80000000 /* Driver has marked this resource busy */
|
|
|
|
|
|
resource: Add System RAM resource type
The IORESOURCE_MEM I/O resource type is used for all types of
memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
reserved, and so on.
This requires walk_system_ram_range(), walk_system_ram_res(),
and region_intersects() to use strcmp() against string "System
RAM" to search for System RAM ranges in the iomem table, which
is inefficient. __ioremap_caller() and reserve_memtype() on x86,
for instance, call walk_system_ram_range() for every request to
check if a given range is in System RAM ranges.
However, adding a new I/O resource type for System RAM is not a
viable option, see [1]. There are approx. 3800 references to
IORESOURCE_MEM in the kernel/drivers, which makes it very
difficult to distinguish their usages between new type and
IORESOURCE_MEM.
The I/O resource types are also used by the PNP subsystem.
Therefore, introduce an extended I/O resource type,
IORESOURCE_SYSTEM_RAM, which consists of IORESOURCE_MEM and a
new modifier flag IORESOURCE_SYSRAM, see [2].
To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' still
working for System RAM, resource_ext_type() is added for
extracting extended type bits.
Link[1]: http://lkml.kernel.org/r/1449168859.9855.54.camel@hpe.com
Link[2]: http://lkml.kernel.org/r/CA+55aFy4WQrWexC4u2LxX9Mw2NVoznw7p3Yh=iF4Xtf7zKWnRw@mail.gmail.com
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Jakub Sitnicki <jsitnicki@gmail.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-arch@vger.kernel.org
Cc: linux-mm <linux-mm@kvack.org>
Link: http://lkml.kernel.org/r/1453841853-11383-2-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-26 23:57:17 +03:00
|
|
|
/* I/O resource extended types */
|
|
|
|
|
#define IORESOURCE_SYSTEM_RAM (IORESOURCE_MEM|IORESOURCE_SYSRAM)
|
|
|
|
|
|
2008-06-10 03:52:04 +04:00
|
|
|
/* PnP IRQ specific bits (IORESOURCE_BITS) */
|
2005-04-17 02:20:36 +04:00
|
|
|
#define IORESOURCE_IRQ_HIGHEDGE (1<<0)
|
|
|
|
|
#define IORESOURCE_IRQ_LOWEDGE (1<<1)
|
|
|
|
|
#define IORESOURCE_IRQ_HIGHLEVEL (1<<2)
|
|
|
|
|
#define IORESOURCE_IRQ_LOWLEVEL (1<<3)
|
2006-07-03 11:24:10 +04:00
|
|
|
#define IORESOURCE_IRQ_SHAREABLE (1<<4)
|
2008-06-28 02:57:14 +04:00
|
|
|
#define IORESOURCE_IRQ_OPTIONAL (1<<5)
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2008-06-10 03:52:04 +04:00
|
|
|
/* PnP DMA specific bits (IORESOURCE_BITS) */
|
2005-04-17 02:20:36 +04:00
|
|
|
#define IORESOURCE_DMA_TYPE_MASK (3<<0)
|
|
|
|
|
#define IORESOURCE_DMA_8BIT (0<<0)
|
|
|
|
|
#define IORESOURCE_DMA_8AND16BIT (1<<0)
|
|
|
|
|
#define IORESOURCE_DMA_16BIT (2<<0)
|
|
|
|
|
|
|
|
|
|
#define IORESOURCE_DMA_MASTER (1<<2)
|
|
|
|
|
#define IORESOURCE_DMA_BYTE (1<<3)
|
|
|
|
|
#define IORESOURCE_DMA_WORD (1<<4)
|
|
|
|
|
|
|
|
|
|
#define IORESOURCE_DMA_SPEED_MASK (3<<6)
|
|
|
|
|
#define IORESOURCE_DMA_COMPATIBLE (0<<6)
|
|
|
|
|
#define IORESOURCE_DMA_TYPEA (1<<6)
|
|
|
|
|
#define IORESOURCE_DMA_TYPEB (2<<6)
|
|
|
|
|
#define IORESOURCE_DMA_TYPEF (3<<6)
|
|
|
|
|
|
2008-06-10 03:52:04 +04:00
|
|
|
/* PnP memory I/O specific bits (IORESOURCE_BITS) */
|
2005-04-17 02:20:36 +04:00
|
|
|
#define IORESOURCE_MEM_WRITEABLE (1<<0) /* dup: IORESOURCE_READONLY */
|
|
|
|
|
#define IORESOURCE_MEM_CACHEABLE (1<<1) /* dup: IORESOURCE_CACHEABLE */
|
|
|
|
|
#define IORESOURCE_MEM_RANGELENGTH (1<<2) /* dup: IORESOURCE_RANGELENGTH */
|
|
|
|
|
#define IORESOURCE_MEM_TYPE_MASK (3<<3)
|
|
|
|
|
#define IORESOURCE_MEM_8BIT (0<<3)
|
|
|
|
|
#define IORESOURCE_MEM_16BIT (1<<3)
|
|
|
|
|
#define IORESOURCE_MEM_8AND16BIT (2<<3)
|
|
|
|
|
#define IORESOURCE_MEM_32BIT (3<<3)
|
|
|
|
|
#define IORESOURCE_MEM_SHADOWABLE (1<<5) /* dup: IORESOURCE_SHADOWABLE */
|
|
|
|
|
#define IORESOURCE_MEM_EXPANSIONROM (1<<6)
|
mm/memory_hotplug: introduce add_memory_driver_managed()
Patch series "mm/memory_hotplug: Interface to add driver-managed system
ram", v4.
kexec (via kexec_load()) can currently not properly handle memory added
via dax/kmem, and will have similar issues with virtio-mem. kexec-tools
will currently add all memory to the fixed-up initial firmware memmap. In
case of dax/kmem, this means that - in contrast to a proper reboot - how
that persistent memory will be used can no longer be configured by the
kexec'd kernel. In case of virtio-mem it will be harmful, because that
memory might contain inaccessible pieces that require coordination with
hypervisor first.
In both cases, we want to let the driver in the kexec'd kernel handle
detecting and adding the memory, like during an ordinary reboot.
Introduce add_memory_driver_managed(). More on the samentics are in patch
#1.
In the future, we might want to make this behavior configurable for
dax/kmem- either by configuring it in the kernel (which would then also
allow to configure kexec_file_load()) or in kexec-tools by also adding
"System RAM (kmem)" memory from /proc/iomem to the fixed-up initial
firmware memmap.
More on the motivation can be found in [1] and [2].
[1] https://lkml.kernel.org/r/20200429160803.109056-1-david@redhat.com
[2] https://lkml.kernel.org/r/20200430102908.10107-1-david@redhat.com
This patch (of 3):
Some device drivers rely on memory they managed to not get added to the
initial (firmware) memmap as system RAM - so it's not used as initial
system RAM by the kernel and the driver is under control. While this is
the case during cold boot and after a reboot, kexec is not aware of that
and might add such memory to the initial (firmware) memmap of the kexec
kernel. We need ways to teach kernel and userspace that this system ram
is different.
For example, dax/kmem allows to decide at runtime if persistent memory is
to be used as system ram. Another future user is virtio-mem, which has to
coordinate with its hypervisor to deal with inaccessible parts within
memory resources.
We want to let users in the kernel (esp. kexec) but also user space
(esp. kexec-tools) know that this memory has different semantics and
needs to be handled differently:
1. Don't create entries in /sys/firmware/memmap/
2. Name the memory resource "System RAM ($DRIVER)" (exposed via
/proc/iomem) ($DRIVER might be "kmem", "virtio_mem").
3. Flag the memory resource IORESOURCE_MEM_DRIVER_MANAGED
/sys/firmware/memmap/ [1] represents the "raw firmware-provided memory
map" because "on most architectures that firmware-provided memory map is
modified afterwards by the kernel itself". The primary user is kexec on
x86-64. Since commit d96ae5309165 ("memory-hotplug: create
/sys/firmware/memmap entry for new memory"), we add all hotplugged memory
to that firmware memmap - which makes perfect sense for traditional memory
hotplug on x86-64, where real HW will also add hotplugged DIMMs to the
firmware memmap. We replicate what the "raw firmware-provided memory map"
looks like after hot(un)plug.
To keep things simple, let the user provide the full resource name instead
of only the driver name - this way, we don't have to manually
allocate/craft strings for memory resources. Also use the resource name
to make decisions, to avoid passing additional flags. In case the name
isn't "System RAM", it's special.
We don't have to worry about firmware_map_remove() on the removal path.
If there is no entry, it will simply return with -EINVAL.
We'll adapt dax/kmem in a follow-up patch.
[1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Link: http://lkml.kernel.org/r/20200508084217.9160-1-david@redhat.com
Link: http://lkml.kernel.org/r/20200508084217.9160-3-david@redhat.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-06-05 02:48:41 +03:00
|
|
|
#define IORESOURCE_MEM_DRIVER_MANAGED (1<<7)
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2008-06-28 02:57:03 +04:00
|
|
|
/* PnP I/O specific bits (IORESOURCE_BITS) */
|
|
|
|
|
#define IORESOURCE_IO_16BIT_ADDR (1<<0)
|
|
|
|
|
#define IORESOURCE_IO_FIXED (1<<1)
|
2015-10-14 09:29:36 +03:00
|
|
|
#define IORESOURCE_IO_SPARSE (1<<2)
|
2008-06-28 02:57:03 +04:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/* PCI ROM control bits (IORESOURCE_BITS) */
|
|
|
|
|
#define IORESOURCE_ROM_ENABLE (1<<0) /* ROM is enabled, same as PCI_ROM_ADDRESS_ENABLE */
|
2016-03-01 20:38:46 +03:00
|
|
|
#define IORESOURCE_ROM_SHADOW (1<<1) /* Use RAM image, not ROM BAR */
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-20 00:12:08 +03:00
|
|
|
/* PCI control bits. Shares IORESOURCE_BITS with above PCI ROM. */
|
|
|
|
|
#define IORESOURCE_PCI_FIXED (1<<4) /* Do not move resource */
|
2016-05-16 23:12:02 +03:00
|
|
|
#define IORESOURCE_PCI_EA_BEI (1<<5) /* BAR Equivalent Indicator */
|
2006-12-20 00:12:08 +03:00
|
|
|
|
2016-01-26 23:57:19 +03:00
|
|
|
/*
|
|
|
|
|
* I/O Resource Descriptors
|
|
|
|
|
*
|
|
|
|
|
* Descriptors are used by walk_iomem_res_desc() and region_intersects()
|
|
|
|
|
* for searching a specific resource range in the iomem table. Assign
|
|
|
|
|
* a new descriptor when a resource range supports the search interfaces.
|
|
|
|
|
* Otherwise, resource.desc must be set to IORES_DESC_NONE (0).
|
|
|
|
|
*/
|
|
|
|
|
enum {
|
|
|
|
|
IORES_DESC_NONE = 0,
|
|
|
|
|
IORES_DESC_CRASH_KERNEL = 1,
|
|
|
|
|
IORES_DESC_ACPI_TABLES = 2,
|
|
|
|
|
IORES_DESC_ACPI_NV_STORAGE = 3,
|
|
|
|
|
IORES_DESC_PERSISTENT_MEMORY = 4,
|
|
|
|
|
IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
|
2017-09-09 02:11:43 +03:00
|
|
|
IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
|
2019-07-15 05:42:11 +03:00
|
|
|
IORES_DESC_RESERVED = 7,
|
2019-11-07 04:43:16 +03:00
|
|
|
IORES_DESC_SOFT_RESERVED = 8,
|
2016-01-26 23:57:19 +03:00
|
|
|
};
|
2011-07-26 04:13:00 +04:00
|
|
|
|
2019-04-23 04:30:06 +03:00
|
|
|
/*
|
|
|
|
|
* Flags controlling ioremap() behavior.
|
|
|
|
|
*/
|
|
|
|
|
enum {
|
|
|
|
|
IORES_MAP_SYSTEM_RAM = BIT(0),
|
|
|
|
|
IORES_MAP_ENCRYPTED = BIT(1),
|
|
|
|
|
};
|
|
|
|
|
|
2011-07-26 04:13:00 +04:00
|
|
|
/* helpers to define resources */
|
|
|
|
|
#define DEFINE_RES_NAMED(_start, _size, _name, _flags) \
|
|
|
|
|
{ \
|
|
|
|
|
.start = (_start), \
|
|
|
|
|
.end = (_start) + (_size) - 1, \
|
|
|
|
|
.name = (_name), \
|
|
|
|
|
.flags = (_flags), \
|
2016-01-26 23:57:19 +03:00
|
|
|
.desc = IORES_DESC_NONE, \
|
2011-07-26 04:13:00 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define DEFINE_RES_IO_NAMED(_start, _size, _name) \
|
|
|
|
|
DEFINE_RES_NAMED((_start), (_size), (_name), IORESOURCE_IO)
|
|
|
|
|
#define DEFINE_RES_IO(_start, _size) \
|
|
|
|
|
DEFINE_RES_IO_NAMED((_start), (_size), NULL)
|
|
|
|
|
|
|
|
|
|
#define DEFINE_RES_MEM_NAMED(_start, _size, _name) \
|
|
|
|
|
DEFINE_RES_NAMED((_start), (_size), (_name), IORESOURCE_MEM)
|
|
|
|
|
#define DEFINE_RES_MEM(_start, _size) \
|
|
|
|
|
DEFINE_RES_MEM_NAMED((_start), (_size), NULL)
|
|
|
|
|
|
|
|
|
|
#define DEFINE_RES_IRQ_NAMED(_irq, _name) \
|
|
|
|
|
DEFINE_RES_NAMED((_irq), 1, (_name), IORESOURCE_IRQ)
|
|
|
|
|
#define DEFINE_RES_IRQ(_irq) \
|
|
|
|
|
DEFINE_RES_IRQ_NAMED((_irq), NULL)
|
|
|
|
|
|
|
|
|
|
#define DEFINE_RES_DMA_NAMED(_dma, _name) \
|
|
|
|
|
DEFINE_RES_NAMED((_dma), 1, (_name), IORESOURCE_DMA)
|
|
|
|
|
#define DEFINE_RES_DMA(_dma) \
|
|
|
|
|
DEFINE_RES_DMA_NAMED((_dma), NULL)
|
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/* PC/ISA/whatever - the normal PC address spaces: IO and memory */
|
|
|
|
|
extern struct resource ioport_resource;
|
|
|
|
|
extern struct resource iomem_resource;
|
|
|
|
|
|
2010-03-12 03:01:09 +03:00
|
|
|
extern struct resource *request_resource_conflict(struct resource *root, struct resource *new);
|
2005-04-17 02:20:36 +04:00
|
|
|
extern int request_resource(struct resource *root, struct resource *new);
|
|
|
|
|
extern int release_resource(struct resource *new);
|
2009-12-23 02:02:22 +03:00
|
|
|
void release_child_resources(struct resource *new);
|
2008-09-04 23:02:44 +04:00
|
|
|
extern void reserve_region_with_split(struct resource *root,
|
|
|
|
|
resource_size_t start, resource_size_t end,
|
|
|
|
|
const char *name);
|
2010-03-12 03:01:09 +03:00
|
|
|
extern struct resource *insert_resource_conflict(struct resource *parent, struct resource *new);
|
2006-06-30 13:15:42 +04:00
|
|
|
extern int insert_resource(struct resource *parent, struct resource *new);
|
2008-08-30 07:18:31 +04:00
|
|
|
extern void insert_resource_expand_to_fit(struct resource *root, struct resource *new);
|
2016-03-09 22:47:04 +03:00
|
|
|
extern int remove_resource(struct resource *old);
|
2010-12-16 20:38:46 +03:00
|
|
|
extern void arch_remove_reservations(struct resource *avail);
|
2005-04-17 02:20:36 +04:00
|
|
|
extern int allocate_resource(struct resource *root, struct resource *new,
|
2006-06-13 03:09:23 +04:00
|
|
|
resource_size_t size, resource_size_t min,
|
|
|
|
|
resource_size_t max, resource_size_t align,
|
2010-01-01 19:40:49 +03:00
|
|
|
resource_size_t (*alignf)(void *,
|
2010-01-01 19:40:50 +03:00
|
|
|
const struct resource *,
|
2010-01-01 19:40:49 +03:00
|
|
|
resource_size_t,
|
|
|
|
|
resource_size_t),
|
2005-04-17 02:20:36 +04:00
|
|
|
void *alignf_data);
|
2011-05-07 22:53:16 +04:00
|
|
|
struct resource *lookup_resource(struct resource *root, resource_size_t start);
|
2006-06-13 03:09:23 +04:00
|
|
|
int adjust_resource(struct resource *res, resource_size_t start,
|
|
|
|
|
resource_size_t size);
|
PCI: clean up resource alignment management
Done per Linus' request and suggestions. Linus has explained that
better than I'll be able to explain:
On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
> Actually, before we go any further, there might be a less intrusive
> alternative: add just a couple of flags to the resource flags field (we
> still have something like 8 unused bits on 32-bit), and use those to
> implement a generic "resource_alignment()" routine.
>
> Two flags would do it:
>
> - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
> resources)
>
> - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
> during probing)
>
> and then the case of both flags zero (or both bits set) would actually be
> "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
> actually allocate the resource (so that we don't use the "start" field as
> alignment incorrectly when it no longer indicates alignment).
>
> That wouldn't be totally generic, but it would have the nice property of
> automatically at least add sanity checking for that whole "res->start has
> the odd meaning of 'alignment' during probing" and remove the need for a
> new field, and it would allow us to have a generic "resource_alignment()"
> routine that just gets a resource pointer.
Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-30 19:50:14 +04:00
|
|
|
resource_size_t resource_alignment(struct resource *res);
|
2009-12-16 03:48:21 +03:00
|
|
|
static inline resource_size_t resource_size(const struct resource *res)
|
2008-07-30 09:32:57 +04:00
|
|
|
{
|
|
|
|
|
return res->end - res->start + 1;
|
|
|
|
|
}
|
2009-12-16 03:48:21 +03:00
|
|
|
static inline unsigned long resource_type(const struct resource *res)
|
2008-10-16 09:05:15 +04:00
|
|
|
{
|
|
|
|
|
return res->flags & IORESOURCE_TYPE_BITS;
|
|
|
|
|
}
|
resource: Add System RAM resource type
The IORESOURCE_MEM I/O resource type is used for all types of
memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
reserved, and so on.
This requires walk_system_ram_range(), walk_system_ram_res(),
and region_intersects() to use strcmp() against string "System
RAM" to search for System RAM ranges in the iomem table, which
is inefficient. __ioremap_caller() and reserve_memtype() on x86,
for instance, call walk_system_ram_range() for every request to
check if a given range is in System RAM ranges.
However, adding a new I/O resource type for System RAM is not a
viable option, see [1]. There are approx. 3800 references to
IORESOURCE_MEM in the kernel/drivers, which makes it very
difficult to distinguish their usages between new type and
IORESOURCE_MEM.
The I/O resource types are also used by the PNP subsystem.
Therefore, introduce an extended I/O resource type,
IORESOURCE_SYSTEM_RAM, which consists of IORESOURCE_MEM and a
new modifier flag IORESOURCE_SYSRAM, see [2].
To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' still
working for System RAM, resource_ext_type() is added for
extracting extended type bits.
Link[1]: http://lkml.kernel.org/r/1449168859.9855.54.camel@hpe.com
Link[2]: http://lkml.kernel.org/r/CA+55aFy4WQrWexC4u2LxX9Mw2NVoznw7p3Yh=iF4Xtf7zKWnRw@mail.gmail.com
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Jakub Sitnicki <jsitnicki@gmail.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-arch@vger.kernel.org
Cc: linux-mm <linux-mm@kvack.org>
Link: http://lkml.kernel.org/r/1453841853-11383-2-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-26 23:57:17 +03:00
|
|
|
static inline unsigned long resource_ext_type(const struct resource *res)
|
|
|
|
|
{
|
|
|
|
|
return res->flags & IORESOURCE_EXT_TYPE_BITS;
|
|
|
|
|
}
|
2014-02-05 07:32:28 +04:00
|
|
|
/* True iff r1 completely contains r2 */
|
|
|
|
|
static inline bool resource_contains(struct resource *r1, struct resource *r2)
|
|
|
|
|
{
|
|
|
|
|
if (resource_type(r1) != resource_type(r2))
|
|
|
|
|
return false;
|
|
|
|
|
if (r1->flags & IORESOURCE_UNSET || r2->flags & IORESOURCE_UNSET)
|
|
|
|
|
return false;
|
|
|
|
|
return r1->start <= r2->start && r1->end >= r2->end;
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
|
/* Convenience shorthand with allocation */
|
2010-03-29 21:38:00 +04:00
|
|
|
#define request_region(start,n,name) __request_region(&ioport_resource, (start), (n), (name), 0)
|
|
|
|
|
#define request_muxed_region(start,n,name) __request_region(&ioport_resource, (start), (n), (name), IORESOURCE_MUXED)
|
2008-10-23 06:55:31 +04:00
|
|
|
#define __request_mem_region(start,n,name, excl) __request_region(&iomem_resource, (start), (n), (name), excl)
|
|
|
|
|
#define request_mem_region(start,n,name) __request_region(&iomem_resource, (start), (n), (name), 0)
|
|
|
|
|
#define request_mem_region_exclusive(start,n,name) \
|
|
|
|
|
__request_region(&iomem_resource, (start), (n), (name), IORESOURCE_EXCLUSIVE)
|
2005-04-17 02:20:36 +04:00
|
|
|
#define rename_region(region, newname) do { (region)->name = (newname); } while (0)
|
|
|
|
|
|
2006-06-13 03:09:23 +04:00
|
|
|
extern struct resource * __request_region(struct resource *,
|
|
|
|
|
resource_size_t start,
|
2009-01-16 00:51:01 +03:00
|
|
|
resource_size_t n,
|
|
|
|
|
const char *name, int flags);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
|
/* Compatibility cruft */
|
|
|
|
|
#define release_region(start,n) __release_region(&ioport_resource, (start), (n))
|
|
|
|
|
#define release_mem_region(start,n) __release_region(&iomem_resource, (start), (n))
|
|
|
|
|
|
2006-06-13 03:09:23 +04:00
|
|
|
extern void __release_region(struct resource *, resource_size_t,
|
|
|
|
|
resource_size_t);
|
resource: add release_mem_region_adjustable()
Add release_mem_region_adjustable(), which releases a requested region
from a currently busy memory resource. This interface adjusts the
matched memory resource accordingly even if the requested region does
not match exactly but still fits into.
This new interface is intended for memory hot-delete. During bootup,
memory resources are inserted from the boot descriptor table, such as
EFI Memory Table and e820. Each memory resource entry usually covers
the whole contigous memory range. Memory hot-delete request, on the
other hand, may target to a particular range of memory resource, and its
size can be much smaller than the whole contiguous memory. Since the
existing release interfaces like __release_region() require a requested
region to be exactly matched to a resource entry, they do not allow a
partial resource to be released.
This new interface is restrictive (i.e. release under certain
conditions), which is consistent with other release interfaces,
__release_region() and __release_resource(). Additional release
conditions, such as an overlapping region to a resource entry, can be
supported after they are confirmed as valid cases.
There is no change to the existing interfaces since their restriction is
valid for I/O resources.
[akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
[akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
[akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: T Makphaibulchoke <tmac@hp.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:19 +04:00
|
|
|
#ifdef CONFIG_MEMORY_HOTREMOVE
|
kernel/resource: make release_mem_region_adjustable() never fail
Patch series "selective merging of system ram resources", v4.
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where possible.
Resources are effectively stored in a list-based tree. Having a lot of
resources not only wastes memory, it also makes traversing that tree more
expensive, and makes /proc/iomem explode in size (e.g., requiring
kexec-tools to manually merge resources when creating a kdump header. The
current kexec-tools resource count limit does not allow for more than
~100GB of memory with a memory block size of 128MB on x86-64).
Let's allow to selectively merge system ram resources by specifying a new
flag for add_memory*(). Patch #5 contains a /proc/iomem example. Only
tested with virtio-mem.
This patch (of 8):
Let's make sure splitting a resource on memory hotunplug will never fail.
This will become more relevant once we merge selected System RAM resources
- then, we'll trigger that case more often on memory hotunplug.
In general, this function is already unlikely to fail. When we remove
memory, we free up quite a lot of metadata (memmap, page tables, memory
block device, etc.). The only reason it could really fail would be when
injecting allocation errors.
All other error cases inside release_mem_region_adjustable() seem to be
sanity checks if the function would be abused in different context - let's
add WARN_ON_ONCE() in these cases so we can catch them.
[natechancellor@gmail.com: fix use of ternary condition in release_mem_region_adjustable]
Link: https://lkml.kernel.org/r/20200922060748.2452056-1-natechancellor@gmail.com
Link: https://github.com/ClangBuiltLinux/linux/issues/1159
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>
Cc: Anton Blanchard <anton@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Leonardo Bras <leobras.c@gmail.com>
Cc: Libor Pechacek <lpechacek@suse.cz>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: "Oliver O'Halloran" <oohall@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Roger Pau Monn <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Wei Liu <wei.liu@kernel.org>
Link: https://lkml.kernel.org/r/20200911103459.10306-2-david@redhat.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 06:08:28 +03:00
|
|
|
extern void release_mem_region_adjustable(struct resource *, resource_size_t,
|
|
|
|
|
resource_size_t);
|
resource: add release_mem_region_adjustable()
Add release_mem_region_adjustable(), which releases a requested region
from a currently busy memory resource. This interface adjusts the
matched memory resource accordingly even if the requested region does
not match exactly but still fits into.
This new interface is intended for memory hot-delete. During bootup,
memory resources are inserted from the boot descriptor table, such as
EFI Memory Table and e820. Each memory resource entry usually covers
the whole contigous memory range. Memory hot-delete request, on the
other hand, may target to a particular range of memory resource, and its
size can be much smaller than the whole contiguous memory. Since the
existing release interfaces like __release_region() require a requested
region to be exactly matched to a resource entry, they do not allow a
partial resource to be released.
This new interface is restrictive (i.e. release under certain
conditions), which is consistent with other release interfaces,
__release_region() and __release_resource(). Additional release
conditions, such as an overlapping region to a resource entry, can be
supported after they are confirmed as valid cases.
There is no change to the existing interfaces since their restriction is
valid for I/O resources.
[akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
[akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
[akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: T Makphaibulchoke <tmac@hp.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:19 +04:00
|
|
|
#endif
|
2005-04-17 02:20:36 +04:00
|
|
|
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
|
|
|
/* Wrappers for managed devices */
|
|
|
|
|
struct device;
|
2014-08-01 16:15:10 +04:00
|
|
|
|
|
|
|
|
extern int devm_request_resource(struct device *dev, struct resource *root,
|
|
|
|
|
struct resource *new);
|
|
|
|
|
extern void devm_release_resource(struct device *dev, struct resource *new);
|
|
|
|
|
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
|
|
|
#define devm_request_region(dev,start,n,name) \
|
|
|
|
|
__devm_request_region(dev, &ioport_resource, (start), (n), (name))
|
|
|
|
|
#define devm_request_mem_region(dev,start,n,name) \
|
|
|
|
|
__devm_request_region(dev, &iomem_resource, (start), (n), (name))
|
|
|
|
|
|
|
|
|
|
extern struct resource * __devm_request_region(struct device *dev,
|
|
|
|
|
struct resource *parent, resource_size_t start,
|
|
|
|
|
resource_size_t n, const char *name);
|
|
|
|
|
|
2008-09-13 13:33:07 +04:00
|
|
|
#define devm_release_region(dev, start, n) \
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
|
|
|
__devm_release_region(dev, &ioport_resource, (start), (n))
|
2008-09-13 13:33:07 +04:00
|
|
|
#define devm_release_mem_region(dev, start, n) \
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
|
|
|
__devm_release_region(dev, &iomem_resource, (start), (n))
|
|
|
|
|
|
|
|
|
|
extern void __devm_release_region(struct device *dev, struct resource *parent,
|
|
|
|
|
resource_size_t start, resource_size_t n);
|
2008-09-26 05:43:34 +04:00
|
|
|
extern int iomem_map_sanity_check(resource_size_t addr, unsigned long size);
|
2018-02-07 02:41:28 +03:00
|
|
|
extern bool iomem_is_exclusive(u64 addr);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
|
|
|
|
2009-09-23 03:45:46 +04:00
|
|
|
extern int
|
|
|
|
|
walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
|
|
|
|
|
void *arg, int (*func)(unsigned long, unsigned long, void *));
|
2014-08-09 01:25:50 +04:00
|
|
|
extern int
|
2017-10-20 17:30:52 +03:00
|
|
|
walk_mem_res(u64 start, u64 end, void *arg,
|
|
|
|
|
int (*func)(struct resource *, void *));
|
|
|
|
|
extern int
|
2014-08-09 01:25:50 +04:00
|
|
|
walk_system_ram_res(u64 start, u64 end, void *arg,
|
2017-10-20 17:30:51 +03:00
|
|
|
int (*func)(struct resource *, void *));
|
2014-08-09 01:25:50 +04:00
|
|
|
extern int
|
2016-01-26 23:57:29 +03:00
|
|
|
walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 end,
|
2017-10-20 17:30:51 +03:00
|
|
|
void *arg, int (*func)(struct resource *, void *));
|
2009-09-23 03:45:46 +04:00
|
|
|
|
2012-04-26 11:32:55 +04:00
|
|
|
/* True if any part of r1 overlaps r2 */
|
|
|
|
|
static inline bool resource_overlaps(struct resource *r1, struct resource *r2)
|
|
|
|
|
{
|
|
|
|
|
return (r1->start <= r2->end && r1->end >= r2->start);
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-26 15:27:06 +03:00
|
|
|
struct resource *devm_request_free_mem_region(struct device *dev,
|
|
|
|
|
struct resource *base, unsigned long size);
|
2019-08-18 12:05:54 +03:00
|
|
|
struct resource *request_free_mem_region(struct resource *base,
|
|
|
|
|
unsigned long size, const char *name);
|
2012-04-26 11:32:55 +04:00
|
|
|
|
2020-05-22 00:06:17 +03:00
|
|
|
#ifdef CONFIG_IO_STRICT_DEVMEM
|
|
|
|
|
void revoke_devmem(struct resource *res);
|
|
|
|
|
#else
|
|
|
|
|
static inline void revoke_devmem(struct resource *res) { };
|
|
|
|
|
#endif
|
|
|
|
|
|
2008-01-30 15:30:32 +03:00
|
|
|
#endif /* __ASSEMBLY__ */
|
2005-04-17 02:20:36 +04:00
|
|
|
#endif /* _LINUX_IOPORT_H */
|
