Merge d652502ef4 Merge tag 'ovl-update-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs into android-mainline

A tiny step en route to v5.13-rc1

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I049e80976042ebffc90bb080f09da0afcfd48d77
This commit is contained in:
Lee Jones
2021-05-12 15:54:32 +01:00
1192 changed files with 54942 additions and 15327 deletions

View File

@@ -5000,6 +5000,10 @@
slram= [HW,MTD]
slab_merge [MM]
Enable merging of slabs with similar size when the
kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
slab_nomerge [MM]
Disable merging of slabs with similar size. May be
necessary if there is some reason to distinguish
@@ -5047,6 +5051,9 @@
lower than slub_max_order.
For more information see Documentation/vm/slub.rst.
slub_merge [MM, SLUB]
Same with slab_merge.
slub_nomerge [MM, SLUB]
Same with slab_nomerge. This is supported for legacy.
See slab_nomerge for more information.

View File

@@ -402,7 +402,7 @@ compact_fail
but failed.
It is possible to establish how long the stalls were using the function
tracer to record how long was spent in __alloc_pages_nodemask and
tracer to record how long was spent in __alloc_pages() and
using the mm_page_alloc tracepoint to identify which allocations were
for huge pages.

View File

@@ -64,6 +64,7 @@ two flavors of JITs, the newer eBPF JIT currently supported on:
- arm64
- arm32
- ppc64
- ppc32
- sparc64
- mips64
- s390x
@@ -73,7 +74,6 @@ two flavors of JITs, the newer eBPF JIT currently supported on:
And the older cBPF JIT supported on the following archs:
- mips
- ppc
- sparc
eBPF JITs are a superset of cBPF JITs, meaning the kernel will

View File

@@ -213,9 +213,9 @@ Here are the routines, one by one:
there will be no entries in the cache for the kernel address
space for virtual addresses in the range 'start' to 'end-1'.
The first of these two routines is invoked after map_kernel_range()
The first of these two routines is invoked after vmap_range()
has installed the page table entries. The second is invoked
before unmap_kernel_range() deletes the page table entries.
before vunmap_range() deletes the page table entries.
There exists another whole class of cpu cache issues which currently
require a whole different set of interfaces to handle properly.

View File

@@ -92,3 +92,9 @@ More Memory Management Functions
:export:
.. kernel-doc:: mm/page_alloc.c
.. kernel-doc:: mm/mempolicy.c
.. kernel-doc:: include/linux/mm_types.h
:internal:
.. kernel-doc:: include/linux/mm.h
:internal:
.. kernel-doc:: include/linux/mmzone.h

View File

@@ -11,46 +11,56 @@ designed to find out-of-bound and use-after-free bugs. KASAN has three modes:
2. software tag-based KASAN (similar to userspace HWASan),
3. hardware tag-based KASAN (based on hardware memory tagging).
Software KASAN modes (1 and 2) use compile-time instrumentation to insert
validity checks before every memory access, and therefore require a compiler
Generic KASAN is mainly used for debugging due to a large memory overhead.
Software tag-based KASAN can be used for dogfood testing as it has a lower
memory overhead that allows using it with real workloads. Hardware tag-based
KASAN comes with low memory and performance overheads and, therefore, can be
used in production. Either as an in-field memory bug detector or as a security
mitigation.
Software KASAN modes (#1 and #2) use compile-time instrumentation to insert
validity checks before every memory access and, therefore, require a compiler
version that supports that.
Generic KASAN is supported in both GCC and Clang. With GCC it requires version
Generic KASAN is supported in GCC and Clang. With GCC, it requires version
8.3.0 or later. Any supported Clang version is compatible, but detection of
out-of-bounds accesses for global variables is only supported since Clang 11.
Tag-based KASAN is only supported in Clang.
Software tag-based KASAN mode is only supported in Clang.
Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and
riscv architectures, and tag-based KASAN is supported only for arm64.
The hardware KASAN mode (#3) relies on hardware to perform the checks but
still requires a compiler version that supports memory tagging instructions.
This mode is supported in GCC 10+ and Clang 11+.
Both software KASAN modes work with SLUB and SLAB memory allocators,
while the hardware tag-based KASAN currently only supports SLUB.
Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390,
and riscv architectures, and tag-based KASAN is supported only for arm64.
Usage
-----
To enable KASAN configure kernel with::
To enable KASAN, configure the kernel with::
CONFIG_KASAN = y
CONFIG_KASAN=y
and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN),
CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN), and
CONFIG_KASAN_HW_TAGS (to enable hardware tag-based KASAN).
and choose between ``CONFIG_KASAN_GENERIC`` (to enable generic KASAN),
``CONFIG_KASAN_SW_TAGS`` (to enable software tag-based KASAN), and
``CONFIG_KASAN_HW_TAGS`` (to enable hardware tag-based KASAN).
For software modes, you also need to choose between CONFIG_KASAN_OUTLINE and
CONFIG_KASAN_INLINE. Outline and inline are compiler instrumentation types.
The former produces smaller binary while the latter is 1.1 - 2 times faster.
For software modes, also choose between ``CONFIG_KASAN_OUTLINE`` and
``CONFIG_KASAN_INLINE``. Outline and inline are compiler instrumentation types.
The former produces a smaller binary while the latter is 1.1-2 times faster.
Both software KASAN modes work with both SLUB and SLAB memory allocators,
while the hardware tag-based KASAN currently only support SLUB.
For better error reports that include stack traces, enable CONFIG_STACKTRACE.
To augment reports with last allocation and freeing stack of the physical page,
it is recommended to enable also CONFIG_PAGE_OWNER and boot with page_owner=on.
To include alloc and free stack traces of affected slab objects into reports,
enable ``CONFIG_STACKTRACE``. To include alloc and free stack traces of affected
physical pages, enable ``CONFIG_PAGE_OWNER`` and boot with ``page_owner=on``.
Error reports
~~~~~~~~~~~~~
A typical out-of-bounds access generic KASAN report looks like this::
A typical KASAN report looks like this::
==================================================================
BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan]
@@ -123,41 +133,57 @@ A typical out-of-bounds access generic KASAN report looks like this::
ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==================================================================
The header of the report provides a short summary of what kind of bug happened
and what kind of access caused it. It's followed by a stack trace of the bad
access, a stack trace of where the accessed memory was allocated (in case bad
access happens on a slab object), and a stack trace of where the object was
freed (in case of a use-after-free bug report). Next comes a description of
the accessed slab object and information about the accessed memory page.
The report header summarizes what kind of bug happened and what kind of access
caused it. It is followed by a stack trace of the bad access, a stack trace of
where the accessed memory was allocated (in case a slab object was accessed),
and a stack trace of where the object was freed (in case of a use-after-free
bug report). Next comes a description of the accessed slab object and the
information about the accessed memory page.
In the last section the report shows memory state around the accessed address.
Internally KASAN tracks memory state separately for each memory granule, which
In the end, the report shows the memory state around the accessed address.
Internally, KASAN tracks memory state separately for each memory granule, which
is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the
memory state section of the report shows the state of one of the memory
granules that surround the accessed address.
For generic KASAN the size of each memory granule is 8. The state of each
For generic KASAN, the size of each memory granule is 8. The state of each
granule is encoded in one shadow byte. Those 8 bytes can be accessible,
partially accessible, freed or be a part of a redzone. KASAN uses the following
encoding for each shadow byte: 0 means that all 8 bytes of the corresponding
partially accessible, freed, or be a part of a redzone. KASAN uses the following
encoding for each shadow byte: 00 means that all 8 bytes of the corresponding
memory region are accessible; number N (1 <= N <= 7) means that the first N
bytes are accessible, and other (8 - N) bytes are not; any negative value
indicates that the entire 8-byte word is inaccessible. KASAN uses different
negative values to distinguish between different kinds of inaccessible memory
like redzones or freed memory (see mm/kasan/kasan.h).
In the report above the arrows point to the shadow byte 03, which means that
the accessed address is partially accessible. For tag-based KASAN modes this
last report section shows the memory tags around the accessed address
(see the `Implementation details`_ section).
In the report above, the arrow points to the shadow byte ``03``, which means
that the accessed address is partially accessible.
For tag-based KASAN modes, this last report section shows the memory tags around
the accessed address (see the `Implementation details`_ section).
Note that KASAN bug titles (like ``slab-out-of-bounds`` or ``use-after-free``)
are best-effort: KASAN prints the most probable bug type based on the limited
information it has. The actual type of the bug might be different.
Generic KASAN also reports up to two auxiliary call stack traces. These stack
traces point to places in code that interacted with the object but that are not
directly present in the bad access stack trace. Currently, this includes
call_rcu() and workqueue queuing.
Boot parameters
~~~~~~~~~~~~~~~
KASAN is affected by the generic ``panic_on_warn`` command line parameter.
When it is enabled, KASAN panics the kernel after printing a bug report.
By default, KASAN prints a bug report only for the first invalid memory access.
With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
effectively disables ``panic_on_warn`` for KASAN reports.
Hardware tag-based KASAN mode (see the section about various modes below) is
intended for use in production as a security mitigation. Therefore, it supports
boot parameters that allow to disable KASAN competely or otherwise control
particular KASAN features.
boot parameters that allow disabling KASAN or controlling its features.
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
@@ -174,26 +200,8 @@ particular KASAN features.
traces collection (default: ``on``).
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
report or also panic the kernel (default: ``report``). Note, that tag
checking gets disabled after the first reported bug.
For developers
~~~~~~~~~~~~~~
Software KASAN modes use compiler instrumentation to insert validity checks.
Such instrumentation might be incompatible with some part of the kernel, and
therefore needs to be disabled. To disable instrumentation for specific files
or directories, add a line similar to the following to the respective kernel
Makefile:
- For a single file (e.g. main.o)::
KASAN_SANITIZE_main.o := n
- For all files in one directory::
KASAN_SANITIZE := n
report or also panic the kernel (default: ``report``). The panic happens even
if ``kasan_multi_shot`` is enabled.
Implementation details
----------------------
@@ -201,12 +209,11 @@ Implementation details
Generic KASAN
~~~~~~~~~~~~~
From a high level perspective, KASAN's approach to memory error detection is
similar to that of kmemcheck: use shadow memory to record whether each byte of
memory is safe to access, and use compile-time instrumentation to insert checks
of shadow memory on each memory access.
Software KASAN modes use shadow memory to record whether each byte of memory is
safe to access and use compile-time instrumentation to insert shadow memory
checks before each memory access.
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (16TB
to cover 128TB on x86_64) and uses direct mapping with a scale and offset to
translate a memory address to its corresponding shadow address.
@@ -215,113 +222,105 @@ address::
static inline void *kasan_mem_to_shadow(const void *addr)
{
return ((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
+ KASAN_SHADOW_OFFSET;
}
where ``KASAN_SHADOW_SCALE_SHIFT = 3``.
Compile-time instrumentation is used to insert memory access checks. Compiler
inserts function calls (__asan_load*(addr), __asan_store*(addr)) before each
memory access of size 1, 2, 4, 8 or 16. These functions check whether memory
access is valid or not by checking corresponding shadow memory.
inserts function calls (``__asan_load*(addr)``, ``__asan_store*(addr)``) before
each memory access of size 1, 2, 4, 8, or 16. These functions check whether
memory accesses are valid or not by checking corresponding shadow memory.
GCC 5.0 has possibility to perform inline instrumentation. Instead of making
function calls GCC directly inserts the code to check the shadow memory.
This option significantly enlarges kernel but it gives x1.1-x2 performance
boost over outline instrumented kernel.
With inline instrumentation, instead of making function calls, the compiler
directly inserts the code to check shadow memory. This option significantly
enlarges the kernel, but it gives an x1.1-x2 performance boost over the
outline-instrumented kernel.
Generic KASAN also reports the last 2 call stacks to creation of work that
potentially has access to an object. Call stacks for the following are shown:
call_rcu() and workqueue queuing.
Generic KASAN is the only mode that delays the reuse of freed object via
Generic KASAN is the only mode that delays the reuse of freed objects via
quarantine (see mm/kasan/quarantine.c for implementation).
Software tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Software tag-based KASAN requires software memory tagging support in the form
of HWASan-like compiler instrumentation (see HWASan documentation for details).
Software tag-based KASAN is currently only implemented for arm64 architecture.
Software tag-based KASAN uses a software memory tagging approach to checking
access validity. It is currently only implemented for the arm64 architecture.
Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
to store a pointer tag in the top byte of kernel pointers. Like generic KASAN
it uses shadow memory to store memory tags associated with each 16-byte memory
cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
to store memory tags associated with each 16-byte memory cell (therefore, it
dedicates 1/16th of the kernel memory for shadow memory).
On each memory allocation software tag-based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds this tag into the returned
On each memory allocation, software tag-based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds the same tag into the returned
pointer.
Software tag-based KASAN uses compile-time instrumentation to insert checks
before each memory access. These checks make sure that tag of the memory that
is being accessed is equal to tag of the pointer that is used to access this
memory. In case of a tag mismatch software tag-based KASAN prints a bug report.
before each memory access. These checks make sure that the tag of the memory
that is being accessed is equal to the tag of the pointer that is used to access
this memory. In case of a tag mismatch, software tag-based KASAN prints a bug
report.
Software tag-based KASAN also has two instrumentation modes (outline, that
emits callbacks to check memory accesses; and inline, that performs the shadow
Software tag-based KASAN also has two instrumentation modes (outline, which
emits callbacks to check memory accesses; and inline, which performs the shadow
memory checks inline). With outline instrumentation mode, a bug report is
simply printed from the function that performs the access check. With inline
instrumentation a brk instruction is emitted by the compiler, and a dedicated
brk handler is used to print bug reports.
printed from the function that performs the access check. With inline
instrumentation, a ``brk`` instruction is emitted by the compiler, and a
dedicated ``brk`` handler is used to print bug reports.
Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
Software tag-based KASAN currently only supports tagging of
kmem_cache_alloc/kmalloc and page_alloc memory.
Software tag-based KASAN currently only supports tagging of slab and page_alloc
memory.
Hardware tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Hardware tag-based KASAN is similar to the software mode in concept, but uses
Hardware tag-based KASAN is similar to the software mode in concept but uses
hardware memory tagging support instead of compiler instrumentation and
shadow memory.
Hardware tag-based KASAN is currently only implemented for arm64 architecture
and based on both arm64 Memory Tagging Extension (MTE) introduced in ARMv8.5
Instruction Set Architecture, and Top Byte Ignore (TBI).
Instruction Set Architecture and Top Byte Ignore (TBI).
Special arm64 instructions are used to assign memory tags for each allocation.
Same tags are assigned to pointers to those allocations. On every memory
access, hardware makes sure that tag of the memory that is being accessed is
equal to tag of the pointer that is used to access this memory. In case of a
tag mismatch a fault is generated and a report is printed.
access, hardware makes sure that the tag of the memory that is being accessed is
equal to the tag of the pointer that is used to access this memory. In case of a
tag mismatch, a fault is generated, and a report is printed.
Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
Hardware tag-based KASAN currently only supports tagging of
kmem_cache_alloc/kmalloc and page_alloc memory.
Hardware tag-based KASAN currently only supports tagging of slab and page_alloc
memory.
If the hardware doesn't support MTE (pre ARMv8.5), hardware tag-based KASAN
won't be enabled. In this case all boot parameters are ignored.
If the hardware does not support MTE (pre ARMv8.5), hardware tag-based KASAN
will not be enabled. In this case, all KASAN boot parameters are ignored.
Note, that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
enabled. Even when kasan.mode=off is provided, or when the hardware doesn't
Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not
support MTE (but supports TBI).
Hardware tag-based KASAN only reports the first found bug. After that MTE tag
Hardware tag-based KASAN only reports the first found bug. After that, MTE tag
checking gets disabled.
What memory accesses are sanitised by KASAN?
--------------------------------------------
Shadow memory
-------------
The kernel maps memory in a number of different parts of the address
space. This poses something of a problem for KASAN, which requires
that all addresses accessed by instrumented code have a valid shadow
region.
The kernel maps memory in several different parts of the address space.
The range of kernel virtual addresses is large: there is not enough real
memory to support a real shadow region for every address that could be
accessed by the kernel. Therefore, KASAN only maps real shadow for certain
parts of the address space.
The range of kernel virtual addresses is large: there is not enough
real memory to support a real shadow region for every address that
could be accessed by the kernel.
By default
~~~~~~~~~~
Default behaviour
~~~~~~~~~~~~~~~~~
By default, architectures only map real memory over the shadow region
for the linear mapping (and potentially other small areas). For all
@@ -330,10 +329,9 @@ page is mapped over the shadow area. This read-only shadow page
declares all memory accesses as permitted.
This presents a problem for modules: they do not live in the linear
mapping, but in a dedicated module space. By hooking in to the module
allocator, KASAN can temporarily map real shadow memory to cover
them. This allows detection of invalid accesses to module globals, for
example.
mapping but in a dedicated module space. By hooking into the module
allocator, KASAN temporarily maps real shadow memory to cover them.
This allows detection of invalid accesses to module globals, for example.
This also creates an incompatibility with ``VMAP_STACK``: if the stack
lives in vmalloc space, it will be shadowed by the read-only page, and
@@ -344,9 +342,10 @@ CONFIG_KASAN_VMALLOC
~~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the
cost of greater memory usage. Currently this is only supported on x86.
cost of greater memory usage. Currently, this is supported on x86,
riscv, s390, and powerpc.
This works by hooking into vmalloc and vmap, and dynamically
This works by hooking into vmalloc and vmap and dynamically
allocating real shadow memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
@@ -365,28 +364,76 @@ memory.
To avoid the difficulties around swapping mappings around, KASAN expects
that the part of the shadow region that covers the vmalloc space will
not be covered by the early shadow page, but will be left
unmapped. This will require changes in arch-specific code.
not be covered by the early shadow page but will be left unmapped.
This will require changes in arch-specific code.
This allows ``VMAP_STACK`` support on x86, and can simplify support of
This allows ``VMAP_STACK`` support on x86 and can simplify support of
architectures that do not have a fixed module region.
CONFIG_KASAN_KUNIT_TEST and CONFIG_KASAN_MODULE_TEST
----------------------------------------------------
For developers
--------------
KASAN tests consist of two parts:
Ignoring accesses
~~~~~~~~~~~~~~~~~
Software KASAN modes use compiler instrumentation to insert validity checks.
Such instrumentation might be incompatible with some parts of the kernel, and
therefore needs to be disabled.
Other parts of the kernel might access metadata for allocated objects.
Normally, KASAN detects and reports such accesses, but in some cases (e.g.,
in memory allocators), these accesses are valid.
For software KASAN modes, to disable instrumentation for a specific file or
directory, add a ``KASAN_SANITIZE`` annotation to the respective kernel
Makefile:
- For a single file (e.g., main.o)::
KASAN_SANITIZE_main.o := n
- For all files in one directory::
KASAN_SANITIZE := n
For software KASAN modes, to disable instrumentation on a per-function basis,
use the KASAN-specific ``__no_sanitize_address`` function attribute or the
generic ``noinstr`` one.
Note that disabling compiler instrumentation (either on a per-file or a
per-function basis) makes KASAN ignore the accesses that happen directly in
that code for software KASAN modes. It does not help when the accesses happen
indirectly (through calls to instrumented functions) or with the hardware
tag-based mode that does not use compiler instrumentation.
For software KASAN modes, to disable KASAN reports in a part of the kernel code
for the current task, annotate this part of the code with a
``kasan_disable_current()``/``kasan_enable_current()`` section. This also
disables the reports for indirect accesses that happen through function calls.
For tag-based KASAN modes (include the hardware one), to disable access
checking, use ``kasan_reset_tag()`` or ``page_kasan_tag_reset()``. Note that
temporarily disabling access checking via ``page_kasan_tag_reset()`` requires
saving and restoring the per-page KASAN tag via
``page_kasan_tag``/``page_kasan_tag_set``.
Tests
~~~~~
There are KASAN tests that allow verifying that KASAN works and can detect
certain types of memory corruptions. The tests consist of two parts:
1. Tests that are integrated with the KUnit Test Framework. Enabled with
``CONFIG_KASAN_KUNIT_TEST``. These tests can be run and partially verified
automatically in a few different ways, see the instructions below.
automatically in a few different ways; see the instructions below.
2. Tests that are currently incompatible with KUnit. Enabled with
``CONFIG_KASAN_MODULE_TEST`` and can only be run as a module. These tests can
only be verified manually, by loading the kernel module and inspecting the
only be verified manually by loading the kernel module and inspecting the
kernel log for KASAN reports.
Each KUnit-compatible KASAN test prints a KASAN report if an error is detected.
Then the test prints its number and status.
Each KUnit-compatible KASAN test prints one of multiple KASAN reports if an
error is detected. Then the test prints its number and status.
When a test passes::
@@ -414,30 +461,24 @@ Or, if one of the tests failed::
not ok 1 - kasan
There are a few ways to run KUnit-compatible KASAN tests.
1. Loadable module
~~~~~~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` enabled, ``CONFIG_KASAN_KUNIT_TEST`` can be built as
a loadable module and run on any architecture that supports KASAN by loading
the module with insmod or modprobe. The module is called ``test_kasan``.
With ``CONFIG_KUNIT`` enabled, KASAN-KUnit tests can be built as a loadable
module and run by loading ``test_kasan.ko`` with ``insmod`` or ``modprobe``.
2. Built-In
~~~~~~~~~~~
With ``CONFIG_KUNIT`` built-in, ``CONFIG_KASAN_KUNIT_TEST`` can be built-in
on any architecure that supports KASAN. These and any other KUnit tests enabled
will run and print the results at boot as a late-init call.
With ``CONFIG_KUNIT`` built-in, KASAN-KUnit tests can be built-in as well.
In this case, the tests will run at boot as a late-init call.
3. Using kunit_tool
~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, it's also
possible use ``kunit_tool`` to see the results of these and other KUnit tests
in a more readable way. This will not print the KASAN reports of the tests that
passed. Use `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
for more up-to-date information on ``kunit_tool``.
With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, it is also
possible to use ``kunit_tool`` to see the results of KUnit tests in a more
readable way. This will not print the KASAN reports of the tests that passed.
See `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
for more up-to-date information on ``kunit_tool``.
.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html

View File

@@ -142,8 +142,8 @@ mpp50 50 gpio, ge1(rxclk), mss_i2c(sda), spi1(csn0), uart2(txd), uart0(rxd), xg(
mpp51 51 gpio, ge1(rxd0), mss_i2c(sck), spi1(csn1), uart2(rxd), uart0(cts), sdio(pwr10)
mpp52 52 gpio, ge1(rxd1), synce1(clk), synce2(clk), spi1(csn2), uart1(cts), led(clk), pcie(rstoutn), pcie0(clkreq)
mpp53 53 gpio, ge1(rxd2), ptp(clk), spi1(csn3), uart1(rxd), led(stb), sdio(led)
mpp54 54 gpio, ge1(rxd3), synce2(clk), ptp(pclk_out), synce1(clk), led(data), sdio(hw_rst), sdio(wr_protect)
mpp55 55 gpio, ge1(rxctl_rxdv), ptp(pulse), sdio(led), sdio(card_detect)
mpp54 54 gpio, ge1(rxd3), synce2(clk), ptp(pclk_out), synce1(clk), led(data), sdio(hw_rst), sdio_wp(wr_protect)
mpp55 55 gpio, ge1(rxctl_rxdv), ptp(pulse), sdio(led), sdio_cd(card_detect)
mpp56 56 gpio, tdm(drx), au(i2sdo_spdifo), spi0(clk), uart1(rxd), sata1(present_act), sdio(clk)
mpp57 57 gpio, mss_i2c(sda), ptp(pclk_out), tdm(intn), au(i2sbclk), spi0(mosi), uart1(txd), sata0(present_act), sdio(cmd)
mpp58 58 gpio, mss_i2c(sck), ptp(clk), tdm(rstn), au(i2sdi), spi0(miso), uart1(cts), led(clk), sdio(d0)

View File

@@ -1,46 +0,0 @@
Bindings for the Broadcom's brcm,bcm6345-gpio memory-mapped GPIO controllers.
These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
are the only ones which don't need a pinctrl driver.
BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
Required properties:
- compatible: should be "brcm,bcm6345-gpio"
- reg-names: must contain
"dat" - data register
"dirout" - direction (output) register
- reg: address + size pairs describing the GPIO register sets;
order must correspond with the order of entries in reg-names
- #gpio-cells: must be set to 2. The first cell is the pin number and
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- gpio-controller: Marks the device node as a gpio controller.
Optional properties:
- native-endian: use native endian memory.
Examples:
- BCM6338:
gpio: gpio-controller@fffe0407 {
compatible = "brcm,bcm6345-gpio";
reg-names = "dirout", "dat";
reg = <0xfffe0407 1>, <0xfffe040f 1>;
#gpio-cells = <2>;
gpio-controller;
};
- BCM6345:
gpio: gpio-controller@fffe0406 {
compatible = "brcm,bcm6345-gpio";
reg-names = "dirout", "dat";
reg = <0xfffe0406 2>, <0xfffe040a 2>;
native-endian;
#gpio-cells = <2>;
gpio-controller;
};

View File

@@ -0,0 +1,86 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6345 GPIO controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description: |+
Bindings for Broadcom's BCM63xx memory-mapped GPIO controllers.
These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
are the only ones which don't need a pinctrl driver.
BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
and dirout registers, where GPIO state can be read and/or written, and the
direction changed from input to output.
properties:
compatible:
enum:
- brcm,bcm6318-gpio
- brcm,bcm6328-gpio
- brcm,bcm6345-gpio
- brcm,bcm6358-gpio
- brcm,bcm6362-gpio
- brcm,bcm6368-gpio
- brcm,bcm63268-gpio
gpio-controller: true
"#gpio-cells":
const: 2
gpio-ranges:
maxItems: 1
native-endian: true
reg:
maxItems: 2
reg-names:
items:
- const: dirout
- const: dat
required:
- compatible
- reg
- reg-names
- gpio-controller
- '#gpio-cells'
additionalProperties: false
examples:
- |
gpio@fffe0406 {
compatible = "brcm,bcm6345-gpio";
reg-names = "dirout", "dat";
reg = <0xfffe0406 2>, <0xfffe040a 2>;
native-endian;
gpio-controller;
#gpio-cells = <2>;
};
- |
gpio@0 {
compatible = "brcm,bcm63268-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 52>;
#gpio-cells = <2>;
};

View File

@@ -1,62 +0,0 @@
* I2C
Required properties :
- reg : Offset and length of the register set for the device
- compatible : should be "fsl,CHIP-i2c" where CHIP is the name of a
compatible processor, e.g. mpc8313, mpc8543, mpc8544, mpc5121,
mpc5200 or mpc5200b. For the mpc5121, an additional node
"fsl,mpc5121-i2c-ctrl" is required as shown in the example below.
Recommended properties :
- interrupts : <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and level
information for the interrupt. This should be encoded based on
the information in section 2) depending on the type of interrupt
controller you have.
- fsl,preserve-clocking : boolean; if defined, the clock settings
from the bootloader are preserved (not touched).
- clock-frequency : desired I2C bus clock frequency in Hz.
- fsl,timeout : I2C bus timeout in microseconds.
Examples :
/* MPC5121 based board */
i2c@1740 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5121-i2c", "fsl-i2c";
reg = <0x1740 0x20>;
interrupts = <11 0x8>;
interrupt-parent = <&ipic>;
clock-frequency = <100000>;
};
i2ccontrol@1760 {
compatible = "fsl,mpc5121-i2c-ctrl";
reg = <0x1760 0x8>;
};
/* MPC5200B based board */
i2c@3d00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <0x3d00 0x40>;
interrupts = <2 15 0>;
interrupt-parent = <&mpc5200_pic>;
fsl,preserve-clocking;
};
/* MPC8544 base board */
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8544-i2c", "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <400000>;
fsl,timeout = <10000>;
};

View File

@@ -0,0 +1,91 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-mpc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: I2C-Bus adapter for MPC824x/83xx/85xx/86xx/512x/52xx SoCs
maintainers:
- Chris Packham <chris.packham@alliedtelesis.co.nz>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- mpc5200-i2c
- fsl,mpc5200-i2c
- fsl,mpc5121-i2c
- fsl,mpc8313-i2c
- fsl,mpc8543-i2c
- fsl,mpc8544-i2c
- const: fsl-i2c
- items:
- const: fsl,mpc5200b-i2c
- const: fsl,mpc5200-i2c
- const: fsl-i2c
reg:
maxItems: 1
interrupts:
maxItems: 1
fsl,preserve-clocking:
$ref: /schemas/types.yaml#/definitions/flag
description: |
if defined, the clock settings from the bootloader are
preserved (not touched)
fsl,timeout:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
I2C bus timeout in microseconds
required:
- compatible
- reg
- interrupts
unevaluatedProperties: false
examples:
- |
/* MPC5121 based board */
i2c@1740 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5121-i2c", "fsl-i2c";
reg = <0x1740 0x20>;
interrupts = <11 0x8>;
interrupt-parent = <&ipic>;
clock-frequency = <100000>;
};
/* MPC5200B based board */
i2c@3d00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
reg = <0x3d00 0x40>;
interrupts = <2 15 0>;
interrupt-parent = <&mpc5200_pic>;
fsl,preserve-clocking;
};
/* MPC8544 base board */
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8544-i2c", "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <400000>;
fsl,timeout = <10000>;
};
...

View File

@@ -0,0 +1,177 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6318-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6318 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6318 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6318-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6318-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@10000080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6318-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x10000080 0x80>;
ranges = <0 0x10000080 0x80>;
gpio@0 {
compatible = "brcm,bcm6318-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 50>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@10 {
compatible = "brcm,bcm6318-pinctrl";
reg = <0x18 0x10>, <0x54 0x18>;
pinctrl_ephy0_spd_led: ephy0_spd_led-pins {
function = "ephy0_spd_led";
pins = "gpio0";
};
pinctrl_ephy1_spd_led: ephy1_spd_led-pins {
function = "ephy1_spd_led";
pins = "gpio1";
};
pinctrl_ephy2_spd_led: ephy2_spd_led-pins {
function = "ephy2_spd_led";
pins = "gpio2";
};
pinctrl_ephy3_spd_led: ephy3_spd_led-pins {
function = "ephy3_spd_led";
pins = "gpio3";
};
pinctrl_ephy0_act_led: ephy0_act_led-pins {
function = "ephy0_act_led";
pins = "gpio4";
};
pinctrl_ephy1_act_led: ephy1_act_led-pins {
function = "ephy1_act_led";
pins = "gpio5";
};
pinctrl_ephy2_act_led: ephy2_act_led-pins {
function = "ephy2_act_led";
pins = "gpio6";
};
pinctrl_ephy3_act_led: ephy3_act_led-pins {
function = "ephy3_act_led";
pins = "gpio7";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio6";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio7";
};
};
pinctrl_inet_act_led: inet_act_led-pins {
function = "inet_act_led";
pins = "gpio8";
};
pinctrl_inet_fail_led: inet_fail_led-pins {
function = "inet_fail_led";
pins = "gpio9";
};
pinctrl_dsl_led: dsl_led-pins {
function = "dsl_led";
pins = "gpio10";
};
pinctrl_post_fail_led: post_fail_led-pins {
function = "post_fail_led";
pins = "gpio11";
};
pinctrl_wlan_wps_led: wlan_wps_led-pins {
function = "wlan_wps_led";
pins = "gpio12";
};
pinctrl_usb_pwron: usb_pwron-pins {
function = "usb_pwron";
pins = "gpio13";
};
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio13";
};
pinctrl_usb_active: usb_active-pins {
function = "usb_active";
pins = "gpio40";
};
};
};

View File

@@ -0,0 +1,194 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm63268-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM63268 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM63268 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm63268-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm63268-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@100000c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm63268-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x100000c0 0x80>;
ranges = <0 0x100000c0 0x80>;
gpio@0 {
compatible = "brcm,bcm63268-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 52>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@10 {
compatible = "brcm,bcm63268-pinctrl";
reg = <0x10 0x4>, <0x18 0x8>, <0x38 0x4>;
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio0";
};
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio1";
};
};
pinctrl_hsspi_cs4: hsspi_cs4-pins {
function = "hsspi_cs4";
pins = "gpio16";
};
pinctrl_hsspi_cs5: hsspi_cs5-pins {
function = "hsspi_cs5";
pins = "gpio17";
};
pinctrl_hsspi_cs6: hsspi_cs6-pins {
function = "hsspi_cs6";
pins = "gpio8";
};
pinctrl_hsspi_cs7: hsspi_cs7-pins {
function = "hsspi_cs7";
pins = "gpio9";
};
pinctrl_adsl_spi: adsl_spi-pins {
pinctrl_adsl_spi_miso: adsl_spi_miso-pins {
function = "adsl_spi_miso";
pins = "gpio18";
};
pinctrl_adsl_spi_mosi: adsl_spi_mosi-pins {
function = "adsl_spi_mosi";
pins = "gpio19";
};
};
pinctrl_vreq_clk: vreq_clk-pins {
function = "vreq_clk";
pins = "gpio22";
};
pinctrl_pcie_clkreq_b: pcie_clkreq_b-pins {
function = "pcie_clkreq_b";
pins = "gpio23";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio30";
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio31";
};
pinctrl_nand: nand-pins {
function = "nand";
group = "nand_grp";
};
pinctrl_gpio35_alt: gpio35_alt-pins {
function = "gpio35_alt";
pin = "gpio35";
};
pinctrl_dectpd: dectpd-pins {
function = "dectpd";
group = "dectpd_grp";
};
pinctrl_vdsl_phy_override_0: vdsl_phy_override_0-pins {
function = "vdsl_phy_override_0";
group = "vdsl_phy_override_0_grp";
};
pinctrl_vdsl_phy_override_1: vdsl_phy_override_1-pins {
function = "vdsl_phy_override_1";
group = "vdsl_phy_override_1_grp";
};
pinctrl_vdsl_phy_override_2: vdsl_phy_override_2-pins {
function = "vdsl_phy_override_2";
group = "vdsl_phy_override_2_grp";
};
pinctrl_vdsl_phy_override_3: vdsl_phy_override_3-pins {
function = "vdsl_phy_override_3";
group = "vdsl_phy_override_3_grp";
};
pinctrl_dsl_gpio8: dsl_gpio8-pins {
function = "dsl_gpio8";
group = "dsl_gpio8";
};
pinctrl_dsl_gpio9: dsl_gpio9-pins {
function = "dsl_gpio9";
group = "dsl_gpio9";
};
};
};

View File

@@ -0,0 +1,162 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6328-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6328 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6328 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6328-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6328-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@10000080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6328-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x10000080 0x80>;
ranges = <0 0x10000080 0x80>;
gpio@0 {
compatible = "brcm,bcm6328-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 32>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@18 {
compatible = "brcm,bcm6328-pinctrl";
reg = <0x18 0x10>;
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio6";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio7";
};
};
pinctrl_inet_act_led: inet_act_led-pins {
function = "inet_act_led";
pins = "gpio11";
};
pinctrl_pcie_clkreq: pcie_clkreq-pins {
function = "pcie_clkreq";
pins = "gpio16";
};
pinctrl_ephy0_spd_led: ephy0_spd_led-pins {
function = "led";
pins = "gpio17";
};
pinctrl_ephy1_spd_led: ephy1_spd_led-pins {
function = "led";
pins = "gpio18";
};
pinctrl_ephy2_spd_led: ephy2_spd_led-pins {
function = "led";
pins = "gpio19";
};
pinctrl_ephy3_spd_led: ephy3_spd_led-pins {
function = "led";
pins = "gpio20";
};
pinctrl_ephy0_act_led: ephy0_act_led-pins {
function = "ephy0_act_led";
pins = "gpio25";
};
pinctrl_ephy1_act_led: ephy1_act_led-pins {
function = "ephy1_act_led";
pins = "gpio26";
};
pinctrl_ephy2_act_led: ephy2_act_led-pins {
function = "ephy2_act_led";
pins = "gpio27";
};
pinctrl_ephy3_act_led: ephy3_act_led-pins {
function = "ephy3_act_led";
pins = "gpio28";
};
pinctrl_hsspi_cs1: hsspi_cs1-pins {
function = "hsspi_cs1";
pins = "hsspi_cs1";
};
pinctrl_usb_port1_device: usb_port1_device-pins {
function = "usb_device_port";
pins = "usb_port1";
};
pinctrl_usb_port1_host: usb_port1_host-pins {
function = "usb_host_port";
pins = "usb_port1";
};
};
};

View File

@@ -0,0 +1,130 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6358-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6358 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6358 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6358-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6358-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@fffe0080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6358-gpio-sysctl", "syscon", "simple-mfd";
reg = <0xfffe0080 0x80>;
ranges = <0 0xfffe0080 0x80>;
gpio@0 {
compatible = "brcm,bcm6358-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 40>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@18 {
compatible = "brcm,bcm6358-pinctrl";
reg = <0x18 0x4>;
pinctrl_ebi_cs: ebi_cs-pins {
function = "ebi_cs";
groups = "ebi_cs_grp";
};
pinctrl_uart1: uart1-pins {
function = "uart1";
groups = "uart1_grp";
};
pinctrl_serial_led: serial_led-pins {
function = "serial_led";
groups = "serial_led_grp";
};
pinctrl_legacy_led: legacy_led-pins {
function = "legacy_led";
groups = "legacy_led_grp";
};
pinctrl_led: led-pins {
function = "led";
groups = "led_grp";
};
pinctrl_spi_cs_23: spi_cs-pins {
function = "spi_cs";
groups = "spi_cs_grp";
};
pinctrl_utopia: utopia-pins {
function = "utopia";
groups = "utopia_grp";
};
pinctrl_pwm_syn_clk: pwm_syn_clk-pins {
function = "pwm_syn_clk";
groups = "pwm_syn_clk_grp";
};
pinctrl_sys_irq: sys_irq-pins {
function = "sys_irq";
groups = "sys_irq_grp";
};
};
};

View File

@@ -0,0 +1,236 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6362-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6362 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6362 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6362-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6362-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@10000080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6362-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x10000080 0x80>;
ranges = <0 0x10000080 0x80>;
gpio@0 {
compatible = "brcm,bcm6362-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 48>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@18 {
compatible = "brcm,bcm6362-pinctrl";
reg = <0x18 0x10>, <0x38 0x4>;
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio0";
};
pinctrl_sys_irq: sys_irq-pins {
function = "sys_irq";
pins = "gpio1";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio2";
};
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio3";
};
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio4";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio5";
};
pinctrl_robosw_led0: robosw_led0-pins {
function = "robosw_led0";
pins = "gpio6";
};
pinctrl_robosw_led1: robosw_led1-pins {
function = "robosw_led1";
pins = "gpio7";
};
pinctrl_inet_led: inet_led-pins {
function = "inet_led";
pins = "gpio8";
};
pinctrl_spi_cs2: spi_cs2-pins {
function = "spi_cs2";
pins = "gpio9";
};
pinctrl_spi_cs3: spi_cs3-pins {
function = "spi_cs3";
pins = "gpio10";
};
pinctrl_ntr_pulse: ntr_pulse-pins {
function = "ntr_pulse";
pins = "gpio11";
};
pinctrl_uart1_scts: uart1_scts-pins {
function = "uart1_scts";
pins = "gpio12";
};
pinctrl_uart1_srts: uart1_srts-pins {
function = "uart1_srts";
pins = "gpio13";
};
pinctrl_uart1: uart1-pins {
pinctrl_uart1_sdin: uart1_sdin-pins {
function = "uart1_sdin";
pins = "gpio14";
};
pinctrl_uart1_sdout: uart1_sdout-pins {
function = "uart1_sdout";
pins = "gpio15";
};
};
pinctrl_adsl_spi: adsl_spi-pins {
pinctrl_adsl_spi_miso: adsl_spi_miso-pins {
function = "adsl_spi_miso";
pins = "gpio16";
};
pinctrl_adsl_spi_mosi: adsl_spi_mosi-pins {
function = "adsl_spi_mosi";
pins = "gpio17";
};
pinctrl_adsl_spi_clk: adsl_spi_clk-pins {
function = "adsl_spi_clk";
pins = "gpio18";
};
pinctrl_adsl_spi_cs: adsl_spi_cs-pins {
function = "adsl_spi_cs";
pins = "gpio19";
};
};
pinctrl_ephy0_led: ephy0_led-pins {
function = "ephy0_led";
pins = "gpio20";
};
pinctrl_ephy1_led: ephy1_led-pins {
function = "ephy1_led";
pins = "gpio21";
};
pinctrl_ephy2_led: ephy2_led-pins {
function = "ephy2_led";
pins = "gpio22";
};
pinctrl_ephy3_led: ephy3_led-pins {
function = "ephy3_led";
pins = "gpio23";
};
pinctrl_ext_irq0: ext_irq0-pins {
function = "ext_irq0";
pins = "gpio24";
};
pinctrl_ext_irq1: ext_irq1-pins {
function = "ext_irq1";
pins = "gpio25";
};
pinctrl_ext_irq2: ext_irq2-pins {
function = "ext_irq2";
pins = "gpio26";
};
pinctrl_ext_irq3: ext_irq3-pins {
function = "ext_irq3";
pins = "gpio27";
};
pinctrl_nand: nand-pins {
function = "nand";
group = "nand_grp";
};
};
};

View File

@@ -0,0 +1,246 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6368-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6368 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6368 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6368-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6368-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@10000080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6368-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x10000080 0x80>;
ranges = <0 0x10000080 0x80>;
gpio@0 {
compatible = "brcm,bcm6368-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 38>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@18 {
compatible = "brcm,bcm6368-pinctrl";
reg = <0x18 0x4>, <0x38 0x4>;
pinctrl_analog_afe_0: analog_afe_0-pins {
function = "analog_afe_0";
pins = "gpio0";
};
pinctrl_analog_afe_1: analog_afe_1-pins {
function = "analog_afe_1";
pins = "gpio1";
};
pinctrl_sys_irq: sys_irq-pins {
function = "sys_irq";
pins = "gpio2";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio3";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio4";
};
};
pinctrl_inet_led: inet_led-pins {
function = "inet_led";
pins = "gpio5";
};
pinctrl_ephy0_led: ephy0_led-pins {
function = "ephy0_led";
pins = "gpio6";
};
pinctrl_ephy1_led: ephy1_led-pins {
function = "ephy1_led";
pins = "gpio7";
};
pinctrl_ephy2_led: ephy2_led-pins {
function = "ephy2_led";
pins = "gpio8";
};
pinctrl_ephy3_led: ephy3_led-pins {
function = "ephy3_led";
pins = "gpio9";
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio10";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio11";
};
pinctrl_robosw_led0: robosw_led0-pins {
function = "robosw_led0";
pins = "gpio12";
};
pinctrl_robosw_led1: robosw_led1-pins {
function = "robosw_led1";
pins = "gpio13";
};
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio14";
};
pinctrl_pci: pci-pins {
pinctrl_pci_req1: pci_req1-pins {
function = "pci_req1";
pins = "gpio16";
};
pinctrl_pci_gnt1: pci_gnt1-pins {
function = "pci_gnt1";
pins = "gpio17";
};
pinctrl_pci_intb: pci_intb-pins {
function = "pci_intb";
pins = "gpio18";
};
pinctrl_pci_req0: pci_req0-pins {
function = "pci_req0";
pins = "gpio19";
};
pinctrl_pci_gnt0: pci_gnt0-pins {
function = "pci_gnt0";
pins = "gpio20";
};
};
pinctrl_pcmcia: pcmcia-pins {
pinctrl_pcmcia_cd1: pcmcia_cd1-pins {
function = "pcmcia_cd1";
pins = "gpio22";
};
pinctrl_pcmcia_cd2: pcmcia_cd2-pins {
function = "pcmcia_cd2";
pins = "gpio23";
};
pinctrl_pcmcia_vs1: pcmcia_vs1-pins {
function = "pcmcia_vs1";
pins = "gpio24";
};
pinctrl_pcmcia_vs2: pcmcia_vs2-pins {
function = "pcmcia_vs2";
pins = "gpio25";
};
};
pinctrl_ebi_cs2: ebi_cs2-pins {
function = "ebi_cs2";
pins = "gpio26";
};
pinctrl_ebi_cs3: ebi_cs3-pins {
function = "ebi_cs3";
pins = "gpio27";
};
pinctrl_spi_cs2: spi_cs2-pins {
function = "spi_cs2";
pins = "gpio28";
};
pinctrl_spi_cs3: spi_cs3-pins {
function = "spi_cs3";
pins = "gpio29";
};
pinctrl_spi_cs4: spi_cs4-pins {
function = "spi_cs4";
pins = "gpio30";
};
pinctrl_spi_cs5: spi_cs5-pins {
function = "spi_cs5";
pins = "gpio31";
};
pinctrl_uart1: uart1-pins {
function = "uart1";
group = "uart1_grp";
};
};
};

View File

@@ -0,0 +1,143 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/brcm,bcm6318-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6318 pin controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Bindings for Broadcom's BCM6318 memory-mapped pin controller.
properties:
compatible:
const: brcm,bcm6318-pinctrl
reg:
maxItems: 2
patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
properties:
function:
enum: [ ephy0_spd_led, ephy1_spd_led, ephy2_spd_led, ephy3_spd_led,
ephy0_act_led, ephy1_act_led, ephy2_act_led, ephy3_act_led,
serial_led_data, serial_led_clk, inet_act_led, inet_fail_led,
dsl_led, post_fail_led, wlan_wps_led, usb_pwron,
usb_device_led, usb_active ]
pins:
enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7,
gpio8, gpio9, gpio10, gpio11, gpio12, gpio13, gpio40 ]
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pinctrl@18 {
compatible = "brcm,bcm6318-pinctrl";
reg = <0x18 0x10>, <0x54 0x18>;
pinctrl_ephy0_spd_led: ephy0_spd_led-pins {
function = "ephy0_spd_led";
pins = "gpio0";
};
pinctrl_ephy1_spd_led: ephy1_spd_led-pins {
function = "ephy1_spd_led";
pins = "gpio1";
};
pinctrl_ephy2_spd_led: ephy2_spd_led-pins {
function = "ephy2_spd_led";
pins = "gpio2";
};
pinctrl_ephy3_spd_led: ephy3_spd_led-pins {
function = "ephy3_spd_led";
pins = "gpio3";
};
pinctrl_ephy0_act_led: ephy0_act_led-pins {
function = "ephy0_act_led";
pins = "gpio4";
};
pinctrl_ephy1_act_led: ephy1_act_led-pins {
function = "ephy1_act_led";
pins = "gpio5";
};
pinctrl_ephy2_act_led: ephy2_act_led-pins {
function = "ephy2_act_led";
pins = "gpio6";
};
pinctrl_ephy3_act_led: ephy3_act_led-pins {
function = "ephy3_act_led";
pins = "gpio7";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio6";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio7";
};
};
pinctrl_inet_act_led: inet_act_led-pins {
function = "inet_act_led";
pins = "gpio8";
};
pinctrl_inet_fail_led: inet_fail_led-pins {
function = "inet_fail_led";
pins = "gpio9";
};
pinctrl_dsl_led: dsl_led-pins {
function = "dsl_led";
pins = "gpio10";
};
pinctrl_post_fail_led: post_fail_led-pins {
function = "post_fail_led";
pins = "gpio11";
};
pinctrl_wlan_wps_led: wlan_wps_led-pins {
function = "wlan_wps_led";
pins = "gpio12";
};
pinctrl_usb_pwron: usb_pwron-pins {
function = "usb_pwron";
pins = "gpio13";
};
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio13";
};
pinctrl_usb_active: usb_active-pins {
function = "usb_active";
pins = "gpio40";
};
};

View File

@@ -0,0 +1,164 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/brcm,bcm63268-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM63268 pin controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Bindings for Broadcom's BCM63268 memory-mapped pin controller.
properties:
compatible:
const: brcm,bcm63268-pinctrl
reg:
maxItems: 3
patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
properties:
function:
enum: [ serial_led_clk, serial_led_data, hsspi_cs4, hsspi_cs5,
hsspi_cs6, hsspi_cs7, adsl_spi_miso, adsl_spi_mosi,
vreq_clk, pcie_clkreq_b, robosw_led_clk, robosw_led_data,
nand, gpio35_alt, dectpd, vdsl_phy_override_0,
vdsl_phy_override_1, vdsl_phy_override_2,
vdsl_phy_override_3, dsl_gpio8, dsl_gpio9 ]
pins:
enum: [ gpio0, gpio1, gpio16, gpio17, gpio8, gpio9, gpio18, gpio19,
gpio22, gpio23, gpio30, gpio31, nand_grp, gpio35
dectpd_grp, vdsl_phy_override_0_grp,
vdsl_phy_override_1_grp, vdsl_phy_override_2_grp,
vdsl_phy_override_3_grp, dsl_gpio8, dsl_gpio9 ]
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pinctrl@10 {
compatible = "brcm,bcm63268-pinctrl";
reg = <0x10 0x4>, <0x18 0x8>, <0x38 0x4>;
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio0";
};
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio1";
};
};
pinctrl_hsspi_cs4: hsspi_cs4-pins {
function = "hsspi_cs4";
pins = "gpio16";
};
pinctrl_hsspi_cs5: hsspi_cs5-pins {
function = "hsspi_cs5";
pins = "gpio17";
};
pinctrl_hsspi_cs6: hsspi_cs6-pins {
function = "hsspi_cs6";
pins = "gpio8";
};
pinctrl_hsspi_cs7: hsspi_cs7-pins {
function = "hsspi_cs7";
pins = "gpio9";
};
pinctrl_adsl_spi: adsl_spi-pins {
pinctrl_adsl_spi_miso: adsl_spi_miso-pins {
function = "adsl_spi_miso";
pins = "gpio18";
};
pinctrl_adsl_spi_mosi: adsl_spi_mosi-pins {
function = "adsl_spi_mosi";
pins = "gpio19";
};
};
pinctrl_vreq_clk: vreq_clk-pins {
function = "vreq_clk";
pins = "gpio22";
};
pinctrl_pcie_clkreq_b: pcie_clkreq_b-pins {
function = "pcie_clkreq_b";
pins = "gpio23";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio30";
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio31";
};
pinctrl_nand: nand-pins {
function = "nand";
group = "nand_grp";
};
pinctrl_gpio35_alt: gpio35_alt-pins {
function = "gpio35_alt";
pin = "gpio35";
};
pinctrl_dectpd: dectpd-pins {
function = "dectpd";
group = "dectpd_grp";
};
pinctrl_vdsl_phy_override_0: vdsl_phy_override_0-pins {
function = "vdsl_phy_override_0";
group = "vdsl_phy_override_0_grp";
};
pinctrl_vdsl_phy_override_1: vdsl_phy_override_1-pins {
function = "vdsl_phy_override_1";
group = "vdsl_phy_override_1_grp";
};
pinctrl_vdsl_phy_override_2: vdsl_phy_override_2-pins {
function = "vdsl_phy_override_2";
group = "vdsl_phy_override_2_grp";
};
pinctrl_vdsl_phy_override_3: vdsl_phy_override_3-pins {
function = "vdsl_phy_override_3";
group = "vdsl_phy_override_3_grp";
};
pinctrl_dsl_gpio8: dsl_gpio8-pins {
function = "dsl_gpio8";
group = "dsl_gpio8";
};
pinctrl_dsl_gpio9: dsl_gpio9-pins {
function = "dsl_gpio9";
group = "dsl_gpio9";
};
};

View File

@@ -0,0 +1,127 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/brcm,bcm6328-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6328 pin controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Bindings for Broadcom's BCM6328 memory-mapped pin controller.
properties:
compatible:
const: brcm,bcm6328-pinctrl
reg:
maxItems: 1
patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
properties:
function:
enum: [ serial_led_data, serial_led_clk, inet_act_led, pcie_clkreq,
led, ephy0_act_led, ephy1_act_led, ephy2_act_led,
ephy3_act_led, hsspi_cs1, usb_device_port, usb_host_port ]
pins:
enum: [ gpio6, gpio7, gpio11, gpio16, gpio17, gpio18, gpio19,
gpio20, gpio25, gpio26, gpio27, gpio28, hsspi_cs1,
usb_port1 ]
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pinctrl@18 {
compatible = "brcm,bcm6328-pinctrl";
reg = <0x18 0x10>;
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio6";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio7";
};
};
pinctrl_inet_act_led: inet_act_led-pins {
function = "inet_act_led";
pins = "gpio11";
};
pinctrl_pcie_clkreq: pcie_clkreq-pins {
function = "pcie_clkreq";
pins = "gpio16";
};
pinctrl_ephy0_spd_led: ephy0_spd_led-pins {
function = "led";
pins = "gpio17";
};
pinctrl_ephy1_spd_led: ephy1_spd_led-pins {
function = "led";
pins = "gpio18";
};
pinctrl_ephy2_spd_led: ephy2_spd_led-pins {
function = "led";
pins = "gpio19";
};
pinctrl_ephy3_spd_led: ephy3_spd_led-pins {
function = "led";
pins = "gpio20";
};
pinctrl_ephy0_act_led: ephy0_act_led-pins {
function = "ephy0_act_led";
pins = "gpio25";
};
pinctrl_ephy1_act_led: ephy1_act_led-pins {
function = "ephy1_act_led";
pins = "gpio26";
};
pinctrl_ephy2_act_led: ephy2_act_led-pins {
function = "ephy2_act_led";
pins = "gpio27";
};
pinctrl_ephy3_act_led: ephy3_act_led-pins {
function = "ephy3_act_led";
pins = "gpio28";
};
pinctrl_hsspi_cs1: hsspi_cs1-pins {
function = "hsspi_cs1";
pins = "hsspi_cs1";
};
pinctrl_usb_port1_device: usb_port1_device-pins {
function = "usb_device_port";
pins = "usb_port1";
};
pinctrl_usb_port1_host: usb_port1_host-pins {
function = "usb_host_port";
pins = "usb_port1";
};
};

View File

@@ -0,0 +1,93 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/brcm,bcm6358-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6358 pin controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Bindings for Broadcom's BCM6358 memory-mapped pin controller.
properties:
compatible:
const: brcm,bcm6358-pinctrl
reg:
maxItems: 1
patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
properties:
function:
enum: [ ebi_cs, uart1, serial_led, legacy_led, led, spi_cs, utopia,
pwm_syn_clk, sys_irq ]
pins:
enum: [ ebi_cs_grp, uart1_grp, serial_led_grp, legacy_led_grp,
led_grp, spi_cs_grp, utopia_grp, pwm_syn_clk, sys_irq_grp ]
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pinctrl@18 {
compatible = "brcm,bcm6358-pinctrl";
reg = <0x18 0x4>;
pinctrl_ebi_cs: ebi_cs-pins {
function = "ebi_cs";
groups = "ebi_cs_grp";
};
pinctrl_uart1: uart1-pins {
function = "uart1";
groups = "uart1_grp";
};
pinctrl_serial_led: serial_led-pins {
function = "serial_led";
groups = "serial_led_grp";
};
pinctrl_legacy_led: legacy_led-pins {
function = "legacy_led";
groups = "legacy_led_grp";
};
pinctrl_led: led-pins {
function = "led";
groups = "led_grp";
};
pinctrl_spi_cs_23: spi_cs-pins {
function = "spi_cs";
groups = "spi_cs_grp";
};
pinctrl_utopia: utopia-pins {
function = "utopia";
groups = "utopia_grp";
};
pinctrl_pwm_syn_clk: pwm_syn_clk-pins {
function = "pwm_syn_clk";
groups = "pwm_syn_clk_grp";
};
pinctrl_sys_irq: sys_irq-pins {
function = "sys_irq";
groups = "sys_irq_grp";
};
};

View File

@@ -0,0 +1,206 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/brcm,bcm6362-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6362 pin controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Bindings for Broadcom's BCM6362 memory-mapped pin controller.
properties:
compatible:
const: brcm,bcm6362-pinctrl
reg:
maxItems: 2
patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
properties:
function:
enum: [ usb_device_led, sys_irq, serial_led_clk, serial_led_data,
robosw_led_data, robosw_led_clk, robosw_led0, robosw_led1,
inet_led, spi_cs2, spi_cs3, ntr_pulse, uart1_scts,
uart1_srts, uart1_sdin, uart1_sdout, adsl_spi_miso,
adsl_spi_mosi, adsl_spi_clk, adsl_spi_cs, ephy0_led,
ephy1_led, ephy2_led, ephy3_led, ext_irq0, ext_irq1,
ext_irq2, ext_irq3, nand ]
pins:
enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7,
gpio8, gpio9, gpio10, gpio11, gpio12, gpio13, gpio14,
gpio15, gpio16, gpio17, gpio18, gpio19, gpio20, gpio21,
gpio22, gpio23, gpio24, gpio25, gpio26, gpio27, nand_grp ]
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pinctrl@18 {
compatible = "brcm,bcm6362-pinctrl";
reg = <0x18 0x10>, <0x38 0x4>;
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio0";
};
pinctrl_sys_irq: sys_irq-pins {
function = "sys_irq";
pins = "gpio1";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio2";
};
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio3";
};
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio4";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio5";
};
pinctrl_robosw_led0: robosw_led0-pins {
function = "robosw_led0";
pins = "gpio6";
};
pinctrl_robosw_led1: robosw_led1-pins {
function = "robosw_led1";
pins = "gpio7";
};
pinctrl_inet_led: inet_led-pins {
function = "inet_led";
pins = "gpio8";
};
pinctrl_spi_cs2: spi_cs2-pins {
function = "spi_cs2";
pins = "gpio9";
};
pinctrl_spi_cs3: spi_cs3-pins {
function = "spi_cs3";
pins = "gpio10";
};
pinctrl_ntr_pulse: ntr_pulse-pins {
function = "ntr_pulse";
pins = "gpio11";
};
pinctrl_uart1_scts: uart1_scts-pins {
function = "uart1_scts";
pins = "gpio12";
};
pinctrl_uart1_srts: uart1_srts-pins {
function = "uart1_srts";
pins = "gpio13";
};
pinctrl_uart1: uart1-pins {
pinctrl_uart1_sdin: uart1_sdin-pins {
function = "uart1_sdin";
pins = "gpio14";
};
pinctrl_uart1_sdout: uart1_sdout-pins {
function = "uart1_sdout";
pins = "gpio15";
};
};
pinctrl_adsl_spi: adsl_spi-pins {
pinctrl_adsl_spi_miso: adsl_spi_miso-pins {
function = "adsl_spi_miso";
pins = "gpio16";
};
pinctrl_adsl_spi_mosi: adsl_spi_mosi-pins {
function = "adsl_spi_mosi";
pins = "gpio17";
};
pinctrl_adsl_spi_clk: adsl_spi_clk-pins {
function = "adsl_spi_clk";
pins = "gpio18";
};
pinctrl_adsl_spi_cs: adsl_spi_cs-pins {
function = "adsl_spi_cs";
pins = "gpio19";
};
};
pinctrl_ephy0_led: ephy0_led-pins {
function = "ephy0_led";
pins = "gpio20";
};
pinctrl_ephy1_led: ephy1_led-pins {
function = "ephy1_led";
pins = "gpio21";
};
pinctrl_ephy2_led: ephy2_led-pins {
function = "ephy2_led";
pins = "gpio22";
};
pinctrl_ephy3_led: ephy3_led-pins {
function = "ephy3_led";
pins = "gpio23";
};
pinctrl_ext_irq0: ext_irq0-pins {
function = "ext_irq0";
pins = "gpio24";
};
pinctrl_ext_irq1: ext_irq1-pins {
function = "ext_irq1";
pins = "gpio25";
};
pinctrl_ext_irq2: ext_irq2-pins {
function = "ext_irq2";
pins = "gpio26";
};
pinctrl_ext_irq3: ext_irq3-pins {
function = "ext_irq3";
pins = "gpio27";
};
pinctrl_nand: nand-pins {
function = "nand";
group = "nand_grp";
};
};

View File

@@ -0,0 +1,217 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/brcm,bcm6368-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6368 pin controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Bindings for Broadcom's BCM6368 memory-mapped pin controller.
properties:
compatible:
const: brcm,bcm6368-pinctrl
reg:
maxItems: 2
patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
properties:
function:
enum: [ analog_afe_0, analog_afe_1, sys_irq, serial_led_data,
serial_led_clk, inet_led, ephy0_led, ephy1_led, ephy2_led,
ephy3_led, robosw_led_data, robosw_led_clk, robosw_led0,
robosw_led1, usb_device_led, pci_req1, pci_gnt1, pci_intb,
pci_req0, pci_gnt0, pcmcia_cd1, pcmcia_cd2, pcmcia_vs1,
pcmcia_vs2, ebi_cs2, ebi_cs3, spi_cs2, spi_cs3, spi_cs4,
spi_cs5, uart1 ]
pins:
enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7,
gpio8, gpio9, gpio10, gpio11, gpio12, gpio13, gpio14,
gpio16, gpio17, gpio18, gpio19, gpio20, gpio22, gpio23,
gpio24, gpio25, gpio26, gpio27, gpio28, gpio29, gpio30,
gpio31, uart1_grp ]
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pinctrl@18 {
compatible = "brcm,bcm6368-pinctrl";
reg = <0x18 0x4>, <0x38 0x4>;
pinctrl_analog_afe_0: analog_afe_0-pins {
function = "analog_afe_0";
pins = "gpio0";
};
pinctrl_analog_afe_1: analog_afe_1-pins {
function = "analog_afe_1";
pins = "gpio1";
};
pinctrl_sys_irq: sys_irq-pins {
function = "sys_irq";
pins = "gpio2";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio3";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio4";
};
};
pinctrl_inet_led: inet_led-pins {
function = "inet_led";
pins = "gpio5";
};
pinctrl_ephy0_led: ephy0_led-pins {
function = "ephy0_led";
pins = "gpio6";
};
pinctrl_ephy1_led: ephy1_led-pins {
function = "ephy1_led";
pins = "gpio7";
};
pinctrl_ephy2_led: ephy2_led-pins {
function = "ephy2_led";
pins = "gpio8";
};
pinctrl_ephy3_led: ephy3_led-pins {
function = "ephy3_led";
pins = "gpio9";
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio10";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio11";
};
pinctrl_robosw_led0: robosw_led0-pins {
function = "robosw_led0";
pins = "gpio12";
};
pinctrl_robosw_led1: robosw_led1-pins {
function = "robosw_led1";
pins = "gpio13";
};
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio14";
};
pinctrl_pci: pci-pins {
pinctrl_pci_req1: pci_req1-pins {
function = "pci_req1";
pins = "gpio16";
};
pinctrl_pci_gnt1: pci_gnt1-pins {
function = "pci_gnt1";
pins = "gpio17";
};
pinctrl_pci_intb: pci_intb-pins {
function = "pci_intb";
pins = "gpio18";
};
pinctrl_pci_req0: pci_req0-pins {
function = "pci_req0";
pins = "gpio19";
};
pinctrl_pci_gnt0: pci_gnt0-pins {
function = "pci_gnt0";
pins = "gpio20";
};
};
pinctrl_pcmcia: pcmcia-pins {
pinctrl_pcmcia_cd1: pcmcia_cd1-pins {
function = "pcmcia_cd1";
pins = "gpio22";
};
pinctrl_pcmcia_cd2: pcmcia_cd2-pins {
function = "pcmcia_cd2";
pins = "gpio23";
};
pinctrl_pcmcia_vs1: pcmcia_vs1-pins {
function = "pcmcia_vs1";
pins = "gpio24";
};
pinctrl_pcmcia_vs2: pcmcia_vs2-pins {
function = "pcmcia_vs2";
pins = "gpio25";
};
};
pinctrl_ebi_cs2: ebi_cs2-pins {
function = "ebi_cs2";
pins = "gpio26";
};
pinctrl_ebi_cs3: ebi_cs3-pins {
function = "ebi_cs3";
pins = "gpio27";
};
pinctrl_spi_cs2: spi_cs2-pins {
function = "spi_cs2";
pins = "gpio28";
};
pinctrl_spi_cs3: spi_cs3-pins {
function = "spi_cs3";
pins = "gpio29";
};
pinctrl_spi_cs4: spi_cs4-pins {
function = "spi_cs4";
pins = "gpio30";
};
pinctrl_spi_cs5: spi_cs5-pins {
function = "spi_cs5";
pins = "gpio31";
};
pinctrl_uart1: uart1-pins {
function = "uart1";
group = "uart1_grp";
};
};

View File

@@ -17,10 +17,12 @@ description: >
naming scheme "PxN" where x is a character identifying the GPIO port with
which the pin is associated and N is an integer from 0 to 31 identifying the
pin within that GPIO port. For example PA0 is the first pin in GPIO port A,
and PB31 is the last pin in GPIO port B. The JZ4740, the X1000 and the X1830
contains 4 GPIO ports, PA to PD, for a total of 128 pins. The JZ4760, the
JZ4770 and the JZ4780 contains 6 GPIO ports, PA to PF, for a total of 192
pins.
and PB31 is the last pin in GPIO port B. The JZ4730, the JZ4740, the JZ4725B,
the X1000 and the X1830 contains 4 GPIO ports, PA to PD, for a total of 128
pins. The X2000 contains 5 GPIO ports, PA to PE, for a total of 160 pins.
The JZ4750, the JZ4755 the JZ4760, the JZ4770 and the JZ4780 contains 6 GPIO
ports, PA to PF, for a total of 192 pins. The JZ4775 contains 7 GPIO ports,
PA to PG, for a total of 224 pins.
maintainers:
- Paul Cercueil <paul@crapouillou.net>
@@ -32,20 +34,28 @@ properties:
compatible:
oneOf:
- enum:
- ingenic,jz4730-pinctrl
- ingenic,jz4740-pinctrl
- ingenic,jz4725b-pinctrl
- ingenic,jz4750-pinctrl
- ingenic,jz4755-pinctrl
- ingenic,jz4760-pinctrl
- ingenic,jz4770-pinctrl
- ingenic,jz4775-pinctrl
- ingenic,jz4780-pinctrl
- ingenic,x1000-pinctrl
- ingenic,x1500-pinctrl
- ingenic,x1830-pinctrl
- ingenic,x2000-pinctrl
- items:
- const: ingenic,jz4760b-pinctrl
- const: ingenic,jz4760-pinctrl
- items:
- const: ingenic,x1000e-pinctrl
- const: ingenic,x1000-pinctrl
- items:
- const: ingenic,x2000e-pinctrl
- const: ingenic,x2000-pinctrl
reg:
maxItems: 1
@@ -62,14 +72,19 @@ patternProperties:
properties:
compatible:
enum:
- ingenic,jz4730-gpio
- ingenic,jz4740-gpio
- ingenic,jz4725b-gpio
- ingenic,jz4750-gpio
- ingenic,jz4755-gpio
- ingenic,jz4760-gpio
- ingenic,jz4770-gpio
- ingenic,jz4775-gpio
- ingenic,jz4780-gpio
- ingenic,x1000-gpio
- ingenic,x1500-gpio
- ingenic,x1830-gpio
- ingenic,x2000-gpio
reg:
items:

View File

@@ -0,0 +1,151 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8195.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mediatek MT8195 Pin Controller
maintainers:
- Sean Wang <sean.wang@mediatek.com>
description: |
The Mediatek's Pin controller is used to control SoC pins.
properties:
compatible:
const: mediatek,mt8195-pinctrl
gpio-controller: true
'#gpio-cells':
description: |
Number of cells in GPIO specifier. Since the generic GPIO binding is used,
the amount of cells must be specified as 2. See the below
mentioned gpio binding representation for description of particular cells.
const: 2
gpio-ranges:
description: gpio valid number range.
maxItems: 1
reg:
description: |
Physical address base for gpio base registers. There are 8 GPIO
physical address base in mt8195.
maxItems: 8
reg-names:
description: |
Gpio base register names.
maxItems: 8
interrupt-controller: true
'#interrupt-cells':
const: 2
interrupts:
description: The interrupt outputs to sysirq.
maxItems: 1
#PIN CONFIGURATION NODES
patternProperties:
'-pins$':
type: object
description: |
A pinctrl node should contain at least one subnodes representing the
pinctrl groups available on the machine. Each subnode will list the
pins it needs, and how they should be configured, with regard to muxer
configuration, pullups, drive strength, input enable/disable and
input schmitt.
An example of using macro:
pincontroller {
/* GPIO0 set as multifunction GPIO0 */
gpio_pin {
pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
};
/* GPIO8 set as multifunction SDA0 */
i2c0_pin {
pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
};
};
$ref: "pinmux-node.yaml"
properties:
pinmux:
description: |
Integer array, represents gpio pin number and mux setting.
Supported pin number and mux varies for different SoCs, and are defined
as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
drive-strength:
description: |
It can support some arguments which is from 0 to 7. It can only support
2/4/6/8/10/12/14/16mA in mt8195.
enum: [0, 1, 2, 3, 4, 5, 6, 7]
bias-pull-down: true
bias-pull-up: true
bias-disable: true
output-high: true
output-low: true
input-enable: true
input-disable: true
input-schmitt-enable: true
input-schmitt-disable: true
required:
- pinmux
additionalProperties: false
required:
- compatible
- reg
- interrupts
- interrupt-controller
- '#interrupt-cells'
- gpio-controller
- '#gpio-cells'
- gpio-ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/pinctrl/mt8195-pinfunc.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
pio: pinctrl@10005000 {
compatible = "mediatek,mt8195-pinctrl";
reg = <0x10005000 0x1000>,
<0x11d10000 0x1000>,
<0x11d30000 0x1000>,
<0x11d40000 0x1000>,
<0x11e20000 0x1000>,
<0x11eb0000 0x1000>,
<0x11f40000 0x1000>,
<0x1000b000 0x1000>;
reg-names = "iocfg0", "iocfg_bm", "iocfg_bl",
"iocfg_br", "iocfg_lm", "iocfg_rb",
"iocfg_tl", "eint";
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&pio 0 0 144>;
interrupt-controller;
interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>;
#interrupt-cells = <2>;
pio-pins {
pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
output-low;
};
};

View File

@@ -27,8 +27,15 @@ PMIC's from Qualcomm.
"qcom,pm660l-gpio"
"qcom,pm8150-gpio"
"qcom,pm8150b-gpio"
"qcom,pm8350-gpio"
"qcom,pm8350b-gpio"
"qcom,pm8350c-gpio"
"qcom,pmk8350-gpio"
"qcom,pmr735a-gpio"
"qcom,pmr735b-gpio"
"qcom,pm6150-gpio"
"qcom,pm6150l-gpio"
"qcom,pm8008-gpio"
"qcom,pmx55-gpio"
And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio"
@@ -109,8 +116,15 @@ to specify in a pin configuration subnode:
and gpio8)
gpio1-gpio12 for pm8150b (holes on gpio3, gpio4, gpio7)
gpio1-gpio12 for pm8150l (hole on gpio7)
gpio1-gpio10 for pm8350
gpio1-gpio8 for pm8350b
gpio1-gpio9 for pm8350c
gpio1-gpio4 for pmk8350
gpio1-gpio4 for pmr735a
gpio1-gpio4 for pmr735b
gpio1-gpio10 for pm6150
gpio1-gpio12 for pm6150l
gpio1-gpio2 for pm8008
gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10
and gpio11)

View File

@@ -33,6 +33,7 @@ Required properties for iomux controller:
"rockchip,rk3328-pinctrl": for Rockchip RK3328
"rockchip,rk3368-pinctrl": for Rockchip RK3368
"rockchip,rk3399-pinctrl": for Rockchip RK3399
"rockchip,rk3568-pinctrl": for Rockchip RK3568
- rockchip,grf: phandle referencing a syscon providing the
"general register files"

View File

@@ -0,0 +1,336 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx ZynqMP Pinctrl
maintainers:
- Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
- Rajan Vaja <rajan.vaja@xilinx.com>
description: |
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
ZynqMP's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as pull-up, slew rate, etc.
Each configuration node can consist of multiple nodes describing the pinmux and
pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
properties:
compatible:
const: xlnx,zynqmp-pinctrl
patternProperties:
'^(.*-)?(default|gpio)$':
type: object
patternProperties:
'^mux':
type: object
description:
Pinctrl node's client devices use subnodes for pin muxes,
which in turn use below standard properties.
$ref: pinmux-node.yaml#
properties:
groups:
description:
List of groups to select (either this or "pins" must be
specified), available groups for this subnode.
items:
enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
sdio1_3_grp, sdio1_4_grp, sdio1_5_grp,
sdio1_6_grp, sdio1_7_grp, sdio1_8_grp,
sdio1_9_grp, sdio1_10_grp, sdio1_11_grp,
sdio1_12_grp, sdio1_13_grp, sdio1_14_grp,
sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp,
sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp,
sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp,
nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp,
nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp,
can0_1_grp, can0_2_grp, can0_3_grp,
can0_4_grp, can0_5_grp, can0_6_grp,
can0_7_grp, can0_8_grp, can0_9_grp,
can0_10_grp, can0_11_grp, can0_12_grp,
can0_13_grp, can0_14_grp, can0_15_grp,
can0_16_grp, can0_17_grp, can0_18_grp,
can1_0_grp, can1_1_grp, can1_2_grp,
can1_3_grp, can1_4_grp, can1_5_grp,
can1_6_grp, can1_7_grp, can1_8_grp,
can1_9_grp, can1_10_grp, can1_11_grp,
can1_12_grp, can1_13_grp, can1_14_grp,
can1_15_grp, can1_16_grp, can1_17_grp,
can1_18_grp, can1_19_grp, uart0_0_grp,
uart0_1_grp, uart0_2_grp, uart0_3_grp,
uart0_4_grp, uart0_5_grp, uart0_6_grp,
uart0_7_grp, uart0_8_grp, uart0_9_grp,
uart0_10_grp, uart0_11_grp, uart0_12_grp,
uart0_13_grp, uart0_14_grp, uart0_15_grp,
uart0_16_grp, uart0_17_grp, uart0_18_grp,
uart1_0_grp, uart1_1_grp, uart1_2_grp,
uart1_3_grp, uart1_4_grp, uart1_5_grp,
uart1_6_grp, uart1_7_grp, uart1_8_grp,
uart1_9_grp, uart1_10_grp, uart1_11_grp,
uart1_12_grp, uart1_13_grp, uart1_14_grp,
uart1_15_grp, uart1_16_grp, uart1_17_grp,
uart1_18_grp, i2c0_0_grp, i2c0_1_grp,
i2c0_2_grp, i2c0_3_grp, i2c0_4_grp,
i2c0_5_grp, i2c0_6_grp, i2c0_7_grp,
i2c0_8_grp, i2c0_9_grp, i2c0_10_grp,
i2c0_11_grp, i2c0_12_grp, i2c0_13_grp,
i2c0_14_grp, i2c0_15_grp, i2c0_16_grp,
i2c0_17_grp, i2c0_18_grp, i2c1_0_grp,
i2c1_1_grp, i2c1_2_grp, i2c1_3_grp,
i2c1_4_grp, i2c1_5_grp, i2c1_6_grp,
i2c1_7_grp, i2c1_8_grp, i2c1_9_grp,
i2c1_10_grp, i2c1_11_grp, i2c1_12_grp,
i2c1_13_grp, i2c1_14_grp, i2c1_15_grp,
i2c1_16_grp, i2c1_17_grp, i2c1_18_grp,
i2c1_19_grp, ttc0_clk_0_grp, ttc0_wav_0_grp,
ttc0_clk_1_grp, ttc0_wav_1_grp, ttc0_clk_2_grp,
ttc0_wav_2_grp, ttc0_clk_3_grp, ttc0_wav_3_grp,
ttc0_clk_4_grp, ttc0_wav_4_grp, ttc0_clk_5_grp,
ttc0_wav_5_grp, ttc0_clk_6_grp, ttc0_wav_6_grp,
ttc0_clk_7_grp, ttc0_wav_7_grp, ttc0_clk_8_grp,
ttc0_wav_8_grp, ttc1_clk_0_grp, ttc1_wav_0_grp,
ttc1_clk_1_grp, ttc1_wav_1_grp, ttc1_clk_2_grp,
ttc1_wav_2_grp, ttc1_clk_3_grp, ttc1_wav_3_grp,
ttc1_clk_4_grp, ttc1_wav_4_grp, ttc1_clk_5_grp,
ttc1_wav_5_grp, ttc1_clk_6_grp, ttc1_wav_6_grp,
ttc1_clk_7_grp, ttc1_wav_7_grp, ttc1_clk_8_grp,
ttc1_wav_8_grp, ttc2_clk_0_grp, ttc2_wav_0_grp,
ttc2_clk_1_grp, ttc2_wav_1_grp, ttc2_clk_2_grp,
ttc2_wav_2_grp, ttc2_clk_3_grp, ttc2_wav_3_grp,
ttc2_clk_4_grp, ttc2_wav_4_grp, ttc2_clk_5_grp,
ttc2_wav_5_grp, ttc2_clk_6_grp, ttc2_wav_6_grp,
ttc2_clk_7_grp, ttc2_wav_7_grp, ttc2_clk_8_grp,
ttc2_wav_8_grp, ttc3_clk_0_grp, ttc3_wav_0_grp,
ttc3_clk_1_grp, ttc3_wav_1_grp, ttc3_clk_2_grp,
ttc3_wav_2_grp, ttc3_clk_3_grp, ttc3_wav_3_grp,
ttc3_clk_4_grp, ttc3_wav_4_grp, ttc3_clk_5_grp,
ttc3_wav_5_grp, ttc3_clk_6_grp, ttc3_wav_6_grp,
ttc3_clk_7_grp, ttc3_wav_7_grp, ttc3_clk_8_grp,
ttc3_wav_8_grp, swdt0_clk_0_grp, swdt0_rst_0_grp,
swdt0_clk_1_grp, swdt0_rst_1_grp, swdt0_clk_2_grp,
swdt0_rst_2_grp, swdt0_clk_3_grp, swdt0_rst_3_grp,
swdt0_clk_4_grp, swdt0_rst_4_grp, swdt0_clk_5_grp,
swdt0_rst_5_grp, swdt0_clk_6_grp, swdt0_rst_6_grp,
swdt0_clk_7_grp, swdt0_rst_7_grp, swdt0_clk_8_grp,
swdt0_rst_8_grp, swdt0_clk_9_grp, swdt0_rst_9_grp,
swdt0_clk_10_grp, swdt0_rst_10_grp, swdt0_clk_11_grp,
swdt0_rst_11_grp, swdt0_clk_12_grp, swdt0_rst_12_grp,
swdt1_clk_0_grp, swdt1_rst_0_grp, swdt1_clk_1_grp,
swdt1_rst_1_grp, swdt1_clk_2_grp, swdt1_rst_2_grp,
swdt1_clk_3_grp, swdt1_rst_3_grp, swdt1_clk_4_grp,
swdt1_rst_4_grp, swdt1_clk_5_grp, swdt1_rst_5_grp,
swdt1_clk_6_grp, swdt1_rst_6_grp, swdt1_clk_7_grp,
swdt1_rst_7_grp, swdt1_clk_8_grp, swdt1_rst_8_grp,
swdt1_clk_9_grp, swdt1_rst_9_grp, swdt1_clk_10_grp,
swdt1_rst_10_grp, swdt1_clk_11_grp, swdt1_rst_11_grp,
swdt1_clk_12_grp, swdt1_rst_12_grp, gpio0_0_grp,
gpio0_1_grp, gpio0_2_grp, gpio0_3_grp,
gpio0_4_grp, gpio0_5_grp, gpio0_6_grp,
gpio0_7_grp, gpio0_8_grp, gpio0_9_grp,
gpio0_10_grp, gpio0_11_grp, gpio0_12_grp,
gpio0_13_grp, gpio0_14_grp, gpio0_15_grp,
gpio0_16_grp, gpio0_17_grp, gpio0_18_grp,
gpio0_19_grp, gpio0_20_grp, gpio0_21_grp,
gpio0_22_grp, gpio0_23_grp, gpio0_24_grp,
gpio0_25_grp, gpio0_26_grp, gpio0_27_grp,
gpio0_28_grp, gpio0_29_grp, gpio0_30_grp,
gpio0_31_grp, gpio0_32_grp, gpio0_33_grp,
gpio0_34_grp, gpio0_35_grp, gpio0_36_grp,
gpio0_37_grp, gpio0_38_grp, gpio0_39_grp,
gpio0_40_grp, gpio0_41_grp, gpio0_42_grp,
gpio0_43_grp, gpio0_44_grp, gpio0_45_grp,
gpio0_46_grp, gpio0_47_grp, gpio0_48_grp,
gpio0_49_grp, gpio0_50_grp, gpio0_51_grp,
gpio0_52_grp, gpio0_53_grp, gpio0_54_grp,
gpio0_55_grp, gpio0_56_grp, gpio0_57_grp,
gpio0_58_grp, gpio0_59_grp, gpio0_60_grp,
gpio0_61_grp, gpio0_62_grp, gpio0_63_grp,
gpio0_64_grp, gpio0_65_grp, gpio0_66_grp,
gpio0_67_grp, gpio0_68_grp, gpio0_69_grp,
gpio0_70_grp, gpio0_71_grp, gpio0_72_grp,
gpio0_73_grp, gpio0_74_grp, gpio0_75_grp,
gpio0_76_grp, gpio0_77_grp, usb0_0_grp,
usb1_0_grp, pmu0_0_grp, pmu0_1_grp,
pmu0_2_grp, pmu0_3_grp, pmu0_4_grp,
pmu0_5_grp, pmu0_6_grp, pmu0_7_grp,
pmu0_8_grp, pmu0_9_grp, pmu0_10_grp,
pmu0_11_grp, pcie0_0_grp, pcie0_1_grp,
pcie0_2_grp, pcie0_3_grp, pcie0_4_grp,
pcie0_5_grp, pcie0_6_grp, pcie0_7_grp,
csu0_0_grp, csu0_1_grp, csu0_2_grp,
csu0_3_grp, csu0_4_grp, csu0_5_grp,
csu0_6_grp, csu0_7_grp, csu0_8_grp,
csu0_9_grp, csu0_10_grp, csu0_11_grp,
dpaux0_0_grp, dpaux0_1_grp, dpaux0_2_grp,
dpaux0_3_grp, pjtag0_0_grp, pjtag0_1_grp,
pjtag0_2_grp, pjtag0_3_grp, pjtag0_4_grp,
pjtag0_5_grp, trace0_0_grp, trace0_clk_0_grp,
trace0_1_grp, trace0_clk_1_grp, trace0_2_grp,
trace0_clk_2_grp, testscan0_0_grp]
maxItems: 78
function:
description:
Specify the alternative function to be configured for the
given pin groups.
enum: [ethernet0, ethernet1, ethernet2, ethernet3, gemtsu0, usb0, usb1, mdio0,
mdio1, mdio2, mdio3, qspi0, qspi_fbclk, qspi_ss, spi0, spi1, spi0_ss,
spi1_ss, sdio0, sdio0_pc, sdio0_wp, sdio0_cd, sdio1, sdio1_pc, sdio1_wp,
sdio1_cd, nand0, nand0_ce, nand0_rb, nand0_dqs, can0, can1, uart0, uart1,
i2c0, i2c1, ttc0_clk, ttc0_wav, ttc1_clk, ttc1_wav, ttc2_clk, ttc2_wav,
ttc3_clk, ttc3_wav, swdt0_clk, swdt0_rst, swdt1_clk, swdt1_rst, gpio0, pmu0,
pcie0, csu0, dpaux0, pjtag0, trace0, trace0_clk, testscan0]
required:
- groups
- function
additionalProperties: false
'^conf':
type: object
description:
Pinctrl node's client devices use subnodes for pin configurations,
which in turn use the standard properties below.
$ref: pincfg-node.yaml#
properties:
groups:
description:
List of pin groups as mentioned above.
pins:
description:
List of pin names to select in this subnode.
items:
pattern: '^MIO([0-9]|[1-6][0-9]|7[0-7])$'
maxItems: 78
bias-pull-up: true
bias-pull-down: true
bias-disable: true
input-schmitt-enable: true
input-schmitt-disable: true
bias-high-impedance: true
low-power-enable: true
low-power-disable: true
slew-rate:
enum: [0, 1]
drive-strength:
description:
Selects the drive strength for MIO pins, in mA.
enum: [2, 4, 8, 12]
power-source:
enum: [0, 1]
oneOf:
- required: [ groups ]
- required: [ pins ]
additionalProperties: false
additionalProperties: false
required:
- compatible
additionalProperties: false
examples:
- |
#include <dt-bindings/pinctrl/pinctrl-zynqmp.h>
zynqmp_firmware: zynqmp-firmware {
pinctrl0: pinctrl {
compatible = "xlnx,zynqmp-pinctrl";
pinctrl_uart1_default: uart1-default {
mux {
groups = "uart0_4_grp", "uart0_5_grp";
function = "uart0";
};
conf {
groups = "uart0_4_grp";
slew-rate = <SLEW_RATE_SLOW>;
power-source = <IO_STANDARD_LVCMOS18>;
};
conf-rx {
pins = "MIO18";
bias-pull-up;
};
conf-tx {
pins = "MIO19";
bias-disable;
input-schmitt-disable;
};
};
};
};
uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1_default>;
};
...

View File

@@ -4,7 +4,7 @@ This device supports I2C mode only.
Required properties:
- compatible : "asahi-kasei,ak5558"
- compatible : "asahi-kasei,ak5558" or "asahi-kasei,ak5552".
- reg : The I2C address of the device.
Optional properties:

View File

@@ -11,71 +11,59 @@ maintainers:
select: false
allOf:
- $ref: /schemas/graph.yaml#/$defs/port-base
properties:
port:
description: single OF-Graph subnode
type: object
prefix:
description: "device name prefix"
$ref: /schemas/types.yaml#/definitions/string
convert-rate:
description: CPU to Codec rate convert.
$ref: /schemas/types.yaml#/definitions/uint32
convert-channels:
description: CPU to Codec rate channels.
$ref: /schemas/types.yaml#/definitions/uint32
patternProperties:
"^endpoint(@[0-9a-f]+)?":
$ref: /schemas/graph.yaml#/$defs/endpoint-base
properties:
reg:
maxItems: 1
prefix:
description: "device name prefix"
$ref: /schemas/types.yaml#/definitions/string
mclk-fs:
description: |
Multiplication factor between stream rate and codec mclk.
When defined, mclk-fs property defined in dai-link sub nodes are
ignored.
$ref: /schemas/types.yaml#/definitions/uint32
frame-inversion:
description: dai-link uses frame clock inversion
$ref: /schemas/types.yaml#/definitions/flag
bitclock-inversion:
description: dai-link uses bit clock inversion
$ref: /schemas/types.yaml#/definitions/flag
frame-master:
description: Indicates dai-link frame master.
$ref: /schemas/types.yaml#/definitions/phandle
bitclock-master:
description: Indicates dai-link bit clock master
$ref: /schemas/types.yaml#/definitions/phandle
dai-format:
description: audio format.
items:
enum:
- i2s
- right_j
- left_j
- dsp_a
- dsp_b
- ac97
- pdm
- msb
- lsb
convert-rate:
description: CPU to Codec rate convert.
$ref: /schemas/types.yaml#/definitions/uint32
convert-channels:
description: CPU to Codec rate channels.
$ref: /schemas/types.yaml#/definitions/uint32
patternProperties:
"^endpoint(@[0-9a-f]+)?":
type: object
properties:
remote-endpoint:
maxItems: 1
mclk-fs:
description: |
Multiplication factor between stream rate and codec mclk.
When defined, mclk-fs property defined in dai-link sub nodes are
ignored.
$ref: /schemas/types.yaml#/definitions/uint32
frame-inversion:
description: dai-link uses frame clock inversion
$ref: /schemas/types.yaml#/definitions/flag
bitclock-inversion:
description: dai-link uses bit clock inversion
$ref: /schemas/types.yaml#/definitions/flag
frame-master:
description: Indicates dai-link frame master.
$ref: /schemas/types.yaml#/definitions/phandle
bitclock-master:
description: Indicates dai-link bit clock master
$ref: /schemas/types.yaml#/definitions/phandle
dai-format:
description: audio format.
items:
enum:
- i2s
- right_j
- left_j
- dsp_a
- dsp_b
- ac97
- pdm
- msb
- lsb
convert-rate:
description: CPU to Codec rate convert.
$ref: /schemas/types.yaml#/definitions/uint32
convert-channels:
description: CPU to Codec rate channels.
$ref: /schemas/types.yaml#/definitions/uint32
ports:
description: multi OF-Graph subnode
type: object
patternProperties:
"^port(@[0-9a-f]+)?":
$ref: "#/properties/port"
additionalProperties: true

View File

@@ -0,0 +1,108 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/sound/fsl,rpmsg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP Audio RPMSG CPU DAI Controller
maintainers:
- Shengjiu Wang <shengjiu.wang@nxp.com>
description: |
fsl_rpmsg is a virtual audio device. Mapping to real hardware devices
are SAI, DMA controlled by Cortex M core. What we see from Linux
side is a device which provides audio service by rpmsg channel.
properties:
compatible:
enum:
- fsl,imx7ulp-rpmsg-audio
- fsl,imx8mn-rpmsg-audio
- fsl,imx8mm-rpmsg-audio
- fsl,imx8mp-rpmsg-audio
model:
$ref: /schemas/types.yaml#/definitions/string
description: User specified audio sound card name
clocks:
items:
- description: Peripheral clock for register access
- description: Master clock
- description: DMA clock for DMA register access
- description: Parent clock for multiple of 8kHz sample rates
- description: Parent clock for multiple of 11kHz sample rates
clock-names:
items:
- const: ipg
- const: mclk
- const: dma
- const: pll8k
- const: pll11k
power-domains:
description:
List of phandle and PM domain specifier as documented in
Documentation/devicetree/bindings/power/power_domain.txt
maxItems: 1
memory-region:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle to a node describing reserved memory (System RAM memory)
The M core can't access all the DDR memory space on some platform,
So reserved a specific memory for dma buffer which M core can
access.
(see bindings/reserved-memory/reserved-memory.txt)
audio-codec:
$ref: /schemas/types.yaml#/definitions/phandle
description: The phandle to a node of audio codec
audio-routing:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
description: |
A list of the connections between audio components. Each entry is a
pair of strings, the first being the connection's sink, the second
being the connection's source.
fsl,enable-lpa:
$ref: /schemas/types.yaml#/definitions/flag
description: enable low power audio path.
fsl,rpmsg-out:
$ref: /schemas/types.yaml#/definitions/flag
description: |
This is a boolean property. If present, the transmitting function
will be enabled.
fsl,rpmsg-in:
$ref: /schemas/types.yaml#/definitions/flag
description: |
This is a boolean property. If present, the receiving function
will be enabled.
required:
- compatible
- model
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx8mn-clock.h>
rpmsg_audio: rpmsg_audio {
compatible = "fsl,imx8mn-rpmsg-audio";
model = "wm8524-audio";
fsl,enable-lpa;
fsl,rpmsg-out;
clocks = <&clk IMX8MN_CLK_SAI3_IPG>,
<&clk IMX8MN_CLK_SAI3_ROOT>,
<&clk IMX8MN_CLK_SDMA3_ROOT>,
<&clk IMX8MN_AUDIO_PLL1_OUT>,
<&clk IMX8MN_AUDIO_PLL2_OUT>;
clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k";
};

View File

@@ -42,6 +42,8 @@ The compatible list for this generic sound card currently:
"fsl,imx-audio-si476x"
"fsl,imx-audio-wm8958"
Required properties:
- compatible : Contains one of entries in the compatible list.

View File

@@ -81,6 +81,6 @@ examples:
interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "osc", "apb_clk";
clocks = <&scmi_clk KEEM_BAY_PSS_AUX_I2S3>, <&scmi_clk KEEM_BAY_PSS_I2S3>;
dmas = <&axi_dma0 29 &axi_dma0 33>;
dmas = <&axi_dma0 29>, <&axi_dma0 33>;
dma-names = "tx", "rx";
};

View File

@@ -9,9 +9,6 @@ title: Marvel SSPA Digital Audio Interface Bindings
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
allOf:
- $ref: audio-graph-port.yaml#
properties:
$nodename:
pattern: "^audio-controller(@.*)?$"
@@ -54,7 +51,8 @@ properties:
- const: rx
port:
type: object
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
properties:
endpoint:

View File

@@ -0,0 +1,108 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/sound/mchp,i2s-mcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip I2S Multi-Channel Controller
maintainers:
- Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
description:
The I2SMCC complies with the Inter-IC Sound (I2S) bus specification and
supports a Time Division Multiplexed (TDM) interface with external
multi-channel audio codecs. It consists of a receiver, a transmitter and a
common clock generator that can be enabled separately to provide Adapter,
Client or Controller modes with receiver and/or transmitter active.
On later I2SMCC versions (starting with Microchip's SAMA7G5) I2S
multi-channel is supported by using multiple data pins, output and
input, without TDM.
properties:
"#sound-dai-cells":
const: 0
compatible:
enum:
- microchip,sam9x60-i2smcc
- microchip,sama7g5-i2smcc
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: Peripheral Bus Clock
- description: Generic Clock (Optional). Should be set mostly when Master
Mode is required.
minItems: 1
clock-names:
items:
- const: pclk
- const: gclk
minItems: 1
dmas:
items:
- description: TX DMA Channel
- description: RX DMA Channel
dma-names:
items:
- const: tx
- const: rx
microchip,tdm-data-pair:
description:
Represents the DIN/DOUT pair pins that are used to receive/send
TDM data. It is optional and it is only needed if the controller
uses the TDM mode.
$ref: /schemas/types.yaml#/definitions/uint8
enum: [0, 1, 2, 3]
default: 0
if:
properties:
compatible:
const: microchip,sam9x60-i2smcc
then:
properties:
microchip,tdm-data-pair: false
required:
- "#sound-dai-cells"
- compatible
- reg
- interrupts
- clocks
- clock-names
- dmas
- dma-names
additionalProperties: false
examples:
- |
#include <dt-bindings/dma/at91.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
i2s@f001c000 {
#sound-dai-cells = <0>;
compatible = "microchip,sam9x60-i2smcc";
reg = <0xf001c000 0x100>;
interrupts = <34 IRQ_TYPE_LEVEL_HIGH 7>;
dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
AT91_XDMAC_DT_PERID(36))>,
<&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
AT91_XDMAC_DT_PERID(37))>;
dma-names = "tx", "rx";
clocks = <&i2s_clk>, <&i2s_gclk>;
clock-names = "pclk", "gclk";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2s_default>;
};

View File

@@ -1,43 +0,0 @@
* Microchip I2S Multi-Channel Controller
Required properties:
- compatible: Should be "microchip,sam9x60-i2smcc".
- reg: Should be the physical base address of the controller and the
length of memory mapped region.
- interrupts: Should contain the interrupt for the controller.
- dmas: Should be one per channel name listed in the dma-names property,
as described in atmel-dma.txt and dma.txt files.
- dma-names: Identifier string for each DMA request line in the dmas property.
Two dmas have to be defined, "tx" and "rx".
- clocks: Must contain an entry for each entry in clock-names.
Please refer to clock-bindings.txt.
- clock-names: Should be one of each entry matching the clocks phandles list:
- "pclk" (peripheral clock) Required.
- "gclk" (generated clock) Optional (1).
Optional properties:
- pinctrl-0: Should specify pin control groups used for this controller.
- princtrl-names: Should contain only one value - "default".
(1) : Only the peripheral clock is required. The generated clock is optional
and should be set mostly when Master Mode is required.
Example:
i2s@f001c000 {
compatible = "microchip,sam9x60-i2smcc";
reg = <0xf001c000 0x100>;
interrupts = <34 IRQ_TYPE_LEVEL_HIGH 7>;
dmas = <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
AT91_XDMAC_DT_PERID(36))>,
<&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
AT91_XDMAC_DT_PERID(37))>;
dma-names = "tx", "rx";
clocks = <&i2s_clk>, <&i2s_gclk>;
clock-names = "pclk", "gclk";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2s_default>;
};

View File

@@ -4,6 +4,7 @@ Required properties:
- compatible : "mediatek,mt8183_mt6358_ts3a227_max98357" for MAX98357A codec
"mediatek,mt8183_mt6358_ts3a227_max98357b" for MAX98357B codec
"mediatek,mt8183_mt6358_ts3a227_rt1015" for RT1015 codec
"mediatek,mt8183_mt6358_ts3a227_rt1015p" for RT1015P codec
- mediatek,platform: the phandle of MT8183 ASoC platform
Optional properties:

View File

@@ -17,9 +17,6 @@ maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Sameer Pujar <spujar@nvidia.com>
allOf:
- $ref: audio-graph-port.yaml#
properties:
$nodename:
pattern: "^dspk@[0-9a-f]*$"
@@ -59,14 +56,18 @@ properties:
available instances on a Tegra SoC.
ports:
type: object
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
description: |
DSPK ACIF (Audio Client Interface) port connected to the
corresponding AHUB (Audio Hub) ACIF port.
port@1:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
description: |
DSPK DAP (Digital Audio Port) interface which can be connected
to external audio codec for playback.
@@ -80,7 +81,7 @@ required:
- assigned-clock-parents
- sound-name-prefix
unevaluatedProperties: false
additionalProperties: false
examples:
- |

View File

@@ -17,9 +17,6 @@ maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Sameer Pujar <spujar@nvidia.com>
allOf:
- $ref: audio-graph-port.yaml#
properties:
$nodename:
pattern: "^admaif@[0-9a-f]*$"
@@ -41,6 +38,7 @@ properties:
dma-names: true
ports:
$ref: /schemas/graph.yaml#/properties/ports
description: |
Contains list of ACIF (Audio CIF) port nodes for ADMAIF channels.
The number of port nodes depends on the number of ADMAIF channels
@@ -48,6 +46,11 @@ properties:
in AHUB (Audio Hub). Each port is capable of data transfers in
both directions.
patternProperties:
'^port@[0-9]':
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
if:
properties:
compatible:
@@ -92,7 +95,7 @@ required:
- dmas
- dma-names
unevaluatedProperties: false
additionalProperties: false
examples:
- |

View File

@@ -17,9 +17,6 @@ maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Sameer Pujar <spujar@nvidia.com>
allOf:
- $ref: audio-graph-port.yaml#
properties:
$nodename:
pattern: "^ahub@[0-9a-f]*$"
@@ -60,12 +57,34 @@ properties:
ranges: true
ports:
$ref: /schemas/graph.yaml#/properties/ports
description: |
Contains list of ACIF (Audio CIF) port nodes for AHUB (Audio Hub).
These are connected to ACIF interfaces of AHUB clients. Thus the
number of port nodes depend on the number of clients that AHUB may
have depending on the SoC revision.
patternProperties:
'^port@[0-9]':
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
patternProperties:
'^i2s@[0-9a-f]+$':
type: object
'^dmic@[0-9a-f]+$':
type: object
$ref: nvidia,tegra210-dmic.yaml#
'^admaif@[0-9a-f]+$':
type: object
$ref: nvidia,tegra210-admaif.yaml#
'^dspk@[0-9a-f]+$':
type: object
$ref: nvidia,tegra186-dspk.yaml#
required:
- compatible
- reg
@@ -77,7 +96,7 @@ required:
- "#size-cells"
- ranges
unevaluatedProperties: false
additionalProperties: false
examples:
- |

View File

@@ -16,9 +16,6 @@ maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Sameer Pujar <spujar@nvidia.com>
allOf:
- $ref: audio-graph-port.yaml#
properties:
$nodename:
pattern: "^dmic@[0-9a-f]*$"
@@ -60,14 +57,18 @@ properties:
on the maximum available instances on a Tegra SoC.
ports:
type: object
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
description: |
DMIC ACIF (Audio Client Interface) port connected to the
corresponding AHUB (Audio Hub) ACIF port.
port@1:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
description: |
DMIC DAP (Digital Audio Port) interface which can be connected
to external audio codec for capture.
@@ -80,7 +81,7 @@ required:
- assigned-clocks
- assigned-clock-parents
unevaluatedProperties: false
additionalProperties: false
examples:
- |

View File

@@ -16,9 +16,6 @@ maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Sameer Pujar <spujar@nvidia.com>
allOf:
- $ref: audio-graph-port.yaml#
properties:
$nodename:
pattern: "^i2s@[0-9a-f]*$"
@@ -78,14 +75,18 @@ properties:
on the maximum available instances on a Tegra SoC.
ports:
type: object
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
description: |
I2S ACIF (Audio Client Interface) port connected to the
corresponding AHUB (Audio Hub) ACIF port.
port@1:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
description: |
I2S DAP (Digital Audio Port) interface which can be connected
to external audio codec for playback or capture.
@@ -98,7 +99,7 @@ required:
- assigned-clocks
- assigned-clock-parents
unevaluatedProperties: false
additionalProperties: false
examples:
- |

View File

@@ -110,7 +110,9 @@ properties:
- pattern: '^dvc\.[0-1]$'
- pattern: '^clk_(a|b|c|i)$'
port: true
port:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
# use patternProperties to avoid naming "xxx,yyy" issue
patternProperties:
@@ -256,7 +258,6 @@ required:
allOf:
- $ref: audio-graph.yaml#
- $ref: audio-graph-port.yaml#
- if:
properties:
compatible:

View File

@@ -0,0 +1,35 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/sound/rt1019.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: RT1019 Mono Class-D Audio Amplifier
maintainers:
- jack.yu@realtek.com
properties:
compatible:
const: realtek,rt1019
reg:
maxItems: 1
description: I2C address of the device.
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
rt1019: codec@28 {
compatible = "realtek,rt1019";
reg = <0x28>;
};
};

View File

@@ -44,7 +44,7 @@ Optional properties:
- realtek,dmic-delay-ms : Set the delay time (ms) for the requirement of
the particular DMIC.
- realtek,dmic-clk-driving-high : Set the high drving of the DMIC clock out.
- realtek,dmic-clk-driving-high : Set the high driving of the DMIC clock out.
Pins on the device (for linking into audio routes) for RT5682:

View File

@@ -46,11 +46,9 @@ properties:
patternProperties:
"^port@[0-9]$":
type: object
properties:
endpoint: true
required:
- endpoint
description: FIXME, Need to define what each port is.
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
additionalProperties: false

View File

@@ -40,11 +40,9 @@ properties:
patternProperties:
"^port@[0-9]$":
type: object
properties:
endpoint: true
required:
- endpoint
description: FIXME, Need to define what each port is.
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
additionalProperties: false

View File

@@ -1,6 +1,6 @@
Texas Instruments - tlv320aic3x Codec module
The tlv320aic3x serial control bus communicates through I2C protocols
The tlv320aic3x serial control bus communicates through both I2C and SPI bus protocols
Required properties:
@@ -63,7 +63,7 @@ CODEC input pins for other compatible codecs:
The pins can be used in referring sound node's audio-routing property.
Example:
I2C example:
#include <dt-bindings/gpio/gpio.h>
@@ -78,3 +78,20 @@ tlv320aic3x: tlv320aic3x@1b {
DRVDD-supply = <&regulator>;
DVDD-supply = <&regulator>;
};
SPI example:
spi0: spi@f0000000 {
tlv320aic3x: codec@0 {
compatible = "ti,tlv320aic3x";
reg = <0>; /* CS number */
#sound-dai-cells = <0>;
spi-max-frequency = <1000000>;
AVDD-supply = <&regulator>;
IOVDD-supply = <&regulator>;
DRVDD-supply = <&regulator>;
DVDD-supply = <&regulator>;
ai3x-ocmv = <0>;
};
};

View File

@@ -461,7 +461,7 @@ pin controller?
This is done by registering "ranges" of pins, which are essentially
cross-reference tables. These are described in
Documentation/driver-api/pinctl.rst
Documentation/driver-api/pin-control.rst
While the pin allocation is totally managed by the pinctrl subsystem,
gpio (under gpiolib) is still maintained by gpio drivers. It may happen

View File

@@ -62,7 +62,7 @@ available subsections can be seen below.
80211/index
uio-howto
firmware/index
pinctl
pin-control
gpio/index
md/index
media/index

View File

@@ -1235,7 +1235,7 @@ default state like this::
foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT);
if (IS_ERR(foo->s)) {
/* FIXME: clean up "foo" here */
return PTR_ERR(s);
return PTR_ERR(foo->s);
}
ret = pinctrl_select_state(foo->s);
@@ -1428,3 +1428,40 @@ on the pins defined by group B::
The above has to be done from process context. The reservation of the pins
will be done when the state is activated, so in effect one specific pin
can be used by different functions at different times on a running system.
Debugfs files
=============
These files are created in ``/sys/kernel/debug/pinctrl``:
- ``pinctrl-devices``: prints each pin controller device along with columns to
indicate support for pinmux and pinconf
- ``pinctrl-handles``: prints each configured pin controller handle and the
corresponding pinmux maps
- ``pinctrl-maps``: print all pinctrl maps
A sub-directory is created inside of ``/sys/kernel/debug/pinctrl`` for each pin
controller device containing these files:
- ``pins``: prints a line for each pin registered on the pin controller. The
pinctrl driver may add additional information such as register contents.
- ``gpio-ranges``: print ranges that map gpio lines to pins on the controller
- ``pingroups``: print all pin groups registered on the pin controller
- ``pinconf-pins``: print pin config settings for each pin
- ``pinconf-groups``: print pin config settings per pin group
- ``pinmux-functions``: print each pin function along with the pin groups that
map to the pin function
- ``pinmux-pins``: iterate through all pins and print mux owner, gpio owner
and if the pin is a hog
- ``pinmux-select``: write to this file to activate a pin function for a group::
echo "<group-name function-name>" > pinmux-select

View File

@@ -21,7 +21,7 @@
| nios2: | TODO |
| openrisc: | TODO |
| parisc: | TODO |
| powerpc: | TODO |
| powerpc: | ok |
| riscv: | ok |
| s390: | ok |
| sh: | TODO |

View File

@@ -40,17 +40,17 @@ On 64bit systems, even if all overlay layers are not on the same
underlying filesystem, the same compliant behavior could be achieved
with the "xino" feature. The "xino" feature composes a unique object
identifier from the real object st_ino and an underlying fsid index.
If all underlying filesystems support NFS file handles and export file
handles with 32bit inode number encoding (e.g. ext4), overlay filesystem
will use the high inode number bits for fsid. Even when the underlying
filesystem uses 64bit inode numbers, users can still enable the "xino"
feature with the "-o xino=on" overlay mount option. That is useful for the
case of underlying filesystems like xfs and tmpfs, which use 64bit inode
numbers, but are very unlikely to use the high inode number bits. In case
The "xino" feature uses the high inode number bits for fsid, because the
underlying filesystems rarely use the high inode number bits. In case
the underlying inode number does overflow into the high xino bits, overlay
filesystem will fall back to the non xino behavior for that inode.
The "xino" feature can be enabled with the "-o xino=on" overlay mount option.
If all underlying filesystems support NFS file handles, the value of st_ino
for overlay filesystem objects is not only unique, but also persistent over
the lifetime of the filesystem. The "-o xino=auto" overlay mount option
enables the "xino" feature only if the persistent st_ino requirement is met.
The following table summarizes what can be expected in different overlay
configurations.
@@ -66,14 +66,13 @@ Inode properties
| All layers | Y | Y | Y | Y | Y | Y | Y | Y |
| on same fs | | | | | | | | |
+--------------+-----+------+-----+------+--------+--------+--------+-------+
| Layers not | N | Y | Y | N | N | Y | N | Y |
| Layers not | N | N | Y | N | N | Y | N | Y |
| on same fs, | | | | | | | | |
| xino=off | | | | | | | | |
+--------------+-----+------+-----+------+--------+--------+--------+-------+
| xino=on/auto | Y | Y | Y | Y | Y | Y | Y | Y |
| | | | | | | | | |
+--------------+-----+------+-----+------+--------+--------+--------+-------+
| xino=on/auto,| N | Y | Y | N | N | Y | N | Y |
| xino=on/auto,| N | N | Y | N | N | Y | N | Y |
| ino overflow | | | | | | | | |
+--------------+-----+------+-----+------+--------+--------+--------+-------+
@@ -81,7 +80,6 @@ Inode properties
/proc files, such as /proc/locks and /proc/self/fdinfo/<fd> of an inotify
file descriptor.
Upper and Lower
---------------
@@ -461,7 +459,7 @@ enough free bits in the inode number, then overlayfs will not be able to
guarantee that the values of st_ino and st_dev returned by stat(2) and the
value of d_ino returned by readdir(3) will act like on a normal filesystem.
E.g. the value of st_dev may be different for two objects in the same
overlay filesystem and the value of st_ino for directory objects may not be
overlay filesystem and the value of st_ino for filesystem objects may not be
persistent and could change even while the overlay filesystem is mounted, as
summarized in the `Inode properties`_ table above.
@@ -476,7 +474,7 @@ a crash or deadlock.
Offline changes, when the overlay is not mounted, are allowed to the
upper tree. Offline changes to the lower tree are only allowed if the
"metadata only copy up", "inode index", and "redirect_dir" features
"metadata only copy up", "inode index", "xino" and "redirect_dir" features
have not been used. If the lower tree is modified and any of these
features has been used, the behavior of the overlay is undefined,
though it will not result in a crash or deadlock.

View File

@@ -275,6 +275,20 @@ Health Bitmap Flags:
Given a DRC Index collect the performance statistics for NVDIMM and copy them
to the resultBuffer.
**H_SCM_FLUSH**
| Input: *drcIndex, continue-token*
| Out: *continue-token*
| Return Value: *H_SUCCESS, H_Parameter, H_P2, H_BUSY*
Given a DRC Index Flush the data to backend NVDIMM device.
The hcall returns H_BUSY when the flush takes longer time and the hcall needs
to be issued multiple times in order to be completely serviced. The
*continue-token* from the output to be passed in the argument list of
subsequent hcalls to the hypervisor until the hcall is completely serviced
at which point H_SUCCESS or other error is returned by the hypervisor.
References
==========
.. [1] "Power Architecture Platform Reference"

View File

@@ -254,7 +254,7 @@ using this window. the signal will be issued to the thread group leader
signals.
NX-GZIP User's Manual:
https://github.com/libnxz/power-gzip/blob/master/power_nx_gzip_um.pdf
https://github.com/libnxz/power-gzip/blob/master/doc/power_nx_gzip_um.pdf
Simple example
==============
@@ -301,5 +301,5 @@ Simple example
close(fd) or window can be closed upon process exit
}
Refer https://github.com/abalib/power-gzip for tests or more
Refer https://github.com/libnxz/power-gzip for tests or more
use cases.

View File

@@ -47,7 +47,7 @@ size change due to this facility.
text data bss dec hex filename
48800 2445 644 51889 cab1 mm/page_alloc.o
6574 108 29 6711 1a37 mm/page_owner.o
6662 108 29 6799 1a8f mm/page_owner.o
1025 8 8 1041 411 mm/page_ext.o
Although, roughly, 8 KB code is added in total, page_alloc.o increase by

View File

@@ -53,11 +53,6 @@ prevent the page from being split by anyone.
of handling GUP on hugetlbfs will also work fine on transparent
hugepage backed mappings.
In case you can't handle compound pages if they're returned by
follow_page, the FOLL_SPLIT bit can be specified as a parameter to
follow_page, so that it will split the hugepages before returning
them.
Graceful fallback
=================

View File

@@ -4663,6 +4663,11 @@ F: drivers/counter/
F: include/linux/counter.h
F: include/linux/counter_enum.h
CP2615 I2C DRIVER
M: Bence Csókás <bence98@sch.bme.hu>
S: Maintained
F: drivers/i2c/busses/i2c-cp2615.c
CPMAC ETHERNET DRIVER
M: Florian Fainelli <f.fainelli@gmail.com>
L: netdev@vger.kernel.org
@@ -7236,6 +7241,13 @@ S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
F: drivers/i2c/busses/i2c-imx-lpi2c.c
FREESCALE MPC I2C DRIVER
M: Chris Packham <chris.packham@alliedtelesis.co.nz>
L: linux-i2c@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
F: drivers/i2c/busses/i2c-mpc.c
FREESCALE QORIQ DPAA ETHERNET DRIVER
M: Madalin Bucur <madalin.bucur@nxp.com>
L: netdev@vger.kernel.org
@@ -7433,6 +7445,13 @@ F: fs/verity/
F: include/linux/fsverity.h
F: include/uapi/linux/fsverity.h
FT260 FTDI USB-HID TO I2C BRIDGE DRIVER
M: Michael Zaidman <michael.zaidman@gmail.com>
L: linux-i2c@vger.kernel.org
L: linux-input@vger.kernel.org
S: Maintained
F: drivers/hid/hid-ft260.c
FUJITSU LAPTOP EXTRAS
M: Jonathan Woithe <jwoithe@just42.net>
L: platform-driver-x86@vger.kernel.org
@@ -8151,6 +8170,13 @@ F: drivers/crypto/hisilicon/hpre/hpre.h
F: drivers/crypto/hisilicon/hpre/hpre_crypto.c
F: drivers/crypto/hisilicon/hpre/hpre_main.c
HISILICON I2C CONTROLLER DRIVER
M: Yicong Yang <yangyicong@hisilicon.com>
L: linux-i2c@vger.kernel.org
S: Maintained
W: https://www.hisilicon.com
F: drivers/i2c/busses/i2c-hisi.c
HISILICON LPC BUS DRIVER
M: john.garry@huawei.com
S: Maintained
@@ -11752,6 +11778,7 @@ F: include/linux/gfp.h
F: include/linux/memory_hotplug.h
F: include/linux/mm.h
F: include/linux/mmzone.h
F: include/linux/pagewalk.h
F: include/linux/vmalloc.h
F: mm/
@@ -12087,6 +12114,13 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git
F: drivers/platform/surface/
MICROSOFT SURFACE HID TRANSPORT DRIVER
M: Maximilian Luz <luzmaximilian@gmail.com>
L: linux-input@vger.kernel.org
L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/hid/surface-hid/
MICROSOFT SURFACE HOT-PLUG DRIVER
M: Maximilian Luz <luzmaximilian@gmail.com>
L: platform-driver-x86@vger.kernel.org
@@ -14345,7 +14379,7 @@ L: linux-gpio@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
F: Documentation/devicetree/bindings/pinctrl/
F: Documentation/driver-api/pinctl.rst
F: Documentation/driver-api/pin-control.rst
F: drivers/pinctrl/
F: include/linux/pinctrl/
@@ -19336,6 +19370,15 @@ W: https://virtio-mem.gitlab.io/
F: drivers/virtio/virtio_mem.c
F: include/uapi/linux/virtio_mem.h
VIRTIO SOUND DRIVER
M: Anton Yakovlev <anton.yakovlev@opensynergy.com>
M: "Michael S. Tsirkin" <mst@redhat.com>
L: virtualization@lists.linux-foundation.org
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: include/uapi/linux/virtio_snd.h
F: sound/virtio/*
VIRTUAL BOX GUEST DEVICE DRIVER
M: Hans de Goede <hdegoede@redhat.com>
M: Arnd Bergmann <arnd@arndb.de>

View File

@@ -829,6 +829,17 @@ config HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
config HAVE_ARCH_HUGE_VMAP
bool
#
# Archs that select this would be capable of PMD-sized vmaps (i.e.,
# arch_vmap_pmd_supported() returns true), and they must make no assumptions
# that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag
# can be used to prohibit arch-specific allocations from using hugepages to
# help with this (e.g., modules may require it).
#
config HAVE_ARCH_HUGE_VMALLOC
depends on HAVE_ARCH_HUGE_VMAP
bool
config ARCH_WANT_HUGE_PMD_SHARE
bool

View File

@@ -282,5 +282,4 @@ mem_init(void)
set_max_mapnr(max_low_pfn);
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
memblock_free_all();
mem_init_print_info(NULL);
}

View File

@@ -194,7 +194,6 @@ void __init mem_init(void)
{
memblock_free_all();
highmem_init();
mem_init_print_info(NULL);
}
#ifdef CONFIG_HIGHMEM

View File

@@ -33,6 +33,7 @@ config ARM
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_USE_MEMTEST
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_WANT_LD_ORPHAN_WARN

View File

@@ -186,8 +186,6 @@ static inline pte_t pte_mkspecial(pte_t pte)
#define pmd_write(pmd) (pmd_isclear((pmd), L_PMD_SECT_RDONLY))
#define pmd_dirty(pmd) (pmd_isset((pmd), L_PMD_SECT_DIRTY))
#define pud_page(pud) pmd_page(__pmd(pud_val(pud)))
#define pud_write(pud) pmd_write(__pmd(pud_val(pud)))
#define pmd_hugewillfault(pmd) (!pmd_young(pmd) || !pmd_write(pmd))
#define pmd_thp_or_huge(pmd) (pmd_huge(pmd) || pmd_trans_huge(pmd))

View File

@@ -166,6 +166,9 @@ extern struct page *empty_zero_page;
extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
#define pud_page(pud) pmd_page(__pmd(pud_val(pud)))
#define pud_write(pud) pmd_write(__pmd(pud_val(pud)))
#define pmd_none(pmd) (!pmd_val(pmd))
static inline pte_t *pmd_page_vaddr(pmd_t pmd)

View File

@@ -454,6 +454,10 @@ static const struct property_entry da830_evm_i2c_eeprom_properties[] = {
{ }
};
static const struct software_node da830_evm_i2c_eeprom_node = {
.properties = da830_evm_i2c_eeprom_properties,
};
static int __init da830_evm_ui_expander_setup(struct i2c_client *client,
int gpio, unsigned ngpio, void *context)
{
@@ -485,7 +489,7 @@ static struct pcf857x_platform_data __initdata da830_evm_ui_expander_info = {
static struct i2c_board_info __initdata da830_evm_i2c_devices[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
.properties = da830_evm_i2c_eeprom_properties,
.swnode = &da830_evm_i2c_eeprom_node,
},
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),

View File

@@ -232,10 +232,14 @@ static const struct property_entry eeprom_properties[] = {
{ }
};
static const struct software_node eeprom_node = {
.properties = eeprom_properties,
};
static struct i2c_board_info i2c_info[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
.properties = eeprom_properties,
.swnode = &eeprom_node,
},
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),

View File

@@ -541,6 +541,10 @@ static const struct property_entry eeprom_properties[] = {
{ }
};
static const struct software_node eeprom_node = {
.properties = eeprom_properties,
};
/*
* MSP430 supports RTC, card detection, input from IR remote, and
* a bit more. It triggers interrupts on GPIO(7) from pressing
@@ -647,7 +651,7 @@ static struct i2c_board_info __initdata i2c_info[] = {
},
{
I2C_BOARD_INFO("24c256", 0x50),
.properties = eeprom_properties,
.swnode = &eeprom_node,
},
{
I2C_BOARD_INFO("tlv320aic33", 0x1b),

View File

@@ -362,6 +362,10 @@ static const struct property_entry eeprom_properties[] = {
PROPERTY_ENTRY_U32("pagesize", 64),
{ }
};
static const struct software_node eeprom_node = {
.properties = eeprom_properties,
};
#endif
static u8 dm646x_iis_serializer_direction[] = {
@@ -430,7 +434,7 @@ static void evm_init_cpld(void)
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
.properties = eeprom_properties,
.swnode = &eeprom_node,
},
{
I2C_BOARD_INFO("pcf8574a", 0x38),

View File

@@ -197,6 +197,10 @@ static const struct property_entry mityomapl138_fd_chip_properties[] = {
{ }
};
static const struct software_node mityomapl138_fd_chip_node = {
.properties = mityomapl138_fd_chip_properties,
};
static struct davinci_i2c_platform_data mityomap_i2c_0_pdata = {
.bus_freq = 100, /* kHz */
.bus_delay = 0, /* usec */
@@ -323,7 +327,7 @@ static struct i2c_board_info __initdata mityomap_tps65023_info[] = {
},
{
I2C_BOARD_INFO("24c02", 0x50),
.properties = mityomapl138_fd_chip_properties,
.swnode = &mityomapl138_fd_chip_node,
},
};

View File

@@ -84,10 +84,14 @@ static const struct property_entry eeprom_properties[] = {
{ }
};
static const struct software_node eeprom_node = {
.properties = eeprom_properties,
};
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO("24c64", 0x50),
.properties = eeprom_properties,
.swnode = &eeprom_node,
},
/* Other I2C devices:
* MSP430, addr 0x23 (not used)

View File

@@ -332,11 +332,15 @@ static const struct property_entry mistral_at24_properties[] = {
{ }
};
static const struct software_node mistral_at24_node = {
.properties = mistral_at24_properties,
};
static struct i2c_board_info __initdata mistral_i2c_board_info[] = {
{
/* NOTE: powered from LCD supply */
I2C_BOARD_INFO("24c04", 0x50),
.properties = mistral_at24_properties,
.swnode = &mistral_at24_node,
},
/* TODO when driver support is ready:
* - optionally ov9640 camera sensor at 0x30

View File

@@ -794,6 +794,10 @@ static const struct property_entry pca9500_eeprom_properties[] = {
{ }
};
static const struct software_node pca9500_eeprom_node = {
.properties = pca9500_eeprom_properties,
};
/**
* stargate2_reset_bluetooth() reset the bluecore to ensure consistent state
**/
@@ -929,7 +933,7 @@ static struct i2c_board_info __initdata stargate2_i2c_board_info[] = {
}, {
.type = "24c02",
.addr = 0x57,
.properties = pca9500_eeprom_properties,
.swnode = &pca9500_eeprom_node,
}, {
.type = "max1238",
.addr = 0x35,

View File

@@ -542,10 +542,14 @@ static const struct property_entry mini2440_at24_properties[] = {
{ }
};
static const struct software_node mini2440_at24_node = {
.properties = mini2440_at24_properties,
};
static struct i2c_board_info mini2440_i2c_devs[] __initdata = {
{
I2C_BOARD_INFO("24c08", 0x50),
.properties = mini2440_at24_properties,
.swnode = &mini2440_at24_node,
},
};

View File

@@ -13,6 +13,7 @@
#include <linux/init.h>
#include <linux/mm.h>
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <asm/tlbflush.h>
#include <asm/cacheflush.h>

View File

@@ -8,6 +8,7 @@
#include <linux/spinlock.h>
#include <linux/mm.h>
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <asm/shmparam.h>
#include <asm/tlbflush.h>

View File

@@ -13,6 +13,7 @@
#include <linux/init.h>
#include <linux/mm.h>
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <asm/tlbflush.h>
#include <asm/cacheflush.h>

View File

@@ -316,8 +316,6 @@ void __init mem_init(void)
free_highpages();
mem_init_print_info(NULL);
/*
* Check boundaries twice: Some fundamental inconsistencies can
* be detected at build time already.

View File

@@ -67,6 +67,7 @@ config ARM64
select ARCH_KEEP_MEMBLOCK
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_USE_GNU_PROPERTY
select ARCH_USE_MEMTEST
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
select ARCH_USE_SYM_ANNOTATIONS

View File

@@ -231,9 +231,7 @@ config ARCH_RENESAS
config ARCH_ROCKCHIP
bool "Rockchip Platforms"
select ARCH_HAS_RESET_CONTROLLER
select GPIOLIB
select PINCTRL
select PINCTRL_ROCKCHIP
select PM
select ROCKCHIP_TIMER
help

View File

@@ -250,8 +250,8 @@ static inline const void *__tag_set(const void *addr, u8 tag)
#define arch_init_tags(max_tag) mte_init_tags(max_tag)
#define arch_get_random_tag() mte_get_random_tag()
#define arch_get_mem_tag(addr) mte_get_mem_tag(addr)
#define arch_set_mem_tag_range(addr, size, tag) \
mte_set_mem_tag_range((addr), (size), (tag))
#define arch_set_mem_tag_range(addr, size, tag, init) \
mte_set_mem_tag_range((addr), (size), (tag), (init))
#endif /* CONFIG_KASAN_HW_TAGS */
/*

View File

@@ -53,7 +53,8 @@ static inline u8 mte_get_random_tag(void)
* Note: The address must be non-NULL and MTE_GRANULE_SIZE aligned and
* size must be non-zero and MTE_GRANULE_SIZE aligned.
*/
static inline void mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
static inline void mte_set_mem_tag_range(void *addr, size_t size,
u8 tag, bool init)
{
u64 curr, end;
@@ -63,18 +64,27 @@ static inline void mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
curr = (u64)__tag_set(addr, tag);
end = curr + size;
do {
/*
* 'asm volatile' is required to prevent the compiler to move
* the statement outside of the loop.
*/
asm volatile(__MTE_PREAMBLE "stg %0, [%0]"
:
: "r" (curr)
: "memory");
curr += MTE_GRANULE_SIZE;
} while (curr != end);
/*
* 'asm volatile' is required to prevent the compiler to move
* the statement outside of the loop.
*/
if (init) {
do {
asm volatile(__MTE_PREAMBLE "stzg %0, [%0]"
:
: "r" (curr)
: "memory");
curr += MTE_GRANULE_SIZE;
} while (curr != end);
} else {
do {
asm volatile(__MTE_PREAMBLE "stg %0, [%0]"
:
: "r" (curr)
: "memory");
curr += MTE_GRANULE_SIZE;
} while (curr != end);
}
}
void mte_enable_kernel_sync(void);
@@ -101,7 +111,8 @@ static inline u8 mte_get_random_tag(void)
return 0xFF;
}
static inline void mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
static inline void mte_set_mem_tag_range(void *addr, size_t size,
u8 tag, bool init)
{
}

View File

@@ -155,7 +155,8 @@ static __always_inline const struct vdso_data *__arch_get_vdso_data(void)
}
#ifdef CONFIG_TIME_NS
static __always_inline const struct vdso_data *__arch_get_timens_vdso_data(void)
static __always_inline
const struct vdso_data *__arch_get_timens_vdso_data(const struct vdso_data *vd)
{
const struct vdso_data *ret;

View File

@@ -96,7 +96,7 @@ const struct vdso_data *__arch_get_vdso_data(void)
#ifdef CONFIG_TIME_NS
static __always_inline
const struct vdso_data *__arch_get_timens_vdso_data(void)
const struct vdso_data *__arch_get_timens_vdso_data(const struct vdso_data *vd)
{
return _timens_data;
}

View File

@@ -1,4 +1,28 @@
#ifndef _ASM_ARM64_VMALLOC_H
#define _ASM_ARM64_VMALLOC_H
#include <asm/page.h>
#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
#define arch_vmap_pud_supported arch_vmap_pud_supported
static inline bool arch_vmap_pud_supported(pgprot_t prot)
{
/*
* Only 4k granule supports level 1 block mappings.
* SW table walks can't handle removal of intermediate entries.
*/
return IS_ENABLED(CONFIG_ARM64_4K_PAGES) &&
!IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
}
#define arch_vmap_pmd_supported arch_vmap_pmd_supported
static inline bool arch_vmap_pmd_supported(pgprot_t prot)
{
/* See arch_vmap_pud_supported() */
return !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
}
#endif
#endif /* _ASM_ARM64_VMALLOC_H */

View File

@@ -491,8 +491,6 @@ void __init mem_init(void)
/* this will put all unused low memory onto the freelists */
memblock_free_all();
mem_init_print_info(NULL);
/*
* Check boundaries twice: Some fundamental inconsistencies can be
* detected at build time already.
@@ -521,7 +519,7 @@ void free_initmem(void)
* prevents the region from being reused for kernel modules, which
* is not supported by kallsyms.
*/
unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
vunmap_range((u64)__init_begin, (u64)__init_end);
}
void dump_mem_limit(void)

View File

@@ -1339,27 +1339,6 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
return dt_virt;
}
int __init arch_ioremap_p4d_supported(void)
{
return 0;
}
int __init arch_ioremap_pud_supported(void)
{
/*
* Only 4k granule supports level 1 block mappings.
* SW table walks can't handle removal of intermediate entries.
*/
return IS_ENABLED(CONFIG_ARM64_4K_PAGES) &&
!IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
}
int __init arch_ioremap_pmd_supported(void)
{
/* See arch_ioremap_pud_supported() */
return !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
}
int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot)
{
pud_t new_pud = pfn_pud(__phys_to_pfn(phys), mk_pud_sect_prot(prot));
@@ -1451,11 +1430,6 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
return 1;
}
int p4d_free_pud_page(p4d_t *p4d, unsigned long addr)
{
return 0; /* Don't attempt a block mapping */
}
#ifdef CONFIG_MEMORY_HOTPLUG
static void __remove_pgd_mapping(pgd_t *pgdir, unsigned long start, u64 size)
{

View File

@@ -4,6 +4,7 @@
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/fs.h>
#include <linux/pagemap.h>
#include <linux/syscalls.h>
#include <linux/spinlock.h>
#include <asm/page.h>

View File

@@ -107,7 +107,6 @@ void __init mem_init(void)
free_highmem_page(page);
}
#endif
mem_init_print_info(NULL);
}
void free_initmem(void)

View File

@@ -98,6 +98,4 @@ void __init mem_init(void)
/* this will put all low memory onto the freelists */
memblock_free_all();
mem_init_print_info(NULL);
}

View File

@@ -55,7 +55,6 @@ void __init mem_init(void)
{
/* No idea where this is actually declared. Seems to evade LXR. */
memblock_free_all();
mem_init_print_info(NULL);
/*
* To-Do: someone somewhere should wipe out the bootmem map

View File

@@ -286,15 +286,6 @@ config FORCE_CPEI_RETARGET
config ARCH_SELECT_MEMORY_MODEL
def_bool y
config ARCH_DISCONTIGMEM_ENABLE
def_bool y
depends on BROKEN
help
Say Y to support efficient handling of discontiguous physical memory,
for architectures which are either NUMA (Non-Uniform Memory Access)
or have huge holes in the physical address space for other reasons.
See <file:Documentation/vm/numa.rst> for more.
config ARCH_FLATMEM_ENABLE
def_bool y
@@ -325,22 +316,8 @@ config NODES_SHIFT
MAX_NUMNODES will be 2^(This value).
If in doubt, use the default.
# VIRTUAL_MEM_MAP and FLAT_NODE_MEM_MAP are functionally equivalent.
# VIRTUAL_MEM_MAP has been retained for historical reasons.
config VIRTUAL_MEM_MAP
bool "Virtual mem map"
depends on !SPARSEMEM && !FLATMEM
default y
help
Say Y to compile the kernel with support for a virtual mem map.
This code also only takes effect if a memory hole of greater than
1 Gb is found during boot. You must turn this option on if you
require the DISCONTIGMEM option for your machine. If you are
unsure, say Y.
config HOLES_IN_ZONE
bool
default y if VIRTUAL_MEM_MAP
config HAVE_ARCH_NODEDATA_EXTENSION
def_bool y

View File

@@ -9,7 +9,6 @@ CONFIG_SGI_PARTITION=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_PREEMPT=y
# CONFIG_VIRTUAL_MEM_MAP is not set
CONFIG_IA64_PALINFO=y
CONFIG_EFI_VARS=y
CONFIG_BINFMT_MISC=m

View File

@@ -58,15 +58,4 @@ extern int reserve_elfcorehdr(u64 *start, u64 *end);
extern int register_active_ranges(u64 start, u64 len, int nid);
#ifdef CONFIG_VIRTUAL_MEM_MAP
extern unsigned long VMALLOC_END;
extern struct page *vmem_map;
extern int create_mem_map_page_table(u64 start, u64 end, void *arg);
extern int vmemmap_find_next_valid_pfn(int, int);
#else
static inline int vmemmap_find_next_valid_pfn(int node, int i)
{
return i + 1;
}
#endif
#endif /* meminit_h */

View File

@@ -14,16 +14,20 @@
struct elf64_shdr; /* forward declration */
struct mod_arch_specific {
/* Used only at module load time. */
struct elf64_shdr *core_plt; /* core PLT section */
struct elf64_shdr *init_plt; /* init PLT section */
struct elf64_shdr *got; /* global offset table */
struct elf64_shdr *opd; /* official procedure descriptors */
struct elf64_shdr *unwind; /* unwind-table section */
unsigned long gp; /* global-pointer for module */
unsigned int next_got_entry; /* index of next available got entry */
/* Used at module run and cleanup time. */
void *core_unw_table; /* core unwind-table cookie returned by unwinder */
void *init_unw_table; /* init unwind-table cookie returned by unwinder */
unsigned int next_got_entry; /* index of next available got entry */
void *opd_addr; /* symbolize uses .opd to get to actual function */
unsigned long opd_size;
};
#define ARCH_SHF_SMALL SHF_IA_64_SHORT

View File

@@ -95,31 +95,10 @@ do { \
#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
#ifdef CONFIG_VIRTUAL_MEM_MAP
extern int ia64_pfn_valid (unsigned long pfn);
#else
# define ia64_pfn_valid(pfn) 1
#endif
#ifdef CONFIG_VIRTUAL_MEM_MAP
extern struct page *vmem_map;
#ifdef CONFIG_DISCONTIGMEM
# define page_to_pfn(page) ((unsigned long) (page - vmem_map))
# define pfn_to_page(pfn) (vmem_map + (pfn))
# define __pfn_to_phys(pfn) PFN_PHYS(pfn)
#else
# include <asm-generic/memory_model.h>
#endif
#else
# include <asm-generic/memory_model.h>
#endif
#include <asm-generic/memory_model.h>
#ifdef CONFIG_FLATMEM
# define pfn_valid(pfn) (((pfn) < max_mapnr) && ia64_pfn_valid(pfn))
#elif defined(CONFIG_DISCONTIGMEM)
extern unsigned long min_low_pfn;
extern unsigned long max_low_pfn;
# define pfn_valid(pfn) (((pfn) >= min_low_pfn) && ((pfn) < max_low_pfn) && ia64_pfn_valid(pfn))
# define pfn_valid(pfn) ((pfn) < max_mapnr)
#endif
#define page_to_phys(page) (page_to_pfn(page) << PAGE_SHIFT)

View File

@@ -223,10 +223,6 @@ ia64_phys_addr_valid (unsigned long addr)
#define VMALLOC_START (RGN_BASE(RGN_GATE) + 0x200000000UL)
#ifdef CONFIG_VIRTUAL_MEM_MAP
# define VMALLOC_END_INIT (RGN_BASE(RGN_GATE) + (1UL << (4*PAGE_SHIFT - 9)))
extern unsigned long VMALLOC_END;
#else
#if defined(CONFIG_SPARSEMEM) && defined(CONFIG_SPARSEMEM_VMEMMAP)
/* SPARSEMEM_VMEMMAP uses half of vmalloc... */
# define VMALLOC_END (RGN_BASE(RGN_GATE) + (1UL << (4*PAGE_SHIFT - 10)))
@@ -234,7 +230,6 @@ extern unsigned long VMALLOC_END;
#else
# define VMALLOC_END (RGN_BASE(RGN_GATE) + (1UL << (4*PAGE_SHIFT - 9)))
#endif
#endif
/* fs/proc/kcore.c */
#define kc_vaddr_to_offset(v) ((v) - RGN_BASE(RGN_GATE))
@@ -328,7 +323,7 @@ extern void __ia64_sync_icache_dcache(pte_t pteval);
static inline void set_pte(pte_t *ptep, pte_t pteval)
{
/* page is present && page is user && page is executable
* && (page swapin or new page or page migraton
* && (page swapin or new page or page migration
* || copy_on_write with page copying.)
*/
if (pte_present_exec_user(pteval) &&

View File

@@ -9,7 +9,7 @@ endif
extra-y := head.o vmlinux.lds
obj-y := entry.o efi.o efi_stub.o gate-data.o fsys.o ia64_ksyms.o irq.o irq_ia64.o \
obj-y := entry.o efi.o efi_stub.o gate-data.o fsys.o irq.o irq_ia64.o \
irq_lsapic.o ivt.o pal.o patch.o process.o ptrace.o sal.o \
salinfo.o setup.o signal.o sys_ia64.o time.o traps.o unaligned.o \
unwind.o mca.o mca_asm.o topology.o dma-mapping.o iosapic.o acpi.o \

View File

@@ -446,7 +446,8 @@ void __init acpi_numa_fixup(void)
if (srat_num_cpus == 0) {
node_set_online(0);
node_cpuid[0].phys_id = hard_smp_processor_id();
return;
slit_distance(0, 0) = LOCAL_DISTANCE;
goto out;
}
/*
@@ -489,7 +490,7 @@ void __init acpi_numa_fixup(void)
for (j = 0; j < MAX_NUMNODES; j++)
slit_distance(i, j) = i == j ?
LOCAL_DISTANCE : REMOTE_DISTANCE;
return;
goto out;
}
memset(numa_slit, -1, sizeof(numa_slit));
@@ -514,6 +515,8 @@ void __init acpi_numa_fixup(void)
printk("\n");
}
#endif
out:
node_possible_map = node_online_map;
}
#endif /* CONFIG_ACPI_NUMA */

View File

@@ -415,10 +415,10 @@ efi_get_pal_addr (void)
mask = ~((1 << IA64_GRANULE_SHIFT) - 1);
printk(KERN_INFO "CPU %d: mapping PAL code "
"[0x%lx-0x%lx) into [0x%lx-0x%lx)\n",
smp_processor_id(), md->phys_addr,
md->phys_addr + efi_md_size(md),
vaddr & mask, (vaddr & mask) + IA64_GRANULE_SIZE);
"[0x%llx-0x%llx) into [0x%llx-0x%llx)\n",
smp_processor_id(), md->phys_addr,
md->phys_addr + efi_md_size(md),
vaddr & mask, (vaddr & mask) + IA64_GRANULE_SIZE);
#endif
return __va(md->phys_addr);
}
@@ -560,6 +560,7 @@ efi_init (void)
{
efi_memory_desc_t *md;
void *p;
unsigned int i;
for (i = 0, p = efi_map_start; p < efi_map_end;
++i, p += efi_desc_size)
@@ -586,7 +587,7 @@ efi_init (void)
}
printk("mem%02d: %s "
"range=[0x%016lx-0x%016lx) (%4lu%s)\n",
"range=[0x%016llx-0x%016llx) (%4lu%s)\n",
i, efi_md_typeattr_format(buf, sizeof(buf), md),
md->phys_addr,
md->phys_addr + efi_md_size(md), size, unit);

View File

@@ -172,7 +172,7 @@ ENTRY(fsys_gettimeofday)
// r25 = itc_lastcycle value
// r26 = address clocksource cycle_last
// r27 = (not used)
// r28 = sequence number at the beginning of critcal section
// r28 = sequence number at the beginning of critical section
// r29 = address of itc_jitter
// r30 = time processing flags / memory address
// r31 = pointer to result
@@ -432,7 +432,7 @@ GLOBAL_ENTRY(fsys_bubble_down)
* - r29: psr
*
* We used to clear some PSR bits here but that requires slow
* serialization. Fortuntely, that isn't really necessary.
* serialization. Fortunately, that isn't really necessary.
* The rationale is as follows: we used to clear bits
* ~PSR_PRESERVED_BITS in PSR.L. Since
* PSR_PRESERVED_BITS==PSR.{UP,MFL,MFH,PK,DT,PP,SP,RT,IC}, we

Some files were not shown because too many files have changed in this diff Show More