diff options
Diffstat (limited to 'Documentation')
76 files changed, 3850 insertions, 772 deletions
diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index 5e23e22dce1b..b77e30b9014e 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -114,15 +114,60 @@ Description: Access: Read Valid values: Represented in microamps +What: /sys/class/power_supply/<supply_name>/charge_control_limit +Date: Oct 2012 +Contact: linux-pm@vger.kernel.org +Description: + Maximum allowable charging current. Used for charge rate + throttling for thermal cooling or improving battery health. + + Access: Read, Write + Valid values: Represented in microamps + +What: /sys/class/power_supply/<supply_name>/charge_control_limit_max +Date: Oct 2012 +Contact: linux-pm@vger.kernel.org +Description: + Maximum legal value for the charge_control_limit property. + + Access: Read + Valid values: Represented in microamps + +What: /sys/class/power_supply/<supply_name>/charge_control_start_threshold +Date: April 2019 +Contact: linux-pm@vger.kernel.org +Description: + Represents a battery percentage level, below which charging will + begin. + + Access: Read, Write + Valid values: 0 - 100 (percent) + +What: /sys/class/power_supply/<supply_name>/charge_control_end_threshold +Date: April 2019 +Contact: linux-pm@vger.kernel.org +Description: + Represents a battery percentage level, above which charging will + stop. + + Access: Read, Write + Valid values: 0 - 100 (percent) + What: /sys/class/power_supply/<supply_name>/charge_type Date: July 2009 Contact: linux-pm@vger.kernel.org Description: Represents the type of charging currently being applied to the - battery. + battery. "Trickle", "Fast", and "Standard" all mean different + charging speeds. "Adaptive" means that the charger uses some + algorithm to adjust the charge rate dynamically, without + any user configuration required. "Custom" means that the charger + uses the charge_control_* properties as configuration for some + different algorithm. - Access: Read - Valid values: "Unknown", "N/A", "Trickle", "Fast" + Access: Read, Write + Valid values: "Unknown", "N/A", "Trickle", "Fast", "Standard", + "Adaptive", "Custom" What: /sys/class/power_supply/<supply_name>/charge_term_current Date: July 2014 diff --git a/Documentation/accounting/psi.txt b/Documentation/accounting/psi.txt index 7e71c9c1d8e9..5cbe5659e3b7 100644 --- a/Documentation/accounting/psi.txt +++ b/Documentation/accounting/psi.txt @@ -63,6 +63,110 @@ as well as medium and long term trends. The total absolute stall time spikes which wouldn't necessarily make a dent in the time averages, or to average trends over custom time frames. +Monitoring for pressure thresholds +================================== + +Users can register triggers and use poll() to be woken up when resource +pressure exceeds certain thresholds. + +A trigger describes the maximum cumulative stall time over a specific +time window, e.g. 100ms of total stall time within any 500ms window to +generate a wakeup event. + +To register a trigger user has to open psi interface file under +/proc/pressure/ representing the resource to be monitored and write the +desired threshold and time window. The open file descriptor should be +used to wait for trigger events using select(), poll() or epoll(). +The following format is used: + +<some|full> <stall amount in us> <time window in us> + +For example writing "some 150000 1000000" into /proc/pressure/memory +would add 150ms threshold for partial memory stall measured within +1sec time window. Writing "full 50000 1000000" into /proc/pressure/io +would add 50ms threshold for full io stall measured within 1sec time window. + +Triggers can be set on more than one psi metric and more than one trigger +for the same psi metric can be specified. However for each trigger a separate +file descriptor is required to be able to poll it separately from others, +therefore for each trigger a separate open() syscall should be made even +when opening the same psi interface file. + +Monitors activate only when system enters stall state for the monitored +psi metric and deactivates upon exit from the stall state. While system is +in the stall state psi signal growth is monitored at a rate of 10 times per +tracking window. + +The kernel accepts window sizes ranging from 500ms to 10s, therefore min +monitoring update interval is 50ms and max is 1s. Min limit is set to +prevent overly frequent polling. Max limit is chosen as a high enough number +after which monitors are most likely not needed and psi averages can be used +instead. + +When activated, psi monitor stays active for at least the duration of one +tracking window to avoid repeated activations/deactivations when system is +bouncing in and out of the stall state. + +Notifications to the userspace are rate-limited to one per tracking window. + +The trigger will de-register when the file descriptor used to define the +trigger is closed. + +Userspace monitor usage example +=============================== + +#include <errno.h> +#include <fcntl.h> +#include <stdio.h> +#include <poll.h> +#include <string.h> +#include <unistd.h> + +/* + * Monitor memory partial stall with 1s tracking window size + * and 150ms threshold. + */ +int main() { + const char trig[] = "some 150000 1000000"; + struct pollfd fds; + int n; + + fds.fd = open("/proc/pressure/memory", O_RDWR | O_NONBLOCK); + if (fds.fd < 0) { + printf("/proc/pressure/memory open error: %s\n", + strerror(errno)); + return 1; + } + fds.events = POLLPRI; + + if (write(fds.fd, trig, strlen(trig) + 1) < 0) { + printf("/proc/pressure/memory write error: %s\n", + strerror(errno)); + return 1; + } + + printf("waiting for events...\n"); + while (1) { + n = poll(&fds, 1, -1); + if (n < 0) { + printf("poll error: %s\n", strerror(errno)); + return 1; + } + if (fds.revents & POLLERR) { + printf("got POLLERR, event source is gone\n"); + return 0; + } + if (fds.revents & POLLPRI) { + printf("event triggered!\n"); + } else { + printf("unknown event received: 0x%x\n", fds.revents); + return 1; + } + } + + return 0; +} + Cgroup2 interface ================= @@ -71,3 +175,6 @@ mounted, pressure stall information is also tracked for tasks grouped into cgroups. Each subdirectory in the cgroupfs mountpoint contains cpu.pressure, memory.pressure, and io.pressure files; the format is the same as the /proc/pressure/ files. + +Per-cgroup psi monitors can be specified and used the same way as +system-wide ones. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 43176340c73d..138f6664b2e2 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1830,6 +1830,9 @@ ip= [IP_PNP] See Documentation/filesystems/nfs/nfsroot.txt. + ipcmni_extend [KNL] Extend the maximum number of unique System V + IPC identifiers from 32,768 to 16,777,216. + irqaffinity= [SMP] Set the default irq affinity mask The argument is a cpu list, as described above. @@ -3174,6 +3177,16 @@ This will also cause panics on machine check exceptions. Useful together with panic=30 to trigger a reboot. + page_alloc.shuffle= + [KNL] Boolean flag to control whether the page allocator + should randomize its free lists. The randomization may + be automatically enabled if the kernel detects it is + running on a platform with a direct-mapped memory-side + cache, and this parameter can be used to + override/disable that behavior. The state of the flag + can be read from sysfs at: + /sys/module/page_alloc/parameters/shuffle. + page_owner= [KNL] Boot-time page_owner enabling option. Storage of the information about who allocated each page is disabled in default. With this switch, @@ -3199,6 +3212,7 @@ bit 2: print timer info bit 3: print locks info if CONFIG_LOCKDEP is on bit 4: print ftrace buffer + bit 5: print all printk messages in buffer panic_on_warn panic() instead of WARN(). Useful to cause kdump on a WARN(). @@ -4054,7 +4068,9 @@ [[,]s[mp]#### \ [[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \ [[,]f[orce] - Where reboot_mode is one of warm (soft) or cold (hard) or gpio, + Where reboot_mode is one of warm (soft) or cold (hard) or gpio + (prefix with 'panic_' to set mode for panic + reboot only), reboot_type is one of bios, acpi, kbd, triple, efi, or pci, reboot_force is either force or not specified, reboot_cpu is s[mp]#### with #### being the processor @@ -5245,6 +5261,13 @@ with /sys/devices/system/xen_memory/xen_memory0/scrub_pages. Default value controlled with CONFIG_XEN_SCRUB_PAGES_DEFAULT. + xen_timer_slop= [X86-64,XEN] + Set the timer slop (in nanoseconds) for the virtual Xen + timers (default is 100000). This adjusts the minimum + delta of virtualized Xen timers, where lower values + improve timer resolution at the expense of processing + more timer interrupts. + xirc2ps_cs= [NET,PCMCIA] Format: <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]] diff --git a/Documentation/arm64/perf.txt b/Documentation/arm64/perf.txt new file mode 100644 index 000000000000..0d6a7d87d49e --- /dev/null +++ b/Documentation/arm64/perf.txt @@ -0,0 +1,85 @@ +Perf Event Attributes +===================== + +Author: Andrew Murray <andrew.murray@arm.com> +Date: 2019-03-06 + +exclude_user +------------ + +This attribute excludes userspace. + +Userspace always runs at EL0 and thus this attribute will exclude EL0. + + +exclude_kernel +-------------- + +This attribute excludes the kernel. + +The kernel runs at EL2 with VHE and EL1 without. Guest kernels always run +at EL1. + +For the host this attribute will exclude EL1 and additionally EL2 on a VHE +system. + +For the guest this attribute will exclude EL1. Please note that EL2 is +never counted within a guest. + + +exclude_hv +---------- + +This attribute excludes the hypervisor. + +For a VHE host this attribute is ignored as we consider the host kernel to +be the hypervisor. + +For a non-VHE host this attribute will exclude EL2 as we consider the +hypervisor to be any code that runs at EL2 which is predominantly used for +guest/host transitions. + +For the guest this attribute has no effect. Please note that EL2 is +never counted within a guest. + + +exclude_host / exclude_guest +---------------------------- + +These attributes exclude the KVM host and guest, respectively. + +The KVM host may run at EL0 (userspace), EL1 (non-VHE kernel) and EL2 (VHE +kernel or non-VHE hypervisor). + +The KVM guest may run at EL0 (userspace) and EL1 (kernel). + +Due to the overlapping exception levels between host and guests we cannot +exclusively rely on the PMU's hardware exception filtering - therefore we +must enable/disable counting on the entry and exit to the guest. This is +performed differently on VHE and non-VHE systems. + +For non-VHE systems we exclude EL2 for exclude_host - upon entering and +exiting the guest we disable/enable the event as appropriate based on the +exclude_host and exclude_guest attributes. + +For VHE systems we exclude EL1 for exclude_guest and exclude both EL0,EL2 +for exclude_host. Upon entering and exiting the guest we modify the event +to include/exclude EL0 as appropriate based on the exclude_host and +exclude_guest attributes. + +The statements above also apply when these attributes are used within a +non-VHE guest however please note that EL2 is never counted within a guest. + + +Accuracy +-------- + +On non-VHE hosts we enable/disable counters on the entry/exit of host/guest +transition at EL2 - however there is a period of time between +enabling/disabling the counters and entering/exiting the guest. We are +able to eliminate counters counting host events on the boundaries of guest +entry/exit when counting guest events by filtering out EL2 for +exclude_host. However when using !exclude_hv there is a small blackout +window at the guest entry/exit where host events are not captured. + +On VHE systems there are no blackout windows. diff --git a/Documentation/arm64/pointer-authentication.txt b/Documentation/arm64/pointer-authentication.txt index 5baca42ba146..fc71b33de87e 100644 --- a/Documentation/arm64/pointer-authentication.txt +++ b/Documentation/arm64/pointer-authentication.txt @@ -87,7 +87,21 @@ used to get and set the keys for a thread. Virtualization -------------- -Pointer authentication is not currently supported in KVM guests. KVM -will mask the feature bits from ID_AA64ISAR1_EL1, and attempted use of -the feature will result in an UNDEFINED exception being injected into -the guest. +Pointer authentication is enabled in KVM guest when each virtual cpu is +initialised by passing flags KVM_ARM_VCPU_PTRAUTH_[ADDRESS/GENERIC] and +requesting these two separate cpu features to be enabled. The current KVM +guest implementation works by enabling both features together, so both +these userspace flags are checked before enabling pointer authentication. +The separate userspace flag will allow to have no userspace ABI changes +if support is added in the future to allow these two features to be +enabled independently of one another. + +As Arm Architecture specifies that Pointer Authentication feature is +implemented along with the VHE feature so KVM arm64 ptrauth code relies +on VHE mode to be present. + +Additionally, when these vcpu feature flags are not set then KVM will +filter out the Pointer Authentication system key registers from +KVM_GET/SET_REG_* ioctls and mask those features from cpufeature ID +register. Any attempt to use the Pointer Authentication instructions will +result in an UNDEFINED exception being injected into the guest. diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 71f5d2fe39b7..a29c99d13331 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -147,10 +147,10 @@ Division Functions .. kernel-doc:: include/linux/math64.h :internal: -.. kernel-doc:: lib/div64.c +.. kernel-doc:: lib/math/div64.c :functions: div_s64_rem div64_u64_rem div64_u64 div64_s64 -.. kernel-doc:: lib/gcd.c +.. kernel-doc:: lib/math/gcd.c :export: UUID/GUID diff --git a/Documentation/dev-tools/gcov.rst b/Documentation/dev-tools/gcov.rst index 69a7d90c320a..46aae52a41d0 100644 --- a/Documentation/dev-tools/gcov.rst +++ b/Documentation/dev-tools/gcov.rst @@ -34,10 +34,6 @@ Configure the kernel with:: CONFIG_DEBUG_FS=y CONFIG_GCOV_KERNEL=y -select the gcc's gcov format, default is autodetect based on gcc version:: - - CONFIG_GCOV_FORMAT_AUTODETECT=y - and to get coverage data for the entire kernel:: CONFIG_GCOV_PROFILE_ALL=y @@ -169,6 +165,20 @@ b) gcov is run on the BUILD machine [user@build] gcov -o /tmp/coverage/tmp/out/init main.c +Note on compilers +----------------- + +GCC and LLVM gcov tools are not necessarily compatible. Use gcov_ to work with +GCC-generated .gcno and .gcda files, and use llvm-cov_ for Clang. + +.. _gcov: http://gcc.gnu.org/onlinedocs/gcc/Gcov.html +.. _llvm-cov: https://llvm.org/docs/CommandGuide/llvm-cov.html + +Build differences between GCC and Clang gcov are handled by Kconfig. It +automatically selects the appropriate gcov format depending on the detected +toolchain. + + Troubleshooting --------------- diff --git a/Documentation/device-mapper/dm-dust.txt b/Documentation/device-mapper/dm-dust.txt new file mode 100644 index 000000000000..954d402a1f6a --- /dev/null +++ b/Documentation/device-mapper/dm-dust.txt @@ -0,0 +1,272 @@ +dm-dust +======= + +This target emulates the behavior of bad sectors at arbitrary +locations, and the ability to enable the emulation of the failures +at an arbitrary time. + +This target behaves similarly to a linear target. At a given time, +the user can send a message to the target to start failing read +requests on specific blocks (to emulate the behavior of a hard disk +drive with bad sectors). + +When the failure behavior is enabled (i.e.: when the output of +"dmsetup status" displays "fail_read_on_bad_block"), reads of blocks +in the "bad block list" will fail with EIO ("Input/output error"). + +Writes of blocks in the "bad block list will result in the following: + +1. Remove the block from the "bad block list". +2. Successfully complete the write. + +This emulates the "remapped sector" behavior of a drive with bad +sectors. + +Normally, a drive that is encountering bad sectors will most likely +encounter more bad sectors, at an unknown time or location. +With dm-dust, the user can use the "addbadblock" and "removebadblock" +messages to add arbitrary bad blocks at new locations, and the +"enable" and "disable" messages to modulate the state of whether the +configured "bad blocks" will be treated as bad, or bypassed. +This allows the pre-writing of test data and metadata prior to +simulating a "failure" event where bad sectors start to appear. + +Table parameters: +----------------- +<device_path> <offset> <blksz> + +Mandatory parameters: + <device_path>: path to the block device. + <offset>: offset to data area from start of device_path + <blksz>: block size in bytes + (minimum 512, maximum 1073741824, must be a power of 2) + +Usage instructions: +------------------- + +First, find the size (in 512-byte sectors) of the device to be used: + +$ sudo blockdev --getsz /dev/vdb1 +33552384 + +Create the dm-dust device: +(For a device with a block size of 512 bytes) +$ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 512' + +(For a device with a block size of 4096 bytes) +$ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 4096' + +Check the status of the read behavior ("bypass" indicates that all I/O +will be passed through to the underlying device): +$ sudo dmsetup status dust1 +0 33552384 dust 252:17 bypass + +$ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=128 iflag=direct +128+0 records in +128+0 records out + +$ sudo dd if=/dev/zero of=/dev/mapper/dust1 bs=512 count=128 oflag=direct +128+0 records in +128+0 records out + +Adding and removing bad blocks: +------------------------------- + +At any time (i.e.: whether the device has the "bad block" emulation +enabled or disabled), bad blocks may be added or removed from the +device via the "addbadblock" and "removebadblock" messages: + +$ sudo dmsetup message dust1 0 addbadblock 60 +kernel: device-mapper: dust: badblock added at block 60 + +$ sudo dmsetup message dust1 0 addbadblock 67 +kernel: device-mapper: dust: badblock added at block 67 + +$ sudo dmsetup message dust1 0 addbadblock 72 +kernel: device-mapper: dust: badblock added at block 72 + +These bad blocks will be stored in the "bad block list". +While the device is in "bypass" mode, reads and writes will succeed: + +$ sudo dmsetup status dust1 +0 33552384 dust 252:17 bypass + +Enabling block read failures: +----------------------------- + +To enable the "fail read on bad block" behavior, send the "enable" message: + +$ sudo dmsetup message dust1 0 enable +kernel: device-mapper: dust: enabling read failures on bad sectors + +$ sudo dmsetup status dust1 +0 33552384 dust 252:17 fail_read_on_bad_block + +With the device in "fail read on bad block" mode, attempting to read a +block will encounter an "Input/output error": + +$ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=1 skip=67 iflag=direct +dd: error reading '/dev/mapper/dust1': Input/output error +0+0 records in +0+0 records out +0 bytes copied, 0.00040651 s, 0.0 kB/s + +...and writing to the bad blocks will remove the blocks from the list, +therefore emulating the "remap" behavior of hard disk drives: + +$ sudo dd if=/dev/zero of=/dev/mapper/dust1 bs=512 count=128 oflag=direct +128+0 records in +128+0 records out + +kernel: device-mapper: dust: block 60 removed from badblocklist by write +kernel: device-mapper: dust: block 67 removed from badblocklist by write +kernel: device-mapper: dust: block 72 removed from badblocklist by write +kernel: device-mapper: dust: block 87 removed from badblocklist by write + +Bad block add/remove error handling: +------------------------------------ + +Attempting to add a bad block that already exists in the list will +result in an "Invalid argument" error, as well as a helpful message: + +$ sudo dmsetup message dust1 0 addbadblock 88 +device-mapper: message ioctl on dust1 failed: Invalid argument +kernel: device-mapper: dust: block 88 already in badblocklist + +Attempting to remove a bad block that doesn't exist in the list will +result in an "Invalid argument" error, as well as a helpful message: + +$ sudo dmsetup message dust1 0 removebadblock 87 +device-mapper: message ioctl on dust1 failed: Invalid argument +kernel: device-mapper: dust: block 87 not found in badblocklist + +Counting the number of bad blocks in the bad block list: +-------------------------------------------------------- + +To count the number of bad blocks configured in the device, run the +following message command: + +$ sudo dmsetup message dust1 0 countbadblocks + +A message will print with the number of bad blocks currently +configured on the device: + +kernel: device-mapper: dust: countbadblocks: 895 badblock(s) found + +Querying for specific bad blocks: +--------------------------------- + +To find out if a specific block is in the bad block list, run the +following message command: + +$ sudo dmsetup message dust1 0 queryblock 72 + +The following message will print if the block is in the list: +device-mapper: dust: queryblock: block 72 found in badblocklist + +The following message will print if the block is in the list: +device-mapper: dust: queryblock: block 72 not found in badblocklist + +The "queryblock" message command will work in both the "enabled" +and "disabled" modes, allowing the verification of whether a block +will be treated as "bad" without having to issue I/O to the device, +or having to "enable" the bad block emulation. + +Clearing the bad block list: +---------------------------- + +To clear the bad block list (without needing to individually run +a "removebadblock" message command for every block), run the +following message command: + +$ sudo dmsetup message dust1 0 clearbadblocks + +After clearing the bad block list, the following message will appear: + +kernel: device-mapper: dust: clearbadblocks: badblocks cleared + +If there were no bad blocks to clear, the following message will +appear: + +kernel: device-mapper: dust: clearbadblocks: no badblocks found + +Message commands list: +---------------------- + +Below is a list of the messages that can be sent to a dust device: + +Operations on blocks (requires a <blknum> argument): + +addbadblock <blknum> +queryblock <blknum> +removebadblock <blknum> + +...where <blknum> is a block number within range of the device + (corresponding to the block size of the device.) + +Single argument message commands: + +countbadblocks +clearbadblocks +disable +enable +quiet + +Device removal: +--------------- + +When finished, remove the device via the "dmsetup remove" command: + +$ sudo dmsetup remove dust1 + +Quiet mode: +----------- + +On test runs with many bad blocks, it may be desirable to avoid +excessive logging (from bad blocks added, removed, or "remapped"). +This can be done by enabling "quiet mode" via the following message: + +$ sudo dmsetup message dust1 0 quiet + +This will suppress log messages from add / remove / removed by write +operations. Log messages from "countbadblocks" or "queryblock" +message commands will still print in quiet mode. + +The status of quiet mode can be seen by running "dmsetup status": + +$ sudo dmsetup status dust1 +0 33552384 dust 252:17 fail_read_on_bad_block quiet + +To disable quiet mode, send the "quiet" message again: + +$ sudo dmsetup message dust1 0 quiet + +$ sudo dmsetup status dust1 +0 33552384 dust 252:17 fail_read_on_bad_block verbose + +(The presence of "verbose" indicates normal logging.) + +"Why not...?" +------------- + +scsi_debug has a "medium error" mode that can fail reads on one +specified sector (sector 0x1234, hardcoded in the source code), but +it uses RAM for the persistent storage, which drastically decreases +the potential device size. + +dm-flakey fails all I/O from all block locations at a specified time +frequency, and not a given point in time. + +When a bad sector occurs on a hard disk drive, reads to that sector +are failed by the device, usually resulting in an error code of EIO +("I/O error") or ENODATA ("No data available"). However, a write to +the sector may succeed, and result in the sector becoming readable +after the device controller no longer experiences errors reading the +sector (or after a reallocation of the sector). However, there may +be bad sectors that occur on the device in the future, in a different, +unpredictable location. + +This target seeks to provide a device that can exhibit the behavior +of a bad sector at a known sector location, at a known time, based +on a large storage device (at least tens of gigabytes, not occupying +system memory). diff --git a/Documentation/device-mapper/dm-integrity.txt b/Documentation/device-mapper/dm-integrity.txt index 297251b0d2d5..d63d78ffeb73 100644 --- a/Documentation/device-mapper/dm-integrity.txt +++ b/Documentation/device-mapper/dm-integrity.txt @@ -21,6 +21,13 @@ mode it calculates and verifies the integrity tag internally. In this mode, the dm-integrity target can be used to detect silent data corruption on the disk or in the I/O path. +There's an alternate mode of operation where dm-integrity uses bitmap +instead of a journal. If a bit in the bitmap is 1, the corresponding +region's data and integrity tags are not synchronized - if the machine +crashes, the unsynchronized regions will be recalculated. The bitmap mode +is faster than the journal mode, because we don't have to write the data +twice, but it is also less reliable, because if data corruption happens +when the machine crashes, it may not be detected. When loading the target for the first time, the kernel driver will format the device. But it will only format the device if the superblock contains @@ -59,6 +66,10 @@ Target arguments: either both data and tag or none of them are written. The journaled mode degrades write throughput twice because the data have to be written twice. + B - bitmap mode - data and metadata are written without any + synchronization, the driver maintains a bitmap of dirty + regions where data and metadata don't match. This mode can + only be used with internal hash. R - recovery mode - in this mode, journal is not replayed, checksums are not checked and writes to the device are not allowed. This mode is useful for data recovery if the @@ -79,6 +90,10 @@ interleave_sectors:number a power of two. If the device is already formatted, the value from the superblock is used. +meta_device:device + Don't interleave the data and metadata on on device. Use a + separate device for metadata. + buffer_sectors:number The number of sectors in one buffer. The value is rounded down to a power of two. @@ -146,6 +161,15 @@ block_size:number Supported values are 512, 1024, 2048 and 4096 bytes. If not specified the default block size is 512 bytes. +sectors_per_bit:number + In the bitmap mode, this parameter specifies the number of + 512-byte sectors that corresponds to one bitmap bit. + +bitmap_flush_interval:number + The bitmap flush interval in milliseconds. The metadata buffers + are synchronized when this interval expires. + + The journal mode (D/J), buffer_sectors, journal_watermark, commit_time can be changed when reloading the target (load an inactive table and swap the tables with suspend and resume). The other arguments should not be changed @@ -167,7 +191,13 @@ The layout of the formatted block device: provides (i.e. the size of the device minus the size of all metadata and padding). The user of this target should not send bios that access data beyond the "provided data sectors" limit. - * flags - a flag is set if journal_mac is used + * flags + SB_FLAG_HAVE_JOURNAL_MAC - a flag is set if journal_mac is used + SB_FLAG_RECALCULATING - recalculating is in progress + SB_FLAG_DIRTY_BITMAP - journal area contains the bitmap of dirty + blocks + * log2(sectors per block) + * a position where recalculating finished * journal The journal is divided into sections, each section contains: * metadata area (4kiB), it contains journal entries diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt index 7f40cb5f490b..061f7b98a07f 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.txt +++ b/Documentation/devicetree/bindings/arm/amlogic.txt @@ -110,6 +110,7 @@ Board compatible values (alphabetically, grouped by SoC): - "amlogic,u200" (Meson g12a s905d2) - "amediatech,x96-max" (Meson g12a s905x2) + - "seirobotics,sei510" (Meson g12a s905x2) Amlogic Meson Firmware registers Interface ------------------------------------------ diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt index 4bf1b4da7659..99dee23c74a4 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt +++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt @@ -25,6 +25,7 @@ compatible: must be one of: o "atmel,at91sam9n12" o "atmel,at91sam9rl" o "atmel,at91sam9xe" + o "microchip,sam9x60" * "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific SoC family: o "atmel,sama5d2" shall be extended with the specific SoC compatible: diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index e61d00e25b95..9fbde401a090 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -84,7 +84,7 @@ SHDWC SAMA5D2-Compatible Shutdown Controller 1) shdwc node required properties: -- compatible: should be "atmel,sama5d2-shdwc". +- compatible: should be "atmel,sama5d2-shdwc" or "microchip,sam9x60-shdwc". - reg: should contain registers location and length - clocks: phandle to input clock. - #address-cells: should be one. The cell is the wake-up input index. @@ -96,6 +96,9 @@ optional properties: microseconds. It's usually a board-related property. - atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up. +optional microchip,sam9x60-shdwc properties: +- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up. + The node contains child nodes for each wake-up input that the platform uses. 2) input nodes diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 72d481c8dd48..5d7dbabbb784 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -22,9 +22,11 @@ Required properties: ------------------- - compatible: should be "fsl,imx-scu". - mbox-names: should include "tx0", "tx1", "tx2", "tx3", - "rx0", "rx1", "rx2", "rx3". -- mboxes: List of phandle of 4 MU channels for tx and 4 MU channels - for rx. All 8 MU channels must be in the same MU instance. + "rx0", "rx1", "rx2", "rx3"; + include "gip3" if want to support general MU interrupt. +- mboxes: List of phandle of 4 MU channels for tx, 4 MU channels for + rx, and 1 optional MU channel for general interrupt. + All MU channels must be in the same MU instance. Cross instances are not allowed. The MU instance can only be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need to make sure use the one which is not conflict with other @@ -34,6 +36,7 @@ Required properties: Channel 1 must be "tx1" or "rx1". Channel 2 must be "tx2" or "rx2". Channel 3 must be "tx3" or "rx3". + General interrupt rx channel must be "gip3". e.g. mboxes = <&lsio_mu1 0 0 &lsio_mu1 0 1 @@ -42,10 +45,18 @@ Required properties: &lsio_mu1 1 0 &lsio_mu1 1 1 &lsio_mu1 1 2 - &lsio_mu1 1 3>; + &lsio_mu1 1 3 + &lsio_mu1 3 3>; See Documentation/devicetree/bindings/mailbox/fsl,mu.txt for detailed mailbox binding. +Note: Each mu which supports general interrupt should have an alias correctly +numbered in "aliases" node. +e.g. +aliases { + mu1 = &lsio_mu1; +}; + i.MX SCU Client Device Node: ============================================================ @@ -124,6 +135,10 @@ Required properties: Example (imx8qxp): ------------- +aliases { + mu1 = &lsio_mu1; +}; + lsio_mu1: mailbox@5d1c0000 { ... #mbox-cells = <2>; @@ -133,7 +148,8 @@ firmware { scu { compatible = "fsl,imx-scu"; mbox-names = "tx0", "tx1", "tx2", "tx3", - "rx0", "rx1", "rx2", "rx3"; + "rx0", "rx1", "rx2", "rx3", + "gip3"; mboxes = <&lsio_mu1 0 0 &lsio_mu1 0 1 &lsio_mu1 0 2 @@ -141,7 +157,8 @@ firmware { &lsio_mu1 1 0 &lsio_mu1 1 1 &lsio_mu1 1 2 - &lsio_mu1 1 3>; + &lsio_mu1 1 3 + &lsio_mu1 3 3>; clk: clk { compatible = "fsl,imx8qxp-clk", "fsl,scu-clk"; diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 7e2cd6ad26bd..407138ebc0d0 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -51,6 +51,13 @@ properties: - const: i2se,duckbill-2 - const: fsl,imx28 + - description: i.MX50 based Boards + items: + - enum: + - fsl,imx50-evk + - kobo,aura + - const: fsl,imx50 + - description: i.MX51 Babbage Board items: - enum: @@ -67,6 +74,7 @@ properties: - fsl,imx53-evk - fsl,imx53-qsb - fsl,imx53-smd + - menlo,m53menlo - const: fsl,imx53 - description: i.MX6Q based Boards @@ -90,6 +98,7 @@ properties: - description: i.MX6DL based Boards items: - enum: + - eckelmann,imx6dl-ci4x10 - fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board - fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board - technologic,imx6dl-ts4900 @@ -137,10 +146,18 @@ properties: - const: fsl,imx6ull # This seems odd. Should be last? - const: fsl,imx6ulz + - description: i.MX7S based Boards + items: + - enum: + - tq,imx7s-mba7 # i.MX7S TQ MBa7 with TQMa7S SoM + - const: fsl,imx7s + - description: i.MX7D based Boards items: - enum: - fsl,imx7d-sdb # i.MX7 SabreSD Board + - tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM + - zii,imx7d-rpu2 # ZII RPU2 Board - const: fsl,imx7d - description: @@ -154,6 +171,12 @@ properties: - const: compulab,cl-som-imx7 - const: fsl,imx7d + - description: i.MX8MM based Boards + items: + - enum: + - fsl,imx8mm-evk # i.MX8MM EVK Board + - const: fsl,imx8mm + - description: i.MX8QXP based Boards items: - enum: @@ -176,6 +199,19 @@ properties: - fsl,vf610 - fsl,vf610m4 + - description: ZII's VF610 based Boards + items: + - enum: + - zii,vf610cfu1 # ZII VF610 CFU1 Board + - zii,vf610dev-c # ZII VF610 Development Board, Rev C + - zii,vf610dev-b # ZII VF610 Development Board, Rev B + - zii,vf610scu4-aib # ZII VF610 SCU4 AIB + - zii,vf610dtu # ZII VF610 SSMB DTU Board + - zii,vf610spu3 # ZII VF610 SSMB SPU3 Board + - zii,vf610spb4 # ZII VF610 SPB4 Board + - const: zii,vf610dev + - const: fsl,vf610 + - description: LS1012A based Boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml b/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml new file mode 100644 index 000000000000..f4f7451e5e8a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml @@ -0,0 +1,22 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/intel-ixp4xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel IXP4xx Device Tree Bindings + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + compatible: + oneOf: + - items: + - enum: + - linksys,nslu2 + - const: intel,ixp42x + - items: + - enum: + - gateworks,gw2358 + - const: intel,ixp43x diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt index b56a02c10ae6..6f0cd31c1520 100644 --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt @@ -24,7 +24,8 @@ relationship between the TI-SCI parent node to the child node. Required properties: ------------------- -- compatible: should be "ti,k2g-sci" +- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC + should be "ti,am654-sci" for for TI AM654 SoC - mbox-names: "rx" - Mailbox corresponding to receive path "tx" - Mailbox corresponding to transmit path diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index 2ecc712bf707..1c1e48fd94b5 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -92,6 +92,9 @@ SoCs: - DRA718 compatible = "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7" +- AM5748 + compatible = "ti,am5748", "ti,dra762", "ti,dra7" + - AM5728 compatible = "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7" @@ -184,6 +187,9 @@ Boards: - AM57XX SBC-AM57x compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7" +- AM5748 IDK + compatible = "ti,am5748-idk", "ti,am5748", "ti,dra762", "ti,dra7"; + - AM5728 IDK compatible = "ti,am5728-idk", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7" diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 061a03edf9c8..5c6bbf10abc9 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -97,6 +97,7 @@ properties: - enum: - friendlyarm,nanopc-t4 - friendlyarm,nanopi-m4 + - friendlyarm,nanopi-neo4 - const: rockchip,rk3399 - description: GeekBuying GeekBox @@ -146,7 +147,7 @@ properties: - const: google,gru - const: rockchip,rk3399 - - description: Google Jaq (Haier Chromebook 11 and more) + - description: Google Jaq (Haier Chromebook 11 and more w/ uSD) items: - const: google,veyron-jaq-rev5 - const: google,veyron-jaq-rev4 @@ -159,6 +160,12 @@ properties: - description: Google Jerry (Hisense Chromebook C11 and more) items: + - const: google,veyron-jerry-rev15 + - const: google,veyron-jerry-rev14 + - const: google,veyron-jerry-rev13 + - const: google,veyron-jerry-rev12 + - const: google,veyron-jerry-rev11 + - const: google,veyron-jerry-rev10 - const: google,veyron-jerry-rev7 - const: google,veyron-jerry-rev6 - const: google,veyron-jerry-rev5 @@ -199,6 +206,17 @@ properties: - const: google,veyron - const: rockchip,rk3288 + - description: Google Mighty (Haier Chromebook 11 and more w/ SD) + items: + - const: google,veyron-mighty-rev5 + - const: google,veyron-mighty-rev4 + - const: google,veyron-mighty-rev3 + - const: google,veyron-mighty-rev2 + - const: google,veyron-mighty-rev1 + - const: google,veyron-mighty + - const: google,veyron + - const: rockchip,rk3288 + - description: Google Minnie (Asus Chromebook Flip C100P) items: - const: google,veyron-minnie-rev4 @@ -308,6 +326,11 @@ properties: - const: netxeon,r89 - const: rockchip,rk3288 + - description: Orange Pi RK3399 board + items: + - const: rockchip,rk3399-orangepi + - const: rockchip,rk3399 + - description: Phytec phyCORE-RK3288 Rapid Development Kit items: - const: phytec,rk3288-pcm-947 diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt deleted file mode 100644 index 9254cbe7d516..000000000000 --- a/Documentation/devicetree/bindings/arm/sunxi.txt +++ /dev/null @@ -1,23 +0,0 @@ -Allwinner sunXi Platforms Device Tree Bindings - -Each device tree must specify which Allwinner SoC it uses, -using one of the following compatible strings: - - allwinner,sun4i-a10 - allwinner,sun5i-a10s - allwinner,sun5i-a13 - allwinner,sun5i-r8 - allwinner,sun6i-a31 - allwinner,sun7i-a20 - allwinner,sun8i-a23 - allwinner,sun8i-a33 - allwinner,sun8i-a83t - allwinner,sun8i-h2-plus - allwinner,sun8i-h3 - allwinner,sun8i-r40 - allwinner,sun8i-t3 - allwinner,sun8i-v3s - allwinner,sun9i-a80 - allwinner,sun50i-a64 - allwinner,suniv-f1c100s - nextthing,gr8 diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml new file mode 100644 index 000000000000..285f4fc8519d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -0,0 +1,807 @@ +# SPDX-License-Identifier: (GPL-2.0+ OR X11) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/sunxi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner platforms device tree bindings + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + - Maxime Ripard <maxime.ripard@bootlin.com> + +properties: + $nodename: + const: '/' + compatible: + oneOf: + + - description: Allwinner A23 Evaluation Board + items: + - const: allwinner,sun8i-a23-evb + - const: allwinner,sun8i-a23 + + - description: Allwinner A31 APP4 Evaluation Board + items: + - const: allwinner,app4-evb1 + - const: allwinner,sun6i-a31 + + - description: Allwinner A83t Homlet Evaluation Board v2 + items: + - const: allwinner,h8homlet-v2 + - const: allwinner,sun8i-a83t + + - description: Allwinner GA10H Quad Core Tablet v1.1 + items: + - const: allwinner,ga10h-v1.1 + - const: allwinner,sun8i-a33 + + - description: Allwinner GT90H Tablet v4 + items: + - const: allwinner,gt90h-v4 + - const: allwinner,sun8i-a23 + + - description: Allwinner R16 EVB (Parrot) + items: + - const: allwinner,parrot + - const: allwinner,sun8i-a33 + + - description: Amarula A64 Relic + items: + - const: amarula,a64-relic + - const: allwinner,sun50i-a64 + + - description: Auxtek T003 A10s HDMI TV Stick + items: + - const: allwinner,auxtek-t003 + - const: allwinner,sun5i-a10s + + - description: Auxtek T004 A10s HDMI TV Stick + items: + - const: allwinner,auxtek-t004 + - const: allwinner,sun5i-a10s + + - description: BA10 TV Box + items: + - const: allwinner,ba10-tvbox + - const: allwinner,sun4i-a10 + + - description: BananaPi + items: + - const: lemaker,bananapi + - const: allwinner,sun7i-a20 + + - description: BananaPi M1 Plus + items: + - const: sinovoip,bpi-m1-plus + - const: allwinner,sun7i-a20 + + - description: BananaPi M2 + items: + - const: sinovoip,bpi-m2 + - const: allwinner,sun6i-a31s + + - description: BananaPi M2 Berry + items: + - const: sinovoip,bpi-m2-berry + - const: allwinner,sun8i-r40 + + - description: BananaPi M2 Plus + items: + - const: sinovoip,bpi-m2-plus + - const: allwinner,sun8i-h3 + + - description: BananaPi M2 Plus + items: + - const: sinovoip,bpi-m2-plus + - const: allwinner,sun50i-h5 + + - description: BananaPi M2 Plus v1.2 + items: + - const: bananapi,bpi-m2-plus-v1.2 + - const: allwinner,sun8i-h3 + + - description: BananaPi M2 Plus v1.2 + items: + - const: bananapi,bpi-m2-plus-v1.2 + - const: allwinner,sun50i-h5 + + - description: BananaPi M2 Magic + items: + - const: sinovoip,bananapi-m2m + - const: allwinner,sun8i-a33 + + - description: BananaPi M2 Ultra + items: + - const: sinovoip,bpi-m2-ultra + - const: allwinner,sun8i-r40 + + - description: BananaPi M2 Zero + items: + - const: sinovoip,bpi-m2-zero + - const: allwinner,sun8i-h2-plus + + - description: BananaPi M3 + items: + - const: sinovoip,bpi-m3 + - const: allwinner,sun8i-a83t + + - description: BananaPi M64 + items: + - const: sinovoip,bananapi-m64 + - const: allwinner,sun50i-a64 + + - description: BananaPro + items: + - const: lemaker,bananapro + - const: allwinner,sun7i-a20 + + - description: Beelink GS1 + items: + - const: azw,beelink-gs1 + - const: allwinner,sun50i-h6 + + - description: Beelink X2 + items: + - const: roofull,beelink-x2 + - const: allwinner,sun8i-h3 + + - description: Chuwi V7 CW0825 + items: + - const: chuwi,v7-cw0825 + - const: allwinner,sun4i-a10 + + - description: Colorfly E708 Q1 Tablet + items: + - const: colorfly,e708-q1 + - const: allwinner,sun6i-a31s + + - description: CSQ CS908 Set Top Box + items: + - const: csq,cs908 + - const: allwinner,sun6i-a31s + + - description: Cubietech Cubieboard + items: + - const: cubietech,a10-cubieboard + - const: allwinner,sun4i-a10 + + - description: Cubietech Cubieboard2 + items: + - const: cubietech,cubieboard2 + - const: allwinner,sun7i-a20 + + - description: Cubietech Cubieboard4 + items: + - const: cubietech,a80-cubieboard4 + - const: allwinner,sun9i-a80 + + - description: Cubietech Cubietruck + items: + - const: cubietech,cubietruck + - const: allwinner,sun7i-a20 + + - description: Cubietech Cubietruck Plus + items: + - const: cubietech,cubietruck-plus + - const: allwinner,sun8i-a83t + + - description: Difrnce DIT4350 + items: + - const: difrnce,dit4350 + - const: allwinner,sun5i-a13 + + - description: Dserve DSRV9703C + items: + - const: dserve,dsrv9703c + - const: allwinner,sun4i-a10 + + - description: Empire Electronix D709 Tablet + items: + - const: empire-electronix,d709 + - const: allwinner,sun5i-a13 + + - description: Empire Electronix M712 Tablet + items: + - const: empire-electronix,m712 + - const: allwinner,sun5i-a13 + + - description: FriendlyARM NanoPi A64 + items: + - const: friendlyarm,nanopi-a64 + - const: allwinner,sun50i-a64 + + - description: FriendlyARM NanoPi M1 + items: + - const: friendlyarm,nanopi-m1 + - const: allwinner,sun8i-h3 + + - description: FriendlyARM NanoPi M1 Plus + items: + - const: friendlyarm,nanopi-m1-plus + - const: allwinner,sun8i-h3 + + - description: FriendlyARM NanoPi Neo + items: + - const: friendlyarm,nanopi-neo + - const: allwinner,sun8i-h3 + + - description: FriendlyARM NanoPi Neo 2 + items: + - const: friendlyarm,nanopi-neo2 + - const: allwinner,sun50i-h5 + + - description: FriendlyARM NanoPi Neo Air + items: + - const: friendlyarm,nanopi-neo-air + - const: allwinner,sun8i-h3 + + - description: FriendlyARM NanoPi Neo Plus2 + items: + - const: friendlyarm,nanopi-neo-plus2 + - const: allwinner,sun50i-h5 + + - description: Gemei G9 Tablet + items: + - const: gemei,g9 + - const: allwinner,sun4i-a10 + + - description: Hyundai A7HD + items: + - const: hyundai,a7hd + - const: allwinner,sun4i-a10 + + - description: HSG H702 + items: + - const: hsg,h702 + - const: allwinner,sun5i-a13 + + - description: I12 TV Box + items: + - const: allwinner,i12-tvbox + - const: allwinner,sun7i-a20 + + - description: ICNova A20 SWAC + items: + - const: swac,icnova-a20-swac + - const: incircuit,icnova-a20 + - const: allwinner,sun7i-a20 + + - description: INet-1 + items: + - const: inet-tek,inet1 + - const: allwinner,sun4i-a10 + + - description: iNet-86DZ Rev 01 + items: + - const: primux,inet86dz + - const: allwinner,sun8i-a23 + + - description: iNet-9F Rev 03 + items: + - const: inet-tek,inet9f-rev03 + - const: allwinner,sun4i-a10 + + - description: iNet-97F Rev 02 + items: + - const: primux,inet97fv2 + - const: allwinner,sun4i-a10 + + - description: iNet-98V Rev 02 + items: + - const: primux,inet98v-rev2 + - const: allwinner,sun5i-a13 + + - description: iNet D978 Rev 02 Tablet + items: + - const: primux,inet-d978-rev2 + - const: allwinner,sun8i-a33 + + - description: iNet Q972 Tablet + items: + - const: inet-tek,inet-q972 + - const: allwinner,sun6i-a31s + + - description: Itead Ibox A20 + items: + - const: itead,itead-ibox-a20 + - const: allwinner,sun7i-a20 + + - description: Itead Iteaduino Plus A10 + items: + - const: itead,iteaduino-plus-a10 + - const: allwinner,sun4i-a10 + + - description: Jesurun Q5 + items: + - const: jesurun,q5 + - const: allwinner,sun4i-a10 + + - description: Lamobo R1 + items: + - const: lamobo,lamobo-r1 + - const: allwinner,sun7i-a20 + + - description: Libre Computer Board ALL-H3-CC H2+ + items: + - const: libretech,all-h3-cc-h2-plus + - const: allwinner,sun8i-h2-plus + + - description: Libre Computer Board ALL-H3-CC H3 + items: + - const: libretech,all-h3-cc-h3 + - const: allwinner,sun8i-h3 + + - description: Libre Computer Board ALL-H3-CC H5 + items: + - const: libretech,all-h3-cc-h5 + - const: allwinner,sun50i-h5 + + - description: Lichee Pi One + items: + - const: licheepi,licheepi-one + - const: allwinner,sun5i-a13 + + - description: Lichee Pi Zero + items: + - const: licheepi,licheepi-zero + - const: allwinner,sun8i-v3s + + - description: Lichee Pi Zero (with Dock) + items: + - const: licheepi,licheepi-zero-dock + - const: licheepi,licheepi-zero + - const: allwinner,sun8i-v3s + + - description: Linksprite PCDuino + items: + - const: linksprite,a10-pcduino + - const: allwinner,sun4i-a10 + + - description: Linksprite PCDuino2 + items: + - const: linksprite,a10-pcduino2 + - const: allwinner,sun4i-a10 + + - description: Linksprite PCDuino3 + items: + - const: linksprite,pcduino3 + - const: allwinner,sun7i-a20 + + - description: Linksprite PCDuino3 Nano + items: + - const: linksprite,pcduino3-nano + - const: allwinner,sun7i-a20 + + - description: HAOYU Electronics Marsboard A10 + items: + - const: haoyu,a10-marsboard + - const: allwinner,sun4i-a10 + + - description: MapleBoard MP130 + items: + - const: mapleboard,mp130 + - const: allwinner,sun8i-h3 + + - description: Mele A1000 + items: + - const: mele,a1000 + - const: allwinner,sun4i-a10 + + - description: Mele A1000G Quad Set Top Box + items: + - const: mele,a1000g-quad + - const: allwinner,sun6i-a31 + + - description: Mele I7 Quad Set Top Box + items: + - const: mele,i7 + - const: allwinner,sun6i-a31 + + - description: Mele M3 + items: + - const: mele,m3 + - const: allwinner,sun7i-a20 + + - description: Mele M9 Set Top Box + items: + - const: mele,m9 + - const: allwinner,sun6i-a31 + + - description: Merrii A20 Hummingboard + items: + - const: merrii,a20-hummingbird + - const: allwinner,sun7i-a20 + + - description: Merrii A31 Hummingboard + items: + - const: merrii,a31-hummingbird + - const: allwinner,sun6i-a31 + + - description: Merrii A80 Optimus + items: + - const: merrii,a80-optimus + - const: allwinner,sun9i-a80 + + - description: Miniand Hackberry + items: + - const: miniand,hackberry + - const: allwinner,sun4i-a10 + + - description: MK802 + items: + - const: allwinner,mk802 + - const: allwinner,sun4i-a10 + + - description: MK802-A10s + items: + - const: allwinner,a10s-mk802 + - const: allwinner,sun5i-a10s + + - description: MK802-II + items: + - const: allwinner,mk802ii + - const: allwinner,sun4i-a10 + + - description: MK808c + items: + - const: allwinner,mk808c + - const: allwinner,sun7i-a20 + + - description: MSI Primo81 Tablet + items: + - const: msi,primo81 + - const: allwinner,sun6i-a31s + + - description: Emlid Neutis N5 Developper Board + items: + - const: emlid,neutis-n5-devboard + - const: emlid,neutis-n5 + - const: allwinner,sun50i-h5 + + - description: NextThing Co. CHIP + items: + - const: nextthing,chip + - const: allwinner,sun5i-r8 + - const: allwinner,sun5i-a13 + + - description: NextThing Co. CHIP Pro + items: + - const: nextthing,chip-pro + - const: nextthing,gr8 + + - description: NextThing Co. GR8 Evaluation Board + items: + - const: nextthing,gr8-evb + - const: nextthing,gr8 + + - description: Nintendo NES Classic + items: + - const: nintendo,nes-classic + - const: allwinner,sun8i-r16 + - const: allwinner,sun8i-a33 + + - description: Nintendo Super NES Classic + items: + - const: nintendo,super-nes-classic + - const: nintendo,nes-classic + - const: allwinner,sun8i-r16 + - const: allwinner,sun8i-a33 + + - description: Oceanic 5inMFD (5205) + items: + - const: oceanic,5205-5inmfd + - const: allwinner,sun50i-a64 + + - description: Olimex A10-OlinuXino LIME + items: + - const: olimex,a10-olinuxino-lime + - const: allwinner,sun4i-a10 + + - description: Olimex A10s-OlinuXino Micro + items: + - const: olimex,a10s-olinuxino-micro + - const: allwinner,sun5i-a10s + + - description: Olimex A13-OlinuXino + items: + - const: olimex,a13-olinuxino + - const: allwinner,sun5i-a13 + + - description: Olimex A13-OlinuXino Micro + items: + - const: olimex,a13-olinuxino-micro + - const: allwinner,sun5i-a13 + + - description: Olimex A20-Olimex SOM Evaluation Board + items: + - const: olimex,a20-olimex-som-evb + - const: allwinner,sun7i-a20 + + - description: Olimex A20-Olimex SOM Evaluation Board (with eMMC) + items: + - const: olimex,a20-olimex-som-evb-emmc + - const: allwinner,sun7i-a20 + + - description: Olimex A20-OlinuXino LIME + items: + - const: olimex,a20-olinuxino-lime + - const: allwinner,sun7i-a20 + + - description: Olimex A20-OlinuXino LIME2 + items: + - const: olimex,a20-olinuxino-lime2 + - const: allwinner,sun7i-a20 + + - description: Olimex A20-OlinuXino LIME2 (with eMMC) + items: + - const: olimex,a20-olinuxino-lime2-emmc + - const: allwinner,sun7i-a20 + + - description: Olimex A20-OlinuXino Micro + items: + - const: olimex,a20-olinuxino-micro + - const: allwinner,sun7i-a20 + + - description: Olimex A20-OlinuXino Micro (with eMMC) + items: + - const: olimex,a20-olinuxino-micro-emmc + - const: allwinner,sun7i-a20 + + - description: Olimex A20-SOM204 Evaluation Board + items: + - const: olimex,a20-olimex-som204-evb + - const: allwinner,sun7i-a20 + + - description: Olimex A20-SOM204 Evaluation Board (with eMMC) + items: + - const: olimex,a20-olimex-som204-evb-emmc + - const: allwinner,sun7i-a20 + + - description: Olimex A33-OlinuXino + items: + - const: olimex,a33-olinuxino + - const: allwinner,sun8i-a33 + + - description: Olimex A64-OlinuXino + items: + - const: olimex,a64-olinuxino + - const: allwinner,sun50i-a64 + + - description: Olimex A64 Teres-I + items: + - const: olimex,a64-teres-i + - const: allwinner,sun50i-a64 + + - description: Pine64 + items: + - const: pine64,pine64 + - const: allwinner,sun50i-a64 + + - description: Pine64+ + items: + - const: pine64,pine64-plus + - const: allwinner,sun50i-a64 + + - description: Pine64 PineH64 + items: + - const: pine64,pine-h64 + - const: allwinner,sun50i-h6 + + - description: Pine64 LTS + items: + - const: pine64,pine64-lts + - const: allwinner,sun50i-r18 + - const: allwinner,sun50i-a64 + + - description: Pine64 Pinebook + items: + - const: pine64,pinebook + - const: allwinner,sun50i-a64 + + - description: Pine64 SoPine Baseboard + items: + - const: pine64,sopine-baseboard + - const: pine64,sopine + - const: allwinner,sun50i-a64 + + - description: PineRiver Mini X-Plus + items: + - const: pineriver,mini-xplus + - const: allwinner,sun4i-a10 + + - description: Point of View Protab2-IPS9 + items: + - const: pov,protab2-ips9 + - const: allwinner,sun4i-a10 + + - description: Polaroid MID2407PXE03 Tablet + items: + - const: polaroid,mid2407pxe03 + - const: allwinner,sun8i-a23 + + - description: Polaroid MID2809PXE04 Tablet + items: + - const: polaroid,mid2809pxe04 + - const: allwinner,sun8i-a23 + + - description: Q8 A13 Tablet + items: + - const: allwinner,q8-a13 + - const: allwinner,sun5i-a13 + + - description: Q8 A23 Tablet + items: + - const: allwinner,q8-a23 + - const: allwinner,sun8i-a23 + + - description: Q8 A33 Tablet + items: + - const: allwinner,q8-a33 + - const: allwinner,sun8i-a33 + + - description: Qihua CQA3T BV3 + items: + - const: qihua,t3-cqa3t-bv3 + - const: allwinner,sun8i-t3 + - const: allwinner,sun8i-r40 + + - description: R7 A10s HDMI TV Stick + items: + - const: allwinner,r7-tv-dongle + - const: allwinner,sun5i-a10s + + - description: RerVision H3-DVK + items: + - const: rervision,h3-dvk + - const: allwinner,sun8i-h3 + + - description: Sinlinx SinA31s Core Board + items: + - const: sinlinx,sina31s + - const: allwinner,sun6i-a31s + + - description: Sinlinx SinA31s Development Board + items: + - const: sinlinx,sina31s-sdk + - const: allwinner,sun6i-a31s + + - description: Sinlinx SinA33 + items: + - const: sinlinx,sina33 + - const: allwinner,sun8i-a33 + + - description: TBS A711 Tablet + items: + - const: tbs-biometrics,a711 + - const: allwinner,sun8i-a83t + + - description: Utoo P66 + items: + - const: utoo,p66 + - const: allwinner,sun5i-a13 + + - description: Wexler TAB7200 + items: + - const: wexler,tab7200 + - const: allwinner,sun7i-a20 + + - description: WITS A31 Colombus Evaluation Board + items: + - const: wits,colombus + - const: allwinner,sun6i-a31 + + - description: WITS Pro A20 DKT + items: + - const: wits,pro-a20-dkt + - const: allwinner,sun7i-a20 + + - description: Wobo i5 + items: + - const: wobo,a10s-wobo-i5 + - const: allwinner,sun5i-a10s + + - description: Yones TopTech BS1078 v2 Tablet + items: + - const: yones-toptech,bs1078-v2 + - const: allwinner,sun6i-a31s + + - description: Xunlong OrangePi + items: + - const: xunlong,orangepi + - const: allwinner,sun7i-a20 + + - description: Xunlong OrangePi 2 + items: + - const: xunlong,orangepi-2 + - const: allwinner,sun8i-h3 + + - description: Xunlong OrangePi 3 + items: + - const: xunlong,orangepi-3 + - const: allwinner,sun50i-h6 + + - description: Xunlong OrangePi Lite + items: + - const: xunlong,orangepi-lite + - const: allwinner,sun8i-h3 + + - description: Xunlong OrangePi Lite2 + items: + - const: xunlong,orangepi-lite2 + - const: allwinner,sun50i-h6 + + - description: Xunlong OrangePi Mini + items: + - const: xunlong,orangepi-mini + - const: allwinner,sun7i-a20 + + - description: Xunlong OrangePi One + items: + - const: xunlong,orangepi-one + - const: allwinner,sun8i-h3 + + - description: Xunlong OrangePi One Plus + items: + - const: xunlong,orangepi-one-plus + - const: allwinner,sun50i-h6 + + - description: Xunlong OrangePi PC + items: + - const: xunlong,orangepi-pc + - const: allwinner,sun8i-h3 + + - description: Xunlong OrangePi PC 2 + items: + - const: xunlong,orangepi-pc2 + - const: allwinner,sun50i-h5 + + - description: Xunlong OrangePi PC Plus + items: + - const: xunlong,orangepi-pc-plus + - const: allwinner,sun8i-h3 + + - description: Xunlong OrangePi Plus + items: + - const: xunlong,orangepi-plus + - const: allwinner,sun8i-h3 + + - description: Xunlong OrangePi Plus 2E + items: + - const: xunlong,orangepi-plus2e + - const: allwinner,sun8i-h3 + + - description: Xunlong OrangePi Prime + items: + - const: xunlong,orangepi-prime + - const: allwinner,sun50i-h5 + + - description: Xunlong OrangePi R1 + items: + - const: xunlong,orangepi-r1 + - const: allwinner,sun8i-h2-plus + + - description: Xunlong OrangePi Win + items: + - const: xunlong,orangepi-win + - const: allwinner,sun50i-a64 + + - description: Xunlong OrangePi Zero + items: + - const: xunlong,orangepi-zero + - const: allwinner,sun8i-h2-plus + + - description: Xunlong OrangePi Zero Plus + items: + - const: xunlong,orangepi-zero-plus + - const: allwinner,sun50i-h5 + + - description: Xunlong OrangePi Zero Plus2 + items: + - const: xunlong,orangepi-zero-plus2 + - const: allwinner,sun50i-h5 + + - description: Xunlong OrangePi Zero Plus2 + items: + - const: xunlong,orangepi-zero-plus2-h3 + - const: allwinner,sun8i-h3 diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt index 85a23f551f02..233eb8294204 100644 --- a/Documentation/devicetree/bindings/bus/ti-sysc.txt +++ b/Documentation/devicetree/bindings/bus/ti-sysc.txt @@ -94,6 +94,8 @@ Optional properties: - ti,no-idle-on-init interconnect target module should not be idled at init +- ti,no-idle interconnect target module should not be idled + Example: Single instance of MUSB controller on omap4 using interconnect ranges using offsets from l4_cfg second segment (0x4a000000 + 0x80000 = 0x4a0ab000): @@ -131,6 +133,6 @@ using offsets from l4_cfg second segment (0x4a000000 + 0x80000 = 0x4a0ab000): }; }; -Note that other SoCs, such as am335x can have multipe child devices. On am335x +Note that other SoCs, such as am335x can have multiple child devices. On am335x there are two MUSB instances, two USB PHY instances, and a single CPPI41 DMA -instance as children of a single interconnet target module. +instance as children of a single interconnect target module. diff --git a/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt b/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt new file mode 100644 index 000000000000..391ee1a60bed --- /dev/null +++ b/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt @@ -0,0 +1,63 @@ +-------------------------------------------------------------------------- +Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using +Zynq MPSoC firmware interface +-------------------------------------------------------------------------- +The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock +tree. It reads required input clock frequencies from the devicetree and acts +as clock provider for all clock consumers of PS clocks. + +See clock_bindings.txt for more information on the generic clock bindings. + +Required properties: + - #clock-cells: Must be 1 + - compatible: Must contain: "xlnx,zynqmp-clk" + - clocks: List of clock specifiers which are external input + clocks to the given clock controller. Please refer + the next section to find the input clocks for a + given controller. + - clock-names: List of clock names which are exteral input clocks + to the given clock controller. Please refer to the + clock bindings for more details. + +Input clocks for zynqmp Ultrascale+ clock controller: + +The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock +inputs. These required clock inputs are: + - pss_ref_clk (PS reference clock) + - video_clk (reference clock for video system ) + - pss_alt_ref_clk (alternative PS reference clock) + - aux_ref_clk + - gt_crx_ref_clk (transceiver reference clock) + +The following strings are optional parameters to the 'clock-names' property in +order to provide an optional (E)MIO clock source: + - swdt0_ext_clk + - swdt1_ext_clk + - gem0_emio_clk + - gem1_emio_clk + - gem2_emio_clk + - gem3_emio_clk + - mio_clk_XX # with XX = 00..77 + - mio_clk_50_or_51 #for the mux clock to gem tsu from 50 or 51 + + +Output clocks are registered based on clock information received +from firmware. Output clocks indexes are mentioned in +include/dt-bindings/clock/xlnx-zynqmp-clk.h. + +------- +Example +------- + +firmware { + zynqmp_firmware: zynqmp-firmware { + compatible = "xlnx,zynqmp-firmware"; + method = "smc"; + zynqmp_clk: clock-controller { + #clock-cells = <1>; + compatible = "xlnx,zynqmp-clk"; + clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>, <&aux_ref_clk>, <>_crx_ref_clk>; + clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk"; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt index 3c9a57a8443b..9d8bbac27d8b 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt @@ -9,6 +9,7 @@ Required properties: "fsl,imx53-sdma" "fsl,imx6q-sdma" "fsl,imx7d-sdma" + "fsl,imx8mq-sdma" The -to variants should be preferred since they allow to determine the correct ROM script addresses needed for the driver to work without additional firmware. diff --git a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml new file mode 100644 index 000000000000..8cb136c376fb --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Linaro Ltd. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/firmware/intel-ixp4xx-network-processing-engine.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Intel IXP4xx Network Processing Engine + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + On the IXP4xx SoCs, the Network Processing Engine (NPE) is a small + processor that can load a firmware to perform offloading of networking + and crypto tasks. It also manages the MDIO bus to the ethernet PHYs + on the IXP4xx platform. All IXP4xx platforms have three NPEs at + consecutive memory locations. They are all included in the same + device node since they are not independent of each other. + +properties: + compatible: + oneOf: + - items: + - const: intel,ixp4xx-network-processing-engine + + reg: + minItems: 3 + maxItems: 3 + items: + - description: NPE0 register range + - description: NPE1 register range + - description: NPE2 register range + +required: + - compatible + - reg + +examples: + - | + npe@c8006000 { + compatible = "intel,ixp4xx-network-processing-engine"; + reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt index 614bac55df86..a4fe136be2ba 100644 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt @@ -17,53 +17,6 @@ Required properties: - "smc" : SMC #0, following the SMCCC - "hvc" : HVC #0, following the SMCCC --------------------------------------------------------------------------- -Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using -Zynq MPSoC firmware interface --------------------------------------------------------------------------- -The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock -tree. It reads required input clock frequencies from the devicetree and acts -as clock provider for all clock consumers of PS clocks. - -See clock_bindings.txt for more information on the generic clock bindings. - -Required properties: - - #clock-cells: Must be 1 - - compatible: Must contain: "xlnx,zynqmp-clk" - - clocks: List of clock specifiers which are external input - clocks to the given clock controller. Please refer - the next section to find the input clocks for a - given controller. - - clock-names: List of clock names which are exteral input clocks - to the given clock controller. Please refer to the - clock bindings for more details. - -Input clocks for zynqmp Ultrascale+ clock controller: - -The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock -inputs. These required clock inputs are: - - pss_ref_clk (PS reference clock) - - video_clk (reference clock for video system ) - - pss_alt_ref_clk (alternative PS reference clock) - - aux_ref_clk - - gt_crx_ref_clk (transceiver reference clock) - -The following strings are optional parameters to the 'clock-names' property in -order to provide an optional (E)MIO clock source: - - swdt0_ext_clk - - swdt1_ext_clk - - gem0_emio_clk - - gem1_emio_clk - - gem2_emio_clk - - gem3_emio_clk - - mio_clk_XX # with XX = 00..77 - - mio_clk_50_or_51 #for the mux clock to gem tsu from 50 or 51 - - -Output clocks are registered based on clock information received -from firmware. Output clocks indexes are mentioned in -include/dt-bindings/clock/xlnx,zynqmp-clk.h. - ------- Example ------- @@ -72,11 +25,6 @@ firmware { zynqmp_firmware: zynqmp-firmware { compatible = "xlnx,zynqmp-firmware"; method = "smc"; - zynqmp_clk: clock-controller { - #clock-cells = <1>; - compatible = "xlnx,zynqmp-clk"; - clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>, <&aux_ref_clk>, <>_crx_ref_clk>; - clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk"; - }; + ... }; }; diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt new file mode 100644 index 000000000000..3052bf619dd5 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt @@ -0,0 +1,25 @@ +Devicetree bindings for Zynq Ultrascale MPSoC FPGA Manager. +The ZynqMP SoC uses the PCAP (Processor configuration Port) to configure the +Programmable Logic (PL). The configuration uses the firmware interface. + +Required properties: +- compatible: should contain "xlnx,zynqmp-pcap-fpga" + +Example for full FPGA configuration: + + fpga-region0 { + compatible = "fpga-region"; + fpga-mgr = <&zynqmp_pcap>; + #address-cells = <0x1>; + #size-cells = <0x1>; + }; + + firmware { + zynqmp_firmware: zynqmp-firmware { + compatible = "xlnx,zynqmp-firmware"; + method = "smc"; + zynqmp_pcap: pcap { + compatible = "xlnx,zynqmp-pcap-fpga"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 18a2cde2e5f3..1b1a74129141 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -37,6 +37,20 @@ Optional properties: - operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt for details. +- resets : Phandle of the GPU reset line. + +Vendor-specific bindings +------------------------ + +The Mali GPU is integrated very differently from one SoC to +another. In order to accomodate those differences, you have the option +to specify one more vendor-specific compatible, among: + +- "amlogic,meson-gxm-mali" + Required properties: + - resets : Should contain phandles of : + + GPU reset line + + GPU APB glue reset line Example for a Mali-T760: diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt index 6ced829b0e58..41b76762953a 100644 --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt @@ -21,8 +21,6 @@ Optional properties: Example: fan0: pwm-fan { compatible = "pwm-fan"; - cooling-min-state = <0>; - cooling-max-state = <3>; #cooling-cells = <2>; pwms = <&pwm 0 10000 0>; cooling-levels = <0 102 170 230>; diff --git a/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt index 5c184b940669..f1f3a552459b 100644 --- a/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt +++ b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt @@ -10,6 +10,7 @@ Required properties: - clocks: The root clock of the ADC controller - clock-names: Must contain "adc", matching entry in the clocks property - vref-supply: The regulator supply ADC reference voltage +- #io-channel-cells: Must be 1 as per ../iio-bindings.txt Example: adc1: adc@30610000 { @@ -19,4 +20,5 @@ adc1: adc@30610000 { clocks = <&clks IMX7D_ADC_ROOT_CLK>; clock-names = "adc"; vref-supply = <®_vcc_3v3_mcu>; + #io-channel-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt index c81993f8d8c3..c8787688122a 100644 --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt @@ -13,6 +13,7 @@ VADC node: Definition: Should contain "qcom,spmi-vadc". Should contain "qcom,spmi-adc5" for PMIC5 ADC driver. Should contain "qcom,spmi-adc-rev2" for PMIC rev2 ADC driver. + Should contain "qcom,pms405-adc" for PMS405 PMIC - reg: Usage: required diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml b/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml new file mode 100644 index 000000000000..bae10e261fa9 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2018 Linaro Ltd. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/interrupt/intel-ixp4xx-interrupt.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Intel IXP4xx XScale Networking Processors Interrupt Controller + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + This interrupt controller is found in the Intel IXP4xx processors. + Some processors have 32 interrupts, some have up to 64 interrupts. + The exact number of interrupts is determined from the compatible + string. + + The distinct IXP4xx families with different interrupt controller + variations are IXP42x, IXP43x, IXP45x and IXP46x. Those four + families were the only ones to reach the developer and consumer + market. + +properties: + compatible: + items: + - enum: + - intel,ixp42x-interrupt + - intel,ixp43x-interrupt + - intel,ixp45x-interrupt + - intel,ixp46x-interrupt + + reg: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + +required: + - compatible + - reg + - interrupt-controller + - '#interrupt-cells' + +examples: + - | + intcon: interrupt-controller@c8003000 { + compatible = "intel,ixp43x-interrupt"; + reg = <0xc8003000 0x100>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt index c5d589108a94..0e312fea2a5d 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt @@ -1,15 +1,18 @@ -+Mediatek MT65xx/MT67xx/MT81xx sysirq +MediaTek sysirq -Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI +MediaTek SOCs sysirq support controllable irq inverter for each GIC SPI interrupt. Required properties: - compatible: should be + "mediatek,mt8516-sysirq", "mediatek,mt6577-sysirq": for MT8516 + "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183 "mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173 "mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135 "mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127 "mediatek,mt7622-sysirq", "mediatek,mt6577-sysirq": for MT7622 "mediatek,mt7623-sysirq", "mediatek,mt6577-sysirq": for MT7623 + "mediatek,mt7629-sysirq", "mediatek,mt6577-sysirq": for MT7629 "mediatek,mt6795-sysirq", "mediatek,mt6577-sysirq": for MT6795 "mediatek,mt6797-sysirq", "mediatek,mt6577-sysirq": for MT6797 "mediatek,mt6765-sysirq", "mediatek,mt6577-sysirq": for MT6765 diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt new file mode 100644 index 000000000000..7841cb099e13 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt @@ -0,0 +1,66 @@ +Texas Instruments K3 Interrupt Aggregator +========================================= + +The Interrupt Aggregator (INTA) provides a centralized machine +which handles the termination of system events to that they can +be coherently processed by the host(s) in the system. A maximum +of 64 events can be mapped to a single interrupt. + + + Interrupt Aggregator + +-----------------------------------------+ + | Intmap VINT | + | +--------------+ +------------+ | + m ------>| | vint | bit | | 0 |.....|63| vint0 | + . | +--------------+ +------------+ | +------+ + . | . . | | HOST | +Globalevents ------>| . . |------>| IRQ | + . | . . | | CTRL | + . | . . | +------+ + n ------>| +--------------+ +------------+ | + | | vint | bit | | 0 |.....|63| vintx | + | +--------------+ +------------+ | + | | + +-----------------------------------------+ + +Configuration of these Intmap registers that maps global events to vint is done +by a system controller (like the Device Memory and Security Controller on K3 +AM654 SoC). Driver should request the system controller to get the range +of global events and vints assigned to the requesting host. Management +of these requested resources should be handled by driver and requests +system controller to map specific global event to vint, bit pair. + +Communication between the host processor running an OS and the system +controller happens through a protocol called TI System Control Interface +(TISCI protocol). For more details refer: +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt + +TISCI Interrupt Aggregator Node: +------------------------------- +- compatible: Must be "ti,sci-inta". +- reg: Should contain registers location and length. +- interrupt-controller: Identifies the node as an interrupt controller +- msi-controller: Identifies the node as an MSI controller. +- interrupt-parent: phandle of irq parent. +- ti,sci: Phandle to TI-SCI compatible System controller node. +- ti,sci-dev-id: TISCI device ID of the Interrupt Aggregator. +- ti,sci-rm-range-vint: Array of TISCI subtype ids representing vints(inta + outputs) range within this INTA, assigned to the + requesting host context. +- ti,sci-rm-range-global-event: Array of TISCI subtype ids representing the + global events range reaching this IA and are assigned + to the requesting host context. + +Example: +-------- +main_udmass_inta: interrupt-controller@33d00000 { + compatible = "ti,sci-inta"; + reg = <0x0 0x33d00000 0x0 0x100000>; + interrupt-controller; + msi-controller; + interrupt-parent = <&main_navss_intr>; + ti,sci = <&dmsc>; + ti,sci-dev-id = <179>; + ti,sci-rm-range-vint = <0x0>; + ti,sci-rm-range-global-event = <0x1>; +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt new file mode 100644 index 000000000000..1a8718f8855d --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt @@ -0,0 +1,82 @@ +Texas Instruments K3 Interrupt Router +===================================== + +The Interrupt Router (INTR) module provides a mechanism to mux M +interrupt inputs to N interrupt outputs, where all M inputs are selectable +to be driven per N output. An Interrupt Router can either handle edge triggered +or level triggered interrupts and that is fixed in hardware. + + Interrupt Router + +----------------------+ + | Inputs Outputs | + +-------+ | +------+ +-----+ | + | GPIO |----------->| | irq0 | | 0 | | Host IRQ + +-------+ | +------+ +-----+ | controller + | . . | +-------+ + +-------+ | . . |----->| IRQ | + | INTA |----------->| . . | +-------+ + +-------+ | . +-----+ | + | +------+ | N | | + | | irqM | +-----+ | + | +------+ | + | | + +----------------------+ + +There is one register per output (MUXCNTL_N) that controls the selection. +Configuration of these MUXCNTL_N registers is done by a system controller +(like the Device Memory and Security Controller on K3 AM654 SoC). System +controller will keep track of the used and unused registers within the Router. +Driver should request the system controller to get the range of GIC IRQs +assigned to the requesting hosts. It is the drivers responsibility to keep +track of Host IRQs. + +Communication between the host processor running an OS and the system +controller happens through a protocol called TI System Control Interface +(TISCI protocol). For more details refer: +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt + +TISCI Interrupt Router Node: +---------------------------- +Required Properties: +- compatible: Must be "ti,sci-intr". +- ti,intr-trigger-type: Should be one of the following: + 1: If intr supports edge triggered interrupts. + 4: If intr supports level triggered interrupts. +- interrupt-controller: Identifies the node as an interrupt controller +- #interrupt-cells: Specifies the number of cells needed to encode an + interrupt source. The value should be 2. + First cell should contain the TISCI device ID of source + Second cell should contain the interrupt source offset + within the device. +- ti,sci: Phandle to TI-SCI compatible System controller node. +- ti,sci-dst-id: TISCI device ID of the destination IRQ controller. +- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the host irqs + assigned to this interrupt router. Each subtype id + corresponds to a range of host irqs. + +For more details on TISCI IRQ resource management refer: +http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html + +Example: +-------- +The following example demonstrates both interrupt router node and the consumer +node(main gpio) on the AM654 SoC: + +main_intr: interrupt-controller0 { + compatible = "ti,sci-intr"; + ti,intr-trigger-type = <1>; + interrupt-controller; + interrupt-parent = <&gic500>; + #interrupt-cells = <2>; + ti,sci = <&dmsc>; + ti,sci-dst-id = <56>; + ti,sci-rm-range-girq = <0x1>; +}; + +main_gpio0: gpio@600000 { + ... + interrupt-parent = <&main_intr>; + interrupts = <57 256>, <57 257>, <57 258>, + <57 259>, <57 260>, <57 261>; + ... +}; diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.txt new file mode 100644 index 000000000000..bcc36c5b543c --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.txt @@ -0,0 +1,35 @@ +Freescale Multi Mode DDR controller (MMDC) + +Required properties : +- compatible : should be one of following: + for i.MX6Q/i.MX6DL: + - "fsl,imx6q-mmdc"; + for i.MX6QP: + - "fsl,imx6qp-mmdc", "fsl,imx6q-mmdc"; + for i.MX6SL: + - "fsl,imx6sl-mmdc", "fsl,imx6q-mmdc"; + for i.MX6SLL: + - "fsl,imx6sll-mmdc", "fsl,imx6q-mmdc"; + for i.MX6SX: + - "fsl,imx6sx-mmdc", "fsl,imx6q-mmdc"; + for i.MX6UL/i.MX6ULL/i.MX6ULZ: + - "fsl,imx6ul-mmdc", "fsl,imx6q-mmdc"; + for i.MX7ULP: + - "fsl,imx7ulp-mmdc", "fsl,imx6q-mmdc"; +- reg : address and size of MMDC DDR controller registers + +Optional properties : +- clocks : the clock provided by the SoC to access the MMDC registers + +Example : + mmdc0: memory-controller@21b0000 { /* MMDC0 */ + compatible = "fsl,imx6q-mmdc"; + reg = <0x021b0000 0x4000>; + clocks = <&clks IMX6QDL_CLK_MMDC_P0_IPG>; + }; + + mmdc1: memory-controller@21b4000 { /* MMDC1 */ + compatible = "fsl,imx6q-mmdc"; + reg = <0x021b4000 0x4000>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/misc/intel,ixp4xx-queue-manager.yaml b/Documentation/devicetree/bindings/misc/intel,ixp4xx-queue-manager.yaml new file mode 100644 index 000000000000..d2313b1d9405 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/intel,ixp4xx-queue-manager.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Linaro Ltd. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/misc/intel-ixp4xx-ahb-queue-manager.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Intel IXP4xx AHB Queue Manager + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + The IXP4xx AHB Queue Manager maintains queues as circular buffers in + an 8KB embedded SRAM along with hardware pointers. It is used by both + the XScale processor and the NPEs (Network Processing Units) in the + IXP4xx for accelerating queues, especially for networking. Clients pick + queues from the queue manager with foo-queue = <&qmgr N> where the + &qmgr is a phandle to the queue manager and N is the queue resource + number. The queue resources available and their specific purpose + on a certain IXP4xx system will vary. + +properties: + compatible: + items: + - const: intel,ixp4xx-ahb-queue-manager + + reg: + maxItems: 1 + + interrupts: + items: + - description: Interrupt for queues 0-31 + - description: Interrupt for queues 32-63 + +required: + - compatible + - reg + - interrupts + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + qmgr: queue-manager@60000000 { + compatible = "intel,ixp4xx-ahb-queue-manager"; + reg = <0x60000000 0x4000>; + interrupts = <3 IRQ_TYPE_LEVEL_HIGH>, <4 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt index 07242d141773..36c4bea675d5 100644 --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt @@ -13,6 +13,8 @@ Required Properties: * compatible: should be one of the following. - "hisilicon,hi3660-dw-mshc": for controllers with hi3660 specific extensions. + - "hisilicon,hi3670-dw-mshc", "hisilicon,hi3660-dw-mshc": for controllers + with hi3670 specific extensions. - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions. - "hisilicon,hi6220-dw-mshc": for controllers with hi6220 specific extensions. diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt b/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt index 1cd050b4054c..0fdc3dd1125e 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt +++ b/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt @@ -16,7 +16,9 @@ Device Tree Bindings: --------------------- Required properties: -- compatible: should be "amlogic,meson-gx-pwrc-vpu" for the Meson GX SoCs +- compatible: should be one of the following : + - "amlogic,meson-gx-pwrc-vpu" for the Meson GX SoCs + - "amlogic,meson-g12a-pwrc-vpu" for the Meson G12A SoCs - #power-domain-cells: should be 0 - amlogic,hhi-sysctrl: phandle to the HHI sysctrl node - resets: phandles to the reset lines needed for this power demain sequence diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt index 11906316b43d..e23dea8344f8 100644 --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt @@ -3,13 +3,20 @@ Generic SYSCON mapped register reset driver This is a generic reset driver using syscon to map the reset register. The reset is generally performed with a write to the reset register defined by the register map pointed by syscon reference plus the offset -with the mask defined in the reboot node. +with the value and mask defined in the reboot node. Required properties: - compatible: should contain "syscon-reboot" - regmap: this is phandle to the register map node - offset: offset in the register map for the reboot register (in bytes) -- mask: the reset value written to the reboot register (32 bit access) +- value: the reset value written to the reboot register (32 bit access) + +Optional properties: +- mask: update only the register bits defined by the mask (32 bit) + +Legacy usage: +If a node doesn't contain a value property but contains a mask property, the +mask property is used as the value. Default will be little endian mode, 32 bit access only. diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt index ba8d35f66cbe..b2d4968fde7d 100644 --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt @@ -4,6 +4,7 @@ Required Properties: -compatible: One of: "x-powers,axp202-usb-power-supply" "x-powers,axp221-usb-power-supply" "x-powers,axp223-usb-power-supply" + "x-powers,axp813-usb-power-supply" The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight variations such as the former being able to set the VBUS power supply max diff --git a/Documentation/devicetree/bindings/power/supply/gpio-charger.txt b/Documentation/devicetree/bindings/power/supply/gpio-charger.txt index adbb5dc5b6e9..0fb33b2c62a6 100644 --- a/Documentation/devicetree/bindings/power/supply/gpio-charger.txt +++ b/Documentation/devicetree/bindings/power/supply/gpio-charger.txt @@ -14,13 +14,17 @@ Required properties : usb-cdp (USB charging downstream port) usb-aca (USB accessory charger adapter) +Optional properties: + - charge-status-gpios: GPIO indicating whether a battery is charging. + Example: usb_charger: charger { compatible = "gpio-charger"; charger-type = "usb-sdp"; - gpios = <&gpf0 2 0 0 0>; - } + gpios = <&gpd 28 GPIO_ACTIVE_LOW>; + charge-status-gpios = <&gpc 27 GPIO_ACTIVE_LOW>; + }; battery { power-supplies = <&usb_charger>; diff --git a/Documentation/devicetree/bindings/power/supply/ingenic,battery.txt b/Documentation/devicetree/bindings/power/supply/ingenic,battery.txt new file mode 100644 index 000000000000..66430bf73815 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/ingenic,battery.txt @@ -0,0 +1,31 @@ +* Ingenic JZ47xx battery bindings + +Required properties: + +- compatible: Must be "ingenic,jz4740-battery". +- io-channels: phandle and IIO specifier pair to the IIO device. + Format described in iio-bindings.txt. +- monitored-battery: phandle to a "simple-battery" compatible node. + +The "monitored-battery" property must be a phandle to a node using the format +described in battery.txt, with the following properties being required: + +- voltage-min-design-microvolt: Drained battery voltage. +- voltage-max-design-microvolt: Fully charged battery voltage. + +Example: + +#include <dt-bindings/iio/adc/ingenic,adc.h> + +simple_battery: battery { + compatible = "simple-battery"; + voltage-min-design-microvolt = <3600000>; + voltage-max-design-microvolt = <4200000>; +}; + +ingenic_battery { + compatible = "ingenic,jz4740-battery"; + io-channels = <&adc INGENIC_ADC_BATTERY>; + io-channel-names = "battery"; + monitored-battery = <&simple_battery>; +}; diff --git a/Documentation/devicetree/bindings/power/supply/ltc3651-charger.txt b/Documentation/devicetree/bindings/power/supply/lt3651-charger.txt index 71f2840e8209..40811ff8de10 100644 --- a/Documentation/devicetree/bindings/power/supply/ltc3651-charger.txt +++ b/Documentation/devicetree/bindings/power/supply/lt3651-charger.txt @@ -1,14 +1,16 @@ -ltc3651-charger +Analog Devices LT3651 Charger Power Supply bindings: lt3651-charger Required properties: - - compatible: "lltc,ltc3651-charger" +- compatible: Should contain one of the following: + * "lltc,ltc3651-charger", (DEPRECATED: Use "lltc,lt3651-charger") + * "lltc,lt3651-charger" - lltc,acpr-gpios: Connect to ACPR output. See remark below. Optional properties: - lltc,fault-gpios: Connect to FAULT output. See remark below. - lltc,chrg-gpios: Connect to CHRG output. See remark below. -The ltc3651 outputs are open-drain type and active low. The driver assumes the +The lt3651 outputs are open-drain type and active low. The driver assumes the GPIO reports "active" when the output is asserted, so if the pins have been connected directly, the GPIO flags should be set to active low also. @@ -20,7 +22,7 @@ attributes to detect changes. Example: charger: battery-charger { - compatible = "lltc,ltc3651-charger"; + compatible = "lltc,lt3651-charger"; lltc,acpr-gpios = <&gpio0 68 GPIO_ACTIVE_LOW>; lltc,fault-gpios = <&gpio0 64 GPIO_ACTIVE_LOW>; lltc,chrg-gpios = <&gpio0 63 GPIO_ACTIVE_LOW>; diff --git a/Documentation/devicetree/bindings/power/supply/microchip,ucs1002.txt b/Documentation/devicetree/bindings/power/supply/microchip,ucs1002.txt new file mode 100644 index 000000000000..1d284ad816bf --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/microchip,ucs1002.txt @@ -0,0 +1,27 @@ +Microchip UCS1002 USB Port Power Controller + +Required properties: +- compatible : Should be "microchip,ucs1002"; +- reg : I2C slave address + +Optional properties: +- interrupts : A list of interrupts lines present (could be either + corresponding to A_DET# pin, ALERT# pin, or both) +- interrupt-names : A list of interrupt names. Should contain (if + present): + - "a_det" for line connected to A_DET# pin + - "alert" for line connected to ALERT# pin + Both are expected to be IRQ_TYPE_EDGE_BOTH +Example: + +&i2c3 { + charger@32 { + compatible = "microchip,ucs1002"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ucs1002_pins>; + reg = <0x32>; + interrupts-extended = <&gpio5 2 IRQ_TYPE_EDGE_BOTH>, + <&gpio3 21 IRQ_TYPE_EDGE_BOTH>; + interrupt-names = "a_det", "alert"; + }; +}; diff --git a/Documentation/devicetree/bindings/power/supply/olpc_battery.txt b/Documentation/devicetree/bindings/power/supply/olpc_battery.txt index c8901b3992d9..8d87d6b35a98 100644 --- a/Documentation/devicetree/bindings/power/supply/olpc_battery.txt +++ b/Documentation/devicetree/bindings/power/supply/olpc_battery.txt @@ -2,4 +2,4 @@ OLPC battery ~~~~~~~~~~~~ Required properties: - - compatible : "olpc,xo1-battery" + - compatible : "olpc,xo1-battery" or "olpc,xo1.5-battery" diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt b/Documentation/devicetree/bindings/pps/pps-gpio.txt index 3683874832ae..9012a2a02e14 100644 --- a/Documentation/devicetree/bindings/pps/pps-gpio.txt +++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt @@ -7,6 +7,10 @@ Required properties: - compatible: should be "pps-gpio" - gpios: one PPS GPIO in the format described by ../gpio/gpio.txt +Additional required properties for the PPS ECHO functionality: +- echo-gpios: one PPS ECHO GPIO in the format described by ../gpio/gpio.txt +- echo-active-ms: duration in ms of the active portion of the echo pulse + Optional properties: - assert-falling-edge: when present, assert is indicated by a falling edge (instead of by a rising edge) @@ -19,5 +23,8 @@ Example: gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>; assert-falling-edge; + echo-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; + echo-active-ms = <100>; + compatible = "pps-gpio"; }; diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt index 2bf3344b2a02..2df4bddeb688 100644 --- a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt @@ -5,11 +5,12 @@ Please also refer to reset.txt in this directory for common reset controller binding usage. The reset controller registers are part of the system-ctl block on -hi3660 SoC. +hi3660 and hi3670 SoCs. Required properties: -- compatible: should be - "hisilicon,hi3660-reset" +- compatible: should be one of the following: + "hisilicon,hi3660-reset" for HI3660 + "hisilicon,hi3670-reset", "hisilicon,hi3660-reset" for HI3670 - hisi,rst-syscon: phandle of the reset's syscon. - #reset-cells : Specifies the number of cells needed to encode a reset source. The type shall be a <u32> and the value shall be 2. diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt new file mode 100644 index 000000000000..73d8f19c3bd9 --- /dev/null +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt @@ -0,0 +1,51 @@ +SiFive L2 Cache Controller +-------------------------- +The SiFive Level 2 Cache Controller is used to provide access to fast copies +of memory for masters in a Core Complex. The Level 2 Cache Controller also +acts as directory-based coherency manager. +All the properties in ePAPR/DeviceTree specification applies for this platform + +Required Properties: +-------------------- +- compatible: Should be "sifive,fu540-c000-ccache" and "cache" + +- cache-block-size: Specifies the block size in bytes of the cache. + Should be 64 + +- cache-level: Should be set to 2 for a level 2 cache + +- cache-sets: Specifies the number of associativity sets of the cache. + Should be 1024 + +- cache-size: Specifies the size in bytes of the cache. Should be 2097152 + +- cache-unified: Specifies the cache is a unified cache + +- interrupts: Must contain 3 entries (DirError, DataError and DataFail signals) + +- reg: Physical base address and size of L2 cache controller registers map + +Optional Properties: +-------------------- +- next-level-cache: phandle to the next level cache if present. + +- memory-region: reference to the reserved-memory for the L2 Loosely Integrated + Memory region. The reserved memory node should be defined as per the bindings + in reserved-memory.txt + + +Example: + + cache-controller@2010000 { + compatible = "sifive,fu540-c000-ccache", "cache"; + cache-block-size = <64>; + cache-level = <2>; + cache-sets = <1024>; + cache-size = <2097152>; + cache-unified; + interrupt-parent = <&plic0>; + interrupts = <1 2 3>; + reg = <0x0 0x2010000 0x0 0x1000>; + next-level-cache = <&L25 &L40 &L36>; + memory-region = <&l2_lim>; + }; diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index bcfb13194f16..c6b5262eb352 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -1,4 +1,4 @@ -* Mediatek Universal Asynchronous Receiver/Transmitter (UART) +* MediaTek Universal Asynchronous Receiver/Transmitter (UART) Required properties: - compatible should contain: @@ -13,10 +13,12 @@ Required properties: * "mediatek,mt6797-uart" for MT6797 compatible UARTS * "mediatek,mt7622-uart" for MT7622 compatible UARTS * "mediatek,mt7623-uart" for MT7623 compatible UARTS + * "mediatek,mt7629-uart" for MT7629 compatible UARTS * "mediatek,mt8127-uart" for MT8127 compatible UARTS * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS + * "mediatek,mt8516-uart" for MT8516 compatible UARTS * "mediatek,mt6577-uart" for MT6577 and all of the above - reg: The base address of the UART register bank. diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt index 5a2ef1726e2a..7a32404c6114 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt @@ -25,6 +25,7 @@ Required properties in pwrap device node. "mediatek,mt8135-pwrap" for MT8135 SoCs "mediatek,mt8173-pwrap" for MT8173 SoCs "mediatek,mt8183-pwrap" for MT8183 SoCs + "mediatek,mt8516-pwrap" for MT8516 SoCs - interrupts: IRQ for pwrap in SOC - reg-names: Must include the following entries: "pwrap": Main registers base diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt index d6fe16f094af..876693a7ada5 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt @@ -23,6 +23,7 @@ Required properties: - "mediatek,mt7622-scpsys" - "mediatek,mt7623-scpsys", "mediatek,mt2701-scpsys": For MT7623 SoC - "mediatek,mt7623a-scpsys": For MT7623A SoC + - "mediatek,mt7629-scpsys", "mediatek,mt7622-scpsys": For MT7629 SoC - "mediatek,mt8173-scpsys" - #power-domain-cells: Must be 1 - reg: Address range of the SCPSYS unit @@ -33,8 +34,8 @@ Required properties: Required clocks for MT2701 or MT7623: "mm", "mfg", "ethif" Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", "vdec" Required clocks for MT6797: "mm", "mfg", "vdec" - Required clocks for MT7622: "hif_sel" - Required clocks for MT7622A: "ethif" + Required clocks for MT7622 or MT7629: "hif_sel" + Required clocks for MT7623A: "ethif" Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt" Optional properties: diff --git a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt new file mode 100644 index 000000000000..703979dbd577 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt @@ -0,0 +1,33 @@ +Amazon's Annapurna Labs Thermal Sensor + +Simple thermal device that allows temperature reading by a single MMIO +transaction. + +Required properties: +- compatible: "amazon,al-thermal". +- reg: The physical base address and length of the sensor's registers. +- #thermal-sensor-cells: Must be 1. See ./thermal.txt for a description. + +Example: + thermal: thermal { + compatible = "amazon,al-thermal"; + reg = <0x0 0x05002860 0x0 0x1>; + #thermal-sensor-cells = <0x1>; + }; + + thermal-zones { + thermal-z0 { + polling-delay-passive = <250>; + polling-delay = <1000>; + thermal-sensors = <&thermal 0>; + trips { + critical { + temperature = <105000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + + }; + }; + diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt index b6c0ae53d4dc..f02f38527a6b 100644 --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt @@ -52,13 +52,47 @@ Required properties : Must set as following values: TEGRA_SOCTHERM_THROT_LEVEL_LOW, TEGRA_SOCTHERM_THROT_LEVEL_MED TEGRA_SOCTHERM_THROT_LEVEL_HIGH, TEGRA_SOCTHERM_THROT_LEVEL_NONE + - nvidia,gpu-throt-level: This property is for Tegra124 and Tegra210. + It is the level of pulse skippers, which used to throttle clock + frequencies. It indicates gpu clock throttling depth and can be + programmed to any of the following values which represent a throttling + percentage: + TEGRA_SOCTHERM_THROT_LEVEL_NONE (0%) + TEGRA_SOCTHERM_THROT_LEVEL_LOW (50%), + TEGRA_SOCTHERM_THROT_LEVEL_MED (75%), + TEGRA_SOCTHERM_THROT_LEVEL_HIGH (85%). - #cooling-cells: Should be 1. This cooling device only support on/off state. See ./thermal.txt for a description of this property. + Optional properties: The following properties are T210 specific and + valid only for OCx throttle events. + - nvidia,count-threshold: Specifies the number of OC events that are + required for triggering an interrupt. Interrupts are not triggered if + the property is missing. A value of 0 will interrupt on every OC alarm. + - nvidia,polarity-active-low: Configures the polarity of the OC alaram + signal. If present, this means assert low, otherwise assert high. + - nvidia,alarm-filter: Number of clocks to filter event. When the filter + expires (which means the OC event has not occurred for a long time), + the counter is cleared and filter is rearmed. Default value is 0. + - nvidia,throttle-period-us: Specifies the number of uSec for which + throttling is engaged after the OC event is deasserted. Default value + is 0. + +Optional properties: +- nvidia,thermtrips : When present, this property specifies the temperature at + which the soctherm hardware will assert the thermal trigger signal to the + Power Management IC, which can be configured to reset or shutdown the device. + It is an array of pairs where each pair represents a tsensor id followed by a + temperature in milli Celcius. In the absence of this property the critical + trip point will be used for thermtrip temperature. + Note: -- the "critical" type trip points will be set to SOC_THERM hardware as the -shut down temperature. Once the temperature of this thermal zone is higher -than it, the system will be shutdown or reset by hardware. +- the "critical" type trip points will be used to set the temperature at which +the SOC_THERM hardware will assert a thermal trigger if the "nvidia,thermtrips" +property is missing. When the thermtrips property is present, the breach of a +critical trip point is reported back to the thermal framework to implement +software shutdown. + - the "hot" type trip points will be set to SOC_THERM hardware as the throttle temperature. Once the the temperature of this thermal zone is higher than it, it will trigger the HW throttle event. @@ -79,25 +113,32 @@ Example : #thermal-sensor-cells = <1>; + nvidia,thermtrips = <TEGRA124_SOCTHERM_SENSOR_CPU 102500 + TEGRA124_SOCTHERM_SENSOR_GPU 103000>; + throttle-cfgs { /* * When the "heavy" cooling device triggered, - * the HW will skip cpu clock's pulse in 85% depth + * the HW will skip cpu clock's pulse in 85% depth, + * skip gpu clock's pulse in 85% level */ throttle_heavy: heavy { nvidia,priority = <100>; nvidia,cpu-throt-percent = <85>; + nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>; #cooling-cells = <1>; }; /* * When the "light" cooling device triggered, - * the HW will skip cpu clock's pulse in 50% depth + * the HW will skip cpu clock's pulse in 50% depth, + * skip gpu clock's pulse in 50% level */ throttle_light: light { nvidia,priority = <80>; nvidia,cpu-throt-percent = <50>; + nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_LOW>; #cooling-cells = <1>; }; @@ -107,6 +148,17 @@ Example : * arbiter will select the highest priority as the final throttle * settings to skip cpu pulse. */ + + throttle_oc1: oc1 { + nvidia,priority = <50>; + nvidia,polarity-active-low; + nvidia,count-threshold = <100>; + nvidia,alarm-filter = <5100000>; + nvidia,throttle-period-us = <0>; + nvidia,cpu-throt-percent = <75>; + nvidia,gpu-throt-level = + <TEGRA_SOCTHERM_THROT_LEVEL_MED>; + }; }; }; diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt index 1d9e8cf61018..673cc1831ee9 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt @@ -6,11 +6,14 @@ Required properties: - "qcom,msm8916-tsens" (MSM8916) - "qcom,msm8974-tsens" (MSM8974) - "qcom,msm8996-tsens" (MSM8996) + - "qcom,qcs404-tsens", "qcom,tsens-v1" (QCS404) - "qcom,msm8998-tsens", "qcom,tsens-v2" (MSM8998) - "qcom,sdm845-tsens", "qcom,tsens-v2" (SDM845) The generic "qcom,tsens-v2" property must be used as a fallback for any SoC with version 2 of the TSENS IP. MSM8996 is the only exception because the generic property did not exist when support was added. + Similarly, the generic "qcom,tsens-v1" property must be used as a fallback for + any SoC with version 1 of the TSENS IP. - reg: Address range of the thermal registers. New platforms containing v2.x.y of the TSENS IP must specify the SROT and TM @@ -39,3 +42,14 @@ tsens0: thermal-sensor@c263000 { #qcom,sensors = <13>; #thermal-sensor-cells = <1>; }; + +Example 3 (for any platform containing v1 of the TSENS IP): +tsens: thermal-sensor@4a9000 { + compatible = "qcom,qcs404-tsens", "qcom,tsens-v1"; + reg = <0x004a9000 0x1000>, /* TM */ + <0x004a8000 0x1000>; /* SROT */ + nvmem-cells = <&tsens_caldata>; + nvmem-cell-names = "calib"; + #qcom,sensors = <10>; + #thermal-sensor-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index 43d744e5305e..c6aac9bcacf1 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt @@ -2,6 +2,7 @@ Required properties: - compatible : should be "rockchip,<name>-tsadc" + "rockchip,px30-tsadc": found on PX30 SoCs "rockchip,rv1108-tsadc": found on RV1108 SoCs "rockchip,rk3228-tsadc": found on RK3228 SoCs "rockchip,rk3288-tsadc": found on RK3288 SoCs diff --git a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt index d72355502b78..691a09db2fef 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt +++ b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt @@ -8,16 +8,22 @@ temperature using voltage-temperature lookup table. Required properties: =================== - compatible: Must be "generic-adc-thermal". +- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description + of this property. +Optional properties: +=================== - temperature-lookup-table: Two dimensional array of Integer; lookup table to map the relation between ADC value and temperature. When ADC is read, the value is looked up on the table to get the equivalent temperature. + The first value of the each row of array is the temperature in milliCelsius and second value of the each row of array is the ADC read value. -- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description - of this property. + + If not specified, driver assumes the ADC channel + gives milliCelsius directly. Example : #include <dt-bindings/thermal/thermal.h> diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt index 5c2e23574ca0..3da9d515c03a 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt @@ -2,7 +2,9 @@ Allwinner A1X SoCs Timer Controller Required properties: -- compatible : should be "allwinner,sun4i-a10-timer" +- compatible : should be one of the following: + "allwinner,sun4i-a10-timer" + "allwinner,suniv-f1c100s-timer" - reg : Specifies base physical address and size of the registers. - interrupts : The interrupt of the first timer - clocks: phandle to the source clock (usually a 24 MHz fixed clock) diff --git a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml new file mode 100644 index 000000000000..a36a0746c056 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2018 Linaro Ltd. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/timer/intel-ixp4xx-timer.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Intel IXP4xx XScale Networking Processors Timers + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: This timer is found in the Intel IXP4xx processors. + +properties: + compatible: + items: + - const: intel,ixp4xx-timer + + reg: + description: Should contain registers location and length + + interrupts: + minItems: 1 + maxItems: 2 + items: + - description: Timer 1 interrupt + - description: Timer 2 interrupt + +required: + - compatible + - reg + - interrupts + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + timer@c8005000 { + compatible = "intel,ixp4xx-timer"; + reg = <0xc8005000 0x100>; + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt index ff7c567a7972..74c3eadad844 100644 --- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt +++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt @@ -17,6 +17,7 @@ Required properties: * "mediatek,mt8127-timer" for MT8127 compatible timers (GPT) * "mediatek,mt8135-timer" for MT8135 compatible timers (GPT) * "mediatek,mt8173-timer" for MT8173 compatible timers (GPT) + * "mediatek,mt8516-timer" for MT8516 compatible timers (GPT) * "mediatek,mt6577-timer" for MT6577 and all above compatible timers (GPT) For those SoCs that use SYST diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index 56bccde9953a..a74720486ee2 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -11,6 +11,7 @@ Required properties: the appropriate jedec string: "qcom,msm8994-ufshc", "qcom,ufshc", "jedec,ufs-2.0" "qcom,msm8996-ufshc", "qcom,ufshc", "jedec,ufs-2.0" + "qcom,msm8998-ufshc", "qcom,ufshc", "jedec,ufs-2.0" "qcom,sdm845-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - interrupts : <interrupt mapping for UFS host controller IRQ> - reg : <registers mapping> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt deleted file mode 100644 index e0e216002efd..000000000000 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ /dev/null @@ -1,469 +0,0 @@ -Device tree binding vendor prefix registry. Keep list in alphabetical order. - -This isn't an exhaustive list, but you should add new prefixes to it before -using them to avoid name-space collisions. - -abilis Abilis Systems -abracon Abracon Corporation -actions Actions Semiconductor Co., Ltd. -active-semi Active-Semi International Inc -ad Avionic Design GmbH -adafruit Adafruit Industries, LLC -adapteva Adapteva, Inc. -adaptrum Adaptrum, Inc. -adh AD Holdings Plc. -adi Analog Devices, Inc. -advantech Advantech Corporation -aeroflexgaisler Aeroflex Gaisler AB -al Annapurna Labs -allo Allo.com -allwinner Allwinner Technology Co., Ltd. -alphascale AlphaScale Integrated Circuits Systems, Inc. -altr Altera Corp. -amarula Amarula Solutions -amazon Amazon.com, Inc. -amcc Applied Micro Circuits Corporation (APM, formally AMCC) -amd Advanced Micro Devices (AMD), Inc. -amediatech Shenzhen Amediatech Technology Co., Ltd -amlogic Amlogic, Inc. -ampire Ampire Co., Ltd. -ams AMS AG -amstaos AMS-Taos Inc. -analogix Analogix Semiconductor, Inc. -andestech Andes Technology Corporation -apm Applied Micro Circuits Corporation (APM) -aptina Aptina Imaging -arasan Arasan Chip Systems -archermind ArcherMind Technology (Nanjing) Co., Ltd. -arctic Arctic Sand -arcx arcx Inc. / Archronix Inc. -aries Aries Embedded GmbH -arm ARM Ltd. -armadeus ARMadeus Systems SARL -arrow Arrow Electronics -artesyn Artesyn Embedded Technologies Inc. -asahi-kasei Asahi Kasei Corp. -aspeed ASPEED Technology Inc. -asus AsusTek Computer Inc. -atlas Atlas Scientific LLC -atmel Atmel Corporation -auo AU Optronics Corporation -auvidea Auvidea GmbH -avago Avago Technologies -avia avia semiconductor -avic Shanghai AVIC Optoelectronics Co., Ltd. -avnet Avnet, Inc. -axentia Axentia Technologies AB -axis Axis Communications AB -azoteq Azoteq (Pty) Ltd -bananapi BIPAI KEJI LIMITED -bhf Beckhoff Automation GmbH & Co. KG -bitmain Bitmain Technologies -boe BOE Technology Group Co., Ltd. -bosch Bosch Sensortec GmbH -boundary Boundary Devices Inc. -brcm Broadcom Corporation -buffalo Buffalo, Inc. -bticino Bticino International -calxeda Calxeda -capella Capella Microsystems, Inc -cascoda Cascoda, Ltd. -catalyst Catalyst Semiconductor, Inc. -cavium Cavium, Inc. -cdns Cadence Design Systems Inc. -cdtech CDTech(H.K.) Electronics Limited -ceva Ceva, Inc. -chipidea Chipidea, Inc -chipone ChipOne -chipspark ChipSPARK -chrp Common Hardware Reference Platform -chunghwa Chunghwa Picture Tubes Ltd. -ciaa Computadora Industrial Abierta Argentina -cirrus Cirrus Logic, Inc. -cloudengines Cloud Engines, Inc. -cnm Chips&Media, Inc. -cnxt Conexant Systems, Inc. -compulab CompuLab Ltd. -cortina Cortina Systems, Inc. -cosmic Cosmic Circuits -crane Crane Connectivity Solutions -creative Creative Technology Ltd -crystalfontz Crystalfontz America, Inc. -csky Hangzhou C-SKY Microsystems Co., Ltd -cubietech Cubietech, Ltd. -cypress Cypress Semiconductor Corporation -cznic CZ.NIC, z.s.p.o. -dallas Maxim Integrated Products (formerly Dallas Semiconductor) -dataimage DataImage, Inc. -davicom DAVICOM Semiconductor, Inc. -delta Delta Electronics, Inc. -denx Denx Software Engineering -devantech Devantech, Ltd. -dh DH electronics GmbH -digi Digi International Inc. -digilent Diglent, Inc. -dioo Dioo Microcircuit Co., Ltd -dlc DLC Display Co., Ltd. -dlg Dialog Semiconductor -dlink D-Link Corporation -dmo Data Modul AG -domintech Domintech Co., Ltd. -dongwoon Dongwoon Anatech -dptechnics DPTechnics -dragino Dragino Technology Co., Limited -ea Embedded Artists AB -ebs-systart EBS-SYSTART GmbH -ebv EBV Elektronik -eckelmann Eckelmann AG -edt Emerging Display Technologies -eeti eGalax_eMPIA Technology Inc -elan Elan Microelectronic Corp. -elgin Elgin S/A. -embest Shenzhen Embest Technology Co., Ltd. -emlid Emlid, Ltd. -emmicro EM Microelectronic -emtrion emtrion GmbH -endless Endless Mobile, Inc. -energymicro Silicon Laboratories (formerly Energy Micro AS) -engicam Engicam S.r.l. -epcos EPCOS AG -epfl Ecole Polytechnique Fédérale de Lausanne -epson Seiko Epson Corp. -est ESTeem Wireless Modems -ettus NI Ettus Research -eukrea Eukréa Electromatique -everest Everest Semiconductor Co. Ltd. -everspin Everspin Technologies, Inc. -exar Exar Corporation -excito Excito -ezchip EZchip Semiconductor -facebook Facebook -fairphone Fairphone B.V. -faraday Faraday Technology Corporation -fastrax Fastrax Oy -fcs Fairchild Semiconductor -feiyang Shenzhen Fly Young Technology Co.,LTD. -firefly Firefly -focaltech FocalTech Systems Co.,Ltd -friendlyarm Guangzhou FriendlyARM Computer Tech Co., Ltd -fsl Freescale Semiconductor -fujitsu Fujitsu Ltd. -gateworks Gateworks Corporation -gcw Game Consoles Worldwide -ge General Electric Company -geekbuying GeekBuying -gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. -GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. -geniatech Geniatech, Inc. -giantec Giantec Semiconductor, Inc. -giantplus Giantplus Technology Co., Ltd. -globalscale Globalscale Technologies, Inc. -globaltop GlobalTop Technology, Inc. -gmt Global Mixed-mode Technology, Inc. -goodix Shenzhen Huiding Technology Co., Ltd. -google Google, Inc. -grinn Grinn -grmn Garmin Limited -gumstix Gumstix, Inc. -gw Gateworks Corporation -hannstar HannStar Display Corporation -haoyu Haoyu Microelectronic Co. Ltd. -hardkernel Hardkernel Co., Ltd -hideep HiDeep Inc. -himax Himax Technologies, Inc. -hisilicon Hisilicon Limited. -hit Hitachi Ltd. -hitex Hitex Development Tools -holt Holt Integrated Circuits, Inc. -honeywell Honeywell -hp Hewlett Packard -holtek Holtek Semiconductor, Inc. -hwacom HwaCom Systems Inc. -i2se I2SE GmbH -ibm International Business Machines (IBM) -icplus IC Plus Corp. -idt Integrated Device Technologies, Inc. -ifi Ingenieurburo Fur Ic-Technologie (I/F/I) -ilitek ILI Technology Corporation (ILITEK) -img Imagination Technologies Ltd. -infineon Infineon Technologies -inforce Inforce Computing -ingenic Ingenic Semiconductor -innolux Innolux Corporation -inside-secure INSIDE Secure -intel Intel Corporation -intercontrol Inter Control Group -invensense InvenSense Inc. -inversepath Inverse Path -iom Iomega Corporation -isee ISEE 2007 S.L. -isil Intersil -issi Integrated Silicon Solutions Inc. -itead ITEAD Intelligent Systems Co.Ltd -iwave iWave Systems Technologies Pvt. Ltd. -jdi Japan Display Inc. -jedec JEDEC Solid State Technology Association -jianda Jiandangjing Technology Co., Ltd. -karo Ka-Ro electronics GmbH -keithkoep Keith & Koep GmbH -keymile Keymile GmbH -khadas Khadas -kiebackpeter Kieback & Peter GmbH -kinetic Kinetic Technologies -kingdisplay King & Display Technology Co., Ltd. -kingnovel Kingnovel Technology Co., Ltd. -kionix Kionix, Inc. -koe Kaohsiung Opto-Electronics Inc. -kosagi Sutajio Ko-Usagi PTE Ltd. -kyo Kyocera Corporation -lacie LaCie -laird Laird PLC -lantiq Lantiq Semiconductor -lattice Lattice Semiconductor -lego LEGO Systems A/S -lemaker Shenzhen LeMaker Technology Co., Ltd. -lenovo Lenovo Group Ltd. -lg LG Corporation -libretech Shenzhen Libre Technology Co., Ltd -licheepi Lichee Pi -linaro Linaro Limited -linksys Belkin International, Inc. (Linksys) -linux Linux-specific binding -linx Linx Technologies -lltc Linear Technology Corporation -logicpd Logic PD, Inc. -lsi LSI Corp. (LSI Logic) -lwn Liebherr-Werk Nenzing GmbH -macnica Macnica Americas -marvell Marvell Technology Group Ltd. -maxbotix MaxBotix Inc. -maxim Maxim Integrated Products -mbvl Mobiveil Inc. -mcube mCube -meas Measurement Specialties -mediatek MediaTek Inc. -megachips MegaChips -mele Shenzhen MeLE Digital Technology Ltd. -melexis Melexis N.V. -melfas MELFAS Inc. -mellanox Mellanox Technologies -memsic MEMSIC Inc. -merrii Merrii Technology Co., Ltd. -micrel Micrel Inc. -microchip Microchip Technology Inc. -microcrystal Micro Crystal AG -micron Micron Technology Inc. -mikroe MikroElektronika d.o.o. -minix MINIX Technology Ltd. -miramems MiraMEMS Sensing Technology Co., Ltd. -mitsubishi Mitsubishi Electric Corporation -mosaixtech Mosaix Technologies, Inc. -motorola Motorola, Inc. -moxa Moxa Inc. -mpl MPL AG -mqmaker mqmaker Inc. -mscc Microsemi Corporation -msi Micro-Star International Co. Ltd. -mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) -multi-inno Multi-Inno Technology Co.,Ltd -mundoreader Mundo Reader S.L. -murata Murata Manufacturing Co., Ltd. -mxicy Macronix International Co., Ltd. -myir MYIR Tech Limited -national National Semiconductor -nec NEC LCD Technologies, Ltd. -neonode Neonode Inc. -netgear NETGEAR -netlogic Broadcom Corporation (formerly NetLogic Microsystems) -netron-dy Netron DY -netxeon Shenzhen Netxeon Technology CO., LTD -nexbox Nexbox -nextthing Next Thing Co. -newhaven Newhaven Display International -ni National Instruments -nintendo Nintendo -nlt NLT Technologies, Ltd. -nokia Nokia -nordic Nordic Semiconductor -novtech NovTech, Inc. -nutsboard NutsBoard -nuvoton Nuvoton Technology Corporation -nvd New Vision Display -nvidia NVIDIA -nxp NXP Semiconductors -okaya Okaya Electric America, Inc. -oki Oki Electric Industry Co., Ltd. -olimex OLIMEX Ltd. -olpc One Laptop Per Child -onion Onion Corporation -onnn ON Semiconductor Corp. -ontat On Tat Industrial Company -opalkelly Opal Kelly Incorporated -opencores OpenCores.org -openrisc OpenRISC.io -option Option NV -oranth Shenzhen Oranth Technology Co., Ltd. -ORCL Oracle Corporation -orisetech Orise Technology -ortustech Ortus Technology Co., Ltd. -osddisplays OSD Displays -ovti OmniVision Technologies -oxsemi Oxford Semiconductor, Ltd. -panasonic Panasonic Corporation -parade Parade Technologies Inc. -pda Precision Design Associates, Inc. -pericom Pericom Technology Inc. -pervasive Pervasive Displays, Inc. -phicomm PHICOMM Co., Ltd. -phytec PHYTEC Messtechnik GmbH -picochip Picochip Ltd -pine64 Pine64 -pixcir PIXCIR MICROELECTRONICS Co., Ltd -plantower Plantower Co., Ltd -plathome Plat'Home Co., Ltd. -plda PLDA -plx Broadcom Corporation (formerly PLX Technology) -pni PNI Sensor Corporation -portwell Portwell Inc. -poslab Poslab Technology Co., Ltd. -powervr PowerVR (deprecated, use img) -probox2 PROBOX2 (by W2COMP Co., Ltd.) -pulsedlight PulsedLight, Inc -qca Qualcomm Atheros, Inc. -qcom Qualcomm Technologies, Inc -qemu QEMU, a generic and open source machine emulator and virtualizer -qi Qi Hardware -qiaodian QiaoDian XianShi Corporation -qnap QNAP Systems, Inc. -radxa Radxa -raidsonic RaidSonic Technology GmbH -ralink Mediatek/Ralink Technology Corp. -ramtron Ramtron International -raspberrypi Raspberry Pi Foundation -raydium Raydium Semiconductor Corp. -rda Unisoc Communications, Inc. -realtek Realtek Semiconductor Corp. -renesas Renesas Electronics Corporation -richtek Richtek Technology Corporation -ricoh Ricoh Co. Ltd. -rikomagic Rikomagic Tech Corp. Ltd -riscv RISC-V Foundation -rockchip Fuzhou Rockchip Electronics Co., Ltd -rocktech ROCKTECH DISPLAYS LIMITED -rohm ROHM Semiconductor Co., Ltd -ronbo Ronbo Electronics -roofull Shenzhen Roofull Technology Co, Ltd -samsung Samsung Semiconductor -samtec Samtec/Softing company -sancloud Sancloud Ltd -sandisk Sandisk Corporation -sbs Smart Battery System -schindler Schindler -seagate Seagate Technology PLC -semtech Semtech Corporation -sensirion Sensirion AG -sff Small Form Factor Committee -sgd Solomon Goldentek Display Corporation -sgx SGX Sensortech -sharp Sharp Corporation -shimafuji Shimafuji Electric, Inc. -si-en Si-En Technology Ltd. -sifive SiFive, Inc. -sigma Sigma Designs, Inc. -sii Seiko Instruments, Inc. -sil Silicon Image -silabs Silicon Laboratories -silead Silead Inc. -silergy Silergy Corp. -siliconmitus Silicon Mitus, Inc. -simtek -sirf SiRF Technology, Inc. -sis Silicon Integrated Systems Corp. -sitronix Sitronix Technology Corporation -skyworks Skyworks Solutions, Inc. -smsc Standard Microsystems Corporation -snps Synopsys, Inc. -socionext Socionext Inc. -solidrun SolidRun -solomon Solomon Systech Limited -sony Sony Corporation -spansion Spansion Inc. -sprd Spreadtrum Communications Inc. -sst Silicon Storage Technology, Inc. -st STMicroelectronics -starry Starry Electronic Technology (ShenZhen) Co., LTD -startek Startek -ste ST-Ericsson -stericsson ST-Ericsson -summit Summit microelectronics -sunchip Shenzhen Sunchip Technology Co., Ltd -SUNW Sun Microsystems, Inc -swir Sierra Wireless -syna Synaptics Inc. -synology Synology, Inc. -tbs TBS Technologies -tbs-biometrics Touchless Biometric Systems AG -tcg Trusted Computing Group -tcl Toby Churchill Ltd. -technexion TechNexion -technologic Technologic Systems -tempo Tempo Semiconductor -techstar Shenzhen Techstar Electronics Co., Ltd. -terasic Terasic Inc. -thine THine Electronics, Inc. -ti Texas Instruments -tianma Tianma Micro-electronics Co., Ltd. -tlm Trusted Logic Mobility -tmt Tecon Microprocessor Technologies, LLC. -topeet Topeet -toradex Toradex AG -toshiba Toshiba Corporation -toumaz Toumaz -tpk TPK U.S.A. LLC -tplink TP-LINK Technologies Co., Ltd. -tpo TPO -tronfy Tronfy -tronsmart Tronsmart -truly Truly Semiconductors Limited -tsd Theobroma Systems Design und Consulting GmbH -tyan Tyan Computer Corporation -u-blox u-blox -ucrobotics uCRobotics -ubnt Ubiquiti Networks -udoo Udoo -uniwest United Western Technologies Corp (UniWest) -upisemi uPI Semiconductor Corp. -urt United Radiant Technology Corporation -usi Universal Scientific Industrial Co., Ltd. -v3 V3 Semiconductor -vamrs Vamrs Ltd. -variscite Variscite Ltd. -via VIA Technologies, Inc. -virtio Virtual I/O Device Specification, developed by the OASIS consortium -vishay Vishay Intertechnology, Inc -vitesse Vitesse Semiconductor Corporation -vivante Vivante Corporation -vocore VoCore Studio -voipac Voipac Technologies s.r.o. -vot Vision Optical Technology Co., Ltd. -wd Western Digital Corp. -wetek WeTek Electronics, limited. -wexler Wexler -whwave Shenzhen whwave Electronics, Inc. -wi2wi Wi2Wi, Inc. -winbond Winbond Electronics corp. -winstar Winstar Display Corp. -wlf Wolfson Microelectronics -wm Wondermedia Technologies, Inc. -x-powers X-Powers -xes Extreme Engineering Solutions (X-ES) -xillybus Xillybus Ltd. -xlnx Xilinx -xunlong Shenzhen Xunlong Software CO.,Limited -ysoft Y Soft Corporation a.s. -zarlink Zarlink Semiconductor -zeitec ZEITEC Semiconductor Co., LTD. -zidoo Shenzhen Zidoo Technology Co., Ltd. -zii Zodiac Inflight Innovations -zte ZTE Corp. -zyxel ZyXEL Communications Corp. diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml new file mode 100644 index 000000000000..33a65a45e319 --- /dev/null +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -0,0 +1,977 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/vendor-prefixes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Devicetree Vendor Prefix Registry + +maintainers: + - Rob Herring <robh@kernel.org> + +select: true + +properties: {} + +patternProperties: + # Prefixes which are not vendors, but followed the pattern + # DO NOT ADD NEW PROPERTIES TO THIS LIST + "^(at25|devbus|dmacap|dsa|exynos|gpio-fan|gpio|gpmc|hdmi|i2c-gpio),.*": true + "^(keypad|m25p|max8952|max8997|max8998|mpmc),.*": true + "^(pinctrl-single|#pinctrl-single|PowerPC),.*": true + "^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*": true + "^(simple-audio-card|simple-graph-card|st-plgpio|st-spics|ts),.*": true + + # Keep list in alphabetical order. + "^abilis,.*": + description: Abilis Systems + "^abracon,.*": + description: Abracon Corporation + "^actions,.*": + description: Actions Semiconductor Co., Ltd. + "^active-semi,.*": + description: Active-Semi International Inc + "^ad,.*": + description: Avionic Design GmbH + "^adafruit,.*": + description: Adafruit Industries, LLC + "^adapteva,.*": + description: Adapteva, Inc. + "^adaptrum,.*": + description: Adaptrum, Inc. + "^adh,.*": + description: AD Holdings Plc. + "^adi,.*": + description: Analog Devices, Inc. + "^advantech,.*": + description: Advantech Corporation + "^aeroflexgaisler,.*": + description: Aeroflex Gaisler AB + "^al,.*": + description: Annapurna Labs + "^allo,.*": + description: Allo.com + "^allwinner,.*": + description: Allwinner Technology Co., Ltd. + "^alphascale,.*": + description: AlphaScale Integrated Circuits Systems, Inc. + "^altr,.*": + description: Altera Corp. + "^amarula,.*": + description: Amarula Solutions + "^amazon,.*": + description: Amazon.com, Inc. + "^amcc,.*": + description: Applied Micro Circuits Corporation (APM, formally AMCC) + "^amd,.*": + description: Advanced Micro Devices (AMD), Inc. + "^amediatech,.*": + description: Shenzhen Amediatech Technology Co., Ltd + "^amlogic,.*": + description: Amlogic, Inc. + "^ampire,.*": + description: Ampire Co., Ltd. + "^ams,.*": + description: AMS AG + "^amstaos,.*": + description: AMS-Taos Inc. + "^analogix,.*": + description: Analogix Semiconductor, Inc. + "^andestech,.*": + description: Andes Technology Corporation + "^apm,.*": + description: Applied Micro Circuits Corporation (APM) + "^aptina,.*": + description: Aptina Imaging + "^arasan,.*": + description: Arasan Chip Systems + "^archermind,.*": + description: ArcherMind Technology (Nanjing) Co., Ltd. + "^arctic,.*": + description: Arctic Sand + "^arcx,.*": + description: arcx Inc. / Archronix Inc. + "^aries,.*": + description: Aries Embedded GmbH + "^arm,.*": + description: ARM Ltd. + "^armadeus,.*": + description: ARMadeus Systems SARL + "^arrow,.*": + description: Arrow Electronics + "^artesyn,.*": + description: Artesyn Embedded Technologies Inc. + "^asahi-kasei,.*": + description: Asahi Kasei Corp. + "^aspeed,.*": + description: ASPEED Technology Inc. + "^asus,.*": + description: AsusTek Computer Inc. + "^atlas,.*": + description: Atlas Scientific LLC + "^atmel,.*": + description: Atmel Corporation + "^auo,.*": + description: AU Optronics Corporation + "^auvidea,.*": + description: Auvidea GmbH + "^avago,.*": + description: Avago Technologies + "^avia,.*": + description: avia semiconductor + "^avic,.*": + description: Shanghai AVIC Optoelectronics Co., Ltd. + "^avnet,.*": + description: Avnet, Inc. + "^axentia,.*": + description: Axentia Technologies AB + "^axis,.*": + description: Axis Communications AB + "^azoteq,.*": + description: Azoteq (Pty) Ltd + "^azw,.*": + description: Shenzhen AZW Technology Co., Ltd. + "^bananapi,.*": + description: BIPAI KEJI LIMITED + "^bhf,.*": + description: Beckhoff Automation GmbH & Co. KG + "^bitmain,.*": + description: Bitmain Technologies + "^boe,.*": + description: BOE Technology Group Co., Ltd. + "^bosch,.*": + description: Bosch Sensortec GmbH + "^boundary,.*": + description: Boundary Devices Inc. + "^brcm,.*": + description: Broadcom Corporation + "^buffalo,.*": + description: Buffalo, Inc. + "^bticino,.*": + description: Bticino International + "^calxeda,.*": + description: Calxeda + "^capella,.*": + description: Capella Microsystems, Inc + "^cascoda,.*": + description: Cascoda, Ltd. + "^catalyst,.*": + description: Catalyst Semiconductor, Inc. + "^cavium,.*": + description: Cavium, Inc. + "^cdns,.*": + description: Cadence Design Systems Inc. + "^cdtech,.*": + description: CDTech(H.K.) Electronics Limited + "^ceva,.*": + description: Ceva, Inc. + "^chipidea,.*": + description: Chipidea, Inc + "^chipone,.*": + description: ChipOne + "^chipspark,.*": + description: ChipSPARK + "^chrp,.*": + description: Common Hardware Reference Platform + "^chunghwa,.*": + description: Chunghwa Picture Tubes Ltd. + "^ciaa,.*": + description: Computadora Industrial Abierta Argentina + "^cirrus,.*": + description: Cirrus Logic, Inc. + "^cloudengines,.*": + description: Cloud Engines, Inc. + "^cnm,.*": + description: Chips&Media, Inc. + "^cnxt,.*": + description: Conexant Systems, Inc. + "^compulab,.*": + description: CompuLab Ltd. + "^cortina,.*": + description: Cortina Systems, Inc. + "^cosmic,.*": + description: Cosmic Circuits + "^crane,.*": + description: Crane Connectivity Solutions + "^creative,.*": + description: Creative Technology Ltd + "^crystalfontz,.*": + description: Crystalfontz America, Inc. + "^csky,.*": + description: Hangzhou C-SKY Microsystems Co., Ltd + "^cubietech,.*": + description: Cubietech, Ltd. + "^cypress,.*": + description: Cypress Semiconductor Corporation + "^cznic,.*": + description: CZ.NIC, z.s.p.o. + "^dallas,.*": + description: Maxim Integrated Products (formerly Dallas Semiconductor) + "^dataimage,.*": + description: DataImage, Inc. + "^davicom,.*": + description: DAVICOM Semiconductor, Inc. + "^delta,.*": + description: Delta Electronics, Inc. + "^denx,.*": + description: Denx Software Engineering + "^devantech,.*": + description: Devantech, Ltd. + "^dh,.*": + description: DH electronics GmbH + "^digi,.*": + description: Digi International Inc. + "^digilent,.*": + description: Diglent, Inc. + "^dioo,.*": + description: Dioo Microcircuit Co., Ltd + "^dlc,.*": + description: DLC Display Co., Ltd. + "^dlg,.*": + description: Dialog Semiconductor + "^dlink,.*": + description: D-Link Corporation + "^dmo,.*": + description: Data Modul AG + "^domintech,.*": + description: Domintech Co., Ltd. + "^dongwoon,.*": + description: Dongwoon Anatech + "^dptechnics,.*": + description: DPTechnics + "^dragino,.*": + description: Dragino Technology Co., Limited + "^ea,.*": + description: Embedded Artists AB + "^ebs-systart,.*": + description: EBS-SYSTART GmbH + "^ebv,.*": + description: EBV Elektronik + "^eckelmann,.*": + description: Eckelmann AG + "^edt,.*": + description: Emerging Display Technologies + "^eeti,.*": + description: eGalax_eMPIA Technology Inc + "^elan,.*": + description: Elan Microelectronic Corp. + "^elgin,.*": + description: Elgin S/A. + "^embest,.*": + description: Shenzhen Embest Technology Co., Ltd. + "^emlid,.*": + description: Emlid, Ltd. + "^emmicro,.*": + description: EM Microelectronic + "^emtrion,.*": + description: emtrion GmbH + "^endless,.*": + description: Endless Mobile, Inc. + "^energymicro,.*": + description: Silicon Laboratories (formerly Energy Micro AS) + "^engicam,.*": + description: Engicam S.r.l. + "^epcos,.*": + description: EPCOS AG + "^epfl,.*": + description: Ecole Polytechnique Fédérale de Lausanne + "^epson,.*": + description: Seiko Epson Corp. + "^est,.*": + description: ESTeem Wireless Modems + "^ettus,.*": + description: NI Ettus Research + "^eukrea,.*": + description: Eukréa Electromatique + "^everest,.*": + description: Everest Semiconductor Co. Ltd. + "^everspin,.*": + description: Everspin Technologies, Inc. + "^exar,.*": + description: Exar Corporation + "^excito,.*": + description: Excito + "^ezchip,.*": + description: EZchip Semiconductor + "^facebook,.*": + description: Facebook + "^fairphone,.*": + description: Fairphone B.V. + "^faraday,.*": + description: Faraday Technology Corporation + "^fastrax,.*": + description: Fastrax Oy + "^fcs,.*": + description: Fairchild Semiconductor + "^feiyang,.*": + description: Shenzhen Fly Young Technology Co.,LTD. + "^firefly,.*": + description: Firefly + "^focaltech,.*": + description: FocalTech Systems Co.,Ltd + "^friendlyarm,.*": + description: Guangzhou FriendlyARM Computer Tech Co., Ltd + "^fsl,.*": + description: Freescale Semiconductor + "^fujitsu,.*": + description: Fujitsu Ltd. + "^gateworks,.*": + description: Gateworks Corporation + "^gcw,.*": + description: Game Consoles Worldwide + "^ge,.*": + description: General Electric Company + "^geekbuying,.*": + description: GeekBuying + "^gef,.*": + description: GE Fanuc Intelligent Platforms Embedded Systems, Inc. + "^GEFanuc,.*": + description: GE Fanuc Intelligent Platforms Embedded Systems, Inc. + "^geniatech,.*": + description: Geniatech, Inc. + "^giantec,.*": + description: Giantec Semiconductor, Inc. + "^giantplus,.*": + description: Giantplus Technology Co., Ltd. + "^globalscale,.*": + description: Globalscale Technologies, Inc. + "^globaltop,.*": + description: GlobalTop Technology, Inc. + "^gmt,.*": + description: Global Mixed-mode Technology, Inc. + "^goodix,.*": + description: Shenzhen Huiding Technology Co., Ltd. + "^google,.*": + description: Google, Inc. + "^grinn,.*": + description: Grinn + "^grmn,.*": + description: Garmin Limited + "^gumstix,.*": + description: Gumstix, Inc. + "^gw,.*": + description: Gateworks Corporation + "^hannstar,.*": + description: HannStar Display Corporation + "^haoyu,.*": + description: Haoyu Microelectronic Co. Ltd. + "^hardkernel,.*": + description: Hardkernel Co., Ltd + "^hideep,.*": + description: HiDeep Inc. + "^himax,.*": + description: Himax Technologies, Inc. + "^hisilicon,.*": + description: Hisilicon Limited. + "^hit,.*": + description: Hitachi Ltd. + "^hitex,.*": + description: Hitex Development Tools + "^holt,.*": + description: Holt Integrated Circuits, Inc. + "^honeywell,.*": + description: Honeywell + "^hp,.*": + description: Hewlett Packard + "^holtek,.*": + description: Holtek Semiconductor, Inc. + "^hwacom,.*": + description: HwaCom Systems Inc. + "^i2se,.*": + description: I2SE GmbH + "^ibm,.*": + description: International Business Machines (IBM) + "^icplus,.*": + description: IC Plus Corp. + "^idt,.*": + description: Integrated Device Technologies, Inc. + "^ifi,.*": + description: Ingenieurburo Fur Ic-Technologie (I/F/I) + "^ilitek,.*": + description: ILI Technology Corporation (ILITEK) + "^img,.*": + description: Imagination Technologies Ltd. + "^infineon,.*": + description: Infineon Technologies + "^inforce,.*": + description: Inforce Computing + "^ingenic,.*": + description: Ingenic Semiconductor + "^innolux,.*": + description: Innolux Corporation + "^inside-secure,.*": + description: INSIDE Secure + "^intel,.*": + description: Intel Corporation + "^intercontrol,.*": + description: Inter Control Group + "^invensense,.*": + description: InvenSense Inc. + "^inversepath,.*": + description: Inverse Path + "^iom,.*": + description: Iomega Corporation + "^isee,.*": + description: ISEE 2007 S.L. + "^isil,.*": + description: Intersil + "^issi,.*": + description: Integrated Silicon Solutions Inc. + "^itead,.*": + description: ITEAD Intelligent Systems Co.Ltd + "^iwave,.*": + description: iWave Systems Technologies Pvt. Ltd. + "^jdi,.*": + description: Japan Display Inc. + "^jedec,.*": + description: JEDEC Solid State Technology Association + "^jianda,.*": + description: Jiandangjing Technology Co., Ltd. + "^karo,.*": + description: Ka-Ro electronics GmbH + "^keithkoep,.*": + description: Keith & Koep GmbH + "^keymile,.*": + description: Keymile GmbH + "^khadas,.*": + description: Khadas + "^kiebackpeter,.*": + description: Kieback & Peter GmbH + "^kinetic,.*": + description: Kinetic Technologies + "^kingdisplay,.*": + description: King & Display Technology Co., Ltd. + "^kingnovel,.*": + description: Kingnovel Technology Co., Ltd. + "^kionix,.*": + description: Kionix, Inc. + "^kobo,.*": + description: Rakuten Kobo Inc. + "^koe,.*": + description: Kaohsiung Opto-Electronics Inc. + "^kosagi,.*": + description: Sutajio Ko-Usagi PTE Ltd. + "^kyo,.*": + description: Kyocera Corporation + "^lacie,.*": + description: LaCie + "^laird,.*": + description: Laird PLC + "^lantiq,.*": + description: Lantiq Semiconductor + "^lattice,.*": + description: Lattice Semiconductor + "^lego,.*": + description: LEGO Systems A/S + "^lemaker,.*": + description: Shenzhen LeMaker Technology Co., Ltd. + "^lenovo,.*": + description: Lenovo Group Ltd. + "^lg,.*": + description: LG Corporation + "^libretech,.*": + description: Shenzhen Libre Technology Co., Ltd + "^licheepi,.*": + description: Lichee Pi + "^linaro,.*": + description: Linaro Limited + "^linksys,.*": + description: Belkin International, Inc. (Linksys) + "^linux,.*": + description: Linux-specific binding + "^linx,.*": + description: Linx Technologies + "^lltc,.*": + description: Linear Technology Corporation + "^logicpd,.*": + description: Logic PD, Inc. + "^lsi,.*": + description: LSI Corp. (LSI Logic) + "^lwn,.*": + description: Liebherr-Werk Nenzing GmbH + "^macnica,.*": + description: Macnica Americas + "^marvell,.*": + description: Marvell Technology Group Ltd. + "^maxbotix,.*": + description: MaxBotix Inc. + "^maxim,.*": + description: Maxim Integrated Products + "^mbvl,.*": + description: Mobiveil Inc. + "^mcube,.*": + description: mCube + "^meas,.*": + description: Measurement Specialties + "^mediatek,.*": + description: MediaTek Inc. + "^megachips,.*": + description: MegaChips + "^mele,.*": + description: Shenzhen MeLE Digital Technology Ltd. + "^melexis,.*": + description: Melexis N.V. + "^melfas,.*": + description: MELFAS Inc. + "^mellanox,.*": + description: Mellanox Technologies + "^memsic,.*": + description: MEMSIC Inc. + "^menlo,.*": + description: Menlo Systems GmbH + "^merrii,.*": + description: Merrii Technology Co., Ltd. + "^micrel,.*": + description: Micrel Inc. + "^microchip,.*": + description: Microchip Technology Inc. + "^microcrystal,.*": + description: Micro Crystal AG + "^micron,.*": + description: Micron Technology Inc. + "^mikroe,.*": + description: MikroElektronika d.o.o. + "^minix,.*": + description: MINIX Technology Ltd. + "^miramems,.*": + description: MiraMEMS Sensing Technology Co., Ltd. + "^mitsubishi,.*": + description: Mitsubishi Electric Corporation + "^mosaixtech,.*": + description: Mosaix Technologies, Inc. + "^motorola,.*": + description: Motorola, Inc. + "^moxa,.*": + description: Moxa Inc. + "^mpl,.*": + description: MPL AG + "^mqmaker,.*": + description: mqmaker Inc. + "^mscc,.*": + description: Microsemi Corporation + "^msi,.*": + description: Micro-Star International Co. Ltd. + "^mti,.*": + description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) + "^multi-inno,.*": + description: Multi-Inno Technology Co.,Ltd + "^mundoreader,.*": + description: Mundo Reader S.L. + "^murata,.*": + description: Murata Manufacturing Co., Ltd. + "^mxicy,.*": + description: Macronix International Co., Ltd. + "^myir,.*": + description: MYIR Tech Limited + "^national,.*": + description: National Semiconductor + "^nec,.*": + description: NEC LCD Technologies, Ltd. + "^neonode,.*": + description: Neonode Inc. + "^netgear,.*": + description: NETGEAR + "^netlogic,.*": + description: Broadcom Corporation (formerly NetLogic Microsystems) + "^netron-dy,.*": + description: Netron DY + "^netxeon,.*": + description: Shenzhen Netxeon Technology CO., LTD + "^nexbox,.*": + description: Nexbox + "^nextthing,.*": + description: Next Thing Co. + "^newhaven,.*": + description: Newhaven Display International + "^ni,.*": + description: National Instruments + "^nintendo,.*": + description: Nintendo + "^nlt,.*": + description: NLT Technologies, Ltd. + "^nokia,.*": + description: Nokia + "^nordic,.*": + description: Nordic Semiconductor + "^novtech,.*": + description: NovTech, Inc. + "^nutsboard,.*": + description: NutsBoard + "^nuvoton,.*": + description: Nuvoton Technology Corporation + "^nvd,.*": + description: New Vision Display + "^nvidia,.*": + description: NVIDIA + "^nxp,.*": + description: NXP Semiconductors + "^oceanic,.*": + description: Oceanic Systems (UK) Ltd. + "^okaya,.*": + description: Okaya Electric America, Inc. + "^oki,.*": + description: Oki Electric Industry Co., Ltd. + "^olimex,.*": + description: OLIMEX Ltd. + "^olpc,.*": + description: One Laptop Per Child + "^onion,.*": + description: Onion Corporation + "^onnn,.*": + description: ON Semiconductor Corp. + "^ontat,.*": + description: On Tat Industrial Company + "^opalkelly,.*": + description: Opal Kelly Incorporated + "^opencores,.*": + description: OpenCores.org + "^openrisc,.*": + description: OpenRISC.io + "^option,.*": + description: Option NV + "^oranth,.*": + description: Shenzhen Oranth Technology Co., Ltd. + "^ORCL,.*": + description: Oracle Corporation + "^orisetech,.*": + description: Orise Technology + "^ortustech,.*": + description: Ortus Technology Co., Ltd. + "^osddisplays,.*": + description: OSD Displays + "^ovti,.*": + description: OmniVision Technologies + "^oxsemi,.*": + description: Oxford Semiconductor, Ltd. + "^panasonic,.*": + description: Panasonic Corporation + "^parade,.*": + description: Parade Technologies Inc. + "^pda,.*": + description: Precision Design Associates, Inc. + "^pericom,.*": + description: Pericom Technology Inc. + "^pervasive,.*": + description: Pervasive Displays, Inc. + "^phicomm,.*": + description: PHICOMM Co., Ltd. + "^phytec,.*": + description: PHYTEC Messtechnik GmbH + "^picochip,.*": + description: Picochip Ltd + "^pine64,.*": + description: Pine64 + "^pixcir,.*": + description: PIXCIR MICROELECTRONICS Co., Ltd + "^plantower,.*": + description: Plantower Co., Ltd + "^plathome,.*": + description: Plat'Home Co., Ltd. + "^plda,.*": + description: PLDA + "^plx,.*": + description: Broadcom Corporation (formerly PLX Technology) + "^pni,.*": + description: PNI Sensor Corporation + "^portwell,.*": + description: Portwell Inc. + "^poslab,.*": + description: Poslab Technology Co., Ltd. + "^powervr,.*": + description: PowerVR (deprecated, use img) + "^probox2,.*": + description: PROBOX2 (by W2COMP Co., Ltd.) + "^pulsedlight,.*": + description: PulsedLight, Inc + "^qca,.*": + description: Qualcomm Atheros, Inc. + "^qcom,.*": + description: Qualcomm Technologies, Inc + "^qemu,.*": + description: QEMU, a generic and open source machine emulator and virtualizer + "^qi,.*": + description: Qi Hardware + "^qiaodian,.*": + description: QiaoDian XianShi Corporation + "^qnap,.*": + description: QNAP Systems, Inc. + "^radxa,.*": + description: Radxa + "^raidsonic,.*": + description: RaidSonic Technology GmbH + "^ralink,.*": + description: Mediatek/Ralink Technology Corp. + "^ramtron,.*": + description: Ramtron International + "^raspberrypi,.*": + description: Raspberry Pi Foundation + "^raydium,.*": + description: Raydium Semiconductor Corp. + "^rda,.*": + description: Unisoc Communications, Inc. + "^realtek,.*": + description: Realtek Semiconductor Corp. + "^renesas,.*": + description: Renesas Electronics Corporation + "^richtek,.*": + description: Richtek Technology Corporation + "^ricoh,.*": + description: Ricoh Co. Ltd. + "^rikomagic,.*": + description: Rikomagic Tech Corp. Ltd + "^riscv,.*": + description: RISC-V Foundation + "^rockchip,.*": + description: Fuzhou Rockchip Electronics Co., Ltd + "^rocktech,.*": + description: ROCKTECH DISPLAYS LIMITED + "^rohm,.*": + description: ROHM Semiconductor Co., Ltd + "^ronbo,.*": + description: Ronbo Electronics + "^roofull,.*": + description: Shenzhen Roofull Technology Co, Ltd + "^samsung,.*": + description: Samsung Semiconductor + "^samtec,.*": + description: Samtec/Softing company + "^sancloud,.*": + description: Sancloud Ltd + "^sandisk,.*": + description: Sandisk Corporation + "^sbs,.*": + description: Smart Battery System + "^schindler,.*": + description: Schindler + "^seagate,.*": + description: Seagate Technology PLC + "^seirobotics,.*": + description: Shenzhen SEI Robotics Co., Ltd + "^semtech,.*": + description: Semtech Corporation + "^sensirion,.*": + description: Sensirion AG + "^sff,.*": + description: Small Form Factor Committee + "^sgd,.*": + description: Solomon Goldentek Display Corporation + "^sgx,.*": + description: SGX Sensortech + "^sharp,.*": + description: Sharp Corporation + "^shimafuji,.*": + description: Shimafuji Electric, Inc. + "^si-en,.*": + description: Si-En Technology Ltd. + "^si-linux,.*": + description: Silicon Linux Corporation + "^sifive,.*": + description: SiFive, Inc. + "^sigma,.*": + description: Sigma Designs, Inc. + "^sii,.*": + description: Seiko Instruments, Inc. + "^sil,.*": + description: Silicon Image + "^silabs,.*": + description: Silicon Laboratories + "^silead,.*": + description: Silead Inc. + "^silergy,.*": + description: Silergy Corp. + "^siliconmitus,.*": + description: Silicon Mitus, Inc. + "^simte,.*": + description: k + "^sirf,.*": + description: SiRF Technology, Inc. + "^sis,.*": + description: Silicon Integrated Systems Corp. + "^sitronix,.*": + description: Sitronix Technology Corporation + "^skyworks,.*": + description: Skyworks Solutions, Inc. + "^smsc,.*": + description: Standard Microsystems Corporation + "^snps,.*": + description: Synopsys, Inc. + "^socionext,.*": + description: Socionext Inc. + "^solidrun,.*": + description: SolidRun + "^solomon,.*": + description: Solomon Systech Limited + "^sony,.*": + description: Sony Corporation + "^spansion,.*": + description: Spansion Inc. + "^sprd,.*": + description: Spreadtrum Communications Inc. + "^sst,.*": + description: Silicon Storage Technology, Inc. + "^st,.*": + description: STMicroelectronics + "^starry,.*": + description: Starry Electronic Technology (ShenZhen) Co., LTD + "^startek,.*": + description: Startek + "^ste,.*": + description: ST-Ericsson + "^stericsson,.*": + description: ST-Ericsson + "^summit,.*": + description: Summit microelectronics + "^sunchip,.*": + description: Shenzhen Sunchip Technology Co., Ltd + "^SUNW,.*": + description: Sun Microsystems, Inc + "^swir,.*": + description: Sierra Wireless + "^syna,.*": + description: Synaptics Inc. + "^synology,.*": + description: Synology, Inc. + "^tbs,.*": + description: TBS Technologies + "^tbs-biometrics,.*": + description: Touchless Biometric Systems AG + "^tcg,.*": + description: Trusted Computing Group + "^tcl,.*": + description: Toby Churchill Ltd. + "^technexion,.*": + description: TechNexion + "^technologic,.*": + description: Technologic Systems + "^tempo,.*": + description: Tempo Semiconductor + "^techstar,.*": + description: Shenzhen Techstar Electronics Co., Ltd. + "^terasic,.*": + description: Terasic Inc. + "^thine,.*": + description: THine Electronics, Inc. + "^ti,.*": + description: Texas Instruments + "^tianma,.*": + description: Tianma Micro-electronics Co., Ltd. + "^tlm,.*": + description: Trusted Logic Mobility + "^tmt,.*": + description: Tecon Microprocessor Technologies, LLC. + "^topeet,.*": + description: Topeet + "^toradex,.*": + description: Toradex AG + "^toshiba,.*": + description: Toshiba Corporation + "^toumaz,.*": + description: Toumaz + "^tpk,.*": + description: TPK U.S.A. LLC + "^tplink,.*": + description: TP-LINK Technologies Co., Ltd. + "^tpo,.*": + description: TPO + "^tq,.*": + description: TQ Systems GmbH + "^tronfy,.*": + description: Tronfy + "^tronsmart,.*": + description: Tronsmart + "^truly,.*": + description: Truly Semiconductors Limited + "^tsd,.*": + description: Theobroma Systems Design und Consulting GmbH + "^tyan,.*": + description: Tyan Computer Corporation + "^u-blox,.*": + description: u-blox + "^ucrobotics,.*": + description: uCRobotics + "^ubnt,.*": + description: Ubiquiti Networks + "^udoo,.*": + description: Udoo + "^uniwest,.*": + description: United Western Technologies Corp (UniWest) + "^upisemi,.*": + description: uPI Semiconductor Corp. + "^urt,.*": + description: United Radiant Technology Corporation + "^usi,.*": + description: Universal Scientific Industrial Co., Ltd. + "^v3,.*": + description: V3 Semiconductor + "^vamrs,.*": + description: Vamrs Ltd. + "^variscite,.*": + description: Variscite Ltd. + "^via,.*": + description: VIA Technologies, Inc. + "^virtio,.*": + description: Virtual I/O Device Specification, developed by the OASIS consortium + "^vishay,.*": + description: Vishay Intertechnology, Inc + "^vitesse,.*": + description: Vitesse Semiconductor Corporation + "^vivante,.*": + description: Vivante Corporation + "^vocore,.*": + description: VoCore Studio + "^voipac,.*": + description: Voipac Technologies s.r.o. + "^vot,.*": + description: Vision Optical Technology Co., Ltd. + "^wd,.*": + description: Western Digital Corp. + "^wetek,.*": + description: WeTek Electronics, limited. + "^wexler,.*": + description: Wexler + "^whwave,.*": + description: Shenzhen whwave Electronics, Inc. + "^wi2wi,.*": + description: Wi2Wi, Inc. + "^winbond,.*": + description: Winbond Electronics corp. + "^winstar,.*": + description: Winstar Display Corp. + "^wlf,.*": + description: Wolfson Microelectronics + "^wm,.*": + description: Wondermedia Technologies, Inc. + "^x-powers,.*": + description: X-Powers + "^xes,.*": + description: Extreme Engineering Solutions (X-ES) + "^xillybus,.*": + description: Xillybus Ltd. + "^xlnx,.*": + description: Xilinx + "^xunlong,.*": + description: Shenzhen Xunlong Software CO.,Limited + "^ysoft,.*": + description: Y Soft Corporation a.s. + "^zarlink,.*": + description: Zarlink Semiconductor + "^zeitec,.*": + description: ZEITEC Semiconductor Co., LTD. + "^zidoo,.*": + description: Shenzhen Zidoo Technology Co., Ltd. + "^zii,.*": + description: Zodiac Inflight Innovations + "^zte,.*": + description: ZTE Corp. + "^zyxel,.*": + description: ZyXEL Communications Corp. + + # Normal property name match without a comma + # These should catch all node/property names without a prefix + "^[a-zA-Z0-9#][a-zA-Z0-9+\\-._@]{0,63}$": true + "^[a-zA-Z0-9+\\-._]*@[0-9a-zA-Z,]*$": true + "^#.*": true + +additionalProperties: false + +... diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 99994a461359..69c7fa7f616c 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -271,6 +271,9 @@ GPIO devm_gpio_request_one() devm_gpio_free() +I2C + devm_i2c_new_dummy_device() + IIO devm_iio_device_alloc() devm_iio_device_free() diff --git a/Documentation/filesystems/autofs-mount-control.txt b/Documentation/filesystems/autofs-mount-control.txt index 45edad6933cc..acc02fc57993 100644 --- a/Documentation/filesystems/autofs-mount-control.txt +++ b/Documentation/filesystems/autofs-mount-control.txt @@ -354,8 +354,10 @@ this ioctl is called until no further expire candidates are found. The call requires an initialized struct autofs_dev_ioctl with the ioctlfd field set to the descriptor obtained from the open call. In -addition an immediate expire, independent of the mount timeout, can be -requested by setting the how field of struct args_expire to 1. If no +addition an immediate expire that's independent of the mount timeout, +and a forced expire that's independent of whether the mount is busy, +can be requested by setting the how field of struct args_expire to +AUTOFS_EXP_IMMEDIATE or AUTOFS_EXP_FORCED, respectively . If no expire candidates can be found the ioctl returns -1 with errno set to EAGAIN. diff --git a/Documentation/filesystems/autofs.txt b/Documentation/filesystems/autofs.txt index 373ad25852d3..3af38c7fd26d 100644 --- a/Documentation/filesystems/autofs.txt +++ b/Documentation/filesystems/autofs.txt @@ -116,7 +116,7 @@ that purpose there is another flag. **DCACHE_MANAGE_TRANSIT** If a dentry has DCACHE_MANAGE_TRANSIT set then two very different but -related behaviors are invoked, both using the `d_op->d_manage()` +related behaviours are invoked, both using the `d_op->d_manage()` dentry operation. Firstly, before checking to see if any filesystem is mounted on the @@ -193,8 +193,8 @@ VFS remain in RCU-walk mode, but can only tell it to get out of RCU-walk mode by returning `-ECHILD`. So `d_manage()`, when called with `rcu_walk` set, should either return --ECHILD if there is any reason to believe it is unsafe to end the -mounted filesystem, and otherwise should return 0. +-ECHILD if there is any reason to believe it is unsafe to enter the +mounted filesystem, otherwise it should return 0. autofs will return `-ECHILD` if an expiry of the filesystem has been initiated or is being considered, otherwise it returns 0. @@ -210,7 +210,7 @@ mounts that were created by `d_automount()` returning a filesystem to be mounted. As autofs doesn't return such a filesystem but leaves the mounting to the automount daemon, it must involve the automount daemon in unmounting as well. This also means that autofs has more control -of expiry. +over expiry. The VFS also supports "expiry" of mounts using the MNT_EXPIRE flag to the `umount` system call. Unmounting with MNT_EXPIRE will fail unless @@ -225,7 +225,7 @@ unmount any filesystems mounted on the autofs filesystem or remove any symbolic links or empty directories any time it likes. If the unmount or removal is successful the filesystem will be returned to the state it was before the mount or creation, so that any access of the name -will trigger normal auto-mount processing. In particlar, `rmdir` and +will trigger normal auto-mount processing. In particular, `rmdir` and `unlink` do not leave negative entries in the dcache as a normal filesystem would, so an attempt to access a recently-removed object is passed to autofs for handling. @@ -240,11 +240,18 @@ Normally the daemon only wants to remove entries which haven't been used for a while. For this purpose autofs maintains a "`last_used`" time stamp on each directory or symlink. For symlinks it genuinely does record the last time the symlink was "used" or followed to find -out where it points to. For directories the field is a slight -misnomer. It actually records the last time that autofs checked if -the directory or one of its descendents was busy and found that it -was. This is just as useful and doesn't require updating the field so -often. +out where it points to. For directories the field is used slightly +differently. The field is updated at mount time and during expire +checks if it is found to be in use (ie. open file descriptor or +process working directory) and during path walks. The update done +during path walks prevents frequent expire and immediate mount of +frequently accessed automounts. But in the case where a GUI continually +access or an application frequently scans an autofs directory tree +there can be an accumulation of mounts that aren't actually being +used. To cater for this case the "`strictexpire`" autofs mount option +can be used to avoid the "`last_used`" update on path walk thereby +preventing this apparent inability to expire mounts that aren't +really in use. The daemon is able to ask autofs if anything is due to be expired, using an `ioctl` as discussed later. For a *direct* mount, autofs @@ -255,8 +262,12 @@ up. There is an option with indirect mounts to consider each of the leaves that has been mounted on instead of considering the top-level names. -This is intended for compatability with version 4 of autofs and should -be considered as deprecated. +This was originally intended for compatibility with version 4 of autofs +and should be considered as deprecated for Sun Format automount maps. +However, it may be used again for amd format mount maps (which are +generally indirect maps) because the amd automounter allows for the +setting of an expire timeout for individual mounts. But there are +some difficulties in making the needed changes for this. When autofs considers a directory it checks the `last_used` time and compares it with the "timeout" value set when the filesystem was @@ -273,7 +284,7 @@ mounts. If it finds something in the root directory to expire it will return the name of that thing. Once a name has been returned the automount daemon needs to unmount any filesystems mounted below the name normally. As described above, this is unsafe for non-toplevel -mounts in a version-5 autofs. For this reason the current `automountd` +mounts in a version-5 autofs. For this reason the current `automount(8)` does not use this ioctl. The second mechanism uses either the **AUTOFS_DEV_IOCTL_EXPIRE_CMD** or @@ -345,7 +356,7 @@ The `wait_queue_token` is a unique number which can identify a particular request to be acknowledged. When a message is sent over the pipe the affected dentry is marked as either "active" or "expiring" and other accesses to it block until the message is -acknowledged using one of the ioctls below and the relevant +acknowledged using one of the ioctls below with the relevant `wait_queue_token`. Communicating with autofs: root directory ioctls @@ -367,15 +378,14 @@ The available ioctl commands are: This mode is also entered if a write to the pipe fails. - **AUTOFS_IOC_PROTOVER**: This returns the protocol version in use. - **AUTOFS_IOC_PROTOSUBVER**: Returns the protocol sub-version which - is really a version number for the implementation. It is - currently 2. + is really a version number for the implementation. - **AUTOFS_IOC_SETTIMEOUT**: This passes a pointer to an unsigned long. The value is used to set the timeout for expiry, and the current timeout value is stored back through the pointer. - **AUTOFS_IOC_ASKUMOUNT**: Returns, in the pointed-to `int`, 1 if the filesystem could be unmounted. This is only a hint as the situation could change at any instant. This call can be - use to avoid a more expensive full unmount attempt. + used to avoid a more expensive full unmount attempt. - **AUTOFS_IOC_EXPIRE**: as described above, this asks if there is anything suitable to expire. A pointer to a packet: @@ -400,6 +410,11 @@ The available ioctl commands are: **AUTOFS_EXP_IMMEDIATE** causes `last_used` time to be ignored and objects are expired if the are not in use. + **AUTOFS_EXP_FORCED** causes the in use status to be ignored + and objects are expired ieven if they are in use. This assumes + that the daemon has requested this because it is capable of + performing the umount. + **AUTOFS_EXP_LEAVES** will select a leaf rather than a top-level name to expire. This is only safe when *maxproto* is 4. @@ -415,7 +430,7 @@ which can be used to communicate directly with the autofs filesystem. It requires CAP_SYS_ADMIN for access. The `ioctl`s that can be used on this device are described in a separate -document `autofs-mount-control.txt`, and are summarized briefly here. +document `autofs-mount-control.txt`, and are summarised briefly here. Each ioctl is passed a pointer to an `autofs_dev_ioctl` structure: struct autofs_dev_ioctl { @@ -511,6 +526,21 @@ directories. Catatonic mode can only be left via the **AUTOFS_DEV_IOCTL_OPENMOUNT_CMD** ioctl on the `/dev/autofs`. +The "ignore" mount option +------------------------- + +The "ignore" mount option can be used to provide a generic indicator +to applications that the mount entry should be ignored when displaying +mount information. + +In other OSes that provide autofs and that provide a mount list to user +space based on the kernel mount list a no-op mount option ("ignore" is +the one use on the most common OSes) is allowed so that autofs file +system users can optionally use it. + +This is intended to be used by user space programs to exclude autofs +mounts from consideration when reading the mounts list. + autofs, name spaces, and shared mounts -------------------------------------- diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst index 1351984e767c..febccbc5689d 100644 --- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst @@ -45,8 +45,8 @@ the ANOD object which is also the final target node of the reference. Name (_DSD, Package () { ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { - Package () { "node@0", NOD0 }, - Package () { "node@1", NOD1 }, + Package () { "node@0", "NOD0" }, + Package () { "node@1", "NOD1" }, } }) Name (NOD0, Package() { @@ -58,7 +58,7 @@ the ANOD object which is also the final target node of the reference. Name (NOD1, Package() { ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { - Package () { "anothernode", ANOD }, + Package () { "anothernode", "ANOD" }, } }) Name (ANOD, Package() { diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst index e0baed35b037..1a6ce7afba5e 100644 --- a/Documentation/firmware-guide/acpi/dsd/graph.rst +++ b/Documentation/firmware-guide/acpi/dsd/graph.rst @@ -45,7 +45,7 @@ with "port" and must be followed by the "@" character and the number of the port as its key. The target object it refers to should be called "PRTX", where "X" is the number of the port. An example of such a package would be:: - Package() { "port@4", PRT4 } + Package() { "port@4", "PRT4" } Further on, endpoints are located under the port nodes. The hierarchical data extension key of the endpoint nodes must begin with @@ -54,7 +54,7 @@ endpoint. The object it refers to should be called "EPXY", where "X" is the number of the port and "Y" is the number of the endpoint. An example of such a package would be:: - Package() { "endpoint@0", EP40 } + Package() { "endpoint@0", "EP40" } Each port node contains a property extension key "port", the value of which is the number of the port. Each endpoint is similarly numbered with a property @@ -82,68 +82,68 @@ A simple example of this is show below:: Scope (\_SB.PCI0.I2C2) { - Device (CAM0) - { - Name (_DSD, Package () { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "compatible", Package () { "nokia,smia" } }, - }, - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "port@0", PRT0 }, - } - }) - Name (PRT0, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 0 }, - }, - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "endpoint@0", EP00 }, - } - }) - Name (EP00, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 0 }, - Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } }, - } - }) - } + Device (CAM0) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "compatible", Package () { "nokia,smia" } }, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "port@0", "PRT0" }, + } + }) + Name (PRT0, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "endpoint@0", "EP00" }, + } + }) + Name (EP00, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } }, + } + }) + } } Scope (\_SB.PCI0) { - Device (ISP) - { - Name (_DSD, Package () { - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "port@4", PRT4 }, - } - }) - - Name (PRT4, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 4 }, /* CSI-2 port number */ - }, - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "endpoint@0", EP40 }, - } - }) - - Name (EP40, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 0 }, - Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } }, - } - }) - } + Device (ISP) + { + Name (_DSD, Package () { + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "port@4", "PRT4" }, + } + }) + + Name (PRT4, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 4 }, /* CSI-2 port number */ + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "endpoint@0", "EP40" }, + } + }) + + Name (EP40, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } }, + } + }) + } } Here, the port 0 of the "CAM0" device is connected to the port 4 of diff --git a/Documentation/media/uapi/v4l/field-order.rst b/Documentation/media/uapi/v4l/field-order.rst index 3fb473e3b8e2..d640e922a974 100644 --- a/Documentation/media/uapi/v4l/field-order.rst +++ b/Documentation/media/uapi/v4l/field-order.rst @@ -75,12 +75,11 @@ enum v4l2_field * - ``V4L2_FIELD_ANY`` - 0 - - Applications request this field order when any one of the - ``V4L2_FIELD_NONE``, ``V4L2_FIELD_TOP``, ``V4L2_FIELD_BOTTOM``, or - ``V4L2_FIELD_INTERLACED`` formats is acceptable. Drivers choose - depending on hardware capabilities or e. g. the requested image - size, and return the actual field order. Drivers must never return - ``V4L2_FIELD_ANY``. If multiple field orders are possible the + - Applications request this field order when any field format + is acceptable. Drivers choose depending on hardware capabilities or + e.g. the requested image size, and return the actual field order. + Drivers must never return ``V4L2_FIELD_ANY``. + If multiple field orders are possible the driver must choose one of the possible field orders during :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`. struct @@ -88,9 +87,8 @@ enum v4l2_field ``V4L2_FIELD_ANY``. * - ``V4L2_FIELD_NONE`` - 1 - - Images are in progressive format, not interlaced. The driver may - also indicate this order when it cannot distinguish between - ``V4L2_FIELD_TOP`` and ``V4L2_FIELD_BOTTOM``. + - Images are in progressive (frame-based) format, not interlaced + (field-based). * - ``V4L2_FIELD_TOP`` - 2 - Images consist of the top (aka odd) field only. diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt index cd7303d7fa25..180e07d956a7 100644 --- a/Documentation/networking/rxrpc.txt +++ b/Documentation/networking/rxrpc.txt @@ -796,7 +796,9 @@ The kernel interface functions are as follows: s64 tx_total_len, gfp_t gfp, rxrpc_notify_rx_t notify_rx, - bool upgrade); + bool upgrade, + bool intr, + unsigned int debug_id); This allocates the infrastructure to make a new RxRPC call and assigns call and connection numbers. The call will be made on the UDP port that @@ -824,6 +826,13 @@ The kernel interface functions are as follows: the server upgrade the service to a better one. The resultant service ID is returned by rxrpc_kernel_recv_data(). + intr should be set to true if the call should be interruptible. If this + is not set, this function may not return until a channel has been + allocated; if it is set, the function may return -ERESTARTSYS. + + debug_id is the call debugging ID to be used for tracing. This can be + obtained by atomically incrementing rxrpc_debug_id. + If this function is successful, an opaque reference to the RxRPC call is returned. The caller now holds a reference on this and it must be properly ended. @@ -1056,6 +1065,16 @@ The kernel interface functions are as follows: This value can be used to determine if the remote client has been restarted as it shouldn't change otherwise. + (*) Set the maxmimum lifespan on a call. + + void rxrpc_kernel_set_max_life(struct socket *sock, + struct rxrpc_call *call, + unsigned long hard_timeout) + + This sets the maximum lifespan on a call to hard_timeout (which is in + jiffies). In the event of the timeout occurring, the call will be + aborted and -ETIME or -ETIMEDOUT will be returned. + ======================= CONFIGURABLE PARAMETERS diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index c3b9bd2fd512..f60079259669 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -765,6 +765,37 @@ Here is the list of current tracers that may be configured. tracers from tracing simply echo "nop" into current_tracer. +Error conditions +---------------- + + For most ftrace commands, failure modes are obvious and communicated + using standard return codes. + + For other more involved commands, extended error information may be + available via the tracing/error_log file. For the commands that + support it, reading the tracing/error_log file after an error will + display more detailed information about what went wrong, if + information is available. The tracing/error_log file is a circular + error log displaying a small number (currently, 8) of ftrace errors + for the last (8) failed commands. + + The extended error information and usage takes the form shown in + this example:: + + # echo xxx > /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger + echo: write error: Invalid argument + + # cat /sys/kernel/debug/tracing/error_log + [ 5348.887237] location: error: Couldn't yyy: zzz + Command: xxx + ^ + [ 7517.023364] location: error: Bad rrr: sss + Command: ppp qqq + ^ + + To clear the error log, echo the empty string into it:: + + # echo > /sys/kernel/debug/tracing/error_log Examples of using the tracer ---------------------------- diff --git a/Documentation/trace/histogram.rst b/Documentation/trace/histogram.rst index ddbaffa530f9..fb621a1c2638 100644 --- a/Documentation/trace/histogram.rst +++ b/Documentation/trace/histogram.rst @@ -199,20 +199,8 @@ Extended error information For some error conditions encountered when invoking a hist trigger command, extended error information is available via the - corresponding event's 'hist' file. Reading the hist file after an - error will display more detailed information about what went wrong, - if information is available. This extended error information will - be available until the next hist trigger command for that event. - - If available for a given error condition, the extended error - information and usage takes the following form:: - - # echo xxx > /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger - echo: write error: Invalid argument - - # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/hist - ERROR: Couldn't yyy: zzz - Last command: xxx + tracing/error_log file. See Error Conditions in + :file:`Documentation/trace/ftrace.rst` for details. 6.2 'hist' trigger examples --------------------------- diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 64b38dfcc243..ba6c42c576dd 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -69,23 +69,6 @@ by and on behalf of the VM's process may not be freed/unaccounted when the VM is shut down. -It is important to note that althought VM ioctls may only be issued from -the process that created the VM, a VM's lifecycle is associated with its -file descriptor, not its creator (process). In other words, the VM and -its resources, *including the associated address space*, are not freed -until the last reference to the VM's file descriptor has been released. -For example, if fork() is issued after ioctl(KVM_CREATE_VM), the VM will -not be freed until both the parent (original) process and its child have -put their references to the VM's file descriptor. - -Because a VM's resources are not freed until the last reference to its -file descriptor is released, creating additional references to a VM via -via fork(), dup(), etc... without careful consideration is strongly -discouraged and may have unwanted side effects, e.g. memory allocated -by and on behalf of the VM's process may not be freed/unaccounted when -the VM is shut down. - - 3. Extensions ------------- @@ -347,7 +330,7 @@ They must be less than the value that KVM_CHECK_EXTENSION returns for the KVM_CAP_MULTI_ADDRESS_SPACE capability. The bits in the dirty bitmap are cleared before the ioctl returns, unless -KVM_CAP_MANUAL_DIRTY_LOG_PROTECT is enabled. For more information, +KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is enabled. For more information, see the description of the capability. 4.9 KVM_SET_MEMORY_ALIAS @@ -1117,9 +1100,8 @@ struct kvm_userspace_memory_region { This ioctl allows the user to create, modify or delete a guest physical memory slot. Bits 0-15 of "slot" specify the slot id and this value should be less than the maximum number of user memory slots supported per -VM. The maximum allowed slots can be queried using KVM_CAP_NR_MEMSLOTS, -if this capability is supported by the architecture. Slots may not -overlap in guest physical address space. +VM. The maximum allowed slots can be queried using KVM_CAP_NR_MEMSLOTS. +Slots may not overlap in guest physical address space. If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of "slot" specifies the address space which is being modified. They must be @@ -1901,6 +1883,12 @@ Architectures: all Type: vcpu ioctl Parameters: struct kvm_one_reg (in) Returns: 0 on success, negative value on failure +Errors: + ENOENT: no such register + EINVAL: invalid register ID, or no such register + EPERM: (arm64) register access not allowed before vcpu finalization +(These error codes are indicative only: do not rely on a specific error +code being returned in a specific situation.) struct kvm_one_reg { __u64 id; @@ -1985,6 +1973,7 @@ registers, find a list below: PPC | KVM_REG_PPC_TLB3PS | 32 PPC | KVM_REG_PPC_EPTCFG | 32 PPC | KVM_REG_PPC_ICP_STATE | 64 + PPC | KVM_REG_PPC_VP_STATE | 128 PPC | KVM_REG_PPC_TB_OFFSET | 64 PPC | KVM_REG_PPC_SPMC1 | 32 PPC | KVM_REG_PPC_SPMC2 | 32 @@ -2137,6 +2126,37 @@ contains elements ranging from 32 to 128 bits. The index is a 32bit value in the kvm_regs structure seen as a 32bit array. 0x60x0 0000 0010 <index into the kvm_regs struct:16> +Specifically: + Encoding Register Bits kvm_regs member +---------------------------------------------------------------- + 0x6030 0000 0010 0000 X0 64 regs.regs[0] + 0x6030 0000 0010 0002 X1 64 regs.regs[1] + ... + 0x6030 0000 0010 003c X30 64 regs.regs[30] + 0x6030 0000 0010 003e SP 64 regs.sp + 0x6030 0000 0010 0040 PC 64 regs.pc + 0x6030 0000 0010 0042 PSTATE 64 regs.pstate + 0x6030 0000 0010 0044 SP_EL1 64 sp_el1 + 0x6030 0000 0010 0046 ELR_EL1 64 elr_el1 + 0x6030 0000 0010 0048 SPSR_EL1 64 spsr[KVM_SPSR_EL1] (alias SPSR_SVC) + 0x6030 0000 0010 004a SPSR_ABT 64 spsr[KVM_SPSR_ABT] + 0x6030 0000 0010 004c SPSR_UND 64 spsr[KVM_SPSR_UND] + 0x6030 0000 0010 004e SPSR_IRQ 64 spsr[KVM_SPSR_IRQ] + 0x6060 0000 0010 0050 SPSR_FIQ 64 spsr[KVM_SPSR_FIQ] + 0x6040 0000 0010 0054 V0 128 fp_regs.vregs[0] (*) + 0x6040 0000 0010 0058 V1 128 fp_regs.vregs[1] (*) + ... + 0x6040 0000 0010 00d0 V31 128 fp_regs.vregs[31] (*) + 0x6020 0000 0010 00d4 FPSR 32 fp_regs.fpsr + 0x6020 0000 0010 00d5 FPCR 32 fp_regs.fpcr + +(*) These encodings are not accepted for SVE-enabled vcpus. See + KVM_ARM_VCPU_INIT. + + The equivalent register content can be accessed via bits [127:0] of + the corresponding SVE Zn registers instead for vcpus that have SVE + enabled (see below). + arm64 CCSIDR registers are demultiplexed by CSSELR value: 0x6020 0000 0011 00 <csselr:8> @@ -2146,6 +2166,64 @@ arm64 system registers have the following id bit patterns: arm64 firmware pseudo-registers have the following bit pattern: 0x6030 0000 0014 <regno:16> +arm64 SVE registers have the following bit patterns: + 0x6080 0000 0015 00 <n:5> <slice:5> Zn bits[2048*slice + 2047 : 2048*slice] + 0x6050 0000 0015 04 <n:4> <slice:5> Pn bits[256*slice + 255 : 256*slice] + 0x6050 0000 0015 060 <slice:5> FFR bits[256*slice + 255 : 256*slice] + 0x6060 0000 0015 ffff KVM_REG_ARM64_SVE_VLS pseudo-register + +Access to register IDs where 2048 * slice >= 128 * max_vq will fail with +ENOENT. max_vq is the vcpu's maximum supported vector length in 128-bit +quadwords: see (**) below. + +These registers are only accessible on vcpus for which SVE is enabled. +See KVM_ARM_VCPU_INIT for details. + +In addition, except for KVM_REG_ARM64_SVE_VLS, these registers are not +accessible until the vcpu's SVE configuration has been finalized +using KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE). See KVM_ARM_VCPU_INIT +and KVM_ARM_VCPU_FINALIZE for more information about this procedure. + +KVM_REG_ARM64_SVE_VLS is a pseudo-register that allows the set of vector +lengths supported by the vcpu to be discovered and configured by +userspace. When transferred to or from user memory via KVM_GET_ONE_REG +or KVM_SET_ONE_REG, the value of this register is of type +__u64[KVM_ARM64_SVE_VLS_WORDS], and encodes the set of vector lengths as +follows: + +__u64 vector_lengths[KVM_ARM64_SVE_VLS_WORDS]; + +if (vq >= SVE_VQ_MIN && vq <= SVE_VQ_MAX && + ((vector_lengths[(vq - KVM_ARM64_SVE_VQ_MIN) / 64] >> + ((vq - KVM_ARM64_SVE_VQ_MIN) % 64)) & 1)) + /* Vector length vq * 16 bytes supported */ +else + /* Vector length vq * 16 bytes not supported */ + +(**) The maximum value vq for which the above condition is true is +max_vq. This is the maximum vector length available to the guest on +this vcpu, and determines which register slices are visible through +this ioctl interface. + +(See Documentation/arm64/sve.txt for an explanation of the "vq" +nomenclature.) + +KVM_REG_ARM64_SVE_VLS is only accessible after KVM_ARM_VCPU_INIT. +KVM_ARM_VCPU_INIT initialises it to the best set of vector lengths that +the host supports. + +Userspace may subsequently modify it if desired until the vcpu's SVE +configuration is finalized using KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE). + +Apart from simply removing all vector lengths from the host set that +exceed some value, support for arbitrarily chosen sets of vector lengths +is hardware-dependent and may not be available. Attempting to configure +an invalid set of vector lengths via KVM_SET_ONE_REG will fail with +EINVAL. + +After the vcpu's SVE configuration is finalized, further attempts to +write this register will fail with EPERM. + MIPS registers are mapped using the lower 32 bits. The upper 16 of that is the register group type: @@ -2198,6 +2276,12 @@ Architectures: all Type: vcpu ioctl Parameters: struct kvm_one_reg (in and out) Returns: 0 on success, negative value on failure +Errors include: + ENOENT: no such register + EINVAL: invalid register ID, or no such register + EPERM: (arm64) register access not allowed before vcpu finalization +(These error codes are indicative only: do not rely on a specific error +code being returned in a specific situation.) This ioctl allows to receive the value of a single register implemented in a vcpu. The register to read is indicated by the "id" field of the @@ -2690,6 +2774,49 @@ Possible features: - KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU. Depends on KVM_CAP_ARM_PMU_V3. + - KVM_ARM_VCPU_PTRAUTH_ADDRESS: Enables Address Pointer authentication + for arm64 only. + Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS. + If KVM_CAP_ARM_PTRAUTH_ADDRESS and KVM_CAP_ARM_PTRAUTH_GENERIC are + both present, then both KVM_ARM_VCPU_PTRAUTH_ADDRESS and + KVM_ARM_VCPU_PTRAUTH_GENERIC must be requested or neither must be + requested. + + - KVM_ARM_VCPU_PTRAUTH_GENERIC: Enables Generic Pointer authentication + for arm64 only. + Depends on KVM_CAP_ARM_PTRAUTH_GENERIC. + If KVM_CAP_ARM_PTRAUTH_ADDRESS and KVM_CAP_ARM_PTRAUTH_GENERIC are + both present, then both KVM_ARM_VCPU_PTRAUTH_ADDRESS and + KVM_ARM_VCPU_PTRAUTH_GENERIC must be requested or neither must be + requested. + + - KVM_ARM_VCPU_SVE: Enables SVE for the CPU (arm64 only). + Depends on KVM_CAP_ARM_SVE. + Requires KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE): + + * After KVM_ARM_VCPU_INIT: + + - KVM_REG_ARM64_SVE_VLS may be read using KVM_GET_ONE_REG: the + initial value of this pseudo-register indicates the best set of + vector lengths possible for a vcpu on this host. + + * Before KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE): + + - KVM_RUN and KVM_GET_REG_LIST are not available; + + - KVM_GET_ONE_REG and KVM_SET_ONE_REG cannot be used to access + the scalable archietctural SVE registers + KVM_REG_ARM64_SVE_ZREG(), KVM_REG_ARM64_SVE_PREG() or + KVM_REG_ARM64_SVE_FFR; + + - KVM_REG_ARM64_SVE_VLS may optionally be written using + KVM_SET_ONE_REG, to modify the set of vector lengths available + for the vcpu. + + * After KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE): + + - the KVM_REG_ARM64_SVE_VLS pseudo-register is immutable, and can + no longer be written using KVM_SET_ONE_REG. 4.83 KVM_ARM_PREFERRED_TARGET @@ -3809,7 +3936,7 @@ to I/O ports. 4.117 KVM_CLEAR_DIRTY_LOG (vm ioctl) -Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT +Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 Architectures: x86, arm, arm64, mips Type: vm ioctl Parameters: struct kvm_dirty_log (in) @@ -3842,10 +3969,10 @@ 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. -This ioctl is mostly useful when KVM_CAP_MANUAL_DIRTY_LOG_PROTECT +This ioctl is mostly useful when KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is enabled; for more information, see the description of the capability. However, it can always be used as long as KVM_CHECK_EXTENSION confirms -that KVM_CAP_MANUAL_DIRTY_LOG_PROTECT is present. +that KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is present. 4.118 KVM_GET_SUPPORTED_HV_CPUID @@ -3904,6 +4031,40 @@ 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. +4.119 KVM_ARM_VCPU_FINALIZE + +Architectures: arm, arm64 +Type: vcpu ioctl +Parameters: int feature (in) +Returns: 0 on success, -1 on error +Errors: + EPERM: feature not enabled, needs configuration, or already finalized + EINVAL: feature unknown or not present + +Recognised values for feature: + arm64 KVM_ARM_VCPU_SVE (requires KVM_CAP_ARM_SVE) + +Finalizes the configuration of the specified vcpu feature. + +The vcpu must already have been initialised, enabling the affected feature, by +means of a successful KVM_ARM_VCPU_INIT call with the appropriate flag set in +features[]. + +For affected vcpu features, this is a mandatory step that must be performed +before the vcpu is fully usable. + +Between KVM_ARM_VCPU_INIT and KVM_ARM_VCPU_FINALIZE, the feature may be +configured by use of ioctls such as KVM_SET_ONE_REG. The exact configuration +that should be performaned and how to do it are feature-dependent. + +Other calls that depend on a particular feature being finalized, such as +KVM_RUN, KVM_GET_REG_LIST, KVM_GET_ONE_REG and KVM_SET_ONE_REG, will fail with +-EPERM unless the feature has already been finalized by means of a +KVM_ARM_VCPU_FINALIZE call. + +See KVM_ARM_VCPU_INIT for details of vcpu features that require finalization +using this ioctl. + 5. The kvm_run structure ------------------------ @@ -4505,6 +4666,15 @@ struct kvm_sync_regs { struct kvm_vcpu_events events; }; +6.75 KVM_CAP_PPC_IRQ_XIVE + +Architectures: ppc +Target: vcpu +Parameters: args[0] is the XIVE device fd + args[1] is the XIVE CPU number (server ID) for this vcpu + +This capability connects the vcpu to an in-kernel XIVE device. + 7. Capabilities that can be enabled on VMs ------------------------------------------ @@ -4798,7 +4968,7 @@ and injected exceptions. * For the new DR6 bits, note that bit 16 is set iff the #DB exception will clear DR6.RTM. -7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT +7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 Architectures: x86, arm, arm64, mips Parameters: args[0] whether feature should be enabled or not @@ -4821,6 +4991,11 @@ while userspace can see false reports of dirty pages. Manual reprotection helps reducing this time, improving guest performance and reducing the number of dirty log false positives. +KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 was previously available under the name +KVM_CAP_MANUAL_DIRTY_LOG_PROTECT, but the implementation had bugs that make +it hard or impossible to use it correctly. The availability of +KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 signals that those bugs are fixed. +Userspace should not try to use KVM_CAP_MANUAL_DIRTY_LOG_PROTECT. 8. Other capabilities. ---------------------- diff --git a/Documentation/virtual/kvm/devices/vm.txt b/Documentation/virtual/kvm/devices/vm.txt index 95ca68d663a4..4ffb82b02468 100644 --- a/Documentation/virtual/kvm/devices/vm.txt +++ b/Documentation/virtual/kvm/devices/vm.txt @@ -141,7 +141,8 @@ struct kvm_s390_vm_cpu_subfunc { u8 pcc[16]; # valid with Message-Security-Assist-Extension 4 u8 ppno[16]; # valid with Message-Security-Assist-Extension 5 u8 kma[16]; # valid with Message-Security-Assist-Extension 8 - u8 reserved[1808]; # reserved for future instructions + u8 kdsa[16]; # valid with Message-Security-Assist-Extension 9 + u8 reserved[1792]; # reserved for future instructions }; Parameters: address of a buffer to load the subfunction blocks from. diff --git a/Documentation/virtual/kvm/devices/xive.txt b/Documentation/virtual/kvm/devices/xive.txt new file mode 100644 index 000000000000..9a24a4525253 --- /dev/null +++ b/Documentation/virtual/kvm/devices/xive.txt @@ -0,0 +1,197 @@ +POWER9 eXternal Interrupt Virtualization Engine (XIVE Gen1) +========================================================== + +Device types supported: + KVM_DEV_TYPE_XIVE POWER9 XIVE Interrupt Controller generation 1 + +This device acts as a VM interrupt controller. It provides the KVM +interface to configure the interrupt sources of a VM in the underlying +POWER9 XIVE interrupt controller. + +Only one XIVE instance may be instantiated. A guest XIVE device +requires a POWER9 host and the guest OS should have support for the +XIVE native exploitation interrupt mode. If not, it should run using +the legacy interrupt mode, referred as XICS (POWER7/8). + +* Device Mappings + + The KVM device exposes different MMIO ranges of the XIVE HW which + are required for interrupt management. These are exposed to the + guest in VMAs populated with a custom VM fault handler. + + 1. Thread Interrupt Management Area (TIMA) + + Each thread has an associated Thread Interrupt Management context + composed of a set of registers. These registers let the thread + handle priority management and interrupt acknowledgment. The most + important are : + + - Interrupt Pending Buffer (IPB) + - Current Processor Priority (CPPR) + - Notification Source Register (NSR) + + They are exposed to software in four different pages each proposing + a view with a different privilege. The first page is for the + physical thread context and the second for the hypervisor. Only the + third (operating system) and the fourth (user level) are exposed the + guest. + + 2. Event State Buffer (ESB) + + Each source is associated with an Event State Buffer (ESB) with + either a pair of even/odd pair of pages which provides commands to + manage the source: to trigger, to EOI, to turn off the source for + instance. + + 3. Device pass-through + + When a device is passed-through into the guest, the source + interrupts are from a different HW controller (PHB4) and the ESB + pages exposed to the guest should accommadate this change. + + The passthru_irq helpers, kvmppc_xive_set_mapped() and + kvmppc_xive_clr_mapped() are called when the device HW irqs are + mapped into or unmapped from the guest IRQ number space. The KVM + device extends these helpers to clear the ESB pages of the guest IRQ + number being mapped and then lets the VM fault handler repopulate. + The handler will insert the ESB page corresponding to the HW + interrupt of the device being passed-through or the initial IPI ESB + page if the device has being removed. + + The ESB remapping is fully transparent to the guest and the OS + device driver. All handling is done within VFIO and the above + helpers in KVM-PPC. + +* Groups: + + 1. KVM_DEV_XIVE_GRP_CTRL + Provides global controls on the device + Attributes: + 1.1 KVM_DEV_XIVE_RESET (write only) + Resets the interrupt controller configuration for sources and event + queues. To be used by kexec and kdump. + Errors: none + + 1.2 KVM_DEV_XIVE_EQ_SYNC (write only) + Sync all the sources and queues and mark the EQ pages dirty. This + to make sure that a consistent memory state is captured when + migrating the VM. + Errors: none + + 2. KVM_DEV_XIVE_GRP_SOURCE (write only) + Initializes a new source in the XIVE device and mask it. + Attributes: + Interrupt source number (64-bit) + The kvm_device_attr.addr points to a __u64 value: + bits: | 63 .... 2 | 1 | 0 + values: | unused | level | type + - type: 0:MSI 1:LSI + - level: assertion level in case of an LSI. + Errors: + -E2BIG: Interrupt source number is out of range + -ENOMEM: Could not create a new source block + -EFAULT: Invalid user pointer for attr->addr. + -ENXIO: Could not allocate underlying HW interrupt + + 3. KVM_DEV_XIVE_GRP_SOURCE_CONFIG (write only) + Configures source targeting + Attributes: + Interrupt source number (64-bit) + The kvm_device_attr.addr points to a __u64 value: + bits: | 63 .... 33 | 32 | 31 .. 3 | 2 .. 0 + values: | eisn | mask | server | priority + - priority: 0-7 interrupt priority level + - server: CPU number chosen to handle the interrupt + - mask: mask flag (unused) + - eisn: Effective Interrupt Source Number + Errors: + -ENOENT: Unknown source number + -EINVAL: Not initialized source number + -EINVAL: Invalid priority + -EINVAL: Invalid CPU number. + -EFAULT: Invalid user pointer for attr->addr. + -ENXIO: CPU event queues not configured or configuration of the + underlying HW interrupt failed + -EBUSY: No CPU available to serve interrupt + + 4. KVM_DEV_XIVE_GRP_EQ_CONFIG (read-write) + Configures an event queue of a CPU + Attributes: + EQ descriptor identifier (64-bit) + The EQ descriptor identifier is a tuple (server, priority) : + bits: | 63 .... 32 | 31 .. 3 | 2 .. 0 + values: | unused | server | priority + The kvm_device_attr.addr points to : + struct kvm_ppc_xive_eq { + __u32 flags; + __u32 qshift; + __u64 qaddr; + __u32 qtoggle; + __u32 qindex; + __u8 pad[40]; + }; + - flags: queue flags + KVM_XIVE_EQ_ALWAYS_NOTIFY (required) + forces notification without using the coalescing mechanism + provided by the XIVE END ESBs. + - qshift: queue size (power of 2) + - qaddr: real address of queue + - qtoggle: current queue toggle bit + - qindex: current queue index + - pad: reserved for future use + Errors: + -ENOENT: Invalid CPU number + -EINVAL: Invalid priority + -EINVAL: Invalid flags + -EINVAL: Invalid queue size + -EINVAL: Invalid queue address + -EFAULT: Invalid user pointer for attr->addr. + -EIO: Configuration of the underlying HW failed + + 5. KVM_DEV_XIVE_GRP_SOURCE_SYNC (write only) + Synchronize the source to flush event notifications + Attributes: + Interrupt source number (64-bit) + Errors: + -ENOENT: Unknown source number + -EINVAL: Not initialized source number + +* VCPU state + + The XIVE IC maintains VP interrupt state in an internal structure + called the NVT. When a VP is not dispatched on a HW processor + thread, this structure can be updated by HW if the VP is the target + of an event notification. + + It is important for migration to capture the cached IPB from the NVT + as it synthesizes the priorities of the pending interrupts. We + capture a bit more to report debug information. + + KVM_REG_PPC_VP_STATE (2 * 64bits) + bits: | 63 .... 32 | 31 .... 0 | + values: | TIMA word0 | TIMA word1 | + bits: | 127 .......... 64 | + values: | unused | + +* Migration: + + Saving the state of a VM using the XIVE native exploitation mode + should follow a specific sequence. When the VM is stopped : + + 1. Mask all sources (PQ=01) to stop the flow of events. + + 2. Sync the XIVE device with the KVM control KVM_DEV_XIVE_EQ_SYNC to + flush any in-flight event notification and to stabilize the EQs. At + this stage, the EQ pages are marked dirty to make sure they are + transferred in the migration sequence. + + 3. Capture the state of the source targeting, the EQs configuration + and the state of thread interrupt context registers. + + Restore is similar : + + 1. Restore the EQ configuration. As targeting depends on it. + 2. Restore targeting + 3. Restore the thread interrupt contexts + 4. Restore the source states + 5. Let the vCPU run diff --git a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst index 534e9baa4e1d..5d4330be200f 100644 --- a/Documentation/x86/mds.rst +++ b/Documentation/x86/mds.rst @@ -142,45 +142,13 @@ Mitigation points mds_user_clear. The mitigation is invoked in prepare_exit_to_usermode() which covers - most of the kernel to user space transitions. There are a few exceptions - which are not invoking prepare_exit_to_usermode() on return to user - space. These exceptions use the paranoid exit code. + all but one of the kernel to user space transitions. The exception + is when we return from a Non Maskable Interrupt (NMI), which is + handled directly in do_nmi(). - - Non Maskable Interrupt (NMI): - - Access to sensible data like keys, credentials in the NMI context is - mostly theoretical: The CPU can do prefetching or execute a - misspeculated code path and thereby fetching data which might end up - leaking through a buffer. - - But for mounting other attacks the kernel stack address of the task is - already valuable information. So in full mitigation mode, the NMI is - mitigated on the return from do_nmi() to provide almost complete - coverage. - - - Double fault (#DF): - - A double fault is usually fatal, but the ESPFIX workaround, which can - be triggered from user space through modify_ldt(2) is a recoverable - double fault. #DF uses the paranoid exit path, so explicit mitigation - in the double fault handler is required. - - - Machine Check Exception (#MC): - - Another corner case is a #MC which hits between the CPU buffer clear - invocation and the actual return to user. As this still is in kernel - space it takes the paranoid exit path which does not clear the CPU - buffers. So the #MC handler repopulates the buffers to some - extent. Machine checks are not reliably controllable and the window is - extremly small so mitigation would just tick a checkbox that this - theoretical corner case is covered. To keep the amount of special - cases small, ignore #MC. - - - Debug Exception (#DB): - - This takes the paranoid exit path only when the INT1 breakpoint is in - kernel space. #DB on a user space address takes the regular exit path, - so no extra mitigation required. + (The reason that NMI is special is that prepare_exit_to_usermode() can + enable IRQs. In NMI context, NMIs are blocked, and we don't want to + enable IRQs with NMIs blocked.) 2. C-State transition diff --git a/Documentation/xilinx/eemi.txt b/Documentation/xilinx/eemi.txt index 0ab686c173be..5f39b4ffdcd4 100644 --- a/Documentation/xilinx/eemi.txt +++ b/Documentation/xilinx/eemi.txt @@ -41,8 +41,8 @@ Example of EEMI ops usage: int ret; eemi_ops = zynqmp_pm_get_eemi_ops(); - if (!eemi_ops) - return -ENXIO; + if (IS_ERR(eemi_ops)) + return PTR_ERR(eemi_ops); ret = eemi_ops->query_data(qdata, ret_payload); |