diff options
| author | Jiri Kosina <jkosina@suse.cz> | 2021-02-23 11:33:13 +0100 |
|---|---|---|
| committer | Jiri Kosina <jkosina@suse.cz> | 2021-02-23 11:33:13 +0100 |
| commit | d6310078d9f8c416e85f641a631aecf58f9c97ff (patch) | |
| tree | 58ed5d9818ada3e970d93438083731abd6293ba9 /Documentation | |
| parent | f8dd50e097b221e35c34b844826db92158ec18c2 (diff) | |
| parent | df7b622906f24be954beca94e60c195fde65c6d5 (diff) | |
Merge branch 'for-5.12/google' into for-linus
- User experience improvements for hid-google from Nicolas Boichat
Diffstat (limited to 'Documentation')
234 files changed, 5408 insertions, 1387 deletions
diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index b44183880935..55285c136cf0 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -77,6 +77,13 @@ Contact: dmaengine@vger.kernel.org Description: The operation capability bit mask specify the operation types supported by the this device. +What: /sys/bus/dsa/devices/dsa<m>/pasid_enabled +Date: Oct 27, 2020 +KernelVersion: 5.11.0 +Contact: dmaengine@vger.kernel.org +Description: To indicate if PASID (process address space identifier) is + enabled or not for this device. + What: /sys/bus/dsa/devices/dsa<m>/state Date: Oct 25, 2019 KernelVersion: 5.6.0 @@ -122,6 +129,13 @@ KernelVersion: 5.10.0 Contact: dmaengine@vger.kernel.org Description: The last executed device administrative command's status/error. +What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault +Date: Oct 27, 2020 +KernelVersion: 5.11.0 +Contact: dmaengine@vger.kernel.org +Description: To indicate block on fault is allowed or not for the work queue + to support on demand paging. + What: /sys/bus/dsa/devices/wq<m>.<n>/group_id Date: Oct 25, 2019 KernelVersion: 5.6.0 @@ -190,6 +204,13 @@ Contact: dmaengine@vger.kernel.org Description: The max batch size for this workqueue. Cannot exceed device max batch size. Configurable parameter. +What: /sys/bus/dsa/devices/wq<m>.<n>/ats_disable +Date: Nov 13, 2020 +KernelVersion: 5.11.0 +Contact: dmaengine@vger.kernel.org +Description: Indicate whether ATS disable is turned on for the workqueue. + 0 indicates ATS is on, and 1 indicates ATS is off for the workqueue. + What: /sys/bus/dsa/devices/engine<m>.<n>/group_id Date: Oct 25, 2019 KernelVersion: 5.6.0 diff --git a/Documentation/ABI/testing/sysfs-class-devlink b/Documentation/ABI/testing/sysfs-class-devlink index b662f747c83e..8a21ce515f61 100644 --- a/Documentation/ABI/testing/sysfs-class-devlink +++ b/Documentation/ABI/testing/sysfs-class-devlink @@ -5,8 +5,8 @@ Description: Provide a place in sysfs for the device link objects in the kernel at any given time. The name of a device link directory, denoted as ... above, is of the form <supplier>--<consumer> - where <supplier> is the supplier device name and <consumer> is - the consumer device name. + where <supplier> is the supplier bus:device name and <consumer> + is the consumer bus:device name. What: /sys/class/devlink/.../auto_remove_on Date: May 2020 diff --git a/Documentation/ABI/testing/sysfs-devices-consumer b/Documentation/ABI/testing/sysfs-devices-consumer index 1f06d74d1c3c..0809fda092e6 100644 --- a/Documentation/ABI/testing/sysfs-devices-consumer +++ b/Documentation/ABI/testing/sysfs-devices-consumer @@ -4,5 +4,6 @@ Contact: Saravana Kannan <saravanak@google.com> Description: The /sys/devices/.../consumer:<consumer> are symlinks to device links where this device is the supplier. <consumer> denotes the - name of the consumer in that device link. There can be zero or - more of these symlinks for a given device. + name of the consumer in that device link and is of the form + bus:device name. There can be zero or more of these symlinks + for a given device. diff --git a/Documentation/ABI/testing/sysfs-devices-supplier b/Documentation/ABI/testing/sysfs-devices-supplier index a919e0db5e90..207f5972e98d 100644 --- a/Documentation/ABI/testing/sysfs-devices-supplier +++ b/Documentation/ABI/testing/sysfs-devices-supplier @@ -4,5 +4,6 @@ Contact: Saravana Kannan <saravanak@google.com> Description: The /sys/devices/.../supplier:<supplier> are symlinks to device links where this device is the consumer. <supplier> denotes the - name of the supplier in that device link. There can be zero or - more of these symlinks for a given device. + name of the supplier in that device link and is of the form + bus:device name. There can be zero or more of these symlinks + for a given device. diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 1a04ca8162ad..0eee30b27ab6 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -264,7 +264,8 @@ Description: Discover CPUs in the same CPU frequency coordination domain attribute is useful for user space DVFS controllers to get better power/performance results for platforms using acpi-cpufreq. - This file is only present if the acpi-cpufreq driver is in use. + This file is only present if the acpi-cpufreq or the cppc-cpufreq + drivers are in use. What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1} diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index adc0d0e91607..75ccc5c62b3c 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -916,21 +916,25 @@ Date: September 2014 Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry could be used to set or show the UFS device runtime power management level. The current driver - implementation supports 6 levels with next target states: + implementation supports 7 levels with next target states: == ==================================================== - 0 an UFS device will stay active, an UIC link will + 0 UFS device will stay active, UIC link will stay active - 1 an UFS device will stay active, an UIC link will + 1 UFS device will stay active, UIC link will hibernate - 2 an UFS device will moved to sleep, an UIC link will + 2 UFS device will be moved to sleep, UIC link will stay active - 3 an UFS device will moved to sleep, an UIC link will + 3 UFS device will be moved to sleep, UIC link will hibernate - 4 an UFS device will be powered off, an UIC link will + 4 UFS device will be powered off, UIC link will hibernate - 5 an UFS device will be powered off, an UIC link will + 5 UFS device will be powered off, UIC link will be powered off + 6 UFS device will be moved to deep sleep, UIC link + will be powered off. Note, deep sleep might not be + supported in which case this value will not be + accepted == ==================================================== What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state @@ -954,21 +958,25 @@ Date: September 2014 Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry could be used to set or show the UFS device system power management level. The current driver - implementation supports 6 levels with next target states: + implementation supports 7 levels with next target states: == ==================================================== - 0 an UFS device will stay active, an UIC link will + 0 UFS device will stay active, UIC link will stay active - 1 an UFS device will stay active, an UIC link will + 1 UFS device will stay active, UIC link will hibernate - 2 an UFS device will moved to sleep, an UIC link will + 2 UFS device will be moved to sleep, UIC link will stay active - 3 an UFS device will moved to sleep, an UIC link will + 3 UFS device will be moved to sleep, UIC link will hibernate - 4 an UFS device will be powered off, an UIC link will + 4 UFS device will be powered off, UIC link will hibernate - 5 an UFS device will be powered off, an UIC link will + 5 UFS device will be powered off, UIC link will be powered off + 6 UFS device will be moved to deep sleep, UIC link + will be powered off. Note, deep sleep might not be + supported in which case this value will not be + accepted == ==================================================== What: /sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 67b3ed8e8c2f..3dfee94e0618 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -370,3 +370,10 @@ Date: April 2020 Contact: "Daeho Jeong" <daehojeong@google.com> Description: Give a way to change iostat_period time. 3secs by default. The new iostat trace gives stats gap given the period. +What: /sys/fs/f2fs/<disk>/max_io_bytes +Date: December 2020 +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> +Description: This gives a control to limit the bio size in f2fs. + Default is zero, which will follow underlying block layer limit, + whereas, if it has a certain bytes value, f2fs won't submit a + bio larger than that size. diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index 83ae3b79a643..a648b423ba0e 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -473,7 +473,7 @@ read-side critical sections that follow the idle period (the oval near the bottom of the diagram above). Plumbing this into the full grace-period execution is described -`below <#Forcing%20Quiescent%20States>`__. +`below <Forcing Quiescent States_>`__. CPU-Hotplug Interface ^^^^^^^^^^^^^^^^^^^^^ @@ -494,7 +494,7 @@ mask to detect CPUs having gone offline since the beginning of this grace period. Plumbing this into the full grace-period execution is described -`below <#Forcing%20Quiescent%20States>`__. +`below <Forcing Quiescent States_>`__. Forcing Quiescent States ^^^^^^^^^^^^^^^^^^^^^^^^ @@ -532,7 +532,7 @@ from other CPUs. | RCU. But this diagram is complex enough as it is, so simplicity | | overrode accuracy. You can think of it as poetic license, or you can | | think of it as misdirection that is resolved in the | -| `stitched-together diagram <#Putting%20It%20All%20Together>`__. | +| `stitched-together diagram <Putting It All Together_>`__. | +-----------------------------------------------------------------------+ Grace-Period Cleanup @@ -596,7 +596,7 @@ maintain ordering. For example, if the callback function wakes up a task that runs on some other CPU, proper ordering must in place in both the callback function and the task being awakened. To see why this is important, consider the top half of the `grace-period -cleanup <#Grace-Period%20Cleanup>`__ diagram. The callback might be +cleanup`_ diagram. The callback might be running on a CPU corresponding to the leftmost leaf ``rcu_node`` structure, and awaken a task that is to run on a CPU corresponding to the rightmost leaf ``rcu_node`` structure, and the grace-period kernel diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index e8c84fcc0507..d4c9a016074b 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -45,7 +45,7 @@ requirements: #. `Other RCU Flavors`_ #. `Possible Future Changes`_ -This is followed by a `summary <#Summary>`__, however, the answers to +This is followed by a summary_, however, the answers to each quick quiz immediately follows the quiz. Select the big white space with your mouse to see the answer. @@ -1096,7 +1096,7 @@ memory barriers. | case, voluntary context switch) within an RCU read-side critical | | section. However, sleeping locks may be used within userspace RCU | | read-side critical sections, and also within Linux-kernel sleepable | -| RCU `(SRCU) <#Sleepable%20RCU>`__ read-side critical sections. In | +| RCU `(SRCU) <Sleepable RCU_>`__ read-side critical sections. In | | addition, the -rt patchset turns spinlocks into a sleeping locks so | | that the corresponding critical sections can be preempted, which also | | means that these sleeplockified spinlocks (but not other sleeping | @@ -1186,7 +1186,7 @@ non-preemptible (``CONFIG_PREEMPT=n``) kernels, and thus `tiny RCU <https://lkml.kernel.org/g/20090113221724.GA15307@linux.vnet.ibm.com>`__ was born. Josh Triplett has since taken over the small-memory banner with his `Linux kernel tinification <https://tiny.wiki.kernel.org/>`__ -project, which resulted in `SRCU <#Sleepable%20RCU>`__ becoming optional +project, which resulted in `SRCU <Sleepable RCU_>`__ becoming optional for those kernels not needing it. The remaining performance requirements are, for the most part, @@ -1457,8 +1457,8 @@ will vary as the value of ``HZ`` varies, and can also be changed using the relevant Kconfig options and kernel boot parameters. RCU currently does not do much sanity checking of these parameters, so please use caution when changing them. Note that these forward-progress measures -are provided only for RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks -RCU <#Tasks%20RCU>`__. +are provided only for RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks +RCU`_. RCU takes the following steps in ``call_rcu()`` to encourage timely invocation of callbacks when any given non-\ ``rcu_nocbs`` CPU has @@ -1477,8 +1477,8 @@ encouragement was provided: Again, these are default values when running at ``HZ=1000``, and can be overridden. Again, these forward-progress measures are provided only for -RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks -RCU <#Tasks%20RCU>`__. Even for RCU, callback-invocation forward +RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks +RCU`_. Even for RCU, callback-invocation forward progress for ``rcu_nocbs`` CPUs is much less well-developed, in part because workloads benefiting from ``rcu_nocbs`` CPUs tend to invoke ``call_rcu()`` relatively infrequently. If workloads emerge that need @@ -1920,7 +1920,7 @@ Hotplug CPU The Linux kernel supports CPU hotplug, which means that CPUs can come and go. It is of course illegal to use any RCU API member from an -offline CPU, with the exception of `SRCU <#Sleepable%20RCU>`__ read-side +offline CPU, with the exception of `SRCU <Sleepable RCU_>`__ read-side critical sections. This requirement was present from day one in DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug implementation is “interesting.” @@ -2177,7 +2177,7 @@ handles these states differently: However, RCU must be reliably informed as to whether any given CPU is currently in the idle loop, and, for ``NO_HZ_FULL``, also whether that CPU is executing in usermode, as discussed -`earlier <#Energy%20Efficiency>`__. It also requires that the +`earlier <Energy Efficiency_>`__. It also requires that the scheduling-clock interrupt be enabled when RCU needs it to be: #. If a CPU is either idle or executing in usermode, and RCU believes it @@ -2294,7 +2294,7 @@ Performance, Scalability, Response Time, and Reliability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Expanding on the `earlier -discussion <#Performance%20and%20Scalability>`__, RCU is used heavily by +discussion <Performance and Scalability_>`__, RCU is used heavily by hot code paths in performance-critical portions of the Linux kernel's networking, security, virtualization, and scheduling code paths. RCU must therefore use efficient implementations, especially in its diff --git a/Documentation/admin-guide/binfmt-misc.rst b/Documentation/admin-guide/binfmt-misc.rst index 7a864131e5ea..59cd902e3549 100644 --- a/Documentation/admin-guide/binfmt-misc.rst +++ b/Documentation/admin-guide/binfmt-misc.rst @@ -23,7 +23,7 @@ Here is what the fields mean: - ``name`` is an identifier string. A new /proc file will be created with this - ``name below /proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for + name below ``/proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for obvious reasons. - ``type`` is the type of recognition. Give ``M`` for magic and ``E`` for extension. @@ -83,7 +83,7 @@ Here is what the fields mean: ``F`` - fix binary The usual behaviour of binfmt_misc is to spawn the binary lazily when the misc format file is invoked. However, - this doesn``t work very well in the face of mount namespaces and + this doesn't work very well in the face of mount namespaces and changeroots, so the ``F`` mode opens the binary as soon as the emulation is installed and uses the opened image to spawn the emulator, meaning it is always available once installed, diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst index 9b90efcc3a35..452b7dcd7f6b 100644 --- a/Documentation/admin-guide/bootconfig.rst +++ b/Documentation/admin-guide/bootconfig.rst @@ -154,7 +154,7 @@ get the boot configuration data. Because of this "piggyback" method, there is no need to change or update the boot loader and the kernel image itself as long as the boot loader passes the correct initrd file size. If by any chance, the boot -loader passes a longer size, the kernel feils to find the bootconfig data. +loader passes a longer size, the kernel fails to find the bootconfig data. To do this operation, Linux kernel provides "bootconfig" command under tools/bootconfig, which allows admin to apply or delete the config file diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst b/Documentation/admin-guide/device-mapper/dm-integrity.rst index 4e6f504474ac..2cc5488acbd9 100644 --- a/Documentation/admin-guide/device-mapper/dm-integrity.rst +++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst @@ -177,14 +177,20 @@ bitmap_flush_interval:number The bitmap flush interval in milliseconds. The metadata buffers are synchronized when this interval expires. +allow_discards + Allow block discard requests (a.k.a. TRIM) for the integrity device. + Discards are only allowed to devices using internal hash. + fix_padding Use a smaller padding of the tag area that is more space-efficient. If this option is not present, large padding is used - that is for compatibility with older kernels. -allow_discards - Allow block discard requests (a.k.a. TRIM) for the integrity device. - Discards are only allowed to devices using internal hash. +legacy_recalculate + Allow recalculating of volumes with HMAC keys. This is disabled by + default for security reasons - an attacker could modify the volume, + set recalc_sector to zero, and the kernel would not detect the + modification. The journal mode (D/J), buffer_sectors, journal_watermark, commit_time and allow_discards can be changed when reloading the target (load an inactive diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst index 8c50e5c96ee1..1a6b91368e59 100644 --- a/Documentation/admin-guide/device-mapper/verity.rst +++ b/Documentation/admin-guide/device-mapper/verity.rst @@ -134,7 +134,12 @@ root_hash_sig_key_desc <key_description> the pkcs7 signature of the roothash. The pkcs7 signature is used to validate the root hash during the creation of the device mapper block device. Verification of roothash depends on the config DM_VERITY_VERIFY_ROOTHASH_SIG - being set in the kernel. + being set in the kernel. The signatures are checked against the builtin + trusted keyring by default, or the secondary trusted keyring if + DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING is set. The secondary + trusted keyring includes by default the builtin trusted keyring, and it can + also gain new certificates at run time if they are signed by a certificate + already in the secondary trusted keyring. Theory of operation =================== diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 06fb1b4aa849..682ab28b5c94 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -3,8 +3,8 @@ The kernel's command-line parameters ==================================== -The following is a consolidated list of the kernel parameters as -implemented by the __setup(), core_param() and module_param() macros +The following is a consolidated list of the kernel parameters as implemented +by the __setup(), early_param(), core_param() and module_param() macros and sorted into English Dictionary order (defined as ignoring all punctuation and sorting digits before letters in a case insensitive manner), and with descriptions where known. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a28982dfee6e..a10b545c2070 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1385,7 +1385,7 @@ ftrace_filter=[function-list] [FTRACE] Limit the functions traced by the function - tracer at boot up. function-list is a comma separated + tracer at boot up. function-list is a comma-separated list of functions. This list can be changed at run time by the set_ftrace_filter file in the debugfs tracing directory. @@ -1399,13 +1399,13 @@ ftrace_graph_filter=[function-list] [FTRACE] Limit the top level callers functions traced by the function graph tracer at boot up. - function-list is a comma separated list of functions + function-list is a comma-separated list of functions that can be changed at run time by the set_graph_function file in the debugfs tracing directory. ftrace_graph_notrace=[function-list] [FTRACE] Do not trace from the functions specified in - function-list. This list is a comma separated list of + function-list. This list is a comma-separated list of functions that can be changed at run time by the set_graph_notrace file in the debugfs tracing directory. @@ -2254,6 +2254,16 @@ for all guests. Default is 1 (enabled) if in 64-bit or 32-bit PAE mode. + kvm-arm.mode= + [KVM,ARM] Select one of KVM/arm64's modes of operation. + + protected: nVHE-based mode with support for guests whose + state is kept private from the host. + Not valid if the kernel is running in EL2. + + Defaults to VHE/nVHE based on hardware support and + the value of CONFIG_ARM64_VHE. + kvm-arm.vgic_v3_group0_trap= [KVM,ARM] Trap guest accesses to GICv3 group-0 system registers @@ -2411,7 +2421,7 @@ when set. Format: <int> - libata.force= [LIBATA] Force configurations. The format is comma + libata.force= [LIBATA] Force configurations. The format is comma- separated list of "[ID:]VAL" where ID is PORT[.DEVICE]. PORT and DEVICE are decimal numbers matching port, link or device. Basically, it matches @@ -2948,7 +2958,7 @@ mtdset= [ARM] ARM/S3C2412 JIVE boot control - See arch/arm/mach-s3c2412/mach-jive.c + See arch/arm/mach-s3c/mach-jive.c mtouchusb.raw_coordinates= [HW] Make the MicroTouch USB driver use raw coordinates @@ -5135,7 +5145,7 @@ stacktrace_filter=[function-list] [FTRACE] Limit the functions that the stack tracer - will trace at boot up. function-list is a comma separated + will trace at boot up. function-list is a comma-separated list of functions. This list can be changed at run time by the stack_trace_filter file in the debugfs tracing directory. Note, this enables stack tracing @@ -5338,7 +5348,7 @@ trace_event=[event-list] [FTRACE] Set and start specified trace events in order to facilitate early boot debugging. The event-list is a - comma separated list of trace events to enable. See + comma-separated list of trace events to enable. See also Documentation/trace/events.rst trace_options=[option-list] @@ -5962,6 +5972,10 @@ This option is obsoleted by the "nopv" option, which has equivalent effect for XEN platform. + xen_no_vector_callback + [KNL,X86,XEN] Disable the vector callback for Xen + event channel interrupts. + xen_scrub_pages= [XEN] Boolean option to control scrubbing pages before giving them back to Xen, for use by other domains. Can be also changed at runtime diff --git a/Documentation/admin-guide/mm/concepts.rst b/Documentation/admin-guide/mm/concepts.rst index fa0974fbeae7..b966fcff993b 100644 --- a/Documentation/admin-guide/mm/concepts.rst +++ b/Documentation/admin-guide/mm/concepts.rst @@ -184,7 +184,7 @@ pages either asynchronously or synchronously, depending on the state of the system. When the system is not loaded, most of the memory is free and allocation requests will be satisfied immediately from the free pages supply. As the load increases, the amount of the free pages goes -down and when it reaches a certain threshold (high watermark), an +down and when it reaches a certain threshold (low watermark), an allocation request will awaken the ``kswapd`` daemon. It will asynchronously scan memory pages and either just free them if the data they contain is available elsewhere, or evict to the backing storage diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst index 1307b5274a0f..904e4eb37f99 100644 --- a/Documentation/admin-guide/perf-security.rst +++ b/Documentation/admin-guide/perf-security.rst @@ -84,11 +84,14 @@ capabilities then providing the process with CAP_PERFMON capability singly is recommended as the preferred secure approach to resolve double access denial logging related to usage of performance monitoring and observability. -Unprivileged processes using perf_events system call are also subject -for PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose -outcome determines whether monitoring is permitted. So unprivileged -processes provided with CAP_SYS_PTRACE capability are effectively -permitted to pass the check. +Prior Linux v5.9 unprivileged processes using perf_events system call +are also subject for PTRACE_MODE_READ_REALCREDS ptrace access mode check +[7]_ , whose outcome determines whether monitoring is permitted. +So unprivileged processes provided with CAP_SYS_PTRACE capability are +effectively permitted to pass the check. Starting from Linux v5.9 +CAP_SYS_PTRACE capability is not required and CAP_PERFMON is enough to +be provided for processes to make performance monitoring and observability +operations. Other capabilities being granted to unprivileged processes can effectively enable capturing of additional data required for later @@ -99,11 +102,11 @@ CAP_SYSLOG capability permits reading kernel space memory addresses from Privileged Perf users groups --------------------------------- -Mechanisms of capabilities, privileged capability-dumb files [6]_ and -file system ACLs [10]_ can be used to create dedicated groups of -privileged Perf users who are permitted to execute performance monitoring -and observability without scope limits. The following steps can be -taken to create such groups of privileged Perf users. +Mechanisms of capabilities, privileged capability-dumb files [6]_, +file system ACLs [10]_ and sudo [15]_ utility can be used to create +dedicated groups of privileged Perf users who are permitted to execute +performance monitoring and observability without limits. The following +steps can be taken to create such groups of privileged Perf users. 1. Create perf_users group of privileged Perf users, assign perf_users group to Perf tool executable and limit access to the executable for @@ -133,7 +136,7 @@ taken to create such groups of privileged Perf users. # getcap perf perf = cap_sys_ptrace,cap_syslog,cap_perfmon+ep -If the libcap installed doesn't yet support "cap_perfmon", use "38" instead, +If the libcap [16]_ installed doesn't yet support "cap_perfmon", use "38" instead, i.e.: :: @@ -159,6 +162,60 @@ performance monitoring and observability by using functionality of the configured Perf tool executable that, when executes, passes perf_events subsystem scope checks. +In case Perf tool executable can't be assigned required capabilities (e.g. +file system is mounted with nosuid option or extended attributes are +not supported by the file system) then creation of the capabilities +privileged environment, naturally shell, is possible. The shell provides +inherent processes with CAP_PERFMON and other required capabilities so that +performance monitoring and observability operations are available in the +environment without limits. Access to the environment can be open via sudo +utility for members of perf_users group only. In order to create such +environment: + +1. Create shell script that uses capsh utility [16]_ to assign CAP_PERFMON + and other required capabilities into ambient capability set of the shell + process, lock the process security bits after enabling SECBIT_NO_SETUID_FIXUP, + SECBIT_NOROOT and SECBIT_NO_CAP_AMBIENT_RAISE bits and then change + the process identity to sudo caller of the script who should essentially + be a member of perf_users group: + +:: + + # ls -alh /usr/local/bin/perf.shell + -rwxr-xr-x. 1 root root 83 Oct 13 23:57 /usr/local/bin/perf.shell + # cat /usr/local/bin/perf.shell + exec /usr/sbin/capsh --iab=^cap_perfmon --secbits=239 --user=$SUDO_USER -- -l + +2. Extend sudo policy at /etc/sudoers file with a rule for perf_users group: + +:: + + # grep perf_users /etc/sudoers + %perf_users ALL=/usr/local/bin/perf.shell + +3. Check that members of perf_users group have access to the privileged + shell and have CAP_PERFMON and other required capabilities enabled + in permitted, effective and ambient capability sets of an inherent process: + +:: + + $ id + uid=1003(capsh_test) gid=1004(capsh_test) groups=1004(capsh_test),1000(perf_users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 + $ sudo perf.shell + [sudo] password for capsh_test: + $ grep Cap /proc/self/status + CapInh: 0000004000000000 + CapPrm: 0000004000000000 + CapEff: 0000004000000000 + CapBnd: 000000ffffffffff + CapAmb: 0000004000000000 + $ capsh --decode=0000004000000000 + 0x0000004000000000=cap_perfmon + +As a result, members of perf_users group have access to the privileged +environment where they can use tools employing performance monitoring APIs +governed by CAP_PERFMON Linux capability. + This specific access control management is only available to superuser or root running processes with CAP_SETPCAP, CAP_SETFCAP [6]_ capabilities. @@ -264,3 +321,5 @@ Bibliography .. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_ .. [13] `<https://sites.google.com/site/fullycapable>`_ .. [14] `<http://man7.org/linux/man-pages/man8/auditd.8.html>`_ +.. [15] `<https://man7.org/linux/man-pages/man8/sudo.8.html>`_ +.. [16] `<https://git.kernel.org/pub/scm/libs/libcap/libcap.git/>`_ diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index e972caa43bd4..e35a3f2fb006 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -428,7 +428,7 @@ While most applications need less than a thousand maps, certain programs, particularly malloc debuggers, may consume lots of them, e.g., up to one or two maps per allocation. -The default value is 65536. +The default value is 65530. memory_failure_early_kill: diff --git a/Documentation/arm/memory.rst b/Documentation/arm/memory.rst index 0521b4ce5c96..0cb1e2938823 100644 --- a/Documentation/arm/memory.rst +++ b/Documentation/arm/memory.rst @@ -45,9 +45,14 @@ fffe8000 fffeffff DTCM mapping area for platforms with fffe0000 fffe7fff ITCM mapping area for platforms with ITCM mounted inside the CPU. -ffc00000 ffefffff Fixmap mapping region. Addresses provided +ffc80000 ffefffff Fixmap mapping region. Addresses provided by fix_to_virt() will be located here. +ffc00000 ffc7ffff Guard region + +ff800000 ffbfffff Permanent, fixed read-only mapping of the + firmware provided DT blob + fee00000 feffffff Mapping of PCI I/O space. This is a static mapping within the vmalloc space. @@ -72,6 +77,11 @@ MODULES_VADDR MODULES_END-1 Kernel module space Kernel modules inserted via insmod are placed here using dynamic mappings. +TASK_SIZE MODULES_VADDR-1 KASAn shadow memory when KASan is in use. + The range from MODULES_VADDR to the top + of the memory is shadowed here with 1 bit + per byte of memory. + 00001000 TASK_SIZE-1 User space mappings Per-thread mappings are placed here via the mmap() system call. diff --git a/Documentation/arm/samsung-s3c24xx/gpio.rst b/Documentation/arm/samsung-s3c24xx/gpio.rst index f7c3d7d011a2..f4a8c800a457 100644 --- a/Documentation/arm/samsung-s3c24xx/gpio.rst +++ b/Documentation/arm/samsung-s3c24xx/gpio.rst @@ -29,7 +29,7 @@ GPIOLIB The following functions now either have a `s3c_` specific variant or are merged into gpiolib. See the definitions in - arch/arm/plat-samsung/include/plat/gpio-cfg.h: + arch/arm/mach-s3c/gpio-cfg.h: - s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output() - s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input() @@ -86,7 +86,7 @@ between the calls. Headers ------- - See arch/arm/mach-s3c24xx/include/mach/regs-gpio.h for the list + See arch/arm/mach-s3c/regs-gpio-s3c24xx.h for the list of GPIO pins, and the configuration values for them. This is included by using #include <mach/regs-gpio.h> diff --git a/Documentation/arm/samsung-s3c24xx/overview.rst b/Documentation/arm/samsung-s3c24xx/overview.rst index e9a1dc7276b5..14535e5cffb7 100644 --- a/Documentation/arm/samsung-s3c24xx/overview.rst +++ b/Documentation/arm/samsung-s3c24xx/overview.rst @@ -18,7 +18,7 @@ Introduction versions. The S3C2416 and S3C2450 devices are very similar and S3C2450 support is - included under the arch/arm/mach-s3c2416 directory. Note, while core + included under the arch/arm/mach-s3c directory. Note, while core support for these SoCs is in, work on some of the extra peripherals and extra interrupts is still ongoing. @@ -37,19 +37,11 @@ Configuration Layout ------ - The core support files are located in the platform code contained in - arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx. - This directory should be kept to items shared between the platform - code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code. + The core support files, register, kernel and paltform data are located in the + platform code contained in arch/arm/mach-s3c with headers in + arch/arm/mach-s3c/include - Each cpu has a directory with the support files for it, and the - machines that carry the device. For example S3C2410 is contained - in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440 - - Register, kernel and platform data definitions are held in the - arch/arm/mach-s3c2410 directory./include/mach - -arch/arm/plat-s3c24xx: +arch/arm/mach-s3c: Files in here are either common to all the s3c24xx family, or are common to only some of them with names to indicate this @@ -134,7 +126,7 @@ Adding New Machines should keep this in mind before altering items outside of their own machine files. - Machine definitions should be kept in linux/arch/arm/mach-s3c2410, + Machine definitions should be kept in arch/arm/mach-s3c, and there are a number of examples that can be looked at. Read the kernel patch submission policies as well as the @@ -293,7 +285,7 @@ Platform Data } Note, since the code is marked as __init, it should not be - exported outside arch/arm/mach-s3c2410/, or exported to + exported outside arch/arm/mach-s3c/, or exported to modules via EXPORT_SYMBOL() and related functions. diff --git a/Documentation/arm/samsung-s3c24xx/usb-host.rst b/Documentation/arm/samsung-s3c24xx/usb-host.rst index c84268bd1884..7aaffac89e04 100644 --- a/Documentation/arm/samsung-s3c24xx/usb-host.rst +++ b/Documentation/arm/samsung-s3c24xx/usb-host.rst @@ -36,7 +36,7 @@ Board Support ------------- The driver attaches to a platform device, which will need to be - added by the board specific support file in linux/arch/arm/mach-s3c2410, + added by the board specific support file in arch/arm/mach-s3c, such as mach-bast.c or mach-smdk2410.c The platform device's platform_data field is only needed if the @@ -51,9 +51,9 @@ Board Support Platform Data ------------- - See arch/arm/mach-s3c2410/include/mach/usb-control.h for the + See include/linux/platform_data/usb-ohci-s3c2410.h for the descriptions of the platform device data. An implementation - can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c . + can be found in arch/arm/mach-s3c/simtec-usb.c . The `struct s3c2410_hcd_info` contains a pair of functions that get called to enable over-current detection, and to diff --git a/Documentation/arm/samsung/gpio.rst b/Documentation/arm/samsung/gpio.rst index 5f7cadd7159e..f6e27b07c993 100644 --- a/Documentation/arm/samsung/gpio.rst +++ b/Documentation/arm/samsung/gpio.rst @@ -37,5 +37,4 @@ implementation to configure pins as necessary. The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a driver or machine to change gpio configuration. -See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information -on these functions. +See arch/arm/mach-s3c/gpio-cfg.h for more information on these functions. diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst index e7522e5c8322..901cd094f4ec 100644 --- a/Documentation/arm64/memory.rst +++ b/Documentation/arm64/memory.rst @@ -97,7 +97,7 @@ hypervisor maps kernel pages in EL2 at a fixed (and potentially random) offset from the linear mapping. See the kern_hyp_va macro and kvm_update_va_mask function for more details. MMIO devices such as GICv2 gets mapped next to the HYP idmap page, as do vectors when -ARM64_HARDEN_EL2_VECTORS is selected for particular CPUs. +ARM64_SPECTRE_V3A is enabled for particular CPUs. When using KVM with the Virtualization Host Extensions, no additional mappings are created, since the host kernel runs directly in EL2. diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 69171b1799f2..f1c9d20bd42d 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -53,7 +53,6 @@ How Linux keeps everything from happening at the same time. See .. toctree:: :maxdepth: 1 - atomic_ops refcount-vs-atomic irq/index local_ops diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index 6b752a45a936..1651d961f06a 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -4,13 +4,16 @@ The Kernel Address Sanitizer (KASAN) Overview -------- -KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to -find out-of-bound and use-after-free bugs. KASAN has two modes: generic KASAN -(similar to userspace ASan) and software tag-based KASAN (similar to userspace -HWASan). +KernelAddressSANitizer (KASAN) is a dynamic memory safety error detector +designed to find out-of-bound and use-after-free bugs. KASAN has three modes: -KASAN uses compile-time instrumentation to insert validity checks before every -memory access, and therefore requires a compiler version that supports that. +1. generic KASAN (similar to userspace ASan), +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 +version that supports that. Generic KASAN is supported in both GCC and Clang. With GCC it requires version 8.3.0 or later. Any supported Clang version is compatible, but detection of @@ -18,8 +21,8 @@ out-of-bounds accesses for global variables is only supported since Clang 11. Tag-based KASAN 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. +Currently generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390 +and riscv architectures, and tag-based KASAN modes are supported only for arm64. Usage ----- @@ -28,30 +31,22 @@ To enable KASAN configure kernel with:: CONFIG_KASAN = y -and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN) and -CONFIG_KASAN_SW_TAGS (to enable software 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. -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. +Both software KASAN modes work with both SLUB and SLAB memory allocators, +while the hardware tag-based KASAN currently only support SLUB. -Both KASAN modes work with both SLUB and SLAB memory allocators. -For better bug detection and nicer reporting, enable CONFIG_STACKTRACE. +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 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 - Error reports ~~~~~~~~~~~~~ @@ -136,22 +131,60 @@ 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. In the last section the report shows memory state around the accessed address. -Reading this part requires some understanding of how KASAN works. - -The state of each 8 aligned bytes of memory is encoded in one shadow byte. -Those 8 bytes can be accessible, partially accessible, freed or be a redzone. -We use the following encoding for each shadow byte: 0 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. -We use different negative values to distinguish between different kinds of -inaccessible memory like redzones or freed memory (see mm/kasan/kasan.h). +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 +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 +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 this last report section shows the memory tags around the -accessed address (see Implementation details section). +accessed address (see `Implementation details`_ section). + +Boot parameters +~~~~~~~~~~~~~~~ + +Hardware tag-based KASAN mode (see the section about different mode 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. + +- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``). + +- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack + traces collection (default: ``on`` for ``CONFIG_DEBUG_KERNEL=y``, otherwise + ``off``). + +- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN + report or also panic the kernel (default: ``report``). + +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 Implementation details @@ -160,10 +193,10 @@ Implementation details Generic KASAN ~~~~~~~~~~~~~ -From a high level, our 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. +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. Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB to cover 128TB on x86_64) and uses direct mapping with a scale and offset to @@ -194,20 +227,30 @@ 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 +quarantine (see mm/kasan/quarantine.c for implementation). + Software tag-based KASAN ~~~~~~~~~~~~~~~~~~~~~~~~ -Tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern 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 +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 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). -On each memory allocation tag-based KASAN generates a random tag, tags the -allocated memory with this tag, and embeds this tag into the returned pointer. +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 +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 tag-based KASAN prints a bug report. +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 @@ -216,9 +259,36 @@ 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. -A potential expansion of this mode is a hardware tag-based mode, which would -use hardware memory tagging support instead of compiler instrumentation and -manual shadow memory manipulation. +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 +reserved to tag freed memory regions. + +Software tag-based KASAN currently only supports tagging of +kmem_cache_alloc/kmalloc and page_alloc memory. + +Hardware tag-based KASAN +~~~~~~~~~~~~~~~~~~~~~~~~ + +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). + +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. + +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 +reserved to tag freed memory regions. + +Hardware tag-based KASAN currently only supports tagging of +kmem_cache_alloc/kmalloc and page_alloc memory. What memory accesses are sanitised by KASAN? -------------------------------------------- @@ -265,17 +335,17 @@ Most mappings in vmalloc space are small, requiring less than a full page of shadow space. Allocating a full shadow page per mapping would therefore be wasteful. Furthermore, to ensure that different mappings use different shadow pages, mappings would have to be aligned to -``KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE``. +``KASAN_GRANULE_SIZE * PAGE_SIZE``. -Instead, we share backing space across multiple mappings. We allocate +Instead, KASAN shares backing space across multiple mappings. It allocates a backing page when a mapping in vmalloc space uses a particular page of the shadow region. This page can be shared by other vmalloc mappings later on. -We hook in to the vmap infrastructure to lazily clean up unused shadow +KASAN hooks into the vmap infrastructure to lazily clean up unused shadow memory. -To avoid the difficulties around swapping mappings around, we expect +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. @@ -286,24 +356,31 @@ architectures that do not have a fixed module region. CONFIG_KASAN_KUNIT_TEST & CONFIG_TEST_KASAN_MODULE -------------------------------------------------- -``CONFIG_KASAN_KUNIT_TEST`` utilizes the KUnit Test Framework for testing. -This means each test focuses on a small unit of functionality and -there are a few ways these tests can be run. +KASAN tests consist on 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. + +2. Tests that are currently incompatible with KUnit. Enabled with +``CONFIG_TEST_KASAN_MODULE`` and can only be run as a module. These tests can +only be verified manually, by loading the kernel module and inspecting the +kernel log for KASAN reports. -Each test will print the KASAN report if an error is detected and then -print the number of the test and the status of the test: +Each KUnit-compatible KASAN test prints a KASAN report if an error is detected. +Then the test prints its number and status. -pass:: +When a test passes:: ok 28 - kmalloc_double_kzfree -or, if kmalloc failed:: +When a test fails due to a failed ``kmalloc``:: # kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163 Expected ptr is not null, but is not ok 4 - kmalloc_large_oob_right -or, if a KASAN report was expected, but not found:: +When a test fails due to a missing KASAN report:: # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629 Expected kasan_data->report_expected == kasan_data->report_found, but @@ -311,46 +388,38 @@ or, if a KASAN report was expected, but not found:: kasan_data->report_found == 0 not ok 28 - kmalloc_double_kzfree -All test statuses are tracked as they run and an overall status will -be printed at the end:: +At the end the cumulative status of all KASAN tests is printed. On success:: ok 1 - kasan -or:: +Or, if one of the tests failed:: not ok 1 - kasan -(1) Loadable Module -~~~~~~~~~~~~~~~~~~~~ + +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 -using something like insmod or modprobe. The module is called ``test_kasan``. +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``. -(2) Built-In -~~~~~~~~~~~~~ +2. Built-In +~~~~~~~~~~~ With ``CONFIG_KUNIT`` built-in, ``CONFIG_KASAN_KUNIT_TEST`` can be built-in -on any architecture that supports KASAN. These and any other KUnit -tests enabled will run and print the results at boot as a late-init -call. +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. -(3) Using kunit_tool -~~~~~~~~~~~~~~~~~~~~~ +3. Using kunit_tool +~~~~~~~~~~~~~~~~~~~ -With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, we can also -use kunit_tool to see the results of these along with other KUnit -tests in a more readable way. This will not print the KASAN reports -of 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'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``. .. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html - -``CONFIG_TEST_KASAN_MODULE`` is a set of KASAN tests that could not be -converted to KUnit. These tests can be run only as a module with -``CONFIG_TEST_KASAN_MODULE`` built as a loadable module and -``CONFIG_KASAN`` built-in. The type of error expected and the -function being run is printed before the expression expected to give -an error. Then the error is printed, if found, and that test -should be interpreted to pass only if the error was the one expected -by the test. diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index d9fdc14f0677..650f99590df5 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -522,6 +522,63 @@ There's more boilerplate involved, but it can: * E.g. if we wanted to also test ``sha256sum``, we could add a ``sha256`` field and reuse ``cases``. +* be converted to a "parameterized test", see below. + +Parameterized Testing +~~~~~~~~~~~~~~~~~~~~~ + +The table-driven testing pattern is common enough that KUnit has special +support for it. + +Reusing the same ``cases`` array from above, we can write the test as a +"parameterized test" with the following. + +.. code-block:: c + + // This is copy-pasted from above. + struct sha1_test_case { + const char *str; + const char *sha1; + }; + struct sha1_test_case cases[] = { + { + .str = "hello world", + .sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", + }, + { + .str = "hello world!", + .sha1 = "430ce34d020724ed75a196dfc2ad67c77772d169", + }, + }; + + // Need a helper function to generate a name for each test case. + static void case_to_desc(const struct sha1_test_case *t, char *desc) + { + strcpy(desc, t->str); + } + // Creates `sha1_gen_params()` to iterate over `cases`. + KUNIT_ARRAY_PARAM(sha1, cases, case_to_desc); + + // Looks no different from a normal test. + static void sha1_test(struct kunit *test) + { + // This function can just contain the body of the for-loop. + // The former `cases[i]` is accessible under test->param_value. + char out[40]; + struct sha1_test_case *test_param = (struct sha1_test_case *)(test->param_value); + + sha1sum(test_param->str, out); + KUNIT_EXPECT_STREQ_MSG(test, (char *)out, test_param->sha1, + "sha1sum(%s)", test_param->str); + } + + // Instead of KUNIT_CASE, we use KUNIT_CASE_PARAM and pass in the + // function declared by KUNIT_ARRAY_PARAM. + static struct kunit_case sha1_test_cases[] = { + KUNIT_CASE_PARAM(sha1_test, sha1_gen_params), + {} + }; + .. _kunit-on-non-uml: KUnit on non-UML architectures diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml new file mode 100644 index 000000000000..5fec063d9a13 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm4908.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM4908 device tree bindings + +description: + Broadcom BCM4906 / BCM4908 / BCM49408 Wi-Fi/network SoCs with Brahma CPUs. + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: BCM4906 based boards + items: + - const: brcm,bcm4906 + - const: brcm,bcm4908 + + - description: BCM4908 based boards + items: + - enum: + - asus,gt-ac5300 + - const: brcm,bcm4908 + + - description: BCM49408 based boards + items: + - const: brcm,bcm49408 + - const: brcm,bcm4908 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 6064d98b1031..395359dc94fd 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -89,7 +89,10 @@ Required properties: "fsl,imx8qm-clock" "fsl,imx8qxp-clock" followed by "fsl,scu-clk" -- #clock-cells: Should be 1. Contains the Clock ID value. +- #clock-cells: Should be either + 2: Contains the Resource and Clock ID value. + or + 1: Contains the Clock ID value. (DEPRECATED) - clocks: List of clock specifiers, must contain an entry for each required entry in clock-names - clock-names: Should include entries "xtal_32KHz", "xtal_24MHz" @@ -208,7 +211,7 @@ firmware { clk: clk { compatible = "fsl,imx8qxp-clk", "fsl,scu-clk"; - #clock-cells = <1>; + #clock-cells = <2>; }; iomuxc { @@ -263,8 +266,7 @@ serial@5a060000 { ... pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lpuart0>; - clocks = <&clk IMX8QXP_UART0_CLK>, - <&clk IMX8QXP_UART0_IPG_CLK>; - clock-names = "per", "ipg"; + clocks = <&uart0_clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>; + clock-names = "ipg"; power-domains = <&pd IMX_SC_R_UART_0>; }; diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 934289446abb..34000f7fbe02 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -33,16 +33,57 @@ properties: items: - enum: - fsl,imx25-pdk + - karo,imx25-tx25 - const: fsl,imx25 - - description: i.MX27 Product Development Kit + - description: i.MX25 Eukrea CPUIMX25 Boards + items: + - enum: + - eukrea,mbimxsd25-baseboard # Eukrea MBIMXSD25 + - const: eukrea,cpuimx25 + - const: fsl,imx25 + + - description: i.MX25 Eukrea MBIMXSD25 Boards + items: + - enum: + - eukrea,mbimxsd25-baseboard-cmo-qvga + - eukrea,mbimxsd25-baseboard-dvi-svga + - eukrea,mbimxsd25-baseboard-dvi-vga + - const: eukrea,mbimxsd25-baseboard + - const: eukrea,cpuimx25 + - const: fsl,imx25 + + - description: i.MX27 based Boards items: - enum: - armadeus,imx27-apf27 # APF27 SoM - - armadeus,imx27-apf27dev # APF27 SoM on APF27Dev board - fsl,imx27-pdk - const: fsl,imx27 + - description: i.MX27 APF27 SoM Board + items: + - const: armadeus,imx27-apf27dev + - const: armadeus,imx27-apf27 + - const: fsl,imx27 + + - description: i.MX27 Eukrea CPUIMX27 SoM Board + items: + - const: eukrea,mbimxsd27-baseboard + - const: eukrea,cpuimx27 + - const: fsl,imx27 + + - description: i.MX27 Phytec pca100 Board + items: + - const: phytec,imx27-pca100-rdk + - const: phytec,imx27-pca100 + - const: fsl,imx27 + + - description: i.MX27 Phytec pcm970 Board + items: + - const: phytec,imx27-pcm970 + - const: phytec,imx27-pcm038 + - const: fsl,imx27 + - description: i.MX28 based Boards items: - enum: @@ -88,13 +129,33 @@ properties: - kobo,aura - const: fsl,imx50 - - description: i.MX51 Babbage Board + - description: i.MX51 based Boards items: - enum: - - armadeus,imx51-apf51 # APF51 SoM - - armadeus,imx51-apf51dev # APF51 SoM on APF51Dev board + - armadeus,imx51-apf51 # Armadeus Systems APF51 module - fsl,imx51-babbage - technologic,imx51-ts4800 + - zii,imx51-scu3-esb + - zii,imx51-scu2-mezz + - zii,imx51-rdu1 + - const: fsl,imx51 + + - description: i.MX51 based Armadeus Systems APF51Dev Board + items: + - const: armadeus,imx51-apf51dev + - const: armadeus,imx51-apf51 + - const: fsl,imx51 + + - description: i.MX51 based Digi ConnectCore CC(W)-MX51 JSK Board + items: + - const: digi,connectcore-ccxmx51-jsk + - const: digi,connectcore-ccxmx51-som + - const: fsl,imx51 + + - description: i.MX51 based Eukrea CPUIMX51 Board + items: + - const: eukrea,mbimxsd51 + - const: eukrea,cpuimx51 - const: fsl,imx51 - description: i.MX53 based Boards @@ -104,36 +165,111 @@ properties: - fsl,imx53-ard - fsl,imx53-evk - fsl,imx53-qsb + - fsl,imx53-qsrb # Freescale i.MX53 Quick Start-R Board - fsl,imx53-smd + - ge,imx53-cpuvo # General Electric CS ONE + - inversepath,imx53-usbarmory # Inverse Path USB armory + - karo,tx53 # Ka-Ro electronics TX53 module + - kiebackpeter,imx53-ddc # K+P imx53 DDC + - kiebackpeter,imx53-hsc # K+P imx53 HSC - menlo,m53menlo + - voipac,imx53-dmm-668 # Voipac i.MX53 X53-DMM-668 + - const: fsl,imx53 + + - description: i.MX53 based Aries/DENX M53EVK Board + items: + - const: aries,imx53-m53evk + - const: denx,imx53-m53evk + - const: fsl,imx53 + + - description: i.MX53 based TQ MBa53 Board + items: + - const: tq,mba53 + - const: tq,tqma53 - const: fsl,imx53 - description: i.MX6Q based Boards items: - enum: - - armadeus,imx6q-apf6 # APF6 (Quad/Dual) SoM - - armadeus,imx6q-apf6dev # APF6 (Quad/Dual) SoM on APF6Dev board + - auvidea,h100 # Auvidea H100 + - boundary,imx6q-nitrogen6_max + - boundary,imx6q-nitrogen6_som2 + - boundary,imx6q-nitrogen6x + - compulab,cm-fx6 # CompuLab CM-FX6 + - dmo,imx6q-edmqmx6 # Data Modul eDM-QMX6 Board + - embest,imx6q-marsboard # Embest MarS Board i.MX6Dual - emtrion,emcon-mx6 # emCON-MX6D or emCON-MX6Q SoM - emtrion,emcon-mx6-avari # emCON-MX6D or emCON-MX6Q SoM on Avari Base + - engicam,imx6-icore # Engicam i.CoreM6 Starter Kit + - engicam,imx6-icore-rqs # Engicam i.CoreM6 RQS Starter Kit - fsl,imx6q-arm2 - fsl,imx6q-sabreauto - fsl,imx6q-sabrelite - fsl,imx6q-sabresd + - karo,imx6q-tx6q # Ka-Ro electronics TX6Q Modules + - kiebackpeter,imx6q-tpc # K+P i.MX6 Quad TPC Board - kontron,imx6q-samx6i # Kontron i.MX6 Dual/Quad SMARC Module + - kosagi,imx6q-novena # Kosagi Novena Dual/Quad - logicpd,imx6q-logicpd + - lwn,display5 # Liebherr Display5 i.MX6 Quad Board + - lwn,mccmon6 # Liebherr Monitor6 i.MX6 Quad Board + - nutsboard,imx6q-pistachio # NutsBoard i.MX6 Quad Pistachio + - microsys,sbc6x # MicroSys sbc6x board + - poslab,imx6q-savageboard # Poslab SavageBoard Quad - prt,prti6q # Protonic PRTI6Q board - prt,prtwd2 # Protonic WD2 board + - rex,imx6q-rex-pro # Rex Pro i.MX6 Quad Board + - solidrun,cubox-i/q # SolidRun Cubox-i Dual/Quad + - solidrun,hummingboard/q + - solidrun,hummingboard2/q + - tbs,imx6q-tbs2910 # TBS2910 Matrix ARM mini PC - technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf - technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit - technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph - technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi - technologic,imx6q-ts4900 - technologic,imx6q-ts7970 - - toradex,apalis_imx6q # Apalis iMX6 Module - - toradex,apalis_imx6q-eval # Apalis iMX6 Module on Apalis Evaluation Board - - toradex,apalis_imx6q-ixora # Apalis iMX6 Module on Ixora - - toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6 Module on Ixora V1.1 + - toradex,apalis_imx6q # Apalis iMX6 Module + - udoo,imx6q-udoo # Udoo i.MX6 Quad Board + - uniwest,imx6q-evi # Uniwest Evi - variscite,dt6customboard + - wand,imx6q-wandboard # Wandboard i.MX6 Quad Board + - zealz,imx6q-gk802 # Zealz GK802 + - zii,imx6q-zii-rdu2 # ZII RDU2 Board + - const: fsl,imx6q + + - description: i.MX6Q Advantech DMS-BA16 Boards + items: + - enum: + - advantech,imx6q-dms-ba16 # Advantech DMS-BA16 + - ge,imx6q-b450v3 # General Electric B450v3 + - ge,imx6q-b650v3 # General Electric B650v3 + - ge,imx6q-b850v3 # General Electric B850v3 + - const: advantech,imx6q-ba16 + - const: fsl,imx6q + + - description: i.MX6Q Armadeus APF6 Boards + items: + - const: armadeus,imx6q-apf6dev + - const: armadeus,imx6q-apf6 + - const: fsl,imx6q + + - description: i.MX6Q CompuLab Utilite Pro Board + items: + - const: compulab,utilite-pro + - const: compulab,cm-fx6 + - const: fsl,imx6q + + - description: i.MX6Q DFI FS700-M60-6QD Board + items: + - const: dfi,fs700-m60-6qd + - const: dfi,fs700e-m60 + - const: fsl,imx6q + + - description: i.MX6Q DHCOM Premium Developer Kit Board + items: + - const: dh,imx6q-dhcom-pdk2 + - const: dh,imx6q-dhcom-som - const: fsl,imx6q - description: i.MX6Q Gateworks Ventana Boards @@ -172,11 +308,32 @@ properties: - const: phytec,imx6q-pfla02 # PHYTEC phyFLEX-i.MX6 Quad - const: fsl,imx6q + - description: i.MX6Q Boards with Toradex Apalis iMX6Q/D Module + items: + - enum: + - toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board + - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board + - const: toradex,apalis_imx6q + - const: fsl,imx6q + + - description: i.MX6Q Toradex Apalis iMX6Q/D Module on Ixora Carrier Board V1.1 + items: + - const: toradex,apalis_imx6q-ixora-v1.1 + - const: toradex,apalis_imx6q-ixora + - const: toradex,apalis_imx6q + - const: fsl,imx6q + - description: i.MX6QP based Boards items: - enum: + - boundary,imx6qp-nitrogen6_max + - boundary,imx6qp-nitrogen6_som2 - fsl,imx6qp-sabreauto # i.MX6 Quad Plus SABRE Automotive Board - fsl,imx6qp-sabresd # i.MX6 Quad Plus SABRE Smart Device Board + - karo,imx6qp-tx6qp # Ka-Ro electronics TX6QP-8037 Module + - prt,prtwd3 # Protonic WD3 board + - wand,imx6qp-wandboard # Wandboard i.MX6 QuadPlus Board + - zii,imx6qp-zii-rdu2 # ZII RDU2+ Board - const: fsl,imx6qp - description: i.MX6QP PHYTEC phyBOARD-Mira @@ -189,32 +346,59 @@ properties: - description: i.MX6DL based Boards items: - enum: - - armadeus,imx6dl-apf6 # APF6 (Solo) SoM - - armadeus,imx6dl-apf6dev # APF6 (Solo) SoM on APF6Dev board + - abb,aristainetos-imx6dl-4 # aristainetos i.MX6 Dual Lite Board 4 + - abb,aristainetos-imx6dl-7 # aristainetos i.MX6 Dual Lite Board 7 + - abb,aristainetos2-imx6dl-4 # aristainetos2 i.MX6 Dual Lite Board 4 + - abb,aristainetos2-imx6dl-7 # aristainetos2 i.MX6 Dual Lite Board 7 + - alt,alti6p # Altesco I6P Board + - boundary,imx6dl-nit6xlite # Boundary Devices Nitrogen6 Lite + - boundary,imx6dl-nitrogen6x # Boundary Devices Nitrogen6x + - bticino,imx6dl-mamoj # BTicino i.MX6DL Mamoj - eckelmann,imx6dl-ci4x10 - emtrion,emcon-mx6 # emCON-MX6S or emCON-MX6DL SoM - emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base + - engicam,imx6-icore # Engicam i.CoreM6 Starter Kit + - engicam,imx6-icore-rqs # Engicam i.CoreM6 RQS Starter Kit - fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board + - fsl,imx6dl-sabrelite # i.MX6 DualLite SABRE Lite Board - fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board + - karo,imx6dl-tx6dl # Ka-Ro electronics TX6U Modules - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - poslab,imx6dl-savageboard # Poslab SavageBoard Dual - prt,prtrvt # Protonic RVT board - prt,prtvt7 # Protonic VT7 board + - rex,imx6dl-rex-basic # Rex Basic i.MX6 Dual Lite Board + - riot,imx6s-riotboard # RIoTboard i.MX6S + - solidrun,cubox-i/dl # SolidRun Cubox-i Solo/DualLite + - solidrun,hummingboard/dl + - solidrun,hummingboard2/dl # SolidRun HummingBoard2 Solo/DualLite - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf - technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit - technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph - technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi - technologic,imx6dl-ts4900 - technologic,imx6dl-ts7970 - - toradex,colibri_imx6dl # Colibri iMX6 Module - - toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1 - - toradex,colibri_imx6dl-eval-v3 # Colibri iMX6 Module on Colibri Evaluation Board V3 - - toradex,colibri_imx6dl-v1_1-eval-v3 # Colibri iMX6 Module V1.1 on Colibri Evaluation Board V3 + - udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board + - vdl,lanmcu # Van der Laan LANMCU board + - wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board - ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board - ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board - ysoft,imx6dl-yapp4-orion # i.MX6 DualLite Y Soft IOTA Orion board - ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board - const: fsl,imx6dl + - description: i.MX6DL based Armadeus AFP6 Board + items: + - const: armadeus,imx6dl-apf6dev + - const: armadeus,imx6dl-apf6 # APF6 (Solo) SoM + - const: fsl,imx6dl + + - description: i.MX6DL based DFI FS700-M60-6DL Board + items: + - const: dfi,fs700-m60-6dl + - const: dfi,fs700e-m60 + - const: fsl,imx6dl + - description: i.MX6DL Gateworks Ventana Boards items: - enum: @@ -250,12 +434,29 @@ properties: - const: phytec,imx6dl-pfla02 # PHYTEC phyFLEX-i.MX6 Quad - const: fsl,imx6dl + - description: i.MX6DL Toradex Colibri iMX6 Module on Colibri + Evaluation Board V3 + items: + - const: toradex,colibri_imx6dl-eval-v3 + - const: toradex,colibri_imx6dl # Colibri iMX6 Module + - const: fsl,imx6dl + + - description: i.MX6DL Toradex Colibri iMX6 Module V1.1 on Colibri + Evaluation Board V3 + items: + - const: toradex,colibri_imx6dl-v1_1-eval-v3 + - const: toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1 + - const: toradex,colibri_imx6dl-eval-v3 + - const: toradex,colibri_imx6dl # Colibri iMX6 Module + - const: fsl,imx6dl + - description: i.MX6SL based Boards items: - enum: - fsl,imx6sl-evk # i.MX6 SoloLite EVK Board - kobo,tolino-shine2hd - kobo,tolino-shine3 + - revotics,imx6sl-warp # Revotics WaRP Board - const: fsl,imx6sl - description: i.MX6SLL based Boards @@ -268,17 +469,23 @@ properties: - description: i.MX6SX based Boards items: - enum: + - boundary,imx6sx-nitrogen6sx - fsl,imx6sx-sabreauto # i.MX6 SoloX Sabre Auto Board - fsl,imx6sx-sdb # i.MX6 SoloX SDB Board - fsl,imx6sx-sdb-reva # i.MX6 SoloX SDB Rev-A Board + - samtec,imx6sx-vining-2000 # Softing VIN|ING 2000 Board + - udoo,neobasic # UDOO Neo Basic Board + - udoo,neoextended # UDOO Neo Extended + - udoo,neofull # UDOO Neo Full - const: fsl,imx6sx - description: i.MX6UL based Boards items: - enum: - - armadeus,imx6ul-opos6ul # OPOS6UL (i.MX6UL) SoM - - armadeus,imx6ul-opos6uldev # OPOS6UL (i.MX6UL) SoM on OPOS6ULDev board + - engicam,imx6ul-geam # Engicam GEAM6UL Starter Kit + - engicam,imx6ul-isiot # Engicam Is.IoT MX6UL eMMC/NAND Starter kit - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board + - karo,imx6ul-tx6ul # Ka-Ro electronics TXUL-0010 Module - kontron,imx6ul-n6310-som # Kontron N6310 SOM - kontron,imx6ul-n6311-som # Kontron N6311 SOM - technexion,imx6ul-pico-dwarf # TechNexion i.MX6UL Pico-Dwarf @@ -286,6 +493,26 @@ properties: - technexion,imx6ul-pico-pi # TechNexion i.MX6UL Pico-Pi - const: fsl,imx6ul + - description: i.MX6UL Armadeus Systems OPOS6UL SoM Board + items: + - const: armadeus,imx6ul-opos6uldev # OPOS6UL (i.MX6UL) SoM on OPOS6ULDev board + - const: armadeus,imx6ul-opos6ul # OPOS6UL (i.MX6UL) SoM + - const: fsl,imx6ul + + - description: i.MX6UL Digi International ConnectCore 6UL Boards + items: + - enum: + - digi,ccimx6ulsbcexpress # Digi International ConnectCore 6UL SBC Express + - digi,ccimx6ulsbcpro # Digi International ConnectCore 6UL SBC Pro + - const: digi,ccimx6ulsom + - const: fsl,imx6ul + + - description: i.MX6UL Grinn liteBoard + items: + - const: grinn,imx6ul-liteboard + - const: grinn,imx6ul-litesom + - const: fsl,imx6ul + - description: i.MX6UL PHYTEC phyBOARD-Segin items: - enum: @@ -317,8 +544,6 @@ properties: - description: i.MX6ULL based Boards items: - enum: - - armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM - - armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board - fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board - kontron,imx6ull-n6411-som # Kontron N6411 SOM - myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board @@ -326,6 +551,12 @@ properties: - toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT Module on Colibri Eval Board - const: fsl,imx6ull + - description: i.MX6ULL Armadeus Systems OPOS6ULDev Board + items: + - const: armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board + - const: armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM + - const: fsl,imx6ull + - description: i.MX6ULL PHYTEC phyBOARD-Segin items: - enum: @@ -351,17 +582,32 @@ properties: - description: i.MX7S based Boards items: - enum: - - toradex,colibri-imx7s # Colibri iMX7 Solo Module - - toradex,colibri-imx7s-aster # Colibri iMX7 Solo Module on Aster Carrier Board - - toradex,colibri-imx7s-eval-v3 # Colibri iMX7 Solo Module on Colibri Evaluation Board V3 - - tq,imx7s-mba7 # i.MX7S TQ MBa7 with TQMa7S SoM + - element14,imx7s-warp # Element14 Warp i.MX7 Board + - const: fsl,imx7s + + - description: i.MX7S Boards with Toradex Colibri iMX7S Module + items: + - enum: + - toradex,colibri-imx7s-aster # Module on Aster Carrier Board + - toradex,colibri-imx7s-eval-v3 # Module on Colibri Evaluation Board V3 + - const: toradex,colibri-imx7s + - const: fsl,imx7s + + - description: TQ-Systems TQMa7S SoM on MBa7x board + items: + - const: tq,imx7s-mba7 + - const: tq,imx7s-tqma7 - const: fsl,imx7s - description: i.MX7D based Boards items: - enum: + - boundary,imx7d-nitrogen7 + - compulab,cl-som-imx7 # CompuLab CL-SOM-iMX7 - fsl,imx7d-sdb # i.MX7 SabreSD Board - fsl,imx7d-sdb-reva # i.MX7 SabreSD Rev-A Board + - kam,imx7d-flex-concentrator # Kamstrup OMNIA Flex Concentrator + - kam,imx7d-flex-concentrator-mfg # Kamstrup OMNIA Flex Concentrator in manufacturing mode - novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board - technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf - technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit @@ -376,11 +622,16 @@ properties: # Colibri Evaluation Board V3 - toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on # Colibri Evaluation Board V3 - - tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM - zii,imx7d-rmu2 # ZII RMU2 Board - zii,imx7d-rpu2 # ZII RPU2 Board - const: fsl,imx7d + - description: TQ-Systems TQMa7D SoM on MBa7x board + items: + - const: tq,imx7d-mba7 + - const: tq,imx7d-tqma7 + - const: fsl,imx7d + - description: Compulab SBC-iMX7 is a single board computer based on the Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with @@ -392,6 +643,22 @@ properties: - const: compulab,cl-som-imx7 - const: fsl,imx7d + - description: i.MX7D Boards with Toradex Colibri i.MX7D Module + items: + - enum: + - toradex,colibri-imx7d-aster # Module on Aster Carrier Board + - toradex,colibri-imx7d-eval-v3 # Module on Colibri Evaluation Board V3 + - const: toradex,colibri-imx7d + - const: fsl,imx7d + + - description: i.MX7D Boards with Toradex Colibri i.MX7D eMMC Module + items: + - enum: + - toradex,colibri-imx7d-emmc-aster # Module on Aster Carrier Board + - toradex,colibri-imx7d-emmc-eval-v3 # Module on Colibri Evaluation Board V3 + - const: toradex,colibri-imx7d-emmc + - const: fsl,imx7d + - description: i.MX7ULP based Boards items: - enum: @@ -405,9 +672,16 @@ properties: - beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit - fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board - fsl,imx8mm-evk # i.MX8MM EVK Board + - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM - variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module - const: fsl,imx8mm + - description: Kontron BL i.MX8MM (N801X S) Board + items: + - const: kontron,imx8mm-n801x-s + - const: kontron,imx8mm-n801x-som + - const: fsl,imx8mm + - description: Variscite VAR-SOM-MX8MM based boards items: - const: variscite,var-som-mx8mm-symphony @@ -491,10 +765,26 @@ properties: - fsl,vf600 - fsl,vf610 - fsl,vf610m4 - - toradex,vf500-colibri_vf50 # Colibri VF50 Module - - toradex,vf500-colibri_vf50-on-eval # Colibri VF50 Module on Colibri Evaluation Board - - toradex,vf610-colibri_vf61 # Colibri VF61 Module - - toradex,vf610-colibri_vf61-on-eval # Colibri VF61 Module on Colibri Evaluation Board + + - description: Toradex Colibri VF50 Module on Colibri Evaluation Board + items: + - const: toradex,vf500-colibri_vf50-on-eval + - const: toradex,vf500-colibri_vf50 + - const: fsl,vf500 + + - description: VF610 based Boards + items: + - enum: + - lwn,bk4 # Liebherr BK4 controller + - phytec,vf610-cosmic # PHYTEC Cosmic/Cosmic+ Board + - fsl,vf610-twr # VF610 Tower Board + - const: fsl,vf610 + + - description: Toradex Colibri VF61 Module on Colibri Evaluation Board + items: + - const: toradex,vf610-colibri_vf61-on-eval + - const: toradex,vf610-colibri_vf61 + - const: fsl,vf610 - description: ZII's VF610 based Boards items: @@ -515,6 +805,7 @@ properties: - ebs-systart,oxalis - fsl,ls1012a-rdb - fsl,ls1012a-frdm + - fsl,ls1012a-frwy - fsl,ls1012a-qds - const: fsl,ls1012a @@ -613,6 +904,15 @@ properties: - enum: - fsl,lx2160a-qds - fsl,lx2160a-rdb + - fsl,lx2162a-qds + - const: fsl,lx2160a + + - description: SolidRun LX2160A based Boards + items: + - enum: + - solidrun,clearfog-cx + - solidrun,honeycomb + - const: solidrun,lx2160a-cex7 - const: fsl,lx2160a - description: S32V234 based Boards diff --git a/Documentation/devicetree/bindings/arm/idle-states.yaml b/Documentation/devicetree/bindings/arm/idle-states.yaml index ea805c1e6b20..52bce5dbb11f 100644 --- a/Documentation/devicetree/bindings/arm/idle-states.yaml +++ b/Documentation/devicetree/bindings/arm/idle-states.yaml @@ -313,7 +313,7 @@ patternProperties: wakeup-latency-us by this duration. idle-state-name: - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string description: A string used as a descriptive name for the idle state. diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index f736e8c859fa..53f0d4e3ea98 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -84,6 +84,10 @@ properties: - enum: - mediatek,mt8135-evbp1 - const: mediatek,mt8135 + - items: + - enum: + - mediatek,mt8167-pumpkin + - const: mediatek,mt8167 - description: Google Elm (Acer Chromebook R13) items: - const: google,elm-rev8 diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml index c3a8604dfa80..0a9889debc7c 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml @@ -23,6 +23,7 @@ properties: enum: - qcom,sc7180-llcc - qcom,sdm845-llcc + - qcom,sm8150-llcc reg: items: diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml new file mode 100644 index 000000000000..599c65980f5d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 thingy.jp. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mstar/mstar,smpctrl.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MStar/SigmaStar Armv7 SoC SMP control registers + +maintainers: + - Daniel Palmer <daniel@thingy.jp> + +description: | + MStar/SigmaStar's Armv7 SoCs that have more than one processor + have a region of registers that allow setting the boot address + and a magic number that allows secondary processors to leave + the loop they are parked in by the boot ROM. + +properties: + compatible: + items: + - enum: + - sstar,ssd201-smpctrl # SSD201/SSD202D + - const: mstar,smpctrl + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + smpctrl@204000 { + compatible = "sstar,ssd201-smpctrl", "mstar,smpctrl"; + reg = <0x204000 0x200>; + }; diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml index 7c787405bb2f..61d08c473eb8 100644 --- a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml +++ b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml @@ -20,6 +20,12 @@ properties: - thingyjp,breadbee-crust # thingy.jp BreadBee Crust - const: mstar,infinity + - description: infinity2m boards + items: + - enum: + - honestar,ssd201htv2 # Honestar SSD201_HT_V2 devkit + - const: mstar,infinity2m + - description: infinity3 boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index ff94c45eefb0..fe11be65039a 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -245,6 +245,7 @@ properties: - enum: - renesas,r8a7795 - renesas,r8a7796 + - renesas,r8a77961 - renesas,r8a77965 - description: R-Car M3-N (R8A77965) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index b621752aaa65..ef4544ad6f82 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -70,6 +70,24 @@ properties: - const: elgin,rv1108-r1 - const: rockchip,rv1108 + - description: Engicam PX30.Core C.TOUCH 2.0 + items: + - const: engicam,px30-core-ctouch2 + - const: engicam,px30-core + - const: rockchip,px30 + + - description: Engicam PX30.Core C.TOUCH 2.0 10.1" Open Frame + items: + - const: engicam,px30-core-ctouch2-of10 + - const: engicam,px30-core + - const: rockchip,px30 + + - description: Engicam PX30.Core EDIMM2.2 Starter Kit + items: + - const: engicam,px30-core-edimm2.2 + - const: engicam,px30-core + - const: rockchip,px30 + - description: Firefly Firefly-RK3288 items: - enum: @@ -381,6 +399,11 @@ properties: - khadas,edge-v - const: rockchip,rk3399 + - description: Kobol Helios64 + items: + - const: kobol,helios64 + - const: rockchip,rk3399 + - description: Mecer Xtreme Mini S6 items: - const: mecer,xms6 diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index 272508010b02..0796f0c87727 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -14,6 +14,19 @@ properties: const: '/' compatible: oneOf: + - description: S3C2416 based boards + items: + - enum: + - samsung,smdk2416 # Samsung SMDK2416 + - const: samsung,s3c2416 + + - description: S3C6410 based boards + items: + - enum: + - friendlyarm,mini6410 # FriendlyARM Mini6410 + - samsung,smdk6410 # Samsung SMDK6410 + - const: samsung,s3c6410 + - description: S5PV210 based boards items: - enum: @@ -83,6 +96,14 @@ properties: - const: samsung,exynos4412 - const: samsung,exynos4 + - description: Samsung p4note family boards + items: + - enum: + - samsung,n8010 # Samsung GT-N8010/GT-N8013 + - const: samsung,p4note + - const: samsung,exynos4412 + - const: samsung,exynos4 + - description: Exynos5250 based boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml index 6634b3e0853e..149afb5df5af 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml @@ -21,6 +21,10 @@ properties: - st,stm32-power-config - st,stm32-tamp - const: syscon + - items: + - const: st,stm32-tamp + - const: syscon + - const: simple-mfd reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 009b424e456e..e7525a3395e5 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -14,6 +14,20 @@ properties: const: "/" compatible: oneOf: + - description: DH STM32MP1 SoM based Boards + items: + - enum: + - arrow,stm32mp157a-avenger96 # Avenger96 + - dh,stm32mp153c-dhcom-drc02 + - dh,stm32mp157c-dhcom-pdk2 + - dh,stm32mp157c-dhcom-picoitx + - enum: + - dh,stm32mp153c-dhcom-som + - dh,stm32mp157a-dhcor-som + - dh,stm32mp157c-dhcom-som + - enum: + - st,stm32mp153 + - st,stm32mp157 - items: - enum: - st,stm32f429i-disco @@ -39,8 +53,6 @@ properties: - const: st,stm32h743 - items: - enum: - - arrow,stm32mp157a-avenger96 # Avenger96 - - lxa,stm32mp157c-mc1 - shiratech,stm32mp157a-iot-box # IoT Box - shiratech,stm32mp157a-stinger96 # Stinger96 - st,stm32mp157c-ed1 @@ -52,6 +64,13 @@ properties: - const: st,stm32mp157c-ev1 - const: st,stm32mp157c-ed1 - const: st,stm32mp157 + - description: Octavo OSD32MP15x System-in-Package based boards + items: + - enum: + - lxa,stm32mp157c-mc1 # Linux Automation MC-1 + - const: oct,stm32mp15xx-osd32 + - enum: + - st,stm32mp157 - description: Odyssey STM32MP1 SoM based Boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index cab8e1b6417b..6db32fbf813f 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -201,6 +201,19 @@ properties: - const: dserve,dsrv9703c - const: allwinner,sun4i-a10 + - description: Elimo Engineering Impetus SoM + items: + - const: elimo,impetus + - const: sochip,s3 + - const: allwinner,sun8i-v3 + + - description: Elimo Engineering Initium + items: + - const: elimo,initium + - const: elimo,impetus + - const: sochip,s3 + - const: allwinner,sun8i-v3 + - description: Empire Electronix D709 Tablet items: - const: empire-electronix,d709 @@ -251,6 +264,16 @@ properties: - const: friendlyarm,nanopi-neo-plus2 - const: allwinner,sun50i-h5 + - description: FriendlyARM NanoPi R1 + items: + - const: friendlyarm,nanopi-r1 + - const: allwinner,sun8i-h3 + + - description: FriendlyARM ZeroPi + items: + - const: friendlyarm,zeropi + - const: allwinner,sun8i-h3 + - description: Gemei G9 Tablet items: - const: gemei,g9 diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 767e86354c8e..c5fbf869aa93 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -72,6 +72,9 @@ properties: - const: asus,grouper - const: nvidia,tegra30 - items: + - const: ouya,ouya + - const: nvidia,tegra30 + - items: - enum: - nvidia,dalmore - nvidia,roth diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt index ea670a5d7ee3..897eedfa2bc8 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt @@ -18,8 +18,30 @@ clock-names. See ../../clock/clock-bindings.txt for details. ../../reset/reset.txt for details. - reset-names: Must include the following entries: - actmon +- operating-points-v2: See ../bindings/opp/opp.txt for details. +- interconnects: Should contain entries for memory clients sitting on + MC->EMC memory interconnect path. +- interconnect-names: Should include name of the interconnect path for each + interconnect entry. Consult TRM documentation for + information about available memory clients, see MEMORY + CONTROLLER section. + +For each opp entry in 'operating-points-v2' table: +- opp-supported-hw: bitfield indicating SoC speedo ID mask +- opp-peak-kBps: peak bandwidth of the memory channel Example: + dfs_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp@12750000 { + opp-hz = /bits/ 64 <12750000>; + opp-supported-hw = <0x000F>; + opp-peak-kBps = <51000>; + }; + ... + }; + actmon@6000c800 { compatible = "nvidia,tegra124-actmon"; reg = <0x0 0x6000c800 0x0 0x400>; @@ -29,4 +51,7 @@ Example: clock-names = "actmon", "emc"; resets = <&tegra_car 119>; reset-names = "actmon"; + operating-points-v2 = <&dfs_opp_table>; + interconnects = <&mc TEGRA124_MC_MPCORER &emc>; + interconnect-names = "cpu"; }; diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml index 0503651cd214..863a287ebc7e 100644 --- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml @@ -34,7 +34,7 @@ properties: description: The SRAM that needs to be claimed to access the display engine bus. - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 ranges: true diff --git a/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml index 0bee4694578a..4ac78b44e45e 100644 --- a/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml +++ b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml @@ -46,7 +46,7 @@ properties: const: 1 syscon: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Phandle to the Baikal-T1 System Controller DT node interrupts: diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt deleted file mode 100644 index 3108d03802ee..000000000000 --- a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt +++ /dev/null @@ -1,44 +0,0 @@ -NVIDIA Tegra ACONNECT Bus - -The Tegra ACONNECT bus is an AXI switch which is used to connnect various -components inside the Audio Processing Engine (APE). All CPU accesses to -the APE subsystem go through the ACONNECT via an APB to AXI wrapper. - -Required properties: -- compatible: Must be "nvidia,tegra210-aconnect". -- clocks: Must contain the entries for the APE clock (TEGRA210_CLK_APE), - and APE interface clock (TEGRA210_CLK_APB2APE). -- clock-names: Must contain the names "ape" and "apb2ape" for the corresponding - 'clocks' entries. -- power-domains: Must contain a phandle that points to the audio powergate - (namely 'aud') for Tegra210. -- #address-cells: The number of cells used to represent physical base addresses - in the aconnect address space. Should be 1. -- #size-cells: The number of cells used to represent the size of an address - range in the aconnect address space. Should be 1. -- ranges: Mapping of the aconnect address space to the CPU address space. - -All devices accessed via the ACONNNECT are described by child-nodes. - -Example: - - aconnect@702c0000 { - compatible = "nvidia,tegra210-aconnect"; - clocks = <&tegra_car TEGRA210_CLK_APE>, - <&tegra_car TEGRA210_CLK_APB2APE>; - clock-names = "ape", "apb2ape"; - power-domains = <&pd_audio>; - - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x702c0000 0x0 0x702c0000 0x00040000>; - - - child1 { - ... - }; - - child2 { - ... - }; - }; diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml new file mode 100644 index 000000000000..7b1a08c62aef --- /dev/null +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/nvidia,tegra210-aconnect.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra ACONNECT Bus + +description: | + The Tegra ACONNECT bus is an AXI switch which is used to connnect various + components inside the Audio Processing Engine (APE). All CPU accesses to + the APE subsystem go through the ACONNECT via an APB to AXI wrapper. All + devices accessed via the ACONNNECT are described by child-nodes. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - const: nvidia,tegra210-aconnect + - items: + - enum: + - nvidia,tegra186-aconnect + - nvidia,tegra194-aconnect + - const: nvidia,tegra210-aconnect + + clocks: + items: + - description: Must contain the entry for APE clock + - description: Must contain the entry for APE interface clock + + clock-names: + items: + - const: ape + - const: apb2ape + + power-domains: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + +patternProperties: + "@[0-9a-f]+$": + type: object + +required: + - compatible + - clocks + - clock-names + - power-domains + - "#address-cells" + - "#size-cells" + - ranges + +additionalProperties: false + +examples: + - | + #include<dt-bindings/clock/tegra210-car.h> + + aconnect@702c0000 { + compatible = "nvidia,tegra210-aconnect"; + clocks = <&tegra_car TEGRA210_CLK_APE>, + <&tegra_car TEGRA210_CLK_APB2APE>; + clock-names = "ape", "apb2ape"; + power-domains = <&pd_audio>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x702c0000 0x702c0000 0x00040000>; + + // Child device nodes follow ... + }; + +... diff --git a/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml new file mode 100644 index 000000000000..0d06387184d6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/adi,axi-clkgen.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for Analog Devices AXI clkgen pcore clock generator + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + - Michael Hennerich <michael.hennerich@analog.com> + +description: | + The axi_clkgen IP core is a software programmable clock generator, + that can be synthesized on various FPGA platforms. + + Link: https://wiki.analog.com/resources/fpga/docs/axi_clkgen + +properties: + compatible: + enum: + - adi,axi-clkgen-2.00.a + + clocks: + description: + Specifies the reference clock(s) from which the output frequency is + derived. This must either reference one clock if only the first clock + input is connected or two if both clock inputs are connected. + minItems: 1 + maxItems: 2 + + '#clock-cells': + const: 0 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@ff000000 { + compatible = "adi,axi-clkgen-2.00.a"; + #clock-cells = <0>; + reg = <0xff000000 0x1000>; + clocks = <&osc 1>; + }; diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt b/Documentation/devicetree/bindings/clock/axi-clkgen.txt deleted file mode 100644 index aca94fe9416f..000000000000 --- a/Documentation/devicetree/bindings/clock/axi-clkgen.txt +++ /dev/null @@ -1,25 +0,0 @@ -Binding for the axi-clkgen clock generator - -This binding uses the common clock binding[1]. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Required properties: -- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a". -- #clock-cells : from common clock binding; Should always be set to 0. -- reg : Address and length of the axi-clkgen register set. -- clocks : Phandle and clock specifier for the parent clock(s). This must - either reference one clock if only the first clock input is connected or two - if both clock inputs are connected. For the later case the clock connected - to the first input must be specified first. - -Optional properties: -- clock-output-names : From common clock binding. - -Example: - clock@ff000000 { - compatible = "adi,axi-clkgen"; - #clock-cells = <0>; - reg = <0xff000000 0x1000>; - clocks = <&osc 1>; - }; diff --git a/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml b/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml new file mode 100644 index 000000000000..565ca468cb44 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/canaan,k210-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Canaan Kendryte K210 Clock Device Tree Bindings + +maintainers: + - Damien Le Moal <damien.lemoal@wdc.com> + +description: | + Canaan Kendryte K210 SoC clocks driver bindings. The clock + controller node must be defined as a child node of the K210 + system controller node. + + See also: + - dt-bindings/clock/k210-clk.h + +properties: + compatible: + const: canaan,k210-clk + + clocks: + description: + Phandle of the SoC 26MHz fixed-rate oscillator clock. + + '#clock-cells': + const: 1 + +required: + - compatible + - '#clock-cells' + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/k210-clk.h> + clocks { + in0: oscillator { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <26000000>; + }; + }; + + /* ... */ + sysclk: clock-controller { + #clock-cells = <1>; + compatible = "canaan,k210-clk"; + clocks = <&in0>; + }; diff --git a/Documentation/devicetree/bindings/clock/fsl,flexspi-clock.yaml b/Documentation/devicetree/bindings/clock/fsl,flexspi-clock.yaml new file mode 100644 index 000000000000..1fa390ee7b9b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/fsl,flexspi-clock.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/fsl,flexspi-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale FlexSPI clock driver for Layerscape SoCs + +maintainers: + - Michael Walle <michael@walle.cc> + +description: + The Freescale Layerscape SoCs have a special FlexSPI clock which is + derived from the platform PLL. + +properties: + compatible: + enum: + - fsl,ls1028a-flexspi-clk + - fsl,lx2160a-flexspi-clk + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + '#clock-cells': + const: 0 + + clock-output-names: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + - | + dcfg { + #address-cells = <1>; + #size-cells = <1>; + + fspi_clk: clock-controller@900 { + compatible = "fsl,ls1028a-flexspi-clk"; + reg = <0x900 0x4>; + #clock-cells = <0>; + clocks = <&parentclk>; + clock-output-names = "fspi_clk"; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml index 33f3010f48c3..940486ef1051 100644 --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml @@ -21,27 +21,58 @@ description: | The clock consumer should specify the desired clock by having the clock ID in its "clocks" phandle cell. See the full list of clock IDs from: - include/dt-bindings/clock/imx8-clock.h + include/dt-bindings/clock/imx8-lpcg.h properties: compatible: - enum: - - fsl,imx8qxp-lpcg-adma - - fsl,imx8qxp-lpcg-conn - - fsl,imx8qxp-lpcg-dc - - fsl,imx8qxp-lpcg-dsp - - fsl,imx8qxp-lpcg-gpu - - fsl,imx8qxp-lpcg-hsio - - fsl,imx8qxp-lpcg-img - - fsl,imx8qxp-lpcg-lsio - - fsl,imx8qxp-lpcg-vpu - + oneOf: + - const: fsl,imx8qxp-lpcg + - items: + - enum: + - fsl,imx8qm-lpcg + - const: fsl,imx8qxp-lpcg + - enum: + - fsl,imx8qxp-lpcg-adma + - fsl,imx8qxp-lpcg-conn + - fsl,imx8qxp-lpcg-dc + - fsl,imx8qxp-lpcg-dsp + - fsl,imx8qxp-lpcg-gpu + - fsl,imx8qxp-lpcg-hsio + - fsl,imx8qxp-lpcg-img + - fsl,imx8qxp-lpcg-lsio + - fsl,imx8qxp-lpcg-vpu + deprecated: true reg: maxItems: 1 '#clock-cells': const: 1 + clocks: + description: | + Input parent clocks phandle array for each clock + minItems: 1 + maxItems: 8 + + clock-indices: + description: | + An integer array indicating the bit offset for each clock. + Refer to <include/dt-bindings/clock/imx8-lpcg.h> for the + supported LPCG clock indices. + minItems: 1 + maxItems: 8 + + clock-output-names: + description: | + Shall be the corresponding names of the outputs. + NOTE this property must be specified in the same order + as the clock-indices property. + minItems: 1 + maxItems: 8 + + power-domains: + maxItems: 1 + required: - compatible - reg @@ -51,23 +82,33 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/imx8-clock.h> + #include <dt-bindings/clock/imx8-lpcg.h> #include <dt-bindings/firmware/imx/rsrc.h> #include <dt-bindings/interrupt-controller/arm-gic.h> - clock-controller@5b200000 { - compatible = "fsl,imx8qxp-lpcg-conn"; - reg = <0x5b200000 0xb0000>; + sdhc0_lpcg: clock-controller@5b200000 { + compatible = "fsl,imx8qxp-lpcg"; + reg = <0x5b200000 0x10000>; #clock-cells = <1>; + clocks = <&sdhc0_clk IMX_SC_PM_CLK_PER>, + <&conn_ipg_clk>, + <&conn_axi_clk>; + clock-indices = <IMX_LPCG_CLK_0>, + <IMX_LPCG_CLK_4>, + <IMX_LPCG_CLK_5>; + clock-output-names = "sdhc0_lpcg_per_clk", + "sdhc0_lpcg_ipg_clk", + "sdhc0_lpcg_ahb_clk"; + power-domains = <&pd IMX_SC_R_SDHC_0>; }; mmc@5b010000 { compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc"; interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>; reg = <0x5b010000 0x10000>; - clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>, - <&conn_lpcg IMX_CONN_LPCG_SDHC0_PER_CLK>, - <&conn_lpcg IMX_CONN_LPCG_SDHC0_HCLK>; + clocks = <&sdhc0_lpcg IMX_LPCG_CLK_4>, + <&sdhc0_lpcg IMX_LPCG_CLK_0>, + <&sdhc0_lpcg IMX_LPCG_CLK_5>; clock-names = "ipg", "per", "ahb"; power-domains = <&pd IMX_SC_R_SDHC_0>; }; diff --git a/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml new file mode 100644 index 000000000000..c40a74b5d672 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,aoncc-sm8250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for LPASS Always ON Clock Controller on SM8250 SoCs + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. + See include/dt-bindings/clock/qcom,sm8250-lpass-aoncc.h for the full list + of Audio Clock controller clock IDs. + +properties: + compatible: + const: qcom,sm8250-lpass-aon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: LPASS Core voting clock + - description: Glitch Free Mux register clock + + clock-names: + items: + - const: core + - const: bus + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm8250-lpass-aoncc.h> + #include <dt-bindings/sound/qcom,q6afe.h> + clock-controller@3800000 { + #clock-cells = <1>; + compatible = "qcom,sm8250-lpass-aon"; + reg = <0x03380000 0x40000>; + clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>, + <&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>; + clock-names = "core", "bus"; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml new file mode 100644 index 000000000000..915d76206ad0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,audiocc-sm8250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for LPASS Audio Clock Controller on SM8250 SoCs + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. + See include/dt-bindings/clock/qcom,sm8250-lpass-audiocc.h for the full list + of Audio Clock controller clock IDs. + +properties: + compatible: + const: qcom,sm8250-lpass-audiocc + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: LPASS Core voting clock + - description: Glitch Free Mux register clock + + clock-names: + items: + - const: core + - const: bus + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm8250-lpass-audiocc.h> + #include <dt-bindings/sound/qcom,q6afe.h> + clock-controller@3300000 { + #clock-cells = <1>; + compatible = "qcom,sm8250-lpass-audiocc"; + reg = <0x03300000 0x30000>; + clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>, + <&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>; + clock-names = "core", "bus"; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml new file mode 100644 index 000000000000..1121b3934cb9 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-sdx55.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for SDX55 + +maintainers: + - Vinod Koul <vkoul@kernel.org> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on SDX55 + + See also: + - dt-bindings/clock/qcom,gcc-sdx55.h + +properties: + compatible: + const: qcom,gcc-sdx55 + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: PLL test clock source (Optional clock) + minItems: 2 + maxItems: 3 + + clock-names: + items: + - const: bi_tcxo + - const: sleep_clk + - const: core_bi_pll_test_se # Optional clock + minItems: 2 + maxItems: 3 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - reg + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@100000 { + compatible = "qcom,gcc-sdx55"; + reg = <0x00100000 0x1f0000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&sleep_clk>, <&pll_test_clk>; + clock-names = "bi_tcxo", "sleep_clk", "core_bi_pll_test_se"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index a46a3a799a70..12c9cbc0ebf9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -19,8 +19,10 @@ properties: enum: - qcom,sc7180-rpmh-clk - qcom,sdm845-rpmh-clk + - qcom,sdx55-rpmh-clk - qcom,sm8150-rpmh-clk - qcom,sm8250-rpmh-clk + - qcom,sm8350-rpmh-clk clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml new file mode 100644 index 000000000000..f49027edfc44 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sc7180-camcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Clock & Reset Controller Binding for SC7180 + +maintainers: + - Taniya Das <tdas@codeaurora.org> + +description: | + Qualcomm camera clock control module which supports the clocks, resets and + power domains on SC7180. + + See also: + - dt-bindings/clock/qcom,camcc-sc7180.h + +properties: + compatible: + const: qcom,sc7180-camcc + + clocks: + items: + - description: Board XO source + - description: Camera_ahb clock from GCC + - description: Camera XO clock from GCC + + clock-names: + items: + - const: bi_tcxo + - const: iface + - const: xo + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sc7180.h> + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@ad00000 { + compatible = "qcom,sc7180-camcc"; + reg = <0x0ad00000 0x10000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_CAMERA_AHB_CLK>, + <&gcc GCC_CAMERA_XO_CLK>; + clock-names = "bi_tcxo", "iface", "xo"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt deleted file mode 100644 index da92f5748dee..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt +++ /dev/null @@ -1,68 +0,0 @@ -* Renesas R-Car USB 2.0 clock selector - -This file provides information on what the device node for the R-Car USB 2.0 -clock selector. - -If you connect an external clock to the USB_EXTAL pin only, you should set -the clock rate to "usb_extal" node only. -If you connect an oscillator to both the USB_XTAL and USB_EXTAL, this module -is not needed because this is default setting. (Of course, you can set the -clock rates to both "usb_extal" and "usb_xtal" nodes. - -Case 1: An external clock connects to R-Car SoC - +----------+ +--- R-Car ---------------------+ - |External |---|USB_EXTAL ---> all usb channels| - |clock | |USB_XTAL | - +----------+ +-------------------------------+ -In this case, we need this driver with "usb_extal" clock. - -Case 2: An oscillator connects to R-Car SoC - +----------+ +--- R-Car ---------------------+ - |Oscillator|---|USB_EXTAL -+-> all usb channels| - | |---|USB_XTAL --+ | - +----------+ +-------------------------------+ -In this case, we don't need this selector. - -Required properties: -- compatible: "renesas,r8a7795-rcar-usb2-clock-sel" if the device is a part of - an R8A7795 SoC. - "renesas,r8a7796-rcar-usb2-clock-sel" if the device if a part of - an R8A77960 SoC. - "renesas,r8a77961-rcar-usb2-clock-sel" if the device if a part of - an R8A77961 SoC. - "renesas,rcar-gen3-usb2-clock-sel" for a generic R-Car Gen3 - compatible device. - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first - followed by the generic version. - -- reg: offset and length of the USB 2.0 clock selector register block. -- clocks: A list of phandles and specifier pairs. -- clock-names: Name of the clocks. - - The functional clock of USB 2.0 host side must be "ehci_ohci" - - The functional clock of HS-USB side must be "hs-usb-if" - - The USB_EXTAL clock pin must be "usb_extal" - - The USB_XTAL clock pin must be "usb_xtal" -- #clock-cells: Must be 0 -- power-domains: A phandle and symbolic PM domain specifier. - See power/renesas,rcar-sysc.yaml. -- resets: A list of phandles and specifier pairs. -- reset-names: Name of the resets. - - The reset of USB 2.0 host side must be "ehci_ohci" - - The reset of HS-USB side must be "hs-usb-if" - -Example (R-Car H3): - - usb2_clksel: clock-controller@e6590630 { - compatible = "renesas,r8a7795-rcar-usb2-clock-sel", - "renesas,rcar-gen3-usb2-clock-sel"; - reg = <0 0xe6590630 0 0x02>; - clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, - <&usb_extal>, <&usb_xtal>; - clock-names = "ehci_ohci", "hs-usb-if", "usb_extal", "usb_xtal"; - #clock-cells = <0>; - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; - resets = <&cpg 703>, <&cpg 704>; - reset-names = "ehci_ohci", "hs-usb-if"; - }; diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml new file mode 100644 index 000000000000..5be1229b3d6e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/clock/renesas,rcar-usb2-clock-sel.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Renesas R-Car USB 2.0 clock selector + +maintainers: + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +description: | + If you connect an external clock to the USB_EXTAL pin only, you should set + the clock rate to "usb_extal" node only. + If you connect an oscillator to both the USB_XTAL and USB_EXTAL, this module + is not needed because this is default setting. (Of course, you can set the + clock rates to both "usb_extal" and "usb_xtal" nodes. + + Case 1: An external clock connects to R-Car SoC + +----------+ +--- R-Car ---------------------+ + |External |---|USB_EXTAL ---> all usb channels| + |clock | |USB_XTAL | + +----------+ +-------------------------------+ + + In this case, we need this driver with "usb_extal" clock. + + Case 2: An oscillator connects to R-Car SoC + +----------+ +--- R-Car ---------------------+ + |Oscillator|---|USB_EXTAL -+-> all usb channels| + | |---|USB_XTAL --+ | + +----------+ +-------------------------------+ + In this case, we don't need this selector. + +properties: + compatible: + items: + - enum: + - renesas,r8a7795-rcar-usb2-clock-sel # R-Car H3 + - renesas,r8a7796-rcar-usb2-clock-sel # R-Car M3-W + - renesas,r8a77961-rcar-usb2-clock-sel # R-Car M3-W+ + - const: renesas,rcar-gen3-usb2-clock-sel + + reg: + maxItems: 1 + + clocks: + minItems: 4 + maxItems: 4 + + clock-names: + items: + - const: ehci_ohci + - const: hs-usb-if + - const: usb_extal + - const: usb_xtal + + '#clock-cells': + const: 0 + + power-domains: + maxItems: 1 + + resets: + minItems: 2 + maxItems: 2 + + reset-names: + items: + - const: ehci_ohci + - const: hs-usb-if + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - power-domains + - resets + - reset-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + usb2_clksel: clock-controller@e6590630 { + compatible = "renesas,r8a7795-rcar-usb2-clock-sel", + "renesas,rcar-gen3-usb2-clock-sel"; + reg = <0xe6590630 0x02>; + clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, + <&usb_extal>, <&usb_xtal>; + clock-names = "ehci_ohci", "hs-usb-if", "usb_extal", "usb_xtal"; + #clock-cells = <0>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 703>, <&cpg 704>; + reset-names = "ehci_ohci", "hs-usb-if"; + }; diff --git a/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml b/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml new file mode 100644 index 000000000000..e17143cac316 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 SiFive, Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/sifive/fu740-prci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SiFive FU740 Power Reset Clock Interrupt Controller (PRCI) + +maintainers: + - Zong Li <zong.li@sifive.com> + - Paul Walmsley <paul.walmsley@sifive.com> + +description: + On the FU740 family of SoCs, most system-wide clock and reset integration + is via the PRCI IP block. + The clock consumer should specify the desired clock via the clock ID + macros defined in include/dt-bindings/clock/sifive-fu740-prci.h. + These macros begin with PRCI_CLK_. + + The hfclk and rtcclk nodes are required, and represent physical + crystals or resonators located on the PCB. These nodes should be present + underneath /, rather than /soc. + +properties: + compatible: + const: sifive,fu740-c000-prci + + reg: + maxItems: 1 + + clocks: + items: + - description: high frequency clock. + - description: RTL clock. + + clock-names: + items: + - const: hfclk + - const: rtcclk + + "#clock-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - "#clock-cells" + +additionalProperties: false + +examples: + - | + prci: clock-controller@10000000 { + compatible = "sifive,fu740-c000-prci"; + reg = <0x10000000 0x1000>; + clocks = <&hfclk>, <&rtcclk>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 62781518aefc..4286ed767a0a 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -37,7 +37,7 @@ properties: description: Size of the connector, should be specified in case of non-fullsize 'usb-a-connector' or 'usb-b-connector' compatible connectors. - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string enum: - mini @@ -67,7 +67,7 @@ properties: power-role: description: Determines the power role that the Type C connector will support. "dual" refers to Dual Role Port (DRP). - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string enum: - source @@ -76,7 +76,7 @@ properties: try-power-role: description: Preferred power role. - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string enum: - source @@ -86,13 +86,31 @@ properties: data-role: description: Data role if Type C connector supports USB data. "dual" refers Dual Role Device (DRD). - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string enum: - host - device - dual + typec-power-opmode: + description: Determines the power operation mode that the Type C connector + will support and will advertise through CC pins when it has no power + delivery support. + - "default" corresponds to default USB voltage and current defined by the + USB 2.0 and USB 3.2 specifications, 5V 500mA for USB 2.0 ports and + 5V 900mA or 1500mA for USB 3.2 ports in single-lane or dual-lane + operation respectively. + - "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined in USB + Type-C Cable and Connector specification, when Power Delivery is not + supported. + allOf: + - $ref: /schemas/types.yaml#/definitions/string + enum: + - default + - 1.5A + - 3.0A + # The following are optional properties for "usb-c-connector" with power # delivery support. source-pdos: @@ -192,6 +210,12 @@ allOf: type: const: micro +anyOf: + - not: + required: + - typec-power-opmode + - new-source-frs-typec-current + additionalProperties: true examples: diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 60585a4fc22b..9392b5502a32 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -49,8 +49,8 @@ properties: Video port for panel or connector. required: - - port@0 - - port@1 + - port@0 + - port@1 required: - compatible diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml index 8c0e4f285fbc..fccd63521a8c 100644 --- a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml @@ -26,11 +26,9 @@ properties: description: GPIO connected to active low reset dvdd12-supply: - maxItems: 1 description: Regulator for 1.2V digital core power. dvdd25-supply: - maxItems: 1 description: Regulator for 2.5V digital core power. ports: diff --git a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml index ab5be2625224..35c9dfd86650 100644 --- a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml @@ -39,10 +39,10 @@ properties: properties: '#address-cells': - const: 1 + const: 1 '#size-cells': - const: 0 + const: 0 port@0: type: object diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml index efbb3d0117dc..02cfc0a3b550 100644 --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml @@ -35,11 +35,9 @@ properties: maxItems: 1 ovdd-supply: - maxItems: 1 description: I/O voltage pwr18-supply: - maxItems: 1 description: core voltage interrupts: diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index e5e3c72630cf..66a14d60ce1d 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -79,8 +79,7 @@ properties: The GPIO used to control the power down line of this device. maxItems: 1 - power-supply: - maxItems: 1 + power-supply: true required: - compatible diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml index 7e27cfcf770d..763c7909473e 100644 --- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml @@ -35,11 +35,9 @@ properties: description: GPIO connected to active low reset. vdd12-supply: - maxItems: 1 description: Regulator for 1.2V digital core power. vdd33-supply: - maxItems: 1 description: Regulator for 3.3V digital core power. ports: diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml index 3ddb35fcf0a2..64e8a1c24b40 100644 --- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml +++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml @@ -60,7 +60,6 @@ properties: description: GPIO controlling bridge enable vdd-supply: - maxItems: 1 description: Power supply for the bridge required: diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml index 469ac4a34273..3d5ce08a5792 100644 --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml @@ -74,7 +74,6 @@ properties: description: Power down GPIO signal, pin name "/PDWN", active low. vcc-supply: - maxItems: 1 description: Power supply for the TTL output, TTL CLOCKOUT signal, LVDS input, PLL and digital circuitry. diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml index fd3113aa9ccd..b5959cc78b8d 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml @@ -28,11 +28,9 @@ properties: description: i2c address of the bridge, 0x0f vdd-supply: - maxItems: 1 description: 1.2V LVDS Power Supply vddio-supply: - maxItems: 1 description: 1.8V IO Power Supply stby-gpios: diff --git a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml index 40caa6118809..a222b52d8b8f 100644 --- a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml +++ b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml @@ -18,8 +18,8 @@ description: | properties: compatible: items: - - const: intel,keembay-msscam - - const: syscon + - const: intel,keembay-msscam + - const: syscon reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml index 91cb4c3e0198..a108029ecfab 100644 --- a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml +++ b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml @@ -32,7 +32,7 @@ required: - power-supply - reset-gpios -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml index d2170de6b723..2f5df1d235ae 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml @@ -22,7 +22,7 @@ properties: compatible: items: - enum: - - tianma,fhd-video + - tianma,fhd-video - const: novatek,nt36672a description: This indicates the panel manufacturer of the panel that is in turn using the NT36672A panel driver. This compatible string diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index f9750b0b6708..27fffafe5b5c 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -159,6 +159,8 @@ properties: - innolux,g121x1-l03 # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel - innolux,n116bge + # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel + - innolux,n125hce-gn1 # InnoLux 15.6" WXGA TFT LCD panel - innolux,n156bge-l21 # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt index ac63ae4a3861..34d993338453 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt @@ -20,6 +20,10 @@ Required properties: - reset-names: Must include the following entries: - host1x +Each host1x client module having to perform DMA through the Memory Controller +should have the interconnect endpoints set to the Memory Client and External +Memory respectively. + The host1x top-level node defines a number of children, each representing one of the following host1x client modules: @@ -36,6 +40,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - mpe + Optional properties: + - interconnects: Must contain entry for the MPE memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - vi: video input Required properties: @@ -113,6 +123,12 @@ of the following host1x client modules: Required properties: - remote-endpoint: phandle to vi port 'endpoint' node. + Optional properties: + - interconnects: Must contain entry for the VI memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - epp: encoder pre-processor Required properties: @@ -126,6 +142,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - epp + Optional properties: + - interconnects: Must contain entry for the EPP memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - isp: image signal processor Required properties: @@ -139,6 +161,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - isp + Optional properties: + - interconnects: Must contain entry for the ISP memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - gr2d: 2D graphics engine Required properties: @@ -152,6 +180,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - 2d + Optional properties: + - interconnects: Must contain entry for the GR2D memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - gr3d: 3D graphics engine Required properties: @@ -170,6 +204,12 @@ of the following host1x client modules: - 3d - 3d2 (Only required on SoCs with two 3D clocks) + Optional properties: + - interconnects: Must contain entry for the GR3D memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - dc: display controller Required properties: @@ -197,6 +237,10 @@ of the following host1x client modules: - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - nvidia,edid: supplies a binary EDID blob - nvidia,panel: phandle of a display panel + - interconnects: Must contain entry for the DC memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. - hdmi: High Definition Multimedia Interface @@ -345,6 +389,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - vic + Optional properties: + - interconnects: Must contain entry for the VIC memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + Example: / { @@ -498,6 +548,15 @@ Example: resets = <&tegra_car 27>; reset-names = "dc"; + interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>, + <&mc TEGRA20_MC_DISPLAY0B &emc>, + <&mc TEGRA20_MC_DISPLAY0C &emc>, + <&mc TEGRA20_MC_DISPLAYHC &emc>; + interconnect-names = "wina", + "winb", + "winc", + "cursor"; + rgb { status = "disabled"; }; @@ -513,6 +572,15 @@ Example: resets = <&tegra_car 26>; reset-names = "dc"; + interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>, + <&mc TEGRA20_MC_DISPLAY0BB &emc>, + <&mc TEGRA20_MC_DISPLAY0CB &emc>, + <&mc TEGRA20_MC_DISPLAYHCB &emc>; + interconnect-names = "wina", + "winb", + "winc", + "cursor"; + rgb { status = "disabled"; }; diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml index 7b9d468c3e52..403d57977ee7 100644 --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -98,7 +98,6 @@ properties: maxItems: 1 dmas: - maxItems: 4 items: - description: Video layer, plane 0 (RGB or luma) - description: Video layer, plane 1 (U/V or U) diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml index 372679dbd216..b6e1ebfaf366 100644 --- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml @@ -21,6 +21,7 @@ properties: compatible: oneOf: - const: allwinner,sun50i-a64-dma + - const: allwinner,sun50i-a100-dma - const: allwinner,sun50i-h6-dma - items: - const: allwinner,sun8i-r40-dma @@ -56,7 +57,9 @@ required: if: properties: compatible: - const: allwinner,sun50i-h6-dma + enum: + - allwinner,sun50i-a100-dma + - allwinner,sun50i-h6-dma then: properties: diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt b/Documentation/devicetree/bindings/dma/atmel-xdma.txt index 4dc398e1a371..510b7f25ba24 100644 --- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt +++ b/Documentation/devicetree/bindings/dma/atmel-xdma.txt @@ -2,7 +2,8 @@ * XDMA Controller Required properties: -- compatible: Should be "atmel,sama5d4-dma" or "microchip,sam9x60-dma". +- compatible: Should be "atmel,sama5d4-dma", "microchip,sam9x60-dma" or + "microchip,sama7g5-dma". - reg: Should contain DMA registers location and length. - interrupts: Should contain DMA interrupt. - #dma-cells: Must be <1>, used to represent the number of integer cells in diff --git a/Documentation/devicetree/bindings/dma/dma-common.yaml b/Documentation/devicetree/bindings/dma/dma-common.yaml index 307b499e8968..ad06d36af208 100644 --- a/Documentation/devicetree/bindings/dma/dma-common.yaml +++ b/Documentation/devicetree/bindings/dma/dma-common.yaml @@ -38,12 +38,12 @@ properties: maxItems: 255 dma-channels: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: Number of DMA channels supported by the controller. dma-requests: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: Number of DMA request signals supported by the controller. diff --git a/Documentation/devicetree/bindings/dma/dma-router.yaml b/Documentation/devicetree/bindings/dma/dma-router.yaml index 4cee5667b8a8..e72748496fd9 100644 --- a/Documentation/devicetree/bindings/dma/dma-router.yaml +++ b/Documentation/devicetree/bindings/dma/dma-router.yaml @@ -23,7 +23,7 @@ properties: pattern: "^dma-router(@.*)?$" dma-masters: - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array description: Array of phandles to the DMA controllers the router can direct the signal to. diff --git a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml index 00f19b3cac31..6a2043721b95 100644 --- a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml +++ b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml @@ -48,7 +48,7 @@ properties: ingenic,reserved-channels property. ingenic,reserved-channels: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: > Bitmask of channels to reserve for devices that need a specific channel. These channels will only be assigned when explicitely diff --git a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt index 2117db0ce4f2..fef9c1eeb264 100644 --- a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt +++ b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt @@ -4,6 +4,7 @@ Required properties: - compatible should contain: * "mediatek,mt2712-uart-dma" for MT2712 compatible APDMA * "mediatek,mt6577-uart-dma" for MT6577 and all of the above + * "mediatek,mt8516-uart-dma", "mediatek,mt6577" for MT8516 SoC - reg: The base address of the APDMA register bank. diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt deleted file mode 100644 index 245d3063715c..000000000000 --- a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt +++ /dev/null @@ -1,56 +0,0 @@ -* NVIDIA Tegra Audio DMA (ADMA) controller - -The Tegra Audio DMA controller that is used for transferring data -between system memory and the Audio Processing Engine (APE). - -Required properties: -- compatible: Should contain one of the following: - - "nvidia,tegra210-adma": for Tegra210 - - "nvidia,tegra186-adma": for Tegra186 and Tegra194 -- reg: Should contain DMA registers location and length. This should be - a single entry that includes all of the per-channel registers in one - contiguous bank. -- interrupts: Should contain all of the per-channel DMA interrupts in - ascending order with respect to the DMA channel index. -- clocks: Must contain one entry for the ADMA module clock - (TEGRA210_CLK_D_AUDIO). -- clock-names: Must contain the name "d_audio" for the corresponding - 'clocks' entry. -- #dma-cells : Must be 1. The first cell denotes the receive/transmit - request number and should be between 1 and the maximum number of - requests supported. This value corresponds to the RX/TX_REQUEST_SELECT - fields in the ADMA_CHn_CTRL register. - - -Example: - -adma: dma@702e2000 { - compatible = "nvidia,tegra210-adma"; - reg = <0x0 0x702e2000 0x0 0x2000>; - interrupt-parent = <&tegra_agic>; - interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>; - clock-names = "d_audio"; - #dma-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml new file mode 100644 index 000000000000..5c2e2f156e31 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/nvidia,tegra210-adma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Audio DMA (ADMA) controller + +description: | + The Tegra Audio DMA controller is used for transferring data + between system memory and the Audio Processing Engine (APE). + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra210-adma + - nvidia,tegra186-adma + - items: + - const: nvidia,tegra194-adma + - const: nvidia,tegra186-adma + + reg: + maxItems: 1 + + interrupts: + description: | + Should contain all of the per-channel DMA interrupts in + ascending order with respect to the DMA channel index. + minItems: 1 + maxItems: 32 + + clocks: + description: Must contain one entry for the ADMA module clock + maxItems: 1 + + clock-names: + const: d_audio + + "#dma-cells": + description: | + The first cell denotes the receive/transmit request number and + should be between 1 and the maximum number of requests supported. + This value corresponds to the RX/TX_REQUEST_SELECT fields in the + ADMA_CHn_CTRL register. + const: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include<dt-bindings/clock/tegra210-car.h> + + dma-controller@702e2000 { + compatible = "nvidia,tegra210-adma"; + reg = <0x702e2000 0x2000>; + interrupt-parent = <&tegra_agic>; + interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>; + clock-names = "d_audio"; + #dma-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml new file mode 100644 index 000000000000..f8142adf9aea --- /dev/null +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/qcom,gpi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies Inc GPI DMA controller + +maintainers: + - Vinod Koul <vkoul@kernel.org> + +description: | + QCOM GPI DMA controller provides DMA capabilities for + peripheral buses such as I2C, UART, and SPI. + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + enum: + - qcom,sdm845-gpi-dma + + reg: + maxItems: 1 + + interrupts: + description: + Interrupt lines for each GPI instance + maxItems: 13 + + "#dma-cells": + const: 3 + description: > + DMA clients must use the format described in dma.txt, giving a phandle + to the DMA controller plus the following 3 integer cells: + - channel: if set to 0xffffffff, any available channel will be allocated + for the client. Otherwise, the exact channel specified will be used. + - seid: serial id of the client as defined in the SoC documentation. + - client: type of the client as defined in dt-bindings/dma/qcom-gpi.h + + iommus: + maxItems: 1 + + dma-channels: + maximum: 31 + + dma-channel-mask: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - "#dma-cells" + - iommus + - dma-channels + - dma-channel-mask + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/dma/qcom-gpi.h> + gpi_dma0: dma-controller@800000 { + compatible = "qcom,gpi-dma"; + #dma-cells = <3>; + reg = <0x00800000 0x60000>; + iommus = <&apps_smmu 0x0016 0x0>; + dma-channels = <13>; + dma-channel-mask = <0xfa>; + interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 248 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 249 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 250 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 253 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 254 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 255 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml index b548e4723936..c07eb6f2fc8d 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml @@ -73,7 +73,6 @@ properties: maxItems: 1 clock-names: - maxItems: 1 items: - const: fck diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml index ef1d6879c158..6b35089ac017 100644 --- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml +++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml @@ -54,7 +54,7 @@ properties: maximum: 16 dma-masters: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Number of DMA masters supported by the controller. In case if not specified the driver will try to auto-detect this and @@ -63,7 +63,7 @@ properties: maximum: 4 chan_allocation_order: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | DMA channels allocation order specifier. Zero means ascending order (first free allocated), while one - descending (last free allocated). @@ -71,7 +71,7 @@ properties: enum: [0, 1] chan_priority: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | DMA channels priority order. Zero means ascending channels priority so the very first channel has the highest priority. While 1 means @@ -80,7 +80,7 @@ properties: enum: [0, 1] block_size: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: Maximum block size supported by the DMA controller. enum: [3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095] @@ -139,7 +139,7 @@ properties: default: 256 snps,dma-protection-control: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Bits one-to-one passed to the AHB HPROT[3:1] bus. Each bit setting indicates the following features: bit 0 - privileged mode, diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml new file mode 100644 index 000000000000..df29d59d13a8 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml @@ -0,0 +1,166 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +# Author: Peter Ujfalusi <peter.ujfalusi@ti.com> +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings + +maintainers: + - Peter Ujfalusi <peter.ujfalusi@gmail.com> + +description: | + The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR + mode channels of K3 UDMA-P. + BCDMA includes block copy channels and Split channels. + + Block copy channels mainly used for memory to memory transfers, but with + optional triggers a block copy channel can service peripherals by accessing + directly to memory mapped registers or area. + + Split channels can be used to service PSI-L based peripherals. + The peripherals can be PSI-L native or legacy, non PSI-L native peripherals + with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and the + legacy peripheral. + + PDMAs can be configured via BCDMA split channel's peer registers to match with + the configuration of the legacy peripheral. + +allOf: + - $ref: /schemas/dma/dma-controller.yaml# + +properties: + compatible: + const: ti,am64-dmss-bcdma + + "#dma-cells": + const: 3 + description: | + cell 1: type of the BCDMA channel to be used to service the peripheral: + 0 - split channel + 1 - block copy channel using global trigger 1 + 2 - block copy channel using global trigger 2 + 3 - block copy channel using local trigger + + cell 2: parameter for the channel: + if cell 1 is 0 (split channel): + PSI-L thread ID of the remote (to BCDMA) end. + Valid ranges for thread ID depends on the data movement direction: + for source thread IDs (rx): 0 - 0x7fff + for destination thread IDs (tx): 0x8000 - 0xffff + + Please refer to the device documentation for the PSI-L thread map and + also the PSI-L peripheral chapter for the correct thread ID. + if cell 1 is 1 or 2 (block copy channel using global trigger): + Unused, ignored + + The trigger must be configured for the channel externally to BCDMA, + channels using global triggers should not be requested directly, but + via DMA event router. + if cell 1 is 3 (block copy channel using local trigger): + bchan number of the locally triggered channel + + cell 3: ASEL value for the channel + + reg: + maxItems: 5 + + reg-names: + items: + - const: gcfg + - const: bchanrt + - const: rchanrt + - const: tchanrt + - const: ringrt + + msi-parent: true + + ti,asel: + $ref: /schemas/types.yaml#/definitions/uint32 + description: ASEL value for non slave channels + + ti,sci-rm-range-bchan: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of BCDMA block-copy channel resource subtypes for resource + allocation for this host + minItems: 1 + # Should be enough + maxItems: 255 + items: + maximum: 0x3f + + ti,sci-rm-range-tchan: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of BCDMA split tx channel resource subtypes for resource allocation + for this host + minItems: 1 + # Should be enough + maxItems: 255 + items: + maximum: 0x3f + + ti,sci-rm-range-rchan: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of BCDMA split rx channel resource subtypes for resource allocation + for this host + minItems: 1 + # Should be enough + maxItems: 255 + items: + maximum: 0x3f + +required: + - compatible + - "#dma-cells" + - reg + - reg-names + - msi-parent + - ti,sci + - ti,sci-dev-id + - ti,sci-rm-range-bchan + - ti,sci-rm-range-tchan + - ti,sci-rm-range-rchan + +unevaluatedProperties: false + +examples: + - |+ + cbass_main { + #address-cells = <2>; + #size-cells = <2>; + + main_dmss { + compatible = "simple-mfd"; + #address-cells = <2>; + #size-cells = <2>; + dma-ranges; + ranges; + + ti,sci-dev-id = <25>; + + main_bcdma: dma-controller@485c0100 { + compatible = "ti,am64-dmss-bcdma"; + + reg = <0x0 0x485c0100 0x0 0x100>, + <0x0 0x4c000000 0x0 0x20000>, + <0x0 0x4a820000 0x0 0x20000>, + <0x0 0x4aa40000 0x0 0x20000>, + <0x0 0x4bc00000 0x0 0x100000>; + reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt"; + msi-parent = <&inta_main_dmss>; + #dma-cells = <3>; + + ti,sci = <&dmsc>; + ti,sci-dev-id = <26>; + + ti,sci-rm-range-bchan = <0x20>; /* BLOCK_COPY_CHAN */ + ti,sci-rm-range-rchan = <0x21>; /* SPLIT_TR_RX_CHAN */ + ti,sci-rm-range-tchan = <0x22>; /* SPLIT_TR_TX_CHAN */ + }; + }; + }; diff --git a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml new file mode 100644 index 000000000000..ea19d12a9337 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +# Author: Peter Ujfalusi <peter.ujfalusi@ti.com> +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings + +maintainers: + - Peter Ujfalusi <peter.ujfalusi@gmail.com> + +description: | + The Packet DMA (PKTDMA) is intended to perform similar functions as the packet + mode channels of K3 UDMA-P. + PKTDMA only includes Split channels to service PSI-L based peripherals. + + The peripherals can be PSI-L native or legacy, non PSI-L native peripherals + with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and the + legacy peripheral. + + PDMAs can be configured via PKTDMA split channel's peer registers to match + with the configuration of the legacy peripheral. + +allOf: + - $ref: /schemas/dma/dma-controller.yaml# + +properties: + compatible: + const: ti,am64-dmss-pktdma + + "#dma-cells": + const: 2 + description: | + The first cell is the PSI-L thread ID of the remote (to PKTDMA) end. + Valid ranges for thread ID depends on the data movement direction: + for source thread IDs (rx): 0 - 0x7fff + for destination thread IDs (tx): 0x8000 - 0xffff + + Please refer to the device documentation for the PSI-L thread map and also + the PSI-L peripheral chapter for the correct thread ID. + + The second cell is the ASEL value for the channel + + reg: + maxItems: 4 + + reg-names: + items: + - const: gcfg + - const: rchanrt + - const: tchanrt + - const: ringrt + + msi-parent: true + + ti,sci-rm-range-tchan: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of PKTDMA split tx channel resource subtypes for resource allocation + for this host + minItems: 1 + # Should be enough + maxItems: 255 + items: + maximum: 0x3f + + ti,sci-rm-range-tflow: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of PKTDMA split tx flow resource subtypes for resource allocation + for this host + minItems: 1 + # Should be enough + maxItems: 255 + items: + maximum: 0x3f + + ti,sci-rm-range-rchan: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of PKTDMA split rx channel resource subtypes for resource allocation + for this host + minItems: 1 + # Should be enough + maxItems: 255 + items: + maximum: 0x3f + + ti,sci-rm-range-rflow: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of PKTDMA split rx flow resource subtypes for resource allocation + for this host + minItems: 1 + # Should be enough + maxItems: 255 + items: + maximum: 0x3f + +required: + - compatible + - "#dma-cells" + - reg + - reg-names + - msi-parent + - ti,sci + - ti,sci-dev-id + - ti,sci-rm-range-tchan + - ti,sci-rm-range-tflow + - ti,sci-rm-range-rchan + - ti,sci-rm-range-rflow + +unevaluatedProperties: false + +examples: + - |+ + cbass_main { + #address-cells = <2>; + #size-cells = <2>; + + main_dmss { + compatible = "simple-mfd"; + #address-cells = <2>; + #size-cells = <2>; + dma-ranges; + ranges; + + ti,sci-dev-id = <25>; + + main_pktdma: dma-controller@485c0000 { + compatible = "ti,am64-dmss-pktdma"; + + reg = <0x0 0x485c0000 0x0 0x100>, + <0x0 0x4a800000 0x0 0x20000>, + <0x0 0x4aa00000 0x0 0x40000>, + <0x0 0x4b800000 0x0 0x400000>; + reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt"; + msi-parent = <&inta_main_dmss>; + #dma-cells = <2>; + + ti,sci = <&dmsc>; + ti,sci-dev-id = <30>; + + ti,sci-rm-range-tchan = <0x23>, /* UNMAPPED_TX_CHAN */ + <0x24>, /* CPSW_TX_CHAN */ + <0x25>, /* SAUL_TX_0_CHAN */ + <0x26>, /* SAUL_TX_1_CHAN */ + <0x27>, /* ICSSG_0_TX_CHAN */ + <0x28>; /* ICSSG_1_TX_CHAN */ + ti,sci-rm-range-tflow = <0x10>, /* RING_UNMAPPED_TX_CHAN */ + <0x11>, /* RING_CPSW_TX_CHAN */ + <0x12>, /* RING_SAUL_TX_0_CHAN */ + <0x13>, /* RING_SAUL_TX_1_CHAN */ + <0x14>, /* RING_ICSSG_0_TX_CHAN */ + <0x15>; /* RING_ICSSG_1_TX_CHAN */ + ti,sci-rm-range-rchan = <0x29>, /* UNMAPPED_RX_CHAN */ + <0x2b>, /* CPSW_RX_CHAN */ + <0x2d>, /* SAUL_RX_0_CHAN */ + <0x2f>, /* SAUL_RX_1_CHAN */ + <0x31>, /* SAUL_RX_2_CHAN */ + <0x33>, /* SAUL_RX_3_CHAN */ + <0x35>, /* ICSSG_0_RX_CHAN */ + <0x37>; /* ICSSG_1_RX_CHAN */ + ti,sci-rm-range-rflow = <0x2a>, /* FLOW_UNMAPPED_RX_CHAN */ + <0x2c>, /* FLOW_CPSW_RX_CHAN */ + <0x2e>, /* FLOW_SAUL_RX_0/1_CHAN */ + <0x32>, /* FLOW_SAUL_RX_2/3_CHAN */ + <0x36>, /* FLOW_ICSSG_0_RX_CHAN */ + <0x38>; /* FLOW_ICSSG_1_RX_CHAN */ + }; + }; + }; diff --git a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml index 9a87fd9041eb..6a09bbf83d46 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml @@ -1,4 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2019 Texas Instruments Incorporated +# Author: Peter Ujfalusi <peter.ujfalusi@ti.com> %YAML 1.2 --- $id: http://devicetree.org/schemas/dma/ti/k3-udma.yaml# @@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments K3 NAVSS Unified DMA Device Tree Bindings maintainers: - - Peter Ujfalusi <peter.ujfalusi@ti.com> + - Peter Ujfalusi <peter.ujfalusi@gmail.com> description: | The UDMA-P is intended to perform similar (but significantly upgraded) diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index 6edfa705b486..d5117c638b75 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml @@ -131,7 +131,7 @@ properties: default: 1 read-only: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Disables writes to the eeprom. @@ -141,7 +141,7 @@ properties: Total eeprom size in bytes. no-read-rollover: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Indicates that the multi-address eeprom does not automatically roll over reads to the next slave address. Please consult the manual of diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml index 744973637678..121a601db22e 100644 --- a/Documentation/devicetree/bindings/eeprom/at25.yaml +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml @@ -45,13 +45,13 @@ properties: spi-max-frequency: true pagesize: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072] description: Size of the eeprom page. size: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: Total eeprom size in bytes. diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml index 183ec23eda39..f5ee23c2df60 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml @@ -48,6 +48,7 @@ properties: - nxp,pcal6416 - nxp,pcal6524 - nxp,pcal9535 + - nxp,pcal9554b - nxp,pcal9555a - onnn,cat9554 - onnn,pca9654 diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt index 08eed2335db0..e506f30e1a95 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt @@ -13,6 +13,7 @@ Required properties: - gpio-controller : Marks the device node as a GPIO controller. Optional properties: +- clocks : Input clock specifier. Refer to common clock bindings. - interrupts : Interrupt mapping for GPIO IRQ. - xlnx,all-inputs : if n-th bit is setup, GPIO-n is input - xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1 @@ -29,6 +30,7 @@ Example: gpio: gpio@40000000 { #gpio-cells = <2>; compatible = "xlnx,xps-gpio-1.00.a"; + clocks = <&clkc25>; gpio-controller ; interrupt-parent = <µblaze_0_intc>; interrupts = < 6 2 >; diff --git a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt deleted file mode 100644 index e1c49b660d3a..000000000000 --- a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt +++ /dev/null @@ -1,35 +0,0 @@ -Mediatek MT7621 SoC GPIO controller bindings - -The IP core used inside these SoCs has 3 banks of 32 GPIOs each. -The registers of all the banks are interwoven inside one single IO range. -We load one GPIO controller instance per bank. Also the GPIO controller can receive -interrupts on any of the GPIOs, either edge or level. It then interrupts the CPU -using GIC INT12. - -Required properties for the top level node: -- #gpio-cells : Should be two. The first cell is the GPIO pin number and the - second cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. - Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt. Should be 2. The first cell defines the interrupt number, - the second encodes the trigger flags encoded as described in - Documentation/devicetree/bindings/interrupt-controller/interrupts.txt -- compatible: - - "mediatek,mt7621-gpio" for Mediatek controllers -- reg : Physical base address and length of the controller's registers -- interrupt-parent : phandle of the parent interrupt controller. -- interrupts : Interrupt specifier for the controllers interrupt. -- interrupt-controller : Mark the device node as an interrupt controller. -- gpio-controller : Marks the device node as a GPIO controller. - -Example: - gpio@600 { - #gpio-cells = <2>; - #interrupt-cells = <2>; - compatible = "mediatek,mt7621-gpio"; - gpio-controller; - interrupt-controller; - reg = <0x600 0x100>; - interrupt-parent = <&gic>; - interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>; - }; diff --git a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.yaml b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.yaml new file mode 100644 index 000000000000..5bbb2a31266e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/mediatek,mt7621-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT7621 SoC GPIO controller + +maintainers: + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: | + The IP core used inside these SoCs has 3 banks of 32 GPIOs each. + The registers of all the banks are interwoven inside one single IO range. + We load one GPIO controller instance per bank. Also the GPIO controller can receive + interrupts on any of the GPIOs, either edge or level. It then interrupts the CPU + using GIC INT12. + +properties: + $nodename: + pattern: "^gpio@[0-9a-f]+$" + + compatible: + const: mediatek,mt7621-gpio + + reg: + maxItems: 1 + + "#gpio-cells": + const: 2 + + gpio-controller: true + gpio-ranges: true + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - "#gpio-cells" + - gpio-controller + - gpio-ranges + - interrupt-controller + - "#interrupt-cells" + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/mips-gic.h> + + gpio@600 { + compatible = "mediatek,mt7621-gpio"; + reg = <0x600 0x100>; + #gpio-cells = <2>; + gpio-controller; + gpio-ranges = <&pinctrl 0 0 95>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&gic>; + interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>; + }; + +... diff --git a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml new file mode 100644 index 000000000000..1f2ef408bb43 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/mstar,msc313-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MStar/SigmaStar GPIO controller + +maintainers: + - Daniel Palmer <daniel@thingy.jp> + +properties: + $nodename: + pattern: "^gpio@[0-9a-f]+$" + + compatible: + const: mstar,msc313-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + + gpio-ranges: true + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/msc313-gpio.h> + + gpio: gpio@207800 { + compatible = "mstar,msc313e-gpio"; + #gpio-cells = <2>; + reg = <0x207800 0x200>; + gpio-controller; + gpio-ranges = <&pinctrl 0 36 22>, + <&pinctrl 22 63 4>, + <&pinctrl 26 68 6>; + #interrupt-cells = <2>; + interrupt-controller; + interrupt-parent = <&intc_fiq>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml index 6f3e3c01f717..b79f069a04c2 100644 --- a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml +++ b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml @@ -32,7 +32,7 @@ properties: PVT controller has 5 VM (voltage monitor) sensors. vm-map defines CPU core to VM instance mapping. A value of 0xff means that VM sensor is unused. - $ref: /schemas/types.yaml#definitions/uint8-array + $ref: /schemas/types.yaml#/definitions/uint8-array maxItems: 5 clocks: diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml index c523a1beb2b7..7d49478d9668 100644 --- a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml +++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml @@ -29,12 +29,12 @@ properties: const: 0x70 sensirion,blocking-io: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: If set, the driver hold the i2c bus until measurement is finished. sensirion,low-precision: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: If set, the sensor aquire data with low precision (not recommended). The driver aquire data with high precision by default. diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml index c17e5d3ee3f1..8020d739a078 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml @@ -61,7 +61,7 @@ properties: Array of three(TMP513) or two(TMP512) n-Factor value for each remote temperature channel. See datasheet Table 11 for n-Factor range list and value interpretation. - $ref: /schemas/types.yaml#definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 2 maxItems: 3 items: diff --git a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml new file mode 100644 index 000000000000..07a7b10163a3 --- /dev/null +++ b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/i3c/mipi-i3c-hci.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MIPI I3C HCI Device Tree Bindings + +maintainers: + - Nicolas Pitre <npitre@baylibre.com> + +description: | + MIPI I3C Host Controller Interface + + The MIPI I3C HCI (Host Controller Interface) specification defines + a common software driver interface to support compliant MIPI I3C + host controller hardware implementations from multiple vendors. + + The hardware is self-advertising for differences in implementation + capabilities, including the spec version it is based on, so there + isn't much to describe here (yet). + + For details, please see: + https://www.mipi.org/specifications/i3c-hci + +properties: + compatible: + const: mipi-i3c-hci + reg: + maxItems: 1 + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + i3c@a0000000 { + compatible = "mipi-i3c-hci"; + reg = <0xa0000000 0x2000>; + interrupts = <89>; + }; diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index 6eef3480ea8f..c2efbb813ca2 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -16,8 +16,8 @@ description: properties: compatible: enum: - - bosch,bmc150 - - bosch,bmi055 + - bosch,bmc150_accel + - bosch,bmi055_accel - bosch,bma255 - bosch,bma250e - bosch,bma222 diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml index 6a991e9f78e2..2716d4e95329 100644 --- a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml +++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml @@ -17,8 +17,7 @@ properties: - lltc,ltc2496 vref-supply: - description: phandle to an external regulator providing the reference voltage - $ref: /schemas/types.yaml#/definitions/phandle + description: Power supply for the reference voltage reg: description: spi chipselect number according to the usual spi bindings diff --git a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml index 7037f82ec753..88384b69f917 100644 --- a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml +++ b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml @@ -22,8 +22,7 @@ properties: - ti,hdc2010 - ti,hdc2080 - vdd-supply: - maxItems: 1 + vdd-supply: true reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/light/upisemi,us5182.yaml b/Documentation/devicetree/bindings/iio/light/upisemi,us5182.yaml index 4a9b2827cf7b..de5882cb3360 100644 --- a/Documentation/devicetree/bindings/iio/light/upisemi,us5182.yaml +++ b/Documentation/devicetree/bindings/iio/light/upisemi,us5182.yaml @@ -45,7 +45,7 @@ properties: default: 0x16 upisemi,continuous: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: | This chip has two power modes: one-shot (chip takes one measurement and then shuts itself down) and continuous (chip takes continuous diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml index ccfb163f3d34..5de0bb2180e6 100644 --- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml @@ -72,7 +72,7 @@ properties: - finest semtech,startup-sensor: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1, 2, 3] default: 0 description: @@ -81,7 +81,7 @@ properties: compensation. semtech,proxraw-strength: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 2, 4, 8] default: 2 description: @@ -89,7 +89,7 @@ properties: represent 1-1/N. semtech,avg-pos-strength: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 16, 64, 128, 256, 512, 1024, 4294967295] default: 16 description: diff --git a/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml b/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml index 378a85c09d34..878464f128dc 100644 --- a/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml +++ b/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml @@ -31,8 +31,7 @@ properties: interrupts: maxItems: 1 - vdd-supply: - maxItems: 1 + vdd-supply: true linux,keycodes: minItems: 1 diff --git a/Documentation/devicetree/bindings/input/gpio-keys.yaml b/Documentation/devicetree/bindings/input/gpio-keys.yaml index 6966ab009fa3..060a309ff8e7 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys.yaml +++ b/Documentation/devicetree/bindings/input/gpio-keys.yaml @@ -34,13 +34,13 @@ patternProperties: linux,code: description: Key / Axis code to emit. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 linux,input-type: description: Specify event type this button/key generates. If not specified defaults to <1> == EV_KEY. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 default: 1 @@ -56,12 +56,12 @@ patternProperties: linux,input-value = <0xffffffff>; /* -1 */ - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 debounce-interval: description: Debouncing interval time in milliseconds. If not specified defaults to 5. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 default: 5 @@ -79,7 +79,7 @@ patternProperties: EV_ACT_ANY - both asserted and deasserted EV_ACT_ASSERTED - asserted EV_ACT_DEASSERTED - deasserted - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1, 2] linux,can-disable: @@ -118,7 +118,7 @@ then: poll-interval: description: Poll interval time in milliseconds - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 required: - poll-interval diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml index 4ce109476a0e..bfc3a8b5e118 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml @@ -55,8 +55,7 @@ properties: wakeup-source: true - vcc-supply: - maxItems: 1 + vcc-supply: true gain: description: Allows setting the sensitivity in the range from 0 to 31. diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml index 06889963dfb7..ba282f4c9fd0 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml @@ -35,7 +35,6 @@ properties: - arm,gic-400 - arm,pl390 - arm,tc11mp-gic - - nvidia,tegra210-agic - qcom,msm-8660-qgic - qcom,msm-qgic2 @@ -53,6 +52,14 @@ properties: - const: brcm,brahma-b15-gic - const: arm,cortex-a15-gic + - oneOf: + - const: nvidia,tegra210-agic + - items: + - enum: + - nvidia,tegra186-agic + - nvidia,tegra194-agic + - const: nvidia,tegra210-agic + interrupt-controller: true "#address-cells": diff --git a/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml index 039e08af98bb..91bb3c2307a7 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml @@ -42,7 +42,7 @@ properties: Specifies the list of CPU interrupt vectors to which the GIC may not route interrupts. This property is ignored if the CPU is started in EIC mode. - $ref: /schemas/types.yaml#definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 6 uniqueItems: true @@ -56,7 +56,7 @@ properties: It accepts two values: the 1st is the starting interrupt and the 2nd is the size of the reserved range. If not specified, the driver will allocate the last (2 * number of VPEs in the system). - $ref: /schemas/types.yaml#definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array items: - minimum: 0 maximum: 254 diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml index 1c4c009dedd0..c2ce215501a5 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml @@ -80,7 +80,7 @@ properties: mapping is provided. ti,irqs-reserved: - $ref: /schemas/types.yaml#definitions/uint8 + $ref: /schemas/types.yaml#/definitions/uint8 description: | Bitmask of host interrupts between 0 and 7 (corresponding to PRUSS INTC output interrupts 2 through 9) that are not connected to the Arm interrupt diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml index b5af12011499..3d89668573e8 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml @@ -76,7 +76,7 @@ properties: "limit" specifies the limit for translation ti,unmapped-event-sources: - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array description: Array of phandles to DMA controllers where the unmapped events originate. diff --git a/Documentation/devicetree/bindings/leds/backlight/common.yaml b/Documentation/devicetree/bindings/leds/backlight/common.yaml index bc817f77d2b1..702ba350d869 100644 --- a/Documentation/devicetree/bindings/leds/backlight/common.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/common.yaml @@ -22,7 +22,7 @@ properties: The default brightness that should be applied to the LED by the operating system on start-up. The brightness should not exceed the brightness the LED can provide. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 max-brightness: description: @@ -31,6 +31,6 @@ properties: on the brightness apart from what the driver says, as it could happen that a LED can be made so bright that it gets damaged or causes damage due to restrictions in a specific system, such as mounting conditions. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 additionalProperties: true diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index f1211e7045f1..b1f363747a62 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -27,21 +27,21 @@ properties: List of device current outputs the LED is connected to. The outputs are identified by the numbers that must be defined in the LED device binding documentation. - $ref: /schemas/types.yaml#definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array function: description: LED function. Use one of the LED_FUNCTION_* prefixed definitions from the header include/dt-bindings/leds/common.h. If there is no matching LED_FUNCTION available, add a new one. - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string color: description: Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions from the header include/dt-bindings/leds/common.h. If there is no matching LED_COLOR_ID available, add a new one. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 9 @@ -49,7 +49,7 @@ properties: description: Integer to be used when more than one instance of the same function is needed, differing only with an ordinal number. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 label: description: @@ -66,7 +66,7 @@ properties: produced where the LED momentarily turns off (or on). The "keep" setting will keep the LED at whatever its current state is, without producing a glitch. - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string enum: - on - off @@ -77,7 +77,7 @@ properties: description: This parameter, if present, is a string defining the trigger assigned to the LED. - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string enum: # LED will act as a back-light, controlled by the framebuffer system @@ -109,7 +109,7 @@ properties: brightness and duration (in ms). The exact format is described in: Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt - $ref: /schemas/types.yaml#definitions/uint32-matrix + $ref: /schemas/types.yaml#/definitions/uint32-matrix items: minItems: 2 maxItems: 2 @@ -143,7 +143,7 @@ properties: the device tree and be referenced by a phandle and a set of phandle arguments. A length of arguments should be specified by the #trigger-source-cells property in the source node. - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array # Required properties for flash LED child nodes: flash-max-microamp: diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml index 58e974793a79..f552cd143d5b 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml @@ -35,7 +35,7 @@ properties: description: I2C slave address clock-mode: - $ref: /schemas/types.yaml#definitions/uint8 + $ref: /schemas/types.yaml#/definitions/uint8 description: | Input clock mode enum: @@ -49,7 +49,7 @@ properties: GPIO attached to the chip's enable pin pwr-sel: - $ref: /schemas/types.yaml#definitions/uint8 + $ref: /schemas/types.yaml#/definitions/uint8 description: | LP8501 specific property. Power selection for output channels. enum: @@ -70,14 +70,14 @@ patternProperties: $ref: common.yaml# properties: led-cur: - $ref: /schemas/types.yaml#definitions/uint8 + $ref: /schemas/types.yaml#/definitions/uint8 description: | Current setting at each LED channel (mA x10, 0 if LED is not connected) minimum: 0 maximum: 255 max-cur: - $ref: /schemas/types.yaml#definitions/uint8 + $ref: /schemas/types.yaml#/definitions/uint8 description: Maximun current at each LED channel. reg: @@ -97,7 +97,7 @@ patternProperties: - 8 # LED output D9 chan-name: - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string description: name of channel required: diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml index d43791a2dde7..d07eb00b97c8 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml @@ -61,7 +61,6 @@ properties: - description: low-priority non-secure - description: high-priority non-secure - description: Secure - maxItems: 3 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml new file mode 100644 index 000000000000..6608545ea66f --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml @@ -0,0 +1,209 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/arm,mhuv2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM MHUv2 Mailbox Controller + +maintainers: + - Tushar Khandelwal <tushar.khandelwal@arm.com> + - Viresh Kumar <viresh.kumar@linaro.org> + +description: | + The Arm Message Handling Unit (MHU) Version 2 is a mailbox controller that has + between 1 and 124 channel windows (each 32-bit wide) to provide unidirectional + communication with remote processor(s), where the number of channel windows + are implementation dependent. + + Given the unidirectional nature of the controller, an MHUv2 mailbox may only + be written to or read from. If a pair of MHU controllers is implemented + between two processing elements to provide bidirectional communication, these + must be specified as two separate mailboxes. + + If the interrupts property is present in device tree node, then its treated as + a "receiver" mailbox, otherwise a "sender". + + An MHU controller must be specified along with the supported transport + protocols. The transport protocols determine the method of data transmission + as well as the number of provided mailbox channels. + + Following are the possible transport protocols. + + - Data-transfer: Each transfer is made of one or more words, using one or more + channel windows. + + - Doorbell: Each transfer is made up of single bit flag, using any one of the + bits in a channel window. A channel window can support up to 32 doorbells + and the entire window shall be used in doorbell protocol. Optionally, data + may be transmitted through a shared memory region, wherein the MHU is used + strictly as an interrupt generation mechanism but that is out of the scope + of these bindings. + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: + compatible: + contains: + enum: + - arm,mhuv2-tx + - arm,mhuv2-rx + required: + - compatible + +properties: + compatible: + oneOf: + - description: Sender mode + items: + - const: arm,mhuv2-tx + - const: arm,primecell + + - description: Receiver-mode + items: + - const: arm,mhuv2-rx + - const: arm,primecell + + reg: + maxItems: 1 + + interrupts: + description: | + The MHUv2 controller always implements an interrupt in the "receiver" + mode, while the interrupt in the "sender" mode was not available in the + version MHUv2.0, but the later versions do have it. + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + arm,mhuv2-protocols: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + description: | + The MHUv2 controller may contain up to 124 channel windows (each 32-bit + wide). The hardware and the DT bindings allows any combination of those to + be used for various transport protocols. + + This property allows a platform to describe how these channel windows are + used in various transport protocols. The entries in this property shall be + present as an array of tuples, where each tuple describes details about + one of the transport protocol being implemented over some channel + window(s). + + The first field of a tuple signifies the transfer protocol, 0 is reserved + for doorbell protocol, and 1 is reserved for data-transfer protocol. + Using any other value in the first field of a tuple makes it invalid. + + The second field of a tuple signifies the number of channel windows where + the protocol would be used and should be set to a non zero value. For + doorbell protocol this field signifies the number of 32-bit channel + windows that implement the doorbell protocol. For data-transfer protocol, + this field signifies the number of 32-bit channel windows that implement + the data-transfer protocol. + + The total number of channel windows specified here shouldn't be more than + the ones implemented by the platform, though one can specify lesser number + of windows here than what the platform implements. + + mhu: mailbox@2b1f0000 { + ... + + arm,mhuv2-protocols = <0 2>, <1 1>, <1 5>, <1 7>; + } + + The above example defines the protocols of an ARM MHUv2 mailbox + controller, where a total of 15 channel windows are used. The first two + windows are used in doorbell protocol (64 doorbells), followed by 1, 5 and + 7 windows (separately) used in data-transfer protocol. + + minItems: 1 + maxItems: 124 + items: + items: + - enum: [ 0, 1 ] + - minimum: 0 + maximum: 124 + + + '#mbox-cells': + description: | + It is always set to 2. The first argument in the consumers 'mboxes' + property represents the channel window group, which may be used in + doorbell, or data-transfer protocol, and the second argument (only + relevant in doorbell protocol, should be 0 otherwise) represents the + doorbell number within the 32 bit wide channel window. + + From the example given above for arm,mhuv2-protocols, here is how a client + node can reference them. + + mboxes = <&mhu 0 5>; // Channel Window Group 0, doorbell 5. + mboxes = <&mhu 1 7>; // Channel Window Group 1, doorbell 7. + mboxes = <&mhu 2 0>; // Channel Window Group 2, data transfer protocol with 1 window. + mboxes = <&mhu 3 0>; // Channel Window Group 3, data transfer protocol with 5 windows. + mboxes = <&mhu 4 0>; // Channel Window Group 4, data transfer protocol with 7 windows. + + const: 2 + +if: + # Interrupt is compulsory for receiver + properties: + compatible: + contains: + const: arm,mhuv2-rx +then: + required: + - interrupts + +required: + - compatible + - reg + - '#mbox-cells' + - arm,mhuv2-protocols + +additionalProperties: false + +examples: + # Multiple transport protocols implemented by the mailbox controllers + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + mhu_tx: mailbox@2b1f0000 { + #mbox-cells = <2>; + compatible = "arm,mhuv2-tx", "arm,primecell"; + reg = <0 0x2b1f0000 0 0x1000>; + clocks = <&clock 0>; + clock-names = "apb_pclk"; + interrupts = <0 45 4>; + arm,mhuv2-protocols = <1 5>, <1 2>, <1 5>, <1 7>, <0 2>; + }; + + mhu_rx: mailbox@2b1f1000 { + #mbox-cells = <2>; + compatible = "arm,mhuv2-rx", "arm,primecell"; + reg = <0 0x2b1f1000 0 0x1000>; + clocks = <&clock 0>; + clock-names = "apb_pclk"; + interrupts = <0 46 4>; + arm,mhuv2-protocols = <1 1>, <1 7>, <0 2>; + }; + + mhu_client: scb@2e000000 { + compatible = "fujitsu,mb86s70-scb-1.0"; + reg = <0 0x2e000000 0 0x4000>; + + mboxes = + //data-transfer protocol with 5 windows, mhu-tx + <&mhu_tx 2 0>, + //data-transfer protocol with 7 windows, mhu-tx + <&mhu_tx 3 0>, + //doorbell protocol channel 4, doorbell 27, mhu-tx + <&mhu_tx 4 27>, + //data-transfer protocol with 1 window, mhu-rx + <&mhu_rx 0 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/coda.yaml b/Documentation/devicetree/bindings/media/coda.yaml index 7bac0057faf7..36781ee4617f 100644 --- a/Documentation/devicetree/bindings/media/coda.yaml +++ b/Documentation/devicetree/bindings/media/coda.yaml @@ -44,6 +44,21 @@ properties: - const: per - const: ahb + interrupts: + minItems: 1 + items: + - description: BIT processor interrupt + - description: JPEG unit interrupt + + interrupt-names: + minItems: 1 + items: + - const: bit + - const: jpeg + + power-domains: + maxItems: 1 + resets: maxItems: 1 @@ -59,6 +74,8 @@ required: - clocks - clock-names +additionalProperties: false + allOf: - if: properties: @@ -68,34 +85,17 @@ allOf: then: properties: interrupts: - items: - - description: BIT processor interrupt - - description: JPEG unit interrupt + minItems: 2 interrupt-names: - items: - - const: bit - - const: jpeg + minItems: 2 else: properties: interrupts: - items: - - description: BIT processor interrupt - - - if: - properties: - compatible: - contains: - enum: - - fsl,imx6dl-vpu - - fsl,imx6q-vpu - then: - properties: - power-domains: - $ref: /schemas/types.yaml#/definitions/phandle - description: phandle pointing to the PU power domain maxItems: 1 + power-domains: false + examples: - | vpu: video-codec@63ff4000 { diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml index 9ea827092fdd..68ee8c7d9e79 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -40,7 +40,6 @@ properties: poc-supply: description: Regulator providing Power over Coax to the cameras - maxItems: 1 enable-gpios: description: GPIO connected to the \#PWDN pin with inverted polarity diff --git a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml index d94bd67ccea1..bb3528315f20 100644 --- a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml +++ b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml @@ -1,6 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) # Copyright (C) 2014--2020 Intel Corporation - +%YAML 1.2 +--- $id: http://devicetree.org/schemas/media/i2c/mipi-ccs.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# @@ -26,11 +27,11 @@ properties: compatible: oneOf: - items: - - const: mipi-ccs-1.1 - - const: mipi-ccs + - const: mipi-ccs-1.1 + - const: mipi-ccs - items: - - const: mipi-ccs-1.0 - - const: mipi-ccs + - const: mipi-ccs-1.0 + - const: mipi-ccs - const: nokia,smia reg: @@ -38,15 +39,12 @@ properties: vana-supply: description: Analogue voltage supply (VANA), sensor dependent. - maxItems: 1 vcore-supply: description: Core voltage supply (VCore), sensor dependent. - maxItems: 1 vio-supply: description: I/O voltage supply (VIO), sensor dependent. - maxItems: 1 clocks: description: External clock to the sensor. diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml index 1a3590dd0e98..eb12526a462f 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml @@ -37,15 +37,12 @@ properties: vdddo-supply: description: Chip digital IO regulator (1.8V). - maxItems: 1 vdda-supply: description: Chip analog regulator (2.7V). - maxItems: 1 vddd-supply: description: Chip digital core regulator (1.12V). - maxItems: 1 flash-leds: description: See ../video-interfaces.txt diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml index f697e1a20beb..a66acb20d59b 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml @@ -33,15 +33,12 @@ properties: vana-supply: description: Sensor 2.8 V analog supply. - maxItems: 1 vdig-supply: description: Sensor 1.8 V digital core supply. - maxItems: 1 vddl-supply: description: Sensor digital IO 1.2 V supply. - maxItems: 1 port: type: object diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt deleted file mode 100644 index dbafffe3f41e..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt +++ /dev/null @@ -1,50 +0,0 @@ -SMI (Smart Multimedia Interface) Common - -The hardware block diagram please check bindings/iommu/mediatek,iommu.txt - -Mediatek SMI have two generations of HW architecture, here is the list -which generation the SoCs use: -generation 1: mt2701 and mt7623. -generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183. - -There's slight differences between the two SMI, for generation 2, the -register which control the iommu port is at each larb's register base. But -for generation 1, the register is at smi ao base(smi always on register -base). Besides that, the smi async clock should be prepared and enabled for -SMI generation 1 to transform the smi clock into emi clock domain, but that is -not needed for SMI generation 2. - -Required properties: -- compatible : must be one of : - "mediatek,mt2701-smi-common" - "mediatek,mt2712-smi-common" - "mediatek,mt6779-smi-common" - "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common" - "mediatek,mt8167-smi-common" - "mediatek,mt8173-smi-common" - "mediatek,mt8183-smi-common" -- reg : the register and size of the SMI block. -- power-domains : a phandle to the power domain of this local arbiter. -- clocks : Must contain an entry for each entry in clock-names. -- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries - for generation 2 smi HW as follows: - - "apb" : Advanced Peripheral Bus clock, It's the clock for setting - the register. - - "smi" : It's the clock for transfer data and command. - They may be the same if both source clocks are the same. - - "async" : asynchronous clock, it help transform the smi clock into the emi - clock domain, this clock is only needed by generation 1 smi HW. - and these 2 option clocks for generation 2 smi HW: - - "gals0": the path0 clock of GALS(Global Async Local Sync). - - "gals1": the path1 clock of GALS(Global Async Local Sync). - Here is the list which has this GALS: mt6779 and mt8183. - -Example: - smi_common: smi@14022000 { - compatible = "mediatek,mt8173-smi-common"; - reg = <0 0x14022000 0 0x1000>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_SMI_COMMON>, - <&mmsys CLK_MM_SMI_COMMON>; - clock-names = "apb", "smi"; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml new file mode 100644 index 000000000000..a08a32340987 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -0,0 +1,142 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/mediatek,smi-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SMI (Smart Multimedia Interface) Common + +maintainers: + - Yong Wu <yong.wu@mediatek.com> + +description: | + The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml + + MediaTek SMI have two generations of HW architecture, here is the list + which generation the SoCs use: + generation 1: mt2701 and mt7623. + generation 2: mt2712, mt6779, mt8167, mt8173, mt8183 and mt8192. + + There's slight differences between the two SMI, for generation 2, the + register which control the iommu port is at each larb's register base. But + for generation 1, the register is at smi ao base(smi always on register + base). Besides that, the smi async clock should be prepared and enabled for + SMI generation 1 to transform the smi clock into emi clock domain, but that is + not needed for SMI generation 2. + +properties: + compatible: + oneOf: + - enum: + - mediatek,mt2701-smi-common + - mediatek,mt2712-smi-common + - mediatek,mt6779-smi-common + - mediatek,mt8167-smi-common + - mediatek,mt8173-smi-common + - mediatek,mt8183-smi-common + - mediatek,mt8192-smi-common + + - description: for mt7623 + items: + - const: mediatek,mt7623-smi-common + - const: mediatek,mt2701-smi-common + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + clocks: + description: | + apb and smi are mandatory. the async is only for generation 1 smi HW. + gals(global async local sync) also is optional, see below. + minItems: 2 + maxItems: 4 + items: + - description: apb is Advanced Peripheral Bus clock, It's the clock for + setting the register. + - description: smi is the clock for transfer data and command. + - description: async is asynchronous clock, it help transform the smi + clock into the emi clock domain. + - description: gals0 is the path0 clock of gals. + - description: gals1 is the path1 clock of gals. + + clock-names: + minItems: 2 + maxItems: 4 + +required: + - compatible + - reg + - power-domains + - clocks + - clock-names + +allOf: + - if: # only for gen1 HW + properties: + compatible: + contains: + enum: + - mediatek,mt2701-smi-common + then: + properties: + clock: + items: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: apb + - const: smi + - const: async + + - if: # for gen2 HW that have gals + properties: + compatible: + enum: + - mediatek,mt6779-smi-common + - mediatek,mt8183-smi-common + - mediatek,mt8192-smi-common + + then: + properties: + clock: + items: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: apb + - const: smi + - const: gals0 + - const: gals1 + + else: # for gen2 HW that don't have gals + properties: + clock: + items: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: apb + - const: smi + +additionalProperties: false + +examples: + - |+ + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + + smi_common: smi@14022000 { + compatible = "mediatek,mt8173-smi-common"; + reg = <0x14022000 0x1000>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_SMI_COMMON>, + <&mmsys CLK_MM_SMI_COMMON>; + clock-names = "apb", "smi"; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt deleted file mode 100644 index 0c5de12b5496..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt +++ /dev/null @@ -1,50 +0,0 @@ -SMI (Smart Multimedia Interface) Local Arbiter - -The hardware block diagram please check bindings/iommu/mediatek,iommu.txt - -Required properties: -- compatible : must be one of : - "mediatek,mt2701-smi-larb" - "mediatek,mt2712-smi-larb" - "mediatek,mt6779-smi-larb" - "mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb" - "mediatek,mt8167-smi-larb" - "mediatek,mt8173-smi-larb" - "mediatek,mt8183-smi-larb" -- reg : the register and size of this local arbiter. -- mediatek,smi : a phandle to the smi_common node. -- power-domains : a phandle to the power domain of this local arbiter. -- clocks : Must contain an entry for each entry in clock-names. -- clock-names: must contain 2 entries, as follows: - - "apb" : Advanced Peripheral Bus clock, It's the clock for setting - the register. - - "smi" : It's the clock for transfer data and command. - and this optional clock name: - - "gals": the clock for GALS(Global Async Local Sync). - Here is the list which has this GALS: mt8183. - -Required property for mt2701, mt2712, mt6779, mt7623 and mt8167: -- mediatek,larb-id :the hardware id of this larb. - -Example: - larb1: larb@16010000 { - compatible = "mediatek,mt8173-smi-larb"; - reg = <0 0x16010000 0 0x1000>; - mediatek,smi = <&smi_common>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>; - clocks = <&vdecsys CLK_VDEC_CKEN>, - <&vdecsys CLK_VDEC_LARB_CKEN>; - clock-names = "apb", "smi"; - }; - -Example for mt2701: - larb0: larb@14010000 { - compatible = "mediatek,mt2701-smi-larb"; - reg = <0 0x14010000 0 0x1000>; - mediatek,smi = <&smi_common>; - mediatek,larb-id = <0>; - clocks = <&mmsys CLK_MM_SMI_LARB0>, - <&mmsys CLK_MM_SMI_LARB0>; - clock-names = "apb", "smi"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml new file mode 100644 index 000000000000..7ed7839ff0a7 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/mediatek,smi-larb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SMI (Smart Multimedia Interface) Local Arbiter + +maintainers: + - Yong Wu <yong.wu@mediatek.com> + +description: | + The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml + +properties: + compatible: + oneOf: + - enum: + - mediatek,mt2701-smi-larb + - mediatek,mt2712-smi-larb + - mediatek,mt6779-smi-larb + - mediatek,mt8167-smi-larb + - mediatek,mt8173-smi-larb + - mediatek,mt8183-smi-larb + - mediatek,mt8192-smi-larb + + - description: for mt7623 + items: + - const: mediatek,mt7623-smi-larb + - const: mediatek,mt2701-smi-larb + + reg: + maxItems: 1 + + clocks: + description: | + apb and smi are mandatory. gals(global async local sync) is optional. + minItems: 2 + maxItems: 3 + items: + - description: apb is Advanced Peripheral Bus clock, It's the clock for + setting the register. + - description: smi is the clock for transfer data and command. + - description: the clock for gals. + + clock-names: + minItems: 2 + maxItems: 3 + + power-domains: + maxItems: 1 + + mediatek,smi: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: a phandle to the smi_common node. + + mediatek,larb-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: the hardware id of this larb. It's only required when this + hardward id is not consecutive from its M4U point of view. + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + +allOf: + - if: # HW has gals + properties: + compatible: + enum: + - mediatek,mt8183-smi-larb + + then: + properties: + clock: + items: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: apb + - const: smi + - const: gals + + else: + properties: + clock: + items: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: apb + - const: smi + + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt2701-smi-larb + - mediatek,mt2712-smi-larb + - mediatek,mt6779-smi-larb + - mediatek,mt8167-smi-larb + - mediatek,mt8192-smi-larb + + then: + required: + - mediatek,larb-id + +additionalProperties: false + +examples: + - |+ + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + + larb1: larb@16010000 { + compatible = "mediatek,mt8173-smi-larb"; + reg = <0x16010000 0x1000>; + mediatek,smi = <&smi_common>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>; + clocks = <&vdecsys CLK_VDEC_CKEN>, + <&vdecsys CLK_VDEC_LARB_CKEN>; + clock-names = "apb", "smi"; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml index 278549f9e051..09bde65e1955 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml @@ -29,11 +29,23 @@ properties: items: - const: emc + "#interconnect-cells": + const: 0 + nvidia,memory-controller: $ref: /schemas/types.yaml#/definitions/phandle description: phandle of the memory controller node + core-supply: + description: + Phandle of voltage regulator of the SoC "core" power domain. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, which + is a bitfield indicating SoC speedo ID mask. + patternProperties: "^emc-timings-[0-9]+$": type: object @@ -327,6 +339,8 @@ required: - clocks - clock-names - nvidia,memory-controller + - "#interconnect-cells" + - operating-points-v2 additionalProperties: false @@ -345,6 +359,7 @@ examples: #iommu-cells = <1>; #reset-cells = <1>; + #interconnect-cells = <1>; }; external-memory-controller@7001b000 { @@ -354,6 +369,10 @@ examples: clock-names = "emc"; nvidia,memory-controller = <&mc>; + operating-points-v2 = <&dvfs_opp_table>; + core-supply = <&vdd_core>; + + #interconnect-cells = <0>; emc-timings-0 { nvidia,ram-code = <3>; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml index 84d0339505b1..7b18b4d11e0a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml @@ -40,6 +40,9 @@ properties: "#iommu-cells": const: 1 + "#interconnect-cells": + const: 1 + patternProperties: "^emc-timings-[0-9]+$": type: object @@ -104,6 +107,7 @@ required: - clock-names - "#reset-cells" - "#iommu-cells" + - "#interconnect-cells" additionalProperties: false @@ -119,6 +123,7 @@ examples: #iommu-cells = <1>; #reset-cells = <1>; + #interconnect-cells = <1>; emc-timings-3 { nvidia,ram-code = <3>; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt index add95367640b..cc443fcf4bec 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt @@ -12,18 +12,44 @@ Properties: irrespective of ram-code configuration. - interrupts : Should contain EMC General interrupt. - clocks : Should contain EMC clock. +- nvidia,memory-controller : Phandle of the Memory Controller node. +- #interconnect-cells : Should be 0. +- operating-points-v2: See ../bindings/opp/opp.txt for details. + +For each opp entry in 'operating-points-v2' table: +- opp-supported-hw: One bitfield indicating SoC process ID mask + + A bitwise AND is performed against this value and if any bit + matches, the OPP gets enabled. + +Optional properties: +- core-supply: Phandle of voltage regulator of the SoC "core" power domain. Child device nodes describe the memory settings for different configurations and clock rates. Example: + opp_table: opp-table { + compatible = "operating-points-v2"; + + opp@36000000 { + opp-microvolt = <950000 950000 1300000>; + opp-hz = /bits/ 64 <36000000>; + }; + ... + }; + memory-controller@7000f400 { #address-cells = < 1 >; #size-cells = < 0 >; + #interconnect-cells = <0>; compatible = "nvidia,tegra20-emc"; - reg = <0x7000f4000 0x200>; + reg = <0x7000f400 0x400>; interrupts = <0 78 0x04>; clocks = <&tegra_car TEGRA20_CLK_EMC>; + nvidia,memory-controller = <&mc>; + core-supply = <&core_vdd_reg>; + operating-points-v2 = <&opp_table>; } diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt index e55328237df4..739b7c6f2e26 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt @@ -16,6 +16,8 @@ Required properties: IOMMU specifier needed to encode an address. GART supports only a single address space that is shared by all devices, therefore no additional information needed for the address encoding. +- #interconnect-cells : Should be 1. This cell represents memory client. + The assignments may be found in header file <dt-bindings/memory/tegra20-mc.h>. Example: mc: memory-controller@7000f000 { @@ -27,6 +29,7 @@ Example: interrupts = <GIC_SPI 77 0x04>; #reset-cells = <1>; #iommu-cells = <0>; + #interconnect-cells = <1>; }; video-codec@6001a000 { diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml index 112bae2fcbbd..0a2e2c0d0fdd 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml @@ -31,11 +31,23 @@ properties: interrupts: maxItems: 1 + "#interconnect-cells": + const: 0 + nvidia,memory-controller: $ref: /schemas/types.yaml#/definitions/phandle description: Phandle of the Memory Controller node. + core-supply: + description: + Phandle of voltage regulator of the SoC "core" power domain. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, which + is a bitfield indicating SoC speedo ID mask. + patternProperties: "^emc-timings-[0-9]+$": type: object @@ -214,6 +226,8 @@ required: - interrupts - clocks - nvidia,memory-controller + - "#interconnect-cells" + - operating-points-v2 additionalProperties: false @@ -226,6 +240,10 @@ examples: clocks = <&tegra_car 57>; nvidia,memory-controller = <&mc>; + operating-points-v2 = <&dvfs_opp_table>; + core-supply = <&vdd_core>; + + #interconnect-cells = <0>; emc-timings-1 { nvidia,ram-code = <1>; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml index 84fd57bcf0dc..5436e6d420bc 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml @@ -57,6 +57,9 @@ properties: "#iommu-cells": const: 1 + "#interconnect-cells": + const: 1 + patternProperties: "^emc-timings-[0-9]+$": type: object @@ -120,6 +123,7 @@ required: - clock-names - "#reset-cells" - "#iommu-cells" + - "#interconnect-cells" additionalProperties: false @@ -135,6 +139,7 @@ examples: #iommu-cells = <1>; #reset-cells = <1>; + #interconnect-cells = <1>; emc-timings-1 { nvidia,ram-code = <1>; diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt index a92acf1dd491..d0a38ba8b9ce 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt @@ -46,6 +46,7 @@ Required properties - compatible: One of: "aspeed,ast2400-lpc", "simple-mfd" "aspeed,ast2500-lpc", "simple-mfd" + "aspeed,ast2600-lpc", "simple-mfd" - reg: contains the physical address and length values of the Aspeed LPC memory region. @@ -64,6 +65,7 @@ BMC Node - compatible: One of: "aspeed,ast2400-lpc-bmc" "aspeed,ast2500-lpc-bmc" + "aspeed,ast2600-lpc-bmc" - reg: contains the physical address and length values of the H8S/2168-compatible LPC controller memory region @@ -74,6 +76,7 @@ Host Node - compatible: One of: "aspeed,ast2400-lpc-host", "simple-mfd", "syscon" "aspeed,ast2500-lpc-host", "simple-mfd", "syscon" + "aspeed,ast2600-lpc-host", "simple-mfd", "syscon" - reg: contains the address and length values of the host-related register space for the Aspeed LPC controller @@ -128,6 +131,7 @@ Required properties: - compatible: One of: "aspeed,ast2400-lpc-ctrl"; "aspeed,ast2500-lpc-ctrl"; + "aspeed,ast2600-lpc-ctrl"; - reg: contains offset/length values of the host interface controller memory regions @@ -168,6 +172,7 @@ Required properties: - compatible: One of: "aspeed,ast2400-lhc"; "aspeed,ast2500-lhc"; + "aspeed,ast2600-lhc"; - reg: contains offset/length values of the LHC memory regions. In the AST2400 and AST2500 there are two regions. @@ -187,7 +192,8 @@ state of the LPC bus. Some systems may chose to modify this configuration. Required properties: - - compatible: "aspeed,ast2500-lpc-reset" or + - compatible: "aspeed,ast2600-lpc-reset" or + "aspeed,ast2500-lpc-reset" "aspeed,ast2400-lpc-reset" - reg: offset and length of the IP in the LHC memory region - #reset-controller indicates the number of reset cells expected diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt index 4d92c0bb6687..857ee33f7329 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt +++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt @@ -20,3 +20,29 @@ syscon: syscon@1e6e2000 { #clock-cells = <1>; #reset-cells = <1>; }; + +Silicon ID +----------------- + +Families have unique hardware silicon identifiers within the SoC. + +Required properties: + + - compatible: "aspeed,silicon-id" or: + "aspeed,ast2400-silicon-id" or + "aspeed,ast2500-silicon-id" or + "aspeed,ast2600-silicon-id" + + - reg: offset and length of the silicon id information + optionally, a second offset and length describes the unique chip id + + The reg should be the unique silicon id register, and + not backwards compatible one in eg. the 2600. + +Example: + + +silicon-id@7c { + compatible = "aspeed,ast2500-silicon-id", "aspeed,silicon-id"; + reg = <0x7c 0x4 0x150 0x8>; +}; diff --git a/Documentation/devicetree/bindings/mfd/st,stmfx.yaml b/Documentation/devicetree/bindings/mfd/st,stmfx.yaml index 888ab4b5df45..19e9afb385ac 100644 --- a/Documentation/devicetree/bindings/mfd/st,stmfx.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stmfx.yaml @@ -26,8 +26,7 @@ properties: drive-open-drain: true - vdd-supply: - maxItems: 1 + vdd-supply: true pinctrl: type: object diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml index c7c9ad4e3f9f..7f2578d48e3f 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml @@ -38,7 +38,7 @@ properties: const: stmmaceth syscon: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Phandle to the device containing the EMAC or GMAC clock register @@ -114,7 +114,7 @@ allOf: then: properties: allwinner,leds-active-low: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: EPHY LEDs are active low. @@ -126,7 +126,7 @@ allOf: const: allwinner,sun8i-h3-mdio-mux mdio-parent-bus: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Phandle to EMAC MDIO. diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 6b057b117aa0..1f133f4a2924 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -60,7 +60,7 @@ allOf: - const: timing-adjustment amlogic,tx-delay-ns: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: The internal RGMII TX clock delay (provided by this driver) in nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns. diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt deleted file mode 100644 index f1487a751b1a..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/b53.txt +++ /dev/null @@ -1,149 +0,0 @@ -Broadcom BCM53xx Ethernet switches -================================== - -Required properties: - -- compatible: For external switch chips, compatible string must be exactly one - of: "brcm,bcm5325" - "brcm,bcm53115" - "brcm,bcm53125" - "brcm,bcm53128" - "brcm,bcm5365" - "brcm,bcm5395" - "brcm,bcm5389" - "brcm,bcm5397" - "brcm,bcm5398" - - For the BCM11360 SoC, must be: - "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab" string - - For the BCM5310x SoCs with an integrated switch, must be one of: - "brcm,bcm53010-srab" - "brcm,bcm53011-srab" - "brcm,bcm53012-srab" - "brcm,bcm53018-srab" - "brcm,bcm53019-srab" and the mandatory "brcm,bcm5301x-srab" string - - For the BCM5831X/BCM1140x SoCs with an integrated switch, must be one of: - "brcm,bcm11404-srab" - "brcm,bcm11407-srab" - "brcm,bcm11409-srab" - "brcm,bcm58310-srab" - "brcm,bcm58311-srab" - "brcm,bcm58313-srab" and the mandatory "brcm,omega-srab" string - - For the BCM585xx/586XX/88312 SoCs with an integrated switch, must be one of: - "brcm,bcm58522-srab" - "brcm,bcm58523-srab" - "brcm,bcm58525-srab" - "brcm,bcm58622-srab" - "brcm,bcm58623-srab" - "brcm,bcm58625-srab" - "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string - - For the BCM63xx/33xx SoCs with an integrated switch, must be one of: - "brcm,bcm3384-switch" - "brcm,bcm6328-switch" - "brcm,bcm6368-switch" and the mandatory "brcm,bcm63xx-switch" - -Required properties for BCM585xx/586xx/88312 SoCs: - - - reg: a total of 3 register base addresses, the first one must be the - Switch Register Access block base, the second is the port 5/4 mux - configuration register and the third one is the SGMII configuration - and status register base address. - - - interrupts: a total of 13 interrupts must be specified, in the following - order: port 0-5, 7-8 link status change, then the integrated PHY interrupt, - then the timestamping interrupt and the sleep timer interrupts for ports - 5,7,8. - -Optional properties for BCM585xx/586xx/88312 SoCs: - - - reg-names: a total of 3 names matching the 3 base register address, must - be in the following order: - "srab" - "mux_config" - "sgmii_config" - - - interrupt-names: a total of 13 names matching the 13 interrupts specified - must be in the following order: - "link_state_p0" - "link_state_p1" - "link_state_p2" - "link_state_p3" - "link_state_p4" - "link_state_p5" - "link_state_p7" - "link_state_p8" - "phy" - "ts" - "imp_sleep_timer_p5" - "imp_sleep_timer_p7" - "imp_sleep_timer_p8" - -See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional -required and optional properties. - -Examples: - -Ethernet switch connected via MDIO to the host, CPU port wired to eth0: - - eth0: ethernet@10001000 { - compatible = "brcm,unimac"; - reg = <0x10001000 0x1000>; - - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - - mdio0: mdio@10000000 { - compatible = "brcm,unimac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - switch0: ethernet-switch@1e { - compatible = "brcm,bcm53125"; - reg = <30>; - #address-cells = <1>; - #size-cells = <0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port0@0 { - reg = <0>; - label = "lan1"; - }; - - port1@1 { - reg = <1>; - label = "lan2"; - }; - - port5@5 { - reg = <5>; - label = "cable-modem"; - fixed-link { - speed = <1000>; - full-duplex; - }; - phy-mode = "rgmii-txid"; - }; - - port8@8 { - reg = <8>; - label = "cpu"; - fixed-link { - speed = <1000>; - full-duplex; - }; - phy-mode = "rgmii-txid"; - ethernet = <ð0>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml new file mode 100644 index 000000000000..c3c938893ad9 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml @@ -0,0 +1,249 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/brcm,b53.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM53xx Ethernet switches + +allOf: + - $ref: dsa.yaml# + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +description: + Broadcom BCM53xx Ethernet switches + +properties: + compatible: + oneOf: + - const: brcm,bcm5325 + - const: brcm,bcm53115 + - const: brcm,bcm53125 + - const: brcm,bcm53128 + - const: brcm,bcm5365 + - const: brcm,bcm5395 + - const: brcm,bcm5389 + - const: brcm,bcm5397 + - const: brcm,bcm5398 + - items: + - const: brcm,bcm11360-srab + - const: brcm,cygnus-srab + - items: + - enum: + - brcm,bcm53010-srab + - brcm,bcm53011-srab + - brcm,bcm53012-srab + - brcm,bcm53018-srab + - brcm,bcm53019-srab + - const: brcm,bcm5301x-srab + - items: + - enum: + - brcm,bcm11404-srab + - brcm,bcm11407-srab + - brcm,bcm11409-srab + - brcm,bcm58310-srab + - brcm,bcm58311-srab + - brcm,bcm58313-srab + - const: brcm,omega-srab + - items: + - enum: + - brcm,bcm58522-srab + - brcm,bcm58523-srab + - brcm,bcm58525-srab + - brcm,bcm58622-srab + - brcm,bcm58623-srab + - brcm,bcm58625-srab + - brcm,bcm88312-srab + - const: brcm,nsp-srab + - items: + - enum: + - brcm,bcm3384-switch + - brcm,bcm6328-switch + - brcm,bcm6368-switch + - const: brcm,bcm63xx-switch + +required: + - compatible + - reg + +# BCM585xx/586xx/88312 SoCs +if: + properties: + compatible: + contains: + enum: + - brcm,bcm58522-srab + - brcm,bcm58523-srab + - brcm,bcm58525-srab + - brcm,bcm58622-srab + - brcm,bcm58623-srab + - brcm,bcm58625-srab + - brcm,bcm88312-srab +then: + properties: + reg: + minItems: 3 + maxItems: 3 + reg-names: + items: + - const: srab + - const: mux_config + - const: sgmii_config + interrupts: + minItems: 13 + maxItems: 13 + interrupt-names: + items: + - const: link_state_p0 + - const: link_state_p1 + - const: link_state_p2 + - const: link_state_p3 + - const: link_state_p4 + - const: link_state_p5 + - const: link_state_p7 + - const: link_state_p8 + - const: phy + - const: ts + - const: imp_sleep_timer_p5 + - const: imp_sleep_timer_p7 + - const: imp_sleep_timer_p8 + required: + - interrupts +else: + properties: + reg: + maxItems: 1 + +unevaluatedProperties: false + +examples: + - | + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-switch@1e { + compatible = "brcm,bcm53125"; + reg = <30>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan1"; + }; + + port@1 { + reg = <1>; + label = "lan2"; + }; + + port@5 { + reg = <5>; + label = "cable-modem"; + phy-mode = "rgmii-txid"; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + port@8 { + reg = <8>; + label = "cpu"; + phy-mode = "rgmii-txid"; + ethernet = <ð0>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + }; + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + axi { + #address-cells = <1>; + #size-cells = <1>; + + switch@36000 { + compatible = "brcm,bcm58623-srab", "brcm,nsp-srab"; + reg = <0x36000 0x1000>, + <0x3f308 0x8>, + <0x3f410 0xc>; + reg-names = "srab", "mux_config", "sgmii_config"; + interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "link_state_p0", + "link_state_p1", + "link_state_p2", + "link_state_p3", + "link_state_p4", + "link_state_p5", + "link_state_p7", + "link_state_p8", + "phy", + "ts", + "imp_sleep_timer_p5", + "imp_sleep_timer_p7", + "imp_sleep_timer_p8"; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + label = "port0"; + reg = <0>; + }; + + port@1 { + label = "port1"; + reg = <1>; + }; + + port@2 { + label = "port2"; + reg = <2>; + }; + + port@3 { + label = "port3"; + reg = <3>; + }; + + port@4 { + label = "port4"; + reg = <4>; + }; + + port@8 { + ethernet = <&amac2>; + label = "cpu"; + reg = <8>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml index a765ceba28c6..8a3494db4d8d 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml @@ -20,7 +20,7 @@ select: false properties: $nodename: - pattern: "^switch(@.*)?$" + pattern: "^(ethernet-)?switch(@.*)?$" dsa,member: minItems: 2 @@ -54,7 +54,7 @@ patternProperties: description: Describes the label associated with this port, which will become the netdev name - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string link: description: @@ -62,13 +62,13 @@ patternProperties: port is used as the outgoing port towards the phandle ports. The full routing information must be given, not just the one hop routes to neighbouring switches - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array ethernet: description: Should be a phandle to a valid Ethernet device node. This host device is what the switch port is connected to - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle phy-handle: true @@ -78,6 +78,10 @@ patternProperties: mac-address: true + sfp: true + + managed: true + required: - reg diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index fdf709817218..0965f6515f9e 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -16,7 +16,7 @@ properties: local-mac-address: description: Specifies the MAC address that was assigned to the network device. - $ref: /schemas/types.yaml#definitions/uint8-array + $ref: /schemas/types.yaml#/definitions/uint8-array items: - minItems: 6 maxItems: 6 @@ -27,20 +27,20 @@ properties: program; should be used in cases where the MAC address assigned to the device by the boot program is different from the local-mac-address property. - $ref: /schemas/types.yaml#definitions/uint8-array + $ref: /schemas/types.yaml#/definitions/uint8-array items: - minItems: 6 maxItems: 6 max-frame-size: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: Maximum transfer unit (IEEE defined MTU), rather than the maximum frame size (there\'s contradiction in the Devicetree Specification). max-speed: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: Specifies maximum speed in Mbit/s supported by the device. @@ -95,12 +95,13 @@ properties: # 10GBASE-KR, XFI, SFI - 10gbase-kr - usxgmii + - 10gbase-r phy-mode: $ref: "#/properties/phy-connection-type" phy-handle: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Specifies a reference to a node representing a PHY device. @@ -113,7 +114,7 @@ properties: deprecated: true rx-fifo-depth: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: The size of the controller\'s receive fifo in bytes. This is used for components that can have configurable receive fifo sizes, @@ -128,12 +129,12 @@ properties: If this property is present then the MAC applies the RX delay. sfp: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Specifies a reference to a node representing a SFP cage. tx-fifo-depth: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: The size of the controller\'s transmit fifo in bytes. This is used for components that can have configurable fifo sizes. @@ -149,7 +150,7 @@ properties: description: Specifies the PHY management type. If auto is set and fixed-link is not specified, it uses MDIO for management. - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#/definitions/string default: auto enum: - auto @@ -197,17 +198,17 @@ properties: speed: description: Link speed. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [10, 100, 1000] full-duplex: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Indicates that full-duplex is used. When absent, half duplex is assumed. asym-pause: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Indicates that asym_pause should be enabled. diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 6dd72faebd89..2766fe45bb98 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -78,57 +78,57 @@ properties: Maximum PHY supported speed in Mbits / seconds. broken-turn-around: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: If set, indicates the PHY device does not correctly release the turn around line low at end of the control phase of the MDIO transaction. enet-phy-lane-swap: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: If set, indicates the PHY will swap the TX/RX lanes to compensate for the board being designed with the lanes swapped. eee-broken-100tx: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Mark the corresponding energy efficient ethernet mode as broken and request the ethernet to stop advertising it. eee-broken-1000t: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Mark the corresponding energy efficient ethernet mode as broken and request the ethernet to stop advertising it. eee-broken-10gt: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Mark the corresponding energy efficient ethernet mode as broken and request the ethernet to stop advertising it. eee-broken-1000kx: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Mark the corresponding energy efficient ethernet mode as broken and request the ethernet to stop advertising it. eee-broken-10gkx4: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Mark the corresponding energy efficient ethernet mode as broken and request the ethernet to stop advertising it. eee-broken-10gkr: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Mark the corresponding energy efficient ethernet mode as broken and request the ethernet to stop advertising it. phy-is-integrated: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: If set, indicates that the PHY is integrated into the same physical package as the Ethernet MAC. If needed, muxers @@ -158,7 +158,7 @@ properties: this property is missing the delay will be skipped. sfp: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Specifies a reference to a node representing a SFP cage. diff --git a/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml new file mode 100644 index 000000000000..7f620a71a972 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,qoriq-mc-dpmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DPAA2 MAC bindings + +maintainers: + - Ioana Ciornei <ioana.ciornei@nxp.com> + +description: + This binding represents the DPAA2 MAC objects found on the fsl-mc bus and + located under the 'dpmacs' node for the fsl-mc bus DTS node. + +allOf: + - $ref: "ethernet-controller.yaml#" + +properties: + compatible: + const: fsl,qoriq-mc-dpmac + + reg: + maxItems: 1 + description: The DPMAC number + + phy-handle: true + + phy-connection-type: true + + phy-mode: true + + pcs-handle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A reference to a node representing a PCS PHY device found on + the internal MDIO bus. + + managed: true + +required: + - reg + +additionalProperties: false + +examples: + - | + dpmacs { + #address-cells = <1>; + #size-cells = <0>; + + ethernet@4 { + compatible = "fsl,qoriq-mc-dpmac"; + reg = <0x4>; + phy-handle = <&mdio1_phy6>; + phy-connection-type = "qsgmii"; + managed = "in-band-status"; + pcs-handle = <&pcs3_1>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/mdio.yaml b/Documentation/devicetree/bindings/net/mdio.yaml index e811e0fd851c..08e15fb1584f 100644 --- a/Documentation/devicetree/bindings/net/mdio.yaml +++ b/Documentation/devicetree/bindings/net/mdio.yaml @@ -70,7 +70,7 @@ patternProperties: The ID number for the device. broken-turn-around: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: If set, indicates the MDIO device does not correctly release the turn around line low at end of the control phase of the diff --git a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml index 0bbd598704e9..e6a5ff208253 100644 --- a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml +++ b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml @@ -42,7 +42,7 @@ properties: - const: trans mediatek,pericfg: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Phandle to the device containing the PERICFG register range. This is used to control the MII mode. diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 4d8464b2676d..8a2d12644675 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -114,14 +114,13 @@ properties: validating firwmare used by the GSI. modem-remoteproc: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: This defines the phandle to the remoteproc node representing the modem subsystem. This is requied so the IPA driver can receive and act on notifications of modem up/down events. memory-region: - $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 description: If present, a phandle for a reserved memory area that holds diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index 244befb6402a..de9dd574a2f9 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -163,6 +163,7 @@ allOf: enum: - renesas,etheravb-r8a774a1 - renesas,etheravb-r8a774b1 + - renesas,etheravb-r8a774e1 - renesas,etheravb-r8a7795 - renesas,etheravb-r8a7796 - renesas,etheravb-r8a77961 diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 11a6fdb657c9..dfbf5fe4547a 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -126,7 +126,7 @@ properties: in a different mode than the PHY in order to function. snps,axi-config: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: AXI BUS Mode parameters. Phandle to a node that can contain the following properties @@ -141,7 +141,7 @@ properties: * snps,rb, rebuild INCRx Burst snps,mtl-rx-config: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Multiple RX Queues parameters. Phandle to a node that can contain the following properties @@ -161,10 +161,11 @@ properties: * snps,route-dcbcp, DCB Control Packets * snps,route-up, Untagged Packets * snps,route-multi-broad, Multicast & Broadcast Packets - * snps,priority, RX queue priority (Range 0x0 to 0xF) + * snps,priority, bitmask of the tagged frames priorities assigned to + the queue snps,mtl-tx-config: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Multiple TX Queues parameters. Phandle to a node that can contain the following properties @@ -188,7 +189,10 @@ properties: * snps,idle_slope, unlock on WoL * snps,high_credit, max write outstanding req. limit * snps,low_credit, max read outstanding req. limit - * snps,priority, TX queue priority (Range 0x0 to 0xF) + * snps,priority, bitmask of the priorities assigned to the queue. + When a PFC frame is received with priorities matching the bitmask, + the queue is blocked from transmitting for the pause time specified + in the PFC frame. snps,reset-gpio: deprecated: true @@ -198,7 +202,7 @@ properties: snps,reset-active-low: deprecated: true - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Indicates that the PHY Reset is active low @@ -208,55 +212,55 @@ properties: Triplet of delays. The 1st cell is reset pre-delay in micro seconds. The 2nd cell is reset pulse in micro seconds. The 3rd cell is reset post-delay in micro seconds. - $ref: /schemas/types.yaml#definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 3 maxItems: 3 snps,aal: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Use Address-Aligned Beats snps,fixed-burst: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Program the DMA to use the fixed burst mode snps,mixed-burst: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Program the DMA to use the mixed burst mode snps,force_thresh_dma_mode: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Force DMA to use the threshold mode for both tx and rx snps,force_sf_dma_mode: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Force DMA to use the Store and Forward mode for both tx and rx. This flag is ignored if force_thresh_dma_mode is set. snps,en-tx-lpi-clockgating: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Enable gating of the MAC TX clock during TX low-power mode snps,multicast-filter-bins: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: Number of multicast filter hash bins supported by this device instance snps,perfect-filter-entries: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: Number of perfect filter entries supported by this device instance snps,ps-speed: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: Port selection speed that can be passed to the core when PCS is supported. For example, this is used in case of SGMII and @@ -307,25 +311,25 @@ allOf: snps,pbl: description: Programmable Burst Length (tx and rx) - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [2, 4, 8] snps,txpbl: description: Tx Programmable Burst Length. If set, DMA tx will use this value rather than snps,pbl. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [2, 4, 8] snps,rxpbl: description: Rx Programmable Burst Length. If set, DMA rx will use this value rather than snps,pbl. - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [2, 4, 8] snps,no-pbl-x8: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core rev < 3.50, don\'t multiply the values by 4. @@ -351,7 +355,7 @@ allOf: then: properties: snps,tso: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Enables the TSO feature otherwise it will be managed by MAC HW capability register. diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml index cbacc04fc9e6..8a03a24a2019 100644 --- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml @@ -64,7 +64,7 @@ properties: - const: ether # for others socionext,syscon-phy-mode: - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array description: A phandle to syscon with one argument that configures phy mode. The argument is the ID of MAC instance. diff --git a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml index dadeb8f811c0..07a00f53adbf 100644 --- a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml +++ b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml @@ -70,7 +70,7 @@ properties: pinctrl-names: true syscon: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: Phandle to the system control device node which provides access to efuse IO range with MAC addresses diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml index 4050a3608658..047d757e8d82 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml @@ -47,31 +47,31 @@ properties: takes precedence. tx-fifo-depth: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Transmitt FIFO depth see dt-bindings/net/ti-dp83867.h for values rx-fifo-depth: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Receive FIFO depth see dt-bindings/net/ti-dp83867.h for values ti,clk-output-sel: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Muxing option for CLK_OUT pin. See dt-bindings/net/ti-dp83867.h for applicable values. The CLK_OUT pin can also be disabled by this property. When omitted, the PHY's default will be left as is. ti,rx-internal-delay: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83867.h for applicable values. Required only if interface type is PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID. ti,tx-internal-delay: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h for applicable values. Required only if interface type is @@ -101,7 +101,7 @@ properties: ti,fifo-depth: deprecated: true - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h for applicable values. diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml index c3235f08e326..70a1209cb13b 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml @@ -44,22 +44,22 @@ properties: to a maximum value (70 ohms). tx-fifo-depth: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Transmitt FIFO depth see dt-bindings/net/ti-dp83869.h for values rx-fifo-depth: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Receive FIFO depth see dt-bindings/net/ti-dp83869.h for values ti,clk-output-sel: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Muxing option for CLK_OUT pin see dt-bindings/net/ti-dp83869.h for values. ti,op-mode: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Operational mode for the PHY. If this is not set then the operational mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml index 227270cbf892..c47b58f3e3f6 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -119,12 +119,12 @@ properties: description: label associated with this port ti,mac-only: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Specifies the port works in mac-only mode. ti,syscon-efuse: - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array description: Phandle to the system control device node which provides access to efuse IO range with MAC addresses diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index 6af999191559..85c2f699d602 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -136,7 +136,7 @@ properties: - const: tcl2host-status-ring qcom,rproc: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: DT entry of q6v5-wcss remoteproc driver. Phandle to a node that can contain the following properties diff --git a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml index 83d5d0aceb04..cbbf5e8b1197 100644 --- a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml +++ b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml @@ -44,13 +44,13 @@ properties: - const: refclk syscon-phy-power: - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array description: phandle/offset pair. Phandle to the system control module and register offset to power on/off the PHY. ctrl-module: - $ref: /schemas/types.yaml#definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: (deprecated) phandle of the control module used by PHY driver to power on the PHY. Use syscon-phy-power instead. diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt index 8763f448c376..90d38f710635 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt @@ -99,7 +99,7 @@ Example: nvidia,schmitt = <TEGRA_PIN_DISABLE>; nvidia,lpdr = <TEGRA_PIN_ENABLE>; nvidia,enable-input = <TEGRA_PIN_DISABLE>; - nvidia,io-high-voltage = <TEGRA_PIN_ENABLE>; + nvidia,io-hv = <TEGRA_PIN_ENABLE>; nvidia,tristate = <TEGRA_PIN_DISABLE>; nvidia,pull = <TEGRA_PIN_PULL_NONE>; }; diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml new file mode 100644 index 000000000000..d14cb9bac849 --- /dev/null +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml @@ -0,0 +1,293 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/mediatek,power-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Power Domains Controller + +maintainers: + - Weiyi Lu <weiyi.lu@mediatek.com> + - Matthias Brugger <mbrugger@suse.com> + +description: | + Mediatek processors include support for multiple power domains which can be + powered up/down by software based on different application scenes to save power. + + IP cores belonging to a power domain should contain a 'power-domains' + property that is a phandle for SCPSYS node representing the domain. + +properties: + $nodename: + const: power-controller + + compatible: + enum: + - mediatek,mt8173-power-controller + - mediatek,mt8183-power-controller + - mediatek,mt8192-power-controller + + '#power-domain-cells': + const: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^power-domain@[0-9a-f]+$": + type: object + description: | + Represents the power domains within the power controller node as documented + in Documentation/devicetree/bindings/power/power-domain.yaml. + + properties: + + '#power-domain-cells': + description: + Must be 0 for nodes representing a single PM domain and 1 for nodes + providing multiple PM domains. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + reg: + description: | + Power domain index. Valid values are defined in: + "include/dt-bindings/power/mt8173-power.h" - for MT8173 type power domain. + "include/dt-bindings/power/mt8183-power.h" - for MT8183 type power domain. + "include/dt-bindings/power/mt8192-power.h" - for MT8192 type power domain. + maxItems: 1 + + clocks: + description: | + A number of phandles to clocks that need to be enabled during domain + power-up sequencing. + + clock-names: + description: | + List of names of clocks, in order to match the power-up sequencing + for each power domain we need to group the clocks by name. BASIC + clocks need to be enabled before enabling the corresponding power + domain, and should not have a '-' in their name (i.e mm, mfg, venc). + SUSBYS clocks need to be enabled before releasing the bus protection, + and should contain a '-' in their name (i.e mm-0, isp-0, cam-0). + + In order to follow properly the power-up sequencing, the clocks must + be specified by order, adding first the BASIC clocks followed by the + SUSBSYS clocks. + + mediatek,infracfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the device containing the INFRACFG register range. + + mediatek,smi: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the device containing the SMI register range. + + patternProperties: + "^power-domain@[0-9a-f]+$": + type: object + description: | + Represents a power domain child within a power domain parent node. + + properties: + + '#power-domain-cells': + description: + Must be 0 for nodes representing a single PM domain and 1 for nodes + providing multiple PM domains. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + reg: + maxItems: 1 + + clocks: + description: | + A number of phandles to clocks that need to be enabled during domain + power-up sequencing. + + clock-names: + description: | + List of names of clocks, in order to match the power-up sequencing + for each power domain we need to group the clocks by name. BASIC + clocks need to be enabled before enabling the corresponding power + domain, and should not have a '-' in their name (i.e mm, mfg, venc). + SUSBYS clocks need to be enabled before releasing the bus protection, + and should contain a '-' in their name (i.e mm-0, isp-0, cam-0). + + In order to follow properly the power-up sequencing, the clocks must + be specified by order, adding first the BASIC clocks followed by the + SUSBSYS clocks. + + mediatek,infracfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the device containing the INFRACFG register range. + + mediatek,smi: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the device containing the SMI register range. + + patternProperties: + "^power-domain@[0-9a-f]+$": + type: object + description: | + Represents a power domain child within a power domain parent node. + + properties: + + '#power-domain-cells': + description: + Must be 0 for nodes representing a single PM domain and 1 for nodes + providing multiple PM domains. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + reg: + maxItems: 1 + + clocks: + description: | + A number of phandles to clocks that need to be enabled during domain + power-up sequencing. + + clock-names: + description: | + List of names of clocks, in order to match the power-up sequencing + for each power domain we need to group the clocks by name. BASIC + clocks need to be enabled before enabling the corresponding power + domain, and should not have a '-' in their name (i.e mm, mfg, venc). + SUSBYS clocks need to be enabled before releasing the bus protection, + and should contain a '-' in their name (i.e mm-0, isp-0, cam-0). + + In order to follow properly the power-up sequencing, the clocks must + be specified by order, adding first the BASIC clocks followed by the + SUSBSYS clocks. + + mediatek,infracfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the device containing the INFRACFG register range. + + mediatek,smi: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the device containing the SMI register range. + + required: + - reg + + additionalProperties: false + + required: + - reg + + additionalProperties: false + + required: + - reg + + additionalProperties: false + +required: + - compatible + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + scpsys: syscon@10006000 { + compatible = "syscon", "simple-mfd"; + reg = <0 0x10006000 0 0x1000>; + + spm: power-controller { + compatible = "mediatek,mt8173-power-controller"; + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <1>; + + /* power domains of the SoC */ + power-domain@MT8173_POWER_DOMAIN_VDEC { + reg = <MT8173_POWER_DOMAIN_VDEC>; + clocks = <&topckgen CLK_TOP_MM_SEL>; + clock-names = "mm"; + #power-domain-cells = <0>; + }; + power-domain@MT8173_POWER_DOMAIN_VENC { + reg = <MT8173_POWER_DOMAIN_VENC>; + clocks = <&topckgen CLK_TOP_MM_SEL>, + <&topckgen CLK_TOP_VENC_SEL>; + clock-names = "mm", "venc"; + #power-domain-cells = <0>; + }; + power-domain@MT8173_POWER_DOMAIN_ISP { + reg = <MT8173_POWER_DOMAIN_ISP>; + clocks = <&topckgen CLK_TOP_MM_SEL>; + clock-names = "mm"; + #power-domain-cells = <0>; + }; + power-domain@MT8173_POWER_DOMAIN_MM { + reg = <MT8173_POWER_DOMAIN_MM>; + clocks = <&topckgen CLK_TOP_MM_SEL>; + clock-names = "mm"; + #power-domain-cells = <0>; + mediatek,infracfg = <&infracfg>; + }; + power-domain@MT8173_POWER_DOMAIN_VENC_LT { + reg = <MT8173_POWER_DOMAIN_VENC_LT>; + clocks = <&topckgen CLK_TOP_MM_SEL>, + <&topckgen CLK_TOP_VENC_LT_SEL>; + clock-names = "mm", "venclt"; + #power-domain-cells = <0>; + }; + power-domain@MT8173_POWER_DOMAIN_AUDIO { + reg = <MT8173_POWER_DOMAIN_AUDIO>; + #power-domain-cells = <0>; + }; + power-domain@MT8173_POWER_DOMAIN_USB { + reg = <MT8173_POWER_DOMAIN_USB>; + #power-domain-cells = <0>; + }; + power-domain@MT8173_POWER_DOMAIN_MFG_ASYNC { + reg = <MT8173_POWER_DOMAIN_MFG_ASYNC>; + clocks = <&clk26m>; + clock-names = "mfg"; + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <1>; + + power-domain@MT8173_POWER_DOMAIN_MFG_2D { + reg = <MT8173_POWER_DOMAIN_MFG_2D>; + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <1>; + + power-domain@MT8173_POWER_DOMAIN_MFG { + reg = <MT8173_POWER_DOMAIN_MFG>; + #power-domain-cells = <0>; + mediatek,infracfg = <&infracfg>; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index 8058955fb3b9..64825128ee97 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -16,12 +16,16 @@ description: properties: compatible: enum: + - qcom,msm8916-rpmpd + - qcom,msm8939-rpmpd - qcom,msm8976-rpmpd - qcom,msm8996-rpmpd - qcom,msm8998-rpmpd - qcom,qcs404-rpmpd + - qcom,sdm660-rpmpd - qcom,sc7180-rpmhpd - qcom,sdm845-rpmhpd + - qcom,sdx55-rpmhpd - qcom,sm8150-rpmhpd - qcom,sm8250-rpmhpd diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt index 4d530d815484..c5de7b555feb 100644 --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt @@ -7,7 +7,9 @@ The reset registers are both present in the MSCC vcoreiii MIPS and microchip Sparx5 armv8 SoC's. Required Properties: - - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset" + + - compatible: "mscc,ocelot-chip-reset", "mscc,luton-chip-reset", + "mscc,jaguar2-chip-reset" or "microchip,sparx5-chip-reset" Example: reset@1070008 { diff --git a/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml new file mode 100644 index 000000000000..03bd1fa5a623 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/regulator-poweroff.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Force-disable power regulator to turn the power off. + +maintainers: + - Michael Klein <michael@fossekall.de> + +description: | + When the power-off handler is called, a power regulator is disabled by + calling regulator_force_disable(). If the power is still on and the + CPU still running after a 3000ms delay, a warning is emitted. + +properties: + compatible: + const: "regulator-poweroff" + + cpu-supply: + description: + regulator to disable on power-down + +required: + - compatible + - cpu-supply + +additionalProperties: false + +examples: + - | + regulator-poweroff { + compatible = "regulator-poweroff"; + cpu-supply = <®_vcc1v2>; + }; +... diff --git a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml index ee92e6a076ac..5fcdf5801536 100644 --- a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml @@ -27,7 +27,7 @@ properties: of this binary blob is kept secret by CellWise. The only way to obtain it is to mail two batteries to a test facility of CellWise and receive back a test report with the binary blob. - $ref: /schemas/types.yaml#definitions/uint8-array + $ref: /schemas/types.yaml#/definitions/uint8-array minItems: 64 maxItems: 64 diff --git a/Documentation/devicetree/bindings/powerpc/sleep.yaml b/Documentation/devicetree/bindings/powerpc/sleep.yaml index 6494c7d08b93..1b0936a5beec 100644 --- a/Documentation/devicetree/bindings/powerpc/sleep.yaml +++ b/Documentation/devicetree/bindings/powerpc/sleep.yaml @@ -42,6 +42,6 @@ select: true properties: sleep: - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array additionalProperties: true diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt deleted file mode 100644 index 985fcc65f8c4..000000000000 --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++ /dev/null @@ -1,16 +0,0 @@ -Atmel TCB PWM controller - -Required properties: -- compatible: should be "atmel,tcb-pwm" -- #pwm-cells: should be 3. See pwm.yaml in this directory for a description of - the cells format. The only third cell flag supported by this binding is - PWM_POLARITY_INVERTED. -- tc-block: The Timer Counter block to use as a PWM chip. - -Example: - -pwm { - compatible = "atmel,tcb-pwm"; - #pwm-cells = <3>; - tc-block = <1>; -}; diff --git a/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml new file mode 100644 index 000000000000..ff6880a02ce6 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Intel Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/intel,keembay-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Keem Bay PWM Device Tree Bindings + +maintainers: + - Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com> + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + enum: + - intel,keembay-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#pwm-cells": + const: 2 + +required: + - compatible + - reg + - clocks + - '#pwm-cells' + +additionalProperties: false + +examples: + - | + #define KEEM_BAY_A53_GPIO + + pwm@203200a0 { + compatible = "intel,keembay-pwm"; + reg = <0x203200a0 0xe8>; + clocks = <&scmi_clk KEEM_BAY_A53_GPIO>; + #pwm-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml new file mode 100644 index 000000000000..11a606536169 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/intel,lgm-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LGM SoC PWM fan controller + +maintainers: + - Rahul Tanwar <rtanwar@maxlinear.com> + +properties: + compatible: + const: intel,lgm-pwm + + reg: + maxItems: 1 + + "#pwm-cells": + const: 2 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - resets + +additionalProperties: false + +examples: + - | + pwm: pwm@e0d00000 { + compatible = "intel,lgm-pwm"; + reg = <0xe0d00000 0x30>; + #pwm-cells = <2>; + clocks = <&cgu0 126>; + resets = <&rcu0 0x30 21>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt index 29adff59c479..25ed214473d7 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt @@ -7,6 +7,7 @@ Required properties: - "mediatek,mt7623-pwm": found on mt7623 SoC. - "mediatek,mt7628-pwm": found on mt7628 SoC. - "mediatek,mt7629-pwm": found on mt7629 SoC. + - "mediatek,mt8183-pwm": found on mt8183 SoC. - "mediatek,mt8516-pwm": found on mt8516 SoC. - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.yaml in this directory for a description of diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt index 0521957c253f..902b271891ae 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt @@ -4,6 +4,7 @@ Required properties: - compatible: should be "mediatek,<name>-disp-pwm": - "mediatek,mt2701-disp-pwm": found on mt2701 SoC. - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. + - "mediatek,mt8167-disp-pwm", "mediatek,mt8173-disp-pwm": found on mt8167 SoC. - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.yaml in this directory for a description of diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml index e7b3abe30363..0a66338c7e5a 100644 --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml @@ -59,7 +59,6 @@ properties: description: u32 value representing regulator enable bit offset. vin-supply: - $ref: '/schemas/types.yaml#/definitions/phandle' description: input supply phandle. required: diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml index a6c259ce9785..956156fe52a3 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml @@ -19,7 +19,9 @@ description: | properties: compatible: enum: - - nxp,pf8x00 + - nxp,pf8100 + - nxp,pf8121a + - nxp,pf8200 reg: maxItems: 1 @@ -118,7 +120,7 @@ examples: #size-cells = <0>; pmic@8 { - compatible = "nxp,pf8x00"; + compatible = "nxp,pf8100"; reg = <0x08>; regulators { diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt index b8f0b7809c02..7d462b899473 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt @@ -44,6 +44,7 @@ First Level Nodes - PMIC Definition: Must be one of below: "qcom,pm8005-rpmh-regulators" "qcom,pm8009-rpmh-regulators" + "qcom,pm8009-1-rpmh-regulators" "qcom,pm8150-rpmh-regulators" "qcom,pm8150l-rpmh-regulators" "qcom,pm8350-rpmh-regulators" diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml index 8acd2de3de3a..d30dc045aac6 100644 --- a/Documentation/devicetree/bindings/rtc/rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/rtc.yaml @@ -63,6 +63,11 @@ properties: description: Enables wake up of host system on alarm. + reset-source: + $ref: /schemas/types.yaml#/definitions/flag + description: + The RTC is able to reset the machine. + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index c1d4c196f005..f54cae9ff7b2 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -126,7 +126,7 @@ properties: maxItems: 1 current-speed: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: The current active speed of the UART. reg-offset: @@ -154,7 +154,7 @@ properties: Set to indicate that the port does not implement loopback test mode. fifo-size: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: The fifo size of the UART. auto-flow-control: @@ -165,7 +165,7 @@ properties: property. tx-threshold: - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | Specify the TX FIFO low water indication for parts with programmable TX FIFO thresholds. diff --git a/Documentation/devicetree/bindings/serial/litex,liteuart.yaml b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml new file mode 100644 index 000000000000..c4f1f489dc2d --- /dev/null +++ b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/litex,liteuart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LiteUART serial controller + +maintainers: + - Karol Gugala <kgugala@antmicro.com> + - Mateusz Holenko <mholenko@antmicro.com> + +description: | + LiteUART serial controller is a part of the LiteX FPGA SoC builder. It supports + multiple CPU architectures, currently including e.g. OpenRISC and RISC-V. + +properties: + compatible: + const: litex,liteuart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + uart0: serial@e0001800 { + compatible = "litex,liteuart"; + reg = <0xe0001800 0x100>; + interrupts = <2>; + }; diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml new file mode 100644 index 000000000000..c8b57c7fd08c --- /dev/null +++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +# Copyright 2020 Antmicro <www.antmicro.com> +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: LiteX SoC Controller driver + +description: | + This is the SoC Controller driver for the LiteX SoC Builder. + Its purpose is to verify LiteX CSR (Control&Status Register) access + operations and provide functions for other drivers to read/write CSRs + and to check if those accessors are ready to be used. + +maintainers: + - Karol Gugala <kgugala@antmicro.com> + - Mateusz Holenko <mholenko@antmicro.com> + +properties: + compatible: + const: litex,soc-controller + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + soc_ctrl0: soc-controller@f0000000 { + compatible = "litex,soc-controller"; + reg = <0xf0000000 0xc>; + status = "okay"; + }; + +... diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml new file mode 100644 index 000000000000..31e4d3c339bf --- /dev/null +++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# # Copyright 2020 MediaTek Inc. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/mediatek/devapc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Device Access Permission Control driver + +description: | + MediaTek bus fabric provides TrustZone security support and data + protection to prevent slaves from being accessed by unexpected masters. + The security violation is logged and sent to the processor for further + analysis and countermeasures. + +maintainers: + - Neal Liu <neal.liu@mediatek.com> + +properties: + compatible: + enum: + - mediatek,mt6779-devapc + + reg: + description: The base address of devapc register bank + maxItems: 1 + + interrupts: + description: A single interrupt specifier + maxItems: 1 + + clocks: + description: Contains module clock source and clock names + maxItems: 1 + + clock-names: + description: Names of the clocks list in clocks property + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt6779-clk.h> + + devapc: devapc@10207000 { + compatible = "mediatek,mt6779-devapc"; + reg = <0x10207000 0x1000>; + interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>; + clocks = <&infracfg_ao CLK_INFRA_DEVICE_APC>; + clock-names = "devapc-infra-clock"; + }; diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml index 55fffae05dcf..597d67fba92f 100644 --- a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml +++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml @@ -59,6 +59,7 @@ patternProperties: items: - enum: - atmel,tcb-timer + - atmel,tcb-pwm - microchip,tcb-capture reg: description: @@ -68,10 +69,35 @@ patternProperties: minItems: 1 maxItems: 3 + required: + - compatible + - reg + + "^pwm@[0-2]$": + description: The timer block channels that are used as PWMs. + $ref: ../../pwm/pwm.yaml# + type: object + properties: + compatible: + const: atmel,tcb-pwm + reg: + description: + TCB channel to use for this PWM. + enum: [ 0, 1, 2 ] + + "#pwm-cells": + description: + The only third cell flag supported by this binding is + PWM_POLARITY_INVERTED. + const: 3 required: - compatible - reg + - "#pwm-cells" + + additionalProperties: false + allOf: - if: @@ -158,7 +184,13 @@ examples: compatible = "atmel,tcb-timer"; reg = <1>; }; - }; + + pwm@2 { + compatible = "atmel,tcb-pwm"; + reg = <2>; + #pwm-cells = <3>; + }; + }; /* TCB0 Capture with QDEC: */ timer@f800c000 { compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon"; diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml index c3c595e235a8..ddea3d41971d 100644 --- a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml +++ b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml @@ -55,7 +55,7 @@ properties: description: TI-SCI RM subtype for GP ring range ti,sci: - $ref: /schemas/types.yaml#definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array description: phandle on TI-SCI compatible System controller node ti,sci-dev-id: diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu-settings.yaml b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu-settings.yaml new file mode 100644 index 000000000000..cb245f400287 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu-settings.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/xilinx/xlnx,vcu-settings.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx VCU Settings + +maintainers: + - Michael Tretter <kernel@pengutronix.de> + +description: | + The Xilinx VCU Settings provides information about the configuration of the + video codec unit. + +properties: + compatible: + items: + - const: xlnx,vcu-settings + - const: syscon + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + fpga { + #address-cells = <2>; + #size-cells = <2>; + + xlnx_vcu: vcu@a0041000 { + compatible = "xlnx,vcu-settings", "syscon"; + reg = <0x0 0xa0041000 0x0 0x1000>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt index 6786d6715df0..2417b13ba468 100644 --- a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt +++ b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt @@ -12,10 +12,7 @@ Required properties: - compatible: shall be one of: "xlnx,vcu" "xlnx,vcu-logicoreip-1.0" -- reg, reg-names: There are two sets of registers need to provide. - 1. vcu slcr - 2. Logicore - reg-names should contain name for the each register sequence. +- reg : The base offset and size of the VCU_PL_SLCR register space. - clocks: phandle for aclk and pll_ref clocksource - clock-names: The identification string, "aclk", is always required for the axi clock. "pll_ref" is required for pll. @@ -23,9 +20,7 @@ Example: xlnx_vcu: vcu@a0040000 { compatible = "xlnx,vcu-logicoreip-1.0"; - reg = <0x0 0xa0040000 0x0 0x1000>, - <0x0 0xa0041000 0x0 0x1000>; - reg-names = "vcu_slcr", "logicore"; + reg = <0x0 0xa0040000 0x0 0x1000>; clocks = <&si570_1>, <&clkc 71>; clock-names = "pll_ref", "aclk"; }; diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml index be390accdd07..dd47fef9854d 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml @@ -57,7 +57,7 @@ properties: 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. - $ref: /schemas/types.yaml#definitions/non-unique-string-array + $ref: /schemas/types.yaml#/definitions/non-unique-string-array minItems: 2 maxItems: 18 items: diff --git a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml index bf8c8ba25009..54650823b29a 100644 --- a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml +++ b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Mediatek MT8192 with MT6359, RT1015 and RT5682 ASoC sound card driver maintainers: - - Jiaxin Yu <jiaxin.yu@mediatek.com> - - Shane Chien <shane.chien@mediatek.com> + - Jiaxin Yu <jiaxin.yu@mediatek.com> + - Shane Chien <shane.chien@mediatek.com> description: This binding describes the MT8192 sound card. diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml index e543a6123792..b55775e21de6 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml @@ -44,7 +44,6 @@ properties: maxItems: 3 clock-names: - maxItems: 3 items: - const: hda - const: hda2hdmi @@ -54,7 +53,6 @@ properties: maxItems: 3 reset-names: - maxItems: 3 items: - const: hda - const: hda2hdmi diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index 6ad48c7681c1..f2443b651282 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -106,7 +106,7 @@ patternProperties: Must contain the phandle and index of the SAI sub-block providing the synchronization. allOf: - - $ref: /schemas/types.yaml#definitions/phandle-array + - $ref: /schemas/types.yaml#/definitions/phandle-array - maxItems: 1 st,iec60958: @@ -117,7 +117,7 @@ patternProperties: configured according to protocol defined in related DAI link node, such as i2s, left justified, right justified, dsp and pdm protocols. allOf: - - $ref: /schemas/types.yaml#definitions/flag + - $ref: /schemas/types.yaml#/definitions/flag "#clock-cells": description: Configure the SAI device as master clock provider. diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml index 805da4d6a88e..ec06789b21df 100644 --- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml @@ -1,4 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +# Author: Peter Ujfalusi <peter.ujfalusi@ti.com> %YAML 1.2 --- $id: http://devicetree.org/schemas/sound/ti,j721e-cpb-audio.yaml# @@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments J721e Common Processor Board Audio Support maintainers: - - Peter Ujfalusi <peter.ujfalusi@ti.com> + - Peter Ujfalusi <peter.ujfalusi@gmail.com> description: | The audio support on the board is using pcm3168a codec connected to McASP10 diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml index bb780f621628..ee9f960de36b 100644 --- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml @@ -1,4 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +# Author: Peter Ujfalusi <peter.ujfalusi@ti.com> %YAML 1.2 --- $id: http://devicetree.org/schemas/sound/ti,j721e-cpb-ivi-audio.yaml# @@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments J721e Common Processor Board Audio Support maintainers: - - Peter Ujfalusi <peter.ujfalusi@ti.com> + - Peter Ujfalusi <peter.ujfalusi@gmail.com> description: | The Infotainment board plugs into the Common Processor Board, the support of the diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml index 0f078bd0a3e5..22603256ddf8 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml @@ -51,7 +51,6 @@ properties: maxItems: 1 phy-names: - maxItems: 1 items: - const: usb diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index 737c1f47b7de..54c361d4a7af 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -74,11 +74,8 @@ properties: phys: maxItems: 1 - items: - - description: phandle + phy specifier pair. phy-names: - maxItems: 1 items: - const: usb diff --git a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml new file mode 100644 index 000000000000..9a51efa9d101 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/usb/st,stusb160x.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: STMicroelectronics STUSB160x Type-C controller bindings + +maintainers: + - Amelie Delaunay <amelie.delaunay@st.com> + +properties: + compatible: + enum: + - st,stusb1600 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vdd-supply: + description: main power supply (4.1V-22V) + + vsys-supply: + description: low power supply (3.0V-5.5V) + + vconn-supply: + description: power supply (2.7V-5.5V) used to supply VConn on CC pin in + source or dual power role + + connector: + type: object + + allOf: + - $ref: ../connector/usb-connector.yaml + + properties: + compatible: + const: usb-c-connector + + power-role: true + + typec-power-opmode: true + + required: + - compatible + +required: + - compatible + - reg + - connector + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c4 { + #address-cells = <1>; + #size-cells = <0>; + + typec: stusb1600@28 { + compatible = "st,stusb1600"; + reg = <0x28>; + vdd-supply = <&vbus_drd>; + vsys-supply = <&vdd_usb>; + interrupts = <11 IRQ_TYPE_EDGE_FALLING>; + interrupt-parent = <&gpioi>; + + typec_con: connector { + compatible = "usb-c-connector"; + label = "USB-C"; + power-role = "dual"; + data-role = "dual"; + typec-power-opmode = "default"; + + port { + typec_con_ep: endpoint { + remote-endpoint = <&usbotg_hs_ep>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 388245b91a55..148b3fb4ceaf 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -11,8 +11,12 @@ maintainers: properties: compatible: - items: + oneOf: - const: ti,j721e-usb + - const: ti,am64-usb + - items: + - const: ti,j721e-usb + - const: ti,am64-usb reg: description: module registers diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 57f5f312e949..041ae90b0d8f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -25,6 +25,8 @@ patternProperties: # Keep list in alphabetical order. "^70mai,.*": description: 70mai Co., Ltd. + "^abb,.*": + description: ABB "^abilis,.*": description: Abilis Systems "^abracon,.*": @@ -67,6 +69,8 @@ patternProperties: description: AlphaScale Integrated Circuits Systems, Inc. "^alps,.*": description: Alps Electric Co., Ltd. + "^alt,.*": + description: Altus-Escon-Company BV "^altr,.*": description: Altera Corp. "^amarula,.*": @@ -183,6 +187,8 @@ patternProperties: description: CALAO Systems SAS "^calxeda,.*": description: Calxeda + "^canaan,.*": + description: Canaan, Inc. "^caninos,.*": description: Caninos Loucos Program "^capella,.*": @@ -319,10 +325,14 @@ patternProperties: description: Einfochips "^elan,.*": description: Elan Microelectronic Corp. + "^element14,.*": + description: Element14 (A Premier Farnell Company) "^elgin,.*": description: Elgin S/A. "^elida,.*": description: Shenzhen Elida Technology Co., Ltd. + "^elimo,.*": + description: Elimo Engineering Ltd. "^embest,.*": description: Shenzhen Embest Technology Co., Ltd. "^emlid,.*": @@ -459,6 +469,8 @@ patternProperties: description: Holt Integrated Circuits, Inc. "^honeywell,.*": description: Honeywell + "^honestar,.*": + description: Honestar Technologies Co., Ltd. "^hoperun,.*": description: Jiangsu HopeRun Software Co., Ltd. "^hp,.*": @@ -561,6 +573,8 @@ patternProperties: description: Kionix, Inc. "^kobo,.*": description: Rakuten Kobo Inc. + "^kobol,.*": + description: Kobol Innovations Pte. Ltd. "^koe,.*": description: Kaohsiung Opto-Electronics Inc. "^kontron,.*": @@ -609,6 +623,8 @@ patternProperties: description: Linux-specific binding "^linx,.*": description: Linx Technologies + "^litex,.*": + description: LiteX SoC builder "^lltc,.*": description: Linear Technology Corporation "^logicpd,.*": @@ -679,6 +695,8 @@ patternProperties: description: Micron Technology Inc. "^microsoft,.*": description: Microsoft Corporation + "^microsys,.*": + description: MicroSys Electronics GmbH "^mikroe,.*": description: MikroElektronika d.o.o. "^mikrotik,.*": @@ -772,6 +790,8 @@ patternProperties: description: NXP Semiconductors "^oceanic,.*": description: Oceanic Systems (UK) Ltd. + "^oct,.*": + description: Octavo Systems LLC "^okaya,.*": description: Okaya Electric America, Inc. "^oki,.*": @@ -804,6 +824,8 @@ patternProperties: description: Ortus Technology Co., Ltd. "^osddisplays,.*": description: OSD Displays + "^ouya,.*": + description: Ouya Inc. "^overkiz,.*": description: Overkiz SAS "^ovti,.*": @@ -906,6 +928,8 @@ patternProperties: description: iMX6 Rex Project "^rervision,.*": description: Shenzhen Rervision Technology Co., Ltd. + "^revotics,.*": + description: Revolution Robotics, Inc. (Revotics) "^richtek,.*": description: Richtek Technology Corporation "^ricoh,.*": @@ -1154,12 +1178,16 @@ patternProperties: description: Vamrs Ltd. "^variscite,.*": description: Variscite Ltd. + "^vdl,.*": + description: Van der Laan b.v. "^via,.*": description: VIA Technologies, Inc. "^videostrong,.*": description: Videostrong Technology Co., Ltd. "^virtio,.*": description: Virtual I/O Device Specification, developed by the OASIS consortium + "^virtual,.*": + description: Used for virtual device without specific vendor. "^vishay,.*": description: Vishay Intertechnology, Inc "^vitesse,.*": diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml index e8f226376108..5ac607de8be4 100644 --- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml @@ -22,6 +22,9 @@ properties: - const: allwinner,sun50i-a64-wdt - const: allwinner,sun6i-a31-wdt - items: + - const: allwinner,sun50i-a100-wdt + - const: allwinner,sun6i-a31-wdt + - items: - const: allwinner,sun50i-h6-wdt - const: allwinner,sun6i-a31-wdt - items: diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml index 991b4e33486e..fb7695515be1 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml @@ -18,10 +18,26 @@ properties: - const: fsl,imx21-wdt - items: - enum: + - fsl,imx25-wdt + - fsl,imx27-wdt + - fsl,imx31-wdt + - fsl,imx35-wdt + - fsl,imx50-wdt + - fsl,imx51-wdt + - fsl,imx53-wdt + - fsl,imx6q-wdt + - fsl,imx6sl-wdt + - fsl,imx6sll-wdt + - fsl,imx6sx-wdt + - fsl,imx6ul-wdt + - fsl,imx7d-wdt - fsl,imx8mm-wdt - fsl,imx8mn-wdt - fsl,imx8mp-wdt - fsl,imx8mq-wdt + - fsl,ls1012a-wdt + - fsl,ls1043a-wdt + - fsl,vf610-wdt - const: fsl,imx21-wdt reg: diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml index d9fc7bb851b1..f7ee9229c29f 100644 --- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml @@ -14,7 +14,15 @@ maintainers: properties: compatible: - const: snps,dw-wdt + oneOf: + - const: snps,dw-wdt + - items: + - enum: + - rockchip,rk3066-wdt + - rockchip,rk3188-wdt + - rockchip,rk3288-wdt + - rockchip,rk3368-wdt + - const: snps,dw-wdt reg: maxItems: 1 diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index 2fb2ff297d69..36ac2166ad67 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -48,12 +48,12 @@ or ``virtualenv``, depending on how your distribution packaged Python 3. those versions, you should run ``pip install 'docutils==0.12'``. #) It is recommended to use the RTD theme for html output. Depending - on the Sphinx version, it should be installed in separate, + on the Sphinx version, it should be installed separately, with ``pip install sphinx_rtd_theme``. - #) Some ReST pages contain math expressions. Due to the way Sphinx work, + #) Some ReST pages contain math expressions. Due to the way Sphinx works, those expressions are written using LaTeX notation. It needs texlive - installed with amdfonts and amsmath in order to evaluate them. + installed with amsfonts and amsmath in order to evaluate them. In summary, if you want to install Sphinx version 1.7.9, you should do:: @@ -128,7 +128,7 @@ Sphinx Build ============ The usual way to generate the documentation is to run ``make htmldocs`` or -``make pdfdocs``. There are also other formats available, see the documentation +``make pdfdocs``. There are also other formats available: see the documentation section of ``make help``. The generated documentation is placed in format-specific subdirectories under ``Documentation/output``. @@ -303,17 +303,17 @@ and *targets* (e.g. a ref to ``:ref:`last row <last row>``` / :ref:`last row - head col 3 - head col 4 - * - column 1 + * - row 1 - field 1.1 - field 1.2 with autospan - * - column 2 + * - row 2 - field 2.1 - :rspan:`1` :cspan:`1` field 2.2 - 3.3 * .. _`last row`: - - column 3 + - row 3 Rendered as: @@ -325,17 +325,17 @@ Rendered as: - head col 3 - head col 4 - * - column 1 + * - row 1 - field 1.1 - field 1.2 with autospan - * - column 2 + * - row 2 - field 2.1 - :rspan:`1` :cspan:`1` field 2.2 - 3.3 * .. _`last row`: - - column 3 + - row 3 Cross-referencing ----------------- @@ -361,7 +361,7 @@ Figures & Images If you want to add an image, you should use the ``kernel-figure`` and ``kernel-image`` directives. E.g. to insert a figure with a scalable -image format use SVG (:ref:`svg_image_example`):: +image format, use SVG (:ref:`svg_image_example`):: .. kernel-figure:: svg_image.svg :alt: simple SVG image @@ -375,7 +375,7 @@ image format use SVG (:ref:`svg_image_example`):: SVG image example -The kernel figure (and image) directive support **DOT** formatted files, see +The kernel figure (and image) directive supports **DOT** formatted files, see * DOT: http://graphviz.org/pdf/dotguide.pdf * Graphviz: http://www.graphviz.org/content/dot-language @@ -394,7 +394,7 @@ A simple example (:ref:`hello_dot_file`):: DOT's hello world example -Embed *render* markups (or languages) like Graphviz's **DOT** is provided by the +Embedded *render* markups (or languages) like Graphviz's **DOT** are provided by the ``kernel-render`` directives.:: .. kernel-render:: DOT @@ -406,7 +406,7 @@ Embed *render* markups (or languages) like Graphviz's **DOT** is provided by the } How this will be rendered depends on the installed tools. If Graphviz is -installed, you will see an vector image. If not the raw markup is inserted as +installed, you will see a vector image. If not, the raw markup is inserted as *literal-block* (:ref:`hello_dot_render`). .. _hello_dot_render: @@ -421,8 +421,8 @@ installed, you will see an vector image. If not the raw markup is inserted as The *render* directive has all the options known from the *figure* directive, plus option ``caption``. If ``caption`` has a value, a *figure* node is -inserted. If not, a *image* node is inserted. A ``caption`` is also needed, if -you want to refer it (:ref:`hello_svg_render`). +inserted. If not, an *image* node is inserted. A ``caption`` is also needed, if +you want to refer to it (:ref:`hello_svg_render`). Embedded **SVG**:: diff --git a/Documentation/driver-api/connector.rst b/Documentation/driver-api/connector.rst index 23d068191fb1..631b84a48aa5 100644 --- a/Documentation/driver-api/connector.rst +++ b/Documentation/driver-api/connector.rst @@ -25,7 +25,7 @@ handling, etc... The Connector driver allows any kernelspace agents to use netlink based networking for inter-process communication in a significantly easier way:: - int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *)); + int cn_add_callback(const struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *)); void cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid, u32 __group, int gfp_mask); void cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group, int gfp_mask); diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index d6b2a195dbed..a2133d69872c 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -190,7 +190,7 @@ DMA Fence uABI/Sync File Indefinite DMA Fences ~~~~~~~~~~~~~~~~~~~~~ -At various times &dma_fence with an indefinite time until dma_fence_wait() +At various times struct dma_fence with an indefinite time until dma_fence_wait() finishes have been proposed. Examples include: * Future fences, used in HWC1 to signal when a buffer isn't used by the display diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst index 09a3f66dcd26..bfd057b21a00 100644 --- a/Documentation/driver-api/dmaengine/client.rst +++ b/Documentation/driver-api/dmaengine/client.rst @@ -120,7 +120,9 @@ The details of these operations are: .. code-block:: c - nr_sg = dma_map_sg(chan->device->dev, sgl, sg_len); + struct device *dma_dev = dmaengine_get_dma_device(chan); + + nr_sg = dma_map_sg(dma_dev, sgl, sg_len); if (nr_sg == 0) /* error */ diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index bb676570acc3..cd8b6e657b94 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -411,6 +411,12 @@ RESET devm_reset_control_get() devm_reset_controller_register() +RTC + devm_rtc_device_register() + devm_rtc_allocate_device() + devm_rtc_register_device() + devm_rtc_nvmem_register() + SERDEV devm_serdev_device_open() diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst index 423492d125b9..173e4c7b037d 100644 --- a/Documentation/driver-api/gpio/consumer.rst +++ b/Documentation/driver-api/gpio/consumer.rst @@ -440,18 +440,20 @@ For details refer to Documentation/firmware-guide/acpi/gpio-properties.rst Interacting With the Legacy GPIO Subsystem ========================================== -Many kernel subsystems still handle GPIOs using the legacy integer-based -interface. Although it is strongly encouraged to upgrade them to the safer -descriptor-based API, the following two functions allow you to convert a GPIO -descriptor into the GPIO integer namespace and vice-versa:: +Many kernel subsystems and drivers still handle GPIOs using the legacy +integer-based interface. It is strongly recommended to update these to the new +gpiod interface. For cases where both interfaces need to be used, the following +two functions allow to convert a GPIO descriptor into the GPIO integer namespace +and vice-versa:: int desc_to_gpio(const struct gpio_desc *desc) struct gpio_desc *gpio_to_desc(unsigned gpio) -The GPIO number returned by desc_to_gpio() can be safely used as long as the -GPIO descriptor has not been freed. All the same, a GPIO number passed to -gpio_to_desc() must have been properly acquired, and usage of the returned GPIO -descriptor is only possible after the GPIO number has been released. +The GPIO number returned by desc_to_gpio() can safely be used as a parameter of +the gpio\_*() functions for as long as the GPIO descriptor `desc` is not freed. +All the same, a GPIO number passed to gpio_to_desc() must first be properly +acquired using e.g. gpio_request_one(), and the returned GPIO descriptor is only +considered valid until that GPIO number is released using gpio_free(). Freeing a GPIO obtained by one API with the other API is forbidden and an unchecked error. diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 072a7455044e..0fb57e298b41 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -416,7 +416,8 @@ The preferred way to set up the helpers is to fill in the struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip. If you do this, the additional irq_chip will be set up by gpiolib at the same time as setting up the rest of the GPIO functionality. The following -is a typical example of a cascaded interrupt handler using gpio_irq_chip: +is a typical example of a chained cascaded interrupt handler using +the gpio_irq_chip: .. code-block:: c @@ -452,7 +453,46 @@ is a typical example of a cascaded interrupt handler using gpio_irq_chip: return devm_gpiochip_add_data(dev, &g->gc, g); -The helper support using hierarchical interrupt controllers as well. +The helper supports using threaded interrupts as well. Then you just request +the interrupt separately and go with it: + +.. code-block:: c + + /* Typical state container with dynamic irqchip */ + struct my_gpio { + struct gpio_chip gc; + struct irq_chip irq; + }; + + int irq; /* from platform etc */ + struct my_gpio *g; + struct gpio_irq_chip *girq; + + /* Set up the irqchip dynamically */ + g->irq.name = "my_gpio_irq"; + g->irq.irq_ack = my_gpio_ack_irq; + g->irq.irq_mask = my_gpio_mask_irq; + g->irq.irq_unmask = my_gpio_unmask_irq; + g->irq.irq_set_type = my_gpio_set_irq_type; + + ret = devm_request_threaded_irq(dev, irq, NULL, + irq_thread_fn, IRQF_ONESHOT, "my-chip", g); + if (ret < 0) + return ret; + + /* Get a pointer to the gpio_irq_chip */ + girq = &g->gc.irq; + girq->chip = &g->irq; + /* This will let us handle the parent IRQ in the driver */ + girq->parent_handler = NULL; + girq->num_parents = 0; + girq->parents = NULL; + girq->default_type = IRQ_TYPE_NONE; + girq->handler = handle_bad_irq; + + return devm_gpiochip_add_data(dev, &g->gc, g); + +The helper supports using hierarchical interrupt controllers as well. In this case the typical set-up will look like this: .. code-block:: c @@ -493,32 +533,13 @@ the parent hardware irq from a child (i.e. this gpio chip) hardware irq. As always it is good to look at examples in the kernel tree for advice on how to find the required pieces. -The old way of adding irqchips to gpiochips after registration is also still -available but we try to move away from this: - -- DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a - gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ - callbacks, so the callbacks need to embed the gpio_chip in its state - container and obtain a pointer to the container using container_of(). - (See Documentation/driver-api/driver-model/design-patterns.rst) - -- gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip, - as discussed above regarding different types of cascaded irqchips. The - cascaded irq has to be handled by a threaded interrupt handler. - Apart from that it works exactly like the chained irqchip. - -- gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a - gpio_chip from a parent IRQ. As the parent IRQ has usually been - explicitly requested by the driver, this does very little more than - mark all the child IRQs as having the other IRQ as parent. - If there is a need to exclude certain GPIO lines from the IRQ domain handled by these helpers, we can set .irq.need_valid_mask of the gpiochip before devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an .irq.valid_mask with as many bits set as there are GPIO lines in the chip, each bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits -from this mask. The mask must be filled in before gpiochip_irqchip_add() or -gpiochip_irqchip_add_nested() is called. +from this mask. The mask can be filled in the init_valid_mask() callback +that is part of the struct gpio_irq_chip. To use the helpers please keep the following in mind: diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index c3fe9b266e7b..b2288dc14b72 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -8,7 +8,7 @@ ----------------------- | alpha: | TODO | | arc: | TODO | - | arm: | TODO | + | arm: | ok | | arm64: | ok | | c6x: | TODO | | csky: | TODO | diff --git a/Documentation/features/time/irq-time-acct/arch-support.txt b/Documentation/features/time/irq-time-acct/arch-support.txt index d9082b91f10e..6fc03deb1c38 100644 --- a/Documentation/features/time/irq-time-acct/arch-support.txt +++ b/Documentation/features/time/irq-time-acct/arch-support.txt @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | .. | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | .. | | sh: | TODO | | sparc: | .. | diff --git a/Documentation/filesystems/ext2.rst b/Documentation/filesystems/ext2.rst index d83dbbb162e2..c2fce22cfd03 100644 --- a/Documentation/filesystems/ext2.rst +++ b/Documentation/filesystems/ext2.rst @@ -1,6 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 +============================== The Second Extended Filesystem ============================== diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst index 849d5b119eb8..cdbfec473167 100644 --- a/Documentation/filesystems/ext4/journal.rst +++ b/Documentation/filesystems/ext4/journal.rst @@ -681,3 +681,53 @@ Here is the list of supported tags and their meanings: - Stores the TID of the commit, CRC of the fast commit of which this tag represents the end of +Fast Commit Replay Idempotence +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Fast commits tags are idempotent in nature provided the recovery code follows +certain rules. The guiding principle that the commit path follows while +committing is that it stores the result of a particular operation instead of +storing the procedure. + +Let's consider this rename operation: 'mv /a /b'. Let's assume dirent '/a' +was associated with inode 10. During fast commit, instead of storing this +operation as a procedure "rename a to b", we store the resulting file system +state as a "series" of outcomes: + +- Link dirent b to inode 10 +- Unlink dirent a +- Inode 10 with valid refcount + +Now when recovery code runs, it needs "enforce" this state on the file +system. This is what guarantees idempotence of fast commit replay. + +Let's take an example of a procedure that is not idempotent and see how fast +commits make it idempotent. Consider following sequence of operations: + +1) rm A +2) mv B A +3) read A + +If we store this sequence of operations as is then the replay is not idempotent. +Let's say while in replay, we crash after (2). During the second replay, +file A (which was actually created as a result of "mv B A" operation) would get +deleted. Thus, file named A would be absent when we try to read A. So, this +sequence of operations is not idempotent. However, as mentioned above, instead +of storing the procedure fast commits store the outcome of each procedure. Thus +the fast commit log for above procedure would be as follows: + +(Let's assume dirent A was linked to inode 10 and dirent B was linked to +inode 11 before the replay) + +1) Unlink A +2) Link A to inode 11 +3) Unlink B +4) Inode 11 + +If we crash after (3) we will have file A linked to inode 11. During the second +replay, we will remove file A (inode 11). But we will create it back and make +it point to inode 11. We won't find B, so we'll just skip that step. At this +point, the refcount for inode 11 is not reliable, but that gets fixed by the +replay of last inode 11 tag. Thus, by converting a non-idempotent procedure +into a series of idempotent outcomes, fast commits ensured idempotence during +the replay. diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index b8ee761c9922..dae15c96e659 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -260,6 +260,14 @@ compress_extension=%s Support adding specified extension, so that f2fs can enab For other files, we can still enable compression via ioctl. Note that, there is one reserved special extension '*', it can be set to enable compression for all files. +compress_chksum Support verifying chksum of raw data in compressed cluster. +compress_mode=%s Control file compression mode. This supports "fs" and "user" + modes. In "fs" mode (default), f2fs does automatic compression + on the compression enabled files. In "user" mode, f2fs disables + the automaic compression and gives the user discretion of + choosing the target file and the timing. The user can do manual + compression/decompression on the compression enabled files using + ioctls. inlinecrypt When possible, encrypt/decrypt the contents of encrypted files using the blk-crypto framework rather than filesystem-layer encryption. This allows the use of @@ -810,6 +818,34 @@ Compress metadata layout:: | data length | data chksum | reserved | compressed data | +-------------+-------------+----------+----------------------------+ +Compression mode +-------------------------- + +f2fs supports "fs" and "user" compression modes with "compression_mode" mount option. +With this option, f2fs provides a choice to select the way how to compress the +compression enabled files (refer to "Compression implementation" section for how to +enable compression on a regular inode). + +1) compress_mode=fs +This is the default option. f2fs does automatic compression in the writeback of the +compression enabled files. + +2) compress_mode=user +This disables the automaic compression and gives the user discretion of choosing the +target file and the timing. The user can do manual compression/decompression on the +compression enabled files using F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE +ioctls like the below. + +To decompress a file, + +fd = open(filename, O_WRONLY, 0); +ret = ioctl(fd, F2FS_IOC_DECOMPRESS_FILE); + +To compress a file, + +fd = open(filename, O_WRONLY, 0); +ret = ioctl(fd, F2FS_IOC_COMPRESS_FILE); + NVMe Zoned Namespace devices ---------------------------- diff --git a/Documentation/filesystems/gfs2.rst b/Documentation/filesystems/gfs2.rst index 8d1ab589ce18..1bc48a13430c 100644 --- a/Documentation/filesystems/gfs2.rst +++ b/Documentation/filesystems/gfs2.rst @@ -1,53 +1,52 @@ .. SPDX-License-Identifier: GPL-2.0 -================== -Global File System -================== +==================== +Global File System 2 +==================== -https://fedorahosted.org/cluster/wiki/HomePage - -GFS is a cluster file system. It allows a cluster of computers to +GFS2 is a cluster file system. It allows a cluster of computers to simultaneously use a block device that is shared between them (with FC, -iSCSI, NBD, etc). GFS reads and writes to the block device like a local +iSCSI, NBD, etc). GFS2 reads and writes to the block device like a local file system, but also uses a lock module to allow the computers coordinate their I/O so file system consistency is maintained. One of the nifty -features of GFS is perfect consistency -- changes made to the file system +features of GFS2 is perfect consistency -- changes made to the file system on one machine show up immediately on all other machines in the cluster. -GFS uses interchangeable inter-node locking mechanisms, the currently +GFS2 uses interchangeable inter-node locking mechanisms, the currently supported mechanisms are: lock_nolock - - allows gfs to be used as a local file system + - allows GFS2 to be used as a local file system lock_dlm - - uses a distributed lock manager (dlm) for inter-node locking. + - uses the distributed lock manager (dlm) for inter-node locking. The dlm is found at linux/fs/dlm/ -Lock_dlm depends on user space cluster management systems found +lock_dlm depends on user space cluster management systems found at the URL above. -To use gfs as a local file system, no external clustering systems are +To use GFS2 as a local file system, no external clustering systems are needed, simply:: $ mkfs -t gfs2 -p lock_nolock -j 1 /dev/block_device $ mount -t gfs2 /dev/block_device /dir -If you are using Fedora, you need to install the gfs2-utils package -and, for lock_dlm, you will also need to install the cman package -and write a cluster.conf as per the documentation. For F17 and above -cman has been replaced by the dlm package. +The gfs2-utils package is required on all cluster nodes and, for lock_dlm, you +will also need the dlm and corosync user space utilities configured as per the +documentation. + +gfs2-utils can be found at https://pagure.io/gfs2-utils GFS2 is not on-disk compatible with previous versions of GFS, but it is pretty close. -The following man pages can be found at the URL above: +The following man pages are available from gfs2-utils: ============ ============================================= fsck.gfs2 to repair a filesystem gfs2_grow to expand a filesystem online gfs2_jadd to add journals to a filesystem online tunegfs2 to manipulate, examine and tune a filesystem - gfs2_convert to convert a gfs filesystem to gfs2 in-place + gfs2_convert to convert a gfs filesystem to GFS2 in-place mkfs.gfs2 to make a filesystem ============ ============================================= diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 580ab9a0fe31..587a93973929 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -97,11 +97,13 @@ directory trees to be in the same filesystem and there is no requirement that the root of a filesystem be given for either upper or lower. -The lower filesystem can be any filesystem supported by Linux and does -not need to be writable. The lower filesystem can even be another -overlayfs. The upper filesystem will normally be writable and if it -is it must support the creation of trusted.* extended attributes, and -must provide valid d_type in readdir responses, so NFS is not suitable. +A wide range of filesystems supported by Linux can be the lower filesystem, +but not all filesystems that are mountable by Linux have the features +needed for OverlayFS to work. The lower filesystem does not need to be +writable. The lower filesystem can even be another overlayfs. The upper +filesystem will normally be writable and if it is it must support the +creation of trusted.* and/or user.* extended attributes, and must provide +valid d_type in readdir responses, so NFS is not suitable. A read-only overlay of two read-only filesystems may use any filesystem type. @@ -467,14 +469,18 @@ summarized in the `Inode properties`_ table above. Changes to underlying filesystems --------------------------------- -Offline changes, when the overlay is not mounted, are allowed to either -the upper or the lower trees. - Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in 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 +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. + When the overlay NFS export feature is enabled, overlay filesystems behavior on offline changes of the underlying lower layer is different than the behavior when NFS export is disabled. @@ -563,6 +569,11 @@ This verification may cause significant overhead in some cases. Note: the mount options index=off,nfs_export=on are conflicting for a read-write mount and will result in an error. +Note: the mount option uuid=off can be used to replace UUID of the underlying +filesystem in file handles with null, and effectively disable UUID checks. This +can be useful in case the underlying disk is copied and the UUID of this copy +is changed. This is only applicable if all lower/upper/work directories are on +the same filesystem, otherwise it will fallback to normal behaviour. Volatile mount -------------- @@ -583,6 +594,15 @@ fresh one. In very limited cases where the user knows that the system has not crashed and contents of upperdir are intact, The "volatile" directory can be removed. + +User xattr +---------- + +The the "-o userxattr" mount option forces overlayfs to use the +"user.overlay." xattr namespace instead of "trusted.overlay.". This is +useful for unprivileged mounting of overlayfs. + + Testsuite --------- diff --git a/Documentation/firmware-guide/acpi/apei/einj.rst b/Documentation/firmware-guide/acpi/apei/einj.rst index e588bccf5158..c042176e1707 100644 --- a/Documentation/firmware-guide/acpi/apei/einj.rst +++ b/Documentation/firmware-guide/acpi/apei/einj.rst @@ -50,8 +50,8 @@ The following files belong to it: 0x00000010 Memory Uncorrectable non-fatal 0x00000020 Memory Uncorrectable fatal 0x00000040 PCI Express Correctable - 0x00000080 PCI Express Uncorrectable fatal - 0x00000100 PCI Express Uncorrectable non-fatal + 0x00000080 PCI Express Uncorrectable non-fatal + 0x00000100 PCI Express Uncorrectable fatal 0x00000200 Platform Correctable 0x00000400 Platform Uncorrectable non-fatal 0x00000800 Platform Uncorrectable fatal diff --git a/Documentation/hwmon/sbtsi_temp.rst b/Documentation/hwmon/sbtsi_temp.rst index 922b3c8db666..749f518389c3 100644 --- a/Documentation/hwmon/sbtsi_temp.rst +++ b/Documentation/hwmon/sbtsi_temp.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0-or-later Kernel driver sbtsi_temp -================== +======================== Supported hardware: diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 1cf1aebdd6cd..226ae072da7d 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -553,6 +553,41 @@ with "depends on m". E.g.:: limits FOO to module (=m) or disabled (=n). +Compile-testing +~~~~~~~~~~~~~~~ +If a config symbol has a dependency, but the code controlled by the config +symbol can still be compiled if the dependency is not met, it is encouraged to +increase build coverage by adding an "|| COMPILE_TEST" clause to the +dependency. This is especially useful for drivers for more exotic hardware, as +it allows continuous-integration systems to compile-test the code on a more +common system, and detect bugs that way. +Note that compile-tested code should avoid crashing when run on a system where +the dependency is not met. + +Architecture and platform dependencies +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Due to the presence of stubs, most drivers can now be compiled on most +architectures. However, this does not mean it makes sense to have all drivers +available everywhere, as the actual hardware may only exist on specific +architectures and platforms. This is especially true for on-SoC IP cores, +which may be limited to a specific vendor or SoC family. + +To prevent asking the user about drivers that cannot be used on the system(s) +the user is compiling a kernel for, and if it makes sense, config symbols +controlling the compilation of a driver should contain proper dependencies, +limiting the visibility of the symbol to (a superset of) the platform(s) the +driver can be used on. The dependency can be an architecture (e.g. ARM) or +platform (e.g. ARCH_OMAP4) dependency. This makes life simpler not only for +distro config owners, but also for every single developer or user who +configures a kernel. + +Such a dependency can be relaxed by combining it with the compile-testing rule +above, leading to: + + config FOO + bool "Support for foo hardware" + depends on ARCH_FOO_VENDOR || COMPILE_TEST + Kconfig recursive dependency limitations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/kbuild/kconfig-macro-language.rst b/Documentation/kbuild/kconfig-macro-language.rst index 8b413ef9603d..6163467f6ae4 100644 --- a/Documentation/kbuild/kconfig-macro-language.rst +++ b/Documentation/kbuild/kconfig-macro-language.rst @@ -97,7 +97,7 @@ Like Make, Kconfig provides several built-in functions. Every function takes a particular number of arguments. In Make, every built-in function takes at least one argument. Kconfig allows -zero argument for built-in functions, such as $(fileno), $(lineno). You could +zero argument for built-in functions, such as $(filename), $(lineno). You could consider those as "built-in variable", but it is just a matter of how we call it after all. Let's say "built-in function" here to refer to natively supported functionality. diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index 0d5dd5413af0..9f6a11881951 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -15,13 +15,15 @@ This document describes the Linux kernel Makefiles. --- 3.4 Objects which export symbols --- 3.5 Library file goals - lib-y --- 3.6 Descending down in directories - --- 3.7 Compilation flags - --- 3.8 <deleted> - --- 3.9 Dependency tracking - --- 3.10 Special Rules - --- 3.11 $(CC) support functions - --- 3.12 $(LD) support functions - --- 3.13 Script Invocation + --- 3.7 Non-builtin vmlinux targets - extra-y + --- 3.8 Always built goals - always-y + --- 3.9 Compilation flags + --- 3.10 Dependency tracking + --- 3.11 Custom Rules + --- 3.12 Command change detection + --- 3.13 $(CC) support functions + --- 3.14 $(LD) support functions + --- 3.15 Script Invocation === 4 Host Program support --- 4.1 Simple Host Program @@ -46,7 +48,7 @@ This document describes the Linux kernel Makefiles. --- 7.5 Architecture-specific boot images --- 7.6 Building non-kbuild targets --- 7.7 Commands useful for building a boot image - --- 7.8 Custom kbuild commands + --- 7.8 <deleted> --- 7.9 Preprocessing linker scripts --- 7.10 Generic header files --- 7.11 Post-link pass @@ -67,11 +69,11 @@ This document describes the Linux kernel Makefiles. The Makefiles have five parts:: - Makefile the top Makefile. - .config the kernel configuration file. - arch/$(ARCH)/Makefile the arch Makefile. - scripts/Makefile.* common rules etc. for all kbuild Makefiles. - kbuild Makefiles there are about 500 of these. + Makefile the top Makefile. + .config the kernel configuration file. + arch/$(SRCARCH)/Makefile the arch Makefile. + scripts/Makefile.* common rules etc. for all kbuild Makefiles. + kbuild Makefiles exist in every subdirectory The top Makefile reads the .config file, which comes from the kernel configuration process. @@ -82,7 +84,7 @@ It builds these goals by recursively descending into the subdirectories of the kernel source tree. The list of subdirectories which are visited depends upon the kernel configuration. The top Makefile textually includes an arch Makefile -with the name arch/$(ARCH)/Makefile. The arch Makefile supplies +with the name arch/$(SRCARCH)/Makefile. The arch Makefile supplies architecture-specific information to the top Makefile. Each subdirectory has a kbuild Makefile which carries out the commands @@ -278,7 +280,7 @@ more details, with real examples. actually recognize that there is a lib.a being built, the directory shall be listed in libs-y. - See also "6.4 List directories to visit when descending". + See also "7.4 List directories to visit when descending". Use of lib-y is normally restricted to `lib/` and `arch/*/lib`. @@ -317,11 +319,79 @@ more details, with real examples. that directory specifies obj-y, those objects will be left orphan. It is very likely a bug of the Makefile or of dependencies in Kconfig. + Kbuild also supports dedicated syntax, subdir-y and subdir-m, for + descending into subdirectories. It is a good fit when you know they + do not contain kernel-space objects at all. A typical usage is to let + Kbuild descend into subdirectories to build tools. + + Examples:: + + # scripts/Makefile + subdir-$(CONFIG_GCC_PLUGINS) += gcc-plugins + subdir-$(CONFIG_MODVERSIONS) += genksyms + subdir-$(CONFIG_SECURITY_SELINUX) += selinux + + Unlike obj-y/m, subdir-y/m does not need the trailing slash since this + syntax is always used for directories. + It is good practice to use a `CONFIG_` variable when assigning directory names. This allows kbuild to totally skip the directory if the corresponding `CONFIG_` option is neither 'y' nor 'm'. -3.7 Compilation flags +3.7 Non-builtin vmlinux targets - extra-y +----------------------------------------- + + extra-y specifies targets which are needed for building vmlinux, + but not combined into built-in.a. + + Examples are: + + 1) head objects + + Some objects must be placed at the head of vmlinux. They are + directly linked to vmlinux without going through built-in.a + A typical use-case is an object that contains the entry point. + + arch/$(SRCARCH)/Makefile should specify such objects as head-y. + + Discussion: + Given that we can control the section order in the linker script, + why do we need head-y? + + 2) vmlinux linker script + + The linker script for vmlinux is located at + arch/$(SRCARCH)/kernel/vmlinux.lds + + Example:: + + # arch/x86/kernel/Makefile + extra-y := head_$(BITS).o + extra-y += head$(BITS).o + extra-y += ebda.o + extra-y += platform-quirks.o + extra-y += vmlinux.lds + + $(extra-y) should only contain targets needed for vmlinux. + + Kbuild skips extra-y when vmlinux is apparently not a final goal. + (e.g. 'make modules', or building external modules) + + If you intend to build targets unconditionally, always-y (explained + in the next section) is the correct syntax to use. + +3.8 Always built goals - always-y +--------------------------------- + + always-y specifies targets which are literally always built when + Kbuild visits the Makefile. + + Example:: + # ./Kbuild + offsets-file := include/generated/asm-offsets.h + always-y += $(offsets-file) + +3.9 Compilation flags --------------------- ccflags-y, asflags-y and ldflags-y @@ -410,8 +480,8 @@ more details, with real examples. AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt -3.9 Dependency tracking ------------------------ +3.10 Dependency tracking +------------------------ Kbuild tracks dependencies on the following: @@ -422,21 +492,21 @@ more details, with real examples. Thus, if you change an option to $(CC) all affected files will be re-compiled. -3.10 Special Rules ------------------- +3.11 Custom Rules +----------------- - Special rules are used when the kbuild infrastructure does + Custom rules are used when the kbuild infrastructure does not provide the required support. A typical example is header files generated during the build process. Another example are the architecture-specific Makefiles which - need special rules to prepare boot images etc. + need custom rules to prepare boot images etc. - Special rules are written as normal Make rules. + Custom rules are written as normal Make rules. Kbuild is not executing in the directory where the Makefile is - located, so all special rules shall provide a relative + located, so all custom rules shall use a relative path to prerequisite files and target files. - Two variables are used when defining special rules: + Two variables are used when defining custom rules: $(src) $(src) is a relative path which points to the directory @@ -454,7 +524,7 @@ more details, with real examples. $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl $(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl - This is a special rule, following the normal syntax + This is a custom rule, following the normal syntax required by make. The target file depends on two prerequisite files. References @@ -471,13 +541,81 @@ more details, with real examples. Example:: - #arch/blackfin/boot/Makefile - $(obj)/vmImage: $(obj)/vmlinux.gz - $(call if_changed,uimage) - @$(kecho) 'Kernel: $@ is ready' + # arch/arm/Makefile + $(BOOT_TARGETS): vmlinux + $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@ + @$(kecho) ' Kernel: $(boot)/$@ is ready' + + When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand + of a command is normally displayed. + To enable this behaviour for custom commands kbuild requires + two variables to be set:: + + quiet_cmd_<command> - what shall be echoed + cmd_<command> - the command to execute + + Example:: + + # lib/Makefile + quiet_cmd_crc32 = GEN $@ + cmd_crc32 = $< > $@ + + $(obj)/crc32table.h: $(obj)/gen_crc32table + $(call cmd,crc32) + + When updating the $(obj)/crc32table.h target, the line: + + GEN lib/crc32table.h + + will be displayed with "make KBUILD_VERBOSE=0". + +3.12 Command change detection +----------------------------- + + When the rule is evaluated, timestamps are compared between the target + and its prerequisite files. GNU Make updates the target when any of the + prerequisites is newer than that. + + The target should be rebuilt also when the command line has changed + since the last invocation. This is not supported by Make itself, so + Kbuild achieves this by a kind of meta-programming. + + if_changed is the macro used for this purpose, in the following form:: + + quiet_cmd_<command> = ... + cmd_<command> = ... + + <target>: <source(s)> FORCE + $(call if_changed,<command>) + + Any target that utilizes if_changed must be listed in $(targets), + otherwise the command line check will fail, and the target will + always be built. + + If the target is already listed in the recognized syntax such as + obj-y/m, lib-y/m, extra-y/m, always-y/m, hostprogs, userprogs, Kbuild + automatically adds it to $(targets). Otherwise, the target must be + explicitly added to $(targets). + + Assignments to $(targets) are without $(obj)/ prefix. if_changed may be + used in conjunction with custom rules as defined in "3.11 Custom Rules". + + Note: It is a typical mistake to forget the FORCE prerequisite. + Another common pitfall is that whitespace is sometimes significant; for + instance, the below will fail (note the extra space after the comma):: + + target: source(s) FORCE + + **WRONG!** $(call if_changed, objcopy) + Note: + if_changed should not be used more than once per target. + It stores the executed command in a corresponding .cmd + file and multiple calls would result in overwrites and + unwanted results when the target is up to date and only the + tests on changed commands trigger execution of commands. -3.11 $(CC) support functions +3.13 $(CC) support functions ---------------------------- The kernel may be built with several different versions of @@ -592,7 +730,7 @@ more details, with real examples. endif endif -3.12 $(LD) support functions +3.14 $(LD) support functions ---------------------------- ld-option @@ -606,7 +744,7 @@ more details, with real examples. #Makefile LDFLAGS_vmlinux += $(call ld-option, -X) -3.13 Script invocation +3.15 Script invocation ---------------------- Make rules may invoke scripts to build the kernel. The rules shall @@ -744,7 +882,7 @@ Both possibilities are described in the following. as a prerequisite. This is possible in two ways: - (1) List the prerequisite explicitly in a special rule. + (1) List the prerequisite explicitly in a custom rule. Example:: @@ -755,11 +893,11 @@ Both possibilities are described in the following. The target $(obj)/devlist.h will not be built before $(obj)/gen-devlist is updated. Note that references to - the host programs in special rules must be prefixed with $(obj). + the host programs in custom rules must be prefixed with $(obj). (2) Use always-y - When there is no suitable special rule, and the host program + When there is no suitable custom rule, and the host program shall be built when a makefile is entered, the always-y variable shall be used. @@ -933,7 +1071,7 @@ When "make clean" is executed, make will descend down in arch/x86/boot, and clean as usual. The Makefile located in arch/x86/boot/ may use the subdir- trick to descend further down. -Note 1: arch/$(ARCH)/Makefile cannot use "subdir-", because that file is +Note 1: arch/$(SRCARCH)/Makefile cannot use "subdir-", because that file is included in the top level makefile, and the kbuild infrastructure is not operational at that point. @@ -946,9 +1084,9 @@ be visited during "make clean". The top level Makefile sets up the environment and does the preparation, before starting to descend down in the individual directories. The top level makefile contains the generic part, whereas -arch/$(ARCH)/Makefile contains what is required to set up kbuild +arch/$(SRCARCH)/Makefile contains what is required to set up kbuild for said architecture. -To do so, arch/$(ARCH)/Makefile sets up a number of variables and defines +To do so, arch/$(SRCARCH)/Makefile sets up a number of variables and defines a few targets. When kbuild executes, the following steps are followed (roughly): @@ -956,14 +1094,14 @@ When kbuild executes, the following steps are followed (roughly): 1) Configuration of the kernel => produce .config 2) Store kernel version in include/linux/version.h 3) Updating all other prerequisites to the target prepare: - - Additional prerequisites are specified in arch/$(ARCH)/Makefile + - Additional prerequisites are specified in arch/$(SRCARCH)/Makefile 4) Recursively descend down in all directories listed in init-* core* drivers-* net-* libs-* and build all targets. - - The values of the above variables are expanded in arch/$(ARCH)/Makefile. + - The values of the above variables are expanded in arch/$(SRCARCH)/Makefile. 5) All object files are then linked and the resulting file vmlinux is located at the root of the obj tree. The very first objects linked are listed in head-y, assigned by - arch/$(ARCH)/Makefile. + arch/$(SRCARCH)/Makefile. 6) Finally, the architecture-specific part does any required post processing and builds the final bootimage. - This includes building boot records @@ -1154,7 +1292,7 @@ When kbuild executes, the following steps are followed (roughly): machinery is all architecture-independent. - head-y, init-y, core-y, libs-y, drivers-y, net-y + head-y, core-y, libs-y, drivers-y $(head-y) lists objects to be linked first in vmlinux. $(libs-y) lists directories where a lib.a archive can be located. @@ -1162,23 +1300,24 @@ When kbuild executes, the following steps are followed (roughly): The rest list directories where a built-in.a object file can be located. - $(init-y) objects will be located after $(head-y). - Then the rest follows in this order: - $(core-y), $(libs-y), $(drivers-y) and $(net-y). + $(core-y), $(libs-y), $(drivers-y) The top level Makefile defines values for all generic directories, - and arch/$(ARCH)/Makefile only adds architecture-specific + and arch/$(SRCARCH)/Makefile only adds architecture-specific directories. Example:: - #arch/sparc64/Makefile - core-y += arch/sparc64/kernel/ - libs-y += arch/sparc64/prom/ arch/sparc64/lib/ - drivers-$(CONFIG_OPROFILE) += arch/sparc64/oprofile/ + # arch/sparc/Makefile + core-y += arch/sparc/ + + libs-y += arch/sparc/prom/ + libs-y += arch/sparc/lib/ + drivers-$(CONFIG_PM) += arch/sparc/power/ + drivers-$(CONFIG_OPROFILE) += arch/sparc/oprofile/ 7.5 Architecture-specific boot images ------------------------------------- @@ -1189,15 +1328,15 @@ When kbuild executes, the following steps are followed (roughly): The actual goals are not standardized across architectures. It is common to locate any additional processing in a boot/ - directory below arch/$(ARCH)/. + directory below arch/$(SRCARCH)/. Kbuild does not provide any smart way to support building a - target specified in boot/. Therefore arch/$(ARCH)/Makefile shall + target specified in boot/. Therefore arch/$(SRCARCH)/Makefile shall call make manually to build a target in boot/. The recommended approach is to include shortcuts in - arch/$(ARCH)/Makefile, and use the full path when calling down - into the arch/$(ARCH)/boot/Makefile. + arch/$(SRCARCH)/Makefile, and use the full path when calling down + into the arch/$(SRCARCH)/boot/Makefile. Example:: @@ -1217,7 +1356,7 @@ When kbuild executes, the following steps are followed (roughly): #arch/x86/Makefile define archhelp - echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)' + echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)' endif When make is executed without arguments, the first goal encountered @@ -1235,71 +1374,12 @@ When kbuild executes, the following steps are followed (roughly): When "make" is executed without arguments, bzImage will be built. -7.6 Building non-kbuild targets -------------------------------- - - extra-y - extra-y specifies additional targets created in the current - directory, in addition to any targets specified by `obj-*`. - - Listing all targets in extra-y is required for two purposes: - - 1) Enable kbuild to check changes in command lines - - - When $(call if_changed,xxx) is used - - 2) kbuild knows what files to delete during "make clean" - - Example:: - - #arch/x86/kernel/Makefile - extra-y := head.o init_task.o - - In this example, extra-y is used to list object files that - shall be built, but shall not be linked as part of built-in.a. - 7.7 Commands useful for building a boot image --------------------------------------------- Kbuild provides a few macros that are useful when building a boot image. - if_changed - if_changed is the infrastructure used for the following commands. - - Usage:: - - target: source(s) FORCE - $(call if_changed,ld/objcopy/gzip/...) - - When the rule is evaluated, it is checked to see if any files - need an update, or the command line has changed since the last - invocation. The latter will force a rebuild if any options - to the executable have changed. - Any target that utilises if_changed must be listed in $(targets), - otherwise the command line check will fail, and the target will - always be built. - Assignments to $(targets) are without $(obj)/ prefix. - if_changed may be used in conjunction with custom commands as - defined in 7.8 "Custom kbuild commands". - - Note: It is a typical mistake to forget the FORCE prerequisite. - Another common pitfall is that whitespace is sometimes - significant; for instance, the below will fail (note the extra space - after the comma):: - - target: source(s) FORCE - - **WRONG!** $(call if_changed, ld/objcopy/gzip/...) - - Note: - if_changed should not be used more than once per target. - It stores the executed command in a corresponding .cmd - - file and multiple calls would result in overwrites and - unwanted results when the target is up to date and only the - tests on changed commands trigger execution of commands. - ld Link target. Often, LDFLAGS_$@ is used to set specific options to ld. @@ -1332,7 +1412,7 @@ When kbuild executes, the following steps are followed (roughly): objcopy Copy binary. Uses OBJCOPYFLAGS usually specified in - arch/$(ARCH)/Makefile. + arch/$(SRCARCH)/Makefile. OBJCOPYFLAGS_$@ may be used to set additional options. gzip @@ -1361,41 +1441,11 @@ When kbuild executes, the following steps are followed (roughly): targets += $(dtb-y) DTC_FLAGS ?= -p 1024 -7.8 Custom kbuild commands --------------------------- - - When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand - of a command is normally displayed. - To enable this behaviour for custom commands kbuild requires - two variables to be set:: - - quiet_cmd_<command> - what shall be echoed - cmd_<command> - the command to execute - - Example:: - - # - quiet_cmd_image = BUILD $@ - cmd_image = $(obj)/tools/build $(BUILDFLAGS) \ - $(obj)/vmlinux.bin > $@ - - targets += bzImage - $(obj)/bzImage: $(obj)/vmlinux.bin $(obj)/tools/build FORCE - $(call if_changed,image) - @echo 'Kernel: $@ is ready' - - When updating the $(obj)/bzImage target, the line: - - BUILD arch/x86/boot/bzImage - - will be displayed with "make KBUILD_VERBOSE=0". - - 7.9 Preprocessing linker scripts -------------------------------- When the vmlinux image is built, the linker script - arch/$(ARCH)/kernel/vmlinux.lds is used. + arch/$(SRCARCH)/kernel/vmlinux.lds is used. The script is a preprocessed variant of the file vmlinux.lds.S located in the same directory. kbuild knows .lds files and includes a rule `*lds.S` -> `*lds`. @@ -1405,9 +1455,6 @@ When kbuild executes, the following steps are followed (roughly): #arch/x86/kernel/Makefile extra-y := vmlinux.lds - #Makefile - export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH) - The assignment to extra-y is used to tell kbuild to build the target vmlinux.lds. The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the @@ -1481,7 +1528,7 @@ See subsequent chapter for the syntax of the Kbuild file. If an architecture uses a verbatim copy of a header from include/asm-generic then this is listed in the file - arch/$(ARCH)/include/asm/Kbuild like this: + arch/$(SRCARCH)/include/asm/Kbuild like this: Example:: @@ -1492,7 +1539,7 @@ See subsequent chapter for the syntax of the Kbuild file. During the prepare phase of the build a wrapper include file is generated in the directory:: - arch/$(ARCH)/include/generated/asm + arch/$(SRCARCH)/include/generated/asm When a header is exported where the architecture uses the generic header a similar wrapper is generated as part @@ -1527,8 +1574,8 @@ See subsequent chapter for the syntax of the Kbuild file. to define the minimum set of ASM headers that all architectures must have. This works like optional generic-y. If a mandatory header is missing - in arch/$(ARCH)/include/(uapi/)/asm, Kbuild will automatically generate - a wrapper of the asm-generic one. + in arch/$(SRCARCH)/include/(uapi/)/asm, Kbuild will automatically + generate a wrapper of the asm-generic one. 9 Kbuild Variables ================== @@ -1564,6 +1611,16 @@ The top Makefile exports the following variables: make ARCH=m68k ... + SRCARCH + This variable specifies the directory in arch/ to build. + + ARCH and SRCARCH may not necessarily match. A couple of arch + directories are biarch, that is, a single `arch/*/` directory supports + both 32-bit and 64-bit. + + For example, you can pass in ARCH=i386, ARCH=x86_64, or ARCH=x86. + For all of them, SRCARCH=x86 because arch/x86/ supports both i386 and + x86_64. INSTALL_PATH This variable defines a place for the arch Makefiles to install diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst index 85ccc878895e..a1f3eb7a43e2 100644 --- a/Documentation/kbuild/modules.rst +++ b/Documentation/kbuild/modules.rst @@ -332,7 +332,7 @@ according to the following rule: There are two notable exceptions to this rule: larger subsystems have their own directory under include/, such as include/scsi; and architecture specific headers are located - under arch/$(ARCH)/include/. + under arch/$(SRCARCH)/include/. 4.1 Kernel Includes ------------------- diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst index 6ed806e6061b..c3448929a824 100644 --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -118,11 +118,11 @@ spinlock, but you may block holding a mutex. If you can't lock a mutex, your task will suspend itself, and be woken up when the mutex is released. This means the CPU can do something else while you are waiting. There are many cases when you simply can't sleep (see -`What Functions Are Safe To Call From Interrupts? <#sleeping-things>`__), +`What Functions Are Safe To Call From Interrupts?`_), and so have to use a spinlock instead. Neither type of lock is recursive: see -`Deadlock: Simple and Advanced <#deadlock>`__. +`Deadlock: Simple and Advanced`_. Locks and Uniprocessor Kernels ------------------------------ @@ -179,7 +179,7 @@ perfect world). Note that you can also use spin_lock_irq() or spin_lock_irqsave() here, which stop hardware interrupts -as well: see `Hard IRQ Context <#hard-irq-context>`__. +as well: see `Hard IRQ Context`_. This works perfectly for UP as well: the spin lock vanishes, and this macro simply becomes local_bh_disable() @@ -230,7 +230,7 @@ The Same Softirq ~~~~~~~~~~~~~~~~ The same softirq can run on the other CPUs: you can use a per-CPU array -(see `Per-CPU Data <#per-cpu-data>`__) for better performance. If you're +(see `Per-CPU Data`_) for better performance. If you're going so far as to use a softirq, you probably care about scalable performance enough to justify the extra complexity. diff --git a/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst index d5458da01083..14eb0a4d4e4e 100644 --- a/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst +++ b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst @@ -34,7 +34,7 @@ These resources should be specified in that order, as the ordering of the two address regions is important (the driver expects these to be address and then data). -An example from arch/arm/mach-s3c2410/mach-bast.c is:: +An example from arch/arm/mach-s3c/mach-bast.c is:: static struct resource bast_dm9k_resource[] = { [0] = { diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst index d3fcf536d14e..61e850460e18 100644 --- a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst @@ -164,46 +164,56 @@ Devlink health reporters NPA Reporters ------------- -The NPA reporters are responsible for reporting and recovering the following group of errors +The NPA reporters are responsible for reporting and recovering the following group of errors: + 1. GENERAL events + - Error due to operation of unmapped PF. - Error due to disabled alloc/free for other HW blocks (NIX, SSO, TIM, DPI and AURA). + 2. ERROR events + - Fault due to NPA_AQ_INST_S read or NPA_AQ_RES_S write. - AQ Doorbell Error. + 3. RAS events + - RAS Error Reporting for NPA_AQ_INST_S/NPA_AQ_RES_S. + 4. RVU events + - Error due to unmapped slot. -Sample Output -------------- -~# devlink health -pci/0002:01:00.0: - reporter hw_npa_intr - state healthy error 2872 recover 2872 last_dump_date 2020-12-10 last_dump_time 09:39:09 grace_period 0 auto_recover true auto_dump true - reporter hw_npa_gen - state healthy error 2872 recover 2872 last_dump_date 2020-12-11 last_dump_time 04:43:04 grace_period 0 auto_recover true auto_dump true - reporter hw_npa_err - state healthy error 2871 recover 2871 last_dump_date 2020-12-10 last_dump_time 09:39:17 grace_period 0 auto_recover true auto_dump true - reporter hw_npa_ras - state healthy error 0 recover 0 last_dump_date 2020-12-10 last_dump_time 09:32:40 grace_period 0 auto_recover true auto_dump true +Sample Output:: + + ~# devlink health + pci/0002:01:00.0: + reporter hw_npa_intr + state healthy error 2872 recover 2872 last_dump_date 2020-12-10 last_dump_time 09:39:09 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_gen + state healthy error 2872 recover 2872 last_dump_date 2020-12-11 last_dump_time 04:43:04 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_err + state healthy error 2871 recover 2871 last_dump_date 2020-12-10 last_dump_time 09:39:17 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_ras + state healthy error 0 recover 0 last_dump_date 2020-12-10 last_dump_time 09:32:40 grace_period 0 auto_recover true auto_dump true Each reporter dumps the + - Error Type - Error Register value - Reason in words -For eg: -~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_gen - NPA_AF_GENERAL: - NPA General Interrupt Reg : 1 - NIX0: free disabled RX -~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_intr - NPA_AF_RVU: - NPA RVU Interrupt Reg : 1 - Unmap Slot Error -~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_err - NPA_AF_ERR: - NPA Error Interrupt Reg : 4096 - AQ Doorbell Error +For example:: + + ~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_gen + NPA_AF_GENERAL: + NPA General Interrupt Reg : 1 + NIX0: free disabled RX + ~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_intr + NPA_AF_RVU: + NPA RVU Interrupt Reg : 1 + Unmap Slot Error + ~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_err + NPA_AF_ERR: + NPA Error Interrupt Reg : 4096 + AQ Doorbell Error diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 4b9ed5874d5a..ae2ae37cd921 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -6,9 +6,9 @@ netdev FAQ ========== -Q: What is netdev? ------------------- -A: It is a mailing list for all network-related Linux stuff. This +What is netdev? +--------------- +It is a mailing list for all network-related Linux stuff. This includes anything found under net/ (i.e. core code like IPv6) and drivers/net (i.e. hardware specific drivers) in the Linux source tree. @@ -25,9 +25,9 @@ Aside from subsystems like that mentioned above, all network-related Linux development (i.e. RFC, review, comments, etc.) takes place on netdev. -Q: How do the changes posted to netdev make their way into Linux? ------------------------------------------------------------------ -A: There are always two trees (git repositories) in play. Both are +How do the changes posted to netdev make their way into Linux? +-------------------------------------------------------------- +There are always two trees (git repositories) in play. Both are driven by David Miller, the main network maintainer. There is the ``net`` tree, and the ``net-next`` tree. As you can probably guess from the names, the ``net`` tree is for fixes to existing code already in the @@ -37,9 +37,9 @@ for the future release. You can find the trees here: - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git -Q: How often do changes from these trees make it to the mainline Linus tree? ----------------------------------------------------------------------------- -A: To understand this, you need to know a bit of background information on +How often do changes from these trees make it to the mainline Linus tree? +------------------------------------------------------------------------- +To understand this, you need to know a bit of background information on the cadence of Linux development. Each new release starts off with a two week "merge window" where the main maintainers feed their new stuff to Linus for merging into the mainline tree. After the two weeks, the @@ -81,7 +81,8 @@ focus for ``net`` is on stabilization and bug fixes. Finally, the vX.Y gets released, and the whole cycle starts over. -Q: So where are we now in this cycle? +So where are we now in this cycle? +---------------------------------- Load the mainline (Linus) page here: @@ -91,9 +92,9 @@ and note the top of the "tags" section. If it is rc1, it is early in the dev cycle. If it was tagged rc7 a week ago, then a release is probably imminent. -Q: How do I indicate which tree (net vs. net-next) my patch should be in? -------------------------------------------------------------------------- -A: Firstly, think whether you have a bug fix or new "next-like" content. +How do I indicate which tree (net vs. net-next) my patch should be in? +---------------------------------------------------------------------- +Firstly, think whether you have a bug fix or new "next-like" content. Then once decided, assuming that you use git, use the prefix flag, i.e. :: @@ -105,48 +106,45 @@ in the above is just the subject text of the outgoing e-mail, and you can manually change it yourself with whatever MUA you are comfortable with. -Q: I sent a patch and I'm wondering what happened to it? --------------------------------------------------------- -Q: How can I tell whether it got merged? -A: Start by looking at the main patchworks queue for netdev: +I sent a patch and I'm wondering what happened to it - how can I tell whether it got merged? +-------------------------------------------------------------------------------------------- +Start by looking at the main patchworks queue for netdev: https://patchwork.kernel.org/project/netdevbpf/list/ The "State" field will tell you exactly where things are at with your patch. -Q: The above only says "Under Review". How can I find out more? ----------------------------------------------------------------- -A: Generally speaking, the patches get triaged quickly (in less than +The above only says "Under Review". How can I find out more? +------------------------------------------------------------- +Generally speaking, the patches get triaged quickly (in less than 48h). So be patient. Asking the maintainer for status updates on your patch is a good way to ensure your patch is ignored or pushed to the bottom of the priority list. -Q: I submitted multiple versions of the patch series ----------------------------------------------------- -Q: should I directly update patchwork for the previous versions of these -patch series? -A: No, please don't interfere with the patch status on patchwork, leave +I submitted multiple versions of the patch series. Should I directly update patchwork for the previous versions of these patch series? +-------------------------------------------------------------------------------------------------------------------------------------- +No, please don't interfere with the patch status on patchwork, leave it to the maintainer to figure out what is the most recent and current version that should be applied. If there is any doubt, the maintainer will reply and ask what should be done. -Q: I made changes to only a few patches in a patch series should I resend only those changed? ---------------------------------------------------------------------------------------------- -A: No, please resend the entire patch series and make sure you do number your +I made changes to only a few patches in a patch series should I resend only those changed? +------------------------------------------------------------------------------------------ +No, please resend the entire patch series and make sure you do number your patches such that it is clear this is the latest and greatest set of patches that can be applied. -Q: I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do? -------------------------------------------------------------------------------------------------------------------------------------------- -A: There is no revert possible, once it is pushed out, it stays like that. +I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do? +---------------------------------------------------------------------------------------------------------------------------------------- +There is no revert possible, once it is pushed out, it stays like that. Please send incremental versions on top of what has been merged in order to fix the patches the way they would look like if your latest patch series was to be merged. -Q: How can I tell what patches are queued up for backporting to the various stable releases? --------------------------------------------------------------------------------------------- -A: Normally Greg Kroah-Hartman collects stable commits himself, but for +How can I tell what patches are queued up for backporting to the various stable releases? +----------------------------------------------------------------------------------------- +Normally Greg Kroah-Hartman collects stable commits himself, but for networking, Dave collects up patches he deems critical for the networking subsystem, and then hands them off to Greg. @@ -169,11 +167,9 @@ simply clone the repo, and then git grep the mainline commit ID, e.g. releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch stable/stable-queue$ -Q: I see a network patch and I think it should be backported to stable. ------------------------------------------------------------------------ -Q: Should I request it via stable@vger.kernel.org like the references in -the kernel's Documentation/process/stable-kernel-rules.rst file say? -A: No, not for networking. Check the stable queues as per above first +I see a network patch and I think it should be backported to stable. Should I request it via stable@vger.kernel.org like the references in the kernel's Documentation/process/stable-kernel-rules.rst file say? +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +No, not for networking. Check the stable queues as per above first to see if it is already queued. If not, then send a mail to netdev, listing the upstream commit ID and why you think it should be a stable candidate. @@ -190,11 +186,9 @@ mainline, the better the odds that it is an OK candidate for stable. So scrambling to request a commit be added the day after it appears should be avoided. -Q: I have created a network patch and I think it should be backported to stable. --------------------------------------------------------------------------------- -Q: Should I add a Cc: stable@vger.kernel.org like the references in the -kernel's Documentation/ directory say? -A: No. See above answer. In short, if you think it really belongs in +I have created a network patch and I think it should be backported to stable. Should I add a Cc: stable@vger.kernel.org like the references in the kernel's Documentation/ directory say? +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +No. See above answer. In short, if you think it really belongs in stable, then ensure you write a decent commit log that describes who gets impacted by the bug fix and how it manifests itself, and when the bug was introduced. If you do that properly, then the commit will get @@ -207,18 +201,18 @@ marker line as described in :ref:`Documentation/process/submitting-patches.rst <the_canonical_patch_format>` to temporarily embed that information into the patch that you send. -Q: Are all networking bug fixes backported to all stable releases? ------------------------------------------------------------------- -A: Due to capacity, Dave could only take care of the backports for the +Are all networking bug fixes backported to all stable releases? +--------------------------------------------------------------- +Due to capacity, Dave could only take care of the backports for the last two stable releases. For earlier stable releases, each stable branch maintainer is supposed to take care of them. If you find any patch is missing from an earlier stable branch, please notify stable@vger.kernel.org with either a commit ID or a formal patch backported, and CC Dave and other relevant networking developers. -Q: Is the comment style convention different for the networking content? ------------------------------------------------------------------------- -A: Yes, in a largely trivial way. Instead of this:: +Is the comment style convention different for the networking content? +--------------------------------------------------------------------- +Yes, in a largely trivial way. Instead of this:: /* * foobar blah blah blah @@ -231,32 +225,30 @@ it is requested that you make it look like this:: * another line of text */ -Q: I am working in existing code that has the former comment style and not the latter. --------------------------------------------------------------------------------------- -Q: Should I submit new code in the former style or the latter? -A: Make it the latter style, so that eventually all code in the domain +I am working in existing code that has the former comment style and not the latter. Should I submit new code in the former style or the latter? +----------------------------------------------------------------------------------------------------------------------------------------------- +Make it the latter style, so that eventually all code in the domain of netdev is of this format. -Q: I found a bug that might have possible security implications or similar. ---------------------------------------------------------------------------- -Q: Should I mail the main netdev maintainer off-list?** -A: No. The current netdev maintainer has consistently requested that +I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list? +--------------------------------------------------------------------------------------------------------------------------- +No. The current netdev maintainer has consistently requested that people use the mailing lists and not reach out directly. If you aren't OK with that, then perhaps consider mailing security@kernel.org or reading about http://oss-security.openwall.org/wiki/mailing-lists/distros as possible alternative mechanisms. -Q: What level of testing is expected before I submit my change? ---------------------------------------------------------------- -A: If your changes are against ``net-next``, the expectation is that you +What level of testing is expected before I submit my change? +------------------------------------------------------------ +If your changes are against ``net-next``, the expectation is that you have tested by layering your changes on top of ``net-next``. Ideally you will have done run-time testing specific to your change, but at a minimum, your changes should survive an ``allyesconfig`` and an ``allmodconfig`` build without new warnings or failures. -Q: How do I post corresponding changes to user space components? ----------------------------------------------------------------- -A: User space code exercising kernel features should be posted +How do I post corresponding changes to user space components? +------------------------------------------------------------- +User space code exercising kernel features should be posted alongside kernel patches. This gives reviewers a chance to see how any new interface is used and how well it works. @@ -280,9 +272,9 @@ to the mailing list, e.g.:: Posting as one thread is discouraged because it confuses patchwork (as of patchwork 2.2.2). -Q: Any other tips to help ensure my net/net-next patch gets OK'd? ------------------------------------------------------------------ -A: Attention to detail. Re-read your own work as if you were the +Any other tips to help ensure my net/net-next patch gets OK'd? +-------------------------------------------------------------- +Attention to detail. Re-read your own work as if you were the reviewer. You can start with using ``checkpatch.pl``, perhaps even with the ``--strict`` flag. But do not be mindlessly robotic in doing so. If your change is a bug fix, make sure your commit log indicates the diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index 5a85fcc80c76..17bdcb746dcf 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -10,18 +10,177 @@ Introduction The following is a random collection of documentation regarding network devices. -struct net_device allocation rules -================================== +struct net_device lifetime rules +================================ Network device structures need to persist even after module is unloaded and must be allocated with alloc_netdev_mqs() and friends. If device has registered successfully, it will be freed on last use -by free_netdev(). This is required to handle the pathologic case cleanly -(example: rmmod mydriver </sys/class/net/myeth/mtu ) +by free_netdev(). This is required to handle the pathological case cleanly +(example: ``rmmod mydriver </sys/class/net/myeth/mtu``) -alloc_netdev_mqs()/alloc_netdev() reserve extra space for driver +alloc_netdev_mqs() / alloc_netdev() reserve extra space for driver private data which gets freed when the network device is freed. If separately allocated data is attached to the network device -(netdev_priv(dev)) then it is up to the module exit handler to free that. +(netdev_priv()) then it is up to the module exit handler to free that. + +There are two groups of APIs for registering struct net_device. +First group can be used in normal contexts where ``rtnl_lock`` is not already +held: register_netdev(), unregister_netdev(). +Second group can be used when ``rtnl_lock`` is already held: +register_netdevice(), unregister_netdevice(), free_netdevice(). + +Simple drivers +-------------- + +Most drivers (especially device drivers) handle lifetime of struct net_device +in context where ``rtnl_lock`` is not held (e.g. driver probe and remove paths). + +In that case the struct net_device registration is done using +the register_netdev(), and unregister_netdev() functions: + +.. code-block:: c + + int probe() + { + struct my_device_priv *priv; + int err; + + dev = alloc_netdev_mqs(...); + if (!dev) + return -ENOMEM; + priv = netdev_priv(dev); + + /* ... do all device setup before calling register_netdev() ... + */ + + err = register_netdev(dev); + if (err) + goto err_undo; + + /* net_device is visible to the user! */ + + err_undo: + /* ... undo the device setup ... */ + free_netdev(dev); + return err; + } + + void remove() + { + unregister_netdev(dev); + free_netdev(dev); + } + +Note that after calling register_netdev() the device is visible in the system. +Users can open it and start sending / receiving traffic immediately, +or run any other callback, so all initialization must be done prior to +registration. + +unregister_netdev() closes the device and waits for all users to be done +with it. The memory of struct net_device itself may still be referenced +by sysfs but all operations on that device will fail. + +free_netdev() can be called after unregister_netdev() returns on when +register_netdev() failed. + +Device management under RTNL +---------------------------- + +Registering struct net_device while in context which already holds +the ``rtnl_lock`` requires extra care. In those scenarios most drivers +will want to make use of struct net_device's ``needs_free_netdev`` +and ``priv_destructor`` members for freeing of state. + +Example flow of netdev handling under ``rtnl_lock``: + +.. code-block:: c + + static void my_setup(struct net_device *dev) + { + dev->needs_free_netdev = true; + } + + static void my_destructor(struct net_device *dev) + { + some_obj_destroy(priv->obj); + some_uninit(priv); + } + + int create_link() + { + struct my_device_priv *priv; + int err; + + ASSERT_RTNL(); + + dev = alloc_netdev(sizeof(*priv), "net%d", NET_NAME_UNKNOWN, my_setup); + if (!dev) + return -ENOMEM; + priv = netdev_priv(dev); + + /* Implicit constructor */ + err = some_init(priv); + if (err) + goto err_free_dev; + + priv->obj = some_obj_create(); + if (!priv->obj) { + err = -ENOMEM; + goto err_some_uninit; + } + /* End of constructor, set the destructor: */ + dev->priv_destructor = my_destructor; + + err = register_netdevice(dev); + if (err) + /* register_netdevice() calls destructor on failure */ + goto err_free_dev; + + /* If anything fails now unregister_netdevice() (or unregister_netdev()) + * will take care of calling my_destructor and free_netdev(). + */ + + return 0; + + err_some_uninit: + some_uninit(priv); + err_free_dev: + free_netdev(dev); + return err; + } + +If struct net_device.priv_destructor is set it will be called by the core +some time after unregister_netdevice(), it will also be called if +register_netdevice() fails. The callback may be invoked with or without +``rtnl_lock`` held. + +There is no explicit constructor callback, driver "constructs" the private +netdev state after allocating it and before registration. + +Setting struct net_device.needs_free_netdev makes core call free_netdevice() +automatically after unregister_netdevice() when all references to the device +are gone. It only takes effect after a successful call to register_netdevice() +so if register_netdevice() fails driver is responsible for calling +free_netdev(). + +free_netdev() is safe to call on error paths right after unregister_netdevice() +or when register_netdevice() fails. Parts of netdev (de)registration process +happen after ``rtnl_lock`` is released, therefore in those cases free_netdev() +will defer some of the processing until ``rtnl_lock`` is released. + +Devices spawned from struct rtnl_link_ops should never free the +struct net_device directly. + +.ndo_init and .ndo_uninit +~~~~~~~~~~~~~~~~~~~~~~~~~ + +``.ndo_init`` and ``.ndo_uninit`` callbacks are called during net_device +registration and de-registration, under ``rtnl_lock``. Drivers can use +those e.g. when parts of their init process need to run under ``rtnl_lock``. + +``.ndo_init`` runs before device is visible in the system, ``.ndo_uninit`` +runs during de-registering after device is closed but other subsystems +may still have outstanding references to the netdevice. MTU === @@ -64,8 +223,8 @@ ndo_do_ioctl: Context: process ndo_get_stats: - Synchronization: dev_base_lock rwlock. - Context: nominally process, but don't sleep inside an rwlock + Synchronization: rtnl_lock() semaphore, dev_base_lock rwlock, or RCU. + Context: atomic (can't sleep under rwlock or RCU) ndo_start_xmit: Synchronization: __netif_tx_lock spinlock. diff --git a/Documentation/networking/packet_mmap.rst b/Documentation/networking/packet_mmap.rst index 6c009ceb1183..500ef60b1b82 100644 --- a/Documentation/networking/packet_mmap.rst +++ b/Documentation/networking/packet_mmap.rst @@ -8,7 +8,7 @@ Abstract ======== This file documents the mmap() facility available with the PACKET -socket interface on 2.4/2.6/3.x kernels. This type of sockets is used for +socket interface. This type of sockets is used for i) capture network traffic with utilities like tcpdump, ii) transmit network traffic, or any other that needs raw @@ -25,12 +25,12 @@ Please send your comments to Why use PACKET_MMAP =================== -In Linux 2.4/2.6/3.x if PACKET_MMAP is not enabled, the capture process is very +Non PACKET_MMAP capture process (plain AF_PACKET) is very inefficient. It uses very limited buffers and requires one system call to capture each packet, it requires two if you want to get packet's timestamp (like libpcap always does). -In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size +On the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size configurable circular buffer mapped in user space that can be used to either send or receive packets. This way reading packets just needs to wait for them, most of the time there is no need to issue a single system call. Concerning @@ -252,8 +252,7 @@ PACKET_MMAP setting constraints In kernel versions prior to 2.4.26 (for the 2.4 branch) and 2.6.5 (2.6 branch), the PACKET_MMAP buffer could hold only 32768 frames in a 32 bit architecture or -16384 in a 64 bit architecture. For information on these kernel versions -see http://pusa.uv.es/~ulisses/packet_mmap/packet_mmap.pre-2.4.26_2.6.5.txt +16384 in a 64 bit architecture. Block size limit ---------------- @@ -437,7 +436,7 @@ and the following flags apply: Capture process ^^^^^^^^^^^^^^^ - from include/linux/if_packet.h +From include/linux/if_packet.h:: #define TP_STATUS_COPY (1 << 1) #define TP_STATUS_LOSING (1 << 2) diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst index 0f55c6d540f9..5f0dea3d571e 100644 --- a/Documentation/networking/tls-offload.rst +++ b/Documentation/networking/tls-offload.rst @@ -530,7 +530,10 @@ TLS device feature flags only control adding of new TLS connection offloads, old connections will remain active after flags are cleared. TLS encryption cannot be offloaded to devices without checksum calculation -offload. Hence, TLS TX device feature flag requires NETIF_F_HW_CSUM being set. +offload. Hence, TLS TX device feature flag requires TX csum offload being set. Disabling the latter implies clearing the former. Disabling TX checksum offload should not affect old connections, and drivers should make sure checksum calculation does not break for them. +Similarly, device-offloaded TLS decryption implies doing RXCSUM. If the user +does not want to enable RX csum offload, TLS RX device feature is disabled +as well. diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst index c27e59d2f702..0825dc496f22 100644 --- a/Documentation/process/4.Coding.rst +++ b/Documentation/process/4.Coding.rst @@ -249,10 +249,8 @@ features; most of these are found in the "kernel hacking" submenu. Several of these options should be turned on for any kernel used for development or testing purposes. In particular, you should turn on: - - ENABLE_MUST_CHECK and FRAME_WARN to get an - extra set of warnings for problems like the use of deprecated interfaces - or ignoring an important return value from a function. The output - generated by these warnings can be verbose, but one need not worry about + - FRAME_WARN to get warnings for stack frames larger than a given amount. + The output generated can be verbose, but one need not worry about warnings from other parts of the kernel. - DEBUG_OBJECTS will add code to track the lifetime of various objects diff --git a/Documentation/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst index 1879f881c300..230ee42f872f 100644 --- a/Documentation/process/submit-checklist.rst +++ b/Documentation/process/submit-checklist.rst @@ -75,44 +75,44 @@ and elsewhere regarding submitting Linux kernel patches. 13) Has been build- and runtime tested with and without ``CONFIG_SMP`` and ``CONFIG_PREEMPT.`` -16) All codepaths have been exercised with all lockdep features enabled. +14) All codepaths have been exercised with all lockdep features enabled. -17) All new ``/proc`` entries are documented under ``Documentation/`` +15) All new ``/proc`` entries are documented under ``Documentation/`` -18) All new kernel boot parameters are documented in +16) All new kernel boot parameters are documented in ``Documentation/admin-guide/kernel-parameters.rst``. -19) All new module parameters are documented with ``MODULE_PARM_DESC()`` +17) All new module parameters are documented with ``MODULE_PARM_DESC()`` -20) All new userspace interfaces are documented in ``Documentation/ABI/``. +18) All new userspace interfaces are documented in ``Documentation/ABI/``. See ``Documentation/ABI/README`` for more information. Patches that change userspace interfaces should be CCed to linux-api@vger.kernel.org. -21) Check that it all passes ``make headers_check``. +19) Check that it all passes ``make headers_check``. -22) Has been checked with injection of at least slab and page-allocation +20) Has been checked with injection of at least slab and page-allocation failures. See ``Documentation/fault-injection/``. If the new code is substantial, addition of subsystem-specific fault injection might be appropriate. -23) Newly-added code has been compiled with ``gcc -W`` (use +21) Newly-added code has been compiled with ``gcc -W`` (use ``make EXTRA_CFLAGS=-W``). This will generate lots of noise, but is good for finding bugs like "warning: comparison between signed and unsigned". -24) Tested after it has been merged into the -mm patchset to make sure +22) Tested after it has been merged into the -mm patchset to make sure that it still works with all of the other queued patches and various changes in the VM, VFS, and other subsystems. -25) All memory barriers {e.g., ``barrier()``, ``rmb()``, ``wmb()``} need a +23) All memory barriers {e.g., ``barrier()``, ``rmb()``, ``wmb()``} need a comment in the source code that explains the logic of what they are doing and why. -26) If any ioctl's are added by the patch, then also update +24) If any ioctl's are added by the patch, then also update ``Documentation/userspace-api/ioctl/ioctl-number.rst``. -27) If your modified source code depends on or uses any of the kernel +25) If your modified source code depends on or uses any of the kernel APIs or features that are related to the following ``Kconfig`` symbols, then test multiple builds with the related ``Kconfig`` symbols disabled and/or ``=m`` (if that option is available) [not all of these at the diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index fb8261a4be30..5ba54120bef7 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -411,6 +411,12 @@ Some people also put extra tags at the end. They'll just be ignored for now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. +Any further SoBs (Signed-off-by:'s) following the author's SoB are from +people handling and transporting the patch, but were not involved in its +development. SoB chains should reflect the **real** route a patch took +as it was propagated to the maintainers and ultimately to Linus, with +the first SoB entry signalling primary authorship of a single author. + When to use Acked-by:, Cc:, and Co-developed-by: ------------------------------------------------ @@ -446,7 +452,7 @@ patch. This tag documents that potentially interested parties have been included in the discussion. Co-developed-by: states that the patch was co-created by multiple developers; -it is a used to give attribution to co-authors (in addition to the author +it is used to give attribution to co-authors (in addition to the author attributed by the From: tag) when several people work on a single patch. Since Co-developed-by: denotes authorship, every Co-developed-by: must be immediately followed by a Signed-off-by: of the associated co-author. Standard sign-off diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index fe52c314b763..b36af65a08ed 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -1501,7 +1501,7 @@ Module for Digigram miXart8 sound cards. This module supports multiple cards. Note: One miXart8 board will be represented as 4 alsa cards. -See MIXART.txt for details. +See Documentation/sound/cards/mixart.rst for details. When the driver is compiled as a module and the hotplug firmware is supported, the firmware data is loaded via hotplug automatically. diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 73bbd59afc33..e6365836fa8b 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -71,7 +71,7 @@ core/oss The codes for PCM and mixer OSS emulation modules are stored in this directory. The rawmidi OSS emulation is included in the ALSA rawmidi code since it's quite small. The sequencer code is stored in -``core/seq/oss`` directory (see `below <#core-seq-oss>`__). +``core/seq/oss`` directory (see `below <core/seq/oss_>`__). core/seq ~~~~~~~~ @@ -382,7 +382,7 @@ where ``enable[dev]`` is the module option. Each time the ``probe`` callback is called, check the availability of the device. If not available, simply increment the device index and returns. dev will be incremented also later (`step 7 -<#set-the-pci-driver-data-and-return-zero>`__). +<7) Set the PCI driver data and return zero._>`__). 2) Create a card instance ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -450,10 +450,10 @@ field contains the information shown in ``/proc/asound/cards``. 5) Create other components, such as mixer, MIDI, etc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Here you define the basic components such as `PCM <#PCM-Interface>`__, -mixer (e.g. `AC97 <#API-for-AC97-Codec>`__), MIDI (e.g. -`MPU-401 <#MIDI-MPU401-UART-Interface>`__), and other interfaces. -Also, if you want a `proc file <#Proc-Interface>`__, define it here, +Here you define the basic components such as `PCM <PCM Interface_>`__, +mixer (e.g. `AC97 <API for AC97 Codec_>`__), MIDI (e.g. +`MPU-401 <MIDI (MPU401-UART) Interface_>`__), and other interfaces. +Also, if you want a `proc file <Proc Interface_>`__, define it here, too. 6) Register the card instance. @@ -941,7 +941,7 @@ The allocation of an interrupt source is done like this: chip->irq = pci->irq; where :c:func:`snd_mychip_interrupt()` is the interrupt handler -defined `later <#pcm-interface-interrupt-handler>`__. Note that +defined `later <PCM Interrupt Handler_>`__. Note that ``chip->irq`` should be defined only when :c:func:`request_irq()` succeeded. @@ -3104,7 +3104,7 @@ processing the output stream in the irq handler. If the MPU-401 interface shares its interrupt with the other logical devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see -`below <#MIDI-Interrupt-Handler>`__). +`below <MIDI Interrupt Handler_>`__). Usually, the port address corresponds to the command port and port + 1 corresponds to the data port. If not, you may change the ``cport`` diff --git a/Documentation/sphinx/parse-headers.pl b/Documentation/sphinx/parse-headers.pl index 1910079f984f..b063f2f1cfb2 100755 --- a/Documentation/sphinx/parse-headers.pl +++ b/Documentation/sphinx/parse-headers.pl @@ -1,4 +1,4 @@ -#!/usr/bin/perl +#!/usr/bin/env perl use strict; use Text::Tabs; use Getopt::Long; diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py index 1548d8420499..54492aa813b9 100755 --- a/Documentation/target/tcm_mod_builder.py +++ b/Documentation/target/tcm_mod_builder.py @@ -1,4 +1,4 @@ -#!/usr/bin/python +#!/usr/bin/env python # The TCM v4 multi-protocol fabric module generation script for drivers/target/$NEW_MOD # # Copyright (c) 2010 Rising Tide Systems diff --git a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst index a4955f7e3d19..f7d98ae5b885 100644 --- a/Documentation/trace/ftrace-uses.rst +++ b/Documentation/trace/ftrace-uses.rst @@ -30,8 +30,8 @@ The ftrace context This requires extra care to what can be done inside a callback. A callback can be called outside the protective scope of RCU. -The ftrace infrastructure has some protections against recursions and RCU -but one must still be very careful how they use the callbacks. +There are helper functions to help against recursion, and making sure +RCU is watching. These are explained below. The ftrace_ops structure @@ -108,6 +108,58 @@ The prototype of the callback function is as follows (as of v4.14): at the start of the function where ftrace was tracing. Otherwise it either contains garbage, or NULL. +Protect your callback +===================== + +As functions can be called from anywhere, and it is possible that a function +called by a callback may also be traced, and call that same callback, +recursion protection must be used. There are two helper functions that +can help in this regard. If you start your code with: + +.. code-block:: c + + int bit; + + bit = ftrace_test_recursion_trylock(ip, parent_ip); + if (bit < 0) + return; + +and end it with: + +.. code-block:: c + + ftrace_test_recursion_unlock(bit); + +The code in between will be safe to use, even if it ends up calling a +function that the callback is tracing. Note, on success, +ftrace_test_recursion_trylock() will disable preemption, and the +ftrace_test_recursion_unlock() will enable it again (if it was previously +enabled). The instruction pointer (ip) and its parent (parent_ip) is passed to +ftrace_test_recursion_trylock() to record where the recursion happened +(if CONFIG_FTRACE_RECORD_RECURSION is set). + +Alternatively, if the FTRACE_OPS_FL_RECURSION flag is set on the ftrace_ops +(as explained below), then a helper trampoline will be used to test +for recursion for the callback and no recursion test needs to be done. +But this is at the expense of a slightly more overhead from an extra +function call. + +If your callback accesses any data or critical section that requires RCU +protection, it is best to make sure that RCU is "watching", otherwise +that data or critical section will not be protected as expected. In this +case add: + +.. code-block:: c + + if (!rcu_is_watching()) + return; + +Alternatively, if the FTRACE_OPS_FL_RCU flag is set on the ftrace_ops +(as explained below), then a helper trampoline will be used to test +for rcu_is_watching for the callback and no other test needs to be done. +But this is at the expense of a slightly more overhead from an extra +function call. + The ftrace FLAGS ================ @@ -128,26 +180,20 @@ FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED will not fail with this flag set. But the callback must check if regs is NULL or not to determine if the architecture supports it. -FTRACE_OPS_FL_RECURSION_SAFE - By default, a wrapper is added around the callback to - make sure that recursion of the function does not occur. That is, - if a function that is called as a result of the callback's execution - is also traced, ftrace will prevent the callback from being called - again. But this wrapper adds some overhead, and if the callback is - safe from recursion, it can set this flag to disable the ftrace - protection. - - Note, if this flag is set, and recursion does occur, it could cause - the system to crash, and possibly reboot via a triple fault. - - It is OK if another callback traces a function that is called by a - callback that is marked recursion safe. Recursion safe callbacks - must never trace any function that are called by the callback - itself or any nested functions that those functions call. - - If this flag is set, it is possible that the callback will also - be called with preemption enabled (when CONFIG_PREEMPTION is set), - but this is not guaranteed. +FTRACE_OPS_FL_RECURSION + By default, it is expected that the callback can handle recursion. + But if the callback is not that worried about overehead, then + setting this bit will add the recursion protection around the + callback by calling a helper function that will do the recursion + protection and only call the callback if it did not recurse. + + Note, if this flag is not set, and recursion does occur, it could + cause the system to crash, and possibly reboot via a triple fault. + + Not, if this flag is set, then the callback will always be called + with preemption disabled. If it is not set, then it is possible + (but not guaranteed) that the callback will be called in + preemptable context. FTRACE_OPS_FL_IPMODIFY Requires FTRACE_OPS_FL_SAVE_REGS set. If the callback is to "hijack" diff --git a/Documentation/trace/postprocess/decode_msr.py b/Documentation/trace/postprocess/decode_msr.py index 0ab40e0db580..aa9cc7abd5c2 100644 --- a/Documentation/trace/postprocess/decode_msr.py +++ b/Documentation/trace/postprocess/decode_msr.py @@ -1,4 +1,4 @@ -#!/usr/bin/python +#!/usr/bin/env python # add symbolic names to read_msr / write_msr in trace # decode_msr msr-index.h < trace import sys diff --git a/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl b/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl index 0a120aae33ce..b9b7d80c2f9d 100644 --- a/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl +++ b/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl @@ -1,4 +1,4 @@ -#!/usr/bin/perl +#!/usr/bin/env perl # This is a POC (proof of concept or piece of crap, take your pick) for reading the # text representation of trace output related to page allocation. It makes an attempt # to extract some high-level information on what is going on. The accuracy of the parser diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl index 995da15b16ca..2f4e39875fb3 100644 --- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -1,4 +1,4 @@ -#!/usr/bin/perl +#!/usr/bin/env perl # This is a POC for reading the text representation of trace output related to # page reclaim. It makes an attempt to extract some high-level information on # what is going on. The accuracy of the parser may vary diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index e00a66d72372..99ceb978c8b0 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -262,6 +262,18 @@ The KVM_RUN ioctl (cf.) communicates with userspace via a shared memory region. This ioctl returns the size of that region. See the KVM_RUN documentation for details. +Besides the size of the KVM_RUN communication region, other areas of +the VCPU file descriptor can be mmap-ed, including: + +- if KVM_CAP_COALESCED_MMIO is available, a page at + KVM_COALESCED_MMIO_PAGE_OFFSET * PAGE_SIZE; for historical reasons, + this page is included in the result of KVM_GET_VCPU_MMAP_SIZE. + KVM_CAP_COALESCED_MMIO is not documented yet. + +- if KVM_CAP_DIRTY_LOG_RING is available, a number of pages at + KVM_DIRTY_LOG_PAGE_OFFSET * PAGE_SIZE. For more information on + KVM_CAP_DIRTY_LOG_RING, see section 8.3. + 4.6 KVM_SET_MEMORY_REGION ------------------------- @@ -348,10 +360,9 @@ since the last call to this ioctl. Bit 0 is the first page in the memory slot. Ensure the entire structure is cleared to avoid padding issues. -If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 specifies -the address space for which you want to return the dirty bitmap. -They must be less than the value that KVM_CHECK_EXTENSION returns for -the KVM_CAP_MULTI_ADDRESS_SPACE capability. +If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of slot field specifies +the address space for which you want to return the dirty bitmap. See +KVM_SET_USER_MEMORY_REGION for details on the usage of slot field. The bits in the dirty bitmap are cleared before the ioctl returns, unless KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is enabled. For more information, @@ -380,9 +391,14 @@ This ioctl is obsolete and has been removed. Errors: - ===== ============================= + ======= ============================================================== EINTR an unmasked signal is pending - ===== ============================= + ENOEXEC the vcpu hasn't been initialized or the guest tried to execute + instructions from device memory (arm64) + ENOSYS data abort outside memslots with no syndrome info and + KVM_CAP_ARM_NISV_TO_USER not enabled (arm64) + EPERM SVE feature set but not finalized (arm64) + ======= ============================================================== This ioctl is used to run a guest virtual cpu. While there are no explicit parameters, there is an implicit parameter block that can be @@ -1264,6 +1280,9 @@ field userspace_addr, which must point at user addressable memory for the entire memory slot size. Any object may back this memory, including anonymous memory, ordinary files, and hugetlbfs. +On architectures that support a form of address tagging, userspace_addr must +be an untagged address. + It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr be identical. This allows large pages in the guest to be backed by large pages in the host. @@ -1316,7 +1335,7 @@ documentation when it pops into existence). :Capability: KVM_CAP_ENABLE_CAP_VM :Architectures: all -:Type: vcpu ioctl +:Type: vm ioctl :Parameters: struct kvm_enable_cap (in) :Returns: 0 on success; -1 on error @@ -4415,7 +4434,7 @@ to I/O ports. :Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 :Architectures: x86, arm, arm64, mips :Type: vm ioctl -:Parameters: struct kvm_dirty_log (in) +:Parameters: struct kvm_clear_dirty_log (in) :Returns: 0 on success, -1 on error :: @@ -4442,10 +4461,9 @@ in KVM's dirty bitmap, and dirty tracking is re-enabled for that page (for example via write-protection, or by clearing the dirty bit in a page table entry). -If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 specifies -the address space for which you want to return the dirty bitmap. -They must be less than the value that KVM_CHECK_EXTENSION returns for -the KVM_CAP_MULTI_ADDRESS_SPACE capability. +If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of slot field specifies +the address space for which you want to clear the dirty status. See +KVM_SET_USER_MEMORY_REGION for details on the usage of slot field. This ioctl is mostly useful when KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is enabled; for more information, see the description of the capability. @@ -4455,9 +4473,9 @@ that KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is present. 4.118 KVM_GET_SUPPORTED_HV_CPUID -------------------------------- -:Capability: KVM_CAP_HYPERV_CPUID +:Capability: KVM_CAP_HYPERV_CPUID (vcpu), KVM_CAP_SYS_HYPERV_CPUID (system) :Architectures: x86 -:Type: vcpu ioctl +:Type: system ioctl, vcpu ioctl :Parameters: struct kvm_cpuid2 (in/out) :Returns: 0 on success, -1 on error @@ -4502,9 +4520,6 @@ Currently, the following list of CPUID leaves are returned: - HYPERV_CPUID_SYNDBG_INTERFACE - HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES -HYPERV_CPUID_NESTED_FEATURES leaf is only exposed when Enlightened VMCS was -enabled on the corresponding vCPU (KVM_CAP_HYPERV_ENLIGHTENED_VMCS). - Userspace invokes KVM_GET_SUPPORTED_HV_CPUID by passing a kvm_cpuid2 structure with the 'nent' field indicating the number of entries in the variable-size array 'entries'. If the number of entries is too low to describe all Hyper-V @@ -4515,6 +4530,15 @@ number of valid entries in the 'entries' array, which is then filled. 'index' and 'flags' fields in 'struct kvm_cpuid_entry2' are currently reserved, userspace should not expect to get any particular value there. +Note, vcpu version of KVM_GET_SUPPORTED_HV_CPUID is currently deprecated. Unlike +system ioctl which exposes all supported feature bits unconditionally, vcpu +version has the following quirks: +- HYPERV_CPUID_NESTED_FEATURES leaf and HV_X64_ENLIGHTENED_VMCS_RECOMMENDED + feature bit are only exposed when Enlightened VMCS was previously enabled + on the corresponding vCPU (KVM_CAP_HYPERV_ENLIGHTENED_VMCS). +- HV_STIMER_DIRECT_MODE_AVAILABLE bit is only exposed with in-kernel LAPIC. + (presumes KVM_CREATE_IRQCHIP has already been called). + 4.119 KVM_ARM_VCPU_FINALIZE --------------------------- @@ -6390,3 +6414,91 @@ When enabled, KVM will disable paravirtual features provided to the guest according to the bits in the KVM_CPUID_FEATURES CPUID leaf (0x40000001). Otherwise, a guest may use the paravirtual features regardless of what has actually been exposed through the CPUID leaf. + + +8.29 KVM_CAP_DIRTY_LOG_RING +--------------------------- + +:Architectures: x86 +:Parameters: args[0] - size of the dirty log ring + +KVM is capable of tracking dirty memory using ring buffers that are +mmaped into userspace; there is one dirty ring per vcpu. + +The dirty ring is available to userspace as an array of +``struct kvm_dirty_gfn``. Each dirty entry it's defined as:: + + struct kvm_dirty_gfn { + __u32 flags; + __u32 slot; /* as_id | slot_id */ + __u64 offset; + }; + +The following values are defined for the flags field to define the +current state of the entry:: + + #define KVM_DIRTY_GFN_F_DIRTY BIT(0) + #define KVM_DIRTY_GFN_F_RESET BIT(1) + #define KVM_DIRTY_GFN_F_MASK 0x3 + +Userspace should call KVM_ENABLE_CAP ioctl right after KVM_CREATE_VM +ioctl to enable this capability for the new guest and set the size of +the rings. Enabling the capability is only allowed before creating any +vCPU, and the size of the ring must be a power of two. The larger the +ring buffer, the less likely the ring is full and the VM is forced to +exit to userspace. The optimal size depends on the workload, but it is +recommended that it be at least 64 KiB (4096 entries). + +Just like for dirty page bitmaps, the buffer tracks writes to +all user memory regions for which the KVM_MEM_LOG_DIRTY_PAGES flag was +set in KVM_SET_USER_MEMORY_REGION. Once a memory region is registered +with the flag set, userspace can start harvesting dirty pages from the +ring buffer. + +An entry in the ring buffer can be unused (flag bits ``00``), +dirty (flag bits ``01``) or harvested (flag bits ``1X``). The +state machine for the entry is as follows:: + + dirtied harvested reset + 00 -----------> 01 -------------> 1X -------+ + ^ | + | | + +------------------------------------------+ + +To harvest the dirty pages, userspace accesses the mmaped ring buffer +to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage +the RESET bit must be cleared), then it means this GFN is a dirty GFN. +The userspace should harvest this GFN and mark the flags from state +``01b`` to ``1Xb`` (bit 0 will be ignored by KVM, but bit 1 must be set +to show that this GFN is harvested and waiting for a reset), and move +on to the next GFN. The userspace should continue to do this until the +flags of a GFN have the DIRTY bit cleared, meaning that it has harvested +all the dirty GFNs that were available. + +It's not necessary for userspace to harvest the all dirty GFNs at once. +However it must collect the dirty GFNs in sequence, i.e., the userspace +program cannot skip one dirty GFN to collect the one next to it. + +After processing one or more entries in the ring buffer, userspace +calls the VM ioctl KVM_RESET_DIRTY_RINGS to notify the kernel about +it, so that the kernel will reprotect those collected GFNs. +Therefore, the ioctl must be called *before* reading the content of +the dirty pages. + +The dirty ring can get full. When it happens, the KVM_RUN of the +vcpu will return with exit reason KVM_EXIT_DIRTY_LOG_FULL. + +The dirty ring interface has a major difference comparing to the +KVM_GET_DIRTY_LOG interface in that, when reading the dirty ring from +userspace, it's still possible that the kernel has not yet flushed the +processor's dirty page buffers into the kernel buffer (with dirty bitmaps, the +flushing is done by the KVM_GET_DIRTY_LOG ioctl). To achieve that, one +needs to kick the vcpu out of KVM_RUN using a signal. The resulting +vmexit ensures that all dirty GFNs are flushed to the dirty rings. + +NOTE: the capability KVM_CAP_DIRTY_LOG_RING and the corresponding +ioctl KVM_RESET_DIRTY_RINGS are mutual exclusive to the existing ioctls +KVM_GET_DIRTY_LOG and KVM_CLEAR_DIRTY_LOG. After enabling +KVM_CAP_DIRTY_LOG_RING with an acceptable dirty ring size, the virtual +machine will switch to ring-buffer dirty page tracking and further +KVM_GET_DIRTY_LOG or KVM_CLEAR_DIRTY_LOG ioctls will fail. diff --git a/Documentation/virt/kvm/arm/pvtime.rst b/Documentation/virt/kvm/arm/pvtime.rst index 687b60d76ca9..392521af7c90 100644 --- a/Documentation/virt/kvm/arm/pvtime.rst +++ b/Documentation/virt/kvm/arm/pvtime.rst @@ -19,8 +19,8 @@ Two new SMCCC compatible hypercalls are defined: These are only available in the SMC64/HVC64 calling convention as paravirtualized time is not available to 32 bit Arm guests. The existence of -the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES -mechanism before calling it. +the PV_TIME_FEATURES hypercall should be probed using the SMCCC 1.1 +ARCH_FEATURES mechanism before calling it. PV_TIME_FEATURES ============= ======== ========== |