From 8e5f1ad116df6b0de65eac458d5e7c318d1c05af Mon Sep 17 00:00:00 2001 From: Tyler Hicks Date: Fri, 11 Aug 2017 04:33:52 +0000 Subject: seccomp: Sysctl to display available actions This patch creates a read-only sysctl containing an ordered list of seccomp actions that the kernel supports. The ordering, from left to right, is the lowest action value (kill) to the highest action value (allow). Currently, a read of the sysctl file would return "kill trap errno trace allow". The contents of this sysctl file can be useful for userspace code as well as the system administrator. The path to the sysctl is: /proc/sys/kernel/seccomp/actions_avail libseccomp and other userspace code can easily determine which actions the current kernel supports. The set of actions supported by the current kernel may be different than the set of action macros found in kernel headers that were installed where the userspace code was built. In addition, this sysctl will allow system administrators to know which actions are supported by the kernel and make it easier to configure exactly what seccomp logs through the audit subsystem. Support for this level of logging configuration will come in a future patch. Signed-off-by: Tyler Hicks Signed-off-by: Kees Cook --- Documentation/sysctl/kernel.txt | 1 + Documentation/userspace-api/seccomp_filter.rst | 16 ++++++++++++++++ 2 files changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index bac23c198360..995c42cf86ba 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -74,6 +74,7 @@ show up in /proc/sys/kernel: - reboot-cmd [ SPARC only ] - rtsig-max - rtsig-nr +- seccomp/ ==> Documentation/userspace-api/seccomp_filter.rst - sem - sem_next_id [ sysv ipc ] - sg-big-buff [ generic SCSI device (sg) ] diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst index f71eb5ef1f2d..35fc7cbf1d95 100644 --- a/Documentation/userspace-api/seccomp_filter.rst +++ b/Documentation/userspace-api/seccomp_filter.rst @@ -169,7 +169,23 @@ The ``samples/seccomp/`` directory contains both an x86-specific example and a more generic example of a higher level macro interface for BPF program generation. +Sysctls +======= + +Seccomp's sysctl files can be found in the ``/proc/sys/kernel/seccomp/`` +directory. Here's a description of each file in that directory: + +``actions_avail``: + A read-only ordered list of seccomp return values (refer to the + ``SECCOMP_RET_*`` macros above) in string form. The ordering, from + left-to-right, is the least permissive return value to the most + permissive return value. + The list represents the set of seccomp return values supported + by the kernel. A userspace program may use this list to + determine if the actions found in the ``seccomp.h``, when the + program was built, differs from the set of actions actually + supported in the current running kernel. Adding architecture support =========================== -- cgit v1.2.3 From 0ddec0fc8900201c0897b87b762b7c420436662f Mon Sep 17 00:00:00 2001 From: Tyler Hicks Date: Fri, 11 Aug 2017 04:33:54 +0000 Subject: seccomp: Sysctl to configure actions that are allowed to be logged Adminstrators can write to this sysctl to set the seccomp actions that are allowed to be logged. Any actions not found in this sysctl will not be logged. For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and SECCOMP_RET_ERRNO actions would be loggable if "kill trap errno" were written to the sysctl. SECCOMP_RET_TRACE actions would not be logged since its string representation ("trace") wasn't present in the sysctl value. The path to the sysctl is: /proc/sys/kernel/seccomp/actions_logged The actions_avail sysctl can be read to discover the valid action names that can be written to the actions_logged sysctl with the exception of "allow". SECCOMP_RET_ALLOW actions cannot be configured for logging. The default setting for the sysctl is to allow all actions to be logged except SECCOMP_RET_ALLOW. While only SECCOMP_RET_KILL actions are currently logged, an upcoming patch will allow applications to request additional actions to be logged. There's one important exception to this sysctl. If a task is specifically being audited, meaning that an audit context has been allocated for the task, seccomp will log all actions other than SECCOMP_RET_ALLOW despite the value of actions_logged. This exception preserves the existing auditing behavior of tasks with an allocated audit context. With this patch, the logic for deciding if an action will be logged is: if action == RET_ALLOW: do not log else if action == RET_KILL && RET_KILL in actions_logged: log else if audit_enabled && task-is-being-audited: log else: do not log Signed-off-by: Tyler Hicks Signed-off-by: Kees Cook --- Documentation/userspace-api/seccomp_filter.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst index 35fc7cbf1d95..2d1d8ab04ac5 100644 --- a/Documentation/userspace-api/seccomp_filter.rst +++ b/Documentation/userspace-api/seccomp_filter.rst @@ -187,6 +187,24 @@ directory. Here's a description of each file in that directory: program was built, differs from the set of actions actually supported in the current running kernel. +``actions_logged``: + A read-write ordered list of seccomp return values (refer to the + ``SECCOMP_RET_*`` macros above) that are allowed to be logged. Writes + to the file do not need to be in ordered form but reads from the file + will be ordered in the same way as the actions_avail sysctl. + + It is important to note that the value of ``actions_logged`` does not + prevent certain actions from being logged when the audit subsystem is + configured to audit a task. If the action is not found in + ``actions_logged`` list, the final decision on whether to audit the + action for that task is ultimately left up to the audit subsystem to + decide for all seccomp return values other than ``SECCOMP_RET_ALLOW``. + + The ``allow`` string is not accepted in the ``actions_logged`` sysctl + as it is not possible to log ``SECCOMP_RET_ALLOW`` actions. Attempting + to write ``allow`` to the sysctl will result in an EINVAL being + returned. + Adding architecture support =========================== -- cgit v1.2.3 From 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4 Mon Sep 17 00:00:00 2001 From: Tyler Hicks Date: Fri, 11 Aug 2017 04:33:57 +0000 Subject: seccomp: Action to log before allowing Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing the syscall. At the implementation level, this action is identical to the existing SECCOMP_RET_ALLOW action. However, it can be very useful when initially developing a seccomp filter for an application. The developer can set the default action to be SECCOMP_RET_LOG, maybe mark any obviously needed syscalls with SECCOMP_RET_ALLOW, and then put the application through its paces. A list of syscalls that triggered the default action (SECCOMP_RET_LOG) can be easily gleaned from the logs and that list can be used to build the syscall whitelist. Finally, the developer can change the default action to the desired value. This provides a more friendly experience than seeing the application get killed, then updating the filter and rebuilding the app, seeing the application get killed due to a different syscall, then updating the filter and rebuilding the app, etc. The functionality is similar to what's supported by the various LSMs. SELinux has permissive mode, AppArmor has complain mode, SMACK has bring-up mode, etc. SECCOMP_RET_LOG is given a lower value than SECCOMP_RET_ALLOW as allow while logging is slightly more restrictive than quietly allowing. Unfortunately, the tests added for SECCOMP_RET_LOG are not capable of inspecting the audit log to verify that the syscall was logged. With this patch, the logic for deciding if an action will be logged is: if action == RET_ALLOW: do not log else if action == RET_KILL && RET_KILL in actions_logged: log else if action == RET_LOG && RET_LOG in actions_logged: log else if filter-requests-logging && action in actions_logged: log else if audit_enabled && process-is-being-audited: log else: do not log Signed-off-by: Tyler Hicks Signed-off-by: Kees Cook --- Documentation/userspace-api/seccomp_filter.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst index 2d1d8ab04ac5..f4977357daf2 100644 --- a/Documentation/userspace-api/seccomp_filter.rst +++ b/Documentation/userspace-api/seccomp_filter.rst @@ -141,6 +141,15 @@ In precedence order, they are: allow use of ptrace, even of other sandboxed processes, without extreme care; ptracers can use this mechanism to escape.) +``SECCOMP_RET_LOG``: + Results in the system call being executed after it is logged. This + should be used by application developers to learn which syscalls their + application needs without having to iterate through multiple test and + development cycles to build the list. + + This action will only be logged if "log" is present in the + actions_logged sysctl string. + ``SECCOMP_RET_ALLOW``: Results in the system call being executed. -- cgit v1.2.3 From fd76875ca289a3d4722f266fd2d5532a27083903 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Fri, 11 Aug 2017 12:53:18 -0700 Subject: seccomp: Rename SECCOMP_RET_KILL to SECCOMP_RET_KILL_THREAD In preparation for adding SECCOMP_RET_KILL_PROCESS, rename SECCOMP_RET_KILL to the more accurate SECCOMP_RET_KILL_THREAD. The existing selftest values are intentionally left as SECCOMP_RET_KILL just to be sure we're exercising the alias. Signed-off-by: Kees Cook --- Documentation/networking/filter.txt | 2 +- Documentation/userspace-api/seccomp_filter.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index b69b205501de..73aa0f12156d 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -337,7 +337,7 @@ Examples for low-level BPF: jeq #14, good /* __NR_rt_sigprocmask */ jeq #13, good /* __NR_rt_sigaction */ jeq #35, good /* __NR_nanosleep */ - bad: ret #0 /* SECCOMP_RET_KILL */ + bad: ret #0 /* SECCOMP_RET_KILL_THREAD */ good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */ The above example code can be placed into a file (here called "foo"), and diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst index f4977357daf2..d76396f2d8ed 100644 --- a/Documentation/userspace-api/seccomp_filter.rst +++ b/Documentation/userspace-api/seccomp_filter.rst @@ -87,11 +87,11 @@ Return values A seccomp filter may return any of the following values. If multiple filters exist, the return value for the evaluation of a given system call will always use the highest precedent value. (For example, -``SECCOMP_RET_KILL`` will always take precedence.) +``SECCOMP_RET_KILL_THREAD`` will always take precedence.) In precedence order, they are: -``SECCOMP_RET_KILL``: +``SECCOMP_RET_KILL_THREAD``: Results in the task exiting immediately without executing the system call. The exit status of the task (``status & 0x7f``) will be ``SIGSYS``, not ``SIGKILL``. -- cgit v1.2.3 From 0466bdb99e8744bc9befa8d62a317f0fd7fd7421 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Fri, 11 Aug 2017 13:12:11 -0700 Subject: seccomp: Implement SECCOMP_RET_KILL_PROCESS action MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Right now, SECCOMP_RET_KILL_THREAD (neé SECCOMP_RET_KILL) kills the current thread. There have been a few requests for this to kill the entire process (the thread group). This cannot be just changed (discovered when adding coredump support since coredumping kills the entire process) because there are userspace programs depending on the thread-kill behavior. Instead, implement SECCOMP_RET_KILL_PROCESS, which is 0x80000000, and can be processed as "-1" by the kernel, below the existing RET_KILL that is ABI-set to "0". For userspace, SECCOMP_RET_ACTION_FULL is added to expand the mask to the signed bit. Old userspace using the SECCOMP_RET_ACTION mask will see SECCOMP_RET_KILL_PROCESS as 0 still, but this would only be visible when examining the siginfo in a core dump from a RET_KILL_*, where it will think it was thread-killed instead of process-killed. Attempts to introduce this behavior via other ways (filter flags, seccomp struct flags, masked RET_DATA bits) all come with weird side-effects and baggage. This change preserves the central behavioral expectations of the seccomp filter engine without putting too great a burden on changes needed in userspace to use the new action. The new action is discoverable by userspace through either the new actions_avail sysctl or through the SECCOMP_GET_ACTION_AVAIL seccomp operation. If used without checking for availability, old kernels will treat RET_KILL_PROCESS as RET_KILL_THREAD (since the old mask will produce RET_KILL_THREAD). Cc: Paul Moore Cc: Fabricio Voznika Signed-off-by: Kees Cook --- Documentation/userspace-api/seccomp_filter.rst | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst index d76396f2d8ed..099c412951d6 100644 --- a/Documentation/userspace-api/seccomp_filter.rst +++ b/Documentation/userspace-api/seccomp_filter.rst @@ -87,10 +87,15 @@ Return values A seccomp filter may return any of the following values. If multiple filters exist, the return value for the evaluation of a given system call will always use the highest precedent value. (For example, -``SECCOMP_RET_KILL_THREAD`` will always take precedence.) +``SECCOMP_RET_KILL_PROCESS`` will always take precedence.) In precedence order, they are: +``SECCOMP_RET_KILL_PROCESS``: + Results in the entire process exiting immediately without executing + the system call. The exit status of the task (``status & 0x7f``) + will be ``SIGSYS``, not ``SIGKILL``. + ``SECCOMP_RET_KILL_THREAD``: Results in the task exiting immediately without executing the system call. The exit status of the task (``status & 0x7f``) will -- cgit v1.2.3 From a4e6f1c49e0494421d069b0c3110f59b8fd74320 Mon Sep 17 00:00:00 2001 From: Hoegeun Kwon Date: Thu, 13 Jul 2017 11:20:41 +0900 Subject: dt-bindings: Add binding for Samsung S6E63J0X03 panel The Samsung S6E63J0X03 is a 1.63" 320x320 AMOLED panel connected using MIPI-DSI interfaces. Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda Acked-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/1499912443-3671-2-git-send-email-hoegeun.kwon@samsung.com --- .../bindings/display/panel/samsung,s6e63j0x03.txt | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt new file mode 100644 index 000000000000..3f1a8392af7f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt @@ -0,0 +1,24 @@ +Samsung S6E63J0X03 1.63" 320x320 AMOLED panel (interface: MIPI-DSI command mode) + +Required properties: + - compatible: "samsung,s6e63j0x03" + - reg: the virtual channel number of a DSI peripheral + - vdd3-supply: I/O voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpios: a GPIO spec for the reset pin (active low) + - te-gpios: a GPIO spec for the tearing effect synchronization signal + gpio pin (active high) + +Example: +&dsi { + ... + + panel@0 { + compatible = "samsung,s6e63j0x03"; + reg = <0>; + vdd3-supply = <&ldo16_reg>; + vci-supply = <&ldo20_reg>; + reset-gpios = <&gpe0 1 GPIO_ACTIVE_LOW>; + te-gpios = <&gpx0 6 GPIO_ACTIVE_HIGH>; + }; +}; -- cgit v1.2.3 From 931974fae6e8a4f9a09b0639d240393d2e748d7c Mon Sep 17 00:00:00 2001 From: Philippe CORNU Date: Mon, 17 Jul 2017 15:19:51 +0200 Subject: dt-bindings: Add vendor prefix for Orise Technology Orise Technology is headquartered in Taiwan and specializes in manufacture of Flat Panel Display Driver IC and Flat Panel Display Controller IC. Signed-off-by: Philippe CORNU Acked-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/1500297593-30633-2-git-send-email-philippe.cornu@st.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 36b27b1efec6..1dff0b5ca6e4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -243,6 +243,7 @@ ontat On Tat Industrial Company opencores OpenCores.org option Option NV ORCL Oracle Corporation +orisetech Orise Technology ortustech Ortus Technology Co., Ltd. ovti OmniVision Technologies oxsemi Oxford Semiconductor, Ltd. -- cgit v1.2.3 From 59ef38f5bfb1ef756c0b783097ec2148250dcfca Mon Sep 17 00:00:00 2001 From: Philippe CORNU Date: Mon, 17 Jul 2017 15:19:52 +0200 Subject: dt-bindings: display: panel: Add support for Orise Tech OTM8009A DSI panel The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using a MIPI-DSI video interface. Its backlight is managed through the DSI link. Signed-off-by: Philippe CORNU Acked-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/1500297593-30633-3-git-send-email-philippe.cornu@st.com --- .../bindings/display/panel/orisetech,otm8009a.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt new file mode 100644 index 000000000000..6862028e7b2e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt @@ -0,0 +1,21 @@ +Orise Tech OTM8009A 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode) + +The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using +a MIPI-DSI video interface. Its backlight is managed through the DSI link. + +Required properties: + - compatible: "orisetech,otm8009a" + - reg: the virtual channel number of a DSI peripheral + +Optional properties: + - reset-gpios: a GPIO spec for the reset pin (active low). + +Example: +&dsi { + ... + panel@0 { + compatible = "orisetech,otm8009a"; + reg = <0>; + reset-gpios = <&gpioh 7 GPIO_ACTIVE_LOW>; + }; +}; -- cgit v1.2.3 From 043652aa3d87e2ea314327b57fde14ae60dd1d1e Mon Sep 17 00:00:00 2001 From: Marco Franchi Date: Thu, 20 Jul 2017 13:12:59 -0300 Subject: drm/panel: Add driver for Seiko 43WVF1G panel Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel. Datasheet available at: http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf Seiko 43WVF1G panel has two power supplies: avdd and dvdd and they require a specific power on/down sequence. For this reason the simple panel driver cannot be used to drive this panel, so create a new one heavily based on simple panel. Based on initial patch submission from Breno Lima. Signed-off-by: Marco Franchi Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/1500567179-6967-1-git-send-email-marco.franchi@nxp.com --- .../bindings/display/panel/seiko,43wvf1g.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt new file mode 100644 index 000000000000..aae57ef36cdd --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt @@ -0,0 +1,23 @@ +Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel + +Required properties: +- compatible: should be "sii,43wvf1g". +- "dvdd-supply": 3v3 digital regulator. +- "avdd-supply": 5v analog regulator. + +Optional properties: +- backlight: phandle for the backlight control. + +Example: + + panel { + compatible = "sii,43wvf1g"; + backlight = <&backlight_display>; + dvdd-supply = <®_lcd_3v3>; + avdd-supply = <®_lcd_5v>; + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; -- cgit v1.2.3 From 371cadd8c48c8766ec3e3ca3e0d0a6261f2a8cc0 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 18 Aug 2017 19:43:28 +0200 Subject: drm/doc: Document ioctl errno value patterns We're not super-consistent about these, but I think it's worth to document at least the commmon patterns. v2: - Add a not about ENOTTY (it's just a confusing name, but used exactly what it's meant for in DRM) (Chris). - Unconfuse the text for ENODEV (Daniel) - Move text undert the IOCTL heading (Chris). - typos Cc: Daniel Stone Cc: Joonas Lahtinen Cc: Chris Wilson Cc: "Zhang, Tina" Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20170818174328.6386-1-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-uapi.rst | 55 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 679373b4a03f..a2214cc1f821 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -168,6 +168,61 @@ IOCTL Support on Device Nodes .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c :doc: driver specific ioctls +Recommended IOCTL Return Values +------------------------------- + +In theory a driver's IOCTL callback is only allowed to return very few error +codes. In practice it's good to abuse a few more. This section documents common +practice within the DRM subsystem: + +ENOENT: + Strictly this should only be used when a file doesn't exist e.g. when + calling the open() syscall. We reuse that to signal any kind of object + lookup failure, e.g. for unknown GEM buffer object handles, unknown KMS + object handles and similar cases. + +ENOSPC: + Some drivers use this to differentiate "out of kernel memory" from "out + of VRAM". Sometimes also applies to other limited gpu resources used for + rendering (e.g. when you have a special limited compression buffer). + Sometimes resource allocation/reservation issues in command submission + IOCTLs are also signalled through EDEADLK. + + Simply running out of kernel/system memory is signalled through ENOMEM. + +EPERM/EACCESS: + Returned for an operation that is valid, but needs more privileges. + E.g. root-only or much more common, DRM master-only operations return + this when when called by unpriviledged clients. There's no clear + difference between EACCESS and EPERM. + +ENODEV: + Feature (like PRIME, modesetting, GEM) is not supported by the driver. + +ENXIO: + Remote failure, either a hardware transaction (like i2c), but also used + when the exporting driver of a shared dma-buf or fence doesn't support a + feature needed. + +EINTR: + DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can + return EINTR and in such a case should be restarted with the IOCTL + parameters left unchanged. + +EIO: + The GPU died and couldn't be resurrected through a reset. Modesetting + hardware failures are signalled through the "link status" connector + property. + +EINVAL: + Catch-all for anything that is an invalid argument combination which + cannot work. + +IOCTL also use other error codes like ETIME, EFAULT, EBUSY, ENOTTY but their +usage is in line with the common meanings. The above list tries to just document +DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of +"this IOCTL does not exist", and is used exactly as such in DRM. + .. kernel-doc:: include/drm/drm_ioctl.h :internal: -- cgit v1.2.3 From 8b17e80d9e4672c250114443b41cfe8908441857 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sun, 20 Aug 2017 12:05:54 +0200 Subject: drm/tve200: Add DT bindings This adds device tree bindings for the Faraday TVE200 IP block. This IP block is present in the Gemini ARM SoC and also in some Grain Media GMxxxx SoCs. Cc: devicetree@vger.kernel.org Acked-by: Rob Herring Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20170820100557.24991-1-linus.walleij@linaro.org --- .../devicetree/bindings/display/faraday,tve200.txt | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/faraday,tve200.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/faraday,tve200.txt b/Documentation/devicetree/bindings/display/faraday,tve200.txt new file mode 100644 index 000000000000..82e3bc0b7485 --- /dev/null +++ b/Documentation/devicetree/bindings/display/faraday,tve200.txt @@ -0,0 +1,54 @@ +* Faraday TV Encoder TVE200 + +Required properties: + +- compatible: must be one of: + "faraday,tve200" + "cortina,gemini-tvc", "faraday,tve200" + +- reg: base address and size of the control registers block + +- interrupts: contains an interrupt specifier for the interrupt + line from the TVE200 + +- clock-names: should contain "PCLK" for the clock line clocking the + silicon and "TVE" for the 27MHz clock to the video driver + +- clocks: contains phandle and clock specifier pairs for the entries + in the clock-names property. See + Documentation/devicetree/bindings/clock/clock-bindings.txt + +Optional properties: + +- resets: contains the reset line phandle for the block + +Required sub-nodes: + +- port: describes LCD panel signals, following the common binding + for video transmitter interfaces; see + Documentation/devicetree/bindings/media/video-interfaces.txt + This port should have the properties: + reg = <0>; + It should have one endpoint connected to a remote endpoint where + the display is connected. + +Example: + +display-controller@6a000000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "faraday,tve200"; + reg = <0x6a000000 0x1000>; + interrupts = <13 IRQ_TYPE_EDGE_RISING>; + resets = <&syscon GEMINI_RESET_TVC>; + clocks = <&syscon GEMINI_CLK_GATE_TVC>, + <&syscon GEMINI_CLK_TVC>; + clock-names = "PCLK", "TVE"; + + port@0 { + reg = <0>; + display_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; +}; -- cgit v1.2.3 From 179c02fe90a4104d32e92a46b9ff4ecc32bf3647 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sun, 20 Aug 2017 12:05:55 +0200 Subject: drm/tve200: Add new driver for TVE200 This adds a new DRM driver for the Faraday Technology TVE200 block. This "TV Encoder" encodes a ITU-T BT.656 stream and can be found in the StorLink SL3516 (later Cortina Systems CS3516) as well as the Grain Media GM8180. I do not have definitive word from anyone at Faraday that this IP block is theirs, but it bears the hallmark of their 3-digit version code (200) and is used in two SoCs from completely different companies. (Grain Media was fully owned by Faraday until it was transferred to NovoTek this january, and Faraday did lots of work on the StorLink SoCs.) The D-Link DIR-685 uses this in connection with the Ilitek ILI9322 panel driver that supports BT.656 input, while the GM8180 apparently has been used with the Cirrus Logic CS4954 digital video encoder. The oldest user seems to be something called Techwall 2835. This driver is heavily inspired by Eric Anholt's PL111 driver and therefore I have mentioned all the ancestor authors in the header file. Acked-by: Daniel Vetter Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20170820100557.24991-2-linus.walleij@linaro.org --- Documentation/gpu/index.rst | 1 + Documentation/gpu/tve200.rst | 6 ++++++ 2 files changed, 7 insertions(+) create mode 100644 Documentation/gpu/tve200.rst (limited to 'Documentation') diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 35d673bf9b56..c36586dad29d 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -15,6 +15,7 @@ Linux GPU Driver Developer's Guide pl111 tegra tinydrm + tve200 vc4 vga-switcheroo vgaarbiter diff --git a/Documentation/gpu/tve200.rst b/Documentation/gpu/tve200.rst new file mode 100644 index 000000000000..69b17b324e12 --- /dev/null +++ b/Documentation/gpu/tve200.rst @@ -0,0 +1,6 @@ +================================== + drm/tve200 Faraday TV Encoder 200 +================================== + +.. kernel-doc:: drivers/gpu/drm/tve200/tve200_drv.c + :doc: Faraday TV Encoder 200 -- cgit v1.2.3 From 523d3de41f02141f6f6cd497d07946a2837432cf Mon Sep 17 00:00:00 2001 From: Marek Szyprowski Date: Mon, 21 Aug 2017 10:05:01 +0200 Subject: clk: samsung: exynos5433: Add support for runtime PM Add runtime pm support for all clock controller units (CMU), which belong to power domains and require special handling during on/off operations. Typically special values has to be written to MUX registers to change internal clocks parents to OSC clock before turning power off. During such operation all clocks, which enter CMU has to be enabled to let MUX to stabilize. Also for each CMU there is one special parent clock, which has to be enabled all the time when any access to CMU registers is being done. This patch solves most of the mysterious external abort and freeze issues caused by a lack of proper parent CMU clock enabled or incorrect turn off procedure. Signed-off-by: Marek Szyprowski Reviewed-by: Ulf Hansson Reviewed-by: Chanwoo Choi Tested-by: Chanwoo Choi Reviewed-by: Krzysztof Kozlowski Signed-off-by: Michael Turquette Link: lkml.kernel.org/r/1503302703-13801-4-git-send-email-m.szyprowski@samsung.com --- .../devicetree/bindings/clock/exynos5433-clock.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt index 1dc80f8811fe..5c7dd12e667a 100644 --- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt @@ -168,6 +168,11 @@ Required Properties: - aclk_cam1_400 - aclk_cam1_552 +Optional properties: + - power-domains: a phandle to respective power domain node as described by + generic PM domain bindings (see power/power_domain.txt for more + information). + Each clock is assigned an identifier and client nodes can use this identifier to specify the clock which they consume. @@ -270,6 +275,7 @@ Example 2: Examples of clock controller nodes are listed below. clocks = <&xxti>, <&cmu_top CLK_ACLK_G2D_266>, <&cmu_top CLK_ACLK_G2D_400>; + power-domains = <&pd_g2d>; }; cmu_disp: clock-controller@13b90000 { @@ -295,6 +301,7 @@ Example 2: Examples of clock controller nodes are listed below. <&cmu_mif CLK_SCLK_DECON_ECLK_DISP>, <&cmu_mif CLK_SCLK_DECON_TV_VCLK_DISP>, <&cmu_mif CLK_ACLK_DISP_333>; + power-domains = <&pd_disp>; }; cmu_aud: clock-controller@114c0000 { @@ -304,6 +311,7 @@ Example 2: Examples of clock controller nodes are listed below. clock-names = "oscclk", "fout_aud_pll"; clocks = <&xxti>, <&cmu_top CLK_FOUT_AUD_PLL>; + power-domains = <&pd_aud>; }; cmu_bus0: clock-controller@13600000 { @@ -340,6 +348,7 @@ Example 2: Examples of clock controller nodes are listed below. clock-names = "oscclk", "aclk_g3d_400"; clocks = <&xxti>, <&cmu_top CLK_ACLK_G3D_400>; + power-domains = <&pd_g3d>; }; cmu_gscl: clock-controller@13cf0000 { @@ -353,6 +362,7 @@ Example 2: Examples of clock controller nodes are listed below. clocks = <&xxti>, <&cmu_top CLK_ACLK_GSCL_111>, <&cmu_top CLK_ACLK_GSCL_333>; + power-domains = <&pd_gscl>; }; cmu_apollo: clock-controller@11900000 { @@ -384,6 +394,7 @@ Example 2: Examples of clock controller nodes are listed below. clocks = <&xxti>, <&cmu_top CLK_SCLK_JPEG_MSCL>, <&cmu_top CLK_ACLK_MSCL_400>; + power-domains = <&pd_mscl>; }; cmu_mfc: clock-controller@15280000 { @@ -393,6 +404,7 @@ Example 2: Examples of clock controller nodes are listed below. clock-names = "oscclk", "aclk_mfc_400"; clocks = <&xxti>, <&cmu_top CLK_ACLK_MFC_400>; + power-domains = <&pd_mfc>; }; cmu_hevc: clock-controller@14f80000 { @@ -402,6 +414,7 @@ Example 2: Examples of clock controller nodes are listed below. clock-names = "oscclk", "aclk_hevc_400"; clocks = <&xxti>, <&cmu_top CLK_ACLK_HEVC_400>; + power-domains = <&pd_hevc>; }; cmu_isp: clock-controller@146d0000 { @@ -415,6 +428,7 @@ Example 2: Examples of clock controller nodes are listed below. clocks = <&xxti>, <&cmu_top CLK_ACLK_ISP_DIS_400>, <&cmu_top CLK_ACLK_ISP_400>; + power-domains = <&pd_isp>; }; cmu_cam0: clock-controller@120d0000 { @@ -430,6 +444,7 @@ Example 2: Examples of clock controller nodes are listed below. <&cmu_top CLK_ACLK_CAM0_333>, <&cmu_top CLK_ACLK_CAM0_400>, <&cmu_top CLK_ACLK_CAM0_552>; + power-domains = <&pd_cam0>; }; cmu_cam1: clock-controller@145d0000 { @@ -451,6 +466,7 @@ Example 2: Examples of clock controller nodes are listed below. <&cmu_top CLK_ACLK_CAM1_333>, <&cmu_top CLK_ACLK_CAM1_400>, <&cmu_top CLK_ACLK_CAM1_552>; + power-domains = <&pd_cam1>; }; Example 3: UART controller node that consumes the clock generated by the clock -- cgit v1.2.3 From ae432a9b314e07d486acfadc4df2f922721e6757 Mon Sep 17 00:00:00 2001 From: Marek Szyprowski Date: Mon, 21 Aug 2017 10:05:03 +0200 Subject: clk: samsung: exynos-audss: Add support for runtime PM This patch adds support for runtime PM to Exynos Audio SubSystem driver to enable full support for audio power domain on Exynos5 SoCs. The main change is moving register saving and restoring code from system sleep PM ops to runtime PM ops and implementing system sleep PM ops with generic pm_runtime_force_suspend/resume helpers. Runtime PM of the Exynos AudSS device is managed from clock core depending on the preparation status of the provided clocks. Signed-off-by: Marek Szyprowski Reviewed-by: Ulf Hansson Reviewed-by: Krzysztof Kozlowski Reviewed-by: Chanwoo Choi Signed-off-by: Michael Turquette Link: lkml.kernel.org/r/1503302703-13801-6-git-send-email-m.szyprowski@samsung.com --- Documentation/devicetree/bindings/clock/clk-exynos-audss.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt index 0c3d6015868d..f3635d5aeba4 100644 --- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt +++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt @@ -33,6 +33,12 @@ Required Properties: - clock-names: Aliases for the above clocks. They should be "pll_ref", "pll_in", "cdclk", "sclk_audio", and "sclk_pcm_in" respectively. +Optional Properties: + + - power-domains: a phandle to respective power domain node as described by + generic PM domain bindings (see power/power_domain.txt for more + information). + The following is the list of clocks generated by the controller. Each clock is assigned an identifier and client nodes use this identifier to specify the clock which they consume. Some of the clocks are available only on a particular -- cgit v1.2.3 From a5e03a48b296101b3bf248073a409fd768d44072 Mon Sep 17 00:00:00 2001 From: Sandy Huang Date: Sat, 2 Sep 2017 19:28:47 +0800 Subject: dt-bindings: display: Add Document for Rockchip Soc LVDS This patch add Document for Rockchip Soc RK3288 LVDS, This based on the patches from Mark yao and Heiko Stuebner. Signed-off-by: Mark yao Signed-off-by: Heiko Stuebner Signed-off-by: Sandy Huang Reviewed-by: Mark Yao Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/1504351729-135932-1-git-send-email-hjc@rock-chips.com --- .../bindings/display/rockchip/rockchip-lvds.txt | 99 ++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt new file mode 100644 index 000000000000..da6939efdb43 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt @@ -0,0 +1,99 @@ +Rockchip RK3288 LVDS interface +================================ + +Required properties: +- compatible: matching the soc type, one of + - "rockchip,rk3288-lvds"; + +- reg: physical base address of the controller and length + of memory mapped region. +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. +- clock-names: must contain "pclk_lvds" + +- avdd1v0-supply: regulator phandle for 1.0V analog power +- avdd1v8-supply: regulator phandle for 1.8V analog power +- avdd3v3-supply: regulator phandle for 3.3V analog power + +- rockchip,grf: phandle to the general register files syscon +- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output interface + +Optional properties: +- pinctrl-names: must contain a "lcdc" entry. +- pinctrl-0: pin control group to be used for this controller. + +Required nodes: + +The lvds has two video ports as described by + Documentation/devicetree/bindings/media/video-interfaces.txt +Their connections are modeled using the OF graph bindings specified in + Documentation/devicetree/bindings/graph.txt. + +- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl +- video port 1 for either a panel or subsequent encoder + +the lvds panel described by + Documentation/devicetree/bindings/display/panel/simple-panel.txt + +Panel required properties: +- ports for remote LVDS output + +Panel optional properties: +- data-mapping: should be "vesa-24","jeida-24" or "jeida-18". +This describes decribed by: + Documentation/devicetree/bindings/display/panel/panel-lvds.txt + +Example: + +lvds_panel: lvds-panel { + compatible = "auo,b101ean01"; + enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>; + data-mapping = "jeida-24"; + + ports { + panel_in_lvds: endpoint { + remote-endpoint = <&lvds_out_panel>; + }; + }; +}; + +For Rockchip RK3288: + + lvds: lvds@ff96c000 { + compatible = "rockchip,rk3288-lvds"; + rockchip,grf = <&grf>; + reg = <0xff96c000 0x4000>; + clocks = <&cru PCLK_LVDS_PHY>; + clock-names = "pclk_lvds"; + pinctrl-names = "lcdc"; + pinctrl-0 = <&lcdc_ctl>; + avdd1v0-supply = <&vdd10_lcd>; + avdd1v8-supply = <&vcc18_lcd>; + avdd3v3-supply = <&vcca_33>; + rockchip,output = "rgb"; + ports { + #address-cells = <1>; + #size-cells = <0>; + + lvds_in: port@0 { + reg = <0>; + + lvds_in_vopb: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_lvds>; + }; + lvds_in_vopl: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_lvds>; + }; + }; + + lvds_out: port@1 { + reg = <1>; + + lvds_out_panel: endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; -- cgit v1.2.3 From 45ae2787a0e6d57d75ac25ffdfc9d8c7f9c0f3f1 Mon Sep 17 00:00:00 2001 From: Sean Paul Date: Fri, 8 Sep 2017 10:32:07 -0400 Subject: drm/todo: Add s/dev_*/DRM_DEV_*/ coversion to TODO Now that we have the DRM_DEV_* variants, we should use them. Signed-off-by: Sean Paul Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20170908143218.9701-1-seanpaul@chromium.org --- Documentation/gpu/todo.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 22af55d06ab8..e3b622094bf4 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -177,6 +177,17 @@ following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and Contact: Daniel Vetter, respective driver maintainers +Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent +---------------------------------------------------------------------------- + +For drivers which could have multiple instances, it is necessary to +differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR +don't do this, drivers used dev_info/warn/err to make this differentiation. We +now have DRM_DEV_* variants of the drm print macros, so we can start to convert +those drivers back to using drm-formwatted specific log messages. + +Contact: Sean Paul, Maintainer of the driver you plan to convert + Core refactorings ================= -- cgit v1.2.3 From be05fe130fd02ce298cc0ebdfb2f0e7a70dccfd4 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Mon, 11 Sep 2017 08:51:51 +0200 Subject: drm/doc: Update todo.rst We're using this for outreachy, unfortunately someone already tried to look at a task that was done already :-( Update them all. Cc: Sean Paul Signed-off-by: Daniel Vetter Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20170911065151.22672-1-daniel.vetter@ffwll.ch --- Documentation/gpu/todo.rst | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index e3b622094bf4..de9512afd611 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -75,17 +75,6 @@ helpers. Contact: Ville Syrjälä, Daniel Vetter, driver maintainers -Implement deferred fbdev setup in the helper --------------------------------------------- - -Many (especially embedded drivers) want to delay fbdev setup until there's a -real screen plugged in. This is to avoid the dreaded fallback to the low-res -fbdev default. Many drivers have a hacked-up (and often broken) version of this, -better to do it once in the shared helpers. Thierry has a patch series, but that -one needs to be rebased and final polish applied. - -Contact: Thierry Reding, Daniel Vetter, driver maintainers - Convert early atomic drivers to async commit helpers ---------------------------------------------------- @@ -138,6 +127,8 @@ interfaces to fix these issues: the acquire context explicitly on stack and then also pass it down into drivers explicitly so that the legacy-on-atomic functions can use them. + Except for some driver code this is done. + * A bunch of the vtable hooks are now in the wrong place: DRM has a split between core vfunc tables (named ``drm_foo_funcs``), which are used to implement the userspace ABI. And then there's the optional hooks for the @@ -151,6 +142,8 @@ interfaces to fix these issues: connector at runtime. That's almost all of them, and would allow us to get rid of a lot of ``best_encoder`` boilerplate in drivers. + This was almost done, but new drivers added a few more cases again. + Contact: Daniel Vetter Get rid of dev->struct_mutex from GEM drivers -- cgit v1.2.3 From 8d532d36ac02a39c618abd1ee90a600a98274730 Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Sat, 2 Sep 2017 19:39:15 +0200 Subject: dt-bindings: iio: pressure: add LPS33HW and LPS35HW device bindings Signed-off-by: Lorenzo Bianconi Acked-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/st-sensors.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt index 9ec6f5ce54fc..678c035d9ed6 100644 --- a/Documentation/devicetree/bindings/iio/st-sensors.txt +++ b/Documentation/devicetree/bindings/iio/st-sensors.txt @@ -71,3 +71,5 @@ Pressure sensors: - st,lps25h-press - st,lps331ap-press - st,lps22hb-press +- st,lps33hw +- st,lps35hw -- cgit v1.2.3 From 439e7271dc2b63de379e37971dc2f64d71e24f8a Mon Sep 17 00:00:00 2001 From: Joe Lawrence Date: Thu, 31 Aug 2017 16:37:41 -0400 Subject: livepatch: introduce shadow variable API Add exported API for livepatch modules: klp_shadow_get() klp_shadow_alloc() klp_shadow_get_or_alloc() klp_shadow_free() klp_shadow_free_all() that implement "shadow" variables, which allow callers to associate new shadow fields to existing data structures. This is intended to be used by livepatch modules seeking to emulate additions to data structure definitions. See Documentation/livepatch/shadow-vars.txt for a summary of the new shadow variable API, including a few common use cases. See samples/livepatch/livepatch-shadow-* for example modules that demonstrate shadow variables. [jkosina@suse.cz: fix __klp_shadow_get_or_alloc() comment as spotted by Josh] Signed-off-by: Joe Lawrence Acked-by: Josh Poimboeuf Acked-by: Miroslav Benes Signed-off-by: Jiri Kosina --- Documentation/livepatch/shadow-vars.txt | 192 ++++++++++++++++++++++++++++++++ 1 file changed, 192 insertions(+) create mode 100644 Documentation/livepatch/shadow-vars.txt (limited to 'Documentation') diff --git a/Documentation/livepatch/shadow-vars.txt b/Documentation/livepatch/shadow-vars.txt new file mode 100644 index 000000000000..e3ffc4301bfa --- /dev/null +++ b/Documentation/livepatch/shadow-vars.txt @@ -0,0 +1,192 @@ +================ +Shadow Variables +================ + +Shadow variables are a simple way for livepatch modules to associate +additional "shadow" data with existing data structures. Shadow data is +allocated separately from parent data structures, which are left +unmodified. The shadow variable API described in this document is used +to allocate/attach and detach/release shadow variables to their parents. + +The implementation introduces a global, in-kernel hashtable that +associates pointers to parent objects and a numeric identifier of the +shadow data. The numeric identifier is a simple enumeration that may be +used to describe shadow variable version, class or type, etc. More +specifically, the parent pointer serves as the hashtable key while the +numeric id subsequently filters hashtable queries. Multiple shadow +variables may attach to the same parent object, but their numeric +identifier distinguishes between them. + + +1. Brief API summary +==================== + +(See the full API usage docbook notes in livepatch/shadow.c.) + +A hashtable references all shadow variables. These references are +stored and retrieved through a pair. + +* The klp_shadow variable data structure encapsulates both tracking +meta-data and shadow-data: + - meta-data + - obj - pointer to parent object + - id - data identifier + - data[] - storage for shadow data + +It is important to note that the klp_shadow_alloc() and +klp_shadow_get_or_alloc() calls, described below, store a *copy* of the +data that the functions are provided. Callers should provide whatever +mutual exclusion is required of the shadow data. + +* klp_shadow_get() - retrieve a shadow variable data pointer + - search hashtable for pair + +* klp_shadow_alloc() - allocate and add a new shadow variable + - search hashtable for pair + - if exists + - WARN and return NULL + - if doesn't already exist + - allocate a new shadow variable + - copy data into the new shadow variable + - add to the global hashtable + +* klp_shadow_get_or_alloc() - get existing or alloc a new shadow variable + - search hashtable for pair + - if exists + - return existing shadow variable + - if doesn't already exist + - allocate a new shadow variable + - copy data into the new shadow variable + - add pair to the global hashtable + +* klp_shadow_free() - detach and free a shadow variable + - find and remove a reference from global hashtable + - if found, free shadow variable + +* klp_shadow_free_all() - detach and free all <*, id> shadow variables + - find and remove any <*, id> references from global hashtable + - if found, free shadow variable + + +2. Use cases +============ + +(See the example shadow variable livepatch modules in samples/livepatch/ +for full working demonstrations.) + +For the following use-case examples, consider commit 1d147bfa6429 +("mac80211: fix AP powersave TX vs. wakeup race"), which added a +spinlock to net/mac80211/sta_info.h :: struct sta_info. Each use-case +example can be considered a stand-alone livepatch implementation of this +fix. + + +Matching parent's lifecycle +--------------------------- + +If parent data structures are frequently created and destroyed, it may +be easiest to align their shadow variables lifetimes to the same +allocation and release functions. In this case, the parent data +structure is typically allocated, initialized, then registered in some +manner. Shadow variable allocation and setup can then be considered +part of the parent's initialization and should be completed before the +parent "goes live" (ie, any shadow variable get-API requests are made +for this pair.) + +For commit 1d147bfa6429, when a parent sta_info structure is allocated, +allocate a shadow copy of the ps_lock pointer, then initialize it: + +#define PS_LOCK 1 +struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata, + const u8 *addr, gfp_t gfp) +{ + struct sta_info *sta; + spinlock_t *ps_lock; + + /* Parent structure is created */ + sta = kzalloc(sizeof(*sta) + hw->sta_data_size, gfp); + + /* Attach a corresponding shadow variable, then initialize it */ + ps_lock = klp_shadow_alloc(sta, PS_LOCK, NULL, sizeof(ps_lock), gfp); + if (!ps_lock) + goto shadow_fail; + spin_lock_init(ps_lock); + ... + +When requiring a ps_lock, query the shadow variable API to retrieve one +for a specific struct sta_info: + +void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta) +{ + spinlock_t *ps_lock; + + /* sync with ieee80211_tx_h_unicast_ps_buf */ + ps_lock = klp_shadow_get(sta, PS_LOCK); + if (ps_lock) + spin_lock(ps_lock); + ... + +When the parent sta_info structure is freed, first free the shadow +variable: + +void sta_info_free(struct ieee80211_local *local, struct sta_info *sta) +{ + klp_shadow_free(sta, PS_LOCK); + kfree(sta); + ... + + +In-flight parent objects +------------------------ + +Sometimes it may not be convenient or possible to allocate shadow +variables alongside their parent objects. Or a livepatch fix may +require shadow varibles to only a subset of parent object instances. In +these cases, the klp_shadow_get_or_alloc() call can be used to attach +shadow variables to parents already in-flight. + +For commit 1d147bfa6429, a good spot to allocate a shadow spinlock is +inside ieee80211_sta_ps_deliver_wakeup(): + +#define PS_LOCK 1 +void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta) +{ + DEFINE_SPINLOCK(ps_lock_fallback); + spinlock_t *ps_lock; + + /* sync with ieee80211_tx_h_unicast_ps_buf */ + ps_lock = klp_shadow_get_or_alloc(sta, PS_LOCK, + &ps_lock_fallback, sizeof(ps_lock_fallback), + GFP_ATOMIC); + if (ps_lock) + spin_lock(ps_lock); + ... + +This usage will create a shadow variable, only if needed, otherwise it +will use one that was already created for this pair. + +Like the previous use-case, the shadow spinlock needs to be cleaned up. +A shadow variable can be freed just before its parent object is freed, +or even when the shadow variable itself is no longer required. + + +Other use-cases +--------------- + +Shadow variables can also be used as a flag indicating that a data +structure was allocated by new, livepatched code. In this case, it +doesn't matter what data value the shadow variable holds, its existence +suggests how to handle the parent object. + + +3. References +============= + +* https://github.com/dynup/kpatch +The livepatch implementation is based on the kpatch version of shadow +variables. + +* http://files.mkgnu.net/files/dynamos/doc/papers/dynamos_eurosys_07.pdf +Dynamic and Adaptive Updates of Non-Quiescent Subsystems in Commodity +Operating System Kernels (Kritis Makris, Kyung Dong Ryu 2007) presented +a datatype update technique called "shadow data structures". -- cgit v1.2.3 From 50544f39018f8c75778d84228535bf4a0d588583 Mon Sep 17 00:00:00 2001 From: Jagan Teki Date: Sat, 26 Aug 2017 12:21:42 +0530 Subject: dt-bindings: Add vendor prefix for Amarula Solutions Added 'amarula' as a vendor prefix for Amarula Solutions, specialist in Embedded and Opensource solutions. Signed-off-by: Jagan Teki Acked-by: Rob Herring Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1ea1fd4232ab..192709de8632 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -18,6 +18,7 @@ al Annapurna Labs 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. -- cgit v1.2.3 From 15306b752f5a91ade95882aba83022f54fbaa433 Mon Sep 17 00:00:00 2001 From: Jagan Teki Date: Sat, 26 Aug 2017 15:39:24 +0530 Subject: ARM: dts: rockchip: Add rk3288 vyasa board This patch adds initial support for rk3288 based Vyasa board, which is made by Amarula Solutions. Signed-off-by: Jagan Teki Acked-by: Rob Herring Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index b003148e2945..326d24bca1a9 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -1,5 +1,9 @@ Rockchip platforms device tree bindings --------------------------------------- +- Amarula Vyasa RK3288 board + Required root node properties: + - compatible = "amarula,vyasa-rk3288", "rockchip,rk3288"; + - Asus Tinker board Required root node properties: - compatible = "asus,rk3288-tinker", "rockchip,rk3288"; -- cgit v1.2.3 From 912620c02c314a697b05d52263212c24a2a6b05b Mon Sep 17 00:00:00 2001 From: Tomas Novotny Date: Mon, 26 Jun 2017 16:30:16 +0200 Subject: dt-bindings: add vendor prefix for Touchless Biometric Systems AG TBS is a company providing biometrics products and solution in Access control and time management. Signed-off-by: Tomas Novotny Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1ea1fd4232ab..26d105625d38 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -329,6 +329,7 @@ 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 -- cgit v1.2.3 From ec11653b531099ddc08a8c7eb495ab83cae84e19 Mon Sep 17 00:00:00 2001 From: Steve French Date: Thu, 14 Sep 2017 14:51:20 -0500 Subject: CIFS/SMB3: Update documentation to reflect SMB3 and various changes Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Reviewed-by: Pavel Shilovsky --- Documentation/filesystems/cifs/AUTHORS | 5 ++ Documentation/filesystems/cifs/README | 81 ++++++++++++++++----------------- Documentation/filesystems/cifs/TODO | 72 ++++++++++++++--------------- Documentation/filesystems/cifs/cifs.txt | 24 ++++++---- 4 files changed, 91 insertions(+), 91 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/AUTHORS b/Documentation/filesystems/cifs/AUTHORS index c98800df677f..9f4f87e16240 100644 --- a/Documentation/filesystems/cifs/AUTHORS +++ b/Documentation/filesystems/cifs/AUTHORS @@ -41,6 +41,11 @@ Igor Mammedov (DFS support) Jeff Layton (many, many fixes, as well as great work on the cifs Kerberos code) Scott Lovenberg Pavel Shilovsky (for great work adding SMB2 support, and various SMB3 features) +Aurelien Aptel (for DFS SMB3 work and some key bug fixes) +Ronnie Sahlberg (for SMB3 xattr work and bug fixes) +Shirish Pargaonkar (for many ACL patches over the years) +Sachin Prabhu (many bug fixes, including for reconnect, copy offload and security) + Test case and Bug Report contributors ------------------------------------- diff --git a/Documentation/filesystems/cifs/README b/Documentation/filesystems/cifs/README index a54788405429..a9da51553ba3 100644 --- a/Documentation/filesystems/cifs/README +++ b/Documentation/filesystems/cifs/README @@ -1,10 +1,14 @@ -The CIFS VFS support for Linux supports many advanced network filesystem -features such as hierarchical dfs like namespace, hardlinks, locking and more. +This module supports the SMB3 family of advanced network protocols (as well +as older dialects, originally called "CIFS" or SMB1). + +The CIFS VFS module for Linux supports many advanced network filesystem +features such as hierarchical DFS like namespace, hardlinks, locking and more. It was designed to comply with the SNIA CIFS Technical Reference (which supersedes the 1992 X/Open SMB Standard) as well as to perform best practice practical interoperability with Windows 2000, Windows XP, Samba and equivalent servers. This code was developed in participation with the Protocol Freedom -Information Foundation. +Information Foundation. CIFS and now SMB3 has now become a defacto +standard for interoperating between Macs and Windows and major NAS appliances. Please see http://protocolfreedom.org/ and @@ -15,30 +19,11 @@ for more details. For questions or bug reports please contact: sfrench@samba.org (sfrench@us.ibm.com) +See the project page at: https://wiki.samba.org/index.php/LinuxCIFS_utils + Build instructions: ================== -For Linux 2.4: -1) Get the kernel source (e.g.from http://www.kernel.org) -and download the cifs vfs source (see the project page -at http://us1.samba.org/samba/Linux_CIFS_client.html) -and change directory into the top of the kernel directory -then patch the kernel (e.g. "patch -p1 < cifs_24.patch") -to add the cifs vfs to your kernel configure options if -it has not already been added (e.g. current SuSE and UL -users do not need to apply the cifs_24.patch since the cifs vfs is -already in the kernel configure menu) and then -mkdir linux/fs/cifs and then copy the current cifs vfs files from -the cifs download to your kernel build directory e.g. - - cp /fs/cifs/* to /fs/cifs - -2) make menuconfig (or make xconfig) -3) select cifs from within the network filesystem choices -4) save and exit -5) make dep -6) make modules (or "make" if CIFS VFS not to be built as a module) - -For Linux 2.6: +For Linux: 1) Download the kernel (e.g. from http://www.kernel.org) and change directory into the top of the kernel directory tree (e.g. /usr/src/linux-2.5.73) @@ -61,16 +46,13 @@ would simply type "make install"). If you do not have the utility mount.cifs (in the Samba 3.0 source tree and on the CIFS VFS web site) copy it to the same directory in which mount.smbfs and similar files reside (usually /sbin). Although the helper software is not -required, mount.cifs is recommended. Eventually the Samba 3.0 utility program -"net" may also be helpful since it may someday provide easier mount syntax for -users who are used to Windows e.g. - net use +required, mount.cifs is recommended. Most distros include a "cifs-utils" +package that includes this utility so it is recommended to install this. + Note that running the Winbind pam/nss module (logon service) on all of your Linux clients is useful in mapping Uids and Gids consistently across the domain to the proper network user. The mount.cifs mount helper can be -trivially built from Samba 3.0 or later source e.g. by executing: - - gcc samba/source/client/mount.cifs.c -o mount.cifs +found at cifs-utils.git on git.samba.org If cifs is built as a module, then the size and number of network buffers and maximum number of simultaneous requests to one server can be configured. @@ -79,6 +61,18 @@ Changing these from their defaults is not recommended. By executing modinfo on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made at module initialization time (by running insmod cifs.ko) can be seen. +Recommendations +=============== +To improve security the SMB2.1 dialect or later (usually will get SMB3) is now +the new default. To use old dialects (e.g. to mount Windows XP) use "vers=1.0" +on mount (or vers=2.0 for Windows Vista). Note that the CIFS (vers=1.0) is +much older and less secure than the default dialect SMB3 which includes +many advanced security features such as downgrade attack detection +and encrypted shares and stronger signing and authentication algorithms. +There are additional mount options that may be helpful for SMB3 to get +improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1): + "mfsymlinks" and "cifsacl" and "idsfromsid" + Allowing User Mounts ==================== To permit users to mount and unmount over directories they own is possible @@ -98,9 +92,7 @@ and execution of suid programs on the remote target would be enabled by default. This can be changed, as with nfs and other filesystems, by simply specifying "nosuid" among the mount options. For user mounts though to be able to pass the suid flag to mount requires rebuilding -mount.cifs with the following flag: - - gcc samba/source/client/mount.cifs.c -DCIFS_ALLOW_USR_SUID -o mount.cifs +mount.cifs with the following flag: CIFS_ALLOW_USR_SUID There is a corresponding manual page for cifs mounting in the Samba 3.0 and later source tree in docs/manpages/mount.cifs.8 @@ -189,18 +181,18 @@ applications running on the same server as Samba. Use instructions: ================ Once the CIFS VFS support is built into the kernel or installed as a module -(cifs.o), you can use mount syntax like the following to access Samba or Windows -servers: +(cifs.ko), you can use mount syntax like the following to access Samba or +Mac or Windows servers: - mount -t cifs //9.53.216.11/e$ /mnt -o user=myname,pass=mypassword + mount -t cifs //9.53.216.11/e$ /mnt -o username=myname,password=mypassword Before -o the option -v may be specified to make the mount.cifs mount helper display the mount steps more verbosely. After -o the following commonly used cifs vfs specific options are supported: - user= - pass= + username= + password= domain= Other cifs mount options are described below. Use of TCP names (in addition to @@ -246,13 +238,16 @@ the Server's registry. Samba starting with version 3.10 will allow such filenames (ie those which contain valid Linux characters, which normally would be forbidden for Windows/CIFS semantics) as long as the server is configured for Unix Extensions (and the client has not disabled -/proc/fs/cifs/LinuxExtensionsEnabled). - +/proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option +"mapposix" can be used on CIFS (vers=1.0) to force the mapping of +illegal Windows/NTFS/SMB characters to a remap range (this mount parm +is the default for SMB3). This remap ("mapposix") range is also +compatible with Mac (and "Services for Mac" on some older Windows). CIFS VFS Mount Options ====================== A partial list of the supported mount options follows: - user The user name to use when trying to establish + username The user name to use when trying to establish the CIFS session. password The user password. If the mount helper is installed, the user will be prompted for password diff --git a/Documentation/filesystems/cifs/TODO b/Documentation/filesystems/cifs/TODO index 066ffddc3964..396ecfd6ff4a 100644 --- a/Documentation/filesystems/cifs/TODO +++ b/Documentation/filesystems/cifs/TODO @@ -1,4 +1,4 @@ -Version 2.03 August 1, 2014 +Version 2.04 September 13, 2017 A Partial List of Missing Features ================================== @@ -8,73 +8,69 @@ for visible, important contributions to this module. Here is a partial list of the known problems and missing features: a) SMB3 (and SMB3.02) missing optional features: - - RDMA + - RDMA (started) - multichannel (started) - directory leases (improved metadata caching) - T10 copy offload (copy chunk is only mechanism supported) - - encrypted shares b) improved sparse file support c) Directory entry caching relies on a 1 second timer, rather than -using FindNotify or equivalent. - (started) +using Directory Leases d) quota support (needs minor kernel change since quota calls to make it to network filesystems or deviceless filesystems) -e) improve support for very old servers (OS/2 and Win9x for example) -Including support for changing the time remotely (utimes command). +e) Better optimize open to reduce redundant opens (using reference +counts more) and to improve use of compounding in SMB3 to reduce +number of roundtrips. -f) hook lower into the sockets api (as NFS/SunRPC does) to avoid the -extra copy in/out of the socket buffers in some cases. - -g) Better optimize open (and pathbased setfilesize) to reduce the -oplock breaks coming from windows srv. Piggyback identical file -opens on top of each other by incrementing reference count rather -than resending (helps reduce server resource utilization and avoid -spurious oplock breaks). - -h) Add support for storing symlink info to Windows servers -in the Extended Attribute format their SFU clients would recognize. - -i) Finish inotify support so kde and gnome file list windows +f) Finish inotify support so kde and gnome file list windows will autorefresh (partially complete by Asser). Needs minor kernel vfs change to support removing D_NOTIFY on a file. -j) Add GUI tool to configure /proc/fs/cifs settings and for display of +g) Add GUI tool to configure /proc/fs/cifs settings and for display of the CIFS statistics (started) -k) implement support for security and trusted categories of xattrs +h) implement support for security and trusted categories of xattrs (requires minor protocol extension) to enable better support for SELINUX -l) Implement O_DIRECT flag on open (already supported on mount) +i) Implement O_DIRECT flag on open (already supported on mount) -m) Create UID mapping facility so server UIDs can be mapped on a per +j) Create UID mapping facility so server UIDs can be mapped on a per mount or a per server basis to client UIDs or nobody if no mapping -exists. This is helpful when Unix extensions are negotiated to -allow better permission checking when UIDs differ on the server -and client. Add new protocol request to the CIFS protocol -standard for asking the server for the corresponding name of a -particular uid. +exists. Also better integration with winbind for resolving SID owners + +k) Add tools to take advantage of more smb3 specific ioctls and features + +l) encrypted file support + +m) improved stats gathering, tools (perhaps integration with nfsometer?) -n) DOS attrs - returned as pseudo-xattr in Samba format (check VFAT and NTFS for this too) +n) allow setting more NTFS/SMB3 file attributes remotely (currently limited to compressed +file attribute via chflags) and improve user space tools for managing and +viewing them. -o) mount check for unmatched uids +o) mount helper GUI (to simplify the various configuration options on mount) -p) Add support for new vfs entry point for fallocate +p) autonegotiation of dialects (offering more than one dialect ie SMB3.02, +SMB3, SMB2.1 not just SMB3). -q) Add tools to take advantage of cifs/smb3 specific ioctls and features -such as "CopyChunk" (fast server side file copy) +q) Allow mount.cifs to be more verbose in reporting errors with dialect +or unsupported feature errors. -r) encrypted file support +r) updating cifs documentation, and user guid. -s) improved stats gathering, tools (perhaps integration with nfsometer?) +s) Addressing bugs found by running a broader set of xfstests in standard +file system xfstest suite. -t) allow setting more NTFS/SMB3 file attributes remotely (currently limited to compressed -file attribute via chflags) +t) split cifs and smb3 support into separate modules so legacy (and less +secure) CIFS dialect can be disabled in environments that don't need it +and simplify the code. -u) mount helper GUI (to simplify the various configuration options on mount) +u) Finish up SMB3.1.1 dialect support +v) POSIX Extensions for SMB3.1.1 KNOWN BUGS ==================================== diff --git a/Documentation/filesystems/cifs/cifs.txt b/Documentation/filesystems/cifs/cifs.txt index 2fac91ac96cf..67756607246e 100644 --- a/Documentation/filesystems/cifs/cifs.txt +++ b/Documentation/filesystems/cifs/cifs.txt @@ -1,24 +1,28 @@ - This is the client VFS module for the Common Internet File System - (CIFS) protocol which is the successor to the Server Message Block + This is the client VFS module for the SMB3 NAS protocol as well + older dialects such as the Common Internet File System (CIFS) + protocol which was the successor to the Server Message Block (SMB) protocol, the native file sharing mechanism for most early PC operating systems. New and improved versions of CIFS are now called SMB2 and SMB3. These dialects are also supported by the CIFS VFS module. CIFS is fully supported by network - file servers such as Windows 2000, 2003, 2008 and 2012 + file servers such as Windows 2000, 2003, 2008, 2012 and 2016 as well by Samba (which provides excellent CIFS - server support for Linux and many other operating systems), so + server support for Linux and many other operating systems), Apple + systems, as well as most Network Attached Storage vendors, so this network filesystem client can mount to a wide variety of servers. The intent of this module is to provide the most advanced network - file system function for CIFS compliant servers, including better - POSIX compliance, secure per-user session establishment, high - performance safe distributed caching (oplock), optional packet + file system function for SMB3 compliant servers, including advanced + security features, excellent parallelized high performance i/o, better + POSIX compliance, secure per-user session establishment, encryption, + high performance safe distributed caching (leases/oplocks), optional packet signing, large files, Unicode support and other internationalization improvements. Since both Samba server and this filesystem client support - the CIFS Unix extensions, the combination can provide a reasonable - alternative to NFSv4 for fileserving in some Linux to Linux environments, - not just in Linux to Windows environments. + the CIFS Unix extensions (and in the future SMB3 POSIX extensions), + the combination can provide a reasonable alternative to other network and + cluster file systems for fileserving in some Linux to Linux environments, + not just in Linux to Windows (or Linux to Mac) environments. This filesystem has an mount utility (mount.cifs) that can be obtained from -- cgit v1.2.3 From 17760376ae31e06f66b3c3b8981f5978d4c53150 Mon Sep 17 00:00:00 2001 From: Sergei Shtylyov Date: Tue, 12 Sep 2017 23:37:18 +0300 Subject: soc: renesas: rcar-rst: add R8A77970 support Add support for R-Car V3M (R8A77970) to the R-Car RST driver -- this driver is needed for the clock driver to work. Signed-off-by: Sergei Shtylyov Reviewed-by: Geert Uytterhoeven Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/reset/renesas,rst.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt b/Documentation/devicetree/bindings/reset/renesas,rst.txt index e5a03ffe04fb..a8014f3ab8ba 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rst.txt +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt @@ -26,6 +26,7 @@ Required properties: - "renesas,r8a7794-rst" (R-Car E2) - "renesas,r8a7795-rst" (R-Car H3) - "renesas,r8a7796-rst" (R-Car M3-W) + - "renesas,r8a77970-rst" (R-Car V3M) - "renesas,r8a77995-rst" (R-Car D3) - reg: Address start and address range for the device. -- cgit v1.2.3 From 055fb568157c3a6754228138b3ca51247cb4f466 Mon Sep 17 00:00:00 2001 From: Fabrizio Castro Date: Tue, 22 Aug 2017 14:52:19 +0100 Subject: dt-bindings: apmu: Document r8a7745 support Document APMU and SMP enable method for RZ/G1E (also known as r8a7745) SoC. Signed-off-by: Fabrizio Castro Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/power/renesas,apmu.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.txt b/Documentation/devicetree/bindings/power/renesas,apmu.txt index af21502e939c..f747f95eee58 100644 --- a/Documentation/devicetree/bindings/power/renesas,apmu.txt +++ b/Documentation/devicetree/bindings/power/renesas,apmu.txt @@ -8,6 +8,7 @@ Required properties: - compatible: Should be "renesas,-apmu", "renesas,apmu" as fallback. Examples with soctypes are: - "renesas,r8a7743-apmu" (RZ/G1M) + - "renesas,r8a7745-apmu" (RZ/G1E) - "renesas,r8a7790-apmu" (R-Car H2) - "renesas,r8a7791-apmu" (R-Car M2-W) - "renesas,r8a7792-apmu" (R-Car V2H) -- cgit v1.2.3 From 8ac491a5d0934bf1a77db155d759c682ab790c45 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 30 Aug 2017 11:53:01 +0200 Subject: dt-bindings: display: renesas: dw-hdmi: Drop bogus node name suffix Node names should not use numerical suffixes if the nodes can be distinguished by unit-address. Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt index b1a8929c2536..3a72a103a18a 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt @@ -37,7 +37,7 @@ Optional properties: Example: - hdmi0: hdmi0@fead0000 { + hdmi0: hdmi@fead0000 { compatible = "renesas,r8a7795-dw-hdmi"; reg = <0 0xfead0000 0 0x10000>; interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>; -- cgit v1.2.3 From 443c1631172a7a6dc19c1657425354327858a548 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 25 Aug 2017 14:56:49 +0200 Subject: ARM: shmobile: Document R-Car V3M SoC DT bindings Signed-off-by: Geert Uytterhoeven Acked-by: Rob Herring Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index ae75cb3b1331..a1f06711a4dd 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -39,6 +39,8 @@ SoCs: compatible = "renesas,r8a7795" - R-Car M3-W (R8A77960) compatible = "renesas,r8a7796" + - R-Car V3M (R8A77970) + compatible = "renesas,r8a77970" - R-Car D3 (R8A77995) compatible = "renesas,r8a77995" -- cgit v1.2.3 From bab9b2a74fe9da96e895e0919f625679a0a8c964 Mon Sep 17 00:00:00 2001 From: Sergei Shtylyov Date: Tue, 12 Sep 2017 23:37:20 +0300 Subject: soc: renesas: rcar-sysc: add R8A77970 support Add support for R-Car V3M (R8A77970) SoC power areas to the R-Car SYSC driver. Based on the original (and large) patch by Daisuke Matsushita . Signed-off-by: Vladimir Barinov Signed-off-by: Sergei Shtylyov Reviewed-by: Geert Uytterhoeven Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt index 98cc8c09d02d..8690f10426a3 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt @@ -17,6 +17,7 @@ Required properties: - "renesas,r8a7794-sysc" (R-Car E2) - "renesas,r8a7795-sysc" (R-Car H3) - "renesas,r8a7796-sysc" (R-Car M3-W) + - "renesas,r8a77970-sysc" (R-Car V3M) - "renesas,r8a77995-sysc" (R-Car D3) - reg: Address start and address range for the device. - #power-domain-cells: Must be 1. -- cgit v1.2.3 From fc9655e65160936e32adae0d0e8aae25eb12c4e0 Mon Sep 17 00:00:00 2001 From: Eugeniy Paltsev Date: Thu, 14 Sep 2017 12:49:41 +0200 Subject: ARC: reset: add missing DT binding documentation for HSDKv1 reset driver When applying the original patch [1], the DT binding docs were lost. This patch adds them back. [1] https://patchwork.kernel.org/patch/9852997/ Fixes: e0be864f1424 ("ARC: reset: introduce HSDKv1 reset driver") Signed-off-by: Eugeniy Paltsev Signed-off-by: Philipp Zabel --- .../bindings/reset/snps,hsdk-v1-reset.txt | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/snps,hsdk-v1-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/snps,hsdk-v1-reset.txt b/Documentation/devicetree/bindings/reset/snps,hsdk-v1-reset.txt new file mode 100644 index 000000000000..6a68146ee353 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/snps,hsdk-v1-reset.txt @@ -0,0 +1,28 @@ +Binding for the HSDK v1 reset controller + +This binding uses the common reset binding[1]. + +[1] Documentation/devicetree/bindings/reset/reset.txt + +Required properties: +- compatible: should be "snps,hsdk-v1.0-reset". +- reg: should always contain 2 pairs address - length: first for reset + configuration register and second for corresponding SW reset and status bits + register. +- #reset-cells: from common reset binding; Should always be set to 1. + +Example: + reset: reset@880 { + compatible = "snps,hsdk-v1.0-reset"; + #reset-cells = <1>; + reg = <0x8A0 0x4>, <0xFF0 0x4>; + }; + +Specifying reset lines connected to IP modules: + ethernet@.... { + .... + resets = <&reset HSDK_V1_ETH_RESET>; + .... + }; + +The index could be found in -- cgit v1.2.3 From 13541226dc056fa3f54417ce12f18ba711a1591c Mon Sep 17 00:00:00 2001 From: Vineet Gupta Date: Thu, 31 Aug 2017 11:06:07 -0700 Subject: ARC: reset: remove the misleading v1 suffix all over There is no plan yet to do a v2 board. And even if we were to do it only some IPs would actually change, so it be best to add suffixes at that point, not now ! Signed-off-by: Vineet Gupta Signed-off-by: Philipp Zabel --- .../devicetree/bindings/reset/snps,hsdk-reset.txt | 28 ++++++++++++++++++++++ .../bindings/reset/snps,hsdk-v1-reset.txt | 28 ---------------------- 2 files changed, 28 insertions(+), 28 deletions(-) create mode 100644 Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt delete mode 100644 Documentation/devicetree/bindings/reset/snps,hsdk-v1-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt b/Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt new file mode 100644 index 000000000000..830069b1c37c --- /dev/null +++ b/Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt @@ -0,0 +1,28 @@ +Binding for the Synopsys HSDK reset controller + +This binding uses the common reset binding[1]. + +[1] Documentation/devicetree/bindings/reset/reset.txt + +Required properties: +- compatible: should be "snps,hsdk-reset". +- reg: should always contain 2 pairs address - length: first for reset + configuration register and second for corresponding SW reset and status bits + register. +- #reset-cells: from common reset binding; Should always be set to 1. + +Example: + reset: reset@880 { + compatible = "snps,hsdk-reset"; + #reset-cells = <1>; + reg = <0x8A0 0x4>, <0xFF0 0x4>; + }; + +Specifying reset lines connected to IP modules: + ethernet@.... { + .... + resets = <&reset HSDK_V1_ETH_RESET>; + .... + }; + +The index could be found in diff --git a/Documentation/devicetree/bindings/reset/snps,hsdk-v1-reset.txt b/Documentation/devicetree/bindings/reset/snps,hsdk-v1-reset.txt deleted file mode 100644 index 6a68146ee353..000000000000 --- a/Documentation/devicetree/bindings/reset/snps,hsdk-v1-reset.txt +++ /dev/null @@ -1,28 +0,0 @@ -Binding for the HSDK v1 reset controller - -This binding uses the common reset binding[1]. - -[1] Documentation/devicetree/bindings/reset/reset.txt - -Required properties: -- compatible: should be "snps,hsdk-v1.0-reset". -- reg: should always contain 2 pairs address - length: first for reset - configuration register and second for corresponding SW reset and status bits - register. -- #reset-cells: from common reset binding; Should always be set to 1. - -Example: - reset: reset@880 { - compatible = "snps,hsdk-v1.0-reset"; - #reset-cells = <1>; - reg = <0x8A0 0x4>, <0xFF0 0x4>; - }; - -Specifying reset lines connected to IP modules: - ethernet@.... { - .... - resets = <&reset HSDK_V1_ETH_RESET>; - .... - }; - -The index could be found in -- cgit v1.2.3 From 432219fd002ada95d2f45dd3a25c3f7c73f27864 Mon Sep 17 00:00:00 2001 From: Sergei Shtylyov Date: Sat, 2 Sep 2017 01:15:13 +0300 Subject: serial: sh-sci: document R8A77970 bindings R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible SCIF and HSCIF ports, so document the SoC specific bindings. Signed-off-by: Sergei Shtylyov Acked-by: Rob Herring Acked-by: Geert Uytterhoeven Acked-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index 4fc96946f81d..cf504d0380ae 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -41,6 +41,8 @@ Required properties: - "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART. - "renesas,scif-r8a7796" for R8A7796 (R-Car M3-W) SCIF compatible UART. - "renesas,hscif-r8a7796" for R8A7796 (R-Car M3-W) HSCIF compatible UART. + - "renesas,scif-r8a77970" for R8A77970 (R-Car V3M) SCIF compatible UART. + - "renesas,hscif-r8a77970" for R8A77970 (R-Car V3M) HSCIF compatible UART. - "renesas,scif-r8a77995" for R8A77995 (R-Car D3) SCIF compatible UART. - "renesas,hscif-r8a77995" for R8A77995 (R-Car D3) HSCIF compatible UART. - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. -- cgit v1.2.3 From 376349232a93645624426db782cafe688054e6d6 Mon Sep 17 00:00:00 2001 From: Eugeniy Paltsev Date: Thu, 14 Sep 2017 17:28:42 +0300 Subject: ARC: reset: introduce AXS10x reset driver ARC AXS10x boards support custom IP-block which allows to control reset signals of selected peripherals. For example DW GMAC, etc... This block is controlled via memory-mapped register (AKA CREG) which represents up-to 32 reset lines. This regiter is self-clearing so we don't need to deassert line after reset. As of today only the following lines are used: - DW GMAC - line 5 Signed-off-by: Eugeniy Paltsev Signed-off-by: Philipp Zabel --- .../bindings/reset/snps,axs10x-reset.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt b/Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt new file mode 100644 index 000000000000..32d8435a41df --- /dev/null +++ b/Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt @@ -0,0 +1,33 @@ +Binding for the AXS10x reset controller + +This binding describes the ARC AXS10x boards custom IP-block which allows +to control reset signals of selected peripherals. For example DW GMAC, etc... +This block is controlled via memory-mapped register (AKA CREG) which +represents up-to 32 reset lines. + +As of today only the following lines are used: + - DW GMAC - line 5 + +This binding uses the common reset binding[1]. + +[1] Documentation/devicetree/bindings/reset/reset.txt + +Required properties: +- compatible: should be "snps,axs10x-reset". +- reg: should always contain pair address - length: for creg reset + bits register. +- #reset-cells: from common reset binding; Should always be set to 1. + +Example: + reset: reset-controller@11220 { + compatible = "snps,axs10x-reset"; + #reset-cells = <1>; + reg = <0x11220 0x4>; + }; + +Specifying reset lines connected to IP modules: + ethernet@.... { + .... + resets = <&reset 5>; + .... + }; -- cgit v1.2.3 From 785ec87483d1e24a012ecf642ee7d07c4118f142 Mon Sep 17 00:00:00 2001 From: Sergei Shtylyov Date: Tue, 12 Sep 2017 23:02:08 +0300 Subject: ravb: document R8A77970 bindings R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible EtherAVB device, so document the SoC specific bindings. Signed-off-by: Sergei Shtylyov Acked-by: Simon Horman Reviewed-by: Geert Uytterhoeven Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 16723535e1aa..2689211d324c 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -17,6 +17,7 @@ Required properties: - "renesas,etheravb-r8a7795" for the R8A7795 SoC. - "renesas,etheravb-r8a7796" for the R8A7796 SoC. + - "renesas,etheravb-r8a77970" for the R8A77970 SoC. - "renesas,etheravb-rcar-gen3" as a fallback for the above R-Car Gen3 devices. @@ -40,7 +41,7 @@ Optional properties: - interrupt-parent: the phandle for the interrupt controller that services interrupts for this device. - interrupt-names: A list of interrupt names. - For the R8A779[56] SoCs this property is mandatory; + For the R-Car Gen 3 SoCs this property is mandatory; it should include one entry per channel, named "ch%u", where %u is the channel number ranging from 0 to 24. For other SoCs this property is optional; if present -- cgit v1.2.3 From f231c4178a655b09c1fe4dce4b09de7b867c20af Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Thu, 14 Sep 2017 09:06:38 +0900 Subject: dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB Add a new compatible string for the R8A77995 (R-Car D3) RAVB. Signed-off-by: Yoshihiro Shimoda Acked-by: Geert Uytterhoeven Acked-by: Sergei Shtylyov Acked-by: Simon Horman Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 2689211d324c..c902261893b9 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -18,6 +18,7 @@ Required properties: - "renesas,etheravb-r8a7795" for the R8A7795 SoC. - "renesas,etheravb-r8a7796" for the R8A7796 SoC. - "renesas,etheravb-r8a77970" for the R8A77970 SoC. + - "renesas,etheravb-r8a77995" for the R8A77995 SoC. - "renesas,etheravb-rcar-gen3" as a fallback for the above R-Car Gen3 devices. -- cgit v1.2.3 From 367f15d3130e0d6c6818a4ace2463914e8c78e2c Mon Sep 17 00:00:00 2001 From: Markus Mayer Date: Thu, 24 Aug 2017 16:36:25 -0700 Subject: dt-bindings: Add bindings for Broadcom STB DRAM Sensors Provide bindings for the Broadcom STB DDR PHY Front End (DPFE). Signed-off-by: Markus Mayer Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- .../bindings/memory-controllers/brcm,dpfe-cpu.txt | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt new file mode 100644 index 000000000000..82d923ef413f --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt @@ -0,0 +1,27 @@ +DDR PHY Front End (DPFE) for Broadcom STB +========================================= + +DPFE and the DPFE firmware provide an interface for the host CPU to +communicate with the DCPU, which resides inside the DDR PHY. + +There are three memory regions for interacting with the DCPU. These are +specified in a single reg property. + +Required properties: + - compatible: must be "brcm,bcm7271-dpfe-cpu", "brcm,bcm7268-dpfe-cpu" + or "brcm,dpfe-cpu" + - reg: must reference three register ranges + - start address and length of the DCPU register space + - start address and length of the DCPU data memory space + - start address and length of the DCPU instruction memory space + - reg-names: must contain "dpfe-cpu", "dpfe-dmem", and "dpfe-imem"; + they must be in the same order as the register declarations + +Example: + dpfe_cpu0: dpfe-cpu@f1132000 { + compatible = "brcm,bcm7271-dpfe-cpu", "brcm,dpfe-cpu"; + reg = <0xf1132000 0x180 + 0xf1134000 0x1000 + 0xf1138000 0x4000>; + reg-names = "dpfe-cpu", "dpfe-dmem", "dpfe-imem"; + }; -- cgit v1.2.3 From 9600c2340ded841076367cc78fdd2b65e1cf8ed8 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 15 Jun 2017 13:39:51 -0700 Subject: dt-bindings: ARM: brcmstb: Update Broadcom STB Power Management binding Update the Broadcom STB Power Management binding document with new compatible strings for the DDR PHY and memory controller found on newer chips. Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt index 0d0c1ae81bed..790e6b0b8306 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt @@ -164,6 +164,8 @@ Control registers for this memory controller's DDR PHY. Required properties: - compatible : should contain one of these + "brcm,brcmstb-ddr-phy-v71.1" + "brcm,brcmstb-ddr-phy-v72.0" "brcm,brcmstb-ddr-phy-v225.1" "brcm,brcmstb-ddr-phy-v240.1" "brcm,brcmstb-ddr-phy-v240.2" @@ -184,7 +186,9 @@ Sequencer DRAM parameters and control registers. Used for Self-Refresh Power-Down (SRPD), among other things. Required properties: -- compatible : should contain "brcm,brcmstb-memc-ddr" +- compatible : should contain one of these + "brcm,brcmstb-memc-ddr-rev-b.2.2" + "brcm,brcmstb-memc-ddr" - reg : the MEMC DDR register range Example: -- cgit v1.2.3 From 0e1bfb72b076b07dc844bf33c19d62a3075f540f Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 30 Aug 2017 11:57:31 +0200 Subject: v4l: vsp1: Use generic node name Use the preferred generic node name in the example. Signed-off-by: Geert Uytterhoeven Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/media/renesas,vsp1.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt b/Documentation/devicetree/bindings/media/renesas,vsp1.txt index 9b695bcbf219..16427017cb45 100644 --- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt @@ -22,7 +22,7 @@ Optional properties: Example: R8A7790 (R-Car H2) VSP1-S node - vsp1@fe928000 { + vsp@fe928000 { compatible = "renesas,vsp1"; reg = <0 0xfe928000 0 0x8000>; interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>; -- cgit v1.2.3 From 716f1c8992ebbb321c5ad1ff6823a9e9074007e8 Mon Sep 17 00:00:00 2001 From: YuanCheng Cheng Date: Sat, 9 Sep 2017 19:40:58 +0800 Subject: dt-bindings: vendor-prefixes: Add nutsboard MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit NutsBoard (http://nutsboard.org/) is an organization and focus on ARM based embedded boards with open source software. Signed-off-by: YuanCheng Cheng Reviewed-by: Fabio Estevam Reviewed-by: Andreas Färber Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1ea1fd4232ab..f461616cf85f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -235,6 +235,7 @@ nintendo Nintendo nlt NLT Technologies, Ltd. nokia Nokia nordic Nordic Semiconductor +nutsboard NutsBoard nuvoton Nuvoton Technology Corporation nvd New Vision Display nvidia NVIDIA -- cgit v1.2.3 From 0bf4b3fadb5663959605d584410412dce53406cc Mon Sep 17 00:00:00 2001 From: Fabrizio Castro Date: Mon, 11 Sep 2017 09:30:23 +0100 Subject: of: add vendor prefix for Silicon Storage Technology Inc. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add Silicon Storage Technology Inc. to the list of devicetree vendor prefixes. Signed-off-by: Fabrizio Castro Reviewed-by: Andreas Färber Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index f461616cf85f..c6ef403e6321 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -318,6 +318,7 @@ 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 -- cgit v1.2.3 From 51513748ddfe7a5d2812158a1e0570499b0c511c Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 16 Sep 2017 13:10:06 -0700 Subject: Documentation: networking: fix ASCII art in switchdev.txt Fix ASCII art in Documentation/networking/switchdev.txt: Change non-ASCII "spaces" to ASCII spaces. Change 2 erroneous '+' characters in ASCII art to '-' (at the '*' characters below): line 32: +--+----+----+----+-*--+----+---+ +-----+-----+ line 41: +--------------+---*------------+ Signed-off-by: Randy Dunlap Acked-by: Pavel Machek Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- Documentation/networking/switchdev.txt | 68 +++++++++++++++++----------------- 1 file changed, 34 insertions(+), 34 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt index 5e40e1f68873..82236a17b5e6 100644 --- a/Documentation/networking/switchdev.txt +++ b/Documentation/networking/switchdev.txt @@ -13,42 +13,42 @@ an example setup using a data-center-class switch ASIC chip. Other setups with SR-IOV or soft switches, such as OVS, are possible. -                             User-space tools - -       user space                   | -      +-------------------------------------------------------------------+ -       kernel                       | Netlink -                                    | -                     +--------------+-------------------------------+ -                     |         Network stack                        | -                     |           (Linux)                            | -                     |                                              | -                     +----------------------------------------------+ + User-space tools + + user space | + +-------------------------------------------------------------------+ + kernel | Netlink + | + +--------------+-------------------------------+ + | Network stack | + | (Linux) | + | | + +----------------------------------------------+ sw1p2 sw1p4 sw1p6 -                      sw1p1  + sw1p3 +  sw1p5 +         eth1 -                        +    |    +    |    +    |            + -                        |    |    |    |    |    |            | -                     +--+----+----+----+-+--+----+---+  +-----+-----+ -                     |         Switch driver         |  |    mgmt   | -                     |        (this document)        |  |   driver  | -                     |                               |  |           | -                     +--------------+----------------+  +-----------+ -                                    | -       kernel                       | HW bus (eg PCI) -      +-------------------------------------------------------------------+ -       hardware                     | -                     +--------------+---+------------+ -                     |         Switch device (sw1)   | -                     |  +----+                       +--------+ -                     |  |    v offloaded data path   | mgmt port -                     |  |    |                       | -                     +--|----|----+----+----+----+---+ -                        |    |    |    |    |    | -                        +    +    +    +    +    + -                       p1   p2   p3   p4   p5   p6 - -                             front-panel ports + sw1p1 + sw1p3 + sw1p5 + eth1 + + | + | + | + + | | | | | | | + +--+----+----+----+----+----+---+ +-----+-----+ + | Switch driver | | mgmt | + | (this document) | | driver | + | | | | + +--------------+----------------+ +-----------+ + | + kernel | HW bus (eg PCI) + +-------------------------------------------------------------------+ + hardware | + +--------------+----------------+ + | Switch device (sw1) | + | +----+ +--------+ + | | v offloaded data path | mgmt port + | | | | + +--|----|----+----+----+----+---+ + | | | | | | + + + + + + + + p1 p2 p3 p4 p5 p6 + + front-panel ports Fig 1. -- cgit v1.2.3 From 47684e111f52fface17820d3ef84cc845b26070e Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 18 Sep 2017 13:10:15 -0700 Subject: Documentation: core-api: minor workqueue.rst cleanups Clean up workqueue.rst: - fix minor typos - put '@' after `` instead of preceding them (one place) - use "CPU" instead of "cpu" in text consistently - quote one function name Signed-off-by: Randy Dunlap Cc: Tejun Heo Cc: Florian Mickler Signed-off-by: Tejun Heo --- Documentation/core-api/workqueue.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst index 3943b5bfa8cf..00a5ba51e63f 100644 --- a/Documentation/core-api/workqueue.rst +++ b/Documentation/core-api/workqueue.rst @@ -39,8 +39,8 @@ up. Although MT wq wasted a lot of resource, the level of concurrency provided was unsatisfactory. The limitation was common to both ST and MT wq albeit less severe on MT. Each wq maintained its own separate -worker pool. A MT wq could provide only one execution context per CPU -while a ST wq one for the whole system. Work items had to compete for +worker pool. An MT wq could provide only one execution context per CPU +while an ST wq one for the whole system. Work items had to compete for those very limited execution contexts leading to various problems including proneness to deadlocks around the single execution context. @@ -151,7 +151,7 @@ Application Programming Interface (API) ``alloc_workqueue()`` allocates a wq. The original ``create_*workqueue()`` functions are deprecated and scheduled for -removal. ``alloc_workqueue()`` takes three arguments - @``name``, +removal. ``alloc_workqueue()`` takes three arguments - ``@name``, ``@flags`` and ``@max_active``. ``@name`` is the name of the wq and also used as the name of the rescuer thread if there is one. @@ -197,7 +197,7 @@ resources, scheduled and executed. served by worker threads with elevated nice level. Note that normal and highpri worker-pools don't interact with - each other. Each maintain its separate pool of workers and + each other. Each maintains its separate pool of workers and implements concurrency management among its workers. ``WQ_CPU_INTENSIVE`` @@ -249,8 +249,8 @@ unbound worker-pools and only one work item could be active at any given time thus achieving the same ordering property as ST wq. In the current implementation the above configuration only guarantees -ST behavior within a given NUMA node. Instead alloc_ordered_queue should -be used to achieve system wide ST behavior. +ST behavior within a given NUMA node. Instead ``alloc_ordered_queue()`` should +be used to achieve system-wide ST behavior. Example Execution Scenarios -- cgit v1.2.3 From 850fdec8d2fd1eebfa003fea39bec08cd69b6155 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 18 Sep 2017 12:17:57 +0200 Subject: driver core: remove DRIVER_ATTR DRIVER_ATTR is no longer in use, and driver authors should be using DRIVER_ATTR_RW() or DRIVER_ATTR_RO() or DRIVER_ATTR_WO() instead in order to always get the permissions correct. So remove it so that no one can use it anymore. Acked-by: Alan Tull Reviewed-by: Moritz Fischer Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-model/driver.txt | 7 ++++--- Documentation/filesystems/sysfs.txt | 3 ++- 2 files changed, 6 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt index 4421135826a2..d661e6f7e6a0 100644 --- a/Documentation/driver-model/driver.txt +++ b/Documentation/driver-model/driver.txt @@ -196,12 +196,13 @@ struct driver_attribute { }; Device drivers can export attributes via their sysfs directories. -Drivers can declare attributes using a DRIVER_ATTR macro that works -identically to the DEVICE_ATTR macro. +Drivers can declare attributes using a DRIVER_ATTR_RW and DRIVER_ATTR_RO +macro that works identically to the DEVICE_ATTR_RW and DEVICE_ATTR_RO +macros. Example: -DRIVER_ATTR(debug,0644,show_debug,store_debug); +DRIVER_ATTR_RW(debug); This is equivalent to declaring: diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 24da7b32c489..9a3658cc399e 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt @@ -366,7 +366,8 @@ struct driver_attribute { Declaring: -DRIVER_ATTR(_name, _mode, _show, _store) +DRIVER_ATTR_RO(_name) +DRIVER_ATTR_RW(_name) Creation/Removal: -- cgit v1.2.3 From a621c99a96e64e3d6d5d47745a5e832262ac8f7c Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 12 Sep 2017 09:32:34 +0200 Subject: gpio: Clarify consumer stubs use-cases After discussion we add a few blurbs to clarify how the stubs in the consumer API are supposed to be used. Cc: Florian Fainelli Cc: Sergei Shtylyov Cc: Andrew Lunn Signed-off-by: Linus Walleij --- Documentation/gpio/consumer.txt | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt index 912568baabb9..ddbfa775a78a 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/gpio/consumer.txt @@ -10,14 +10,30 @@ Guidelines for GPIOs consumers ============================== Drivers that can't work without standard GPIO calls should have Kconfig entries -that depend on GPIOLIB. The functions that allow a driver to obtain and use -GPIOs are available by including the following file: +that depend on GPIOLIB or select GPIOLIB. The functions that allow a driver to +obtain and use GPIOs are available by including the following file: #include +There are static inline stubs for all functions in the header file in the case +where GPIOLIB is disabled. When these stubs are called they will emit +warnings. These stubs are used for two use cases: + +- Simple compile coverage with e.g. COMPILE_TEST - it does not matter that + the current platform does not enable or select GPIOLIB because we are not + going to execute the system anyway. + +- Truly optional GPIOLIB support - where the driver does not really make use + of the GPIOs on certain compile-time configurations for certain systems, but + will use it under other compile-time configurations. In this case the + consumer must make sure not to call into these functions, or the user will + be met with console warnings that may be perceived as intimidating. + All the functions that work with the descriptor-based GPIO interface are prefixed with gpiod_. The gpio_ prefix is used for the legacy interface. No -other function in the kernel should use these prefixes. +other function in the kernel should use these prefixes. The use of the legacy +functions is strongly discouraged, new code should use +and descriptors exclusively. Obtaining and Disposing GPIOs -- cgit v1.2.3 From 8d46e28fb5081b49c5b24c814ad464fb99359d58 Mon Sep 17 00:00:00 2001 From: Sergei Shtylyov Date: Sat, 9 Sep 2017 00:34:20 +0300 Subject: clk: renesas: cpg-mssr: Add R8A77970 support Add R-Car V3M (R8A77970) Clock Pulse Generator / Module Standby and Software Reset support, using the CPG/MSSR driver core and the common R-Car Gen3 code. Based on the original (and large) patch by Daisuke Matsushita . Signed-off-by: Vladimir Barinov Signed-off-by: Sergei Shtylyov Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt index 316e13686568..f1890d0777a6 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt @@ -22,6 +22,7 @@ Required Properties: - "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2) - "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3) - "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W) + - "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M) - "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3) - reg: Base address and length of the memory resource used by the CPG/MSSR @@ -31,8 +32,8 @@ Required Properties: clock-names - clock-names: List of external parent clock names. Valid names are: - "extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794, - r8a7795, r8a7796, r8a77995) - - "extalr" (r8a7795, r8a7796) + r8a7795, r8a7796, r8a77970, r8a77995) + - "extalr" (r8a7795, r8a7796, r8a77970) - "usb_extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7793, r8a7794) - #clock-cells: Must be 2 -- cgit v1.2.3 From 2f329595b8db42ceb3de93595a740ac7b24eddba Mon Sep 17 00:00:00 2001 From: Baolin Wang Date: Fri, 15 Sep 2017 15:29:15 +0800 Subject: spi: Add Spreadtrum ADI controller documentation This patch adds the binding documentation for Spreadtrum ADI controller device. Signed-off-by: Baolin Wang Signed-off-by: Mark Brown --- .../devicetree/bindings/spi/spi-sprd-adi.txt | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-sprd-adi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt new file mode 100644 index 000000000000..8de589b376ce --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt @@ -0,0 +1,58 @@ +Spreadtrum ADI controller + +ADI is the abbreviation of Anolog-Digital interface, which is used to access +analog chip (such as PMIC) from digital chip. ADI controller follows the SPI +framework for its hardware implementation is alike to SPI bus and its timing +is compatile to SPI timing. + +ADI controller has 50 channels including 2 software read/write channels and +48 hardware channels to access analog chip. For 2 software read/write channels, +users should set ADI registers to access analog chip. For hardware channels, +we can configure them to allow other hardware components to use it independently, +which means we can just link one analog chip address to one hardware channel, +then users can access the mapped analog chip address by this hardware channel +triggered by hardware components instead of ADI software channels. + +Thus we introduce one property named "sprd,hw-channels" to configure hardware +channels, the first value specifies the hardware channel id which is used to +transfer data triggered by hardware automatically, and the second value specifies +the analog chip address where user want to access by hardware components. + +Since we have multi-subsystems will use unique ADI to access analog chip, when +one system is reading/writing data by ADI software channels, that should be under +one hardware spinlock protection to prevent other systems from reading/writing +data by ADI software channels at the same time, or two parallel routine of setting +ADI registers will make ADI controller registers chaos to lead incorrect results. +Then we need one hardware spinlock to synchronize between the multiple subsystems. + +Required properties: +- compatible: Should be "sprd,sc9860-adi". +- reg: Offset and length of ADI-SPI controller register space. +- hwlocks: Reference to a phandle of a hwlock provider node. +- hwlock-names: Reference to hwlock name strings defined in the same order + as the hwlocks, should be "adi". +- #address-cells: Number of cells required to define a chip select address + on the ADI-SPI bus. Should be set to 1. +- #size-cells: Size of cells required to define a chip select address size + on the ADI-SPI bus. Should be set to 0. + +Optional properties: +- sprd,hw-channels: This is an array of channel values up to 49 channels. + The first value specifies the hardware channel id which is used to + transfer data triggered by hardware automatically, and the second + value specifies the analog chip address where user want to access + by hardware components. + +SPI slave nodes must be children of the SPI controller node and can contain +properties described in Documentation/devicetree/bindings/spi/spi-bus.txt. + +Example: + adi_bus: spi@40030000 { + compatible = "sprd,sc9860-adi"; + reg = <0 0x40030000 0 0x10000>; + hwlocks = <&hwlock1 0>; + hwlock-names = "adi"; + #address-cells = <1>; + #size-cells = <0>; + sprd,hw-channels = <30 0x8c20>; + }; -- cgit v1.2.3 From 457c25efc592bb5539e18161c505f7a865013fb7 Mon Sep 17 00:00:00 2001 From: Oder Chiou Date: Mon, 18 Sep 2017 18:14:26 +0800 Subject: ASoC: rt5663: Add the function of impedance sensing Support the function of impedance sensing. It could be set the matrix row number of the impedance sensing table and the related parameters in the DTS. Signed-off-by: Oder Chiou Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/rt5663.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt b/Documentation/devicetree/bindings/sound/rt5663.txt index ff381718c517..497bcfc58b71 100644 --- a/Documentation/devicetree/bindings/sound/rt5663.txt +++ b/Documentation/devicetree/bindings/sound/rt5663.txt @@ -19,6 +19,22 @@ Optional properties: Based on the different PCB layout, add the manual offset value to compensate the DC offset for each L and R channel, and they are different between headphone and headset. +- "realtek,impedance_sensing_num" + The matrix row number of the impedance sensing table. + If the value is 0, it means the impedance sensing is not supported. +- "realtek,impedance_sensing_table" + The matrix rows of the impedance sensing table are consisted by impedance + minimum, impedance maximun, volume, DC offset w/o and w/ mic of each L and + R channel accordingly. Example is shown as following. + < 0 300 7 0xffd160 0xffd1c0 0xff8a10 0xff8ab0 + 301 65535 4 0xffe470 0xffe470 0xffb8e0 0xffb8e0> + The first and second column are defined for the impedance range. If the + detected impedance value is in the range, then the volume value of the + third column will be set to codec. In our codec design, each volume value + should compensate different DC offset to avoid the pop sound, and it is + also different between headphone and headset. In the example, the + "realtek,impedance_sensing_num" is 2. It means that there are 2 ranges of + impedance in the impedance sensing function. Pins on the device (for linking into audio routes) for RT5663: -- cgit v1.2.3 From d6604145dfccc3dd9e882dd3d6bd2545c9ff64e9 Mon Sep 17 00:00:00 2001 From: Jeffy Chen Date: Mon, 18 Sep 2017 19:14:34 +0800 Subject: ASoC: rt5514: Add devicetree binding support for rt5514-spi Add devicetree binding support for rt5514 spi dsp codec. Signed-off-by: Jeffy Chen Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/rt5514.txt | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/rt5514.txt b/Documentation/devicetree/bindings/sound/rt5514.txt index 929ca6756b02..4f33b0d96afe 100644 --- a/Documentation/devicetree/bindings/sound/rt5514.txt +++ b/Documentation/devicetree/bindings/sound/rt5514.txt @@ -1,22 +1,27 @@ RT5514 audio CODEC -This device supports I2C only. +This device supports both I2C and SPI. Required properties: - compatible : "realtek,rt5514". -- reg : The I2C address of the device. +- reg : the I2C address of the device for I2C, the chip select + number for SPI. Optional properties: - clocks: The phandle of the master clock to the CODEC - clock-names: Should be "mclk" +- interrupt-parent: The phandle for the interrupt controller. +- interrupts: The interrupt number to the cpu. The interrupt specifier format + depends on the interrupt controller. + - realtek,dmic-init-delay-ms - Set the DMIC initial delay (ms) to wait it ready. + Set the DMIC initial delay (ms) to wait it ready for I2C. -Pins on the device (for linking into audio routes) for RT5514: +Pins on the device (for linking into audio routes) for I2C: * DMIC1L * DMIC1R -- cgit v1.2.3 From 32c30f73687a7ea5fe6add62b7bc3b520115d0d9 Mon Sep 17 00:00:00 2001 From: Franklin Cooper Date: Fri, 8 Sep 2017 15:46:36 -0500 Subject: spi: spi-davinci: Update binding for 66AK2Gx pwr dm property Add pm-domains property which is required for 66AK2Gx. Also document 66AK2G unique clocks property usage. Signed-off-by: Franklin S Cooper Jr Acked-by: Rob Herring Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-davinci.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt index f5916c92fe91..1925277bfc1e 100644 --- a/Documentation/devicetree/bindings/spi/spi-davinci.txt +++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt @@ -24,6 +24,16 @@ Required properties: based on a specific SoC configuration. - interrupts: interrupt number mapped to CPU. - clocks: spi clk phandle + For 66AK2G this property should be set per binding, + Documentation/devicetree/bindings/clock/ti,sci-clk.txt + +SoC-specific Required Properties: + +The following are mandatory properties for Keystone 2 66AK2G SoCs only: + +- power-domains: Should contain a phandle to a PM domain provider node + and an args specifier containing the SPI device id + value. This property is as per the binding, Optional: - cs-gpios: gpio chip selects -- cgit v1.2.3 From 10c1705eced11d6ad710fddcdb57aaa9f85a6f98 Mon Sep 17 00:00:00 2001 From: Fabrizio Castro Date: Fri, 8 Sep 2017 09:07:15 +0100 Subject: spi: rspi: Add r8a7743/5 to the compatible list Signed-off-by: Fabrizio Castro Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-rspi.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt index 8f4169f63936..3b02b3a7cfb2 100644 --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt @@ -5,11 +5,14 @@ Required properties: "renesas,rspi-", "renesas,rspi" as fallback. For Renesas Serial Peripheral Interface on RZ/A1H: "renesas,rspi-", "renesas,rspi-rz" as fallback. - For Quad Serial Peripheral Interface on R-Car Gen2: + For Quad Serial Peripheral Interface on R-Car Gen2 and + RZ/G1 devices: "renesas,qspi-", "renesas,qspi" as fallback. Examples with soctypes are: - "renesas,rspi-sh7757" (SH) - "renesas,rspi-r7s72100" (RZ/A1H) + - "renesas,qspi-r8a7743" (RZ/G1M) + - "renesas,qspi-r8a7745" (RZ/G1E) - "renesas,qspi-r8a7790" (R-Car H2) - "renesas,qspi-r8a7791" (R-Car M2-W) - "renesas,qspi-r8a7792" (R-Car V2H) -- cgit v1.2.3 From c737abc193d16e62e23e2fb585b8b7398ab380d8 Mon Sep 17 00:00:00 2001 From: allen yan Date: Thu, 7 Sep 2017 15:04:53 +0200 Subject: arm64: dts: marvell: Fix A37xx UART0 register size Armada-37xx UART0 registers are 0x200 bytes wide. Right next to them are the UART1 registers that should not be declared in this node. Update the example in DT bindings document accordingly. Signed-off-by: allen yan Signed-off-by: Miquel Raynal Signed-off-by: Gregory CLEMENT --- Documentation/devicetree/bindings/serial/mvebu-uart.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/serial/mvebu-uart.txt index 6087defd9f93..d37fabe17bd1 100644 --- a/Documentation/devicetree/bindings/serial/mvebu-uart.txt +++ b/Documentation/devicetree/bindings/serial/mvebu-uart.txt @@ -8,6 +8,6 @@ Required properties: Example: serial@12000 { compatible = "marvell,armada-3700-uart"; - reg = <0x12000 0x400>; + reg = <0x12000 0x200>; interrupts = <43>; }; -- cgit v1.2.3 From 53fd40a90f3c0bdad86ec266ee5df833f54ace39 Mon Sep 17 00:00:00 2001 From: Jani Nikula Date: Tue, 12 Sep 2017 11:19:26 +0300 Subject: drm: handle override and firmware EDID at drm_do_get_edid() level MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Handle debugfs override edid and firmware edid at the low level to transparently and completely replace the real edid. Previously, we practically only used the modes from the override EDID, and none of the other data, such as audio parameters. This change also prevents actual EDID reads when the EDID is to be overridden, but retains the DDC probe. This is useful if the reason for preferring override EDID are problems with reading the data, or corruption of the data. Move firmware EDID loading from helper to core, as the functionality moves to lower level as well. This will result in a change of module parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which arguably makes more sense anyway. Some future work remains related to override and firmware EDID validation. Like before, no validation is done for override EDID. The firmware EDID is validated separately in the loader. Some unification and deduplication would be in order, to validate all of them at the drm_do_get_edid() level, like "real" EDIDs. v2: move firmware loading to core v3: rebase, commit message refresh Cc: Abdiel Janulgue Cc: Daniel Vetter Cc: Ville Syrjälä Tested-by: Abdiel Janulgue Reviewed-by: Ville Syrjälä Acked-by: Dave Airlie Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/1e8a710bcac46e5136c1a7b430074893c81f364a.1505203831.git.jani.nikula@intel.com --- Documentation/admin-guide/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index d9c171ce4190..9b393c29953f 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -854,7 +854,7 @@ The filter can be disabled or changed to another driver later using sysfs. - drm_kms_helper.edid_firmware=[:][,[:]] + drm.edid_firmware=[:][,[:]] Broken monitors, graphic adapters, KVMs and EDIDless panels may send no or incorrect EDID data sets. This parameter allows to specify an EDID data sets -- cgit v1.2.3 From 9fda3b428a74339e358d4b0850427fa1ce1b4714 Mon Sep 17 00:00:00 2001 From: Charles Keepax Date: Mon, 4 Sep 2017 16:41:50 +0100 Subject: ASoC: arizona: Add audio device tree bindings In keeping with the style of the rest of this drivers device tree bindings split the audio device tree bindings into their own document. It should be noted this patch makes no change to the binding itself just moves the documentation into a specific file for the audio binding. For easy of merging a separate patch removes the current documentation from the MFD binding documentation. Signed-off-by: Charles Keepax Acked-by: Rob Herring Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/wlf,arizona.txt | 49 ++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/wlf,arizona.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/wlf,arizona.txt b/Documentation/devicetree/bindings/sound/wlf,arizona.txt new file mode 100644 index 000000000000..4e67224488d8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,arizona.txt @@ -0,0 +1,49 @@ +Cirrus Logic Arizona class audio SoCs + +These devices are audio SoCs with extensive digital capabilities and a range +of analogue I/O. + +This document lists sound specific bindings, see the primary binding +document: + ../mfd/arizona.txt + +Optional properties: + + - wlf,inmode : A list of INn_MODE register values, where n is the number + of input signals. Valid values are 0 (Differential), 1 (Single-ended) and + 2 (Digital Microphone). If absent, INn_MODE registers set to 0 by default. + If present, values must be specified less than or equal to the number of + input signals. If values less than the number of input signals, elements + that have not been specified are set to 0 by default. Entries are: + (wm5102, wm5110, wm8280, wm8997) + (wm8998, wm1814) + - wlf,out-mono : A list of boolean values indicating whether each output is + mono or stereo. Position within the list indicates the output affected + (eg. First entry in the list corresponds to output 1). A non-zero value + indicates a mono output. If present, the number of values should be less + than or equal to the number of outputs, if less values are supplied the + additional outputs will be treated as stereo. + + - wlf,dmic-ref : DMIC reference voltage source for each input, can be + selected from either MICVDD or one of the MICBIAS's, defines + (ARIZONA_DMIC_xxxx) are provided in . If + present, the number of values should be less than or equal to the + number of inputs, unspecified inputs will use the chip default. + + - wlf,max-channels-clocked : The maximum number of channels to be clocked on + each AIF, useful for I2S systems with multiple data lines being mastered. + Specify one cell for each AIF to be configured, specify zero for AIFs that + should be handled normally. + If present, number of cells must be less than or equal to the number of + AIFs. If less than the number of AIFs, for cells that have not been + specified the corresponding AIFs will be treated as default setting. + + - wlf,spk-fmt : PDM speaker data format, must contain 2 cells (OUT5 and OUT6). + See the datasheet for values. + The second cell is ignored for codecs that do not have OUT6 (wm5102, wm8997, + wm8998, wm1814) + + - wlf,spk-mute : PDM speaker mute setting, must contain 2 cells (OUT5 and OUT6). + See the datasheet for values. + The second cell is ignored for codecs that do not have OUT6 (wm5102, wm8997, + wm8998, wm1814) -- cgit v1.2.3 From a6899e900509bb2442239d6198dc8bc64f8437ec Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Thu, 14 Sep 2017 23:39:38 +0200 Subject: dt-bindings: fix vendor prefix for Abracon Commit 446810f2dd41 ("of: add vendor prefix for Abracon Corporation") claimed that "abcn" was used as the vendor prefix while in fact "abracon" was used in the subsequent commits. It is also the only prefix used in the tree. Signed-off-by: Alexandre Belloni [robh: fix alphabetical order] Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1ea1fd4232ab..1afd298eddd7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -3,8 +3,8 @@ 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. -abcn Abracon Corporation abilis Abilis Systems +abracon Abracon Corporation actions Actions Semiconductor Co., Ltd. active-semi Active-Semi International Inc ad Avionic Design GmbH -- cgit v1.2.3 From 0c37c56d63f4924134edd7e3af805291add56fac Mon Sep 17 00:00:00 2001 From: Vladimir Barinov Date: Thu, 14 Sep 2017 17:18:30 +0300 Subject: dt: Add vendor prefix 'shimafuji' Add Shimafuji Electric, Inc. to the list of device tree vendor prefixes Signed-off-by: Vladimir Barinov Acked-by: Geert Uytterhoeven Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index c6ef403e6321..9d46f99cc144 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -297,6 +297,7 @@ sensirion Sensirion AG sff Small Form Factor Committee sgx SGX Sensortech sharp Sharp Corporation +shimafuji Shimafuji Electric, Inc. si-en Si-En Technology Ltd. sigma Sigma Designs, Inc. sii Seiko Instruments, Inc. -- cgit v1.2.3 From b247c211ee367cfe975dd54e381094083adfd8d3 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 19 Sep 2017 02:43:13 +0200 Subject: PM: docs: Drop an excess character from devices.rst Drop an excess "`" from Documentation/driver-api/pm/devices.rst. Fixes: 2728b2d2e5be (PM / core / docs: Convert sleep states API document to reST) Signed-off-by: Rafael J. Wysocki --- Documentation/driver-api/pm/devices.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index bedd32388dac..a0dc2879a152 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -675,7 +675,7 @@ sub-domain of the parent domain. Support for power domains is provided through the :c:member:`pm_domain` field of |struct device|. This field is a pointer to an object of type -|struct dev_pm_domain|, defined in :file:`include/linux/pm.h``, providing a set +|struct dev_pm_domain|, defined in :file:`include/linux/pm.h`, providing a set of power management callbacks analogous to the subsystem-level and device driver callbacks that are executed for the given device during all power transitions, instead of the respective subsystem-level callbacks. Specifically, if a -- cgit v1.2.3 From 35e015e1f5773417952fe91ce8790baf9b4237a2 Mon Sep 17 00:00:00 2001 From: Matteo Croce Date: Tue, 12 Sep 2017 17:46:37 +0200 Subject: ipv6: fix net.ipv6.conf.all interface DAD handlers Currently, writing into net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect. Fix handling of these flags by: - using the maximum of global and per-interface values for the accept_dad flag. That is, if at least one of the two values is non-zero, enable DAD on the interface. If at least one value is set to 2, enable DAD and disable IPv6 operation on the interface if MAC-based link-local address was found - using the logical OR of global and per-interface values for the optimistic_dad flag. If at least one of them is set to one, optimistic duplicate address detection (RFC 4429) is enabled on the interface - using the logical OR of global and per-interface values for the use_optimistic flag. If at least one of them is set to one, optimistic addresses won't be marked as deprecated during source address selection on the interface. While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(), drop inline, and let the compiler decide. Fixes: 7fd2561e4ebd ("net: ipv6: Add a sysctl to make optimistic addresses useful candidates") Signed-off-by: Matteo Croce Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index b3345d0fe0a6..77f4de59dc9c 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -1680,6 +1680,9 @@ accept_dad - INTEGER 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found. + DAD operation and mode on a given interface will be selected according + to the maximum value of conf/{all,interface}/accept_dad. + force_tllao - BOOLEAN Enable sending the target link-layer address option even when responding to a unicast neighbor solicitation. @@ -1727,16 +1730,23 @@ suppress_frag_ndisc - INTEGER optimistic_dad - BOOLEAN Whether to perform Optimistic Duplicate Address Detection (RFC 4429). - 0: disabled (default) - 1: enabled + 0: disabled (default) + 1: enabled + + Optimistic Duplicate Address Detection for the interface will be enabled + if at least one of conf/{all,interface}/optimistic_dad is set to 1, + it will be disabled otherwise. use_optimistic - BOOLEAN If enabled, do not classify optimistic addresses as deprecated during source address selection. Preferred addresses will still be chosen before optimistic addresses, subject to other ranking in the source address selection algorithm. - 0: disabled (default) - 1: enabled + 0: disabled (default) + 1: enabled + + This will be enabled if at least one of + conf/{all,interface}/use_optimistic is set to 1, disabled otherwise. stable_secret - IPv6 address This IPv6 address will be used as a secret to generate IPv6 -- cgit v1.2.3 From 4633f7a156bf41003b1527f88ddf843ce0bb7d68 Mon Sep 17 00:00:00 2001 From: Leonard Crestez Date: Fri, 14 Jul 2017 17:11:06 +0300 Subject: thermal: imx: Add nvmem-cells alternate binding for OCOTP access On newer imx SOCs accessing OCOTP directly is wrong because the ocotp clock needs to be enabled first. Add a binding for accessing the same values through the imx-ocotp nvmem driver using nvmem-cells. This is similar to other thermal drivers. The old binding is preserved for compatibility and because it still works fine on imx6qdl series chips. In theory this problem could be solved by adding a reference to the OCOTP clock instead but it is better to hide such details in a specific nvmem driver. Signed-off-by: Leonard Crestez Acked-by: Rob Herring Signed-off-by: Zhang Rui --- Documentation/devicetree/bindings/thermal/imx-thermal.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.txt b/Documentation/devicetree/bindings/thermal/imx-thermal.txt index 3c67bd50aa10..28be51afdb6a 100644 --- a/Documentation/devicetree/bindings/thermal/imx-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.txt @@ -7,10 +7,17 @@ Required properties: is higher than panic threshold, system will auto reboot by SRC module. - fsl,tempmon : phandle pointer to system controller that contains TEMPMON control registers, e.g. ANATOP on imx6q. +- nvmem-cells: A phandle to the calibration cells provided by ocotp. +- nvmem-cell-names: Should be "calib", "temp_grade". + +Deprecated properties: - fsl,tempmon-data : phandle pointer to fuse controller that contains TEMPMON calibration data, e.g. OCOTP on imx6q. The details about calibration data can be found in SoC Reference Manual. +Direct access to OCOTP via fsl,tempmon-data is incorrect on some newer chips +because it does not handle OCOTP clock requirements. + Optional properties: - clocks : thermal sensor's clock source. -- cgit v1.2.3 From 3d345b5f7b2f613b6965fc3fc68de9f439752ffe Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Tue, 19 Sep 2017 19:59:04 -0300 Subject: ASoC: tfa9879: Add device tree bindings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Even though the tfa9879 driver can probe via device tree trough the I2C core code, it is preferable to have explicit device tree bindings instead [1], so add this support. [1] https://www.spinics.net/lists/devicetree/msg195176.html Signed-off-by: Fabio Estevam Reviewed-by: Łukasz Majewski Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/tfa9879.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tfa9879.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/tfa9879.txt b/Documentation/devicetree/bindings/sound/tfa9879.txt new file mode 100644 index 000000000000..23ba522d9e2b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tfa9879.txt @@ -0,0 +1,23 @@ +NXP TFA9879 class-D audio amplifier + +Required properties: + +- compatible : "nxp,tfa9879" + +- reg : the I2C address of the device + +Example: + +&i2c1 { + clock-frequency = <100000>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c1>; + status = "okay"; + + codec: tfa9879@6c { + #sound-dai-cells = <0>; + compatible = "nxp,tfa9879"; + reg = <0x6c>; + }; +}; + -- cgit v1.2.3 From f9705438b0f7da5dd04e270a95536b36b3dca54a Mon Sep 17 00:00:00 2001 From: Martyn Welch Date: Fri, 18 Aug 2017 16:53:47 +0100 Subject: dt-bindings: misc: achc: Add device tree binding for GE ACHC Add Device Tree binding document for GE Healthcare USB Management Controller (ACHC). Signed-off-by: Martyn Welch Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/misc/ge-achc.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/ge-achc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/ge-achc.txt b/Documentation/devicetree/bindings/misc/ge-achc.txt new file mode 100644 index 000000000000..77df94d7a32f --- /dev/null +++ b/Documentation/devicetree/bindings/misc/ge-achc.txt @@ -0,0 +1,26 @@ +* GE Healthcare USB Management Controller + +A device which handles data aquisition from compatible USB based peripherals. +SPI is used for device management. + +Note: This device does not expose the peripherals as USB devices. + +Required properties: + +- compatible : Should be "ge,achc" + +Required SPI properties: + +- reg : Should be address of the device chip select within + the controller. + +- spi-max-frequency : Maximum SPI clocking speed of device in Hz, should be + 1MHz for the GE ACHC. + +Example: + +spidev0: spi@0 { + compatible = "ge,achc"; + reg = <0>; + spi-max-frequency = <1000000>; +}; -- cgit v1.2.3 From ce6a90027c10f970f872de5db0294f9e3e969f1c Mon Sep 17 00:00:00 2001 From: Mario Limonciello Date: Fri, 8 Sep 2017 10:23:11 -0500 Subject: platform/x86: Add driver to force WMI Thunderbolt controller power status Current implementations of Intel Thunderbolt controllers will go into a low power mode when not in use. Many machines containing these controllers also have a GPIO wired up that can force the controller awake. This is offered via a ACPI-WMI interface intended to be manipulated by a userspace utility. This mechanism is provided by Intel to OEMs to include in BIOS. It uses an industry wide GUID that is populated in a separate _WDG entry with no binary MOF. This interface allows software such as fwupd to wake up thunderbolt controllers to query the firmware version or flash new firmware. Signed-off-by: Mario Limonciello Reviewed-by: Mika Westerberg Reviewed-by: Yehezkel Bernat Signed-off-by: Darren Hart (VMware) [andy fixed merge conflicts and bump kernel version for ABI] Signed-off-by: Andy Shevchenko --- .../ABI/testing/sysfs-platform-intel-wmi-thunderbolt | 11 +++++++++++ Documentation/admin-guide/thunderbolt.rst | 15 +++++++++++++++ 2 files changed, 26 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt b/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt new file mode 100644 index 000000000000..8af65059d519 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt @@ -0,0 +1,11 @@ +What: /sys/devices/platform//force_power +Date: September 2017 +KernelVersion: 4.15 +Contact: "Mario Limonciello" +Description: + Modify the platform force power state, influencing + Thunderbolt controllers to turn on or off when no + devices are connected (write-only) + There are two available states: + * 0 -> Force power disabled + * 1 -> Force power enabled diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst index 6a4cd1f159ca..dadcd66ee12f 100644 --- a/Documentation/admin-guide/thunderbolt.rst +++ b/Documentation/admin-guide/thunderbolt.rst @@ -197,3 +197,18 @@ information is missing. To recover from this mode, one needs to flash a valid NVM image to the host host controller in the same way it is done in the previous chapter. + +Forcing power +------------- +Many OEMs include a method that can be used to force the power of a +thunderbolt controller to an "On" state even if nothing is connected. +If supported by your machine this will be exposed by the WMI bus with +a sysfs attribute called "force_power". + +For example the intel-wmi-thunderbolt driver exposes this attribute in: + /sys/devices/platform/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/86CCFD48-205E-4A77-9C48-2021CBEDE341/force_power + + To force the power to on, write 1 to this attribute file. + To disable force power, write 0 to this attribute file. + +Note: it's currently not possible to query the force power state of a platform. -- cgit v1.2.3 From 8c5b3b328b3c43bc2453c5ffa9cfdaba68c0feba Mon Sep 17 00:00:00 2001 From: Yuan Yao Date: Wed, 30 Aug 2017 18:12:37 +0800 Subject: dt-bindings: spi: Add fsl,ls1012a-dspi compatible string new compatible string: "fsl,ls1012a-dspi". Signed-off-by: Yuan Yao Signed-off-by: Hou Zhiqiang Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt index 13b1fcc8469e..dcc7eaada511 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt @@ -5,6 +5,7 @@ Required properties: "fsl,ls2085a-dspi" or "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi" + "fsl,ls1012a-dspi" followed by "fsl,ls1021a-v1.0-dspi" - reg : Offset and length of the register set for the device - interrupts : Should contain SPI controller interrupt - clocks: from common clock binding: handle to dspi clock. -- cgit v1.2.3 From b07815d4eaf658b683c345d6e643895a20d92f29 Mon Sep 17 00:00:00 2001 From: Yuan Yao Date: Wed, 30 Aug 2017 18:12:38 +0800 Subject: dt-bindings: mtd: add sst25wf040b and en25s64 to sip-nor list The chip sst25wf040b and en25s64 are compatible with SPI NOR flash. Signed-off-by: Yuan Yao Signed-off-by: Hou Zhiqiang Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt index 9ce35af8507c..4cab5d85cf6f 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt @@ -13,6 +13,7 @@ Required properties: at25df321a at25df641 at26df081a + en25s64 mr25h256 mr25h10 mr25h40 @@ -31,6 +32,7 @@ Required properties: s25fl008k s25fl064k sst25vf040b + sst25wf040b m25p40 m25p80 m25p16 -- cgit v1.2.3 From 601516a6f8cf9118a7c65ec38aa53896efc446bb Mon Sep 17 00:00:00 2001 From: Charles Keepax Date: Mon, 4 Sep 2017 16:41:52 +0100 Subject: mfd: arizona: Remove audio bindings from MFD binding document Now the audio bindings have their own binding document update the main MFD document to point to that file and remove the audio binding documentation. Signed-off-by: Charles Keepax Acked-by: Rob Herring Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/mfd/arizona.txt | 40 +---------------------- 1 file changed, 1 insertion(+), 39 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index b37bdde5cfda..bdd017686ea5 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -65,45 +65,6 @@ Optional properties: a value that is out of range for a 16 bit register then the chip default will be used. If present exactly five values must be specified. - - wlf,inmode : A list of INn_MODE register values, where n is the number - of input signals. Valid values are 0 (Differential), 1 (Single-ended) and - 2 (Digital Microphone). If absent, INn_MODE registers set to 0 by default. - If present, values must be specified less than or equal to the number of - input signals. If values less than the number of input signals, elements - that have not been specified are set to 0 by default. Entries are: - (wm5102, wm5110, wm8280, wm8997) - (wm8998, wm1814) - - wlf,out-mono : A list of boolean values indicating whether each output is - mono or stereo. Position within the list indicates the output affected - (eg. First entry in the list corresponds to output 1). A non-zero value - indicates a mono output. If present, the number of values should be less - than or equal to the number of outputs, if less values are supplied the - additional outputs will be treated as stereo. - - - wlf,dmic-ref : DMIC reference voltage source for each input, can be - selected from either MICVDD or one of the MICBIAS's, defines - (ARIZONA_DMIC_xxxx) are provided in . If - present, the number of values should be less than or equal to the - number of inputs, unspecified inputs will use the chip default. - - - wlf,max-channels-clocked : The maximum number of channels to be clocked on - each AIF, useful for I2S systems with multiple data lines being mastered. - Specify one cell for each AIF to be configured, specify zero for AIFs that - should be handled normally. - If present, number of cells must be less than or equal to the number of - AIFs. If less than the number of AIFs, for cells that have not been - specified the corresponding AIFs will be treated as default setting. - - - wlf,spk-fmt : PDM speaker data format, must contain 2 cells (OUT5 and OUT6). - See the datasheet for values. - The second cell is ignored for codecs that do not have OUT6 (wm5102, wm8997, - wm8998, wm1814) - - - wlf,spk-mute : PDM speaker mute setting, must contain 2 cells (OUT5 and OUT6). - See the datasheet for values. - The second cell is ignored for codecs that do not have OUT6 (wm5102, wm8997, - wm8998, wm1814) - - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if they are being externally supplied. As covered in Documentation/devicetree/bindings/regulator/regulator.txt @@ -112,6 +73,7 @@ Optional properties: Also see child specific device properties: Regulator - ../regulator/arizona-regulator.txt Extcon - ../extcon/extcon-arizona.txt + Sound - ../sound/arizona.txt Example: -- cgit v1.2.3 From 0340afe74d43e9c82bc0f5904d8f5b99d0fc3ab0 Mon Sep 17 00:00:00 2001 From: Charles Keepax Date: Mon, 4 Sep 2017 16:41:54 +0100 Subject: ASoC: arizona: Add device tree binding doc for volume limits Signed-off-by: Charles Keepax Acked-by: Rob Herring Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/wlf,arizona.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/wlf,arizona.txt b/Documentation/devicetree/bindings/sound/wlf,arizona.txt index 4e67224488d8..e172c62dc2df 100644 --- a/Documentation/devicetree/bindings/sound/wlf,arizona.txt +++ b/Documentation/devicetree/bindings/sound/wlf,arizona.txt @@ -47,3 +47,7 @@ Optional properties: See the datasheet for values. The second cell is ignored for codecs that do not have OUT6 (wm5102, wm8997, wm8998, wm1814) + + - wlf,out-volume-limit : The volume limit value that should be applied to each + output channel. See the datasheet for exact values. Channels are specified + in the order OUT1L, OUT1R, OUT2L, OUT2R, etc. -- cgit v1.2.3 From 5418a9004126992aa2bbd07d79e8305659cb0dc9 Mon Sep 17 00:00:00 2001 From: Vladimir Barinov Date: Sat, 16 Sep 2017 21:48:47 +0300 Subject: arm: shmobile: Document Kingfisher board DT bindings Add Kingfisher Device tree bindings Documentation, listing it as a supported board. Kingfisher is the H3ULCB/M3ULCB extension board. Signed-off-by: Vladimir Barinov Acked-by: Geert Uytterhoeven Acked-by: Rob Herring Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index a1f06711a4dd..e9bd3091dcf6 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -78,6 +78,8 @@ Boards: compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743" - iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) compatible = "iwave,g20m", "renesas,r8a7743" + - Kingfisher (SBEV-RCAR-KF-M03) + compatible = "shimafuji,kingfisher" - Koelsch (RTP0RC7791SEB00010S) compatible = "renesas,koelsch", "renesas,r8a7791" - Kyoto Microcomputer Co. KZM-A9-Dual -- cgit v1.2.3 From e22b36bd75ad57fdf1010ce7d6d92df96311947b Mon Sep 17 00:00:00 2001 From: Sergei Shtylyov Date: Fri, 15 Sep 2017 22:43:24 +0300 Subject: arm64: renesas: document Eagle board bindings Document the Eagle device tree bindings, listing it as a supported board. This allows to use checkpatch.pl to validate .dts files referring to the Eagle board. Signed-off-by: Sergei Shtylyov Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index e9bd3091dcf6..4fa984ada912 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -59,6 +59,8 @@ Boards: compatible = "renesas,bockw", "renesas,r8a7778" - Draak (RTP0RC77995SEB0010S) compatible = "renesas,draak", "renesas,r8a77995" + - Eagle (RTP0RC77970SEB0010S) + compatible = "renesas,eagle", "renesas,r8a77970" - Genmai (RTK772100BC00000BR) compatible = "renesas,genmai", "renesas,r7s72100" - GR-Peach (X28A-M01-E/F) -- cgit v1.2.3 From a6bcda44843c6dfced0fb973e2607c2a98addfa9 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Tue, 19 Sep 2017 11:52:43 +0200 Subject: cfg80211: remove unused function ieee80211_data_from_8023() This function hasn't been used since the removal of iwmc3200wifi in 2012. It also appears to have a bug when qos=True, since then it'll copy uninitialized stack memory to the SKB. Just remove the function entirely. Reported-by: Jouni Malinen Signed-off-by: Johannes Berg --- Documentation/driver-api/80211/cfg80211.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/80211/cfg80211.rst b/Documentation/driver-api/80211/cfg80211.rst index 8ffac57e1f5b..eeab91b59457 100644 --- a/Documentation/driver-api/80211/cfg80211.rst +++ b/Documentation/driver-api/80211/cfg80211.rst @@ -299,9 +299,6 @@ Data path helpers .. kernel-doc:: include/net/cfg80211.h :functions: ieee80211_data_to_8023 -.. kernel-doc:: include/net/cfg80211.h - :functions: ieee80211_data_from_8023 - .. kernel-doc:: include/net/cfg80211.h :functions: ieee80211_amsdu_to_8023s -- cgit v1.2.3 From 127b8e2692b6c145955bb71e482ca1bc6ce10027 Mon Sep 17 00:00:00 2001 From: Gabriel Fernandez Date: Tue, 19 Sep 2017 13:44:06 +0200 Subject: dt-bindings: clk: stm32h7: fix clock-cell size The clock-cell size is 1 on stm32h7 plaform. Signed-off-by: Gabriel Fernandez Fixes: 3e4d618b0722 ("clk: stm32h7: Add stm32h743 clock driver") Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt index a135504c7d57..cac24ee10b72 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt +++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt @@ -32,7 +32,7 @@ Example: compatible = "st,stm32h743-rcc", "st,stm32-rcc"; reg = <0x58024400 0x400>; #reset-cells = <1>; - #clock-cells = <2>; + #clock-cells = <1>; clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>; st,syscfg = <&pwrcfg>; -- cgit v1.2.3 From e8901f3ab5b5c2ce75abdcd182b07d00fd6746fe Mon Sep 17 00:00:00 2001 From: Masahiro Yamada Date: Fri, 22 Sep 2017 14:58:23 +0900 Subject: dt-bindings: nand: denali: reduce the register space in the example This example allocates much more than needed for address regions. As for "denali_reg", as you see in drivers/mtd/nand/denali.h, all registers fit in 0x1000. As for "nand_data", this IP is generally configured to use Indexed Addressing mode, where there are only two registers in the address translation module (CTRL: 0x00, DATA: 0x10). Altera SOCFPGA is also this case. So, 0x20 is enough. Signed-off-by: Masahiro Yamada Acked-by: Rob Herring Signed-off-by: Boris Brezillon --- Documentation/devicetree/bindings/mtd/denali-nand.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt index 504291d2e5c2..0ee8edb60efc 100644 --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt @@ -29,7 +29,7 @@ nand: nand@ff900000 { #address-cells = <1>; #size-cells = <1>; compatible = "altr,socfpga-denali-nand"; - reg = <0xff900000 0x100000>, <0xffb80000 0x10000>; + reg = <0xff900000 0x20>, <0xffb80000 0x1000>; reg-names = "nand_data", "denali_reg"; interrupts = <0 144 4>; }; -- cgit v1.2.3 From 9ebd65cbdfbf59e7ef4b9c0c8fd767ff63f60411 Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I Date: Wed, 6 Sep 2017 17:15:54 +0530 Subject: dt-bindings: sdhci-omap: Add bindings for the sdhci-omap controller Add binding for the TI's sdhci-omap controller. Signed-off-by: Kishon Vijay Abraham I Acked-by: Tony Lindgren Acked-by: Rob Herring Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/sdhci-omap.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt new file mode 100644 index 000000000000..51775a372c06 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt @@ -0,0 +1,16 @@ +* TI OMAP SDHCI Controller + +Refer to mmc.txt for standard MMC bindings. + +Required properties: +- compatible: Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers +- ti,hwmods: Must be "mmc", is controller instance starting 1 + +Example: + mmc1: mmc@4809c000 { + compatible = "ti,dra7-sdhci"; + reg = <0x4809c000 0x400>; + ti,hwmods = "mmc1"; + bus-width = <4>; + vmmc-supply = <&vmmc>; /* phandle to regulator node */ + }; -- cgit v1.2.3 From a9a1d2a7827c9cf780966d0879c73ef5a91380e9 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 22 Sep 2017 11:02:10 +0200 Subject: pinctrl/gpio: Unify namespace for cross-calls The pinctrl_request_gpio() and pinctrl_free_gpio() break the nice namespacing in the other cross-calls like pinctrl_gpio_foo(). Just rename them and all references so we have one namespace with all cross-calls under pinctrl_gpio_*(). Signed-off-by: Linus Walleij --- Documentation/driver-api/pinctl.rst | 6 +++--- Documentation/gpio/gpio-legacy.txt | 10 +++++----- Documentation/translations/zh_CN/gpio.txt | 6 +++--- 3 files changed, 11 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/pinctl.rst b/Documentation/driver-api/pinctl.rst index 48f15b4f9d3e..6cb68d67fa75 100644 --- a/Documentation/driver-api/pinctl.rst +++ b/Documentation/driver-api/pinctl.rst @@ -757,8 +757,8 @@ that your datasheet calls "GPIO mode", but actually is just an electrical configuration for a certain device. See the section below named "GPIO mode pitfalls" for more details on this scenario. -The public pinmux API contains two functions named pinctrl_request_gpio() -and pinctrl_free_gpio(). These two functions shall *ONLY* be called from +The public pinmux API contains two functions named pinctrl_gpio_request() +and pinctrl_gpio_free(). These two functions shall *ONLY* be called from gpiolib-based drivers as part of their gpio_request() and gpio_free() semantics. Likewise the pinctrl_gpio_direction_[input|output] shall only be called from within respective gpio_direction_[input|output] @@ -790,7 +790,7 @@ gpiolib driver and the affected GPIO range, pin offset and desired direction will be passed along to this function. Alternatively to using these special functions, it is fully allowed to use -named functions for each GPIO pin, the pinctrl_request_gpio() will attempt to +named functions for each GPIO pin, the pinctrl_gpio_request() will attempt to obtain the function "gpioN" where "N" is the global GPIO pin number if no special GPIO-handler is registered. diff --git a/Documentation/gpio/gpio-legacy.txt b/Documentation/gpio/gpio-legacy.txt index 5eacc147ea87..8356d0e78f67 100644 --- a/Documentation/gpio/gpio-legacy.txt +++ b/Documentation/gpio/gpio-legacy.txt @@ -273,8 +273,8 @@ easily, gating off unused clocks. For GPIOs that use pins known to the pinctrl subsystem, that subsystem should be informed of their use; a gpiolib driver's .request() operation may call -pinctrl_request_gpio(), and a gpiolib driver's .free() operation may call -pinctrl_free_gpio(). The pinctrl subsystem allows a pinctrl_request_gpio() +pinctrl_gpio_request(), and a gpiolib driver's .free() operation may call +pinctrl_gpio_free(). The pinctrl subsystem allows a pinctrl_gpio_request() to succeed concurrently with a pin or pingroup being "owned" by a device for pin multiplexing. @@ -448,8 +448,8 @@ together with an optional gpio feature. We have already covered the case where e.g. a GPIO controller need to reserve a pin or set the direction of a pin by calling any of: -pinctrl_request_gpio() -pinctrl_free_gpio() +pinctrl_gpio_request() +pinctrl_gpio_free() pinctrl_gpio_direction_input() pinctrl_gpio_direction_output() @@ -466,7 +466,7 @@ gpio (under gpiolib) is still maintained by gpio drivers. It may happen that different pin ranges in a SoC is managed by different gpio drivers. This makes it logical to let gpio drivers announce their pin ranges to -the pin ctrl subsystem before it will call 'pinctrl_request_gpio' in order +the pin ctrl subsystem before it will call 'pinctrl_gpio_request' in order to request the corresponding pin to be prepared by the pinctrl subsystem before any gpio usage. diff --git a/Documentation/translations/zh_CN/gpio.txt b/Documentation/translations/zh_CN/gpio.txt index bce972521065..4f8bf30a41dc 100644 --- a/Documentation/translations/zh_CN/gpio.txt +++ b/Documentation/translations/zh_CN/gpio.txt @@ -257,9 +257,9 @@ GPIO 值的命令需要等待其信息排到队首才发送命令，再获得其 简单地关闭未使用时钟)。 对于 GPIO 使用 pinctrl 子系统已知的引脚，子系统应该被告知其使用情况； -一个 gpiolib 驱动的 .request()操作应调用 pinctrl_request_gpio()， -而 gpiolib 驱动的 .free()操作应调用 pinctrl_free_gpio()。pinctrl -子系统允许 pinctrl_request_gpio()在某个引脚或引脚组以复用形式“属于” +一个 gpiolib 驱动的 .request()操作应调用 pinctrl_gpio_request()， +而 gpiolib 驱动的 .free()操作应调用 pinctrl_gpio_free()。pinctrl +子系统允许 pinctrl_gpio_request()在某个引脚或引脚组以复用形式“属于” 一个设备时都成功返回。 任何须将 GPIO 信号导向适当引脚的引脚复用硬件的编程应该发生在 GPIO -- cgit v1.2.3 From 6e480762aa3fb83a038761a54343e197a984821a Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Sun, 3 Sep 2017 21:53:12 +0200 Subject: dt-bindings: gpu: mali-utgard: Add Rockchip Utgard Malis Some (older or lower power) Rockchip socs use Utgard-based Mali-GPUs. So add the necessary compatibles for them. As the setup is the same for all of them (needing only the additional reset line), they get added in a somewhat condensed form, to not inflate the document unnecessary. Signed-off-by: Heiko Stuebner Acked-by: Rob Herring --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt index b4ebd56d03f3..24aacafb2594 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt @@ -13,6 +13,10 @@ Required properties: + allwinner,sun50i-h5-mali + amlogic,meson-gxbb-mali + amlogic,meson-gxl-mali + + rockchip,rk3036-mali + + rockchip,rk3066-mali + + rockchip,rk3188-mali + + rockchip,rk3228-mali + stericsson,db8500-mali - reg: Physical base address and length of the GPU registers @@ -63,6 +67,10 @@ to specify one more vendor-specific compatible, among: Required properties: * resets: phandle to the reset line for the GPU + - Rockchip variants: + Required properties: + * resets: phandle to the reset line for the GPU + - stericsson,db8500-mali Required properties: * interrupt-names and interrupts: -- cgit v1.2.3 From dc1f65c5bd04918a8975009d694fa244f433d08e Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Sun, 3 Sep 2017 22:09:49 +0200 Subject: dt-bindings: gpu: mali-utgard: add optional supply regulator Mali GPUs have a separate supplying regulator in a lot of socs, so describe a mali-supply property. The already described operating points will likely also need access to this regulator. Signed-off-by: Heiko Stuebner Acked-by: Rob Herring --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt index 24aacafb2594..25ebf4140e69 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt @@ -44,6 +44,10 @@ Optional properties: Memory region to allocate from, as defined in Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt + - mali-supply: + Phandle to regulator for the Mali device, as defined in + Documentation/devicetree/bindings/regulator/regulator.txt for details. + - operating-points-v2: Operating Points for the GPU, as defined in Documentation/devicetree/bindings/opp/opp.txt -- cgit v1.2.3 From 6a4d02f88fa2b6c21d8ba645e690bdbfe6adcb1f Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Fri, 15 Sep 2017 11:07:55 +0200 Subject: dt-bindings: gpu: mali-utgard: add optional power-domain reference On some socs Mali Utgard gpus have both soc power-domains and external supplying regulators, so add an optional power-domains property for reference. Signed-off-by: Heiko Stuebner Acked-by: Rob Herring --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt index 25ebf4140e69..c6814d7cc2b2 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt @@ -52,6 +52,10 @@ Optional properties: Operating Points for the GPU, as defined in Documentation/devicetree/bindings/opp/opp.txt + - power-domains: + A power domain consumer specifier as defined in + Documentation/devicetree/bindings/power/power_domain.txt + Vendor-specific bindings ------------------------ -- cgit v1.2.3 From f1f2237ff699bbc1a0265ed10407ae8d4a52008e Mon Sep 17 00:00:00 2001 From: PrasannaKumar Muralidharan Date: Wed, 23 Aug 2017 20:34:43 +0530 Subject: dt/bindings: exynos-rng: Move dt binding documentation to bindings/crypto Samsung exynos PRNG driver is using crypto framework instead of hw_random framework. So move the devicetree binding to crypto folder. Signed-off-by: PrasannaKumar Muralidharan Reviewed-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu --- .../devicetree/bindings/crypto/samsung,exynos-rng4.txt | 17 +++++++++++++++++ .../devicetree/bindings/rng/samsung,exynos-rng4.txt | 17 ----------------- 2 files changed, 17 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt delete mode 100644 Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt b/Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt new file mode 100644 index 000000000000..4ca8dd4d7e66 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt @@ -0,0 +1,17 @@ +Exynos Pseudo Random Number Generator + +Required properties: + +- compatible : Should be "samsung,exynos4-rng". +- reg : Specifies base physical address and size of the registers map. +- clocks : Phandle to clock-controller plus clock-specifier pair. +- clock-names : "secss" as a clock name. + +Example: + + rng@10830400 { + compatible = "samsung,exynos4-rng"; + reg = <0x10830400 0x200>; + clocks = <&clock CLK_SSS>; + clock-names = "secss"; + }; diff --git a/Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt b/Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt deleted file mode 100644 index 4ca8dd4d7e66..000000000000 --- a/Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt +++ /dev/null @@ -1,17 +0,0 @@ -Exynos Pseudo Random Number Generator - -Required properties: - -- compatible : Should be "samsung,exynos4-rng". -- reg : Specifies base physical address and size of the registers map. -- clocks : Phandle to clock-controller plus clock-specifier pair. -- clock-names : "secss" as a clock name. - -Example: - - rng@10830400 { - compatible = "samsung,exynos4-rng"; - reg = <0x10830400 0x200>; - clocks = <&clock CLK_SSS>; - clock-names = "secss"; - }; -- cgit v1.2.3 From d21010789ce0efb48b56de02f57ae56cd40b6503 Mon Sep 17 00:00:00 2001 From: Roy Pledge Date: Mon, 18 Sep 2017 16:39:39 -0400 Subject: dt-bindings: soc/fsl: Update reserved memory binding for QBMan Updates the QMan and BMan device tree bindings for reserved memory nodes. This makes the reserved memory allocation compatible with the shared-dma-pool usage. Signed-off-by: Roy Pledge Acked-by: Rob Herring Signed-off-by: Li Yang --- Documentation/devicetree/bindings/soc/fsl/bman.txt | 12 +++++----- Documentation/devicetree/bindings/soc/fsl/qman.txt | 26 ++++++++++++++++------ 2 files changed, 26 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/fsl/bman.txt b/Documentation/devicetree/bindings/soc/fsl/bman.txt index 47ac834414d8..48eed140765b 100644 --- a/Documentation/devicetree/bindings/soc/fsl/bman.txt +++ b/Documentation/devicetree/bindings/soc/fsl/bman.txt @@ -65,8 +65,8 @@ to the respective BMan instance BMan Private Memory Node BMan requires a contiguous range of physical memory used for the backing store -for BMan Free Buffer Proxy Records (FBPR). This memory is reserved/allocated as a -node under the /reserved-memory node +for BMan Free Buffer Proxy Records (FBPR). This memory is reserved/allocated as +a node under the /reserved-memory node. The BMan FBPR memory node must be named "bman-fbpr" @@ -75,7 +75,9 @@ PROPERTIES - compatible Usage: required Value type: - Definition: Must inclide "fsl,bman-fbpr" + Definition: PPC platforms: Must include "fsl,bman-fbpr" + ARM platforms: Must include "shared-dma-pool" + as well as the "no-map" property The following constraints are relevant to the FBPR private memory: - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to @@ -100,10 +102,10 @@ The example below shows a BMan FBPR dynamic allocation memory node ranges; bman_fbpr: bman-fbpr { - compatible = "fsl,bman-fbpr"; - alloc-ranges = <0 0 0x10 0>; + compatible = "shared-mem-pool"; size = <0 0x1000000>; alignment = <0 0x1000000>; + no-map; }; }; diff --git a/Documentation/devicetree/bindings/soc/fsl/qman.txt b/Documentation/devicetree/bindings/soc/fsl/qman.txt index 556ebb8be75d..ee96afd2af72 100644 --- a/Documentation/devicetree/bindings/soc/fsl/qman.txt +++ b/Documentation/devicetree/bindings/soc/fsl/qman.txt @@ -60,6 +60,12 @@ are located at offsets 0xbf8 and 0xbfc Value type: Definition: Reference input clock. Its frequency is half of the platform clock +- memory-regions + Usage: Required for ARM + Value type: + Definition: List of phandles referencing the QMan private memory + nodes (described below). The qman-fqd node must be + first followed by qman-pfdr node. Only used on ARM Devices connected to a QMan instance via Direct Connect Portals (DCP) must link to the respective QMan instance @@ -74,7 +80,9 @@ QMan Private Memory Nodes QMan requires two contiguous range of physical memory used for the backing store for QMan Frame Queue Descriptor (FQD) and Packed Frame Descriptor Record (PFDR). -This memory is reserved/allocated as a nodes under the /reserved-memory node +This memory is reserved/allocated as a node under the /reserved-memory node. + +For additional details about reserved memory regions see reserved-memory.txt The QMan FQD memory node must be named "qman-fqd" @@ -83,7 +91,9 @@ PROPERTIES - compatible Usage: required Value type: - Definition: Must inclide "fsl,qman-fqd" + Definition: PPC platforms: Must include "fsl,qman-fqd" + ARM platforms: Must include "shared-dma-pool" + as well as the "no-map" property The QMan PFDR memory node must be named "qman-pfdr" @@ -92,7 +102,9 @@ PROPERTIES - compatible Usage: required Value type: - Definition: Must inclide "fsl,qman-pfdr" + Definition: PPC platforms: Must include "fsl,qman-pfdr" + ARM platforms: Must include "shared-dma-pool" + as well as the "no-map" property The following constraints are relevant to the FQD and PFDR private memory: - The size must be 2^(size + 1), with size = 11..29. That is 4 KiB to @@ -117,16 +129,16 @@ The example below shows a QMan FQD and a PFDR dynamic allocation memory nodes ranges; qman_fqd: qman-fqd { - compatible = "fsl,qman-fqd"; - alloc-ranges = <0 0 0x10 0>; + compatible = "shared-dma-pool"; size = <0 0x400000>; alignment = <0 0x400000>; + no-map; }; qman_pfdr: qman-pfdr { - compatible = "fsl,qman-pfdr"; - alloc-ranges = <0 0 0x10 0>; + compatible = "shared-dma-pool"; size = <0 0x2000000>; alignment = <0 0x2000000>; + no-map; }; }; -- cgit v1.2.3 From b69116cd96ec641168ced9460675360fa6df84c8 Mon Sep 17 00:00:00 2001 From: Icenowy Zheng Date: Tue, 22 Aug 2017 13:23:20 +0800 Subject: dt-bindings: add compatible string for Allwinner V3s SoC The compatible string for Allwinner V3s SoC used to be missing. Add it to the binding document. Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC") Acked-by: Rob Herring Signed-off-by: Icenowy Zheng Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/arm/sunxi.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt index d2c46449b4eb..f35c6ada5a65 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.txt +++ b/Documentation/devicetree/bindings/arm/sunxi.txt @@ -14,6 +14,7 @@ using one of the following compatible strings: allwinner,sun8i-a83t allwinner,sun8i-h2-plus allwinner,sun8i-h3 + allwinner,sun8i-v3s allwinner,sun9i-a80 allwinner,sun50i-a64 nextthing,gr8 -- cgit v1.2.3 From 9e8dda2df7cc209d0165618e6d18b324c02c8348 Mon Sep 17 00:00:00 2001 From: Icenowy Zheng Date: Tue, 22 Aug 2017 13:23:21 +0800 Subject: ARM: sunxi: fix the core number of V3s in sunxi README The Allwinner V3s SoC is not quad-core, but single-core. Fix this in the README file. Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC") Signed-off-by: Icenowy Zheng Signed-off-by: Maxime Ripard --- Documentation/arm/sunxi/README | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README index d7b1f016bd62..de791e18ccef 100644 --- a/Documentation/arm/sunxi/README +++ b/Documentation/arm/sunxi/README @@ -33,6 +33,11 @@ SunXi family - Next Thing Co GR8 (sun5i) + * Single ARM Cortex-A7 based SoCs + - Allwinner V3s (sun8i) + + Datasheet + http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf + * Dual ARM Cortex-A7 based SoCs - Allwinner A20 (sun7i) + User Manual @@ -71,10 +76,6 @@ SunXi family + Datasheet http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf - - Allwinner V3s (sun8i) - + Datasheet - http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf - * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs - Allwinner A80 + Datasheet -- cgit v1.2.3 From 14e25a03682f7ca0464ac7e3f3f10f02d885fed4 Mon Sep 17 00:00:00 2001 From: Icenowy Zheng Date: Tue, 22 Aug 2017 13:23:22 +0800 Subject: ARM: sunxi: add support for R40 SoC Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals like A20. Add support for it. Signed-off-by: Icenowy Zheng Signed-off-by: Maxime Ripard --- Documentation/arm/sunxi/README | 6 ++++++ Documentation/devicetree/bindings/arm/sunxi.txt | 1 + 2 files changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README index de791e18ccef..f8efc21998bf 100644 --- a/Documentation/arm/sunxi/README +++ b/Documentation/arm/sunxi/README @@ -76,6 +76,12 @@ SunXi family + Datasheet http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf + - Allwinner R40 (sun8i) + + Datasheet + https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf + + User Manual + https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf + * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs - Allwinner A80 + Datasheet diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt index f35c6ada5a65..e4beec3d9ad3 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.txt +++ b/Documentation/devicetree/bindings/arm/sunxi.txt @@ -14,6 +14,7 @@ using one of the following compatible strings: allwinner,sun8i-a83t allwinner,sun8i-h2-plus allwinner,sun8i-h3 + allwinner-sun8i-r40 allwinner,sun8i-v3s allwinner,sun9i-a80 allwinner,sun50i-a64 -- cgit v1.2.3 From 9a59d9361a68b0f664372312debd7396eda3ed55 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Mon, 18 Sep 2017 06:26:03 -0400 Subject: media: cec-ioc-dqevent.rst: fix typo The documentation talked about INITIAL_VALUE when the actual define is INITIAL_STATE. Fix this. Signed-off-by: Hans Verkuil Reported-by: Jonas Karlman Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/cec.h.rst.exceptions | 2 -- Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 4 ++-- 2 files changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/media/cec.h.rst.exceptions b/Documentation/media/cec.h.rst.exceptions index b1687532742f..d9fd092de6f8 100644 --- a/Documentation/media/cec.h.rst.exceptions +++ b/Documentation/media/cec.h.rst.exceptions @@ -24,8 +24,6 @@ ignore define CEC_VENDOR_ID_NONE ignore define CEC_MODE_INITIATOR_MSK ignore define CEC_MODE_FOLLOWER_MSK -ignore define CEC_EVENT_FL_INITIAL_STATE - # Part of CEC 2.0 spec - shouldn't be documented too? ignore define CEC_LOG_ADDR_TV ignore define CEC_LOG_ADDR_RECORD_1 diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst index a5c821809cc6..4fe96e2adf4c 100644 --- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst +++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst @@ -172,9 +172,9 @@ it is guaranteed that the state did change in between the two events. :stub-columns: 0 :widths: 3 1 8 - * .. _`CEC-EVENT-FL-INITIAL-VALUE`: + * .. _`CEC-EVENT-FL-INITIAL-STATE`: - - ``CEC_EVENT_FL_INITIAL_VALUE`` + - ``CEC_EVENT_FL_INITIAL_STATE`` - 1 - Set for the initial events that are generated when the device is opened. See the table above for which events do this. This allows -- cgit v1.2.3 From da634f623e4879d7716029a84791fc596ebac24d Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Mon, 18 Sep 2017 05:23:57 -0400 Subject: media: cec-core.rst/cec-ioc-receive.rst: clarify CEC_TX_STATUS_ERROR CEC_TX_STATUS_ERROR can be used if the HW cannot tell LOST_ARB and LOW_DRIVE apart, or when some other error occurs. It is not a replacement for NACK. So the hardware must be able to tell the difference between OK, NACK and 'something else'. Clarify the documentation (both public and kernel API) on this point. Also fix two small typos (this messages -> this message). Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/cec-core.rst | 7 +++++-- Documentation/media/uapi/cec/cec-ioc-receive.rst | 10 +++++----- 2 files changed, 10 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/media/kapi/cec-core.rst b/Documentation/media/kapi/cec-core.rst index 28866259998c..d37e107f2fde 100644 --- a/Documentation/media/kapi/cec-core.rst +++ b/Documentation/media/kapi/cec-core.rst @@ -227,8 +227,8 @@ CEC_TX_STATUS_LOW_DRIVE: retransmission. CEC_TX_STATUS_ERROR: - some unspecified error occurred: this can be one of - the previous two if the hardware cannot differentiate or something + some unspecified error occurred: this can be one of ARB_LOST + or LOW_DRIVE if the hardware cannot differentiate or something else entirely. CEC_TX_STATUS_MAX_RETRIES: @@ -238,6 +238,9 @@ CEC_TX_STATUS_MAX_RETRIES: doesn't have to make another attempt to transmit the message since the hardware did that already. +The hardware must be able to differentiate between OK, NACK and 'something +else'. + The \*_cnt arguments are the number of error conditions that were seen. This may be 0 if no information is available. Drivers that do not support hardware retry can just set the counter corresponding to the transmit error diff --git a/Documentation/media/uapi/cec/cec-ioc-receive.rst b/Documentation/media/uapi/cec/cec-ioc-receive.rst index 0f397c535a4c..bdad4b197bcd 100644 --- a/Documentation/media/uapi/cec/cec-ioc-receive.rst +++ b/Documentation/media/uapi/cec/cec-ioc-receive.rst @@ -131,7 +131,7 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). - ``tx_status`` - The status bits of the transmitted message. See :ref:`cec-tx-status` for the possible status values. It is 0 if - this messages was received, not transmitted. + this message was received, not transmitted. * - __u8 - ``msg[16]`` - The message payload. For :ref:`ioctl CEC_TRANSMIT ` this is filled in by the @@ -168,7 +168,7 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). - ``tx_status`` - The status bits of the transmitted message. See :ref:`cec-tx-status` for the possible status values. It is 0 if - this messages was received, not transmitted. + this message was received, not transmitted. * - __u8 - ``tx_arb_lost_cnt`` - A counter of the number of transmit attempts that resulted in the @@ -256,9 +256,9 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). - ``CEC_TX_STATUS_ERROR`` - 0x10 - Some error occurred. This is used for any errors that do not fit - the previous two, either because the hardware could not tell which - error occurred, or because the hardware tested for other - conditions besides those two. + ``CEC_TX_STATUS_ARB_LOST`` or ``CEC_TX_STATUS_LOW_DRIVE``, either because + the hardware could not tell which error occurred, or because the hardware + tested for other conditions besides those two. * .. _`CEC-TX-STATUS-MAX-RETRIES`: - ``CEC_TX_STATUS_MAX_RETRIES`` -- cgit v1.2.3 From 00f7adff0c3a1d793ffa213c28d82c47dfd8ab04 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 30 Aug 2017 12:05:55 -0400 Subject: media: cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events Document these new CEC events. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst index 4fe96e2adf4c..b6fd86424fbb 100644 --- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst +++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst @@ -161,6 +161,24 @@ it is guaranteed that the state did change in between the two events. - Generated if the CEC pin goes from a low voltage to a high voltage. Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN`` capability set. + * .. _`CEC-EVENT-PIN-HPD-LOW`: + + - ``CEC_EVENT_PIN_HPD_LOW`` + - 5 + - Generated if the HPD pin goes from a high voltage to a low voltage. + Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN`` + capability set. When open() is called, the HPD pin can be read and + if the HPD is low, then an initial event will be generated for that + filehandle. + * .. _`CEC-EVENT-PIN-HPD-HIGH`: + + - ``CEC_EVENT_PIN_HPD_HIGH`` + - 6 + - Generated if the HPD pin goes from a low voltage to a high voltage. + Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN`` + capability set. When open() is called, the HPD pin can be read and + if the HPD is high, then an initial event will be generated for that + filehandle. .. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}| -- cgit v1.2.3 From 67f2a06f14a9419bc2da0a8e6b440c6813dccdb0 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 2 Aug 2017 03:22:33 -0400 Subject: media: dt-bindings: document the CEC GPIO bindings Document the bindings for the cec-gpio module for hardware where the CEC line and optionally the HPD line are connected to GPIO lines. Signed-off-by: Hans Verkuil Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/cec-gpio.txt | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt b/Documentation/devicetree/bindings/media/cec-gpio.txt new file mode 100644 index 000000000000..46a0bac8b3b9 --- /dev/null +++ b/Documentation/devicetree/bindings/media/cec-gpio.txt @@ -0,0 +1,32 @@ +* HDMI CEC GPIO driver + +The HDMI CEC GPIO module supports CEC implementations where the CEC line +is hooked up to a pull-up GPIO line and - optionally - the HPD line is +hooked up to another GPIO line. + +Required properties: + - compatible: value must be "cec-gpio". + - cec-gpios: gpio that the CEC line is connected to. The line should be + tagged as open drain. + +If the CEC line is associated with an HDMI receiver/transmitter, then the +following property is also required: + + - hdmi-phandle - phandle to the HDMI controller, see also cec.txt. + +If the CEC line is not associated with an HDMI receiver/transmitter, then +the following property is optional: + + - hpd-gpios: gpio that the HPD line is connected to. + +Example for the Raspberry Pi 3 where the CEC line is connected to +pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is +connected to pin 11 aka BCM17: + +#include + +cec-gpio { + compatible = "cec-gpio"; + cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; + hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>; +}; -- cgit v1.2.3 From 104dc5e20ff52748a16f756ae946391bdc6a4d0a Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 20 Sep 2017 02:26:00 +0200 Subject: PM: Document rules on using pm_runtime_resume() in system suspend callbacks It quite often is necessary to resume devices from runtime suspend during system suspend for various reasons (for example, if their wakeup settings need to be changed), but that requires middle-layer or subsystem code to follow additional rules which currently are not clearly documented. Namely, if a driver calls pm_runtime_resume() for the device from its ->suspend (or equivalent) system sleep callback, that may not work if the middle layer above it has updated the state of the device from its ->prepare or ->suspend callbacks already in an incompatible way. For this reason, all middle layers must follow the rule that, until the ->suspend callback provided by the device's driver is invoked, the only way in which the device's state can be updated is by calling pm_runtime_resume() for it, if necessary. Fortunately enough, all middle layers in the code base today follow this rule, but it is not explicitly stated anywhere, so do that. Note that calling pm_runtime_resume() from the ->suspend callback of a driver will cause the ->runtime_resume callback provided by the middle layer to be invoked, but the rule above guarantees that this callback will nest properly with the middle layer's ->suspend callback and it will play well with the ->prepare one invoked before. Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson --- Documentation/driver-api/pm/devices.rst | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index bedd32388dac..a8b07ec732bd 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -328,7 +328,10 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``. After the ``->prepare`` callback method returns, no new children may be registered below the device. The method may also prepare the device or driver in some way for the upcoming system power transition, but it - should not put the device into a low-power state. + should not put the device into a low-power state. Moreover, if the + device supports runtime power management, the ``->prepare`` callback + method must not update its state in case it is necessary to resume it + from runtime suspend later on. For devices supporting runtime power management, the return value of the prepare callback can be used to indicate to the PM core that it may @@ -356,6 +359,16 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``. the appropriate low-power state, depending on the bus type the device is on, and they may enable wakeup events. + However, for devices supporting runtime power management, the + ``->suspend`` methods provided by subsystems (bus types and PM domains + in particular) must follow an additional rule regarding what can be done + to the devices before their drivers' ``->suspend`` methods are called. + Namely, they can only resume the devices from runtime suspend by + calling :c:func:`pm_runtime_resume` for them, if that is necessary, and + they must not update the state of the devices in any other way at that + time (in case the drivers need to resume the devices from runtime + suspend in their ``->suspend`` methods). + 3. For a number of devices it is convenient to split suspend into the "quiesce device" and "save device state" phases, in which cases ``suspend_late`` is meant to do the latter. It is always executed after @@ -729,6 +742,16 @@ state temporarily, for example so that its system wakeup capability can be disabled. This all depends on the hardware and the design of the subsystem and device driver in question. +If it is necessary to resume a device from runtime suspend during a system-wide +transition into a sleep state, that can be done by calling +:c:func:`pm_runtime_resume` for it from the ``->suspend`` callback (or its +couterpart for transitions related to hibernation) of either the device's driver +or a subsystem responsible for it (for example, a bus type or a PM domain). +That is guaranteed to work by the requirement that subsystems must not change +the state of devices (possibly except for resuming them from runtime suspend) +from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before* +invoking device drivers' ``->suspend`` callbacks (or equivalent). + During system-wide resume from a sleep state it's easiest to put devices into the full-power state, as explained in :file:`Documentation/power/runtime_pm.txt`. Refer to that document for more information regarding this particular issue as -- cgit v1.2.3 From 75f9f7279e874ff95d1abe4613abc0826c9a8dcc Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Fri, 22 Sep 2017 12:32:36 +0300 Subject: dt: bindings: as3645a: Use LED number to refer to LEDs Use integers (reg property) to tell the number of the LED to the driver instead of the node name. While both of these approaches are currently used by the LED bindings, using integers will require less driver changes for ACPI support. Additionally, it will make possible LED naming using chip and LED node names, effectively making the label property most useful for human-readable names only. Signed-off-by: Sakari Ailus Acked-by: Rob Herring Signed-off-by: Jacek Anaszewski --- .../devicetree/bindings/leds/ams,as3645a.txt | 28 ++++++++++++++-------- 1 file changed, 18 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt b/Documentation/devicetree/bindings/leds/ams,as3645a.txt index 12c5ef26ec73..fdc40e354a64 100644 --- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt @@ -15,11 +15,14 @@ Required properties compatible : Must be "ams,as3645a". reg : The I2C address of the device. Typically 0x30. +#address-cells : 1 +#size-cells : 0 -Required properties of the "flash" child node -============================================= +Required properties of the flash child node (0) +=============================================== +reg: 0 flash-timeout-us: Flash timeout in microseconds. The value must be in the range [100000, 850000] and divisible by 50000. flash-max-microamp: Maximum flash current in microamperes. Has to be @@ -33,20 +36,21 @@ ams,input-max-microamp: Maximum flash controller input current. The and divisible by 50000. -Optional properties of the "flash" child node -============================================= +Optional properties of the flash child node +=========================================== label : The label of the flash LED. -Required properties of the "indicator" child node -================================================= +Required properties of the indicator child node (1) +=================================================== +reg: 1 led-max-microamp: Maximum indicator current. The allowed values are 2500, 5000, 7500 and 10000. -Optional properties of the "indicator" child node -================================================= +Optional properties of the indicator child node +=============================================== label : The label of the indicator LED. @@ -55,16 +59,20 @@ Example ======= as3645a@30 { + #address-cells: 1 + #size-cells: 0 reg = <0x30>; compatible = "ams,as3645a"; - flash { + flash@0 { + reg = <0x0>; flash-timeout-us = <150000>; flash-max-microamp = <320000>; led-max-microamp = <60000>; ams,input-max-microamp = <1750000>; label = "as3645a:flash"; }; - indicator { + indicator@1 { + reg = <0x1>; led-max-microamp = <10000>; label = "as3645a:indicator"; }; -- cgit v1.2.3 From 5d0e4d78149b9745ea34848e950e734f7db3b95f Mon Sep 17 00:00:00 2001 From: Enric Balletbo i Serra Date: Tue, 27 Jun 2017 12:27:23 +0200 Subject: Documentation: tpm: add powered-while-suspended binding documentation Add a new powered-while-suspended property to control the behavior of the TPM suspend/resume. Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sonny Rao Reviewed-by: Jason Gunthorpe Reviewed-by: Jarkko Sakkinen Acked-by: Rob Herring Signed-off-by: Jarkko Sakkinen Signed-off-by: James Morris --- Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt b/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt index 8cb638b7e89c..85c8216fc335 100644 --- a/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt +++ b/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt @@ -8,6 +8,12 @@ Required properties: the firmware event log - linux,sml-size : size of the memory allocated for the firmware event log +Optional properties: + +- powered-while-suspended: present when the TPM is left powered on between + suspend and resume (makes the suspend/resume + callbacks do nothing). + Example (for OpenPower Systems with Nuvoton TPM 2.0 on I2C) ---------------------------------------------------------- -- cgit v1.2.3 From fd060b3cd585542b44335d9169c71ce40b6384ac Mon Sep 17 00:00:00 2001 From: Lukas Wunner Date: Sat, 9 Sep 2017 20:32:41 +0200 Subject: dt-bindings: iio: adc: mcp320x: Update for mcp3550/1/3 All chips supported by this driver clock data out on the falling edge and latch data in on the rising edge, hence SPI mode (0,0) or (1,1) must be used. Furthermore, none of the chips has an internal reference voltage regulator, so an external supply is always required and needs to be specified in the device tree lest the IIO "scale" in sysfs cannot be calculated. Document these requirements in the device tree binding, add compatible strings for the newly supported mcp3550/1/3 and explain that SPI mode (0,0) should be preferred for these chips. Cc: Mathias Duckeck Signed-off-by: Lukas Wunner Acked-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/mcp320x.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt index bcd3ac8e6e0c..7d64753df949 100644 --- a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt +++ b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt @@ -29,15 +29,29 @@ Required properties: "microchip,mcp3204" "microchip,mcp3208" "microchip,mcp3301" + "microchip,mcp3550-50" + "microchip,mcp3550-60" + "microchip,mcp3551" + "microchip,mcp3553" NOTE: The use of the compatibles with no vendor prefix is deprecated and only listed because old DT use them. + - spi-cpha, spi-cpol (boolean): + Either SPI mode (0,0) or (1,1) must be used, so specify + none or both of spi-cpha, spi-cpol. The MCP3550/1/3 + is more efficient in mode (1,1) as only 3 instead of + 4 bytes need to be read from the ADC, but not all SPI + masters support it. + + - vref-supply: Phandle to the external reference voltage supply. + Examples: spi_controller { mcp3x0x@0 { compatible = "mcp3002"; reg = <0>; spi-max-frequency = <1000000>; + vref-supply = <&vref_reg>; }; }; -- cgit v1.2.3 From 4d354feffff16499464d57501c034657499eee97 Mon Sep 17 00:00:00 2001 From: Zhiyong Tao Date: Thu, 21 Sep 2017 09:26:50 +0800 Subject: dt-bindings: adc: mt2712: add binding documention The commit adds mt2712 compatible node in binding document. Signed-off-by: Zhiyong Tao Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt index 64dc4843c180..0df9befdaecc 100644 --- a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt +++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt @@ -12,6 +12,7 @@ for the Thermal Controller which holds a phandle to the AUXADC. Required properties: - compatible: Should be one of: - "mediatek,mt2701-auxadc": For MT2701 family of SoCs + - "mediatek,mt2712-auxadc": For MT2712 family of SoCs - "mediatek,mt7622-auxadc": For MT7622 family of SoCs - "mediatek,mt8173-auxadc": For MT8173 family of SoCs - reg: Address range of the AUXADC unit. -- cgit v1.2.3 From 2e931b06de97d762ef139bffbbe75e1483735734 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Thu, 21 Sep 2017 11:44:59 +0200 Subject: ARM: shmobile: remove inconsistent ; from documentation Consistently do not suffix compat string documentation with a ';' Signed-off-by: Simon Horman Acked-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/shmobile.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index 4fa984ada912..020d758fc0c5 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -69,7 +69,7 @@ Boards: compatible = "renesas,gose", "renesas,r8a7793" - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) - compatible = "renesas,h3ulcb", "renesas,r8a7795"; + compatible = "renesas,h3ulcb", "renesas,r8a7795" - Henninger compatible = "renesas,henninger", "renesas,r8a7791" - iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-RainboW-G22D) @@ -91,7 +91,7 @@ Boards: - Lager (RTP0RC7790SEB00010S) compatible = "renesas,lager", "renesas,r8a7790" - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) - compatible = "renesas,m3ulcb", "renesas,r8a7796"; + compatible = "renesas,m3ulcb", "renesas,r8a7796" - Marzen (R0P7779A00010S) compatible = "renesas,marzen", "renesas,r8a7779" - Porter (M2-LCDP) @@ -99,11 +99,11 @@ Boards: - RSKRZA1 (YR0K77210C000BE) compatible = "renesas,rskrza1", "renesas,r7s72100" - Salvator-X (RTP0RC7795SIPB0010S) - compatible = "renesas,salvator-x", "renesas,r8a7795"; + compatible = "renesas,salvator-x", "renesas,r8a7795" - Salvator-X (RTP0RC7796SIPB0011S) - compatible = "renesas,salvator-x", "renesas,r8a7796"; + compatible = "renesas,salvator-x", "renesas,r8a7796" - Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S) - compatible = "renesas,salvator-xs", "renesas,r8a7795"; + compatible = "renesas,salvator-xs", "renesas,r8a7795" - SILK (RTP0RC7794LCB00011S) compatible = "renesas,silk", "renesas,r8a7794" - SK-RZG1E (YR8A77450S000BE) -- cgit v1.2.3 From 041cd640b2f3c5607171c59d8712b503659d21f7 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Mon, 25 Sep 2017 08:12:05 -0700 Subject: cgroup: Implement cgroup2 basic CPU usage accounting In cgroup1, while cpuacct isn't actually controlling any resources, it is a separate controller due to combination of two factors - 1. enabling cpu controller has significant side effects, and 2. we have to pick one of the hierarchies to account CPU usages on. cpuacct controller is effectively used to designate a hierarchy to track CPU usages on. cgroup2's unified hierarchy removes the second reason and we can account basic CPU usages by default. While we can use cpuacct for this purpose, both its interface and implementation leave a lot to be desired - it collects and exposes two sources of truth which don't agree with each other and some of the exposed statistics don't make much sense. Also, it propagates all the way up the hierarchy on each accounting event which is unnecessary. This patch adds basic resource accounting mechanism to cgroup2's unified hierarchy and accounts CPU usages using it. * All accountings are done per-cpu and don't propagate immediately. It just bumps the per-cgroup per-cpu counters and links to the parent's updated list if not already on it. * On a read, the per-cpu counters are collected into the global ones and then propagated upwards. Only the per-cpu counters which have changed since the last read are propagated. * CPU usage stats are collected and shown in "cgroup.stat" with "cpu." prefix. Total usage is collected from scheduling events. User/sys breakdown is sourced from tick sampling and adjusted to the usage using cputime_adjust(). This keeps the accounting side hot path O(1) and per-cpu and the read side O(nr_updated_since_last_read). v2: Minor changes and documentation updates as suggested by Waiman and Roman. Signed-off-by: Tejun Heo Acked-by: Peter Zijlstra Cc: Ingo Molnar Cc: Li Zefan Cc: Johannes Weiner Cc: Waiman Long Cc: Roman Gushchin --- Documentation/cgroup-v2.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt index dc44785dc0fa..3f8216912df0 100644 --- a/Documentation/cgroup-v2.txt +++ b/Documentation/cgroup-v2.txt @@ -886,6 +886,15 @@ All cgroup core files are prefixed with "cgroup." A dying cgroup can consume system resources not exceeding limits, which were active at the moment of cgroup deletion. + cpu.usage_usec + CPU time consumed in the subtree. + + cpu.user_usec + User CPU time consumed in the subtree. + + cpu.system_usec + System CPU time consumed in the subtree. + Controllers =========== -- cgit v1.2.3 From 4702f4b23a2fc6196abacf515a959e69176da40e Mon Sep 17 00:00:00 2001 From: Fabrizio Castro Date: Mon, 25 Sep 2017 09:54:20 +0100 Subject: spi: sh-msiof: Add r8a774[35] to the compatible list Signed-off-by: Fabrizio Castro Reviewed-by: Geert Uytterhoeven Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/sh-msiof.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt index e865855726a2..bdd83959019c 100644 --- a/Documentation/devicetree/bindings/spi/sh-msiof.txt +++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt @@ -1,7 +1,9 @@ Renesas MSIOF spi controller Required properties: -- compatible : "renesas,msiof-r8a7790" (R-Car H2) +- compatible : "renesas,msiof-r8a7743" (RZ/G1M) + "renesas,msiof-r8a7745" (RZ/G1E) + "renesas,msiof-r8a7790" (R-Car H2) "renesas,msiof-r8a7791" (R-Car M2-W) "renesas,msiof-r8a7792" (R-Car V2H) "renesas,msiof-r8a7793" (R-Car M2-N) @@ -10,7 +12,7 @@ Required properties: "renesas,msiof-r8a7796" (R-Car M3-W) "renesas,msiof-sh73a0" (SH-Mobile AG5) "renesas,sh-mobile-msiof" (generic SH-Mobile compatibile device) - "renesas,rcar-gen2-msiof" (generic R-Car Gen2 compatible device) + "renesas,rcar-gen2-msiof" (generic R-Car Gen2 and RZ/G1 compatible device) "renesas,rcar-gen3-msiof" (generic R-Car Gen3 compatible device) "renesas,sh-msiof" (deprecated) -- cgit v1.2.3 From dedcf233ceb069c2c1d919ec74a913b39b5b4dd5 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 15 Jun 2017 15:19:02 -0700 Subject: dt-bindings: Document MIPS Broadcom STB power management nodes Document the different nodes required for supporting S2/S3/S5 suspend states on MIPS-based Broadcom STB SoCs. Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- .../devicetree/bindings/mips/brcm/soc.txt | 153 +++++++++++++++++++++ 1 file changed, 153 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mips/brcm/soc.txt b/Documentation/devicetree/bindings/mips/brcm/soc.txt index e4e1cd91fb1f..356c29789cf5 100644 --- a/Documentation/devicetree/bindings/mips/brcm/soc.txt +++ b/Documentation/devicetree/bindings/mips/brcm/soc.txt @@ -11,3 +11,156 @@ Required properties: The experimental -viper variants are for running Linux on the 3384's BMIPS4355 cable modem CPU instead of the BMIPS5000 application processor. + +Power management +---------------- + +For power management (particularly, S2/S3/S5 system suspend), the following SoC +components are needed: + += Always-On control block (AON CTRL) + +This hardware provides control registers for the "always-on" (even in low-power +modes) hardware, such as the Power Management State Machine (PMSM). + +Required properties: +- compatible : should be one of + "brcm,bcm7425-aon-ctrl" + "brcm,bcm7429-aon-ctrl" + "brcm,bcm7435-aon-ctrl" and + "brcm,brcmstb-aon-ctrl" +- reg : the register start and length for the AON CTRL block + +Example: + +syscon@410000 { + compatible = "brcm,bcm7425-aon-ctrl", "brcm,brcmstb-aon-ctrl"; + reg = <0x410000 0x400>; +}; + += Memory controllers + +A Broadcom STB SoC typically has a number of independent memory controllers, +each of which may have several associated hardware blocks, which are versioned +independently (control registers, DDR PHYs, etc.). One might consider +describing these controllers as a parent "memory controllers" block, which +contains N sub-nodes (one for each controller in the system), each of which is +associated with a number of hardware register resources (e.g., its PHY. + +== MEMC (MEMory Controller) + +Represents a single memory controller instance. + +Required properties: +- compatible : should contain "brcm,brcmstb-memc" and "simple-bus" +- ranges : should contain the child address in the parent address + space, must be 0 here, and the register start and length of + the entire memory controller (including all sub nodes: DDR PHY, + arbiter, etc.) +- #address-cells : must be 1 +- #size-cells : must be 1 + +Example: + + memory-controller@0 { + compatible = "brcm,brcmstb-memc", "simple-bus"; + ranges = <0x0 0x0 0xa000>; + #address-cells = <1>; + #size-cells = <1>; + + memc-arb@1000 { + ... + }; + + memc-ddr@2000 { + ... + }; + + ddr-phy@6000 { + ... + }; + }; + +Should contain subnodes for any of the following relevant hardware resources: + +== DDR PHY control + +Control registers for this memory controller's DDR PHY. + +Required properties: +- compatible : should contain one of these + "brcm,brcmstb-ddr-phy-v64.5" + "brcm,brcmstb-ddr-phy" + +- reg : the DDR PHY register range and length + +Example: + + ddr-phy@6000 { + compatible = "brcm,brcmstb-ddr-phy-v64.5"; + reg = <0x6000 0xc8>; + }; + +== DDR memory controller sequencer + +Control registers for this memory controller's DDR memory sequencer + +Required properties: +- compatible : should contain one of these + "brcm,bcm7425-memc-ddr" + "brcm,bcm7429-memc-ddr" + "brcm,bcm7435-memc-ddr" and + "brcm,brcmstb-memc-ddr" + +- reg : the DDR sequencer register range and length + +Example: + + memc-ddr@2000 { + compatible = "brcm,bcm7425-memc-ddr", "brcm,brcmstb-memc-ddr"; + reg = <0x2000 0x300>; + }; + +== MEMC Arbiter + +The memory controller arbiter is responsible for memory clients allocation +(bandwidth, priorities etc.) and needs to have its contents restored during +deep sleep states (S3). + +Required properties: + +- compatible : should contain one of these + "brcm,brcmstb-memc-arb-v10.0.0.0" + "brcm,brcmstb-memc-arb" + +- reg : the DDR Arbiter register range and length + +Example: + + memc-arb@1000 { + compatible = "brcm,brcmstb-memc-arb-v10.0.0.0"; + reg = <0x1000 0x248>; + }; + +== Timers + +The Broadcom STB chips contain a timer block with several general purpose +timers that can be used. + +Required properties: + +- compatible : should contain one of: + "brcm,bcm7425-timers" + "brcm,bcm7429-timers" + "brcm,bcm7435-timers and + "brcm,brcmstb-timers" +- reg : the timers register range +- interrupts : the interrupt line for this timer block + +Example: + + timers: timer@4067c0 { + compatible = "brcm,bcm7425-timers", "brcm,brcmstb-timers"; + reg = <0x4067c0 0x40>; + interrupts = <&periph_intc 19>; + }; -- cgit v1.2.3 From eb35279dd7c7834d6320edf24e1b9786d31e4899 Mon Sep 17 00:00:00 2001 From: Matt Ranostay Date: Wed, 24 May 2017 22:52:29 -0700 Subject: iio: proximity: as3935: noise detection + threshold changes Most applications are too noisy to allow the default noise and watchdog settings, and thus need to be configurable via DT properties. Also default settings to POR defaults on a reset, and register distuber interrupts as noise since it prevents proper usage. Cc: devicetree@vger.kernel.org Signed-off-by: Matt Ranostay Acked-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 | 8 ++++++++ Documentation/devicetree/bindings/iio/proximity/as3935.txt | 5 +++++ 2 files changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 index 33e96f740639..147d4e8a1403 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 +++ b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 @@ -14,3 +14,11 @@ Description: Show or set the gain boost of the amp, from 0-31 range. 18 = indoors (default) 14 = outdoors + +What /sys/bus/iio/devices/iio:deviceX/noise_level_tripped +Date: May 2017 +KernelVersion: 4.13 +Contact: Matt Ranostay +Description: + When 1 the noise level is over the trip level and not reporting + valid data diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt index 38d74314b7ab..b6c1afa6f02d 100644 --- a/Documentation/devicetree/bindings/iio/proximity/as3935.txt +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt @@ -16,6 +16,10 @@ Optional properties: - ams,tuning-capacitor-pf: Calibration tuning capacitor stepping value 0 - 120pF. This will require using the calibration data from the manufacturer. + - ams,nflwdth: Set the noise and watchdog threshold register on + startup. This will need to set according to the noise from the + MCU board, and possibly the local environment. Refer to the + datasheet for the threshold settings. Example: @@ -27,4 +31,5 @@ as3935@0 { interrupt-parent = <&gpio1>; interrupts = <16 1>; ams,tuning-capacitor-pf = <80>; + ams,nflwdth = <0x44>; }; -- cgit v1.2.3 From 8caea502367056881e5209ca55a7a01775c9a1cd Mon Sep 17 00:00:00 2001 From: Palmer Dabbelt Date: Fri, 8 Sep 2017 17:07:44 -0700 Subject: dt-bindings: RISC-V CPU Bindings This patch adds device tree bindings for RISC-V CPUs, patterned after the ARM device tree CPU bindings. Signed-off-by: Palmer Dabbelt --- Documentation/devicetree/bindings/riscv/cpus.txt | 162 +++++++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 Documentation/devicetree/bindings/riscv/cpus.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/riscv/cpus.txt b/Documentation/devicetree/bindings/riscv/cpus.txt new file mode 100644 index 000000000000..adf7b7af5dc3 --- /dev/null +++ b/Documentation/devicetree/bindings/riscv/cpus.txt @@ -0,0 +1,162 @@ +=================== +RISC-V CPU Bindings +=================== + +The device tree allows to describe the layout of CPUs in a system through +the "cpus" node, which in turn contains a number of subnodes (ie "cpu") +defining properties for every cpu. + +Bindings for CPU nodes follow the Devicetree Specification, available from: + +https://www.devicetree.org/specifications/ + +with updates for 32-bit and 64-bit RISC-V systems provided in this document. + +=========== +Terminology +=========== + +This document uses some terminology common to the RISC-V community that is not +widely used, the definitions of which are listed here: + +* hart: A hardware execution context, which contains all the state mandated by + the RISC-V ISA: a PC and some registers. This terminology is designed to + disambiguate software's view of execution contexts from any particular + microarchitectural implementation strategy. For example, my Intel laptop is + described as having one socket with two cores, each of which has two hyper + threads. Therefore this system has four harts. + +===================================== +cpus and cpu node bindings definition +===================================== + +The RISC-V architecture, in accordance with the Devicetree Specification, +requires the cpus and cpu nodes to be present and contain the properties +described below. + +- cpus node + + Description: Container of cpu nodes + + The node name must be "cpus". + + A cpus node must define the following properties: + + - #address-cells + Usage: required + Value type: + Definition: must be set to 1 + - #size-cells + Usage: required + Value type: + Definition: must be set to 0 + +- cpu node + + Description: Describes a hart context + + PROPERTIES + + - device_type + Usage: required + Value type: + Definition: must be "cpu" + - reg + Usage: required + Value type: + Definition: The hart ID of this CPU node + - compatible: + Usage: required + Value type: + Definition: must contain "riscv", may contain one of + "sifive,rocket0" + - mmu-type: + Usage: optional + Value type: + Definition: Specifies the CPU's MMU type. Possible values are + "riscv,sv32" + "riscv,sv39" + "riscv,sv48" + - riscv,isa: + Usage: required + Value type: + Definition: Contains the RISC-V ISA string of this hart. These + ISA strings are defined by the RISC-V ISA manual. + +Example: SiFive Freedom U540G Development Kit +--------------------------------------------- + +This system contains two harts: a hart marked as disabled that's used for +low-level system tasks and should be ignored by Linux, and a second hart that +Linux is allowed to run on. + + cpus { + #address-cells = <1>; + #size-cells = <0>; + timebase-frequency = <1000000>; + cpu@0 { + clock-frequency = <1600000000>; + compatible = "sifive,rocket0", "riscv"; + device_type = "cpu"; + i-cache-block-size = <64>; + i-cache-sets = <128>; + i-cache-size = <16384>; + next-level-cache = <&L15 &L0>; + reg = <0>; + riscv,isa = "rv64imac"; + status = "disabled"; + L10: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + cpu@1 { + clock-frequency = <1600000000>; + compatible = "sifive,rocket0", "riscv"; + d-cache-block-size = <64>; + d-cache-sets = <64>; + d-cache-size = <32768>; + d-tlb-sets = <1>; + d-tlb-size = <32>; + device_type = "cpu"; + i-cache-block-size = <64>; + i-cache-sets = <64>; + i-cache-size = <32768>; + i-tlb-sets = <1>; + i-tlb-size = <32>; + mmu-type = "riscv,sv39"; + next-level-cache = <&L15 &L0>; + reg = <1>; + riscv,isa = "rv64imafdc"; + status = "okay"; + tlb-split; + L13: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + }; + +Example: Spike ISA Simulator with 1 Hart +---------------------------------------- + +This device tree matches the Spike ISA golden model as run with `spike -p1`. + + cpus { + cpu@0 { + device_type = "cpu"; + reg = <0x00000000>; + status = "okay"; + compatible = "riscv"; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv48"; + clock-frequency = <0x3b9aca00>; + interrupt-controller { + #interrupt-cells = <0x00000001>; + interrupt-controller; + compatible = "riscv,cpu-intc"; + } + } + } -- cgit v1.2.3 From 45b611c896faf29e235d9de6c7a8ceb3393c2b9c Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Fri, 15 Sep 2017 04:00:02 +0200 Subject: rtc: rv3029: fix vendor string The vendor string for Microcrystal is microcrystal. Acked-by: Rob Herring Signed-off-by: Alexandre Belloni --- Documentation/devicetree/bindings/trivial-devices.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt index af284fbd4d23..aae37352c574 100644 --- a/Documentation/devicetree/bindings/trivial-devices.txt +++ b/Documentation/devicetree/bindings/trivial-devices.txt @@ -72,7 +72,6 @@ isil,isl29030 Intersil ISL29030 Ambient Light and Proximity Sensor maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface -mc,rv3029c2 Real Time Clock Module with I2C-Bus mcube,mc3230 mCube 3-axis 8-bit digital accelerometer memsic,mxc6225 MEMSIC 2-axis 8-bit digital accelerometer microchip,mcp4531-502 Microchip 7-bit Single I2C Digital Potentiometer (5k) @@ -141,6 +140,7 @@ microchip,mcp4662-503 Microchip 8-bit Dual I2C Digital Potentiometer with NV Mem microchip,mcp4662-104 Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (100k) microchip,tc654 PWM Fan Speed Controller With Fan Fault Detection microchip,tc655 PWM Fan Speed Controller With Fan Fault Detection +microcrystal,rv3029 Real Time Clock Module with I2C-Bus miramems,da226 MiraMEMS DA226 2-axis 14-bit digital accelerometer miramems,da280 MiraMEMS DA280 3-axis 14-bit digital accelerometer miramems,da311 MiraMEMS DA311 3-axis 12-bit digital accelerometer -- cgit v1.2.3 From 98bfa34462fb6af70b845d28561072f80bacdb9b Mon Sep 17 00:00:00 2001 From: Pavel Machek Date: Sat, 16 Sep 2017 13:48:37 +0200 Subject: Documentation: fix little inconsistencies Fix little inconsistencies in Documentation: make case and spacing match surrounding text. Signed-off-by: Pavel Machek Reviewed-by: Darrick J. Wong Signed-off-by: Jonathan Corbet --- Documentation/filesystems/ext4.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 5a8f7f4d2bca..75236c0c2ac2 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -94,10 +94,10 @@ Note: More extensive information for getting started with ext4 can be * ability to pack bitmaps and inode tables into larger virtual groups via the flex_bg feature * large file support -* Inode allocation using large virtual block groups via flex_bg +* inode allocation using large virtual block groups via flex_bg * delayed allocation * large block (up to pagesize) support -* efficient new ordered mode in JBD2 and ext4(avoid using buffer head to force +* efficient new ordered mode in JBD2 and ext4 (avoid using buffer head to force the ordering) [1] Filesystems with a block size of 1k may see a limit imposed by the @@ -105,7 +105,7 @@ directory hash tree having a maximum depth of two. 2.2 Candidate features for future inclusion -* Online defrag (patches available but not well tested) +* online defrag (patches available but not well tested) * reduced mke2fs time via lazy itable initialization in conjunction with the uninit_bg feature (capability to do this is available in e2fsprogs but a kernel thread to do lazy zeroing of unused inode table blocks @@ -602,7 +602,7 @@ Table of Ext4 specific ioctls bitmaps and inode table, the userspace tool thus just passes the new number of blocks. -EXT4_IOC_SWAP_BOOT Swap i_blocks and associated attributes + EXT4_IOC_SWAP_BOOT Swap i_blocks and associated attributes (like i_blocks, i_size, i_flags, ...) from the specified inode with inode EXT4_BOOT_LOADER_INO (#5). This is typically -- cgit v1.2.3 From 416c7517359b8812c8bcddc31348934b901c3cdc Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 17 Sep 2017 15:19:10 -0700 Subject: Documentation: kernel-api: drop "Data Types" section In the kernel-api chapter, the section for Data Types only contains "Doubly Linked Lists" and all of the function interfaces for list management. There are no other data types in this section, so collapse this section into "List Management Functions". Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Corbet --- Documentation/core-api/kernel-api.rst | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 8282099e0cbf..e557509574a0 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -2,11 +2,9 @@ The Linux Kernel API ==================== -Data Types -========== -Doubly Linked Lists -------------------- +List Management Functions +========================= .. kernel-doc:: include/linux/list.h :internal: -- cgit v1.2.3 From 404376af788a76cca760efdc05f26fd73bd94b17 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 17 Sep 2017 19:07:10 -0700 Subject: Documentation: kernel-api: add bitmap operations from linux/bitmap.h Add to kernel-api Bitmap Operations section. Fix kernel-doc nitpicks in . Signed-off-by: Randy Dunlap Acked-by: Yury Norov Signed-off-by: Jonathan Corbet --- Documentation/core-api/kernel-api.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index e557509574a0..f37c73faa5b7 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -59,6 +59,9 @@ Bitmap Operations .. kernel-doc:: lib/bitmap.c :internal: +.. kernel-doc:: include/linux/bitmap.h + :internal: + Command-line Parsing -------------------- -- cgit v1.2.3 From ac0a314caed1827f4ef5d7145eb609147b48b45d Mon Sep 17 00:00:00 2001 From: Daniel Xu Date: Mon, 18 Sep 2017 22:21:25 -0700 Subject: console: Update to reflect new default value The default value was changed from 10 minutes to disabled in commit a4199f5eb8096d6. Signed-off-by: Daniel Xu Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 05496622b4ef..fcaa8558ed7e 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -641,8 +641,8 @@ For now, only VisioBraille is supported. consoleblank= [KNL] The console blank (screen saver) timeout in - seconds. Defaults to 10*60 = 10mins. A value of 0 - disables the blank timer. + seconds. A value of 0 disables the blank timer. + Defaults to 0. coredump_filter= [KNL] Change the default value for -- cgit v1.2.3 From d19b3e32375bd21b5d89cc484dfc56cbd9b7fee4 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 25 Sep 2017 18:36:19 +0900 Subject: Documentation/process: fix the canonical patch format description There shouldn't be a blank line at the beginning, if there is no optional in-body "From" line. There must be a blank line between the body of the explanation and the beginning of the S-o-b lines. Signed-off-by: Junio C Hamano Signed-off-by: Jonathan Corbet --- Documentation/process/submitting-patches.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 733478ade91b..1ef19d3a3eee 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -621,14 +621,14 @@ The canonical patch subject line is:: The canonical patch message body contains the following: - - A ``from`` line specifying the patch author (only needed if the person - sending the patch is not the author). - - - An empty line. + - A ``from`` line specifying the patch author, followed by an empty + line (only needed if the person sending the patch is not the author). - The body of the explanation, line wrapped at 75 columns, which will be copied to the permanent changelog to describe this patch. + - An empty line. + - The ``Signed-off-by:`` lines, described above, which will also go in the changelog. -- cgit v1.2.3 From d4306db189d04886e07751f682495aeae61a4c4f Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 25 Sep 2017 18:36:20 +0900 Subject: Documentation/process: phrasofix Devils in the details are found only when the high level design is refined and gets more detailed, and the appropriate phrase to use to describe this is "problems are revealed", not "problems are reviewed". Reviews may reveal these problems, though ;-) Signed-off-by: Junio C Hamano Signed-off-by: Jonathan Corbet --- Documentation/process/3.Early-stage.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/3.Early-stage.rst b/Documentation/process/3.Early-stage.rst index af2c0af931d6..be00716071d4 100644 --- a/Documentation/process/3.Early-stage.rst +++ b/Documentation/process/3.Early-stage.rst @@ -178,7 +178,7 @@ matter is (1) kernel developers tend to be busy, (2) there is no shortage of people with grand plans and little code (or even prospect of code) to back them up, and (3) nobody is obligated to review or comment on ideas posted by others. Beyond that, high-level designs often hide problems -which are only reviewed when somebody actually tries to implement those +which are only revealed when somebody actually tries to implement those designs; for that reason, kernel developers would rather see the code. If a request-for-comments posting yields little in the way of comments, do -- cgit v1.2.3 From 44e9f099367716dde33618b7d5d25c3123437ba6 Mon Sep 17 00:00:00 2001 From: stephen lu Date: Tue, 29 Aug 2017 10:42:24 +0800 Subject: docs: highres: fix broken urls Some urls is invalid. I find alternative urls. Signed-off-by: stephen lu Signed-off-by: Jonathan Corbet --- Documentation/timers/highres.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/timers/highres.txt b/Documentation/timers/highres.txt index e8789976e77c..9d88f67781c2 100644 --- a/Documentation/timers/highres.txt +++ b/Documentation/timers/highres.txt @@ -4,10 +4,10 @@ High resolution timers and dynamic ticks design notes Further information can be found in the paper of the OLS 2006 talk "hrtimers and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can be found on the OLS website: -http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf +https://www.kernel.org/doc/ols/2006/ols2006v1-pages-333-346.pdf The slides to this talk are available from: -http://tglx.de/projects/hrtimers/ols2006-hrtimers.pdf +http://www.cs.columbia.edu/~nahum/w6998/papers/ols2006-hrtimers-slides.pdf The slides contain five figures (pages 2, 15, 18, 20, 22), which illustrate the changes in the time(r) related Linux subsystems. Figure #1 (p. 2) shows the -- cgit v1.2.3 From 8a29896a6e31c7aa2ca3b50d8aefe05f280b0b7e Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Fri, 8 Sep 2017 16:35:55 -0700 Subject: docs: clean up and add rest of CRC functions to kernel-api.rst Add the rest of the CRC library functions to kernel-api. - try to clarify crc32() by adding '@' to a function parameter - reorder kernel-api CRC functions to be less random - add more CRC functions to kernel-api - correct the function parameter names in several places Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Corbet --- Documentation/core-api/kernel-api.rst | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index f37c73faa5b7..657a89a219b2 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -71,13 +71,16 @@ Command-line Parsing CRC Functions ------------- +.. kernel-doc:: lib/crc4.c + :export: + .. kernel-doc:: lib/crc7.c :export: -.. kernel-doc:: lib/crc16.c +.. kernel-doc:: lib/crc8.c :export: -.. kernel-doc:: lib/crc-itu-t.c +.. kernel-doc:: lib/crc16.c :export: .. kernel-doc:: lib/crc32.c @@ -85,6 +88,9 @@ CRC Functions .. kernel-doc:: lib/crc-ccitt.c :export: +.. kernel-doc:: lib/crc-itu-t.c + :export: + idr/ida Functions ----------------- -- cgit v1.2.3 From d9c8022475f9144a66e03df5d4818a3377df8d97 Mon Sep 17 00:00:00 2001 From: Haneen Mohammed Date: Tue, 26 Sep 2017 15:08:35 -0600 Subject: drm/doc: Remove todo item about "This is gross" comment This patch remove the todo item "Use new IDR deletion interface to clean up drm_gem_handle_delete()" after it has been resolved with the commit "drm: Remove obsolete "This is gross" comment". Signed-off-by: Haneen Mohammed Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20170926210835.GA4622@Haneen --- Documentation/gpu/todo.rst | 6 ------ 1 file changed, 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index de9512afd611..5f4870289135 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -184,12 +184,6 @@ Contact: Sean Paul, Maintainer of the driver you plan to convert Core refactorings ================= -Use new IDR deletion interface to clean up drm_gem_handle_delete() ------------------------------------------------------------------- - -See the "This is gross" comment -- apparently the IDR system now can return an -error code instead of oopsing. - Clean up the DRM header mess ---------------------------- -- cgit v1.2.3 From 165d3ad884df4b30c3564a478b457b499345886f Mon Sep 17 00:00:00 2001 From: Tony Luck Date: Mon, 25 Sep 2017 16:39:38 -0700 Subject: x86/intel_rdt: Add documentation for "info/last_cmd_status" New file in the "info" directory helps diagnose what went wrong when using the /sys/fs/resctrl file system Signed-off-by: Tony Luck Signed-off-by: Thomas Gleixner Cc: Fenghua Yu Cc: Steven Rostedt Cc: Vikas Shivappa Cc: Boris Petkov Cc: Reinette Chatre Link: https://lkml.kernel.org/r/387e78e444582403c2454479e576caf5721a363f.1506382469.git.tony.luck@intel.com --- Documentation/x86/intel_rdt_ui.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/x86/intel_rdt_ui.txt b/Documentation/x86/intel_rdt_ui.txt index 4d8848e4e224..6851854cf69d 100644 --- a/Documentation/x86/intel_rdt_ui.txt +++ b/Documentation/x86/intel_rdt_ui.txt @@ -87,6 +87,17 @@ with the following files: bytes) at which a previously used LLC_occupancy counter can be considered for re-use. +Finally, in the top level of the "info" directory there is a file +named "last_cmd_status". This is reset with every "command" issued +via the file system (making new directories or writing to any of the +control files). If the command was successful, it will read as "ok". +If the command failed, it will provide more information that can be +conveyed in the error returns from file operations. E.g. + + # echo L3:0=f7 > schemata + bash: echo: write error: Invalid argument + # cat info/last_cmd_status + mask f7 has non-consecutive 1-bits Resource alloc and monitor groups --------------------------------- -- cgit v1.2.3 From da6789756d4e7755bc389389770335927fa96ad0 Mon Sep 17 00:00:00 2001 From: Pierre-Yves MORDRET Date: Fri, 22 Sep 2017 09:31:29 +0200 Subject: dt-bindings: Document the STM32 DMAMUX bindings This patch adds the documentation of device tree bindings for the STM32 DMAMUX. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET Acked-by: Rob Herring Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/stm32-dmamux.txt | 84 ++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/stm32-dmamux.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/stm32-dmamux.txt b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt new file mode 100644 index 000000000000..1b893b235507 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt @@ -0,0 +1,84 @@ +STM32 DMA MUX (DMA request router) + +Required properties: +- compatible: "st,stm32h7-dmamux" +- reg: Memory map for accessing module +- #dma-cells: Should be set to <3>. + First parameter is request line number. + Second is DMA channel configuration + Third is Fifo threshold + For more details about the three cells, please see + stm32-dma.txt documentation binding file +- dma-masters: Phandle pointing to the DMA controllers. + Several controllers are allowed. Only "st,stm32-dma" DMA + compatible are supported. + +Optional properties: +- dma-channels : Number of DMA requests supported. +- dma-requests : Number of DMAMUX requests supported. +- resets: Reference to a reset controller asserting the DMA controller +- clocks: Input clock of the DMAMUX instance. + +Example: + +/* DMA controller 1 */ +dma1: dma-controller@40020000 { + compatible = "st,stm32-dma"; + reg = <0x40020000 0x400>; + interrupts = <11>, + <12>, + <13>, + <14>, + <15>, + <16>, + <17>, + <47>; + clocks = <&timer_clk>; + #dma-cells = <4>; + st,mem2mem; + resets = <&rcc 150>; + dma-channels = <8>; + dma-requests = <8>; +}; + +/* DMA controller 1 */ +dma2: dma@40020400 { + compatible = "st,stm32-dma"; + reg = <0x40020400 0x400>; + interrupts = <56>, + <57>, + <58>, + <59>, + <60>, + <68>, + <69>, + <70>; + clocks = <&timer_clk>; + #dma-cells = <4>; + st,mem2mem; + resets = <&rcc 150>; + dma-channels = <8>; + dma-requests = <8>; +}; + +/* DMA mux */ +dmamux1: dma-router@40020800 { + compatible = "st,stm32h7-dmamux"; + reg = <0x40020800 0x3c>; + #dma-cells = <3>; + dma-requests = <128>; + dma-channels = <16>; + dma-masters = <&dma1 &dma2>; + clocks = <&timer_clk>; +}; + +/* DMA client */ +usart1: serial@40011000 { + compatible = "st,stm32-usart", "st,stm32-uart"; + reg = <0x40011000 0x400>; + interrupts = <37>; + clocks = <&timer_clk>; + dmas = <&dmamux1 41 0x414 0>, + <&dmamux1 42 0x414 0>; + dma-names = "rx", "tx"; +}; -- cgit v1.2.3 From 6e10d19b145747c9667d40b7cf079b42d33c4c28 Mon Sep 17 00:00:00 2001 From: Pierre-Yves MORDRET Date: Fri, 22 Sep 2017 09:31:31 +0200 Subject: dt-bindings: stm32-dma: add a property to handle STM32 DMAMUX STM32 DMA controller has to exposed its number of request line to be addressed via STM32 DMAMUX. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET Acked-by: Rob Herring Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/stm32-dma.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt b/Documentation/devicetree/bindings/dma/stm32-dma.txt index 4408af693d0c..77542e1c7bde 100644 --- a/Documentation/devicetree/bindings/dma/stm32-dma.txt +++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt @@ -13,6 +13,7 @@ Required properties: - #dma-cells : Must be <4>. See DMA client paragraph for more details. Optional properties: +- dma-requests : Number of DMA requests supported. - resets: Reference to a reset controller asserting the DMA controller - st,mem2mem: boolean; if defined, it indicates that the controller supports memory-to-memory transfer @@ -34,12 +35,13 @@ Example: #dma-cells = <4>; st,mem2mem; resets = <&rcc 150>; + dma-requests = <8>; }; * DMA client DMA clients connected to the STM32 DMA controller must use the format -described in the dma.txt file, using a five-cell specifier for each +described in the dma.txt file, using a four-cell specifier for each channel: a phandle to the DMA controller plus the following four integer cells: 1. The channel id -- cgit v1.2.3 From 9949b355dc1c259b4ed3c092b899b7e9cf166236 Mon Sep 17 00:00:00 2001 From: Meghana Madhyastha Date: Wed, 27 Sep 2017 16:21:23 +0530 Subject: drm/Documentation: Refine TODO for backlight helpers in tinydrm Add a summary which resulted from discussions on what should be done to refactor backlight helpers in tinydrm so that they can be used in other drivers as well. Signed-off-by: Meghana Madhyastha Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20170927105116.GA30391@meghana-HP-Pavilion-Notebook --- Documentation/gpu/todo.rst | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 5f4870289135..92ee2f982572 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -351,7 +351,16 @@ those drivers as simple as possible, so lots of room for refactoring: - backlight helpers, probably best to put them into a new drm_backlight.c. This is because drivers/video is de-facto unmaintained. We could also move drivers/video/backlight to drivers/gpu/backlight and take it all - over within drm-misc, but that's more work. + over within drm-misc, but that's more work. Backlight helpers require a fair + bit of reworking and refactoring. A simple example is the enabling of a backlight. + Tinydrm has helpers for this. It would be good if other drivers can also use the + helper. However, there are various cases we need to consider i.e different + drivers seem to have different ways of enabling/disabling a backlight. + We also need to consider the backlight drivers (like gpio_backlight). The situation + is further complicated by the fact that the backlight is tied to fbdev + via fb_notifier_callback() which has complicated logic. For further details, refer + to the following discussion thread: + https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA - spi helpers, probably best put into spi core/helper code. Thierry said the spi maintainer is fast&reactive, so shouldn't be a big issue. -- cgit v1.2.3 From 1c9f98d1bfbd0696442f97fa7d43a727e1e16568 Mon Sep 17 00:00:00 2001 From: Corey Minyard Date: Fri, 18 Aug 2017 17:32:03 -0500 Subject: ipmi: Make IPMI panic strings always available They were set by config items, but people complained that they were never turned on. So have them always available and enabled by a module parameter. Signed-off-by: Corey Minyard --- Documentation/IPMI.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt index aa77a25a0940..5ef1047e2e66 100644 --- a/Documentation/IPMI.txt +++ b/Documentation/IPMI.txt @@ -81,7 +81,9 @@ If you want the driver to put an event into the event log on a panic, enable the 'Generate a panic event to all BMCs on a panic' option. If you want the whole panic string put into the event log using OEM events, enable the 'Generate OEM events containing the panic string' -option. +option. You can also enable these dynamically by setting the module +parameter named "panic_op" in the ipmi_msghandler module to "event" +or "string". Setting that parameter to "none" disables this function. Basic Design ------------ -- cgit v1.2.3 From 8aba2333904f9b1c1ea038df261bf7ae8fefb98e Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 28 Sep 2017 02:08:43 +0200 Subject: cpufreq: docs: Drop intel-pstate.txt from index.txt Commit 33fc30b47098 (cpufreq: intel_pstate: Document the current behavior and user interface) dropped the intel-pstate.txt file from Documentation/cpu-freq/, but it did not update the index.txt file in there accordingly, so do that now. Fixes: 33fc30b47098 (cpufreq: intel_pstate: Document the current behavior and user interface) Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-freq/index.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/index.txt b/Documentation/cpu-freq/index.txt index 03a7cee6ac73..c15e75386a05 100644 --- a/Documentation/cpu-freq/index.txt +++ b/Documentation/cpu-freq/index.txt @@ -32,8 +32,6 @@ cpufreq-stats.txt - General description of sysfs cpufreq stats. index.txt - File index, Mailing list and Links (this document) -intel-pstate.txt - Intel pstate cpufreq driver specific file. - pcc-cpufreq.txt - PCC cpufreq driver specific file. -- cgit v1.2.3 From d25d41827fee2b489518eee99ef156b005c0c01e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Br=C3=BCns?= Date: Thu, 28 Sep 2017 03:49:28 +0200 Subject: arm: allwinner: Correct unit name in devicetree binding example MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Unit-names must not start with a leading 0. Signed-off-by: Stefan Brüns Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/dma/sun6i-dma.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt b/Documentation/devicetree/bindings/dma/sun6i-dma.txt index 98fbe1a5c6dd..b32e3bfdb88a 100644 --- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt +++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt @@ -18,7 +18,7 @@ Required properties: - #dma-cells : Should be 1, a single cell holding a line request number Example: - dma: dma-controller@01c02000 { + dma: dma-controller@1c02000 { compatible = "allwinner,sun6i-a31-dma"; reg = <0x01c02000 0x1000>; interrupts = <0 50 4>; -- cgit v1.2.3 From 0a26a45d1a2338326a369c9544dc5141a6e75106 Mon Sep 17 00:00:00 2001 From: Harry Wentland Date: Thu, 28 Sep 2017 11:53:19 -0400 Subject: drm/doc: Reference AMD DC todos Signed-off-by: Harry Wentland Signed-off-by: Alex Deucher --- Documentation/gpu/todo.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 22af55d06ab8..4a837cfb6a39 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -390,5 +390,15 @@ those drivers as simple as possible, so lots of room for refactoring: Contact: Noralf Trønnes, Daniel Vetter +AMD DC Display Driver +--------------------- + +AMD DC is the display driver for AMD devices starting with Vega. There has been +a bunch of progress cleaning it up but there's still plenty of work to be done. + +See drivers/gpu/drm/amd/display/TODO for tasks. + +Contact: Harry Wentland, Alex Deucher + Outside DRM =========== -- cgit v1.2.3 From 0d5936344f30aba0f6ddb92b030cb6a05168efe6 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Mon, 25 Sep 2017 09:00:19 -0700 Subject: sched: Implement interface for cgroup unified hierarchy There are a couple interface issues which can be addressed in cgroup2 interface. * Stats from cpuacct being reported separately from the cpu stats. * Use of different time units. Writable control knobs use microseconds, some stat fields use nanoseconds while other cpuacct stat fields use centiseconds. * Control knobs which can't be used in the root cgroup still show up in the root. * Control knob names and semantics aren't consistent with other controllers. This patchset implements cpu controller's interface on cgroup2 which adheres to the controller file conventions described in Documentation/cgroups/cgroup-v2.txt. Overall, the following changes are made. * cpuacct is implictly enabled and disabled by cpu and its information is reported through "cpu.stat" which now uses microseconds for all time durations. All time duration fields now have "_usec" appended to them for clarity. Note that cpuacct.usage_percpu is currently not included in "cpu.stat". If this information is actually called for, it will be added later. * "cpu.shares" is replaced with "cpu.weight" and operates on the standard scale defined by CGROUP_WEIGHT_MIN/DFL/MAX (1, 100, 10000). The weight is scaled to scheduler weight so that 100 maps to 1024 and the ratio relationship is preserved - if weight is W and its scaled value is S, W / 100 == S / 1024. While the mapped range is a bit smaller than the orignal scheduler weight range, the dead zones on both sides are relatively small and covers wider range than the nice value mappings. This file doesn't make sense in the root cgroup and isn't created on root. * "cpu.weight.nice" is added. When read, it reads back the nice value which is closest to the current "cpu.weight". When written, it sets "cpu.weight" to the weight value which matches the nice value. This makes it easy to configure cgroups when they're competing against threads in threaded subtrees. * "cpu.cfs_quota_us" and "cpu.cfs_period_us" are replaced by "cpu.max" which contains both quota and period. v4: - Use cgroup2 basic usage stat as the information source instead of cpuacct. v3: - Added "cpu.weight.nice" to allow using nice values when configuring the weight. The feature is requested by PeterZ. - Merge the patch to enable threaded support on cpu and cpuacct. - Dropped the bits about getting rid of cpuacct from patch description as there is a pretty strong case for making cpuacct an implicit controller so that basic cpu usage stats are always available. - Documentation updated accordingly. "cpu.rt.max" section is dropped for now. v2: - cpu_stats_show() was incorrectly using CONFIG_FAIR_GROUP_SCHED for CFS bandwidth stats and also using raw division for u64. Use CONFIG_CFS_BANDWITH and do_div() instead. "cpu.rt.max" is not included yet. Signed-off-by: Tejun Heo Acked-by: Peter Zijlstra (Intel) Cc: Ingo Molnar Cc: Li Zefan Cc: Johannes Weiner --- Documentation/cgroup-v2.txt | 36 ++++++++++++------------------------ 1 file changed, 12 insertions(+), 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt index 3f8216912df0..0bbdc720dd7c 100644 --- a/Documentation/cgroup-v2.txt +++ b/Documentation/cgroup-v2.txt @@ -902,10 +902,6 @@ Controllers CPU --- -.. note:: - - The interface for the cpu controller hasn't been merged yet - The "cpu" controllers regulates distribution of CPU cycles. This controller implements weight and absolute bandwidth limit models for normal scheduling policy and absolute bandwidth allocation model for @@ -935,6 +931,18 @@ All time durations are in microseconds. The weight in the range [1, 10000]. + cpu.weight.nice + A read-write single value file which exists on non-root + cgroups. The default is "0". + + The nice value is in the range [-20, 19]. + + This interface file is an alternative interface for + "cpu.weight" and allows reading and setting weight using the + same values used by nice(2). Because the range is smaller and + granularity is coarser for the nice values, the read value is + the closest approximation of the current weight. + cpu.max A read-write two value file which exists on non-root cgroups. The default is "max 100000". @@ -947,26 +955,6 @@ All time durations are in microseconds. $PERIOD duration. "max" for $MAX indicates no limit. If only one number is written, $MAX is updated. - cpu.rt.max - .. note:: - - The semantics of this file is still under discussion and the - interface hasn't been merged yet - - A read-write two value file which exists on all cgroups. - The default is "0 100000". - - The maximum realtime runtime allocation. Over-committing - configurations are disallowed and process migrations are - rejected if not enough bandwidth is available. It's in the - following format:: - - $MAX $PERIOD - - which indicates that the group may consume upto $MAX in each - $PERIOD duration. If only one number is written, $MAX is - updated. - Memory ------ -- cgit v1.2.3 From 8635d6b3afe68cdde2f646c2a3bbd8149c031e8c Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Sun, 1 Oct 2017 17:17:26 +0200 Subject: dt-bindings: hsi: add omap4 hsi controller bindings Update omap-ssi binding document to also cover the HSI compliant module from OMAP4. Signed-off-by: Tony Lindgren Acked-by: Rob Herring [dropped the omap.dtsi update and updated patch description accordingly] Signed-off-by: Sebastian Reichel --- Documentation/devicetree/bindings/hsi/omap-ssi.txt | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt b/Documentation/devicetree/bindings/hsi/omap-ssi.txt index b8eca3c7810d..955e335e7e56 100644 --- a/Documentation/devicetree/bindings/hsi/omap-ssi.txt +++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt @@ -1,10 +1,12 @@ OMAP SSI controller bindings -OMAP Synchronous Serial Interface (SSI) controller implements a legacy -variant of MIPI's High Speed Synchronous Serial Interface (HSI). +OMAP3's Synchronous Serial Interface (SSI) controller implements a +legacy variant of MIPI's High Speed Synchronous Serial Interface (HSI), +while the controller found inside OMAP4 is supposed to be fully compliant +with the HSI standard. Required properties: -- compatible: Should include "ti,omap3-ssi". +- compatible: Should include "ti,omap3-ssi" or "ti,omap4-hsi" - reg-names: Contains the values "sys" and "gdd" (in this order). - reg: Contains a matching register specifier for each entry in reg-names. @@ -27,6 +29,7 @@ Each port is represented as a sub-node of the ti,omap3-ssi device. Required Port sub-node properties: - compatible: Should be set to the following value ti,omap3-ssi-port (applicable to OMAP34xx devices) + ti,omap4-hsi-port (applicable to OMAP44xx devices) - reg-names: Contains the values "tx" and "rx" (in this order). - reg: Contains a matching register specifier for each entry in reg-names. @@ -38,6 +41,10 @@ Required Port sub-node properties: property. If it's missing the port will not be enabled. +Optional properties: +- ti,hwmods: Shall contain TI interconnect module name if needed + by the SoC + Example for Nokia N900: ssi-controller@48058000 { -- cgit v1.2.3 From 4792ea04bcd03b8ccfd1ae336c5deba52dd9edc9 Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Fri, 29 Sep 2017 14:27:39 +0200 Subject: net: mvpp2: Fix clock resource by adding an optional bus clock On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock is optional because not all the SoCs need them but at least for Armada 7K/8K it is actually mandatory. The binding documentation is updating accordingly. Signed-off-by: Gregory CLEMENT Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/marvell-pp2.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt b/Documentation/devicetree/bindings/net/marvell-pp2.txt index 7e2dad08a12e..1814fa13f6ab 100644 --- a/Documentation/devicetree/bindings/net/marvell-pp2.txt +++ b/Documentation/devicetree/bindings/net/marvell-pp2.txt @@ -21,8 +21,9 @@ Required properties: - main controller clock (for both armada-375-pp2 and armada-7k-pp2) - GOP clock (for both armada-375-pp2 and armada-7k-pp2) - MG clock (only for armada-7k-pp2) -- clock-names: names of used clocks, must be "pp_clk", "gop_clk" and - "mg_clk" (the latter only for armada-7k-pp2). + - AXI clock (only for armada-7k-pp2) +- clock-names: names of used clocks, must be "pp_clk", "gop_clk", "mg_clk" + and "axi_clk" (the 2 latter only for armada-7k-pp2). The ethernet ports are represented by subnodes. At least one port is required. @@ -78,8 +79,9 @@ Example for marvell,armada-7k-pp2: cpm_ethernet: ethernet@0 { compatible = "marvell,armada-7k-pp22"; reg = <0x0 0x100000>, <0x129000 0xb000>; - clocks = <&cpm_syscon0 1 3>, <&cpm_syscon0 1 9>, <&cpm_syscon0 1 5>; - clock-names = "pp_clk", "gop_clk", "gp_clk"; + clocks = <&cpm_syscon0 1 3>, <&cpm_syscon0 1 9>, + <&cpm_syscon0 1 5>, <&cpm_syscon0 1 18>; + clock-names = "pp_clk", "gop_clk", "gp_clk", "axi_clk"; eth0: eth0 { interrupts = , -- cgit v1.2.3 From 9339fd348dd98ed64879a48dc7290cc3fa4e2911 Mon Sep 17 00:00:00 2001 From: Yury Norov Date: Wed, 13 Sep 2017 21:08:30 +0300 Subject: arm64: fix documentation on kernel pages mappings to HYP VA The Documentation/arm64/memory.txt says: When using KVM, the hypervisor maps kernel pages in EL2, at a fixed offset from the kernel VA (top 24bits of the kernel VA set to zero): In fact, kernel addresses are transleted to HYP with kern_hyp_va macro, which has more options, and none of them assumes clearing of top 24bits of the kernel VA. Acked-by: Marc Zyngier Signed-off-by: Yury Norov [will: removed gory details] Signed-off-by: Will Deacon --- Documentation/arm64/memory.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index d7273a5f6456..671bc0639262 100644 --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -86,9 +86,9 @@ Translation table lookup with 64KB pages: +-------------------------------------------------> [63] TTBR0/1 -When using KVM, the hypervisor maps kernel pages in EL2, at a fixed -offset from the kernel VA (top 24bits of the kernel VA set to zero): +When using KVM without the Virtualization Host Extensions, the hypervisor +maps kernel pages in EL2 at a fixed offset from the kernel VA. See the +kern_hyp_va macro for more details. -Start End Size Use ------------------------------------------------------------------------ -0000004000000000 0000007fffffffff 256GB kernel objects mapped in HYP +When using KVM with the Virtualization Host Extensions, no additional +mappings are created, since the host kernel runs directly in EL2. -- cgit v1.2.3 From 19205da6a0da701787d42ad754edd1ffb514c956 Mon Sep 17 00:00:00 2001 From: Petr Mladek Date: Mon, 25 Sep 2017 17:41:59 +0200 Subject: livepatch: Small shadow variable documentation fixes The description of the basic operations was a bit inconsistent and based on older version of the patchset. Also the size of the spinlock structure should be allocated instead of the pointer. Signed-off-by: Petr Mladek Acked-by: Joe Lawrence Signed-off-by: Jiri Kosina --- Documentation/livepatch/shadow-vars.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/livepatch/shadow-vars.txt b/Documentation/livepatch/shadow-vars.txt index e3ffc4301bfa..89c66634d600 100644 --- a/Documentation/livepatch/shadow-vars.txt +++ b/Documentation/livepatch/shadow-vars.txt @@ -6,7 +6,7 @@ Shadow variables are a simple way for livepatch modules to associate additional "shadow" data with existing data structures. Shadow data is allocated separately from parent data structures, which are left unmodified. The shadow variable API described in this document is used -to allocate/attach and detach/release shadow variables to their parents. +to allocate/add and remove/free shadow variables to/from their parents. The implementation introduces a global, in-kernel hashtable that associates pointers to parent objects and a numeric identifier of the @@ -107,7 +107,7 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata, sta = kzalloc(sizeof(*sta) + hw->sta_data_size, gfp); /* Attach a corresponding shadow variable, then initialize it */ - ps_lock = klp_shadow_alloc(sta, PS_LOCK, NULL, sizeof(ps_lock), gfp); + ps_lock = klp_shadow_alloc(sta, PS_LOCK, NULL, sizeof(*ps_lock), gfp); if (!ps_lock) goto shadow_fail; spin_lock_init(ps_lock); -- cgit v1.2.3 From dbfdd153d4aefec13460c97475737e59af92d8e2 Mon Sep 17 00:00:00 2001 From: Marco Franchi Date: Mon, 2 Oct 2017 10:45:30 -0300 Subject: dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage Improve the binding example by removing the '@di0' notation, which fixes the following build warning: Warning (unit_address_vs_reg): Node /display@di0 has a unit name, but no reg property Signed-off-by: Marco Franchi Signed-off-by: Philipp Zabel --- Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt index f79854783c2c..5bf77f6dd19d 100644 --- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt +++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt @@ -129,7 +129,7 @@ Optional properties: example: -display@di0 { +disp0 { compatible = "fsl,imx-parallel-display"; edid = [edid-data]; interface-pix-fmt = "rgb24"; -- cgit v1.2.3 From d1ff70241a275133e1a0258b7c23588b122276c8 Mon Sep 17 00:00:00 2001 From: Mika Westerberg Date: Mon, 2 Oct 2017 13:38:34 +0300 Subject: thunderbolt: Add support for XDomain discovery protocol When two hosts are connected over a Thunderbolt cable, there is a protocol they can use to communicate capabilities supported by the host. The discovery protocol uses automatically configured control channel (ring 0) and is build on top of request/response transactions using special XDomain primitives provided by the Thunderbolt base protocol. The capabilities consists of a root directory block of basic properties used for identification of the host, and then there can be zero or more directories each describing a Thunderbolt service and its capabilities. Once both sides have discovered what is supported the two hosts can setup high-speed DMA paths and transfer data to the other side using whatever protocol was agreed based on the properties. The software protocol used to communicate which DMA paths to enable is service specific. This patch adds support for the XDomain discovery protocol to the Thunderbolt bus. We model each remote host connection as a Linux XDomain device. For each Thunderbolt service found supported on the XDomain device, we create Linux Thunderbolt service device which Thunderbolt service drivers can then bind to based on the protocol identification information retrieved from the property directory describing the service. This code is based on the work done by Amir Levy and Michael Jamet. Signed-off-by: Michael Jamet Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat Reviewed-by: Andy Shevchenko Signed-off-by: David S. Miller --- Documentation/ABI/testing/sysfs-bus-thunderbolt | 48 +++++++++++++++++++++++++ 1 file changed, 48 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index 392bef5bd399..93798c02e28b 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -110,3 +110,51 @@ Description: When new NVM image is written to the non-active NVM is directly the status value from the DMA configuration based mailbox before the device is power cycled. Writing 0 here clears the status. + +What: /sys/bus/thunderbolt/devices/./key +Date: Jan 2018 +KernelVersion: 4.15 +Contact: thunderbolt-software@lists.01.org +Description: This contains name of the property directory the XDomain + service exposes. This entry describes the protocol in + question. Following directories are already reserved by + the Apple XDomain specification: + + network: IP/ethernet over Thunderbolt + targetdm: Target disk mode protocol over Thunderbolt + extdisp: External display mode protocol over Thunderbolt + +What: /sys/bus/thunderbolt/devices/./modalias +Date: Jan 2018 +KernelVersion: 4.15 +Contact: thunderbolt-software@lists.01.org +Description: Stores the same MODALIAS value emitted by uevent for + the XDomain service. Format: tbtsvc:kSpNvNrN + +What: /sys/bus/thunderbolt/devices/./prtcid +Date: Jan 2018 +KernelVersion: 4.15 +Contact: thunderbolt-software@lists.01.org +Description: This contains XDomain protocol identifier the XDomain + service supports. + +What: /sys/bus/thunderbolt/devices/./prtcvers +Date: Jan 2018 +KernelVersion: 4.15 +Contact: thunderbolt-software@lists.01.org +Description: This contains XDomain protocol version the XDomain + service supports. + +What: /sys/bus/thunderbolt/devices/./prtcrevs +Date: Jan 2018 +KernelVersion: 4.15 +Contact: thunderbolt-software@lists.01.org +Description: This contains XDomain software version the XDomain + service supports. + +What: /sys/bus/thunderbolt/devices/./prtcstns +Date: Jan 2018 +KernelVersion: 4.15 +Contact: thunderbolt-software@lists.01.org +Description: This contains XDomain service specific settings as + bitmask. Format: %x -- cgit v1.2.3 From e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e Mon Sep 17 00:00:00 2001 From: Amir Levy Date: Mon, 2 Oct 2017 13:38:45 +0300 Subject: net: Add support for networking over Thunderbolt cable ThunderboltIP is a protocol created by Apple to tunnel IP/ethernet traffic over a Thunderbolt cable. The protocol consists of configuration phase where each side sends ThunderboltIP login packets (the protocol is determined by UUID in the XDomain packet header) over the configuration channel. Once both sides get positive acknowledgment to their login packet, they configure high-speed DMA path accordingly. This DMA path is then used to transmit and receive networking traffic. This patch creates a virtual ethernet interface the host software can use in the same way as any other networking interface. Once the interface is brought up successfully network packets get tunneled over the Thunderbolt cable to the remote host and back. The connection is terminated by sending a ThunderboltIP logout packet over the configuration channel. We do this when the network interface is brought down by user or the driver is unloaded. Signed-off-by: Amir Levy Signed-off-by: Michael Jamet Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat Reviewed-by: Andy Shevchenko Signed-off-by: David S. Miller --- Documentation/admin-guide/thunderbolt.rst | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst index 6a4cd1f159ca..5c62d11d77e8 100644 --- a/Documentation/admin-guide/thunderbolt.rst +++ b/Documentation/admin-guide/thunderbolt.rst @@ -197,3 +197,27 @@ information is missing. To recover from this mode, one needs to flash a valid NVM image to the host host controller in the same way it is done in the previous chapter. + +Networking over Thunderbolt cable +--------------------------------- +Thunderbolt technology allows software communication across two hosts +connected by a Thunderbolt cable. + +It is possible to tunnel any kind of traffic over Thunderbolt link but +currently we only support Apple ThunderboltIP protocol. + +If the other host is running Windows or macOS only thing you need to +do is to connect Thunderbolt cable between the two hosts, the +``thunderbolt-net`` is loaded automatically. If the other host is also +Linux you should load ``thunderbolt-net`` manually on one host (it does +not matter which one):: + + # modprobe thunderbolt-net + +This triggers module load on the other host automatically. If the driver +is built-in to the kernel image, there is no need to do anything. + +The driver will create one virtual ethernet interface per Thunderbolt +port which are named like ``thunderbolt0`` and so on. From this point +you can either use standard userspace tools like ``ifconfig`` to +configure the interface or let your GUI to handle it automatically. -- cgit v1.2.3 From 7a08c4d514b1ee70e637bb06738b13895a318e8e Mon Sep 17 00:00:00 2001 From: Al Cooper Date: Fri, 22 Sep 2017 15:34:00 -0400 Subject: dt-bindings: Add Broadcom STB USB PHY binding document Add DT bindings document for Broadcom STB USB PHYs Acked-by: Rob Herring Signed-off-by: Al Cooper Signed-off-by: Kishon Vijay Abraham I --- .../bindings/phy/brcm,brcmstb-usb-phy.txt | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt new file mode 100644 index 000000000000..24a0d06acd1d --- /dev/null +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt @@ -0,0 +1,43 @@ +Broadcom STB USB PHY + +Required properties: + - compatible: brcm,brcmstb-usb-phy + - reg: two offset and length pairs. + The first pair specifies a manditory set of memory mapped + registers used for general control of the PHY. + The second pair specifies optional registers used by some of + the SoCs that support USB 3.x + - #phy-cells: Shall be 1 as it expects one argument for setting + the type of the PHY. Possible values are: + - PHY_TYPE_USB2 for USB1.1/2.0 PHY + - PHY_TYPE_USB3 for USB3.x PHY + +Optional Properties: +- clocks : clock phandles. +- clock-names: String, clock name. +- brcm,ipp: Boolean, Invert Port Power. + Possible values are: 0 (Don't invert), 1 (Invert) +- brcm,ioc: Boolean, Invert Over Current detection. + Possible values are: 0 (Don't invert), 1 (Invert) +NOTE: one or both of the following two properties must be set +- brcm,has-xhci: Boolean indicating the phy has an XHCI phy. +- brcm,has-eohci: Boolean indicating the phy has an EHCI/OHCI phy. +- dr_mode: String, PHY Device mode. + Possible values are: "host", "peripheral ", "drd" or "typec-pd" + If this property is not defined, the phy will default to "host" mode. + +Example: + +usbphy_0: usb-phy@f0470200 { + reg = <0xf0470200 0xb8>, + <0xf0471940 0x6c0>; + compatible = "brcm,brcmstb-usb-phy"; + #phy-cells = <1>; + dr_mode = "host" + brcm,ioc = <1>; + brcm,ipp = <1>; + brcm,has-xhci; + brcm,has-eohci; + clocks = <&usb20>, <&usb30>; + clock-names = "sw_usb", "sw_usb3"; +}; -- cgit v1.2.3 From d19cd4bb234383166801b5d46365282808d0c0e5 Mon Sep 17 00:00:00 2001 From: Adam Borowski Date: Sat, 30 Sep 2017 05:57:39 +0200 Subject: Documentation/features/KASAN: mark KASAN as supported only on 64-bit on x86 Relevant part is: arch/x86/Kconfig: select HAVE_ARCH_KASAN if X86_64 && SPARSEMEM_VMEMMAP Signed-off-by: Adam Borowski Signed-off-by: Jonathan Corbet --- Documentation/features/debug/KASAN/arch-support.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index 76bbd7fe27b3..f377290fe48e 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -34,6 +34,6 @@ | tile: | TODO | | um: | TODO | | unicore32: | TODO | - | x86: | ok | + | x86: | ok | 64-bit only | xtensa: | TODO | ----------------------- -- cgit v1.2.3 From 3ce62385019fbf7d2aea4fd7c73fbd0ddad5c8fd Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Tue, 3 Oct 2017 17:54:07 +0200 Subject: Documentation: Improve softlockup_panic= description text It should say what that range is and what that integer value means. I had to look at the code... Signed-off-by: Borislav Petkov [jc: changed non-null to nonzero] Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index fcaa8558ed7e..f02961bda6f4 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3885,6 +3885,12 @@ [KNL] Should the soft-lockup detector generate panics. Format: + A nonzero value instructs the soft-lockup detector + to panic the machine when a soft-lockup occurs. This + is also controlled by CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC + which is the respective build-time switch to that + functionality. + softlockup_all_cpu_backtrace= [KNL] Should the soft-lockup detector generate backtraces on all cpus. -- cgit v1.2.3 From 852f1a21ffae19a45d4944791ce574e92a2b31ab Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Tue, 3 Oct 2017 16:16:37 -0500 Subject: docs: Update binfmt_misc links Documentation/binfmt_misc.txt moved to Documentation/admin-guide/binfmt-misc.rst Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/sysctl/README | 2 +- Documentation/sysctl/fs.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/README b/Documentation/sysctl/README index 91f54ffa0077..d5f24ab0ecc3 100644 --- a/Documentation/sysctl/README +++ b/Documentation/sysctl/README @@ -60,7 +60,7 @@ debug/ dev/ device specific information (eg dev/cdrom/info) fs/ specific filesystems filehandle, inode, dentry and quota tuning - binfmt_misc + binfmt_misc kernel/ global kernel info / tuning miscellaneous stuff net/ networking stuff, for documentation look in: diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt index 35e17f748ca7..6c00c1e2743f 100644 --- a/Documentation/sysctl/fs.txt +++ b/Documentation/sysctl/fs.txt @@ -277,7 +277,7 @@ in a mount namespace. ---------------------------------------------------------- Documentation for the files in /proc/sys/fs/binfmt_misc is -in Documentation/binfmt_misc.txt. +in Documentation/admin-guide/binfmt-misc.rst. 3. /proc/sys/fs/mqueue - POSIX message queues filesystem -- cgit v1.2.3 From 05946876f0c16f6fe1db692d575aba42b25f0811 Mon Sep 17 00:00:00 2001 From: David Wu Date: Sat, 30 Sep 2017 17:47:23 +0800 Subject: net: stmmac: dwmac-rk: Add RK3128 GMAC support Add constants and callback functions for the dwmac on rk3128 soc. As can be seen, the base structure is the same, only registers and the bits in them moved slightly. Signed-off-by: David Wu Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/rockchip-dwmac.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt index 6af8eed1adeb..9c16ee2965a2 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt @@ -4,6 +4,7 @@ The device node has following properties. Required properties: - compatible: should be "rockchip,-gamc" + "rockchip,rk3128-gmac": found on RK312x SoCs "rockchip,rk3228-gmac": found on RK322x SoCs "rockchip,rk3288-gmac": found on RK3288 SoCs "rockchip,rk3328-gmac": found on RK3328 SoCs -- cgit v1.2.3 From 06e5e0045afd5f3165ba4d11f23e448d8d2ecbd4 Mon Sep 17 00:00:00 2001 From: Jules Maselbas Date: Fri, 15 Sep 2017 18:58:46 +0200 Subject: dt-bindings: max3421: Add bindings documentation Adds bindings documentation for the max3421 driver. Signed-off-by: Jules Maselbas Acked-by: Rob Herring Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/maxim,max3421.txt | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/maxim,max3421.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/maxim,max3421.txt b/Documentation/devicetree/bindings/usb/maxim,max3421.txt new file mode 100644 index 000000000000..7536c3ab3e5a --- /dev/null +++ b/Documentation/devicetree/bindings/usb/maxim,max3421.txt @@ -0,0 +1,24 @@ +Maxim Integrated SPI-based USB 2.0 host controller MAX3421E + +Required properties: + - compatible: "maxim,max3421" + - spi-max-frequency: maximum frequency for this device must not exceed 26 MHz. + - reg: chip select number to which this device is connected. + - maxim,vbus-en-pin: + GPOUTx is the number (1-8) of the GPOUT pin of MAX3421E to drive Vbus. + ACTIVE_LEVEL is 0 or 1. + - interrupt-parent: the phandle of the associated interrupt controller. + - interrupts: the interuption line description for the interrupt controller. + The driver configures MAX3421E for active low level triggered interrupts, + configure your interrupt line accordingly. + +Example: + + usb@0 { + compatible = "maxim,max3421"; + reg = <0>; + maxim,vbus-en-pin = <3 1>; + spi-max-frequency = <26000000>; + interrupt-parent = <&PIC>; + interrupts = <42>; + }; -- cgit v1.2.3 From 0dc262f49232ba306303a3ebc5c01e41b2e6d1af Mon Sep 17 00:00:00 2001 From: Vikas Manocha Date: Thu, 28 Sep 2017 15:51:24 -0700 Subject: Arm: dts: stm32: remove extra compatible string for uart This patch removes the extra compatibility string "st,stm32-usart" to avoid confusion, save some time & space. Signed-off-by: Vikas Manocha Reviewed-by: Patrice Chotard Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/dma/stm32-dma.txt | 2 +- Documentation/devicetree/bindings/serial/st,stm32-usart.txt | 10 +++------- 2 files changed, 4 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt b/Documentation/devicetree/bindings/dma/stm32-dma.txt index 4408af693d0c..6f44df94101c 100644 --- a/Documentation/devicetree/bindings/dma/stm32-dma.txt +++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt @@ -71,7 +71,7 @@ channel: a phandle to the DMA controller plus the following four integer cells: Example: usart1: serial@40011000 { - compatible = "st,stm32-usart", "st,stm32-uart"; + compatible = "st,stm32-uart"; reg = <0x40011000 0x400>; interrupts = <37>; clocks = <&clk_pclk2>; diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt index 3657f9f9d17a..d150b04a6229 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt @@ -2,14 +2,10 @@ Required properties: - compatible: can be either: - - "st,stm32-usart", - "st,stm32-uart", - - "st,stm32f7-usart", - "st,stm32f7-uart", - - "st,stm32h7-usart" - "st,stm32h7-uart". - depending on whether the device supports synchronous mode - and is compatible with stm32(f4), stm32f7 or stm32h7. + depending is compatible with stm32(f4), stm32f7 or stm32h7. - reg: The address and length of the peripheral registers space - interrupts: - The interrupt line for the USART instance, @@ -33,7 +29,7 @@ usart4: serial@40004c00 { }; usart2: serial@40004400 { - compatible = "st,stm32-usart", "st,stm32-uart"; + compatible = "st,stm32-uart"; reg = <0x40004400 0x400>; interrupts = <38>; clocks = <&clk_pclk1>; @@ -43,7 +39,7 @@ usart2: serial@40004400 { }; usart1: serial@40011000 { - compatible = "st,stm32-usart", "st,stm32-uart"; + compatible = "st,stm32-uart"; reg = <0x40011000 0x400>; interrupts = <37>; clocks = <&rcc 0 164>; -- cgit v1.2.3 From 4038e3483c5331592d24f4ea354bb9c72c7f2d64 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Wed, 20 Sep 2017 14:29:36 +0200 Subject: dt-bindings: serial: document rs485 bindings for various devices MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Atmel USART, Freescale UARTs and OMAP UART all support the rs485 binding described in rs485.txt, this commit just makes that explicit. Acked-by: Nicolas Ferre Acked-by: Rob Herring Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/atmel-usart.txt | 1 + Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 1 + Documentation/devicetree/bindings/serial/fsl-lpuart.txt | 1 + Documentation/devicetree/bindings/serial/omap_serial.txt | 1 + 4 files changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt index e6e6142e33ac..7c0d6b2f53e4 100644 --- a/Documentation/devicetree/bindings/serial/atmel-usart.txt +++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt @@ -24,6 +24,7 @@ Optional properties: - dma-names: "rx" for RX channel, "tx" for TX channel. - atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for FIFO capable USARTs. +- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt compatible description: - at91rm9200: legacy USART support diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt index 574c3a2c77d5..860a9559839a 100644 --- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt @@ -9,6 +9,7 @@ Optional properties: - fsl,irda-mode : Indicate the uart supports irda mode - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works in DCE mode by default. +- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt Please check Documentation/devicetree/bindings/serial/serial.txt for the complete list of generic properties. diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt index a1252a047f78..59567b51cf09 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt @@ -16,6 +16,7 @@ Required properties: Optional properties: - dmas: A list of two dma specifiers, one for each entry in dma-names. - dma-names: should contain "tx" and "rx". +- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt Note: Optional properties for DMA support. Write them both or both not. diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt index 7a71b5de77d6..43eac675f21f 100644 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt @@ -19,6 +19,7 @@ Optional properties: - dmas : DMA specifier, consisting of a phandle to the DMA controller node and a DMA channel number. - dma-names : "rx" for receive channel, "tx" for transmit channel. +- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt Example: -- cgit v1.2.3 From ebc4768ac4971eab4b570e733e47ac9dfd0e4175 Mon Sep 17 00:00:00 2001 From: Jan Kandziora Date: Wed, 20 Sep 2017 23:52:46 +0200 Subject: add w1_ds28e17 driver for the DS28E17 Onewire to I2C master bridge This subpatch adds a driver for the DS28E17 Onewire to I2C master bridge. Signed-off-by: Jan Kandziora Acked-by: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-w1_ds28e17 | 21 +++++++ Documentation/w1/slaves/00-INDEX | 2 + Documentation/w1/slaves/w1_ds28e17 | 68 +++++++++++++++++++++++ 3 files changed, 91 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-w1_ds28e17 create mode 100644 Documentation/w1/slaves/w1_ds28e17 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-w1_ds28e17 b/Documentation/ABI/testing/sysfs-driver-w1_ds28e17 new file mode 100644 index 000000000000..d301e7017afe --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-w1_ds28e17 @@ -0,0 +1,21 @@ +What: /sys/bus/w1/devices/19-/speed +Date: Sep 2017 +KernelVersion: 4.14 +Contact: Jan Kandziora +Description: When written, this file sets the I2C speed on the connected + DS28E17 chip. When read, it reads the current setting from + the DS28E17 chip. + Valid values: 100, 400, 900 [kBaud]. + Default 100, can be set by w1_ds28e17.speed= module parameter. +Users: w1_ds28e17 driver + +What: /sys/bus/w1/devices/19-/stretch +Date: Sep 2017 +KernelVersion: 4.14 +Contact: Jan Kandziora +Description: When written, this file sets the multiplier used to calculate + the busy timeout for I2C operations on the connected DS28E17 + chip. When read, returns the current setting. + Valid values: 1 to 9. + Default 1, can be set by w1_ds28e17.stretch= module parameter. +Users: w1_ds28e17 driver diff --git a/Documentation/w1/slaves/00-INDEX b/Documentation/w1/slaves/00-INDEX index 8d76718e1ea2..68946f83e579 100644 --- a/Documentation/w1/slaves/00-INDEX +++ b/Documentation/w1/slaves/00-INDEX @@ -10,3 +10,5 @@ w1_ds2438 - The Maxim/Dallas Semiconductor ds2438 smart battery monitor. w1_ds28e04 - The Maxim/Dallas Semiconductor ds28e04 eeprom. +w1_ds28e17 + - The Maxim/Dallas Semiconductor ds28e17 1-Wire-to-I2C Master Bridge. diff --git a/Documentation/w1/slaves/w1_ds28e17 b/Documentation/w1/slaves/w1_ds28e17 new file mode 100644 index 000000000000..7fcfad5b4a37 --- /dev/null +++ b/Documentation/w1/slaves/w1_ds28e17 @@ -0,0 +1,68 @@ +Kernel driver w1_ds28e17 +======================== + +Supported chips: + * Maxim DS28E17 1-Wire-to-I2C Master Bridge + +supported family codes: + W1_FAMILY_DS28E17 0x19 + +Author: Jan Kandziora + + +Description +----------- +The DS28E17 is a Onewire slave device which acts as an I2C bus master. + +This driver creates a new I2C bus for any DS28E17 device detected. I2C buses +come and go as the DS28E17 devices come and go. I2C slave devices connected to +a DS28E17 can be accessed by the kernel or userspace tools as if they were +connected to a "native" I2C bus master. + + +An udev rule like the following +------------------------------------------------------------------------------- +SUBSYSTEM=="i2c-dev", KERNEL=="i2c-[0-9]*", ATTRS{name}=="w1-19-*", \ + SYMLINK+="i2c-$attr{name}" +------------------------------------------------------------------------------- +may be used to create stable /dev/i2c- entries based on the unique id of the +DS28E17 chip. + + +Driver parameters are: + +speed: + This sets up the default I2C speed a DS28E17 get configured for as soon + it is connected. The power-on default of the DS28E17 is 400kBaud, but + chips may come and go on the Onewire bus without being de-powered and + as soon the "w1_ds28e17" driver notices a freshly connected, or + reconnected DS28E17 device on the Onewire bus, it will re-apply this + setting. + + Valid values are 100, 400, 900 [kBaud]. Any other value means to leave + alone the current DS28E17 setting on detect. The default value is 100. + +stretch: + This sets up the default stretch value used for freshly connected + DS28E17 devices. It is a multiplier used on the calculation of the busy + wait time for an I2C transfer. This is to account for I2C slave devices + which make heavy use of the I2C clock stretching feature and thus, the + needed timeout cannot be pre-calculated correctly. As the w1_ds28e17 + driver checks the DS28E17's busy flag in a loop after the precalculated + wait time, it should be hardly needed to tweak this setting. + + Leave it at 1 unless you get ETIMEDOUT errors and a "w1_slave_driver + 19-00000002dbd8: busy timeout" in the kernel log. + + Valid values are 1 to 9. The default is 1. + + +The driver creates sysfs files /sys/bus/w1/devices/19-/speed and +/sys/bus/w1/devices/19-/stretch for each device, preloaded with the default +settings from the driver parameters. They may be changed anytime. In addition a +directory /sys/bus/w1/devices/19-/i2c- for the I2C bus master sysfs +structure is created. + + +See https://github.com/ianka/w1_ds28e17 for even more information. + -- cgit v1.2.3 From eeb8b4934f2e9dce2e2c9adc28ce8571e53b8aec Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Sun, 17 Sep 2017 12:33:42 +0200 Subject: nvmem: dt: document SNVS LPGPR binding Documentation bindings for the Low Power General Purpose Register available on i.MX6 SoCs in the Secure Non-Volatile Storage. Signed-off-by: Oleksij Rempel Acked-by: Rob Herring Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/nvmem/snvs-lpgpr.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt new file mode 100644 index 000000000000..20bc49b49799 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt @@ -0,0 +1,20 @@ +Device tree bindings for Low Power General Purpose Register found in i.MX6Q/D +Secure Non-Volatile Storage. + +This DT node should be represented as a sub-node of a "syscon", +"simple-mfd" node. + +Required properties: +- compatible: should be one of the fallowing variants: + "fsl,imx6q-snvs-lpgpr" for Freescale i.MX6Q/D/DL/S + "fsl,imx6ul-snvs-lpgpr" for Freescale i.MX6UL + +Example: +snvs: snvs@020cc000 { + compatible = "fsl,sec-v4.0-mon", "syscon", "simple-mfd"; + reg = <0x020cc000 0x4000>; + + snvs_lpgpr: snvs-lpgpr { + compatible = "fsl,imx6q-snvs-lpgpr"; + }; +}; -- cgit v1.2.3 From c2e5df616e1ae6c2a074cb241ebb65a318ebaf7c Mon Sep 17 00:00:00 2001 From: Stephen Hemminger Date: Thu, 21 Sep 2017 20:58:49 -0700 Subject: vmbus: add per-channel sysfs info This extends existing vmbus related sysfs structure to provide per-channel state information. This is useful when diagnosing issues with multiple queues in networking and storage. The existing sysfs only displayed information about the primary channel. The one place it reported multiple channels was the channel_vp_mapping file which violated the sysfs convention of one value per file. Signed-off-by: Stephen Hemminger Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/stable/sysfs-bus-vmbus | 56 ++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus b/Documentation/ABI/stable/sysfs-bus-vmbus index 5d0125f7bcaf..0ebd8a1537a0 100644 --- a/Documentation/ABI/stable/sysfs-bus-vmbus +++ b/Documentation/ABI/stable/sysfs-bus-vmbus @@ -41,3 +41,59 @@ KernelVersion: 4.5 Contact: K. Y. Srinivasan Description: The 16 bit vendor ID of the device Users: tools/hv/lsvmbus and user level RDMA libraries + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/cpu +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: VCPU (sub)channel is affinitized to +Users: tools/hv/lsvmbus and other debuggig tools + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/cpu +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: VCPU (sub)channel is affinitized to +Users: tools/hv/lsvmbus and other debuggig tools + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/in_mask +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: Inbound channel signaling state +Users: Debuggig tools + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/latency +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: Channel signaling latency +Users: Debuggig tools + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/out_mask +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: Outbound channel signaling state +Users: Debuggig tools + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/pending +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: Channel interrupt pending state +Users: Debuggig tools + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/read_avail +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: Bytes availabble to read +Users: Debuggig tools + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/write_avail +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: Bytes availabble to write +Users: Debuggig tools -- cgit v1.2.3 From bb16ea1742c8f35a9349b7508dc45d3a922db5f5 Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Mon, 2 Oct 2017 16:58:52 +0200 Subject: mmc: sdhci-xenon: Fix clock resource by adding an optional bus clock On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock is optional because not all the SoCs need them but at least for Armada 7K/8K it is actually mandatory. The binding documentation is updating accordingly. Without this patch the kernel hand during boot if the mvpp2.2 network driver was not present in the kernel. Indeed the clock needed by the xenon controller was set by the network driver. Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality)" CC: Stable Tested-by: Zhoujie Wu Signed-off-by: Gregory CLEMENT Signed-off-by: Ulf Hansson --- .../devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt index b878a1e305af..ed1456f5c94d 100644 --- a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt @@ -16,11 +16,13 @@ Required Properties: - clocks: Array of clocks required for SDHC. - Require at least input clock for Xenon IP core. + Require at least input clock for Xenon IP core. For Armada AP806 and + CP110, the AXI clock is also mandatory. - clock-names: Array of names corresponding to clocks property. The input clock for Xenon IP core should be named as "core". + The input clock for the AXI bus must be named as "axi". - reg: * For "marvell,armada-3700-sdhci", two register areas. @@ -106,8 +108,8 @@ Example: compatible = "marvell,armada-ap806-sdhci"; reg = <0xaa0000 0x1000>; interrupts = - clocks = <&emmc_clk>; - clock-names = "core"; + clocks = <&emmc_clk>,<&axi_clk>; + clock-names = "core", "axi"; bus-width = <4>; marvell,xenon-phy-slow-mode; marvell,xenon-tun-count = <11>; @@ -126,8 +128,8 @@ Example: interrupts = vqmmc-supply = <&sd_vqmmc_regulator>; vmmc-supply = <&sd_vmmc_regulator>; - clocks = <&sdclk>; - clock-names = "core"; + clocks = <&sdclk>, <&axi_clk>; + clock-names = "core", "axi"; bus-width = <4>; marvell,xenon-tun-count = <9>; }; -- cgit v1.2.3 From b35bd0d9f8a8ea17aae40893e18274d191a2d2c5 Mon Sep 17 00:00:00 2001 From: Jens Axboe Date: Sat, 30 Sep 2017 23:39:05 -0600 Subject: sysctl: remove /proc/sys/vm/nr_pdflush_threads This tunable has been obsolete since 2.6.32, and writes to the file have been failing and complaining in dmesg since then: nr_pdflush_threads exported in /proc is scheduled for removal That was 8 years ago. Remove the file ABI obsolete notice, and the sysfs file. Reviewed-by: Jan Kara Signed-off-by: Jens Axboe --- Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads | 5 ----- 1 file changed, 5 deletions(-) delete mode 100644 Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads (limited to 'Documentation') diff --git a/Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads b/Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads deleted file mode 100644 index b0b0eeb20fe3..000000000000 --- a/Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads +++ /dev/null @@ -1,5 +0,0 @@ -What: /proc/sys/vm/nr_pdflush_threads -Date: June 2012 -Contact: Wanpeng Li -Description: Since pdflush is replaced by per-BDI flusher, the interface of old pdflush - exported in /proc/sys/vm/ should be removed. -- cgit v1.2.3 From e0a86312874e36033cd94fb977dd603a292875c8 Mon Sep 17 00:00:00 2001 From: James Hogan Date: Wed, 4 Oct 2017 23:10:59 +0100 Subject: Update James Hogan's email address Update my imgtec.com and personal email address to my kernel.org one in a few places as MIPS will soon no longer be part of Imagination Technologies, and add mappings in .mailcap so get_maintainer.pl reports the right address. Signed-off-by: James Hogan Signed-off-by: Linus Torvalds --- Documentation/ABI/testing/sysfs-power | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index 713cab1d5f12..a1d1612f3651 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -127,7 +127,7 @@ Description: What; /sys/power/pm_trace_dev_match Date: October 2010 -Contact: James Hogan +Contact: James Hogan Description: The /sys/power/pm_trace_dev_match file contains the name of the device associated with the last PM event point saved in the RTC -- cgit v1.2.3 From 2a158f888853cb11140532be79883c8faf31c83d Mon Sep 17 00:00:00 2001 From: Masahiro Yamada Date: Thu, 5 Oct 2017 11:30:57 +0900 Subject: reset: uniphier: add PXs3 reset data Add basic reset data for Socionext's new SoC PXs3. Signed-off-by: Masahiro Yamada Signed-off-by: Philipp Zabel --- Documentation/devicetree/bindings/reset/uniphier-reset.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt index 68a6f487c409..93efed629900 100644 --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt @@ -13,6 +13,7 @@ Required properties: "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC "socionext,uniphier-ld11-reset" - for LD11 SoC "socionext,uniphier-ld20-reset" - for LD20 SoC + "socionext,uniphier-pxs3-reset" - for PXs3 SoC - #reset-cells: should be 1. Example: @@ -44,6 +45,7 @@ Required properties: "socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO) "socionext,uniphier-ld11-sd-reset" - for LD11 SoC (SD) "socionext,uniphier-ld20-sd-reset" - for LD20 SoC + "socionext,uniphier-pxs3-sd-reset" - for PXs3 SoC - #reset-cells: should be 1. Example: @@ -74,6 +76,7 @@ Required properties: "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC "socionext,uniphier-ld11-peri-reset" - for LD11 SoC "socionext,uniphier-ld20-peri-reset" - for LD20 SoC + "socionext,uniphier-pxs3-peri-reset" - for PXs3 SoC - #reset-cells: should be 1. Example: -- cgit v1.2.3 From 4750bc78efdb126ddc40f1b34dbae7ce319344cb Mon Sep 17 00:00:00 2001 From: "Thang Q. Nguyen" Date: Thu, 5 Oct 2017 11:21:37 +0300 Subject: usb: host: xhci support option to disable the xHCI USB2 HW LPM XHCI specification 1.1 does not require xHCI-compliant controllers to always enable hardware USB2 LPM. However, the current xHCI driver always enable it when seeing HLC=1. This patch supports an option for users to control disabling USB2 Hardware LPM via DT/ACPI attribute. This option is needed in case user would like to disable this feature. For example, their xHCI controller has its USB2 HW LPM broken. Signed-off-by: Tung Nguyen Signed-off-by: Thang Q. Nguyen Acked-by: Rob Herring Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 2d80b60eeabe..ae6e484a8d7c 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -26,6 +26,7 @@ Required properties: Optional properties: - clocks: reference to a clock + - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM - usb3-lpm-capable: determines if platform is USB3 LPM capable - quirk-broken-port-ped: set if the controller has broken port disable mechanism -- cgit v1.2.3 From cb09d943c70da7c8097006db1dc163b2d99338f6 Mon Sep 17 00:00:00 2001 From: Jarkko Nikula Date: Thu, 21 Sep 2017 16:23:16 +0300 Subject: i2c: i801: Add support for Intel Cedar Fork Add PCI ID for Intel Cedar Fork PCH. Signed-off-by: Jarkko Nikula Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang --- Documentation/i2c/busses/i2c-i801 | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 0500193434cb..d47702456926 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -36,6 +36,7 @@ Supported adapters: * Intel Gemini Lake (SOC) * Intel Cannon Lake-H (PCH) * Intel Cannon Lake-LP (PCH) + * Intel Cedar Fork (PCH) Datasheets: Publicly available at the Intel website On Intel Patsburg and later chipsets, both the normal host SMBus controller -- cgit v1.2.3 From 85fdee1eef1a9e48ad5716916677e0c5fbc781e3 Mon Sep 17 00:00:00 2001 From: Amir Goldstein Date: Fri, 29 Sep 2017 10:21:21 +0300 Subject: ovl: fix regression caused by exclusive upper/work dir protection Enforcing exclusive ownership on upper/work dirs caused a docker regression: https://github.com/moby/moby/issues/34672. Euan spotted the regression and pointed to the offending commit. Vivek has brought the regression to my attention and provided this reproducer: Terminal 1: mount -t overlay -o workdir=work,lowerdir=lower,upperdir=upper none merged/ Terminal 2: unshare -m Terminal 1: umount merged mount -t overlay -o workdir=work,lowerdir=lower,upperdir=upper none merged/ mount: /root/overlay-testing/merged: none already mounted or mount point busy To fix the regression, I replaced the error with an alarming warning. With index feature enabled, mount does fail, but logs a suggestion to override exclusive dir protection by disabling index. Note that index=off mount does take the inuse locks, so a concurrent index=off will issue the warning and a concurrent index=on mount will fail. Documentation was updated to reflect this change. Fixes: 2cac0c00a6cd ("ovl: get exclusive ownership on upper/work dirs") Cc: # v4.13 Reported-by: Euan Kemp Reported-by: Vivek Goyal Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi --- Documentation/filesystems/overlayfs.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt index 36f528a7fdd6..8caa60734647 100644 --- a/Documentation/filesystems/overlayfs.txt +++ b/Documentation/filesystems/overlayfs.txt @@ -210,8 +210,11 @@ path as another overlay mount and it may use a lower layer path that is beneath or above the path of another overlay lower layer path. Using an upper layer path and/or a workdir path that are already used by -another overlay mount is not allowed and will fail with EBUSY. Using +another overlay mount is not allowed and may fail with EBUSY. Using partially overlapping paths is not allowed but will not fail with EBUSY. +If files are accessed from two overlayfs mounts which share or overlap the +upper layer and/or workdir path the behavior of the overlay is undefined, +though it will not result in a crash or deadlock. Mounting an overlay using an upper layer path, where the upper layer path was previously used by another mounted overlay in combination with a -- cgit v1.2.3 From 41dcf197ad5373a7dd0a4b6572aec2e3ec6a0e49 Mon Sep 17 00:00:00 2001 From: Jonathan Brassow Date: Mon, 2 Oct 2017 17:17:35 -0500 Subject: dm raid: fix incorrect status output at the end of a "recover" process There are three important fields that indicate the overall health and status of an array: dev_health, sync_ratio, and sync_action. They tell us the condition of the devices in the array, and the degree to which the array is synchronized. This commit fixes a condition that is reported incorrectly. When a member of the array is being rebuilt or a new device is added, the "recover" process is used to synchronize it with the rest of the array. When the process is complete, but the sync thread hasn't yet been reaped, it is possible for the state of MD to be: mddev->recovery = [ MD_RECOVERY_RUNNING MD_RECOVERY_RECOVER MD_RECOVERY_DONE ] curr_resync_completed = (but not MaxSector) and all rdevs to be In_sync. This causes the 'array_in_sync' output parameter that is passed to rs_get_progress() to be computed incorrectly and reported as 'false' -- or not in-sync. This in turn causes the dev_health status characters to be reported as all 'a', rather than the proper 'A'. This can cause erroneous output for several seconds at a time when tools will want to be checking the condition due to events that are raised at the end of a sync process. Fix this by properly calculating the 'array_in_sync' return parameter in rs_get_progress(). Also, remove an unnecessary intermediate 'recovery_cp' variable in rs_get_progress(). Signed-off-by: Jonathan Brassow Signed-off-by: Mike Snitzer --- Documentation/device-mapper/dm-raid.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt index 4a0a7469fdd7..32df07e29f68 100644 --- a/Documentation/device-mapper/dm-raid.txt +++ b/Documentation/device-mapper/dm-raid.txt @@ -344,3 +344,4 @@ Version History (wrong raid10_copies/raid10_format sequence) 1.11.1 Add raid4/5/6 journal write-back support via journal_mode option 1.12.1 fix for MD deadlock between mddev_suspend() and md_write_start() available +1.13.0 Fix dev_health status at end of "recover" (was 'a', now 'A') -- cgit v1.2.3 From 69146d05ef96d91577b5e8d804b50d47b6b014f9 Mon Sep 17 00:00:00 2001 From: Dmitry Dunaev Date: Tue, 26 Sep 2017 17:49:37 +0300 Subject: Add Tecon Microprocessor Technologies, LLC vendor prefix Signed-off-by: Dmitry Dunaev Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 9d46f99cc144..5268738c3e7c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -341,6 +341,7 @@ 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 -- cgit v1.2.3 From af37bed303e2b8fbdbe62e8c2c60900eb62a7fea Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 8 Sep 2017 14:45:02 +0200 Subject: PCI: v3: Update the device tree bindings The bindings for the V3 Semiconductor PCI bridge are a tad bit outdated and predates the more formal format we have adopted for the bindings. Update them a bit so it is easier to read, and add the Integrator AP- specific compatible so we can detect that we are running on that specific platform. Add a second register bank for the configuration memory area. The device tree specs do specify a memory range for configuration space but it is not applicable to custom accessors like this. Instead follow the pattern from the Versatile PCI adapter and simply add a second register bank for this memory. Signed-off-by: Linus Walleij Signed-off-by: Bjorn Helgaas Acked-by: Rob Herring Cc: Marc Gonzalez --- .../devicetree/bindings/pci/v3-v360epc-pci.txt | 75 ++++++++++++++++++++-- 1 file changed, 68 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt index 30b364e504ba..11063293f761 100644 --- a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt +++ b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt @@ -2,14 +2,75 @@ V3 Semiconductor V360 EPC PCI bridge This bridge is found in the ARM Integrator/AP (Application Platform) -Integrator-specific notes: +Required properties: +- compatible: should be one of: + "v3,v360epc-pci" + "arm,integrator-ap-pci", "v3,v360epc-pci" +- reg: should contain two register areas: + first the base address of the V3 host bridge controller, 64KB + second the configuration area register space, 16MB +- interrupts: should contain a reference to the V3 error interrupt + as routed on the system. +- bus-range: see pci.txt +- ranges: this follows the standard PCI bindings in the IEEE Std + 1275-1994 (see pci.txt) with the following restriction: + - The non-prefetchable and prefetchable memory windows must + each be exactly 256MB (0x10000000) in size. + - The prefetchable memory window must be immediately adjacent + to the non-prefetcable memory window +- dma-ranges: three ranges for the inbound memory region. The ranges must + be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, + 64MB, 128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked + as pre-fetchable. Two ranges are supported by the hardware. -- syscon: should contain a link to the syscon device node (since +Integrator-specific required properties: +- syscon: should contain a link to the syscon device node, since on the Integrator, some registers in the syscon are required to - operate the V3). + operate the V3 host bridge. -V360 EPC specific notes: +Example: -- reg: should contain the base address of the V3 adapter. -- interrupts: should contain a reference to the V3 error interrupt - as routed on the system. +pci: pciv3@62000000 { + compatible = "arm,integrator-ap-pci", "v3,v360epc-pci"; + #interrupt-cells = <1>; + #size-cells = <2>; + #address-cells = <3>; + reg = <0x62000000 0x10000>, <0x61000000 0x01000000>; + interrupt-parent = <&pic>; + interrupts = <17>; /* Bus error IRQ */ + clocks = <&pciclk>; + bus-range = <0x00 0xff>; + ranges = 0x01000000 0 0x00000000 /* I/O space @00000000 */ + 0x60000000 0 0x01000000 /* 16 MiB @ LB 60000000 */ + 0x02000000 0 0x40000000 /* non-prefectable memory @40000000 */ + 0x40000000 0 0x10000000 /* 256 MiB @ LB 40000000 1:1 */ + 0x42000000 0 0x50000000 /* prefetchable memory @50000000 */ + 0x50000000 0 0x10000000>; /* 256 MiB @ LB 50000000 1:1 */ + dma-ranges = <0x02000000 0 0x20000000 /* EBI memory space */ + 0x20000000 0 0x20000000 /* 512 MB @ LB 20000000 1:1 */ + 0x02000000 0 0x80000000 /* Core module alias memory */ + 0x80000000 0 0x40000000>; /* 1GB @ LB 80000000 */ + interrupt-map-mask = <0xf800 0 0 0x7>; + interrupt-map = < + /* IDSEL 9 */ + 0x4800 0 0 1 &pic 13 /* INT A on slot 9 is irq 13 */ + 0x4800 0 0 2 &pic 14 /* INT B on slot 9 is irq 14 */ + 0x4800 0 0 3 &pic 15 /* INT C on slot 9 is irq 15 */ + 0x4800 0 0 4 &pic 16 /* INT D on slot 9 is irq 16 */ + /* IDSEL 10 */ + 0x5000 0 0 1 &pic 14 /* INT A on slot 10 is irq 14 */ + 0x5000 0 0 2 &pic 15 /* INT B on slot 10 is irq 15 */ + 0x5000 0 0 3 &pic 16 /* INT C on slot 10 is irq 16 */ + 0x5000 0 0 4 &pic 13 /* INT D on slot 10 is irq 13 */ + /* IDSEL 11 */ + 0x5800 0 0 1 &pic 15 /* INT A on slot 11 is irq 15 */ + 0x5800 0 0 2 &pic 16 /* INT B on slot 11 is irq 16 */ + 0x5800 0 0 3 &pic 13 /* INT C on slot 11 is irq 13 */ + 0x5800 0 0 4 &pic 14 /* INT D on slot 11 is irq 14 */ + /* IDSEL 12 */ + 0x6000 0 0 1 &pic 16 /* INT A on slot 12 is irq 16 */ + 0x6000 0 0 2 &pic 13 /* INT B on slot 12 is irq 13 */ + 0x6000 0 0 3 &pic 14 /* INT C on slot 12 is irq 14 */ + 0x6000 0 0 4 &pic 15 /* INT D on slot 12 is irq 15 */ + >; +}; -- cgit v1.2.3 From a38b9267995402b89916017872a6f3ba405bcb96 Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Wed, 27 Sep 2017 16:03:40 +0200 Subject: dt-bindings: trivial: Add RTCs Add remaining trivial RTC bindings. Signed-off-by: Alexandre Belloni Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/trivial-devices.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt index af284fbd4d23..e3992013133e 100644 --- a/Documentation/devicetree/bindings/trivial-devices.txt +++ b/Documentation/devicetree/bindings/trivial-devices.txt @@ -41,6 +41,7 @@ dallas,ds1338 I2C RTC with 56-Byte NV RAM dallas,ds1340 I2C RTC with Trickle Charger dallas,ds1374 I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output dallas,ds1631 High-Precision Digital Thermometer +dallas,ds1672 Dallas DS1672 Real-time Clock dallas,ds1682 Total-Elapsed-Time Recorder with Alarm dallas,ds1775 Tiny Digital Thermometer and Thermostat dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM @@ -56,6 +57,7 @@ domintech,dmard10 DMARD10: 3-axis Accelerometer epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE +emmicro,em3027 EM Microelectronic EM3027 Real-time Clock fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51 fsl,mma7660 MMA7660FC: 3-Axis Orientation/Motion Detection Sensor @@ -67,6 +69,8 @@ gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire In infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) isil,isl1208 Intersil ISL1208 Low Power RTC with Battery Backed SRAM +isil,isl1218 Intersil ISL1218 Low Power RTC with Battery Backed SRAM +isil,isl12022 Intersil ISL12022 Real-time Clock isil,isl29028 Intersil ISL29028 Ambient Light and Proximity Sensor isil,isl29030 Intersil ISL29030 Ambient Light and Proximity Sensor maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator @@ -155,6 +159,7 @@ nxp,pca9556 Octal SMBus and I2C registered interface nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset nxp,pcf2127 Real-time clock nxp,pcf2129 Real-time clock +nxp,pcf8523 Real-time Clock nxp,pcf8563 Real-time clock/calendar nxp,pcf85063 Tiny Real-Time Clock oki,ml86v7667 OKI ML86V7667 video decoder -- cgit v1.2.3 From b766f10f7b1b416460c05df57345bba74cd5911d Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Wed, 27 Sep 2017 16:03:41 +0200 Subject: dt-bindings: rtc: add stericsson,coh901331 bindings Add device tree bindings for the ST-Ericsson COH 901 331 Real Time Clock Signed-off-by: Alexandre Belloni Reviewed-by: Linus Walleij Signed-off-by: Alexandre Belloni Signed-off-by: Rob Herring --- .../devicetree/bindings/rtc/stericsson,coh901331.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/stericsson,coh901331.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/stericsson,coh901331.txt b/Documentation/devicetree/bindings/rtc/stericsson,coh901331.txt new file mode 100644 index 000000000000..3ebeb311335f --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/stericsson,coh901331.txt @@ -0,0 +1,17 @@ +ST-Ericsson COH 901 331 Real Time Clock + +Required properties: +- compatible: must be "stericsson,coh901331" +- reg: address range of rtc register set. +- interrupt-parent: phandle for the interrupt controller. +- interrupts: rtc alarm interrupt. +- clocks: phandle to the rtc clock source + +Example: + rtc: rtc@c0017000 { + compatible = "stericsson,coh901331"; + reg = <0xc0017000 0x1000>; + interrupt-parent = <&vicb>; + interrupts = <10>; + clocks = <&rtc_clk>; + }; -- cgit v1.2.3 From 0fc52ca54aa1f6ad8a38efea2f4b072150280008 Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Wed, 27 Sep 2017 16:03:42 +0200 Subject: dt-bindings: rtc: Add sirf,prima2-sysrtc bindings Add device tree bindings for the SiRFSoC Real Time Clock. Signed-off-by: Alexandre Belloni Signed-off-by: Rob Herring --- .../devicetree/bindings/rtc/sirf,prima2-sysrtc.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/sirf,prima2-sysrtc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/sirf,prima2-sysrtc.txt b/Documentation/devicetree/bindings/rtc/sirf,prima2-sysrtc.txt new file mode 100644 index 000000000000..58885b55da21 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/sirf,prima2-sysrtc.txt @@ -0,0 +1,13 @@ +SiRFSoC Real Time Clock + +Required properties: +- compatible: must be "sirf,prima2-sysrtc" +- reg: address range of rtc register set. +- interrupts: rtc alarm interrupts. + +Example: + rtc@2000 { + compatible = "sirf,prima2-sysrtc"; + reg = <0x2000 0x1000>; + interrupts = <52 53 54>; + }; -- cgit v1.2.3 From 13a5595892ca3cf99625085aaee4c2cb2e6dd5a5 Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Wed, 27 Sep 2017 16:03:43 +0200 Subject: dt-bindings: rtc: DS1307 and compatibles are not trivial Document optional properties for ds1307 and compatible RTCs Signed-off-by: Alexandre Belloni Signed-off-by: Rob Herring --- .../devicetree/bindings/rtc/rtc-ds1307.txt | 36 ++++++++++++++++++++++ .../devicetree/bindings/trivial-devices.txt | 6 ---- 2 files changed, 36 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1307.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt b/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt new file mode 100644 index 000000000000..c010f18a85a0 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt @@ -0,0 +1,36 @@ +Dallas DS1307 and compatible RTC + +Required properties: +- compatible: should be one of: + "dallas,ds1307", + "dallas,ds1308", + "dallas,ds1337", + "dallas,ds1338", + "dallas,ds1339", + "dallas,ds1388", + "dallas,ds1340", + "dallas,ds1341", + "maxim,ds3231", + "st,m41t0", + "st,m41t00", + "microchip,mcp7940x", + "microchip,mcp7941x", + "pericom,pt7c4338", + "epson,rx8025", + "isil,isl12057" +- reg: I2C bus address of the device + +Optional properties: +- interrupt-parent: phandle for the interrupt controller. +- interrupts: rtc alarm interrupt. +- clock-output-names: From common clock binding to override the default output + clock name +- wakeup-source: Enables wake up of host system on alarm + +Example: + rtc1: ds1339@68 { + compatible = "dallas,ds1339"; + reg = <0x68>; + interrupt-parent = <&gpio4>; + interrupts = <20 0>; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt index e3992013133e..4353151367a1 100644 --- a/Documentation/devicetree/bindings/trivial-devices.txt +++ b/Documentation/devicetree/bindings/trivial-devices.txt @@ -36,9 +36,6 @@ atmel,at97sc3204t i2c trusted platform module (TPM) capella,cm32181 CM32181: Ambient Light Sensor capella,cm3232 CM3232: Ambient Light Sensor cirrus,cs42l51 Cirrus Logic CS42L51 audio codec -dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock -dallas,ds1338 I2C RTC with 56-Byte NV RAM -dallas,ds1340 I2C RTC with Trickle Charger dallas,ds1374 I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output dallas,ds1631 High-Precision Digital Thermometer dallas,ds1672 Dallas DS1672 Real-time Clock @@ -55,7 +52,6 @@ dlg,da9063 DA9063: system PMIC for quad-core application processors domintech,dmard09 DMARD09: 3-axis Accelerometer domintech,dmard10 DMARD10: 3-axis Accelerometer epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE -epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE emmicro,em3027 EM Microelectronic EM3027 Real-time Clock fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer @@ -179,8 +175,6 @@ sii,s35390a 2-wire CMOS real-time clock silabs,si7020 Relative Humidity and Temperature Sensors skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply st,24c256 i2c serial eeprom (24cxx) -st,m41t0 Serial real-time clock (RTC) -st,m41t00 Serial real-time clock (RTC) st,m41t62 Serial real-time clock (RTC) with alarm st,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface -- cgit v1.2.3 From 5015391d9d6e28c85fd98d663703497dd1ec7917 Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Wed, 27 Sep 2017 16:03:44 +0200 Subject: dt-bindings: rtc: Add bindings for m41t80 and compatibles The ST M41T80 family of RTC are not trivial devices, document them. Signed-off-by: Alexandre Belloni Signed-off-by: Rob Herring --- .../devicetree/bindings/rtc/rtc-m41t80.txt | 31 ++++++++++++++++++++++ .../devicetree/bindings/trivial-devices.txt | 2 -- 2 files changed, 31 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/rtc/rtc-m41t80.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt new file mode 100644 index 000000000000..717d93860af1 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt @@ -0,0 +1,31 @@ +ST M41T80 family of RTC and compatible + +Required properties: +- compatible: should be one of: + "st,m41t62", + "st,m41t65", + "st,m41t80", + "st,m41t81", + "st,m41t81s", + "st,m41t82", + "st,m41t83", + "st,m41t84", + "st,m41t85", + "st,m41t87", + "microcrystal,rv4162", +- reg: I2C bus address of the device + +Optional properties: +- interrupt-parent: phandle for the interrupt controller. +- interrupts: rtc alarm interrupt. +- clock-output-names: From common clock binding to override the default output + clock name +- wakeup-source: Enables wake up of host system on alarm + +Example: + rtc@68 { + compatible = "st,m41t80"; + reg = <0x68>; + interrupt-parent = <&UIC0>; + interrupts = <0x9 0x8>; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt index 4353151367a1..4b169caab0eb 100644 --- a/Documentation/devicetree/bindings/trivial-devices.txt +++ b/Documentation/devicetree/bindings/trivial-devices.txt @@ -175,8 +175,6 @@ sii,s35390a 2-wire CMOS real-time clock silabs,si7020 Relative Humidity and Temperature Sensors skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply st,24c256 i2c serial eeprom (24cxx) -st,m41t62 Serial real-time clock (RTC) with alarm -st,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface ti,ads7828 8-Channels, 12-bit ADC ti,ads7830 8-Channels, 8-bit ADC -- cgit v1.2.3 From 1620c624305f3773563996757a87eecf44cecfec Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Wed, 27 Sep 2017 16:03:45 +0200 Subject: dt-bindings: rtc: merge ds1339 in ds1307 documentation Now that there is documentation for the ds1307 and compatible RTCs, merge the ds1339 documentation in it. Signed-off-by: Alexandre Belloni Signed-off-by: Rob Herring --- .../devicetree/bindings/rtc/dallas,ds1339.txt | 18 ------------------ Documentation/devicetree/bindings/rtc/rtc-ds1307.txt | 8 ++++++++ 2 files changed, 8 insertions(+), 18 deletions(-) delete mode 100644 Documentation/devicetree/bindings/rtc/dallas,ds1339.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/dallas,ds1339.txt b/Documentation/devicetree/bindings/rtc/dallas,ds1339.txt deleted file mode 100644 index 916f57601a8f..000000000000 --- a/Documentation/devicetree/bindings/rtc/dallas,ds1339.txt +++ /dev/null @@ -1,18 +0,0 @@ -* Dallas DS1339 I2C Serial Real-Time Clock - -Required properties: -- compatible: Should contain "dallas,ds1339". -- reg: I2C address for chip - -Optional properties: -- trickle-resistor-ohms : Selected resistor for trickle charger - Values usable for ds1339 are 250, 2000, 4000 - Should be given if trickle charger should be enabled -- trickle-diode-disable : Do not use internal trickle charger diode - Should be given if internal trickle charger diode should be disabled -Example: - ds1339: rtc@68 { - compatible = "dallas,ds1339"; - trickle-resistor-ohms = <250>; - reg = <0x68>; - }; diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt b/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt index c010f18a85a0..d28d6e7f6ae8 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt +++ b/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt @@ -26,6 +26,13 @@ Optional properties: - clock-output-names: From common clock binding to override the default output clock name - wakeup-source: Enables wake up of host system on alarm +- trickle-resistor-ohms : ds1339, ds1340 and ds 1388 only + Selected resistor for trickle charger + Possible values are 250, 2000, 4000 + Should be given if trickle charger should be enabled +- trickle-diode-disable : ds1339, ds1340 and ds 1388 only + Do not use internal trickle charger diode + Should be given if internal trickle charger diode should be disabled Example: rtc1: ds1339@68 { @@ -33,4 +40,5 @@ Example: reg = <0x68>; interrupt-parent = <&gpio4>; interrupts = <20 0>; + trickle-resistor-ohms = <250>; }; -- cgit v1.2.3 From c0374eb804a213ce6f55328c8b3511101d31a485 Mon Sep 17 00:00:00 2001 From: Maciej Purski Date: Thu, 5 Oct 2017 16:07:10 +0200 Subject: drm/bridge: add Silicon Image SiI9234 driver SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0. It is controlled via I2C bus. Its interaction with other devices in video pipeline is performed mainly on HW level. The only interaction it does on device driver level is filtering-out unsupported video modes, it exposes drm_bridge interface to perform this operation. This patch is based on the code refactored by Tomasz Stanislawski , which was initially developed by: Adam Hampson Erik Gilling Shankar Bandal Dharam Kumar Signed-off-by: Maciej Purski Acked-by: Rob Herring [for dt bindings] Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/1507212431-5801-2-git-send-email-m.purski@samsung.com --- .../devicetree/bindings/display/bridge/sii9234.txt | 49 ++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt b/Documentation/devicetree/bindings/display/bridge/sii9234.txt new file mode 100644 index 000000000000..88041ba23d56 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt @@ -0,0 +1,49 @@ +Silicon Image SiI9234 HDMI/MHL bridge bindings + +Required properties: + - compatible : "sil,sii9234". + - reg : I2C address for TPI interface, use 0x39 + - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V) + - iovcc18-supply : I/O Supply Voltage (1.8V) + - avcc12-supply : TMDS Analog Supply Voltage (1.2V) + - cvcc12-supply : Digital Core Supply Voltage (1.2V) + - interrupts, interrupt-parent: interrupt specifier of INT pin + - reset-gpios: gpio specifier of RESET pin (active low) + - video interfaces: Device node can contain two video interface port + nodes for HDMI encoder and connector according to [1]. + - port@0 - MHL to HDMI + - port@1 - MHL to connector + +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt + + +Example: + sii9234@39 { + compatible = "sil,sii9234"; + reg = <0x39>; + avcc33-supply = <&vcc33mhl>; + iovcc18-supply = <&vcc18mhl>; + avcc12-supply = <&vsil12>; + cvcc12-supply = <&vsil12>; + reset-gpios = <&gpf3 4 GPIO_ACTIVE_LOW>; + interrupt-parent = <&gpf3>; + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + mhl_to_hdmi: endpoint { + remote-endpoint = <&hdmi_to_mhl>; + }; + }; + port@1 { + reg = <1>; + mhl_to_connector: endpoint { + remote-endpoint = <&connector_to_mhl>; + }; + }; + }; + }; -- cgit v1.2.3 From 28517c02e1dd8fef7a0eab5e9f18013a0e297aba Mon Sep 17 00:00:00 2001 From: Loic Poulain Date: Fri, 8 Sep 2017 15:57:53 +0200 Subject: dt-bindings: net: document Bluetooth bindings in one place In the same way as Ethernet, gather the Bluetooth related bindings in one file. Introduce the bluetooth-bd-address property which can be used to store the assigned BD address. Signed-off-by: Loic Poulain Signed-off-by: Marcel Holtmann --- Documentation/devicetree/bindings/net/bluetooth.txt | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/bluetooth.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/bluetooth.txt b/Documentation/devicetree/bindings/net/bluetooth.txt new file mode 100644 index 000000000000..94797df751b8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/bluetooth.txt @@ -0,0 +1,5 @@ +The following properties are common to the Bluetooth controllers: + +- local-bd-address: array of 6 bytes, specifies the BD address that was + uniquely assigned to the Bluetooth device, formatted with least significant + byte first (little-endian). -- cgit v1.2.3 From e7868a2f71bd9f81494f0c90a64e4dd454248850 Mon Sep 17 00:00:00 2001 From: Loic Poulain Date: Fri, 8 Sep 2017 15:57:54 +0200 Subject: dt-bindings: soc: qcom: Add local-bd-address property to WCNSS-BT Add optional local-bd-address property which is a 6-byte array storing the assigned BD address. Since having a unique BD address is critical, a per-device property value should be allocated. This property is usually added by the boot loader which has access to the provisioned data. Signed-off-by: Loic Poulain Signed-off-by: Marcel Holtmann --- Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt index 4ea39e9186a7..042a2e4159bd 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt @@ -37,6 +37,11 @@ The following properties are defined to the bluetooth node: Definition: must be: "qcom,wcnss-bt" +- local-bd-address: + Usage: optional + Value type: + Definition: see Documentation/devicetree/bindings/net/bluetooth.txt + == WiFi The following properties are defined to the WiFi node: @@ -91,6 +96,9 @@ smd { bt { compatible = "qcom,wcnss-bt"; + + /* BD address 00:11:22:33:44:55 */ + local-bd-address = [ 55 44 33 22 11 00 ]; }; wlan { -- cgit v1.2.3 From 407b0b1e0ea3be171c324dd5a717ec52391faaab Mon Sep 17 00:00:00 2001 From: Eric Anholt Date: Wed, 27 Sep 2017 12:36:53 -0700 Subject: dt-bindings: Document the Raspberry Pi Touchscreen nodes. This doesn't yet cover input, but the driver does get the display working when the firmware is disabled from talking to our I2C lines. Signed-off-by: Eric Anholt Acked-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20170927193654.12609-3-eric@anholt.net --- .../panel/raspberrypi,7inch-touchscreen.txt | 49 ++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt new file mode 100644 index 000000000000..e9e19c059260 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt @@ -0,0 +1,49 @@ +This binding covers the official 7" (800x480) Raspberry Pi touchscreen +panel. + +This DSI panel contains: + +- TC358762 DSI->DPI bridge +- Atmel microcontroller on I2C for power sequencing the DSI bridge and + controlling backlight +- Touchscreen controller on I2C for touch input + +and this binding covers the DSI display parts but not its touch input. + +Required properties: +- compatible: Must be "raspberrypi,7inch-touchscreen-panel" +- reg: Must be "45" +- port: See panel-common.txt + +Example: + +dsi1: dsi@7e700000 { + #address-cells = <1>; + #size-cells = <0>; + <...> + + port { + dsi_out_port: endpoint { + remote-endpoint = <&panel_dsi_port>; + }; + }; +}; + +i2c_dsi: i2c { + compatible = "i2c-gpio"; + #address-cells = <1>; + #size-cells = <0>; + gpios = <&gpio 28 0 + &gpio 29 0>; + + lcd@45 { + compatible = "raspberrypi,7inch-touchscreen-panel"; + reg = <0x45>; + + port { + panel_dsi_port: endpoint { + remote-endpoint = <&dsi_out_port>; + }; + }; + }; +}; -- cgit v1.2.3 From aee2828ccb3444ad1551e8528a868ab49ef447de Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl Date: Sat, 23 Sep 2017 16:14:01 +0200 Subject: dt-bindings: Amlogic: add documentation for the SoC info register areas There are three register areas which contain information about the SoC version and revision: - the assist registers contain the SoC's "major version" which encodes the SoC generation and part number. this is available on Meson6, Meson8 and Meson8b SoCs. - the bootrom register contains at least the SoCs "misc version". this is avilable on Meson6, Meson8 and Meson8b - the analog top registers contain information about the SoC revision. this is only available on Meson8 and Meson8b Not much else is currently known about these registers. Signed-off-by: Martin Blumenstingl Acked-by: Rob Herring Signed-off-by: Kevin Hilman --- .../devicetree/bindings/arm/amlogic/analog-top.txt | 20 ++++++++++++++++++++ .../devicetree/bindings/arm/amlogic/assist.txt | 17 +++++++++++++++++ .../devicetree/bindings/arm/amlogic/bootrom.txt | 17 +++++++++++++++++ 3 files changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/amlogic/analog-top.txt create mode 100644 Documentation/devicetree/bindings/arm/amlogic/assist.txt create mode 100644 Documentation/devicetree/bindings/arm/amlogic/bootrom.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic/analog-top.txt b/Documentation/devicetree/bindings/arm/amlogic/analog-top.txt new file mode 100644 index 000000000000..101dc21014ec --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amlogic/analog-top.txt @@ -0,0 +1,20 @@ +Amlogic Meson8 and Meson8b "analog top" registers: +-------------------------------------------------- + +The analog top registers contain information about the so-called +"metal revision" (which encodes the "minor version") of the SoC. + +Required properties: +- reg: the register range of the analog top registers +- compatible: depending on the SoC this should be one of: + - "amlogic,meson8-analog-top" + - "amlogic,meson8b-analog-top" + along with "syscon" + + +Example: + + analog_top: analog-top@81a8 { + compatible = "amlogic,meson8-analog-top", "syscon"; + reg = <0x81a8 0x14>; + }; diff --git a/Documentation/devicetree/bindings/arm/amlogic/assist.txt b/Documentation/devicetree/bindings/arm/amlogic/assist.txt new file mode 100644 index 000000000000..7656812b67b9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amlogic/assist.txt @@ -0,0 +1,17 @@ +Amlogic Meson6/Meson8/Meson8b assist registers: +----------------------------------------------- + +The assist registers contain basic information about the SoC, +for example the encoded SoC part number. + +Required properties: +- reg: the register range of the assist registers +- compatible: should be "amlogic,meson-mx-assist" along with "syscon" + + +Example: + + assist: assist@7c00 { + compatible = "amlogic,meson-mx-assist", "syscon"; + reg = <0x7c00 0x200>; + }; diff --git a/Documentation/devicetree/bindings/arm/amlogic/bootrom.txt b/Documentation/devicetree/bindings/arm/amlogic/bootrom.txt new file mode 100644 index 000000000000..407e27f230ab --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amlogic/bootrom.txt @@ -0,0 +1,17 @@ +Amlogic Meson6/Meson8/Meson8b bootrom: +-------------------------------------- + +The bootrom register area can be used to access SoC specific +information, such as the "misc version". + +Required properties: +- reg: the register range of the bootrom registers +- compatible: should be "amlogic,meson-mx-bootrom" along with "syscon" + + +Example: + + bootrom: bootrom@d9040000 { + compatible = "amlogic,meson-mx-bootrom", "syscon"; + reg = <0xd9040000 0x10000>; + }; -- cgit v1.2.3 From b330213d98c357859b686b77ad0db9e98fe73763 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Mon, 25 Sep 2017 16:53:50 +0200 Subject: Documentation: devicetree: add pxa3xx compatible and syscon property Document the new pxa3xx_nand driver compatible string for A7k/A8k SoCs that need to access system controller registers in order to enable the NAND controller through the use of a phandle pointed to by the 'marvell,system-controller' property. Signed-off-by: Miquel Raynal Signed-off-by: Boris Brezillon --- Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt index d9b655f11048..d4ee4da58463 100644 --- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt +++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt @@ -5,9 +5,13 @@ Required properties: - compatible: Should be set to one of the following: marvell,pxa3xx-nand marvell,armada370-nand + marvell,armada-8k-nand - reg: The register base for the controller - interrupts: The interrupt to map - #address-cells: Set to <1> if the node includes partitions + - marvell,system-controller: Set to retrieve the syscon node that handles + NAND controller related registers (only required + with marvell,armada-8k-nand compatible). Optional properties: -- cgit v1.2.3 From 13277782dd4bcef71341a1016bee1d09f8f95ae0 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 6 Oct 2017 11:10:38 +0200 Subject: Documentation: add Kernel Driver Statement to the kernel Way back in 2008 we didn't have "robust" in-kernel documentation system, so the idea of putting something like the kernel driver statement in the kernel tree wasn't even imagined. But now that has changed, so add the old document to the kernel source itself to allow for us to properly reference it in one canonical place (as the LF wiki keeps moving things around.) This also will allow people to add their names to it, as I seem to have lost the ability to do that by not knowing how to edit things on the original document. Signed-off-by: Greg Kroah-Hartman Acked-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet --- Documentation/process/index.rst | 1 + Documentation/process/kernel-driver-statement.rst | 199 ++++++++++++++++++++++ 2 files changed, 200 insertions(+) create mode 100644 Documentation/process/kernel-driver-statement.rst (limited to 'Documentation') diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 82fc399fcd33..68454319f006 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -25,6 +25,7 @@ Below are the essential guides that every developer should read. submitting-patches coding-style email-clients + kernel-driver-statement Other guides to the community that are of interest to most developers are: diff --git a/Documentation/process/kernel-driver-statement.rst b/Documentation/process/kernel-driver-statement.rst new file mode 100644 index 000000000000..60d9d868f300 --- /dev/null +++ b/Documentation/process/kernel-driver-statement.rst @@ -0,0 +1,199 @@ +Kernel Driver Statement +----------------------- + +Position Statement on Linux Kernel Modules +========================================== + + +We, the undersigned Linux kernel developers, consider any closed-source +Linux kernel module or driver to be harmful and undesirable. We have +repeatedly found them to be detrimental to Linux users, businesses, and +the greater Linux ecosystem. Such modules negate the openness, +stability, flexibility, and maintainability of the Linux development +model and shut their users off from the expertise of the Linux +community. Vendors that provide closed-source kernel modules force their +customers to give up key Linux advantages or choose new vendors. +Therefore, in order to take full advantage of the cost savings and +shared support benefits open source has to offer, we urge vendors to +adopt a policy of supporting their customers on Linux with open-source +kernel code. + +We speak only for ourselves, and not for any company we might work for +today, have in the past, or will in the future. + + - Dave Airlie + - Nick Andrew + - Jens Axboe + - Ralf Baechle + - Felipe Balbi + - Ohad Ben-Cohen + - Muli Ben-Yehuda + - Jiri Benc + - Arnd Bergmann + - Thomas Bogendoerfer + - Vitaly Bordug + - James Bottomley + - Josh Boyer + - Neil Brown + - Mark Brown + - David Brownell + - Michael Buesch + - Franck Bui-Huu + - Adrian Bunk + - François Cami + - Ralph Campbell + - Luiz Fernando N. Capitulino + - Mauro Carvalho Chehab + - Denis Cheng + - Jonathan Corbet + - Glauber Costa + - Alan Cox + - Magnus Damm + - Ahmed S. Darwish + - Robert P. J. Day + - Hans de Goede + - Arnaldo Carvalho de Melo + - Helge Deller + - Jean Delvare + - Mathieu Desnoyers + - Sven-Thorsten Dietrich + - Alexey Dobriyan + - Daniel Drake + - Alex Dubov + - Randy Dunlap + - Michael Ellerman + - Pekka Enberg + - Jan Engelhardt + - Mark Fasheh + - J. Bruce Fields + - Larry Finger + - Jeremy Fitzhardinge + - Mike Frysinger + - Kumar Gala + - Robin Getz + - Liam Girdwood + - Jan-Benedict Glaw + - Thomas Gleixner + - Brice Goglin + - Cyrill Gorcunov + - Andy Gospodarek + - Thomas Graf + - Krzysztof Halasa + - Harvey Harrison + - Stephen Hemminger + - Michael Hennerich + - Tejun Heo + - Benjamin Herrenschmidt + - Kristian Høgsberg + - Henrique de Moraes Holschuh + - Marcel Holtmann + - Mike Isely + - Takashi Iwai + - Olof Johansson + - Dave Jones + - Jesper Juhl + - Matthias Kaehlcke + - Kenji Kaneshige + - Jan Kara + - Jeremy Kerr + - Russell King + - Olaf Kirch + - Roel Kluin + - Hans-Jürgen Koch + - Auke Kok + - Peter Korsgaard + - Jiri Kosina + - Mariusz Kozlowski + - Greg Kroah-Hartman + - Michael Krufky + - Aneesh Kumar + - Clemens Ladisch + - Christoph Lameter + - Gunnar Larisch + - Anders Larsen + - Grant Likely + - John W. Linville + - Yinghai Lu + - Tony Luck + - Pavel Machek + - Matt Mackall + - Paul Mackerras + - Roland McGrath + - Patrick McHardy + - Kyle McMartin + - Paul Menage + - Thierry Merle + - Eric Miao + - Akinobu Mita + - Ingo Molnar + - James Morris + - Andrew Morton + - Paul Mundt + - Oleg Nesterov + - Luca Olivetti + - S.Çağlar Onur + - Pierre Ossman + - Keith Owens + - Venkatesh Pallipadi + - Nick Piggin + - Nicolas Pitre + - Evgeniy Polyakov + - Richard Purdie + - Mike Rapoport + - Sam Ravnborg + - Gerrit Renker + - Stefan Richter + - David Rientjes + - Luis R. Rodriguez + - Stefan Roese + - Francois Romieu + - Rami Rosen + - Stephen Rothwell + - Maciej W. Rozycki + - Mark Salyzyn + - Yoshinori Sato + - Deepak Saxena + - Holger Schurig + - Amit Shah + - Yoshihiro Shimoda + - Sergei Shtylyov + - Kay Sievers + - Sebastian Siewior + - Rik Snel + - Jes Sorensen + - Alexey Starikovskiy + - Alan Stern + - Timur Tabi + - Hirokazu Takata + - Eliezer Tamir + - Eugene Teo + - Doug Thompson + - FUJITA Tomonori + - Dmitry Torokhov + - Marcelo Tosatti + - Steven Toth + - Theodore Tso + - Matthias Urlichs + - Geert Uytterhoeven + - Arjan van de Ven + - Ivo van Doorn + - Rik van Riel + - Wim Van Sebroeck + - Hans Verkuil + - Horst H. von Brand + - Dmitri Vorobiev + - Anton Vorontsov + - Daniel Walker + - Johannes Weiner + - Harald Welte + - Matthew Wilcox + - Dan J. Williams + - Darrick J. Wong + - David Woodhouse + - Chris Wright + - Bryan Wu + - Rafael J. Wysocki + - Herbert Xu + - Vlad Yasevich + - Peter Zijlstra + - Bartlomiej Zolnierkiewicz -- cgit v1.2.3 From 68e51252224d06e14457de98960a4622993350ab Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 30 Sep 2017 08:43:53 -0700 Subject: Documentation: add kernel-api section on Math functions Add a kernel-api section on Math Functions. Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Corbet --- Documentation/core-api/kernel-api.rst | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 657a89a219b2..9c6902ba6e67 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -103,6 +103,30 @@ idr/ida Functions .. kernel-doc:: lib/idr.c :export: +Math Functions in Linux +======================= + +Base 2 log and power Functions +------------------------------ + +.. kernel-doc:: include/linux/log2.h + :internal: + +Division Functions +------------------ + +.. kernel-doc:: include/asm-generic/div64.h + :functions: do_div + +.. kernel-doc:: include/linux/math64.h + :internal: + +.. kernel-doc:: lib/div64.c + :functions: div_s64_rem div64_u64_rem div64_u64 div64_s64 + +.. kernel-doc:: lib/gcd.c + :export: + Memory Management in Linux ========================== -- cgit v1.2.3 From 58e7cb9e935d53c64414361fba3f95ed261f9110 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Fri, 6 Oct 2017 00:38:49 +0200 Subject: PM: docs: Fix stale reference in kernel-parameters.txt Commit 7aa7a0360a66 (PM: docs: Delete the obsolete states.txt document) forgot to update kernel-parameters.txt with a reference to the new sleep-states.rst document and it still points to states.txt that was dropped, so fix it now. Fixes: 7aa7a0360a66 (PM: docs: Delete the obsolete states.txt document) Signed-off-by: Rafael J. Wysocki Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f02961bda6f4..a3427399fd07 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2248,7 +2248,7 @@ s2idle - Suspend-To-Idle shallow - Power-On Suspend or equivalent (if supported) deep - Suspend-To-RAM or equivalent (if supported) - See Documentation/power/states.txt. + See Documentation/admin-guide/pm/sleep-states.rst. meye.*= [HW] Set MotionEye Camera parameters See Documentation/video4linux/meye.txt. -- cgit v1.2.3 From 00a534e5ea5c21b95f58cbb2f7918cc9fa82dd47 Mon Sep 17 00:00:00 2001 From: Axel Beckert Date: Thu, 5 Oct 2017 22:00:33 +0200 Subject: doc: Fix typo "8023.ad" in bonding documentation Should be "802.3ad" like everywhere else in the document. Signed-off-by: Axel Beckert Signed-off-by: David S. Miller --- Documentation/networking/bonding.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 57f52cdce32e..9ba04c0bab8d 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -2387,7 +2387,7 @@ broadcast: Like active-backup, there is not much advantage to this and packet type ID), so in a "gatewayed" configuration, all outgoing traffic will generally use the same device. Incoming traffic may also end up on a single device, but that is - dependent upon the balancing policy of the peer's 8023.ad + dependent upon the balancing policy of the peer's 802.3ad implementation. In a "local" configuration, traffic will be distributed across the devices in the bond. -- cgit v1.2.3 From 18d59893eb2e836c920856772ead554eb461ef72 Mon Sep 17 00:00:00 2001 From: Pierre-Yves MORDRET Date: Thu, 28 Sep 2017 17:36:40 +0200 Subject: dt-bindings: Document the STM32 MDMA bindings This patch adds documentation of device tree bindings for the STM32 MDMA controller. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET Acked-by: Rob Herring Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/stm32-mdma.txt | 94 ++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/stm32-mdma.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/stm32-mdma.txt b/Documentation/devicetree/bindings/dma/stm32-mdma.txt new file mode 100644 index 000000000000..d18772d6bc65 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/stm32-mdma.txt @@ -0,0 +1,94 @@ +* STMicroelectronics STM32 MDMA controller + +The STM32 MDMA is a general-purpose direct memory access controller capable of +supporting 64 independent DMA channels with 256 HW requests. + +Required properties: +- compatible: Should be "st,stm32h7-mdma" +- reg: Should contain MDMA registers location and length. This should include + all of the per-channel registers. +- interrupts: Should contain the MDMA interrupt. +- clocks: Should contain the input clock of the DMA instance. +- resets: Reference to a reset controller asserting the DMA controller. +- #dma-cells : Must be <5>. See DMA client paragraph for more details. + +Optional properties: +- dma-channels: Number of DMA channels supported by the controller. +- dma-requests: Number of DMA request signals supported by the controller. +- st,ahb-addr-masks: Array of u32 mask to list memory devices addressed via + AHB bus. + +Example: + + mdma1: dma@52000000 { + compatible = "st,stm32h7-mdma"; + reg = <0x52000000 0x1000>; + interrupts = <122>; + clocks = <&timer_clk>; + resets = <&rcc 992>; + #dma-cells = <5>; + dma-channels = <16>; + dma-requests = <32>; + st,ahb-addr-masks = <0x20000000>, <0x00000000>; + }; + +* DMA client + +DMA clients connected to the STM32 MDMA controller must use the format +described in the dma.txt file, using a five-cell specifier for each channel: +a phandle to the MDMA controller plus the following five integer cells: + +1. The request line number +2. The priority level + 0x00: Low + 0x01: Medium + 0x10: High + 0x11: Very high +3. A 32bit mask specifying the DMA channel configuration + -bit 0-1: Source increment mode + 0x00: Source address pointer is fixed + 0x10: Source address pointer is incremented after each data transfer + 0x11: Source address pointer is decremented after each data transfer + -bit 2-3: Destination increment mode + 0x00: Destination address pointer is fixed + 0x10: Destination address pointer is incremented after each data + transfer + 0x11: Destination address pointer is decremented after each data + transfer + -bit 8-9: Source increment offset size + 0x00: byte (8bit) + 0x01: half-word (16bit) + 0x10: word (32bit) + 0x11: double-word (64bit) + -bit 10-11: Destination increment offset size + 0x00: byte (8bit) + 0x01: half-word (16bit) + 0x10: word (32bit) + 0x11: double-word (64bit) +-bit 25-18: The number of bytes to be transferred in a single transfer + (min = 1 byte, max = 128 bytes) +-bit 29:28: Trigger Mode + 0x00: Each MDMA request triggers a buffer transfer (max 128 bytes) + 0x01: Each MDMA request triggers a block transfer (max 64K bytes) + 0x10: Each MDMA request triggers a repeated block transfer + 0x11: Each MDMA request triggers a linked list transfer +4. A 32bit value specifying the register to be used to acknowledge the request + if no HW ack signal is used by the MDMA client +5. A 32bit mask specifying the value to be written to acknowledge the request + if no HW ack signal is used by the MDMA client + +Example: + + i2c4: i2c@5c002000 { + compatible = "st,stm32f7-i2c"; + reg = <0x5c002000 0x400>; + interrupts = <95>, + <96>; + clocks = <&timer_clk>; + #address-cells = <1>; + #size-cells = <0>; + dmas = <&mdma1 36 0x0 0x40008 0x0 0x0>, + <&mdma1 37 0x0 0x40002 0x0 0x0>; + dma-names = "rx", "tx"; + status = "disabled"; + }; -- cgit v1.2.3 From 5543de66e26776c20ecfb9e498c2561d74823ec3 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Fri, 6 Oct 2017 18:15:17 +0100 Subject: dmaengine: usb-dmac: Add compatible string for r8a7743/5 This patch adds support for r8a7743/5 SoCs. The Renesas RZ/G1[ME] (R8A7743/5) usbdmac engine is identical to the R-Car Gen2 family. No driver change is needed due to the fallback compatible value "renesas,r8a7743-usb-dmac". Adding the SoC-specific compatible values here has two purposes: 1. Document which SoCs have this hardware module, 2. Allow checkpatch to validate compatible values. Signed-off-by: Biju Das Signed-off-by: Chris Paterson Reviewed-by: Geert Uytterhoeven Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt index 1be6941ac1e5..f3d1f151ba80 100644 --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt @@ -3,6 +3,8 @@ Required Properties: -compatible: "renesas,-usb-dmac", "renesas,usb-dmac" as fallback. Examples with soctypes are: + - "renesas,r8a7743-usb-dmac" (RZ/G1M) + - "renesas,r8a7745-usb-dmac" (RZ/G1E) - "renesas,r8a7790-usb-dmac" (R-Car H2) - "renesas,r8a7791-usb-dmac" (R-Car M2-W) - "renesas,r8a7793-usb-dmac" (R-Car M2-N) -- cgit v1.2.3 From c40610198f35e8264f9175dafe74db6288a07eda Mon Sep 17 00:00:00 2001 From: Marek Szyprowski Date: Wed, 4 Oct 2017 08:38:23 +0200 Subject: soc: samsung: Remove Exynos4212 related dead code Support for Exynos4212 SoCs has been removed by commit bca9085e0ae9 ("ARM: dts: exynos: remove Exynos4212 support (dead code)"), so there is no need to keep remaining dead code related to this SoC version. Signed-off-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt index bf5fc59a6938..87ed95512b63 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -4,7 +4,6 @@ Properties: - compatible : should contain two values. First value must be one from following list: - "samsung,exynos3250-pmu" - for Exynos3250 SoC, - "samsung,exynos4210-pmu" - for Exynos4210 SoC, - - "samsung,exynos4212-pmu" - for Exynos4212 SoC, - "samsung,exynos4412-pmu" - for Exynos4412 SoC, - "samsung,exynos5250-pmu" - for Exynos5250 SoC, - "samsung,exynos5260-pmu" - for Exynos5260 SoC. -- cgit v1.2.3 From 78005d91c11ea45a93e68c7d59079784f4c46828 Mon Sep 17 00:00:00 2001 From: Haiyang Zhang Date: Fri, 6 Oct 2017 08:33:59 -0700 Subject: hv_netvsc: Update netvsc Document for TCP hash level setting Update Documentation/networking/netvsc.txt for TCP hash level setting and related info. Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller --- Documentation/networking/netvsc.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netvsc.txt b/Documentation/networking/netvsc.txt index 93560fb1170a..92f5b31392fa 100644 --- a/Documentation/networking/netvsc.txt +++ b/Documentation/networking/netvsc.txt @@ -19,12 +19,12 @@ Features Receive Side Scaling -------------------- - Hyper-V supports receive side scaling. For TCP, packets are - distributed among available queues based on IP address and port + Hyper-V supports receive side scaling. For TCP & UDP, packets can + be distributed among available queues based on IP address and port number. - For UDP, we can switch UDP hash level between L3 and L4 by ethtool - command. UDP over IPv4 and v6 can be set differently. The default + For TCP & UDP, we can switch hash level between L3 and L4 by ethtool + command. TCP/UDP over IPv4 and v6 can be set differently. The default hash level is L4. We currently only allow switching TX hash level from within the guests. -- cgit v1.2.3 From 4a9cfe47b8ea3f7b8c551a365184f4aec993ee5d Mon Sep 17 00:00:00 2001 From: Chris Brandt Date: Wed, 4 Oct 2017 16:07:24 -0500 Subject: dt-bindings: pinctrl: Add support for RZ/A1M and RZ/A1L Describe how to specify RZ/A1M and RZ/A1L devices. Signed-off-by: Chris Brandt Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt index 43e21474528a..fd3696eb36bf 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt @@ -12,8 +12,10 @@ Pin controller node ------------------- Required properties: - - compatible - this shall be "renesas,r7s72100-ports". + - compatible: should be: + - "renesas,r7s72100-ports": for RZ/A1H + - "renesas,r7s72101-ports", "renesas,r7s72100-ports": for RZ/A1M + - "renesas,r7s72102-ports": for RZ/A1L - reg address base and length of the memory area where the pin controller -- cgit v1.2.3 From c78ae068de3c927e195f1628239bc701f8b5f402 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sat, 7 Oct 2017 12:46:57 +0200 Subject: dt-bindings: adi,adv7511.txt: document cec clock Document the cec clock binding. Signed-off-by: Hans Verkuil Acked-by: Rob Herring Signed-off-by: Archit Taneja Link: https://patchwork.freedesktop.org/patch/msgid/20171007104658.14528-2-hverkuil@xs4all.nl --- Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index 06668bca7ffc..0047b1394c70 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt @@ -68,6 +68,8 @@ Optional properties: - adi,disable-timing-generator: Only for ADV7533. Disables the internal timing generator. The chip will rely on the sync signals in the DSI data lanes, rather than generate its own timings for HDMI output. +- clocks: from common clock binding: reference to the CEC clock. +- clock-names: from common clock binding: must be "cec". Required nodes: @@ -89,6 +91,8 @@ Example reg = <39>; interrupt-parent = <&gpio3>; interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + clocks = <&cec_clock>; + clock-names = "cec"; adi,input-depth = <8>; adi,input-colorspace = "rgb"; -- cgit v1.2.3 From b091b9ed1b133455dd46346411dfa7526e889a8f Mon Sep 17 00:00:00 2001 From: "Ismail H. Kose" Date: Fri, 22 Sep 2017 13:12:09 -0700 Subject: iio:dac: Add DT binding documentation for ds4424 Signed-off-by: Ismail H. Kose Signed-off-by: Ismail H. Kose Acked-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/dac/ds4424.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/ds4424.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/ds4424.txt b/Documentation/devicetree/bindings/iio/dac/ds4424.txt new file mode 100644 index 000000000000..eaebbf8dab40 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/ds4424.txt @@ -0,0 +1,20 @@ +Maxim Integrated DS4422/DS4424 7-bit Sink/Source Current DAC Device Driver + +Datasheet publicly available at: +https://datasheets.maximintegrated.com/en/ds/DS4422-DS4424.pdf + +Required properties: + - compatible: Should be one of + maxim,ds4422 + maxim,ds4424 + - reg: Should contain the DAC I2C address + +Optional properties: + - vcc-supply: Power supply is optional. If not defined, driver will ignore it. + +Example: + ds4224@10 { + compatible = "maxim,ds4424"; + reg = <0x10>; /* When A0, A1 pins are ground */ + vcc-supply = <&vcc_3v3>; + }; -- cgit v1.2.3 From 7886082dfb6ab8221b1b5509a582256040820c2e Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Wed, 30 Aug 2017 13:50:43 +0200 Subject: dt-bindings: iio: accel: add LIS2DW12 sensor device binding Signed-off-by: Lorenzo Bianconi Acked-by: Rob Herring Reviewed-by: Linus Walleij Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/st-sensors.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt index 678c035d9ed6..9cfc82d21792 100644 --- a/Documentation/devicetree/bindings/iio/st-sensors.txt +++ b/Documentation/devicetree/bindings/iio/st-sensors.txt @@ -46,6 +46,7 @@ Accelerometers: - st,h3lis331dl-accel - st,lng2dm-accel - st,lis3l02dq +- st,lis2dw12 Gyroscopes: - st,l3g4200d-gyro -- cgit v1.2.3 From bb7e5ce7dde6f42e7793bd6cf4b1eb71a20145aa Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Mon, 7 Aug 2017 17:23:20 -0700 Subject: documentation: RCU grace-period memory ordering guarantees This commit provides text and diagrams showing how Tree RCU implements its grace-period memory ordering guarantees. Signed-off-by: Paul E. McKenney Cc: Jonathan Corbet Cc: Linus Torvalds --- .../Design/Memory-Ordering/Tree-RCU-Diagram.html | 9 + .../Memory-Ordering/Tree-RCU-Memory-Ordering.html | 707 +++ .../TreeRCU-callback-invocation.svg | 486 ++ .../Memory-Ordering/TreeRCU-callback-registry.svg | 655 +++ .../RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg | 700 +++ .../Design/Memory-Ordering/TreeRCU-gp-cleanup.svg | 1126 +++++ .../RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg | 1309 +++++ .../Design/Memory-Ordering/TreeRCU-gp-init-1.svg | 656 +++ .../Design/Memory-Ordering/TreeRCU-gp-init-2.svg | 656 +++ .../Design/Memory-Ordering/TreeRCU-gp-init-3.svg | 632 +++ .../RCU/Design/Memory-Ordering/TreeRCU-gp.svg | 5135 ++++++++++++++++++++ .../RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg | 775 +++ .../RCU/Design/Memory-Ordering/TreeRCU-qs.svg | 1095 +++++ .../RCU/Design/Memory-Ordering/rcu_node-lock.svg | 229 + 14 files changed, 14170 insertions(+) create mode 100644 Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Diagram.html create mode 100644 Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-invocation.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-cleanup.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-1.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-2.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-3.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/TreeRCU-qs.svg create mode 100644 Documentation/RCU/Design/Memory-Ordering/rcu_node-lock.svg (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Diagram.html b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Diagram.html new file mode 100644 index 000000000000..e5b42a798ff3 --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Diagram.html @@ -0,0 +1,9 @@ + + + A Diagram of TREE_RCU's Grace-Period Memory Ordering + + +

TreeRCU-gp.svg + + diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html new file mode 100644 index 000000000000..8651b0b4fd79 --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html @@ -0,0 +1,707 @@ + + + A Tour Through TREE_RCU's Grace-Period Memory Ordering + + +

August 8, 2017

+

This article was contributed by Paul E. McKenney

+ +

Introduction

+ +

This document gives a rough visual overview of how Tree RCU's +grace-period memory ordering guarantee is provided. + +

    +
  1. + What Is Tree RCU's Grace Period Memory Ordering Guarantee? +
  2. + Tree RCU Grace Period Memory Ordering Building Blocks +
  3. + Tree RCU Grace Period Memory Ordering Components +
  4. Putting It All Together +
+ +

+What Is Tree RCU's Grace Period Memory Ordering Guarantee?

+ +

RCU grace periods provide extremely strong memory-ordering guarantees +for non-idle non-offline code. +Any code that happens after the end of a given RCU grace period is guaranteed +to see the effects of all accesses prior to the beginning of that grace +period that are within RCU read-side critical sections. +Similarly, any code that happens before the beginning of a given RCU grace +period is guaranteed to see the effects of all accesses following the end +of that grace period that are within RCU read-side critical sections. + +

This guarantee is particularly pervasive for synchronize_sched(), +for which RCU-sched read-side critical sections include any region +of code for which preemption is disabled. +Given that each individual machine instruction can be thought of as +an extremely small region of preemption-disabled code, one can think of +synchronize_sched() as smp_mb() on steroids. + +

RCU updaters use this guarantee by splitting their updates into +two phases, one of which is executed before the grace period and +the other of which is executed after the grace period. +In the most common use case, phase one removes an element from +a linked RCU-protected data structure, and phase two frees that element. +For this to work, any readers that have witnessed state prior to the +phase-one update (in the common case, removal) must not witness state +following the phase-two update (in the common case, freeing). + +

The RCU implementation provides this guarantee using a network +of lock-based critical sections, memory barriers, and per-CPU +processing, as is described in the following sections. + +

+Tree RCU Grace Period Memory Ordering Building Blocks

+ +

The workhorse for RCU's grace-period memory ordering is the +critical section for the rcu_node structure's +->lock. +These critical sections use helper functions for lock acquisition, including +raw_spin_lock_rcu_node(), +raw_spin_lock_irq_rcu_node(), and +raw_spin_lock_irqsave_rcu_node(). +Their lock-release counterparts are +raw_spin_unlock_rcu_node(), +raw_spin_unlock_irq_rcu_node(), and +raw_spin_unlock_irqrestore_rcu_node(), +respectively. +For completeness, a +raw_spin_trylock_rcu_node() +is also provided. +The key point is that the lock-acquisition functions, including +raw_spin_trylock_rcu_node(), all invoke +smp_mb__after_unlock_lock() immediately after successful +acquisition of the lock. + +

Therefore, for any given rcu_node struction, any access +happening before one of the above lock-release functions will be seen +by all CPUs as happening before any access happening after a later +one of the above lock-acquisition functions. +Furthermore, any access happening before one of the +above lock-release function on any given CPU will be seen by all +CPUs as happening before any access happening after a later one +of the above lock-acquisition functions executing on that same CPU, +even if the lock-release and lock-acquisition functions are operating +on different rcu_node structures. +Tree RCU uses these two ordering guarantees to form an ordering +network among all CPUs that were in any way involved in the grace +period, including any CPUs that came online or went offline during +the grace period in question. + +

The following litmus test exhibits the ordering effects of these +lock-acquisition and lock-release functions: + +

+ 1 int x, y, z;
+ 2
+ 3 void task0(void)
+ 4 {
+ 5   raw_spin_lock_rcu_node(rnp);
+ 6   WRITE_ONCE(x, 1);
+ 7   r1 = READ_ONCE(y);
+ 8   raw_spin_unlock_rcu_node(rnp);
+ 9 }
+10
+11 void task1(void)
+12 {
+13   raw_spin_lock_rcu_node(rnp);
+14   WRITE_ONCE(y, 1);
+15   r2 = READ_ONCE(z);
+16   raw_spin_unlock_rcu_node(rnp);
+17 }
+18
+19 void task2(void)
+20 {
+21   WRITE_ONCE(z, 1);
+22   smp_mb();
+23   r3 = READ_ONCE(x);
+24 }
+25
+26 WARN_ON(r1 == 0 && r2 == 0 && r3 == 0);
+
+ +

The WARN_ON() is evaluated at “the end of time”, +after all changes have propagated throughout the system. +Without the smp_mb__after_unlock_lock() provided by the +acquisition functions, this WARN_ON() could trigger, for example +on PowerPC. +The smp_mb__after_unlock_lock() invocations prevent this +WARN_ON() from triggering. + +

This approach must be extended to include idle CPUs, which need +RCU's grace-period memory ordering guarantee to extend to any +RCU read-side critical sections preceding and following the current +idle sojourn. +This case is handled by calls to the strongly ordered +atomic_add_return() read-modify-write atomic operation that +is invoked within rcu_dynticks_eqs_enter() at idle-entry +time and within rcu_dynticks_eqs_exit() at idle-exit time. +The grace-period kthread invokes rcu_dynticks_snap() and +rcu_dynticks_in_eqs_since() (both of which invoke +an atomic_add_return() of zero) to detect idle CPUs. + + + + + + + + +
 
Quick Quiz:
+ But what about CPUs that remain offline for the entire + grace period? +
Answer:
+ Such CPUs will be offline at the beginning of the grace period, + so the grace period won't expect quiescent states from them. + Races between grace-period start and CPU-hotplug operations + are mediated by the CPU's leaf rcu_node structure's + ->lock as described above. +
 
+ +

The approach must be extended to handle one final case, that +of waking a task blocked in synchronize_rcu(). +This task might be affinitied to a CPU that is not yet aware that +the grace period has ended, and thus might not yet be subject to +the grace period's memory ordering. +Therefore, there is an smp_mb() after the return from +wait_for_completion() in the synchronize_rcu() +code path. + + + + + + + + +
 
Quick Quiz:
+ What? Where??? + I don't see any smp_mb() after the return from + wait_for_completion()!!! +
Answer:
+ That would be because I spotted the need for that + smp_mb() during the creation of this documentation, + and it is therefore unlikely to hit mainline before v4.14. + Kudos to Lance Roy, Will Deacon, Peter Zijlstra, and + Jonathan Cameron for asking questions that sensitized me + to the rather elaborate sequence of events that demonstrate + the need for this memory barrier. +
 
+ +

Tree RCU's grace--period memory-ordering guarantees rely most +heavily on the rcu_node structure's ->lock +field, so much so that it is necessary to abbreviate this pattern +in the diagrams in the next section. +For example, consider the rcu_prepare_for_idle() function +shown below, which is one of several functions that enforce ordering +of newly arrived RCU callbacks against future grace periods: + +

+ 1 static void rcu_prepare_for_idle(void)
+ 2 {
+ 3   bool needwake;
+ 4   struct rcu_data *rdp;
+ 5   struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ 6   struct rcu_node *rnp;
+ 7   struct rcu_state *rsp;
+ 8   int tne;
+ 9
+10   if (IS_ENABLED(CONFIG_RCU_NOCB_CPU_ALL) ||
+11       rcu_is_nocb_cpu(smp_processor_id()))
+12     return;
+13   tne = READ_ONCE(tick_nohz_active);
+14   if (tne != rdtp->tick_nohz_enabled_snap) {
+15     if (rcu_cpu_has_callbacks(NULL))
+16       invoke_rcu_core();
+17     rdtp->tick_nohz_enabled_snap = tne;
+18     return;
+19   }
+20   if (!tne)
+21     return;
+22   if (rdtp->all_lazy &&
+23       rdtp->nonlazy_posted != rdtp->nonlazy_posted_snap) {
+24     rdtp->all_lazy = false;
+25     rdtp->nonlazy_posted_snap = rdtp->nonlazy_posted;
+26     invoke_rcu_core();
+27     return;
+28   }
+29   if (rdtp->last_accelerate == jiffies)
+30     return;
+31   rdtp->last_accelerate = jiffies;
+32   for_each_rcu_flavor(rsp) {
+33     rdp = this_cpu_ptr(rsp->rda);
+34     if (rcu_segcblist_pend_cbs(&rdp->cblist))
+35       continue;
+36     rnp = rdp->mynode;
+37     raw_spin_lock_rcu_node(rnp);
+38     needwake = rcu_accelerate_cbs(rsp, rnp, rdp);
+39     raw_spin_unlock_rcu_node(rnp);
+40     if (needwake)
+41       rcu_gp_kthread_wake(rsp);
+42   }
+43 }
+
+ +

But the only part of rcu_prepare_for_idle() that really +matters for this discussion are lines 37–39. +We will therefore abbreviate this function as follows: + +

rcu_node-lock.svg + +

The box represents the rcu_node structure's ->lock +critical section, with the double line on top representing the additional +smp_mb__after_unlock_lock(). + +

+Tree RCU Grace Period Memory Ordering Components

+ +

Tree RCU's grace-period memory-ordering guarantee is provided by +a number of RCU components: + +

    +
  1. Callback Registry +
  2. Grace-Period Initialization +
  3. + Self-Reported Quiescent States +
  4. Dynamic Tick Interface +
  5. CPU-Hotplug Interface +
  6. Forcing Quiescent States +
  7. Grace-Period Cleanup +
  8. Callback Invocation +
+ +

Each of the following section looks at the corresponding component +in detail. + +

Callback Registry

+ +

If RCU's grace-period guarantee is to mean anything at all, any +access that happens before a given invocation of call_rcu() +must also happen before the corresponding grace period. +The implementation of this portion of RCU's grace period guarantee +is shown in the following figure: + +

TreeRCU-callback-registry.svg + +

Because call_rcu() normally acts only on CPU-local state, +it provides no ordering guarantees, either for itself or for +phase one of the update (which again will usually be removal of +an element from an RCU-protected data structure). +It simply enqueues the rcu_head structure on a per-CPU list, +which cannot become associated with a grace period until a later +call to rcu_accelerate_cbs(), as shown in the diagram above. + +

One set of code paths shown on the left invokes +rcu_accelerate_cbs() via +note_gp_changes(), either directly from call_rcu() (if +the current CPU is inundated with queued rcu_head structures) +or more likely from an RCU_SOFTIRQ handler. +Another code path in the middle is taken only in kernels built with +CONFIG_RCU_FAST_NO_HZ=y, which invokes +rcu_accelerate_cbs() via rcu_prepare_for_idle(). +The final code path on the right is taken only in kernels built with +CONFIG_HOTPLUG_CPU=y, which invokes +rcu_accelerate_cbs() via +rcu_advance_cbs(), rcu_migrate_callbacks, +rcutree_migrate_callbacks(), and takedown_cpu(), +which in turn is invoked on a surviving CPU after the outgoing +CPU has been completely offlined. + +

There are a few other code paths within grace-period processing +that opportunistically invoke rcu_accelerate_cbs(). +However, either way, all of the CPU's recently queued rcu_head +structures are associated with a future grace-period number under +the protection of the CPU's lead rcu_node structure's +->lock. +In all cases, there is full ordering against any prior critical section +for that same rcu_node structure's ->lock, and +also full ordering against any of the current task's or CPU's prior critical +sections for any rcu_node structure's ->lock. + +

The next section will show how this ordering ensures that any +accesses prior to the call_rcu() (particularly including phase +one of the update) +happen before the start of the corresponding grace period. + + + + + + + + +
 
Quick Quiz:
+ But what about synchronize_rcu()? +
Answer:
+ The synchronize_rcu() passes call_rcu() + to wait_rcu_gp(), which invokes it. + So either way, it eventually comes down to call_rcu(). +
 
+ +

Grace-Period Initialization

+ +

Grace-period initialization is carried out by +the grace-period kernel thread, which makes several passes over the +rcu_node tree within the rcu_gp_init() function. +This means that showing the full flow of ordering through the +grace-period computation will require duplicating this tree. +If you find this confusing, please note that the state of the +rcu_node changes over time, just like Heraclitus's river. +However, to keep the rcu_node river tractable, the +grace-period kernel thread's traversals are presented in multiple +parts, starting in this section with the various phases of +grace-period initialization. + +

The first ordering-related grace-period initialization action is to +increment the rcu_state structure's ->gpnum +grace-period-number counter, as shown below: + +

TreeRCU-gp-init-1.svg + +

The actual increment is carried out using smp_store_release(), +which helps reject false-positive RCU CPU stall detection. +Note that only the root rcu_node structure is touched. + +

The first pass through the rcu_node tree updates bitmasks +based on CPUs having come online or gone offline since the start of +the previous grace period. +In the common case where the number of online CPUs for this rcu_node +structure has not transitioned to or from zero, +this pass will scan only the leaf rcu_node structures. +However, if the number of online CPUs for a given leaf rcu_node +structure has transitioned from zero, +rcu_init_new_rnp() will be invoked for the first incoming CPU. +Similarly, if the number of online CPUs for a given leaf rcu_node +structure has transitioned to zero, +rcu_cleanup_dead_rnp() will be invoked for the last outgoing CPU. +The diagram below shows the path of ordering if the leftmost +rcu_node structure onlines its first CPU and if the next +rcu_node structure has no online CPUs +(or, alternatively if the leftmost rcu_node structure offlines +its last CPU and if the next rcu_node structure has no online CPUs). + +

TreeRCU-gp-init-1.svg + +

The final rcu_gp_init() pass through the rcu_node +tree traverses breadth-first, setting each rcu_node structure's +->gpnum field to the newly incremented value from the +rcu_state structure, as shown in the following diagram. + +

TreeRCU-gp-init-1.svg + +

This change will also cause each CPU's next call to +__note_gp_changes() +to notice that a new grace period has started, as described in the next +section. +But because the grace-period kthread started the grace period at the +root (with the increment of the rcu_state structure's +->gpnum field) before setting each leaf rcu_node +structure's ->gpnum field, each CPU's observation of +the start of the grace period will happen after the actual start +of the grace period. + + + + + + + + +
 
Quick Quiz:
+ But what about the CPU that started the grace period? + Why wouldn't it see the start of the grace period right when + it started that grace period? +
Answer:
+ In some deep philosophical and overly anthromorphized + sense, yes, the CPU starting the grace period is immediately + aware of having done so. + However, if we instead assume that RCU is not self-aware, + then even the CPU starting the grace period does not really + become aware of the start of this grace period until its + first call to __note_gp_changes(). + On the other hand, this CPU potentially gets early notification + because it invokes __note_gp_changes() during its + last rcu_gp_init() pass through its leaf + rcu_node structure. +
 
+ +

+Self-Reported Quiescent States

+ +

When all entities that might block the grace period have reported +quiescent states (or as described in a later section, had quiescent +states reported on their behalf), the grace period can end. +Online non-idle CPUs report their own quiescent states, as shown +in the following diagram: + +

TreeRCU-qs.svg + +

This is for the last CPU to report a quiescent state, which signals +the end of the grace period. +Earlier quiescent states would push up the rcu_node tree +only until they encountered an rcu_node structure that +is waiting for additional quiescent states. +However, ordering is nevertheless preserved because some later quiescent +state will acquire that rcu_node structure's ->lock. + +

Any number of events can lead up to a CPU invoking +note_gp_changes (or alternatively, directly invoking +__note_gp_changes()), at which point that CPU will notice +the start of a new grace period while holding its leaf +rcu_node lock. +Therefore, all execution shown in this diagram happens after the +start of the grace period. +In addition, this CPU will consider any RCU read-side critical +section that started before the invocation of __note_gp_changes() +to have started before the grace period, and thus a critical +section that the grace period must wait on. + + + + + + + + +
 
Quick Quiz:
+ But a RCU read-side critical section might have started + after the beginning of the grace period + (the ->gpnum++ from earlier), so why should + the grace period wait on such a critical section? +
Answer:
+ It is indeed not necessary for the grace period to wait on such + a critical section. + However, it is permissible to wait on it. + And it is furthermore important to wait on it, as this + lazy approach is far more scalable than a “big bang” + all-at-once grace-period start could possibly be. +
 
+ +

If the CPU does a context switch, a quiescent state will be +noted by rcu_node_context_switch() on the left. +On the other hand, if the CPU takes a scheduler-clock interrupt +while executing in usermode, a quiescent state will be noted by +rcu_check_callbacks() on the right. +Either way, the passage through a quiescent state will be noted +in a per-CPU variable. + +

The next time an RCU_SOFTIRQ handler executes on +this CPU (for example, after the next scheduler-clock +interrupt), __rcu_process_callbacks() will invoke +rcu_check_quiescent_state(), which will notice the +recorded quiescent state, and invoke +rcu_report_qs_rdp(). +If rcu_report_qs_rdp() verifies that the quiescent state +really does apply to the current grace period, it invokes +rcu_report_rnp() which traverses up the rcu_node +tree as shown at the bottom of the diagram, clearing bits from +each rcu_node structure's ->qsmask field, +and propagating up the tree when the result is zero. + +

Note that traversal passes upwards out of a given rcu_node +structure only if the current CPU is reporting the last quiescent +state for the subtree headed by that rcu_node structure. +A key point is that if a CPU's traversal stops at a given rcu_node +structure, then there will be a later traversal by another CPU +(or perhaps the same one) that proceeds upwards +from that point, and the rcu_node ->lock +guarantees that the first CPU's quiescent state happens before the +remainder of the second CPU's traversal. +Applying this line of thought repeatedly shows that all CPUs' +quiescent states happen before the last CPU traverses through +the root rcu_node structure, the “last CPU” +being the one that clears the last bit in the root rcu_node +structure's ->qsmask field. + +

Dynamic Tick Interface

+ +

Due to energy-efficiency considerations, RCU is forbidden from +disturbing idle CPUs. +CPUs are therefore required to notify RCU when entering or leaving idle +state, which they do via fully ordered value-returning atomic operations +on a per-CPU variable. +The ordering effects are as shown below: + +

TreeRCU-dyntick.svg + +

The RCU grace-period kernel thread samples the per-CPU idleness +variable while holding the corresponding CPU's leaf rcu_node +structure's ->lock. +This means that any RCU read-side critical sections that precede the +idle period (the oval near the top of the diagram above) will happen +before the end of the current grace period. +Similarly, the beginning of the current grace period will happen before +any RCU read-side critical sections that follow the +idle period (the oval near the bottom of the diagram above). + +

Plumbing this into the full grace-period execution is described +below. + +

CPU-Hotplug Interface

+ +

RCU is also forbidden from disturbing offline CPUs, which might well +be powered off and removed from the system completely. +CPUs are therefore required to notify RCU of their comings and goings +as part of the corresponding CPU hotplug operations. +The ordering effects are shown below: + +

TreeRCU-hotplug.svg + +

Because CPU hotplug operations are much less frequent than idle transitions, +they are heavier weight, and thus acquire the CPU's leaf rcu_node +structure's ->lock and update this structure's +->qsmaskinitnext. +The RCU grace-period kernel thread samples this mask to detect CPUs +having gone offline since the beginning of this grace period. + +

Plumbing this into the full grace-period execution is described +below. + +

Forcing Quiescent States

+ +

As noted above, idle and offline CPUs cannot report their own +quiescent states, and therefore the grace-period kernel thread +must do the reporting on their behalf. +This process is called “forcing quiescent states”, it is +repeated every few jiffies, and its ordering effects are shown below: + +

TreeRCU-gp-fqs.svg + +

Each pass of quiescent state forcing is guaranteed to traverse the +leaf rcu_node structures, and if there are no new quiescent +states due to recently idled and/or offlined CPUs, then only the +leaves are traversed. +However, if there is a newly offlined CPU as illustrated on the left +or a newly idled CPU as illustrated on the right, the corresponding +quiescent state will be driven up towards the root. +As with self-reported quiescent states, the upwards driving stops +once it reaches an rcu_node structure that has quiescent +states outstanding from other CPUs. + + + + + + + + +
 
Quick Quiz:
+ The leftmost drive to root stopped before it reached + the root rcu_node structure, which means that + there are still CPUs subordinate to that structure on + which the current grace period is waiting. + Given that, how is it possible that the rightmost drive + to root ended the grace period? +
Answer:
+ Good analysis! + It is in fact impossible in the absence of bugs in RCU. + But this diagram is complex enough as it is, so simplicity + overrode accuracy. + You can think of it as poetic license, or you can think of + it as misdirection that is resolved in the + stitched-together diagram. +
 
+ +

Grace-Period Cleanup

+ +

Grace-period cleanup first scans the rcu_node tree +breadth-first setting all the ->completed fields equal +to the number of the newly completed grace period, then it sets +the rcu_state structure's ->completed field, +again to the number of the newly completed grace period. +The ordering effects are shown below: + +

TreeRCU-gp-cleanup.svg + +

As indicated by the oval at the bottom of the diagram, once +grace-period cleanup is complete, the next grace period can begin. + + + + + + + + +
 
Quick Quiz:
+ But when precisely does the grace period end? +
Answer:
+ There is no useful single point at which the grace period + can be said to end. + The earliest reasonable candidate is as soon as the last + CPU has reported its quiescent state, but it may be some + milliseconds before RCU becomes aware of this. + The latest reasonable candidate is once the rcu_state + structure's ->completed field has been updated, + but it is quite possible that some CPUs have already completed + phase two of their updates by that time. + In short, if you are going to work with RCU, you need to + learn to embrace uncertainty. +
 
+ + +

Callback Invocation

+ +

Once a given CPU's leaf rcu_node structure's +->completed field has been updated, that CPU can begin +invoking its RCU callbacks that were waiting for this grace period +to end. +These callbacks are identified by rcu_advance_cbs(), +which is usually invoked by __note_gp_changes(). +As shown in the diagram below, this invocation can be triggered by +the scheduling-clock interrupt (rcu_check_callbacks() on +the left) or by idle entry (rcu_cleanup_after_idle() on +the right, but only for kernels build with +CONFIG_RCU_FAST_NO_HZ=y). +Either way, RCU_SOFTIRQ is raised, which results in +rcu_do_batch() invoking the callbacks, which in turn +allows those callbacks to carry out (either directly or indirectly +via wakeup) the needed phase-two processing for each update. + +

TreeRCU-callback-invocation.svg + +

Please note that callback invocation can also be prompted by any +number of corner-case code paths, for example, when a CPU notes that +it has excessive numbers of callbacks queued. +In all cases, the CPU acquires its leaf rcu_node structure's +->lock before invoking callbacks, which preserves the +required ordering against the newly completed grace period. + +

However, if the callback function communicates to other CPUs, +for example, doing a wakeup, then it is that function's responsibility +to maintain ordering. +For example, if the callback function wakes up a task that runs on +some other CPU, proper ordering must in place in both the callback +function and the task being awakened. +To see why this is important, consider the top half of the +grace-period cleanup diagram. +The callback might be running on a CPU corresponding to the leftmost +leaf rcu_node structure, and awaken a task that is to run on +a CPU corresponding to the rightmost leaf rcu_node structure, +and the grace-period kernel thread might not yet have reached the +rightmost leaf. +In this case, the grace period's memory ordering might not yet have +reached that CPU, so again the callback function and the awakened +task must supply proper ordering. + +

Putting It All Together

+ +

A stitched-together diagram is +here. + +

+Legal Statement

+ +

This work represents the view of the author and does not necessarily +represent the view of IBM. + +

Linux is a registered trademark of Linus Torvalds. + +

Other company, product, and service names may be trademarks or +service marks of others. + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-invocation.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-invocation.svg new file mode 100644 index 000000000000..832408313d93 --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-invocation.svg @@ -0,0 +1,486 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + rcu_check_callbacks() + + rcu_cleanup_after_idle() + + rcu_advance_cbs() + + + Leaf + __note_gp_changes() + + + + Phase Two + of Update + + + RCU_SOFTIRQ + rcu_do_batch() + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg new file mode 100644 index 000000000000..7ac6f9269806 --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg @@ -0,0 +1,655 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + rcu_accelerate_cbs() + + + + + rcu_prepare_for_idle() + + rcu_accelerate_cbs() + + + + + note_gp_changes() + rcu_advance_cbs() + __note_gp_changes() + + call_rcu() + + Wake up + grace-period + kernel thread + + rcu_accelerate_cbs() + + + + + takedown_cpu() + rcutree_migrate_callbacks() + rcu_migrate_callbacks() + rcu_advance_cbs() + Leaf + Leaf + Leaf + + Phase One + of Update + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg new file mode 100644 index 000000000000..423df00c4df9 --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg @@ -0,0 +1,700 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ->qsmask &= ~->grpmask + Leaf + dyntick_save_progress_counter() + rcu_implicit_dynticks_qs() + + + + RCU + read-side + critical section + + + + rcu_dynticks_eqs_enter() + atomic_add_return() + + + + rcu_dynticks_eqs_exit() + atomic_add_return() + + + + RCU + read-side + critical section + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-cleanup.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-cleanup.svg new file mode 100644 index 000000000000..754f426b297a --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-cleanup.svg @@ -0,0 +1,1126 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ->completed = ->gpnum + + + + + Root + + + rcu_gp_cleanup() + + + + + + ->completed = ->gpnum + + + + + + + Leaf + ->completed = ->gpnum + + + rsp->completed = + + + + + Root + rnp->completed + + + + + + + + + + + + Leaf + + + + + + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + + + + + + + + + + + + + + ->completed = ->gpnum + + + + + + + Leaf + + + + + + + Leaf + ->completed = ->gpnum + + + + + + + Leaf + ->completed = ->gpnum + + + + + + + + ->completed = ->gpnum + + + Start of + Next Grace + Period + + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg new file mode 100644 index 000000000000..7ddc094d7f28 --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg @@ -0,0 +1,1309 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + rcu_gp_fqs() + + + + + + ->qsmask &= ~->grpmask + + + + + + + Leaf + + + + + + + ->qsmask &= ~->grpmask + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + ->qsmask &= ~->grpmask + + + + + + + + + force_qs_rnp() + dyntick_save_progress_counter() + + + + + + Root + ->qsmask &= ~->grpmask + + rcu_implicit_dynticks_qs() + ->qsmask &= ~->grpmask + + + RCU + read-side + critical section + + + + rcu_dynticks_eqs_enter() + atomic_add_return() + + + + rcu_dynticks_eqs_exit() + atomic_add_return() + + + + RCU + read-side + critical section + + + + RCU + read-side + critical section + + + + rcu_report_dead() + rcu_cleanup_dying_idle_cpu() + + + + + ->qsmaskinitnext + Leaf + + + + RCU + read-side + critical section + + + + rcu_cpu_starting() + + + + + ->qsmaskinitnext + Leaf + + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-1.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-1.svg new file mode 100644 index 000000000000..0161262904ec --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-1.svg @@ -0,0 +1,656 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + rsp->gpnum++ + + + + + Root + + + rcu_gp_init() + + + + + + + + + + + + Leaf + + + + + + + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + + + + + + + + + + End of + Last Grace + Period + + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-2.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-2.svg new file mode 100644 index 000000000000..4d956a732685 --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-2.svg @@ -0,0 +1,656 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + rcu_gp_init() + + + + + + + + + + + + Leaf + + + + + + + ->qsmaskinit + ->qsmaskinitnext + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + ->qsmaskinit + + + + + + + + + rcu_init_new_rnp() or + rcu_cleanup_dead_rnp() + (optional) + + ->qsmaskinit + + + + + Root + ->qsmaskinitnext + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-3.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-3.svg new file mode 100644 index 000000000000..de6ecc51b00e --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-3.svg @@ -0,0 +1,632 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ->gpnum = rsp->gpnum + + + + + Root + + + rcu_gp_init() + + + + + + ->gpnum = rsp->gpnum + + + + + + + Leaf + ->gpnum = rsp->gpnum + + + + + + + ->gpnum = rsp->gpnum + + + + + + + Leaf + + + + + + + Leaf + ->gpnum = rsp->gpnum + + + + + + + Leaf + ->gpnum = rsp->gpnum + + + + + + + + ->gpnum = rsp->gpnum + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg new file mode 100644 index 000000000000..b13b7b01bb3a --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg @@ -0,0 +1,5135 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + rcu_accelerate_cbs() + + + + + rcu_prepare_for_idle() + + rcu_accelerate_cbs() + + + + + note_gp_changes() + rcu_advance_cbs() + __note_gp_changes() + + call_rcu() + + Wake up + grace-period + kernel thread + + rcu_accelerate_cbs() + + + + + takedown_cpu() + rcutree_migrate_callbacks() + rcu_migrate_callbacks() + rcu_advance_cbs() + Leaf + Leaf + Leaf + + Phase One + of Update + + + rsp->gpnum++ + + + + + Root + + + rcu_gp_init() + + + + + + + + + + + + Leaf + + + + + + + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + + + + + + + + + + End of + Last Grace + Period + + + + Grace-period + kernel thread + awakened + + + + + + + + + + + + + + Leaf + + + + + + + ->qsmaskinit + ->qsmaskinitnext + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + ->qsmaskinit + + + + + + + + + rcu_init_new_rnp() or + rcu_cleanup_dead_rnp() + (optional) + + ->qsmaskinit + + + + + Root + ->qsmaskinitnext + + + + ->gpnum = rsp->gpnum + + + + + Root + + + + + + + ->gpnum = rsp->gpnum + + + + + + + Leaf + ->gpnum = rsp->gpnum + + + + + + + ->gpnum = rsp->gpnum + + + + + + + Leaf + + + + + + + Leaf + ->gpnum = rsp->gpnum + + + + + + + Leaf + ->gpnum = rsp->gpnum + + + + + + + + ->gpnum = rsp->gpnum + + + + + + + rcu_gp_fqs() + + + + + + ->qsmask &= ~->grpmask + + + + + + + Leaf + + + + + + + ->qsmask &= ~->grpmask + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + ->qsmask &= ~->grpmask + + + + + + + + + force_qs_rnp() + dyntick_save_progress_counter() + + + + + + Root + ->qsmask &= ~->grpmask + + rcu_implicit_dynticks_qs() + ->qsmask &= ~->grpmask + + + RCU + read-side + critical section + + + + rcu_dynticks_eqs_enter() + atomic_add_return() + + + + rcu_dynticks_eqs_exit() + atomic_add_return() + + + + RCU + read-side + critical section + + + + RCU + read-side + critical section + + + + rcu_report_dead() + rcu_cleanup_dying_idle_cpu() + + + + + ->qsmaskinitnext + Leaf + + + + RCU + read-side + critical section + + + + rcu_cpu_starting() + + + + + ->qsmaskinitnext + Leaf + + + + + ->qsmask &= ~->grpmask + + + + + Root + + + rcu_report_rnp() + + + + + + + + + + + + Leaf + + + + + + + ->qsmask &= ~->grpmask + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + ->qsmask &= ~->grpmask + + + + + + + + + + + + + + + + + note_gp_changes() + rdp->gpnum + __note_gp_changes() + Leaf + + + + rcu_node_context_switch() + + + + rcu_check_callbacks() + + + + rcu_process_callbacks() + rcu_check_quiescent_state()) + rcu__report_qs_rdp()) + + + + RCU + read-side + critical section + + + + RCU + read-side + critical section + + + + RCU + read-side + critical section + + + + RCU + read-side + critical section + + + + + + Wake up + grace-period + kernel thread + + + + rcu_report_qs_rsp() + + + Grace-period + kernel thread + awakened + + + + ->completed = ->gpnum + + + + + Root + + + rcu_gp_cleanup() + + + + + + ->completed = ->gpnum + + + + + + Leaf + ->completed = ->gpnum + + rsp->completed = + + + + + Root + rnp->completed + + + + + + + + + + + Leaf + + + + + + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + + + + + + + + + + + + + ->completed = ->gpnum + + + + + + + Leaf + + + + + + + Leaf + ->completed = ->gpnum + + + + + + + Leaf + ->completed = ->gpnum + + + + + + + + ->completed = ->gpnum + + + Start of + Next Grace + Period + + + + + + rcu_check_callbacks() + + rcu_cleanup_after_idle() + rcu_advance_cbs() + + + Leaf + __note_gp_changes() + + + Phase Two + of Update + + + RCU_SOFTIRQ + rcu_do_batch() + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg new file mode 100644 index 000000000000..2c9310ba29ba --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg @@ -0,0 +1,775 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ->qsmask &= ~->grpmask + dyntick_save_progress_counter() + rcu_implicit_dynticks_qs() + Leaf + + + + RCU + read-side + critical section + + + + rcu_report_dead() + rcu_cleanup_dying_idle_cpu() + + + + + ->qsmaskinitnext + Leaf + + + + RCU + read-side + critical section + + + + rcu_cpu_starting() + + + + + ->qsmaskinitnext + Leaf + + diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-qs.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-qs.svg new file mode 100644 index 000000000000..de3992f4cbe1 --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-qs.svg @@ -0,0 +1,1095 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ->qsmask &= ~->grpmask + + + + + Root + + + rcu_report_rnp() + + + + + + + + + + + + Leaf + + + + + + + ->qsmask &= ~->grpmask + + + + + + + Leaf + + + + + + + Leaf + + + + + + + Leaf + ->qsmask &= ~->grpmask + + + + + + + + + + + + + + + + + + note_gp_changes() + rdp->gpnum + __note_gp_changes() + Leaf + + + + rcu_node_context_switch() + + + + rcu_check_callbacks() + + + + rcu_process_callbacks() + rcu_check_quiescent_state()) + rcu__report_qs_rdp()) + + + + RCU + read-side + critical section + + + + RCU + read-side + critical section + + + + RCU + read-side + critical section + + + + RCU + read-side + critical section + + + + + + + Wake up + grace-period + kernel thread + + + + rcu_report_qs_rsp() + + diff --git a/Documentation/RCU/Design/Memory-Ordering/rcu_node-lock.svg b/Documentation/RCU/Design/Memory-Ordering/rcu_node-lock.svg new file mode 100644 index 000000000000..94c96c595aed --- /dev/null +++ b/Documentation/RCU/Design/Memory-Ordering/rcu_node-lock.svg @@ -0,0 +1,229 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + rcu_accelerate_cbs() + + + + + + + rcu_prepare_for_idle() + + -- cgit v1.2.3 From dfa0ee48ef86f79430d2be9d1e2e1b509abb3cce Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Wed, 9 Aug 2017 10:16:29 -0700 Subject: documentation: Long-running irq handlers can stall RCU grace periods If a periodic interrupt's handler takes longer to execute than the period between successive interrupts, RCU's kthreads and softirq handlers can be prevented from executing, resulting in otherwise inexplicable RCU CPU stall warnings. This commit therefore calls out this possibility in Documentation/RCU/stallwarn.txt. Reported-by: Daniel Lezcano Signed-off-by: Paul E. McKenney --- Documentation/RCU/stallwarn.txt | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 96a3d81837e1..21b8913acbdf 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -40,7 +40,9 @@ o Booting Linux using a console connection that is too slow to o Anything that prevents RCU's grace-period kthreads from running. This can result in the "All QSes seen" console-log message. This message will include information on when the kthread last - ran and how often it should be expected to run. + ran and how often it should be expected to run. It can also + result in the "rcu_.*kthread starved for" console-log message, + which will include additional debugging information. o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might happen to preempt a low-priority task in the middle of an RCU @@ -60,6 +62,14 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that CONFIG_PREEMPT_RCU case, you might see stall-warning messages. +o A periodic interrupt whose handler takes longer than the time + interval between successive pairs of interrupts. This can + prevent RCU's kthreads and softirq handlers from running. + Note that certain high-overhead debugging options, for example + the function_graph tracer, can result in interrupt handler taking + considerably longer than normal, which can in turn result in + RCU CPU stall warnings. + o A hardware or software issue shuts off the scheduler-clock interrupt on a CPU that is not in dyntick-idle mode. This problem really has happened, and seems to be most likely to -- cgit v1.2.3 From 3d916a443e97169a3d88765c4e0b07ac813f439f Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 10 Aug 2017 14:33:17 -0700 Subject: documentation: Slow systems can stall RCU grace periods If a fast system has a worst-case grace-period duration of (say) ten seconds, then running the same workload on a system ten times as slow will get you an RCU CPU stall warning given default stall-warning timeout settings. This commit therefore adds this possibility to stallwarn.txt. Reported-by: Daniel Lezcano Signed-off-by: Paul E. McKenney --- Documentation/RCU/stallwarn.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 21b8913acbdf..238acbd94917 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -70,6 +70,12 @@ o A periodic interrupt whose handler takes longer than the time considerably longer than normal, which can in turn result in RCU CPU stall warnings. +o Testing a workload on a fast system, tuning the stall-warning + timeout down to just barely avoid RCU CPU stall warnings, and then + running the same workload with the same stall-warning timeout on a + slow system. Note that thermal throttling and on-demand governors + can cause a single system to be sometimes fast and sometimes slow! + o A hardware or software issue shuts off the scheduler-clock interrupt on a CPU that is not in dyntick-idle mode. This problem really has happened, and seems to be most likely to -- cgit v1.2.3 From d3cf5176d0b17610b7c7f1562e496ec401fe01f8 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 17 Aug 2017 12:29:22 -0700 Subject: documentation: Update RCU CPU stall warning messages The RCU CPU stall warnings have morphed significantly since the last update, so this commit brings the documentation up to date. Signed-off-by: Paul E. McKenney --- Documentation/RCU/stallwarn.txt | 182 +++++++++++++++++++++++----------------- 1 file changed, 105 insertions(+), 77 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 238acbd94917..a08f928c8557 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -171,67 +171,32 @@ Interpreting RCU's CPU Stall-Detector "Splats" For non-RCU-tasks flavors of RCU, when a CPU detects that it is stalling, it will print a message similar to the following: -INFO: rcu_sched_state detected stall on CPU 5 (t=2500 jiffies) + INFO: rcu_sched detected stalls on CPUs/tasks: + 2-...: (3 GPs behind) idle=06c/0/0 softirq=1453/1455 fqs=0 + 16-...: (0 ticks this GP) idle=81c/0/0 softirq=764/764 fqs=0 + (detected by 32, t=2603 jiffies, g=7073, c=7072, q=625) -This message indicates that CPU 5 detected that it was causing a stall, -and that the stall was affecting RCU-sched. This message will normally be -followed by a stack dump of the offending CPU. On TREE_RCU kernel builds, -RCU and RCU-sched are implemented by the same underlying mechanism, -while on PREEMPT_RCU kernel builds, RCU is instead implemented -by rcu_preempt_state. - -On the other hand, if the offending CPU fails to print out a stall-warning -message quickly enough, some other CPU will print a message similar to -the following: - -INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 jiffies) - -This message indicates that CPU 2 detected that CPUs 3 and 5 were both -causing stalls, and that the stall was affecting RCU-bh. This message +This message indicates that CPU 32 detected that CPUs 2 and 16 were both +causing stalls, and that the stall was affecting RCU-sched. This message will normally be followed by stack dumps for each CPU. Please note that -PREEMPT_RCU builds can be stalled by tasks as well as by CPUs, -and that the tasks will be indicated by PID, for example, "P3421". -It is even possible for a rcu_preempt_state stall to be caused by both -CPUs -and- tasks, in which case the offending CPUs and tasks will all -be called out in the list. - -Finally, if the grace period ends just as the stall warning starts -printing, there will be a spurious stall-warning message: - -INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies) - -This is rare, but does happen from time to time in real life. It is also -possible for a zero-jiffy stall to be flagged in this case, depending -on how the stall warning and the grace-period initialization happen to -interact. Please note that it is not possible to entirely eliminate this -sort of false positive without resorting to things like stop_machine(), -which is overkill for this sort of problem. - -Recent kernels will print a long form of the stall-warning message: - - INFO: rcu_preempt detected stall on CPU - 0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543 - (t=65000 jiffies) - -In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed: - - INFO: rcu_preempt detected stall on CPU - 0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D - (t=65000 jiffies) +PREEMPT_RCU builds can be stalled by tasks as well as by CPUs, and that +the tasks will be indicated by PID, for example, "P3421". It is even +possible for a rcu_preempt_state stall to be caused by both CPUs -and- +tasks, in which case the offending CPUs and tasks will all be called +out in the list. -The "(64628 ticks this GP)" indicates that this CPU has taken more -than 64,000 scheduling-clock interrupts during the current stalled -grace period. If the CPU was not yet aware of the current grace -period (for example, if it was offline), then this part of the message -indicates how many grace periods behind the CPU is. +CPU 2's "(3 GPs behind)" indicates that this CPU has not interacted with +the RCU core for the past three grace periods. In contrast, CPU 16's "(0 +ticks this GP)" indicates that this CPU has not taken any scheduling-clock +interrupts during the current stalled grace period. The "idle=" portion of the message prints the dyntick-idle state. The hex number before the first "/" is the low-order 12 bits of the -dynticks counter, which will have an even-numbered value if the CPU is -in dyntick-idle mode and an odd-numbered value otherwise. The hex -number between the two "/"s is the value of the nesting, which will -be a small positive number if in the idle loop and a very large positive -number (as shown above) otherwise. +dynticks counter, which will have an even-numbered value if the CPU +is in dyntick-idle mode and an odd-numbered value otherwise. The hex +number between the two "/"s is the value of the nesting, which will be +a small non-negative number if in the idle loop (as shown above) and a +very large positive number otherwise. The "softirq=" portion of the message tracks the number of RCU softirq handlers that the stalled CPU has executed. The number before the "/" @@ -246,24 +211,72 @@ handlers are no longer able to execute on this CPU. This can happen if the stalled CPU is spinning with interrupts are disabled, or, in -rt kernels, if a high-priority process is starving RCU's softirq handler. -For CONFIG_RCU_FAST_NO_HZ kernels, the "last_accelerate:" prints the -low-order 16 bits (in hex) of the jiffies counter when this CPU last -invoked rcu_try_advance_all_cbs() from rcu_needs_cpu() or last invoked -rcu_accelerate_cbs() from rcu_prepare_for_idle(). The "nonlazy_posted:" -prints the number of non-lazy callbacks posted since the last call to -rcu_needs_cpu(). Finally, an "L" indicates that there are currently -no non-lazy callbacks ("." is printed otherwise, as shown above) and -"D" indicates that dyntick-idle processing is enabled ("." is printed -otherwise, for example, if disabled via the "nohz=" kernel boot parameter). +The "fps=" shows the number of force-quiescent-state idle/offline +detection passes that the grace-period kthread has made across this +CPU since the last time that this CPU noted the beginning of a grace +period. + +The "detected by" line indicates which CPU detected the stall (in this +case, CPU 32), how many jiffies have elapsed since the start of the +grace period (in this case 2603), the number of the last grace period +to start and to complete (7073 and 7072, respectively), and an estimate +of the total number of RCU callbacks queued across all CPUs (625 in +this case). + +In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed +for each CPU: + + 0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D + +The "last_accelerate:" prints the low-order 16 bits (in hex) of the +jiffies counter when this CPU last invoked rcu_try_advance_all_cbs() +from rcu_needs_cpu() or last invoked rcu_accelerate_cbs() from +rcu_prepare_for_idle(). The "nonlazy_posted:" prints the number +of non-lazy callbacks posted since the last call to rcu_needs_cpu(). +Finally, an "L" indicates that there are currently no non-lazy callbacks +("." is printed otherwise, as shown above) and "D" indicates that +dyntick-idle processing is enabled ("." is printed otherwise, for example, +if disabled via the "nohz=" kernel boot parameter). + +If the grace period ends just as the stall warning starts printing, +there will be a spurious stall-warning message, which will include +the following: + + INFO: Stall ended before state dump start + +This is rare, but does happen from time to time in real life. It is also +possible for a zero-jiffy stall to be flagged in this case, depending +on how the stall warning and the grace-period initialization happen to +interact. Please note that it is not possible to entirely eliminate this +sort of false positive without resorting to things like stop_machine(), +which is overkill for this sort of problem. + +If all CPUs and tasks have passed through quiescent states, but the +grace period has nevertheless failed to end, the stall-warning splat +will include something like the following: + + All QSes seen, last rcu_preempt kthread activity 23807 (4297905177-4297881370), jiffies_till_next_fqs=3, root ->qsmask 0x0 + +The "23807" indicates that it has been more than 23 thousand jiffies +since the grace-period kthread ran. The "jiffies_till_next_fqs" +indicates how frequently that kthread should run, giving the number +of jiffies between force-quiescent-state scans, in this case three, +which is way less than 23807. Finally, the root rcu_node structure's +->qsmask field is printed, which will normally be zero. If the relevant grace-period kthread has been unable to run prior to -the stall warning, the following additional line is printed: +the stall warning, as was the case in the "All QSes seen" line above, +the following additional line is printed: - rcu_preempt kthread starved for 2023 jiffies! + kthread starved for 23807 jiffies! g7073 c7072 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 -Starving the grace-period kthreads of CPU time can of course result in -RCU CPU stall warnings even when all CPUs and tasks have passed through -the required quiescent states. +Starving the grace-period kthreads of CPU time can of course result +in RCU CPU stall warnings even when all CPUs and tasks have passed +through the required quiescent states. The "g" and "c" numbers flag the +number of the last grace period started and completed, respectively, +the "f" precedes the ->gp_flags command to the grace-period kthread, +the "RCU_GP_WAIT_FQS" indicates that the kthread is waiting for a short +timeout, and the "state" precedes value of the task_struct ->state field. Multiple Warnings From One Stall @@ -280,13 +293,28 @@ Stall Warnings for Expedited Grace Periods If an expedited grace period detects a stall, it will place a message like the following in dmesg: - INFO: rcu_sched detected expedited stalls on CPUs: { 1 2 6 } 26009 jiffies s: 1043 - -This indicates that CPUs 1, 2, and 6 have failed to respond to a -reschedule IPI, that the expedited grace period has been going on for -26,009 jiffies, and that the expedited grace-period sequence counter is -1043. The fact that this last value is odd indicates that an expedited -grace period is in flight. + INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 7-... } 21119 jiffies s: 73 root: 0x2/. + +This indicates that CPU 7 has failed to respond to a reschedule IPI. +The three periods (".") following the CPU number indicate that the CPU +is online (otherwise the first period would instead have been "O"), +that the CPU was online at the beginning of the expedited grace period +(otherwise the second period would have instead been "o"), and that +the CPU has been online at least once since boot (otherwise, the third +period would instead have been "N"). The number before the "jiffies" +indicates that the expedited grace period has been going on for 21,119 +jiffies. The number following the "s:" indicates that the expedited +grace-period sequence counter is 73. The fact that this last value is +odd indicates that an expedited grace period is in flight. The number +following "root:" is a bitmask that indicates which children of the root +rcu_node structure correspond to CPUs and/or tasks that are blocking the +current expedited grace period. If the tree had more than one level, +additional hex numbers would be printed for the states of the other +rcu_node structures in the tree. + +As with normal grace periods, PREEMPT_RCU builds can be stalled by +tasks as well as by CPUs, and that the tasks will be indicated by PID, +for example, "P3421". It is entirely possible to see stall warnings from normal and from -expedited grace periods at about the same time from the same run. +expedited grace periods at about the same time during the same run. -- cgit v1.2.3 From f1ab25a30ce81f4e9be3cb33cd9bb9fb2db64b28 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Tue, 29 Aug 2017 15:49:21 -0700 Subject: memory-barriers: Replace uses of "transitive" The current version of memory-barriers.txt misuses the term "transitive", so this commit replaces it with multi-copy atomic, also adding a definition of this term. Reported-by: Alan Stern Signed-off-by: Paul E. McKenney --- Documentation/memory-barriers.txt | 185 +++++++++++++++++++------------------- 1 file changed, 91 insertions(+), 94 deletions(-) (limited to 'Documentation') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index b759a60624fd..b6882680247e 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -53,7 +53,7 @@ CONTENTS - SMP barrier pairing. - Examples of memory barrier sequences. - Read memory barriers vs load speculation. - - Transitivity + - Multicopy atomicity. (*) Explicit kernel barriers. @@ -635,6 +635,11 @@ can be used to record rare error conditions and the like, and the CPUs' naturally occurring ordering prevents such records from being lost. +Note well that the ordering provided by a data dependency is local to +the CPU containing it. See the section on "Multicopy atomicity" for +more information. + + The data dependency barrier is very important to the RCU system, for example. See rcu_assign_pointer() and rcu_dereference() in include/linux/rcupdate.h. This permits the current target of an RCU'd @@ -851,38 +856,11 @@ In short, control dependencies apply only to the stores in the then-clause and else-clause of the if-statement in question (including functions invoked by those two clauses), not to code following that if-statement. -Finally, control dependencies do -not- provide transitivity. This is -demonstrated by two related examples, with the initial values of -'x' and 'y' both being zero: - - CPU 0 CPU 1 - ======================= ======================= - r1 = READ_ONCE(x); r2 = READ_ONCE(y); - if (r1 > 0) if (r2 > 0) - WRITE_ONCE(y, 1); WRITE_ONCE(x, 1); - - assert(!(r1 == 1 && r2 == 1)); - -The above two-CPU example will never trigger the assert(). However, -if control dependencies guaranteed transitivity (which they do not), -then adding the following CPU would guarantee a related assertion: - - CPU 2 - ===================== - WRITE_ONCE(x, 2); - - assert(!(r1 == 2 && r2 == 1 && x == 2)); /* FAILS!!! */ -But because control dependencies do -not- provide transitivity, the above -assertion can fail after the combined three-CPU example completes. If you -need the three-CPU example to provide ordering, you will need smp_mb() -between the loads and stores in the CPU 0 and CPU 1 code fragments, -that is, just before or just after the "if" statements. Furthermore, -the original two-CPU example is very fragile and should be avoided. +Note well that the ordering provided by a control dependency is local +to the CPU containing it. See the section on "Multicopy atomicity" +for more information. -These two examples are the LB and WWC litmus tests from this paper: -http://www.cl.cam.ac.uk/users/pes20/ppc-supplemental/test6.pdf and this -site: https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html. In summary: @@ -922,8 +900,8 @@ In summary: (*) Control dependencies pair normally with other types of barriers. - (*) Control dependencies do -not- provide transitivity. If you - need transitivity, use smp_mb(). + (*) Control dependencies do -not- provide multicopy atomicity. If you + need all the CPUs to see a given store at the same time, use smp_mb(). (*) Compilers do not understand control dependencies. It is therefore your job to ensure that they do not break your code. @@ -936,13 +914,14 @@ When dealing with CPU-CPU interactions, certain types of memory barrier should always be paired. A lack of appropriate pairing is almost certainly an error. General barriers pair with each other, though they also pair with most -other types of barriers, albeit without transitivity. An acquire barrier -pairs with a release barrier, but both may also pair with other barriers, -including of course general barriers. A write barrier pairs with a data -dependency barrier, a control dependency, an acquire barrier, a release -barrier, a read barrier, or a general barrier. Similarly a read barrier, -control dependency, or a data dependency barrier pairs with a write -barrier, an acquire barrier, a release barrier, or a general barrier: +other types of barriers, albeit without multicopy atomicity. An acquire +barrier pairs with a release barrier, but both may also pair with other +barriers, including of course general barriers. A write barrier pairs +with a data dependency barrier, a control dependency, an acquire barrier, +a release barrier, a read barrier, or a general barrier. Similarly a +read barrier, control dependency, or a data dependency barrier pairs +with a write barrier, an acquire barrier, a release barrier, or a +general barrier: CPU 1 CPU 2 =============== =============== @@ -1359,64 +1338,77 @@ the speculation will be cancelled and the value reloaded: retrieved : : +-------+ -TRANSITIVITY ------------- +MULTICOPY ATOMICITY +-------------------- + +Multicopy atomicity is a deeply intuitive notion about ordering that is +not always provided by real computer systems, namely that a given store +is visible at the same time to all CPUs, or, alternatively, that all +CPUs agree on the order in which all stores took place. However, use of +full multicopy atomicity would rule out valuable hardware optimizations, +so a weaker form called ``other multicopy atomicity'' instead guarantees +that a given store is observed at the same time by all -other- CPUs. The +remainder of this document discusses this weaker form, but for brevity +will call it simply ``multicopy atomicity''. -Transitivity is a deeply intuitive notion about ordering that is not -always provided by real computer systems. The following example -demonstrates transitivity: +The following example demonstrates multicopy atomicity: CPU 1 CPU 2 CPU 3 ======================= ======================= ======================= { X = 0, Y = 0 } - STORE X=1 LOAD X STORE Y=1 - - LOAD Y LOAD X + STORE X=1 r1=LOAD X (reads 1) LOAD Y (reads 1) + + STORE Y=r1 LOAD X -Suppose that CPU 2's load from X returns 1 and its load from Y returns 0. -This indicates that CPU 2's load from X in some sense follows CPU 1's -store to X and that CPU 2's load from Y in some sense preceded CPU 3's -store to Y. The question is then "Can CPU 3's load from X return 0?" +Suppose that CPU 2's load from X returns 1 which it then stores to Y and +that CPU 3's load from Y returns 1. This indicates that CPU 2's load +from X in some sense follows CPU 1's store to X and that CPU 2's store +to Y in some sense preceded CPU 3's load from Y. The question is then +"Can CPU 3's load from X return 0?" -Because CPU 2's load from X in some sense came after CPU 1's store, it +Because CPU 3's load from X in some sense came after CPU 2's load, it is natural to expect that CPU 3's load from X must therefore return 1. -This expectation is an example of transitivity: if a load executing on -CPU A follows a load from the same variable executing on CPU B, then -CPU A's load must either return the same value that CPU B's load did, -or must return some later value. - -In the Linux kernel, use of general memory barriers guarantees -transitivity. Therefore, in the above example, if CPU 2's load from X -returns 1 and its load from Y returns 0, then CPU 3's load from X must -also return 1. - -However, transitivity is -not- guaranteed for read or write barriers. -For example, suppose that CPU 2's general barrier in the above example -is changed to a read barrier as shown below: +This expectation is an example of multicopy atomicity: if a load executing +on CPU A follows a load from the same variable executing on CPU B, then +an understandable but incorrect expectation is that CPU A's load must +either return the same value that CPU B's load did, or must return some +later value. + +In the Linux kernel, the above use of a general memory barrier compensates +for any lack of multicopy atomicity. Therefore, in the above example, +if CPU 2's load from X returns 1 and its load from Y returns 0, and CPU 3's +load from Y returns 1, then CPU 3's load from X must also return 1. + +However, dependencies, read barriers, and write barriers are not always +able to compensate for non-multicopy atomicity. For example, suppose +that CPU 2's general barrier is removed from the above example, leaving +only the data dependency shown below: CPU 1 CPU 2 CPU 3 ======================= ======================= ======================= { X = 0, Y = 0 } - STORE X=1 LOAD X STORE Y=1 - - LOAD Y LOAD X - -This substitution destroys transitivity: in this example, it is perfectly -legal for CPU 2's load from X to return 1, its load from Y to return 0, -and CPU 3's load from X to return 0. - -The key point is that although CPU 2's read barrier orders its pair -of loads, it does not guarantee to order CPU 1's store. Therefore, if -this example runs on a system where CPUs 1 and 2 share a store buffer -or a level of cache, CPU 2 might have early access to CPU 1's writes. -General barriers are therefore required to ensure that all CPUs agree -on the combined order of CPU 1's and CPU 2's accesses. - -General barriers provide "global transitivity", so that all CPUs will -agree on the order of operations. In contrast, a chain of release-acquire -pairs provides only "local transitivity", so that only those CPUs on -the chain are guaranteed to agree on the combined order of the accesses. -For example, switching to C code in deference to Herman Hollerith: + STORE X=1 r1=LOAD X (reads 1) LOAD Y (reads 1) + + STORE Y=r1 LOAD X (reads 0) + +This substitution allows non-multicopy atomicity to run rampant: in +this example, it is perfectly legal for CPU 2's load from X to return 1, +CPU 3's load from Y to return 1, and its load from X to return 0. + +The key point is that although CPU 2's data dependency orders its load +and store, it does not guarantee to order CPU 1's store. Therefore, +if this example runs on a non-multicopy-atomic system where CPUs 1 and 2 +share a store buffer or a level of cache, CPU 2 might have early access +to CPU 1's writes. A general barrier is therefore required to ensure +that all CPUs agree on the combined order of CPU 1's and CPU 2's accesses. + +General barriers can compensate not only for non-multicopy atomicity, +but can also generate additional ordering that can ensure that -all- +CPUs will perceive the same order of -all- operations. In contrast, a +chain of release-acquire pairs do not provide this additional ordering, +which means that only those CPUs on the chain are guaranteed to agree +on the combined order of the accesses. For example, switching to C code +in deference to the ghost of Herman Hollerith: int u, v, x, y, z; @@ -1448,9 +1440,9 @@ For example, switching to C code in deference to Herman Hollerith: r3 = READ_ONCE(u); } -Because cpu0(), cpu1(), and cpu2() participate in a local transitive -chain of smp_store_release()/smp_load_acquire() pairs, the following -outcome is prohibited: +Because cpu0(), cpu1(), and cpu2() participate in a chain of +smp_store_release()/smp_load_acquire() pairs, the following outcome +is prohibited: r0 == 1 && r1 == 1 && r2 == 1 @@ -1460,9 +1452,9 @@ outcome is prohibited: r1 == 1 && r5 == 0 -However, the transitivity of release-acquire is local to the participating -CPUs and does not apply to cpu3(). Therefore, the following outcome -is possible: +However, the ordering provided by a release-acquire chain is local +to the CPUs participating in that chain and does not apply to cpu3(), +at least aside from stores. Therefore, the following outcome is possible: r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 @@ -1490,8 +1482,8 @@ following outcome is possible: Note that this outcome can happen even on a mythical sequentially consistent system where nothing is ever reordered. -To reiterate, if your code requires global transitivity, use general -barriers throughout. +To reiterate, if your code requires full ordering of all operations, +use general barriers throughout. ======================== @@ -3101,6 +3093,9 @@ AMD64 Architecture Programmer's Manual Volume 2: System Programming Chapter 7.1: Memory-Access Ordering Chapter 7.4: Buffering and Combining Memory Writes +ARM Architecture Reference Manual (ARMv8, for ARMv8-A architecture profile) + Chapter B2: The AArch64 Application Level Memory Model + IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide Chapter 7.1: Locked Atomic Operations @@ -3112,6 +3107,8 @@ The SPARC Architecture Manual, Version 9 Appendix D: Formal Specification of the Memory Models Appendix J: Programming with the Memory Models +Storage in the PowerPC (Stone and Fitzgerald) + UltraSPARC Programmer Reference Manual Chapter 5: Memory Accesses and Cacheability Chapter 15: Sparc-V9 Memory Models -- cgit v1.2.3 From 0902b1f44a72558aece92f074154044861681f84 Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Fri, 1 Sep 2017 07:53:34 -0700 Subject: memory-barriers: Rework multicopy-atomicity section Signed-off-by: Alan Stern Signed-off-by: Paul E. McKenney --- Documentation/memory-barriers.txt | 58 ++++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 28 deletions(-) (limited to 'Documentation') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index b6882680247e..7deee1441640 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1343,13 +1343,13 @@ MULTICOPY ATOMICITY Multicopy atomicity is a deeply intuitive notion about ordering that is not always provided by real computer systems, namely that a given store -is visible at the same time to all CPUs, or, alternatively, that all -CPUs agree on the order in which all stores took place. However, use of -full multicopy atomicity would rule out valuable hardware optimizations, -so a weaker form called ``other multicopy atomicity'' instead guarantees -that a given store is observed at the same time by all -other- CPUs. The -remainder of this document discusses this weaker form, but for brevity -will call it simply ``multicopy atomicity''. +becomes visible at the same time to all CPUs, or, alternatively, that all +CPUs agree on the order in which all stores become visible. However, +support of full multicopy atomicity would rule out valuable hardware +optimizations, so a weaker form called ``other multicopy atomicity'' +instead guarantees only that a given store becomes visible at the same +time to all -other- CPUs. The remainder of this document discusses this +weaker form, but for brevity will call it simply ``multicopy atomicity''. The following example demonstrates multicopy atomicity: @@ -1360,24 +1360,26 @@ The following example demonstrates multicopy atomicity: STORE Y=r1 LOAD X -Suppose that CPU 2's load from X returns 1 which it then stores to Y and -that CPU 3's load from Y returns 1. This indicates that CPU 2's load -from X in some sense follows CPU 1's store to X and that CPU 2's store -to Y in some sense preceded CPU 3's load from Y. The question is then -"Can CPU 3's load from X return 0?" +Suppose that CPU 2's load from X returns 1, which it then stores to Y, +and CPU 3's load from Y returns 1. This indicates that CPU 1's store +to X precedes CPU 2's load from X and that CPU 2's store to Y precedes +CPU 3's load from Y. In addition, the memory barriers guarantee that +CPU 2 executes its load before its store, and CPU 3 loads from Y before +it loads from X. The question is then "Can CPU 3's load from X return 0?" -Because CPU 3's load from X in some sense came after CPU 2's load, it +Because CPU 3's load from X in some sense comes after CPU 2's load, it is natural to expect that CPU 3's load from X must therefore return 1. -This expectation is an example of multicopy atomicity: if a load executing -on CPU A follows a load from the same variable executing on CPU B, then -an understandable but incorrect expectation is that CPU A's load must -either return the same value that CPU B's load did, or must return some -later value. - -In the Linux kernel, the above use of a general memory barrier compensates -for any lack of multicopy atomicity. Therefore, in the above example, -if CPU 2's load from X returns 1 and its load from Y returns 0, and CPU 3's -load from Y returns 1, then CPU 3's load from X must also return 1. +This expectation follows from multicopy atomicity: if a load executing +on CPU B follows a load from the same variable executing on CPU A (and +CPU A did not originally store the value which it read), then on +multicopy-atomic systems, CPU B's load must return either the same value +that CPU A's load did or some later value. However, the Linux kernel +does not require systems to be multicopy atomic. + +The use of a general memory barrier in the example above compensates +for any lack of multicopy atomicity. In the example, if CPU 2's load +from X returns 1 and CPU 3's load from Y returns 1, then CPU 3's load +from X must indeed also return 1. However, dependencies, read barriers, and write barriers are not always able to compensate for non-multicopy atomicity. For example, suppose @@ -1396,11 +1398,11 @@ this example, it is perfectly legal for CPU 2's load from X to return 1, CPU 3's load from Y to return 1, and its load from X to return 0. The key point is that although CPU 2's data dependency orders its load -and store, it does not guarantee to order CPU 1's store. Therefore, -if this example runs on a non-multicopy-atomic system where CPUs 1 and 2 -share a store buffer or a level of cache, CPU 2 might have early access -to CPU 1's writes. A general barrier is therefore required to ensure -that all CPUs agree on the combined order of CPU 1's and CPU 2's accesses. +and store, it does not guarantee to order CPU 1's store. Thus, if this +example runs on a non-multicopy-atomic system where CPUs 1 and 2 share a +store buffer or a level of cache, CPU 2 might have early access to CPU 1's +writes. General barriers are therefore required to ensure that all CPUs +agree on the combined order of multiple accesses. General barriers can compensate not only for non-multicopy atomicity, but can also generate additional ordering that can ensure that -all- -- cgit v1.2.3 From 2b1516e55f8416acfb48d5f43d41222d180fb5a3 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Fri, 18 Aug 2017 16:11:37 -0700 Subject: rcutorture: Add interrupt-disable capability to stall-warning tests When rcutorture sees the rcutorture.stall_cpu kernel boot parameter, it loops with preemption disabled, which does in fact normally generate an RCU CPU stall warning message. However, there are test scenarios that need the stalling CPU to have interrupts disabled. This commit therefore adds an rcutorture.stall_cpu_irqsoff kernel boot parameter that causes the stalling CPU to disable interrupts. Signed-off-by: Paul E. McKenney --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 05496622b4ef..bc94c47085a5 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3539,6 +3539,9 @@ rcutorture.stall_cpu_holdoff= [KNL] Time to wait (s) after boot before inducing stall. + rcutorture.stall_cpu_irqsoff= [KNL] + Disable interrupts while stalling if set. + rcutorture.stat_interval= [KNL] Time (s) between statistics printk()s. -- cgit v1.2.3 From 19f3f22aade704f9ce82a55c853381e672629a1d Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel Date: Fri, 6 Oct 2017 17:39:19 +0100 Subject: dt-bindings: PCI: designware: Add binding for Designware PCIe in ECAM mode Describe the binding for firmware-configured instances of the Synopsys DesignWare PCIe controller in RC mode, that are almost but not quite ECAM compliant. Signed-off-by: Ard Biesheuvel Signed-off-by: Bjorn Helgaas Acked-by: Rob Herring --- .../bindings/pci/designware-pcie-ecam.txt | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt new file mode 100644 index 000000000000..515b2f9542e5 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt @@ -0,0 +1,42 @@ +* Synopsys DesignWare PCIe root complex in ECAM shift mode + +In some cases, firmware may already have configured the Synopsys DesignWare +PCIe controller in RC mode with static ATU window mappings that cover all +config, MMIO and I/O spaces in a [mostly] ECAM compatible fashion. +In this case, there is no need for the OS to perform any low level setup +of clocks, PHYs or device registers, nor is there any reason for the driver +to reconfigure ATU windows for config and/or IO space accesses at runtime. + +In cases where the IP was synthesized with a minimum ATU window size of +64 KB, it cannot be supported by the generic ECAM driver, because it +requires special config space accessors that filter accesses to device #1 +and beyond on the first bus. + +Required properties: +- compatible: "marvell,armada8k-pcie-ecam" or + "socionext,synquacer-pcie-ecam" or + "snps,dw-pcie-ecam" (must be preceded by a more specific match) + +Please refer to the binding document of "pci-host-ecam-generic" in the +file host-generic-pci.txt for a description of the remaining required +and optional properties. + +Example: + + pcie1: pcie@7f000000 { + compatible = "socionext,synquacer-pcie-ecam", "snps,dw-pcie-ecam"; + device_type = "pci"; + reg = <0x0 0x7f000000 0x0 0xf00000>; + bus-range = <0x0 0xe>; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x1000000 0x00 0x00010000 0x00 0x7ff00000 0x0 0x00010000>, + <0x2000000 0x00 0x70000000 0x00 0x70000000 0x0 0x0f000000>, + <0x3000000 0x3f 0x00000000 0x3f 0x00000000 0x1 0x00000000>; + + #interrupt-cells = <0x1>; + interrupt-map-mask = <0x0 0x0 0x0 0x0>; + interrupt-map = <0x0 0x0 0x0 0x0 &gic 0x0 0x0 0x0 182 0x4>; + msi-map = <0x0 &its 0x0 0x10000>; + dma-coherent; + }; -- cgit v1.2.3 From 6be53520ad8f87dc748f381e4e8e6a846a4b466b Mon Sep 17 00:00:00 2001 From: Dou Liyang Date: Mon, 9 Oct 2017 17:03:33 +0800 Subject: x86/tsc: Append the 'tsc=' description for the 'tsc=unstable' boot parameter Commit: 8309f86cd41e ("x86/tsc: Provide 'tsc=unstable' boot parameter") added a new 'tsc=unstable' parameter, but didn't document it. Document it. Signed-off-by: Dou Liyang Signed-off-by: Peter Zijlstra (Intel) Cc: Cc: Cc: Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1507539813-11420-1-git-send-email-douly.fnst@cn.fujitsu.com Signed-off-by: Ingo Molnar --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 05496622b4ef..6b99c8b77c59 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4194,6 +4194,9 @@ Used to run time disable IRQ_TIME_ACCOUNTING on any platforms where RDTSC is slow and this accounting can add overhead. + [x86] unstable: mark the TSC clocksource as unstable, this + marks the TSC unconditionally unstable at bootup and + avoids any further wobbles once the TSC watchdog notices. turbografx.map[2|3]= [HW,JOY] TurboGraFX parallel port interface -- cgit v1.2.3 From 3888ffd0c76110e8f45523e3ede842699a2c6614 Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Sun, 17 Sep 2017 18:17:12 +0200 Subject: dt-bindings: iio: accel: add LIS3DHH device bindings Signed-off-by: Lorenzo Bianconi Acked-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/st-sensors.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt index 9cfc82d21792..6f626f73417e 100644 --- a/Documentation/devicetree/bindings/iio/st-sensors.txt +++ b/Documentation/devicetree/bindings/iio/st-sensors.txt @@ -47,6 +47,7 @@ Accelerometers: - st,lng2dm-accel - st,lis3l02dq - st,lis2dw12 +- st,lis3dhh Gyroscopes: - st,l3g4200d-gyro -- cgit v1.2.3 From 68a48afa6540f0bd193167f91283915ca8a4225e Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Tue, 10 Oct 2017 11:20:03 +0800 Subject: dt-bindings: display: sun4i: Add binding for A31 HDMI controller The HDMI controller in the A31 SoC is slightly different from the earlier version. In addition to the TMDS clock and DDC controls, this version now takes a second DDC clock input. Add a compatible string for it, and add the DDC clock input to the list of clocks required. Signed-off-by: Chen-Yu Tsai Acked-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20171010032008.682-7-wens@csie.org --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 92441086caba..46df3b78ae9e 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -41,14 +41,17 @@ CEC. It is one end of the pipeline. Required properties: - compatible: value must be one of: * allwinner,sun5i-a10s-hdmi + * allwinner,sun6i-a31-hdmi - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the HDMI encoder * ahb: the HDMI interface clock * mod: the HDMI module clock + * ddc: the HDMI ddc clock (A31 only) * pll-0: the first video PLL * pll-1: the second video PLL - clock-names: the clock names mentioned above + - resets: phandle to the reset control for the HDMI encoder (A31 only) - dmas: phandles to the DMA channels used by the HDMI encoder * ddc-tx: The channel for DDC transmission * ddc-rx: The channel for DDC reception -- cgit v1.2.3 From a157789b78f4e95f5d66f8b564356e396716f67e Mon Sep 17 00:00:00 2001 From: Lars Poeschel Date: Thu, 5 Oct 2017 09:50:02 +0200 Subject: dt-bindings: pinctrl: Move mcp23s08 from gpio The mcp23s08 driver was moved from gpio to pinctrl. This moves it's devicetree binding doc as well. So driver and binding doc are in sync again. Signed-off-by: Lars Poeschel Reviewed-by: Sebastian Reichel Signed-off-by: Linus Walleij --- .../devicetree/bindings/gpio/gpio-mcp23s08.txt | 83 ---------------------- .../bindings/pinctrl/pinctrl-mcp23s08.txt | 83 ++++++++++++++++++++++ 2 files changed, 83 insertions(+), 83 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt deleted file mode 100644 index c934106b10aa..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt +++ /dev/null @@ -1,83 +0,0 @@ -Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for -8-/16-bit I/O expander with serial interface (I2C/SPI) - -Required properties: -- compatible : Should be - - "mcp,mcp23s08" (DEPRECATED) for 8 GPIO SPI version - - "mcp,mcp23s17" (DEPRECATED) for 16 GPIO SPI version - - "mcp,mcp23008" (DEPRECATED) for 8 GPIO I2C version or - - "mcp,mcp23017" (DEPRECATED) for 16 GPIO I2C version of the chip - - - "microchip,mcp23s08" for 8 GPIO SPI version - - "microchip,mcp23s17" for 16 GPIO SPI version - - "microchip,mcp23s18" for 16 GPIO SPI version - - "microchip,mcp23008" for 8 GPIO I2C version or - - "microchip,mcp23017" for 16 GPIO I2C version of the chip - NOTE: Do not use the old mcp prefix any more. It is deprecated and will be - removed. -- #gpio-cells : Should be two. - - first cell is the pin number - - second cell is used to specify flags. Flags are currently unused. -- gpio-controller : Marks the device node as a GPIO controller. -- reg : For an address on its bus. I2C uses this a the I2C address of the chip. - SPI uses this to specify the chipselect line which the chip is - connected to. The driver and the SPI variant of the chip support - multiple chips on the same chipselect. Have a look at - microchip,spi-present-mask below. - -Required device specific properties (only for SPI chips): -- mcp,spi-present-mask (DEPRECATED) -- microchip,spi-present-mask : This is a present flag, that makes only sense for SPI - chips - as the name suggests. Multiple SPI chips can share the same - SPI chipselect. Set a bit in bit0-7 in this mask to 1 if there is a - chip connected with the corresponding spi address set. For example if - you have a chip with address 3 connected, you have to set bit3 to 1, - which is 0x08. mcp23s08 chip variant only supports bits 0-3. It is not - possible to mix mcp23s08 and mcp23s17 on the same chipselect. Set at - least one bit to 1 for SPI chips. - NOTE: Do not use the old mcp prefix any more. It is deprecated and will be - removed. -- spi-max-frequency = The maximum frequency this chip is able to handle - -Optional properties: -- #interrupt-cells : Should be two. - - first cell is the pin number - - second cell is used to specify flags. -- interrupt-controller: Marks the device node as a interrupt controller. - -Optional device specific properties: -- microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices - with two interrupt outputs (these are the devices ending with 17 and - those that have 16 IOs) have two IO banks: IO 0-7 form bank 1 and - IO 8-15 are bank 2. These chips have two different interrupt outputs: - One for bank 1 and another for bank 2. If irq-mirror is set, both - interrupts are generated regardless of the bank that an input change - occurred on. If it is not set, the interrupt are only generated for the - bank they belong to. - On devices with only one interrupt output this property is useless. -- microchip,irq-active-high: Sets the INTPOL flag in the IOCON register. This - configures the IRQ output polarity as active high. - -Example I2C (with interrupt): -gpiom1: gpio@20 { - compatible = "microchip,mcp23017"; - gpio-controller; - #gpio-cells = <2>; - reg = <0x20>; - - interrupt-parent = <&gpio1>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells=<2>; - microchip,irq-mirror; -}; - -Example SPI: -gpiom1: gpio@0 { - compatible = "microchip,mcp23s17"; - gpio-controller; - #gpio-cells = <2>; - spi-present-mask = <0x01>; - reg = <0>; - spi-max-frequency = <1000000>; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt new file mode 100644 index 000000000000..c934106b10aa --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt @@ -0,0 +1,83 @@ +Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for +8-/16-bit I/O expander with serial interface (I2C/SPI) + +Required properties: +- compatible : Should be + - "mcp,mcp23s08" (DEPRECATED) for 8 GPIO SPI version + - "mcp,mcp23s17" (DEPRECATED) for 16 GPIO SPI version + - "mcp,mcp23008" (DEPRECATED) for 8 GPIO I2C version or + - "mcp,mcp23017" (DEPRECATED) for 16 GPIO I2C version of the chip + + - "microchip,mcp23s08" for 8 GPIO SPI version + - "microchip,mcp23s17" for 16 GPIO SPI version + - "microchip,mcp23s18" for 16 GPIO SPI version + - "microchip,mcp23008" for 8 GPIO I2C version or + - "microchip,mcp23017" for 16 GPIO I2C version of the chip + NOTE: Do not use the old mcp prefix any more. It is deprecated and will be + removed. +- #gpio-cells : Should be two. + - first cell is the pin number + - second cell is used to specify flags. Flags are currently unused. +- gpio-controller : Marks the device node as a GPIO controller. +- reg : For an address on its bus. I2C uses this a the I2C address of the chip. + SPI uses this to specify the chipselect line which the chip is + connected to. The driver and the SPI variant of the chip support + multiple chips on the same chipselect. Have a look at + microchip,spi-present-mask below. + +Required device specific properties (only for SPI chips): +- mcp,spi-present-mask (DEPRECATED) +- microchip,spi-present-mask : This is a present flag, that makes only sense for SPI + chips - as the name suggests. Multiple SPI chips can share the same + SPI chipselect. Set a bit in bit0-7 in this mask to 1 if there is a + chip connected with the corresponding spi address set. For example if + you have a chip with address 3 connected, you have to set bit3 to 1, + which is 0x08. mcp23s08 chip variant only supports bits 0-3. It is not + possible to mix mcp23s08 and mcp23s17 on the same chipselect. Set at + least one bit to 1 for SPI chips. + NOTE: Do not use the old mcp prefix any more. It is deprecated and will be + removed. +- spi-max-frequency = The maximum frequency this chip is able to handle + +Optional properties: +- #interrupt-cells : Should be two. + - first cell is the pin number + - second cell is used to specify flags. +- interrupt-controller: Marks the device node as a interrupt controller. + +Optional device specific properties: +- microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices + with two interrupt outputs (these are the devices ending with 17 and + those that have 16 IOs) have two IO banks: IO 0-7 form bank 1 and + IO 8-15 are bank 2. These chips have two different interrupt outputs: + One for bank 1 and another for bank 2. If irq-mirror is set, both + interrupts are generated regardless of the bank that an input change + occurred on. If it is not set, the interrupt are only generated for the + bank they belong to. + On devices with only one interrupt output this property is useless. +- microchip,irq-active-high: Sets the INTPOL flag in the IOCON register. This + configures the IRQ output polarity as active high. + +Example I2C (with interrupt): +gpiom1: gpio@20 { + compatible = "microchip,mcp23017"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + + interrupt-parent = <&gpio1>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells=<2>; + microchip,irq-mirror; +}; + +Example SPI: +gpiom1: gpio@0 { + compatible = "microchip,mcp23s17"; + gpio-controller; + #gpio-cells = <2>; + spi-present-mask = <0x01>; + reg = <0>; + spi-max-frequency = <1000000>; +}; -- cgit v1.2.3 From e8527b6eb6ffdccc45b58646312cfe42365b74b0 Mon Sep 17 00:00:00 2001 From: Lars Poeschel Date: Mon, 9 Oct 2017 14:03:00 +0200 Subject: dt-bindings: pinctrl: mcp23s08 update binding doc The mcp23s08 driver moved to pinctrl recently. It accepts the bias-pull-up pinctrl property since then. This updates the binding doc to reflect that. Thanks to Sebastian Reichel for the working example. Signed-off-by: Lars Poeschel Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-mcp23s08.txt | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt index c934106b10aa..b7a0e868ec13 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt @@ -81,3 +81,61 @@ gpiom1: gpio@0 { reg = <0>; spi-max-frequency = <1000000>; }; + +Pull-up configuration +===================== + +If pins are used as output, they can also be configured with pull-ups. This is +done with pinctrl. + +Please refer file +for details of the common pinctrl bindings used by client devices, +including the meaning of the phrase "pin configuration node". + +Optional Pinmux properties: +-------------------------- +Following properties are required if default setting of pins are required +at boot. +- pinctrl-names: A pinctrl state named per . +- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per + . + +The pin configurations are defined as child of the pinctrl states node. Each +sub-node have following properties: + +Required properties: +------------------ +- pins: List of pins. Valid values of pins properties are: + gpio0 ... gpio7 for the devices with 8 GPIO pins and + gpio0 ... gpio15 for the devices with 16 GPIO pins. + +Optional properties: +------------------- +The following optional property is defined in the pinmux DT binding document +. Absence of this property will leave the configuration +in its default state. + bias-pull-up + +Example with pinctrl to pull-up output pins: +gpio21: gpio@21 { + compatible = "microchip,mcp23017"; + gpio-controller; + #gpio-cells = <0x2>; + reg = <0x21>; + interrupt-parent = <&socgpio>; + interrupts = <0x17 0x8>; + interrupt-names = "mcp23017@21 irq"; + interrupt-controller; + #interrupt-cells = <0x2>; + microchip,irq-mirror; + pinctrl-names = "default"; + pinctrl-0 = <&i2cgpio0irq &gpio21pullups>; + + gpio21pullups: pinmux { + pins = "gpio0", "gpio1", "gpio2", "gpio3", + "gpio4", "gpio5", "gpio6", "gpio7", + "gpio8", "gpio9", "gpio10", "gpio11", + "gpio12", "gpio13", "gpio14", "gpio15"; + bias-pull-up; + }; +}; -- cgit v1.2.3 From b889372c843b2a2c4aa776c85bca31636fd38d90 Mon Sep 17 00:00:00 2001 From: Phil Reid Date: Fri, 6 Oct 2017 13:08:06 +0800 Subject: dt-bindings: pinctrl: add mcp23018 to mcp23s08 documentation This adds the compatible string for the mcp23018, which is the i2c variant of the mcp23s18. Signed-off-by: Phil Reid Reviewed-by: Sebastian Reichel Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt index b7a0e868ec13..9c451c20dda4 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt @@ -13,6 +13,7 @@ Required properties: - "microchip,mcp23s18" for 16 GPIO SPI version - "microchip,mcp23008" for 8 GPIO I2C version or - "microchip,mcp23017" for 16 GPIO I2C version of the chip + - "microchip,mcp23018" for 16 GPIO I2C version NOTE: Do not use the old mcp prefix any more. It is deprecated and will be removed. - #gpio-cells : Should be two. -- cgit v1.2.3 From 9044070dc6949d853976b01edc80eaca9d09cea1 Mon Sep 17 00:00:00 2001 From: Kevin Wangtao Date: Tue, 10 Oct 2017 20:02:48 +0200 Subject: dt-bindings: Document the hi3660 thermal sensor binding This adds documentation of device tree bindings for the thermal sensor controller of hi3660 SoC. Signed-off-by: Kevin Wangtao Signed-off-by: Daniel Lezcano Acked-by: Rob Herring Signed-off-by: Wei Xu --- Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt index d48fc5280d5a..cef716a236f1 100644 --- a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt @@ -13,6 +13,7 @@ Example : +for Hi6220: tsensor: tsensor@0,f7030700 { compatible = "hisilicon,tsensor"; reg = <0x0 0xf7030700 0x0 0x1000>; @@ -21,3 +22,11 @@ Example : clock-names = "thermal_clk"; #thermal-sensor-cells = <1>; } + +for Hi3660: + tsensor: tsensor@fff30000 { + compatible = "hisilicon,hi3660-tsensor"; + reg = <0x0 0xfff30000 0x0 0x1000>; + interrupts = ; + #thermal-sensor-cells = <1>; + }; -- cgit v1.2.3 From 007f6c5e6eb45c81ee89368a5f226572ae638831 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Thu, 15 Oct 2015 11:22:58 +0200 Subject: cfg80211: support loading regulatory database as firmware file As the current regulatory database is only about 4k big, and already difficult to extend, we decided that overall it would be better to get rid of the complications with CRDA and load the database into the kernel directly, but in a new format that is extensible. The new file format can be extended since it carries a length field on all the structs that need to be extensible. In order to be able to request firmware when the module initializes, move cfg80211 from subsys_initcall() to the later fs_initcall(); the firmware loader is at the same level but linked earlier, so it can be called from there. Otherwise, when both the firmware loader and cfg80211 are built-in, the request will crash the kernel. We also need to be before device_initcall() so that cfg80211 is available for devices when they initialize. Signed-off-by: Johannes Berg --- Documentation/networking/regulatory.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/regulatory.txt b/Documentation/networking/regulatory.txt index 7818b5fe448b..46c8d8b1cc66 100644 --- a/Documentation/networking/regulatory.txt +++ b/Documentation/networking/regulatory.txt @@ -19,6 +19,14 @@ core regulatory domain all wireless devices should adhere to. How to get regulatory domains to the kernel ------------------------------------------- +When the regulatory domain is first set up, the kernel will request a +database file (regulatory.db) containing all the regulatory rules. It +will then use that database when it needs to look up the rules for a +given country. + +How to get regulatory domains to the kernel (old CRDA solution) +--------------------------------------------------------------- + Userspace gets a regulatory domain in the kernel by having a userspace agent build it and send it via nl80211. Only expected regulatory domains will be respected by the kernel. -- cgit v1.2.3 From c8c240e284b3d821011b4f680b3eaa99569b3756 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Thu, 15 Oct 2015 14:35:41 +0200 Subject: cfg80211: reg: remove support for built-in regdb Parsing and building C structures from a regdb is no longer needed since the "firmware" file (regulatory.db) can be linked into the kernel image to achieve the same effect. Signed-off-by: Johannes Berg --- Documentation/networking/regulatory.txt | 22 ++-------------------- 1 file changed, 2 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/regulatory.txt b/Documentation/networking/regulatory.txt index 46c8d8b1cc66..381e5b23d61d 100644 --- a/Documentation/networking/regulatory.txt +++ b/Documentation/networking/regulatory.txt @@ -200,23 +200,5 @@ Then in some part of your code after your wiphy has been registered: Statically compiled regulatory database --------------------------------------- -In most situations the userland solution using CRDA as described -above is the preferred solution. However in some cases a set of -rules built into the kernel itself may be desirable. To account -for this situation, a configuration option has been provided -(i.e. CONFIG_CFG80211_INTERNAL_REGDB). With this option enabled, -the wireless database information contained in net/wireless/db.txt is -used to generate a data structure encoded in net/wireless/regdb.c. -That option also enables code in net/wireless/reg.c which queries -the data in regdb.c as an alternative to using CRDA. - -The file net/wireless/db.txt should be kept up-to-date with the db.txt -file available in the git repository here: - - git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git - -Again, most users in most situations should be using the CRDA package -provided with their distribution, and in most other situations users -should be building and using CRDA on their own rather than using -this option. If you are not absolutely sure that you should be using -CONFIG_CFG80211_INTERNAL_REGDB then _DO_NOT_USE_IT_. +When a database should be fixed into the kernel, it can be provided as a +firmware file at build time that is then linked into the kernel. -- cgit v1.2.3 From eeb2d80d502af28e5660ff4bbe00f90ceb82c2db Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Thu, 5 Oct 2017 16:24:03 -0700 Subject: ACPI / LPIT: Add Low Power Idle Table (LPIT) support Add functionality to read LPIT table, which provides: - Sysfs interface to read residency counters via /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us Here the count "low_power_idle_cpu_residency_us" shows the time spent by CPU package in low power state. This is read via MSR interface, which points to MSR for PKG C10. Here the count "low_power_idle_system_residency_us" show the count the system was in low power state. This is read via MMIO interface. This is mapped to SLP_S0 residency on modern Intel systems. This residency is achieved only when CPU is in PKG C10 and all functional blocks are in low power state. It is possible that none of the above counters present or anyone of the counter present or all counters present. For example: On my Kabylake system both of the above counters present. After suspend to idle these counts updated and prints: 6916179 6998564 This counter can be read by tools like turbostat to display. Or it can be used to debug, if modern systems are reaching desired low power state. - Provides an interface to read residency counter memory address This address can be used to get the base address of PMC memory mapped IO. This is utilized by intel_pmc_core driver to print more debug information. In addition, to avoid code duplication to read iomem, removed the read of iomem from acpi_os_read_memory() in osl.c and made a common function acpi_os_read_iomem(). This new function is used for reading iomem in in both osl.c and acpi_lpit.c. Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/lpit.txt | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/acpi/lpit.txt (limited to 'Documentation') diff --git a/Documentation/acpi/lpit.txt b/Documentation/acpi/lpit.txt new file mode 100644 index 000000000000..b426398d2e97 --- /dev/null +++ b/Documentation/acpi/lpit.txt @@ -0,0 +1,25 @@ +To enumerate platform Low Power Idle states, Intel platforms are using +“Low Power Idle Table” (LPIT). More details about this table can be +downloaded from: +http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf + +Residencies for each low power state can be read via FFH +(Function fixed hardware) or a memory mapped interface. + +On platforms supporting S0ix sleep states, there can be two types of +residencies: +- CPU PKG C10 (Read via FFH interface) +- Platform Controller Hub (PCH) SLP_S0 (Read via memory mapped interface) + +The following attributes are added dynamically to the cpuidle +sysfs attribute group: + /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us + /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us + +The "low_power_idle_cpu_residency_us" attribute shows time spent +by the CPU package in PKG C10 + +The "low_power_idle_system_residency_us" attribute shows SLP_S0 +residency, or system time spent with the SLP_S0# signal asserted. +This is the lowest possible system power state, achieved only when CPU is in +PKG C10 and all functional blocks in PCH are in a low power state. -- cgit v1.2.3 From f5e035f8694c3bdddc66ea46ecda965ee6853718 Mon Sep 17 00:00:00 2001 From: Suzuki K Poulose Date: Wed, 11 Oct 2017 14:01:02 +0100 Subject: arm64: Expose support for optional ARMv8-A features ARMv8-A adds a few optional features for ARMv8.2 and ARMv8.3. Expose them to the userspace via HWCAPs and mrs emulation. SHA2-512 - Instruction support for SHA512 Hash algorithm (e.g SHA512H, SHA512H2, SHA512U0, SHA512SU1) SHA3 - SHA3 crypto instructions (EOR3, RAX1, XAR, BCAX). SM3 - Instruction support for Chinese cryptography algorithm SM3 SM4 - Instruction support for Chinese cryptography algorithm SM4 DP - Dot Product instructions (UDOT, SDOT). Cc: Will Deacon Cc: Mark Rutland Cc: Dave Martin Cc: Marc Zyngier Reviewed-by: Catalin Marinas Signed-off-by: Suzuki K Poulose Signed-off-by: Will Deacon --- Documentation/arm64/cpu-feature-registers.txt | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt index dad411d635d8..011ddfc1e570 100644 --- a/Documentation/arm64/cpu-feature-registers.txt +++ b/Documentation/arm64/cpu-feature-registers.txt @@ -110,10 +110,20 @@ infrastructure: x--------------------------------------------------x | Name | bits | visible | |--------------------------------------------------| - | RES0 | [63-32] | n | + | RES0 | [63-48] | n | + |--------------------------------------------------| + | DP | [47-44] | y | + |--------------------------------------------------| + | SM4 | [43-40] | y | + |--------------------------------------------------| + | SM3 | [39-36] | y | + |--------------------------------------------------| + | SHA3 | [35-32] | y | |--------------------------------------------------| | RDM | [31-28] | y | |--------------------------------------------------| + | RES0 | [27-24] | n | + |--------------------------------------------------| | ATOMICS | [23-20] | y | |--------------------------------------------------| | CRC32 | [19-16] | y | -- cgit v1.2.3 From 611a7bc74ed2dcbab6693c20bb534cfcf15f9d1d Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Wed, 11 Oct 2017 14:01:03 +0100 Subject: arm64: docs: describe ELF hwcaps We don't document our ELF hwcaps, leaving developers to interpret them according to hearsay, guesswork, or (in exceptional cases) inspection of the current kernel code. This is less than optimal, and it would be far better if we had some definitive description of each of the ELF hwcaps that developers could refer to. This patch adds a document describing the (native) arm64 ELF hwcaps. Cc: Catalin Marinas Cc: Dave Martin Cc: Will Deacon Signed-off-by: Mark Rutland [ Updated new hwcap entries in the document ] Signed-off-by: Suzuki K Poulose Signed-off-by: Will Deacon --- Documentation/arm64/elf_hwcaps.txt | 156 +++++++++++++++++++++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 Documentation/arm64/elf_hwcaps.txt (limited to 'Documentation') diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt new file mode 100644 index 000000000000..0ba180522e3c --- /dev/null +++ b/Documentation/arm64/elf_hwcaps.txt @@ -0,0 +1,156 @@ +ARM64 ELF hwcaps +================ + +This document describes the usage and semantics of the arm64 ELF hwcaps. + + +1. Introduction +--------------- + +Some hardware or software features are only available on some CPU +implementations, and/or with certain kernel configurations, but have no +architected discovery mechanism available to userspace code at EL0. The +kernel exposes the presence of these features to userspace through a set +of flags called hwcaps, exposed in the auxilliary vector. + +Userspace software can test for features by acquiring the AT_HWCAP entry +of the auxilliary vector, and testing whether the relevant flags are +set, e.g. + +bool floating_point_is_present(void) +{ + unsigned long hwcaps = getauxval(AT_HWCAP); + if (hwcaps & HWCAP_FP) + return true; + + return false; +} + +Where software relies on a feature described by a hwcap, it should check +the relevant hwcap flag to verify that the feature is present before +attempting to make use of the feature. + +Features cannot be probed reliably through other means. When a feature +is not available, attempting to use it may result in unpredictable +behaviour, and is not guaranteed to result in any reliable indication +that the feature is unavailable, such as a SIGILL. + + +2. Interpretation of hwcaps +--------------------------- + +The majority of hwcaps are intended to indicate the presence of features +which are described by architected ID registers inaccessible to +userspace code at EL0. These hwcaps are defined in terms of ID register +fields, and should be interpreted with reference to the definition of +these fields in the ARM Architecture Reference Manual (ARM ARM). + +Such hwcaps are described below in the form: + + Functionality implied by idreg.field == val. + +Such hwcaps indicate the availability of functionality that the ARM ARM +defines as being present when idreg.field has value val, but do not +indicate that idreg.field is precisely equal to val, nor do they +indicate the absence of functionality implied by other values of +idreg.field. + +Other hwcaps may indicate the presence of features which cannot be +described by ID registers alone. These may be described without +reference to ID registers, and may refer to other documentation. + + +3. The hwcaps exposed in AT_HWCAP +--------------------------------- + +HWCAP_FP + + Functionality implied by ID_AA64PFR0_EL1.FP == 0b0000. + +HWCAP_ASIMD + + Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0000. + +HWCAP_EVTSTRM + + The generic timer is configured to generate events at a frequency of + approximately 100KHz. + +HWCAP_AES + + Functionality implied by ID_AA64ISAR1_EL1.AES == 0b0001. + +HWCAP_PMULL + + Functionality implied by ID_AA64ISAR1_EL1.AES == 0b0010. + +HWCAP_SHA1 + + Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001. + +HWCAP_SHA2 + + Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001. + +HWCAP_CRC32 + + Functionality implied by ID_AA64ISAR0_EL1.CRC32 == 0b0001. + +HWCAP_ATOMICS + + Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0010. + +HWCAP_FPHP + + Functionality implied by ID_AA64PFR0_EL1.FP == 0b0001. + +HWCAP_ASIMDHP + + Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0001. + +HWCAP_CPUID + + EL0 access to certain ID registers is available, to the extent + described by Documentation/arm64/cpu-feature-registers.txt. + + These ID registers may imply the availability of features. + +HWCAP_ASIMDRDM + + Functionality implied by ID_AA64ISAR0_EL1.RDM == 0b0001. + +HWCAP_JSCVT + + Functionality implied by ID_AA64ISAR1_EL1.JSCVT == 0b0001. + +HWCAP_FCMA + + Functionality implied by ID_AA64ISAR1_EL1.FCMA == 0b0001. + +HWCAP_LRCPC + + Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0001. + +HWCAP_DCPOP + + Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001. + +HWCAP_SHA3 + + Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001. + +HWCAP_SM3 + + Functionality implied by ID_AA64ISAR0_EL1.SM3 == 0b0001. + +HWCAP_SM4 + + Functionality implied by ID_AA64ISAR0_EL1.SM4 == 0b0001. + +HWCAP_ASIMDDP + + Functionality implied by ID_AA64ISAR0_EL1.DP == 0b0001. + +HWCAP_SHA512 + + Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0002. -- cgit v1.2.3 From 5ce8c7a0e6945fdd48ed99cfcfcc25568c1e5960 Mon Sep 17 00:00:00 2001 From: Marc Gonzalez Date: Fri, 6 Oct 2017 08:23:37 -0400 Subject: media: dt: bindings: Add binding for tango HW IR decoder Add DT binding for the HW IR decoder embedded in SMP86xx/SMP87xx. Signed-off-by: Marc Gonzalez Acked-by: Rob Herring Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/tango-ir.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/tango-ir.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/tango-ir.txt b/Documentation/devicetree/bindings/media/tango-ir.txt new file mode 100644 index 000000000000..a9f00c2bf897 --- /dev/null +++ b/Documentation/devicetree/bindings/media/tango-ir.txt @@ -0,0 +1,21 @@ +Sigma Designs Tango IR NEC/RC-5/RC-6 decoder (SMP86xx and SMP87xx) + +Required properties: + +- compatible: "sigma,smp8642-ir" +- reg: address/size of NEC+RC5 area, address/size of RC6 area +- interrupts: spec for IR IRQ +- clocks: spec for IR clock (typically the crystal oscillator) + +Optional properties: + +- linux,rc-map-name: see Documentation/devicetree/bindings/media/rc.txt + +Example: + + ir@10518 { + compatible = "sigma,smp8642-ir"; + reg = <0x10518 0x18>, <0x105e0 0x1c>; + interrupts = <21 IRQ_TYPE_EDGE_RISING>; + clocks = <&xtal>; + }; -- cgit v1.2.3 From 259a41d9ae8f3689742267f340ad2b159d00b302 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 18 Sep 2017 08:21:37 -0400 Subject: media: dvb_frontend: fix return values for FE_SET_PROPERTY There are several problems with regards to the return of FE_SET_PROPERTY. The original idea were to return per-property return codes via tvp->result field, and to return an updated set of values. However, that never worked. What's actually implemented is: - the FE_SET_PROPERTY implementation doesn't call .get_frontend callback in order to get the actual parameters after return; - the tvp->result field is only filled if there's no error. So, it is always filled with zero; - FE_SET_PROPERTY doesn't call memdup_user() nor any other copy_to_user() function. So, any changes to the properties will be lost; - FE_SET_PROPERTY is declared as a write-only ioctl (IOW). While we could fix the above, it could cause regressions. So, let's just assume what the code really does, updating the documentation accordingly and removing the logic that would update the discarded tvp->result. Reviewed-by: Shuah Khan Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/fe-get-property.rst | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/media/uapi/dvb/fe-get-property.rst b/Documentation/media/uapi/dvb/fe-get-property.rst index 948d2ba84f2c..b69741d9cedf 100644 --- a/Documentation/media/uapi/dvb/fe-get-property.rst +++ b/Documentation/media/uapi/dvb/fe-get-property.rst @@ -48,8 +48,11 @@ depends on the delivery system and on the device: - This call requires read/write access to the device. - - At return, the values are updated to reflect the actual parameters - used. +.. note:: + + At return, the values aren't updated to reflect the actual + parameters used. If the actual parameters are needed, an explicit + call to ``FE_GET_PROPERTY`` is needed. - ``FE_GET_PROPERTY:`` -- cgit v1.2.3 From 7af90c04cc8343fb8063d0b3d7ba135daf3aabde Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 19 Sep 2017 16:46:10 -0400 Subject: media: dtv-core.rst: add chapters and introductory tests for common parts Better document the DVB common parts by adding two sections and an introductory text for each. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/dtv-core.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/media/kapi/dtv-core.rst b/Documentation/media/kapi/dtv-core.rst index de9a228aca8a..4cf9cf63bafd 100644 --- a/Documentation/media/kapi/dtv-core.rst +++ b/Documentation/media/kapi/dtv-core.rst @@ -29,8 +29,20 @@ I2C bus. Digital TV Common functions --------------------------- +Math functions +~~~~~~~~~~~~~~ + +Provide some commonly-used math functions, usually required in order to +estimate signal strength and signal to noise measurements in dB. + .. kernel-doc:: drivers/media/dvb-core/dvb_math.h + +DVB devices +~~~~~~~~~~~ + +Those functions are responsible for handling the DVB device nodes. + .. kernel-doc:: drivers/media/dvb-core/dvbdev.h Digital TV Ring buffer -- cgit v1.2.3 From 5b3b8c81b47aa3ca473d310b1aa3ab93f0ec9c6b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 19 Sep 2017 16:54:15 -0400 Subject: media: dtv-core.rst: split into multiple files Instead of document all kAPI into a single file, split it on multiple ones. That makes easier to maintain each part. As a side effect, it will produce multiple html pages, with is a good idea. No changes at the text. Just some chapter levels changed. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/dtv-ca.rst | 4 + Documentation/media/kapi/dtv-common.rst | 55 +++ Documentation/media/kapi/dtv-core.rst | 585 +----------------------------- Documentation/media/kapi/dtv-demux.rst | 71 ++++ Documentation/media/kapi/dtv-frontend.rst | 443 ++++++++++++++++++++++ 5 files changed, 579 insertions(+), 579 deletions(-) create mode 100644 Documentation/media/kapi/dtv-ca.rst create mode 100644 Documentation/media/kapi/dtv-common.rst create mode 100644 Documentation/media/kapi/dtv-demux.rst create mode 100644 Documentation/media/kapi/dtv-frontend.rst (limited to 'Documentation') diff --git a/Documentation/media/kapi/dtv-ca.rst b/Documentation/media/kapi/dtv-ca.rst new file mode 100644 index 000000000000..a4dd700189b0 --- /dev/null +++ b/Documentation/media/kapi/dtv-ca.rst @@ -0,0 +1,4 @@ +Digital TV Conditional Access kABI +---------------------------------- + +.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h diff --git a/Documentation/media/kapi/dtv-common.rst b/Documentation/media/kapi/dtv-common.rst new file mode 100644 index 000000000000..40cf1033b5e1 --- /dev/null +++ b/Documentation/media/kapi/dtv-common.rst @@ -0,0 +1,55 @@ +Digital TV Common functions +--------------------------- + +Math functions +~~~~~~~~~~~~~~ + +Provide some commonly-used math functions, usually required in order to +estimate signal strength and signal to noise measurements in dB. + +.. kernel-doc:: drivers/media/dvb-core/dvb_math.h + + +DVB devices +~~~~~~~~~~~ + +Those functions are responsible for handling the DVB device nodes. + +.. kernel-doc:: drivers/media/dvb-core/dvbdev.h + +Digital TV Ring buffer +~~~~~~~~~~~~~~~~~~~~~~ + +Those routines implement ring buffers used to handle digital TV data and +copy it from/to userspace. + +.. note:: + + 1) For performance reasons read and write routines don't check buffer sizes + and/or number of bytes free/available. This has to be done before these + routines are called. For example: + + .. code-block:: c + + /* write @buflen: bytes */ + free = dvb_ringbuffer_free(rbuf); + if (free >= buflen) + count = dvb_ringbuffer_write(rbuf, buffer, buflen); + else + /* do something */ + + /* read min. 1000, max. @bufsize: bytes */ + avail = dvb_ringbuffer_avail(rbuf); + if (avail >= 1000) + count = dvb_ringbuffer_read(rbuf, buffer, min(avail, bufsize)); + else + /* do something */ + + 2) If there is exactly one reader and one writer, there is no need + to lock read or write operations. + Two or more readers must be locked against each other. + Flushing the buffer counts as a read operation. + Resetting the buffer counts as a read and write operation. + Two or more writers must be locked against each other. + +.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h diff --git a/Documentation/media/kapi/dtv-core.rst b/Documentation/media/kapi/dtv-core.rst index 4cf9cf63bafd..8ee384f61fa0 100644 --- a/Documentation/media/kapi/dtv-core.rst +++ b/Documentation/media/kapi/dtv-core.rst @@ -26,584 +26,11 @@ I2C bus. abandoned standard, not used anymore) and ATSC version 3.0 current proposals. Currently, the DVB subsystem doesn't implement those standards. -Digital TV Common functions ---------------------------- -Math functions -~~~~~~~~~~~~~~ +.. toctree:: + :maxdepth: 1 -Provide some commonly-used math functions, usually required in order to -estimate signal strength and signal to noise measurements in dB. - -.. kernel-doc:: drivers/media/dvb-core/dvb_math.h - - -DVB devices -~~~~~~~~~~~ - -Those functions are responsible for handling the DVB device nodes. - -.. kernel-doc:: drivers/media/dvb-core/dvbdev.h - -Digital TV Ring buffer ----------------------- - -Those routines implement ring buffers used to handle digital TV data and -copy it from/to userspace. - -.. note:: - - 1) For performance reasons read and write routines don't check buffer sizes - and/or number of bytes free/available. This has to be done before these - routines are called. For example: - - .. code-block:: c - - /* write @buflen: bytes */ - free = dvb_ringbuffer_free(rbuf); - if (free >= buflen) - count = dvb_ringbuffer_write(rbuf, buffer, buflen); - else - /* do something */ - - /* read min. 1000, max. @bufsize: bytes */ - avail = dvb_ringbuffer_avail(rbuf); - if (avail >= 1000) - count = dvb_ringbuffer_read(rbuf, buffer, min(avail, bufsize)); - else - /* do something */ - - 2) If there is exactly one reader and one writer, there is no need - to lock read or write operations. - Two or more readers must be locked against each other. - Flushing the buffer counts as a read operation. - Resetting the buffer counts as a read and write operation. - Two or more writers must be locked against each other. - -.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h - - -Digital TV Frontend kABI ------------------------- - -Digital TV Frontend -~~~~~~~~~~~~~~~~~~~ - -The Digital TV Frontend kABI defines a driver-internal interface for -registering low-level, hardware specific driver to a hardware independent -frontend layer. It is only of interest for Digital TV device driver writers. -The header file for this API is named ``dvb_frontend.h`` and located in -``drivers/media/dvb-core``. - -Demodulator driver -^^^^^^^^^^^^^^^^^^ - -The demodulator driver is responsible to talk with the decoding part of the -hardware. Such driver should implement :c:type:`dvb_frontend_ops`, with -tells what type of digital TV standards are supported, and points to a -series of functions that allow the DVB core to command the hardware via -the code under ``drivers/media/dvb-core/dvb_frontend.c``. - -A typical example of such struct in a driver ``foo`` is:: - - static struct dvb_frontend_ops foo_ops = { - .delsys = { SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A }, - .info = { - .name = "foo DVB-T/T2/C driver", - .caps = FE_CAN_FEC_1_2 | - FE_CAN_FEC_2_3 | - FE_CAN_FEC_3_4 | - FE_CAN_FEC_5_6 | - FE_CAN_FEC_7_8 | - FE_CAN_FEC_AUTO | - FE_CAN_QPSK | - FE_CAN_QAM_16 | - FE_CAN_QAM_32 | - FE_CAN_QAM_64 | - FE_CAN_QAM_128 | - FE_CAN_QAM_256 | - FE_CAN_QAM_AUTO | - FE_CAN_TRANSMISSION_MODE_AUTO | - FE_CAN_GUARD_INTERVAL_AUTO | - FE_CAN_HIERARCHY_AUTO | - FE_CAN_MUTE_TS | - FE_CAN_2G_MODULATION, - .frequency_min = 42000000, /* Hz */ - .frequency_max = 1002000000, /* Hz */ - .symbol_rate_min = 870000, - .symbol_rate_max = 11700000 - }, - .init = foo_init, - .sleep = foo_sleep, - .release = foo_release, - .set_frontend = foo_set_frontend, - .get_frontend = foo_get_frontend, - .read_status = foo_get_status_and_stats, - .tune = foo_tune, - .i2c_gate_ctrl = foo_i2c_gate_ctrl, - .get_frontend_algo = foo_get_algo, - }; - -A typical example of such struct in a driver ``bar`` meant to be used on -Satellite TV reception is:: - - static const struct dvb_frontend_ops bar_ops = { - .delsys = { SYS_DVBS, SYS_DVBS2 }, - .info = { - .name = "Bar DVB-S/S2 demodulator", - .frequency_min = 500000, /* KHz */ - .frequency_max = 2500000, /* KHz */ - .frequency_stepsize = 0, - .symbol_rate_min = 1000000, - .symbol_rate_max = 45000000, - .symbol_rate_tolerance = 500, - .caps = FE_CAN_INVERSION_AUTO | - FE_CAN_FEC_AUTO | - FE_CAN_QPSK, - }, - .init = bar_init, - .sleep = bar_sleep, - .release = bar_release, - .set_frontend = bar_set_frontend, - .get_frontend = bar_get_frontend, - .read_status = bar_get_status_and_stats, - .i2c_gate_ctrl = bar_i2c_gate_ctrl, - .get_frontend_algo = bar_get_algo, - .tune = bar_tune, - - /* Satellite-specific */ - .diseqc_send_master_cmd = bar_send_diseqc_msg, - .diseqc_send_burst = bar_send_burst, - .set_tone = bar_set_tone, - .set_voltage = bar_set_voltage, - }; - -.. note:: - - #) For satellite digital TV standards (DVB-S, DVB-S2, ISDB-S), the - frequencies are specified in kHz, while, for terrestrial and cable - standards, they're specified in Hz. Due to that, if the same frontend - supports both types, you'll need to have two separate - :c:type:`dvb_frontend_ops` structures, one for each standard. - #) The ``.i2c_gate_ctrl`` field is present only when the hardware has - allows controlling an I2C gate (either directly of via some GPIO pin), - in order to remove the tuner from the I2C bus after a channel is - tuned. - #) All new drivers should implement the - :ref:`DVBv5 statistics ` via ``.read_status``. - Yet, there are a number of callbacks meant to get statistics for - signal strength, S/N and UCB. Those are there to provide backward - compatibility with legacy applications that don't support the DVBv5 - API. Implementing those callbacks are optional. Those callbacks may be - removed in the future, after we have all existing drivers supporting - DVBv5 stats. - #) Other callbacks are required for satellite TV standards, in order to - control LNBf and DiSEqC: ``.diseqc_send_master_cmd``, - ``.diseqc_send_burst``, ``.set_tone``, ``.set_voltage``. - -.. |delta| unicode:: U+00394 - -The ``drivers/media/dvb-core/dvb_frontend.c`` has a kernel thread with is -responsible for tuning the device. It supports multiple algoritms to -detect a channel, as defined at enum :c:func:`dvbfe_algo`. - -The algorithm to be used is obtained via ``.get_frontend_algo``. If the driver -doesn't fill its field at struct :c:type:`dvb_frontend_ops`, it will default to -``DVBFE_ALGO_SW``, meaning that the dvb-core will do a zigzag when tuning, -e. g. it will try first to use the specified center frequency ``f``, -then, it will do ``f`` + |delta|, ``f`` - |delta|, ``f`` + 2 x |delta|, -``f`` - 2 x |delta| and so on. - -If the hardware has internally a some sort of zigzag algorithm, you should -define a ``.get_frontend_algo`` function that would return ``DVBFE_ALGO_HW``. - -.. note:: - - The core frontend support also supports - a third type (``DVBFE_ALGO_CUSTOM``), in order to allow the driver to - define its own hardware-assisted algorithm. Very few hardware need to - use it nowadays. Using ``DVBFE_ALGO_CUSTOM`` require to provide other - function callbacks at struct :c:type:`dvb_frontend_ops`. - -Attaching frontend driver to the bridge driver -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Before using the Digital TV frontend core, the bridge driver should attach -the frontend demod, tuner and SEC devices and call -:c:func:`dvb_register_frontend()`, -in order to register the new frontend at the subsystem. At device -detach/removal, the bridge driver should call -:c:func:`dvb_unregister_frontend()` to -remove the frontend from the core and then :c:func:`dvb_frontend_detach()` -to free the memory allocated by the frontend drivers. - -The drivers should also call :c:func:`dvb_frontend_suspend()` as part of -their handler for the :c:type:`device_driver`.\ ``suspend()``, and -:c:func:`dvb_frontend_resume()` as -part of their handler for :c:type:`device_driver`.\ ``resume()``. - -A few other optional functions are provided to handle some special cases. - -.. _dvbv5_stats: - -Digital TV Frontend statistics -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Introduction -^^^^^^^^^^^^ - -Digital TV frontends provide a range of -:ref:`statistics ` meant to help tuning the device -and measuring the quality of service. - -For each statistics measurement, the driver should set the type of scale used, -or ``FE_SCALE_NOT_AVAILABLE`` if the statistics is not available on a given -time. Drivers should also provide the number of statistics for each type. -that's usually 1 for most video standards [#f2]_. - -Drivers should initialize each statistic counters with length and -scale at its init code. For example, if the frontend provides signal -strength, it should have, on its init code:: - - struct dtv_frontend_properties *c = &state->fe.dtv_property_cache; - - c->strength.len = 1; - c->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE; - -And, when the statistics got updated, set the scale:: - - c->strength.stat[0].scale = FE_SCALE_DECIBEL; - c->strength.stat[0].uvalue = strength; - -.. [#f2] For ISDB-T, it may provide both a global statistics and a per-layer - set of statistics. On such cases, len should be equal to 4. The first - value corresponds to the global stat; the other ones to each layer, e. g.: - - - c->cnr.stat[0] for global S/N carrier ratio, - - c->cnr.stat[1] for Layer A S/N carrier ratio, - - c->cnr.stat[2] for layer B S/N carrier ratio, - - c->cnr.stat[3] for layer C S/N carrier ratio. - -.. note:: Please prefer to use ``FE_SCALE_DECIBEL`` instead of - ``FE_SCALE_RELATIVE`` for signal strength and CNR measurements. - -Groups of statistics -^^^^^^^^^^^^^^^^^^^^ - -There are several groups of statistics currently supported: - -Signal strength (:ref:`DTV-STAT-SIGNAL-STRENGTH`) - - Measures the signal strength level at the analog part of the tuner or - demod. - - - Typically obtained from the gain applied to the tuner and/or frontend - in order to detect the carrier. When no carrier is detected, the gain is - at the maximum value (so, strength is on its minimal). - - - As the gain is visible through the set of registers that adjust the gain, - typically, this statistics is always available [#f3]_. - - - Drivers should try to make it available all the times, as this statistics - can be used when adjusting an antenna position and to check for troubles - at the cabling. - - .. [#f3] On a few devices, the gain keeps floating if no carrier. - On such devices, strength report should check first if carrier is - detected at the tuner (``FE_HAS_CARRIER``, see :c:type:`fe_status`), - and otherwise return the lowest possible value. - -Carrier Signal to Noise ratio (:ref:`DTV-STAT-CNR`) - - Signal to Noise ratio for the main carrier. - - - Signal to Noise measurement depends on the device. On some hardware, is - available when the main carrier is detected. On those hardware, CNR - measurement usually comes from the tuner (e. g. after ``FE_HAS_CARRIER``, - see :c:type:`fe_status`). - - On other devices, it requires inner FEC decoding, - as the frontend measures it indirectly from other parameters (e. g. after - ``FE_HAS_VITERBI``, see :c:type:`fe_status`). - - Having it available after inner FEC is more common. - -Bit counts post-FEC (:ref:`DTV-STAT-POST-ERROR-BIT-COUNT` and :ref:`DTV-STAT-POST-TOTAL-BIT-COUNT`) - - Those counters measure the number of bits and bit errors errors after - the forward error correction (FEC) on the inner coding block - (after Viterbi, LDPC or other inner code). - - - Due to its nature, those statistics depend on full coding lock - (e. g. after ``FE_HAS_SYNC`` or after ``FE_HAS_LOCK``, - see :c:type:`fe_status`). - -Bit counts pre-FEC (:ref:`DTV-STAT-PRE-ERROR-BIT-COUNT` and :ref:`DTV-STAT-PRE-TOTAL-BIT-COUNT`) - - Those counters measure the number of bits and bit errors errors before - the forward error correction (FEC) on the inner coding block - (before Viterbi, LDPC or other inner code). - - - Not all frontends provide this kind of statistics. - - - Due to its nature, those statistics depend on inner coding lock (e. g. - after ``FE_HAS_VITERBI``, see :c:type:`fe_status`). - -Block counts (:ref:`DTV-STAT-ERROR-BLOCK-COUNT` and :ref:`DTV-STAT-TOTAL-BLOCK-COUNT`) - - Those counters measure the number of blocks and block errors errors after - the forward error correction (FEC) on the inner coding block - (before Viterbi, LDPC or other inner code). - - - Due to its nature, those statistics depend on full coding lock - (e. g. after ``FE_HAS_SYNC`` or after - ``FE_HAS_LOCK``, see :c:type:`fe_status`). - -.. note:: All counters should be monotonically increased as they're - collected from the hardware. - -A typical example of the logic that handle status and statistics is:: - - static int foo_get_status_and_stats(struct dvb_frontend *fe) - { - struct foo_state *state = fe->demodulator_priv; - struct dtv_frontend_properties *c = &fe->dtv_property_cache; - - int rc; - enum fe_status *status; - - /* Both status and strength are always available */ - rc = foo_read_status(fe, &status); - if (rc < 0) - return rc; - - rc = foo_read_strength(fe); - if (rc < 0) - return rc; - - /* Check if CNR is available */ - if (!(fe->status & FE_HAS_CARRIER)) - return 0; - - rc = foo_read_cnr(fe); - if (rc < 0) - return rc; - - /* Check if pre-BER stats are available */ - if (!(fe->status & FE_HAS_VITERBI)) - return 0; - - rc = foo_get_pre_ber(fe); - if (rc < 0) - return rc; - - /* Check if post-BER stats are available */ - if (!(fe->status & FE_HAS_SYNC)) - return 0; - - rc = foo_get_post_ber(fe); - if (rc < 0) - return rc; - } - - static const struct dvb_frontend_ops ops = { - /* ... */ - .read_status = foo_get_status_and_stats, - }; - -Statistics collect -^^^^^^^^^^^^^^^^^^ - -On almost all frontend hardware, the bit and byte counts are stored by -the hardware after a certain amount of time or after the total bit/block -counter reaches a certain value (usually programable), for example, on -every 1000 ms or after receiving 1,000,000 bits. - -So, if you read the registers too soon, you'll end by reading the same -value as in the previous reading, causing the monotonic value to be -incremented too often. - -Drivers should take the responsibility to avoid too often reads. That -can be done using two approaches: - -if the driver have a bit that indicates when a collected data is ready -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -Driver should check such bit before making the statistics available. - -An example of such behavior can be found at this code snippet (adapted -from mb86a20s driver's logic):: - - static int foo_get_pre_ber(struct dvb_frontend *fe) - { - struct foo_state *state = fe->demodulator_priv; - struct dtv_frontend_properties *c = &fe->dtv_property_cache; - int rc, bit_error; - - /* Check if the BER measures are already available */ - rc = foo_read_u8(state, 0x54); - if (rc < 0) - return rc; - - if (!rc) - return 0; - - /* Read Bit Error Count */ - bit_error = foo_read_u32(state, 0x55); - if (bit_error < 0) - return bit_error; - - /* Read Total Bit Count */ - rc = foo_read_u32(state, 0x51); - if (rc < 0) - return rc; - - c->pre_bit_error.stat[0].scale = FE_SCALE_COUNTER; - c->pre_bit_error.stat[0].uvalue += bit_error; - c->pre_bit_count.stat[0].scale = FE_SCALE_COUNTER; - c->pre_bit_count.stat[0].uvalue += rc; - - return 0; - } - -If the driver doesn't provide a statistics available check bit -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -A few devices, however, may not provide a way to check if the stats are -available (or the way to check it is unknown). They may not even provide -a way to directly read the total number of bits or blocks. - -On those devices, the driver need to ensure that it won't be reading from -the register too often and/or estimate the total number of bits/blocks. - -On such drivers, a typical routine to get statistics would be like -(adapted from dib8000 driver's logic):: - - struct foo_state { - /* ... */ - - unsigned long per_jiffies_stats; - } - - static int foo_get_pre_ber(struct dvb_frontend *fe) - { - struct foo_state *state = fe->demodulator_priv; - struct dtv_frontend_properties *c = &fe->dtv_property_cache; - int rc, bit_error; - u64 bits; - - /* Check if time for stats was elapsed */ - if (!time_after(jiffies, state->per_jiffies_stats)) - return 0; - - /* Next stat should be collected in 1000 ms */ - state->per_jiffies_stats = jiffies + msecs_to_jiffies(1000); - - /* Read Bit Error Count */ - bit_error = foo_read_u32(state, 0x55); - if (bit_error < 0) - return bit_error; - - /* - * On this particular frontend, there's no register that - * would provide the number of bits per 1000ms sample. So, - * some function would calculate it based on DTV properties - */ - bits = get_number_of_bits_per_1000ms(fe); - - c->pre_bit_error.stat[0].scale = FE_SCALE_COUNTER; - c->pre_bit_error.stat[0].uvalue += bit_error; - c->pre_bit_count.stat[0].scale = FE_SCALE_COUNTER; - c->pre_bit_count.stat[0].uvalue += bits; - - return 0; - } - -Please notice that, on both cases, we're getting the statistics using the -:c:type:`dvb_frontend_ops` ``.read_status`` callback. The rationale is that -the frontend core will automatically call this function periodically -(usually, 3 times per second, when the frontend is locked). - -That warrants that we won't miss to collect a counter and increment the -monotonic stats at the right time. - -Digital TV Frontend functions and types -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: drivers/media/dvb-core/dvb_frontend.h - - -Digital TV Demux kABI ---------------------- - -Digital TV Demux -~~~~~~~~~~~~~~~~ - -The Kernel Digital TV Demux kABI defines a driver-internal interface for -registering low-level, hardware specific driver to a hardware independent -demux layer. It is only of interest for Digital TV device driver writers. -The header file for this kABI is named demux.h and located in -drivers/media/dvb-core. - -The demux kABI should be implemented for each demux in the system. It is -used to select the TS source of a demux and to manage the demux resources. -When the demux client allocates a resource via the demux kABI, it receives -a pointer to the kABI of that resource. - -Each demux receives its TS input from a DVB front-end or from memory, as -set via this demux kABI. In a system with more than one front-end, the kABI -can be used to select one of the DVB front-ends as a TS source for a demux, -unless this is fixed in the HW platform. - -The demux kABI only controls front-ends regarding to their connections with -demuxes; the kABI used to set the other front-end parameters, such as -tuning, are devined via the Digital TV Frontend kABI. - -The functions that implement the abstract interface demux should be defined -static or module private and registered to the Demux core for external -access. It is not necessary to implement every function in the struct -&dmx_demux. For example, a demux interface might support Section filtering, -but not PES filtering. The kABI client is expected to check the value of any -function pointer before calling the function: the value of ``NULL`` means -that the function is not available. - -Whenever the functions of the demux API modify shared data, the -possibilities of lost update and race condition problems should be -addressed, e.g. by protecting parts of code with mutexes. - -Note that functions called from a bottom half context must not sleep. -Even a simple memory allocation without using ``GFP_ATOMIC`` can result in a -kernel thread being put to sleep if swapping is needed. For example, the -Linux Kernel calls the functions of a network device interface from a -bottom half context. Thus, if a demux kABI function is called from network -device code, the function must not sleep. - - - -Demux Callback API ------------------- - -Demux Callback -~~~~~~~~~~~~~~ - -This kernel-space API comprises the callback functions that deliver filtered -data to the demux client. Unlike the other DVB kABIs, these functions are -provided by the client and called from the demux code. - -The function pointers of this abstract interface are not packed into a -structure as in the other demux APIs, because the callback functions are -registered and used independent of each other. As an example, it is possible -for the API client to provide several callback functions for receiving TS -packets and no callbacks for PES packets or sections. - -The functions that implement the callback API need not be re-entrant: when -a demux driver calls one of these functions, the driver is not allowed to -call the function again before the original call returns. If a callback is -triggered by a hardware interrupt, it is recommended to use the Linux -bottom half mechanism or start a tasklet instead of making the callback -function call directly from a hardware interrupt. - -This mechanism is implemented by :c:func:`dmx_ts_cb()` and :c:func:`dmx_section_cb()` -callbacks. - -.. kernel-doc:: drivers/media/dvb-core/demux.h - -Digital TV Conditional Access kABI ----------------------------------- - -.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h + dtv-common + dtv-frontend + dtv-demux + dtv-ca diff --git a/Documentation/media/kapi/dtv-demux.rst b/Documentation/media/kapi/dtv-demux.rst new file mode 100644 index 000000000000..8169c479156e --- /dev/null +++ b/Documentation/media/kapi/dtv-demux.rst @@ -0,0 +1,71 @@ +Digital TV Demux kABI +--------------------- + +Digital TV Demux +~~~~~~~~~~~~~~~~ + +The Kernel Digital TV Demux kABI defines a driver-internal interface for +registering low-level, hardware specific driver to a hardware independent +demux layer. It is only of interest for Digital TV device driver writers. +The header file for this kABI is named demux.h and located in +drivers/media/dvb-core. + +The demux kABI should be implemented for each demux in the system. It is +used to select the TS source of a demux and to manage the demux resources. +When the demux client allocates a resource via the demux kABI, it receives +a pointer to the kABI of that resource. + +Each demux receives its TS input from a DVB front-end or from memory, as +set via this demux kABI. In a system with more than one front-end, the kABI +can be used to select one of the DVB front-ends as a TS source for a demux, +unless this is fixed in the HW platform. + +The demux kABI only controls front-ends regarding to their connections with +demuxes; the kABI used to set the other front-end parameters, such as +tuning, are devined via the Digital TV Frontend kABI. + +The functions that implement the abstract interface demux should be defined +static or module private and registered to the Demux core for external +access. It is not necessary to implement every function in the struct +&dmx_demux. For example, a demux interface might support Section filtering, +but not PES filtering. The kABI client is expected to check the value of any +function pointer before calling the function: the value of ``NULL`` means +that the function is not available. + +Whenever the functions of the demux API modify shared data, the +possibilities of lost update and race condition problems should be +addressed, e.g. by protecting parts of code with mutexes. + +Note that functions called from a bottom half context must not sleep. +Even a simple memory allocation without using ``GFP_ATOMIC`` can result in a +kernel thread being put to sleep if swapping is needed. For example, the +Linux Kernel calls the functions of a network device interface from a +bottom half context. Thus, if a demux kABI function is called from network +device code, the function must not sleep. + + + +Demux Callback API +~~~~~~~~~~~~~~~~~~ + +This kernel-space API comprises the callback functions that deliver filtered +data to the demux client. Unlike the other DVB kABIs, these functions are +provided by the client and called from the demux code. + +The function pointers of this abstract interface are not packed into a +structure as in the other demux APIs, because the callback functions are +registered and used independent of each other. As an example, it is possible +for the API client to provide several callback functions for receiving TS +packets and no callbacks for PES packets or sections. + +The functions that implement the callback API need not be re-entrant: when +a demux driver calls one of these functions, the driver is not allowed to +call the function again before the original call returns. If a callback is +triggered by a hardware interrupt, it is recommended to use the Linux +bottom half mechanism or start a tasklet instead of making the callback +function call directly from a hardware interrupt. + +This mechanism is implemented by :c:func:`dmx_ts_cb()` and :c:func:`dmx_section_cb()` +callbacks. + +.. kernel-doc:: drivers/media/dvb-core/demux.h diff --git a/Documentation/media/kapi/dtv-frontend.rst b/Documentation/media/kapi/dtv-frontend.rst new file mode 100644 index 000000000000..9f67b7a7387d --- /dev/null +++ b/Documentation/media/kapi/dtv-frontend.rst @@ -0,0 +1,443 @@ +Digital TV Frontend kABI +------------------------ + +Digital TV Frontend +~~~~~~~~~~~~~~~~~~~ + +The Digital TV Frontend kABI defines a driver-internal interface for +registering low-level, hardware specific driver to a hardware independent +frontend layer. It is only of interest for Digital TV device driver writers. +The header file for this API is named ``dvb_frontend.h`` and located in +``drivers/media/dvb-core``. + +Demodulator driver +^^^^^^^^^^^^^^^^^^ + +The demodulator driver is responsible to talk with the decoding part of the +hardware. Such driver should implement :c:type:`dvb_frontend_ops`, with +tells what type of digital TV standards are supported, and points to a +series of functions that allow the DVB core to command the hardware via +the code under ``drivers/media/dvb-core/dvb_frontend.c``. + +A typical example of such struct in a driver ``foo`` is:: + + static struct dvb_frontend_ops foo_ops = { + .delsys = { SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A }, + .info = { + .name = "foo DVB-T/T2/C driver", + .caps = FE_CAN_FEC_1_2 | + FE_CAN_FEC_2_3 | + FE_CAN_FEC_3_4 | + FE_CAN_FEC_5_6 | + FE_CAN_FEC_7_8 | + FE_CAN_FEC_AUTO | + FE_CAN_QPSK | + FE_CAN_QAM_16 | + FE_CAN_QAM_32 | + FE_CAN_QAM_64 | + FE_CAN_QAM_128 | + FE_CAN_QAM_256 | + FE_CAN_QAM_AUTO | + FE_CAN_TRANSMISSION_MODE_AUTO | + FE_CAN_GUARD_INTERVAL_AUTO | + FE_CAN_HIERARCHY_AUTO | + FE_CAN_MUTE_TS | + FE_CAN_2G_MODULATION, + .frequency_min = 42000000, /* Hz */ + .frequency_max = 1002000000, /* Hz */ + .symbol_rate_min = 870000, + .symbol_rate_max = 11700000 + }, + .init = foo_init, + .sleep = foo_sleep, + .release = foo_release, + .set_frontend = foo_set_frontend, + .get_frontend = foo_get_frontend, + .read_status = foo_get_status_and_stats, + .tune = foo_tune, + .i2c_gate_ctrl = foo_i2c_gate_ctrl, + .get_frontend_algo = foo_get_algo, + }; + +A typical example of such struct in a driver ``bar`` meant to be used on +Satellite TV reception is:: + + static const struct dvb_frontend_ops bar_ops = { + .delsys = { SYS_DVBS, SYS_DVBS2 }, + .info = { + .name = "Bar DVB-S/S2 demodulator", + .frequency_min = 500000, /* KHz */ + .frequency_max = 2500000, /* KHz */ + .frequency_stepsize = 0, + .symbol_rate_min = 1000000, + .symbol_rate_max = 45000000, + .symbol_rate_tolerance = 500, + .caps = FE_CAN_INVERSION_AUTO | + FE_CAN_FEC_AUTO | + FE_CAN_QPSK, + }, + .init = bar_init, + .sleep = bar_sleep, + .release = bar_release, + .set_frontend = bar_set_frontend, + .get_frontend = bar_get_frontend, + .read_status = bar_get_status_and_stats, + .i2c_gate_ctrl = bar_i2c_gate_ctrl, + .get_frontend_algo = bar_get_algo, + .tune = bar_tune, + + /* Satellite-specific */ + .diseqc_send_master_cmd = bar_send_diseqc_msg, + .diseqc_send_burst = bar_send_burst, + .set_tone = bar_set_tone, + .set_voltage = bar_set_voltage, + }; + +.. note:: + + #) For satellite digital TV standards (DVB-S, DVB-S2, ISDB-S), the + frequencies are specified in kHz, while, for terrestrial and cable + standards, they're specified in Hz. Due to that, if the same frontend + supports both types, you'll need to have two separate + :c:type:`dvb_frontend_ops` structures, one for each standard. + #) The ``.i2c_gate_ctrl`` field is present only when the hardware has + allows controlling an I2C gate (either directly of via some GPIO pin), + in order to remove the tuner from the I2C bus after a channel is + tuned. + #) All new drivers should implement the + :ref:`DVBv5 statistics ` via ``.read_status``. + Yet, there are a number of callbacks meant to get statistics for + signal strength, S/N and UCB. Those are there to provide backward + compatibility with legacy applications that don't support the DVBv5 + API. Implementing those callbacks are optional. Those callbacks may be + removed in the future, after we have all existing drivers supporting + DVBv5 stats. + #) Other callbacks are required for satellite TV standards, in order to + control LNBf and DiSEqC: ``.diseqc_send_master_cmd``, + ``.diseqc_send_burst``, ``.set_tone``, ``.set_voltage``. + +.. |delta| unicode:: U+00394 + +The ``drivers/media/dvb-core/dvb_frontend.c`` has a kernel thread with is +responsible for tuning the device. It supports multiple algoritms to +detect a channel, as defined at enum :c:func:`dvbfe_algo`. + +The algorithm to be used is obtained via ``.get_frontend_algo``. If the driver +doesn't fill its field at struct :c:type:`dvb_frontend_ops`, it will default to +``DVBFE_ALGO_SW``, meaning that the dvb-core will do a zigzag when tuning, +e. g. it will try first to use the specified center frequency ``f``, +then, it will do ``f`` + |delta|, ``f`` - |delta|, ``f`` + 2 x |delta|, +``f`` - 2 x |delta| and so on. + +If the hardware has internally a some sort of zigzag algorithm, you should +define a ``.get_frontend_algo`` function that would return ``DVBFE_ALGO_HW``. + +.. note:: + + The core frontend support also supports + a third type (``DVBFE_ALGO_CUSTOM``), in order to allow the driver to + define its own hardware-assisted algorithm. Very few hardware need to + use it nowadays. Using ``DVBFE_ALGO_CUSTOM`` require to provide other + function callbacks at struct :c:type:`dvb_frontend_ops`. + +Attaching frontend driver to the bridge driver +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Before using the Digital TV frontend core, the bridge driver should attach +the frontend demod, tuner and SEC devices and call +:c:func:`dvb_register_frontend()`, +in order to register the new frontend at the subsystem. At device +detach/removal, the bridge driver should call +:c:func:`dvb_unregister_frontend()` to +remove the frontend from the core and then :c:func:`dvb_frontend_detach()` +to free the memory allocated by the frontend drivers. + +The drivers should also call :c:func:`dvb_frontend_suspend()` as part of +their handler for the :c:type:`device_driver`.\ ``suspend()``, and +:c:func:`dvb_frontend_resume()` as +part of their handler for :c:type:`device_driver`.\ ``resume()``. + +A few other optional functions are provided to handle some special cases. + +.. _dvbv5_stats: + +Digital TV Frontend statistics +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Introduction +^^^^^^^^^^^^ + +Digital TV frontends provide a range of +:ref:`statistics ` meant to help tuning the device +and measuring the quality of service. + +For each statistics measurement, the driver should set the type of scale used, +or ``FE_SCALE_NOT_AVAILABLE`` if the statistics is not available on a given +time. Drivers should also provide the number of statistics for each type. +that's usually 1 for most video standards [#f2]_. + +Drivers should initialize each statistic counters with length and +scale at its init code. For example, if the frontend provides signal +strength, it should have, on its init code:: + + struct dtv_frontend_properties *c = &state->fe.dtv_property_cache; + + c->strength.len = 1; + c->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE; + +And, when the statistics got updated, set the scale:: + + c->strength.stat[0].scale = FE_SCALE_DECIBEL; + c->strength.stat[0].uvalue = strength; + +.. [#f2] For ISDB-T, it may provide both a global statistics and a per-layer + set of statistics. On such cases, len should be equal to 4. The first + value corresponds to the global stat; the other ones to each layer, e. g.: + + - c->cnr.stat[0] for global S/N carrier ratio, + - c->cnr.stat[1] for Layer A S/N carrier ratio, + - c->cnr.stat[2] for layer B S/N carrier ratio, + - c->cnr.stat[3] for layer C S/N carrier ratio. + +.. note:: Please prefer to use ``FE_SCALE_DECIBEL`` instead of + ``FE_SCALE_RELATIVE`` for signal strength and CNR measurements. + +Groups of statistics +^^^^^^^^^^^^^^^^^^^^ + +There are several groups of statistics currently supported: + +Signal strength (:ref:`DTV-STAT-SIGNAL-STRENGTH`) + - Measures the signal strength level at the analog part of the tuner or + demod. + + - Typically obtained from the gain applied to the tuner and/or frontend + in order to detect the carrier. When no carrier is detected, the gain is + at the maximum value (so, strength is on its minimal). + + - As the gain is visible through the set of registers that adjust the gain, + typically, this statistics is always available [#f3]_. + + - Drivers should try to make it available all the times, as this statistics + can be used when adjusting an antenna position and to check for troubles + at the cabling. + + .. [#f3] On a few devices, the gain keeps floating if no carrier. + On such devices, strength report should check first if carrier is + detected at the tuner (``FE_HAS_CARRIER``, see :c:type:`fe_status`), + and otherwise return the lowest possible value. + +Carrier Signal to Noise ratio (:ref:`DTV-STAT-CNR`) + - Signal to Noise ratio for the main carrier. + + - Signal to Noise measurement depends on the device. On some hardware, is + available when the main carrier is detected. On those hardware, CNR + measurement usually comes from the tuner (e. g. after ``FE_HAS_CARRIER``, + see :c:type:`fe_status`). + + On other devices, it requires inner FEC decoding, + as the frontend measures it indirectly from other parameters (e. g. after + ``FE_HAS_VITERBI``, see :c:type:`fe_status`). + + Having it available after inner FEC is more common. + +Bit counts post-FEC (:ref:`DTV-STAT-POST-ERROR-BIT-COUNT` and :ref:`DTV-STAT-POST-TOTAL-BIT-COUNT`) + - Those counters measure the number of bits and bit errors errors after + the forward error correction (FEC) on the inner coding block + (after Viterbi, LDPC or other inner code). + + - Due to its nature, those statistics depend on full coding lock + (e. g. after ``FE_HAS_SYNC`` or after ``FE_HAS_LOCK``, + see :c:type:`fe_status`). + +Bit counts pre-FEC (:ref:`DTV-STAT-PRE-ERROR-BIT-COUNT` and :ref:`DTV-STAT-PRE-TOTAL-BIT-COUNT`) + - Those counters measure the number of bits and bit errors errors before + the forward error correction (FEC) on the inner coding block + (before Viterbi, LDPC or other inner code). + + - Not all frontends provide this kind of statistics. + + - Due to its nature, those statistics depend on inner coding lock (e. g. + after ``FE_HAS_VITERBI``, see :c:type:`fe_status`). + +Block counts (:ref:`DTV-STAT-ERROR-BLOCK-COUNT` and :ref:`DTV-STAT-TOTAL-BLOCK-COUNT`) + - Those counters measure the number of blocks and block errors errors after + the forward error correction (FEC) on the inner coding block + (before Viterbi, LDPC or other inner code). + + - Due to its nature, those statistics depend on full coding lock + (e. g. after ``FE_HAS_SYNC`` or after + ``FE_HAS_LOCK``, see :c:type:`fe_status`). + +.. note:: All counters should be monotonically increased as they're + collected from the hardware. + +A typical example of the logic that handle status and statistics is:: + + static int foo_get_status_and_stats(struct dvb_frontend *fe) + { + struct foo_state *state = fe->demodulator_priv; + struct dtv_frontend_properties *c = &fe->dtv_property_cache; + + int rc; + enum fe_status *status; + + /* Both status and strength are always available */ + rc = foo_read_status(fe, &status); + if (rc < 0) + return rc; + + rc = foo_read_strength(fe); + if (rc < 0) + return rc; + + /* Check if CNR is available */ + if (!(fe->status & FE_HAS_CARRIER)) + return 0; + + rc = foo_read_cnr(fe); + if (rc < 0) + return rc; + + /* Check if pre-BER stats are available */ + if (!(fe->status & FE_HAS_VITERBI)) + return 0; + + rc = foo_get_pre_ber(fe); + if (rc < 0) + return rc; + + /* Check if post-BER stats are available */ + if (!(fe->status & FE_HAS_SYNC)) + return 0; + + rc = foo_get_post_ber(fe); + if (rc < 0) + return rc; + } + + static const struct dvb_frontend_ops ops = { + /* ... */ + .read_status = foo_get_status_and_stats, + }; + +Statistics collect +^^^^^^^^^^^^^^^^^^ + +On almost all frontend hardware, the bit and byte counts are stored by +the hardware after a certain amount of time or after the total bit/block +counter reaches a certain value (usually programable), for example, on +every 1000 ms or after receiving 1,000,000 bits. + +So, if you read the registers too soon, you'll end by reading the same +value as in the previous reading, causing the monotonic value to be +incremented too often. + +Drivers should take the responsibility to avoid too often reads. That +can be done using two approaches: + +if the driver have a bit that indicates when a collected data is ready +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +Driver should check such bit before making the statistics available. + +An example of such behavior can be found at this code snippet (adapted +from mb86a20s driver's logic):: + + static int foo_get_pre_ber(struct dvb_frontend *fe) + { + struct foo_state *state = fe->demodulator_priv; + struct dtv_frontend_properties *c = &fe->dtv_property_cache; + int rc, bit_error; + + /* Check if the BER measures are already available */ + rc = foo_read_u8(state, 0x54); + if (rc < 0) + return rc; + + if (!rc) + return 0; + + /* Read Bit Error Count */ + bit_error = foo_read_u32(state, 0x55); + if (bit_error < 0) + return bit_error; + + /* Read Total Bit Count */ + rc = foo_read_u32(state, 0x51); + if (rc < 0) + return rc; + + c->pre_bit_error.stat[0].scale = FE_SCALE_COUNTER; + c->pre_bit_error.stat[0].uvalue += bit_error; + c->pre_bit_count.stat[0].scale = FE_SCALE_COUNTER; + c->pre_bit_count.stat[0].uvalue += rc; + + return 0; + } + +If the driver doesn't provide a statistics available check bit +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +A few devices, however, may not provide a way to check if the stats are +available (or the way to check it is unknown). They may not even provide +a way to directly read the total number of bits or blocks. + +On those devices, the driver need to ensure that it won't be reading from +the register too often and/or estimate the total number of bits/blocks. + +On such drivers, a typical routine to get statistics would be like +(adapted from dib8000 driver's logic):: + + struct foo_state { + /* ... */ + + unsigned long per_jiffies_stats; + } + + static int foo_get_pre_ber(struct dvb_frontend *fe) + { + struct foo_state *state = fe->demodulator_priv; + struct dtv_frontend_properties *c = &fe->dtv_property_cache; + int rc, bit_error; + u64 bits; + + /* Check if time for stats was elapsed */ + if (!time_after(jiffies, state->per_jiffies_stats)) + return 0; + + /* Next stat should be collected in 1000 ms */ + state->per_jiffies_stats = jiffies + msecs_to_jiffies(1000); + + /* Read Bit Error Count */ + bit_error = foo_read_u32(state, 0x55); + if (bit_error < 0) + return bit_error; + + /* + * On this particular frontend, there's no register that + * would provide the number of bits per 1000ms sample. So, + * some function would calculate it based on DTV properties + */ + bits = get_number_of_bits_per_1000ms(fe); + + c->pre_bit_error.stat[0].scale = FE_SCALE_COUNTER; + c->pre_bit_error.stat[0].uvalue += bit_error; + c->pre_bit_count.stat[0].scale = FE_SCALE_COUNTER; + c->pre_bit_count.stat[0].uvalue += bits; + + return 0; + } + +Please notice that, on both cases, we're getting the statistics using the +:c:type:`dvb_frontend_ops` ``.read_status`` callback. The rationale is that +the frontend core will automatically call this function periodically +(usually, 3 times per second, when the frontend is locked). + +That warrants that we won't miss to collect a counter and increment the +monotonic stats at the right time. + +Digital TV Frontend functions and types +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/media/dvb-core/dvb_frontend.h -- cgit v1.2.3 From b2fc98fc91647e4b7ec1ac90001729345ec3e790 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 11 Oct 2017 13:06:30 -0400 Subject: media: dtv-frontend.rst fix a typo: algoritms -> algorithms WARNING: 'algoritms' may be misspelled - perhaps 'algorithms'? +responsible for tuning the device. It supports multiple algoritms to Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/dtv-frontend.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/media/kapi/dtv-frontend.rst b/Documentation/media/kapi/dtv-frontend.rst index 9f67b7a7387d..f1a2fdaab5ba 100644 --- a/Documentation/media/kapi/dtv-frontend.rst +++ b/Documentation/media/kapi/dtv-frontend.rst @@ -119,7 +119,7 @@ Satellite TV reception is:: .. |delta| unicode:: U+00394 The ``drivers/media/dvb-core/dvb_frontend.c`` has a kernel thread with is -responsible for tuning the device. It supports multiple algoritms to +responsible for tuning the device. It supports multiple algorithms to detect a channel, as defined at enum :c:func:`dvbfe_algo`. The algorithm to be used is obtained via ``.get_frontend_algo``. If the driver -- cgit v1.2.3 From 1607b8b574c9318ea58f3f08cf85514ceddf467a Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 19 Sep 2017 17:05:14 -0400 Subject: media: dtv-demux.rst: minor markup improvements Add a cross-reference to a mentioned structure and split the kernel-doc stuff on a separate chapter. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/dtv-demux.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/media/kapi/dtv-demux.rst b/Documentation/media/kapi/dtv-demux.rst index 8169c479156e..3ee69266e206 100644 --- a/Documentation/media/kapi/dtv-demux.rst +++ b/Documentation/media/kapi/dtv-demux.rst @@ -7,8 +7,8 @@ Digital TV Demux The Kernel Digital TV Demux kABI defines a driver-internal interface for registering low-level, hardware specific driver to a hardware independent demux layer. It is only of interest for Digital TV device driver writers. -The header file for this kABI is named demux.h and located in -drivers/media/dvb-core. +The header file for this kABI is named ``demux.h`` and located in +``drivers/media/dvb-core``. The demux kABI should be implemented for each demux in the system. It is used to select the TS source of a demux and to manage the demux resources. @@ -27,7 +27,7 @@ tuning, are devined via the Digital TV Frontend kABI. The functions that implement the abstract interface demux should be defined static or module private and registered to the Demux core for external access. It is not necessary to implement every function in the struct -&dmx_demux. For example, a demux interface might support Section filtering, +:c:type:`dmx_demux`. For example, a demux interface might support Section filtering, but not PES filtering. The kABI client is expected to check the value of any function pointer before calling the function: the value of ``NULL`` means that the function is not available. @@ -43,8 +43,6 @@ Linux Kernel calls the functions of a network device interface from a bottom half context. Thus, if a demux kABI function is called from network device code, the function must not sleep. - - Demux Callback API ~~~~~~~~~~~~~~~~~~ @@ -68,4 +66,7 @@ function call directly from a hardware interrupt. This mechanism is implemented by :c:func:`dmx_ts_cb()` and :c:func:`dmx_section_cb()` callbacks. +Digital TV Demux functions and types +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + .. kernel-doc:: drivers/media/dvb-core/demux.h -- cgit v1.2.3 From 8c6b18631ff6a4823249becb51b428da5f0f9a40 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 19 Sep 2017 19:03:14 -0400 Subject: media: dtv-demux.rst: parse other demux headers with kernel-doc Now that we have kernel-doc markups at dvb_demux.h and dmxdev.h, parse them. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/dtv-demux.rst | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/media/kapi/dtv-demux.rst b/Documentation/media/kapi/dtv-demux.rst index 3ee69266e206..7aa865a2b43f 100644 --- a/Documentation/media/kapi/dtv-demux.rst +++ b/Documentation/media/kapi/dtv-demux.rst @@ -66,7 +66,17 @@ function call directly from a hardware interrupt. This mechanism is implemented by :c:func:`dmx_ts_cb()` and :c:func:`dmx_section_cb()` callbacks. -Digital TV Demux functions and types -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Digital TV Demux device registration functions and data structures +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/media/dvb-core/dmxdev.h + +High-level Digital TV demux interface +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/media/dvb-core/dvb_demux.h + +Driver-internal low-level hardware specific driver demux interface +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. kernel-doc:: drivers/media/dvb-core/demux.h -- cgit v1.2.3 From b5b03a200934cad3c77e85026a3549847234f74e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 20 Sep 2017 13:51:06 -0400 Subject: media: dvb-net.rst: document DVB network kAPI interface That's the last DVB kAPI that misses documentation. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/dtv-core.rst | 1 + Documentation/media/kapi/dtv-net.rst | 4 ++++ Documentation/media/uapi/dvb/net-types.rst | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) create mode 100644 Documentation/media/kapi/dtv-net.rst (limited to 'Documentation') diff --git a/Documentation/media/kapi/dtv-core.rst b/Documentation/media/kapi/dtv-core.rst index 8ee384f61fa0..bca743dc6b43 100644 --- a/Documentation/media/kapi/dtv-core.rst +++ b/Documentation/media/kapi/dtv-core.rst @@ -34,3 +34,4 @@ I2C bus. dtv-frontend dtv-demux dtv-ca + dtv-net diff --git a/Documentation/media/kapi/dtv-net.rst b/Documentation/media/kapi/dtv-net.rst new file mode 100644 index 000000000000..ced991b73d69 --- /dev/null +++ b/Documentation/media/kapi/dtv-net.rst @@ -0,0 +1,4 @@ +Digital TV Network kABI +----------------------- + +.. kernel-doc:: drivers/media/dvb-core/dvb_net.h diff --git a/Documentation/media/uapi/dvb/net-types.rst b/Documentation/media/uapi/dvb/net-types.rst index e1177bdcd623..8fa3292eaa42 100644 --- a/Documentation/media/uapi/dvb/net-types.rst +++ b/Documentation/media/uapi/dvb/net-types.rst @@ -1,6 +1,6 @@ .. -*- coding: utf-8; mode: rst -*- -.. _dmx_types: +.. _net_types: ************** Net Data Types -- cgit v1.2.3 From b33494e950c6d492c65799252cb8bc2692468221 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 20 Sep 2017 14:42:42 -0400 Subject: media: dvb uAPI docs: get rid of examples section That section is too outdated and got superseded by DVBv5 and by libdvbv5. Maybe some day we'll end adding updated examples there, but while nobody has time or interest of doing that, just mention that there and get rid of the current examples for good. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/examples.rst | 378 +----------------------------- 1 file changed, 6 insertions(+), 372 deletions(-) (limited to 'Documentation') diff --git a/Documentation/media/uapi/dvb/examples.rst b/Documentation/media/uapi/dvb/examples.rst index e0f627ca2e4d..16dd90fa9e94 100644 --- a/Documentation/media/uapi/dvb/examples.rst +++ b/Documentation/media/uapi/dvb/examples.rst @@ -6,377 +6,11 @@ Examples ******** -In this section we would like to present some examples for using the Digital -TV API. +In the past, we used to have a set of examples here. However, those +examples got out of date and doesn't even compile nowadays. -.. note:: +Also, nowadays, the best is to use the libdvbv5 DVB API nowadays, +with is fully documented. - This section is out of date, and the code below won't even - compile. Please refer to the - `libdvbv5 `__ for - updated/recommended examples. - - -.. _tuning: - -Example: Tuning -=============== - -We will start with a generic tuning subroutine that uses the frontend -and SEC, as well as the demux devices. The example is given for QPSK -tuners, but can easily be adjusted for QAM. - - -.. code-block:: c - - #include - #include - #include - #include - #include - #include - #include - #include - - #include - #include - #include - #include - - #define DMX "/dev/dvb/adapter0/demux1" - #define FRONT "/dev/dvb/adapter0/frontend1" - #define SEC "/dev/dvb/adapter0/sec1" - - /* routine for checking if we have a signal and other status information*/ - int FEReadStatus(int fd, fe_status_t *stat) - { - int ans; - - if ( (ans = ioctl(fd,FE_READ_STATUS,stat) < 0)){ - perror("FE READ STATUS: "); - return -1; - } - - if (*stat & FE_HAS_POWER) - printf("FE HAS POWER\\n"); - - if (*stat & FE_HAS_SIGNAL) - printf("FE HAS SIGNAL\\n"); - - if (*stat & FE_SPECTRUM_INV) - printf("SPEKTRUM INV\\n"); - - return 0; - } - - - /* tune qpsk */ - /* freq: frequency of transponder */ - /* vpid, apid, tpid: PIDs of video, audio and teletext TS packets */ - /* diseqc: DiSEqC address of the used LNB */ - /* pol: Polarisation */ - /* srate: Symbol Rate */ - /* fec. FEC */ - /* lnb_lof1: local frequency of lower LNB band */ - /* lnb_lof2: local frequency of upper LNB band */ - /* lnb_slof: switch frequency of LNB */ - - int set_qpsk_channel(int freq, int vpid, int apid, int tpid, - int diseqc, int pol, int srate, int fec, int lnb_lof1, - int lnb_lof2, int lnb_slof) - { - struct secCommand scmd; - struct secCmdSequence scmds; - struct dmx_pes_filter_params pesFilterParams; - FrontendParameters frp; - struct pollfd pfd[1]; - FrontendEvent event; - int demux1, demux2, demux3, front; - - frequency = (uint32_t) freq; - symbolrate = (uint32_t) srate; - - if((front = open(FRONT,O_RDWR)) < 0){ - perror("FRONTEND DEVICE: "); - return -1; - } - - if((sec = open(SEC,O_RDWR)) < 0){ - perror("SEC DEVICE: "); - return -1; - } - - if (demux1 < 0){ - if ((demux1=open(DMX, O_RDWR|O_NONBLOCK)) - < 0){ - perror("DEMUX DEVICE: "); - return -1; - } - } - - if (demux2 < 0){ - if ((demux2=open(DMX, O_RDWR|O_NONBLOCK)) - < 0){ - perror("DEMUX DEVICE: "); - return -1; - } - } - - if (demux3 < 0){ - if ((demux3=open(DMX, O_RDWR|O_NONBLOCK)) - < 0){ - perror("DEMUX DEVICE: "); - return -1; - } - } - - if (freq < lnb_slof) { - frp.Frequency = (freq - lnb_lof1); - scmds.continuousTone = SEC_TONE_OFF; - } else { - frp.Frequency = (freq - lnb_lof2); - scmds.continuousTone = SEC_TONE_ON; - } - frp.Inversion = INVERSION_AUTO; - if (pol) scmds.voltage = SEC_VOLTAGE_18; - else scmds.voltage = SEC_VOLTAGE_13; - - scmd.type=0; - scmd.u.diseqc.addr=0x10; - scmd.u.diseqc.cmd=0x38; - scmd.u.diseqc.numParams=1; - scmd.u.diseqc.params[0] = 0xF0 | ((diseqc * 4) & 0x0F) | - (scmds.continuousTone == SEC_TONE_ON ? 1 : 0) | - (scmds.voltage==SEC_VOLTAGE_18 ? 2 : 0); - - scmds.miniCommand=SEC_MINI_NONE; - scmds.numCommands=1; - scmds.commands=&scmd; - if (ioctl(sec, SEC_SEND_SEQUENCE, &scmds) < 0){ - perror("SEC SEND: "); - return -1; - } - - if (ioctl(sec, SEC_SEND_SEQUENCE, &scmds) < 0){ - perror("SEC SEND: "); - return -1; - } - - frp.u.qpsk.SymbolRate = srate; - frp.u.qpsk.FEC_inner = fec; - - if (ioctl(front, FE_SET_FRONTEND, &frp) < 0){ - perror("QPSK TUNE: "); - return -1; - } - - pfd[0].fd = front; - pfd[0].events = POLLIN; - - if (poll(pfd,1,3000)){ - if (pfd[0].revents & POLLIN){ - printf("Getting QPSK event\\n"); - if ( ioctl(front, FE_GET_EVENT, &event) - - == -EOVERFLOW){ - perror("qpsk get event"); - return -1; - } - printf("Received "); - switch(event.type){ - case FE_UNEXPECTED_EV: - printf("unexpected event\\n"); - return -1; - case FE_FAILURE_EV: - printf("failure event\\n"); - return -1; - - case FE_COMPLETION_EV: - printf("completion event\\n"); - } - } - } - - - pesFilterParams.pid = vpid; - pesFilterParams.input = DMX_IN_FRONTEND; - pesFilterParams.output = DMX_OUT_DECODER; - pesFilterParams.pes_type = DMX_PES_VIDEO; - pesFilterParams.flags = DMX_IMMEDIATE_START; - if (ioctl(demux1, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ - perror("set_vpid"); - return -1; - } - - pesFilterParams.pid = apid; - pesFilterParams.input = DMX_IN_FRONTEND; - pesFilterParams.output = DMX_OUT_DECODER; - pesFilterParams.pes_type = DMX_PES_AUDIO; - pesFilterParams.flags = DMX_IMMEDIATE_START; - if (ioctl(demux2, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ - perror("set_apid"); - return -1; - } - - pesFilterParams.pid = tpid; - pesFilterParams.input = DMX_IN_FRONTEND; - pesFilterParams.output = DMX_OUT_DECODER; - pesFilterParams.pes_type = DMX_PES_TELETEXT; - pesFilterParams.flags = DMX_IMMEDIATE_START; - if (ioctl(demux3, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ - perror("set_tpid"); - return -1; - } - - return has_signal(fds); - } - -The program assumes that you are using a universal LNB and a standard -DiSEqC switch with up to 4 addresses. Of course, you could build in some -more checking if tuning was successful and maybe try to repeat the -tuning process. Depending on the external hardware, i.e. LNB and DiSEqC -switch, and weather conditions this may be necessary. - - -.. _the_dvr_device: - -Example: The DVR device -======================== - -The following program code shows how to use the DVR device for -recording. - - -.. code-block:: c - - #include - #include - #include - #include - #include - #include - #include - #include - - #include - #include - #include - #define DVR "/dev/dvb/adapter0/dvr1" - #define AUDIO "/dev/dvb/adapter0/audio1" - #define VIDEO "/dev/dvb/adapter0/video1" - - #define BUFFY (188*20) - #define MAX_LENGTH (1024*1024*5) /* record 5MB */ - - - /* switch the demuxes to recording, assuming the transponder is tuned */ - - /* demux1, demux2: file descriptor of video and audio filters */ - /* vpid, apid: PIDs of video and audio channels */ - - int switch_to_record(int demux1, int demux2, uint16_t vpid, uint16_t apid) - { - struct dmx_pes_filter_params pesFilterParams; - - if (demux1 < 0){ - if ((demux1=open(DMX, O_RDWR|O_NONBLOCK)) - < 0){ - perror("DEMUX DEVICE: "); - return -1; - } - } - - if (demux2 < 0){ - if ((demux2=open(DMX, O_RDWR|O_NONBLOCK)) - < 0){ - perror("DEMUX DEVICE: "); - return -1; - } - } - - pesFilterParams.pid = vpid; - pesFilterParams.input = DMX_IN_FRONTEND; - pesFilterParams.output = DMX_OUT_TS_TAP; - pesFilterParams.pes_type = DMX_PES_VIDEO; - pesFilterParams.flags = DMX_IMMEDIATE_START; - if (ioctl(demux1, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ - perror("DEMUX DEVICE"); - return -1; - } - pesFilterParams.pid = apid; - pesFilterParams.input = DMX_IN_FRONTEND; - pesFilterParams.output = DMX_OUT_TS_TAP; - pesFilterParams.pes_type = DMX_PES_AUDIO; - pesFilterParams.flags = DMX_IMMEDIATE_START; - if (ioctl(demux2, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ - perror("DEMUX DEVICE"); - return -1; - } - return 0; - } - - /* start recording MAX_LENGTH , assuming the transponder is tuned */ - - /* demux1, demux2: file descriptor of video and audio filters */ - /* vpid, apid: PIDs of video and audio channels */ - int record_dvr(int demux1, int demux2, uint16_t vpid, uint16_t apid) - { - int i; - int len; - int written; - uint8_t buf[BUFFY]; - uint64_t length; - struct pollfd pfd[1]; - int dvr, dvr_out; - - /* open dvr device */ - if ((dvr = open(DVR, O_RDONLY|O_NONBLOCK)) < 0){ - perror("DVR DEVICE"); - return -1; - } - - /* switch video and audio demuxes to dvr */ - printf ("Switching dvr on\\n"); - i = switch_to_record(demux1, demux2, vpid, apid); - printf("finished: "); - - printf("Recording %2.0f MB of test file in TS format\\n", - MAX_LENGTH/(1024.0*1024.0)); - length = 0; - - /* open output file */ - if ((dvr_out = open(DVR_FILE,O_WRONLY|O_CREAT - |O_TRUNC, S_IRUSR|S_IWUSR - |S_IRGRP|S_IWGRP|S_IROTH| - S_IWOTH)) < 0){ - perror("Can't open file for dvr test"); - return -1; - } - - pfd[0].fd = dvr; - pfd[0].events = POLLIN; - - /* poll for dvr data and write to file */ - while (length < MAX_LENGTH ) { - if (poll(pfd,1,1)){ - if (pfd[0].revents & POLLIN){ - len = read(dvr, buf, BUFFY); - if (len < 0){ - perror("recording"); - return -1; - } - if (len > 0){ - written = 0; - while (written < len) - written += - write (dvr_out, - buf, len); - length += len; - printf("written %2.0f MB\\r", - length/1024./1024.); - } - } - } - } - return 0; - } +Please refer to the `libdvbv5 `__ +for updated/recommended examples. -- cgit v1.2.3 From 9cb072482e1de25db0888899fccd88dc63cea0ab Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 10 Oct 2017 17:16:26 -0700 Subject: scsi: fix doc. typo for I2O Fix typo: I20 should be I2O. Signed-off-by: Randy Dunlap Signed-off-by: Martin K. Petersen --- Documentation/driver-api/scsi.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/scsi.rst b/Documentation/driver-api/scsi.rst index 5a2aa7a377d9..9ae03171daca 100644 --- a/Documentation/driver-api/scsi.rst +++ b/Documentation/driver-api/scsi.rst @@ -28,7 +28,7 @@ SCSI commands can be transported over just about any kind of bus, and are the default protocol for storage devices attached to USB, SATA, SAS, Fibre Channel, FireWire, and ATAPI devices. SCSI packets are also commonly exchanged over Infiniband, -`I20 `__, TCP/IP +`I2O `__, TCP/IP (`iSCSI `__), even `Parallel ports `__. -- cgit v1.2.3 From 68ace22edb932836d59a5834df85f519c5ce4e4d Mon Sep 17 00:00:00 2001 From: Hou Zhiqiang Date: Tue, 19 Sep 2017 17:26:54 +0800 Subject: irqchip/ls-scfg-msi: Add LS1012a MSI support The ls1012a implements only 1 MSI controller, and it is the same as ls1043a. Signed-off-by: Hou Zhiqiang Signed-off-by: Bjorn Helgaas Acked-by: Rob Herring Acked-by: Minghuan Lian Acked-by: Thomas Gleixner --- .../devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt index 49ccabbfa6f3..a4ff93d6b7f3 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt @@ -8,6 +8,7 @@ Required properties: "fsl,ls1043a-msi" "fsl,ls1046a-msi" "fsl,ls1043a-v1.1-msi" + "fsl,ls1012a-msi" - msi-controller: indicates that this is a PCIe MSI controller node - reg: physical base address of the controller and length of memory mapped. - interrupts: an interrupt to the parent interrupt controller. -- cgit v1.2.3 From 1548a21458bf7c5fc541c0785aa886602b27d5f5 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Wed, 11 Oct 2017 13:02:25 +0200 Subject: ARM: dts: qcom: Add initial DTS file for Fairphone 2 phone This DTS has support for the Fairphone 2 (codenamed FP2). This first version of the DTS supports just the serial console via the MSM UART pins. Signed-off-by: Luca Weiss Acked-by: Bjorn Andersson Signed-off-by: Andy Gross --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1ea1fd4232ab..f6d148f5c5f0 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -113,6 +113,7 @@ everspin Everspin Technologies, Inc. exar Exar Corporation excito Excito ezchip EZchip Semiconductor +fairphone Fairphone B.V. faraday Faraday Technology Corporation fcs Fairchild Semiconductor firefly Firefly -- cgit v1.2.3 From b8b74dda3908660f49a5d5cec28725e3950e00d5 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Tue, 3 Oct 2017 17:24:43 +0200 Subject: ARM64: dts: meson-gxm: Add support for Khadas VIM2 The Khadas VIM2 is a Single Board Computer, respin of the origin Khadas VIM board, using an Amlogic S912 SoC and more server oriented. It provides the same external connectors and header pinout, plus a SPI NOR Flash, a reprogrammable STM8S003 MCU, FPC Connector, Cooling FAN header and Pogo Pads Arrays. Cc: Gouwa Acked-by: Martin Blumenstingl Acked-by: Rob Herring Signed-off-by: Neil Armstrong Tested-by: Jerome Brunet Signed-off-by: Kevin Hilman --- Documentation/devicetree/bindings/arm/amlogic.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt index 4e4bc0bae597..a44599739746 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.txt +++ b/Documentation/devicetree/bindings/arm/amlogic.txt @@ -71,6 +71,7 @@ Board compatible values (alphabetically, grouped by SoC): - "amlogic,q200" (Meson gxm s912) - "amlogic,q201" (Meson gxm s912) + - "khadas,vim2" (Meson gxm s912) - "kingnovel,r-box-pro" (Meson gxm S912) - "nexbox,a1" (Meson gxm s912) -- cgit v1.2.3 From abe8bbd308c5f2864c1bc066a0e60ec59a0ae450 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Tue, 3 Oct 2017 17:29:45 +0200 Subject: dt-bindings: arm: amlogic: Add Tronsmart Vega S96 binding Cc: support@tronsmart.com Acked-by: Jerome Brunet Signed-off-by: Oleg Ivanov Signed-off-by: Neil Armstrong Acked-by: Rob Herring Signed-off-by: Kevin Hilman --- Documentation/devicetree/bindings/arm/amlogic.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt index a44599739746..da379880abb6 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.txt +++ b/Documentation/devicetree/bindings/arm/amlogic.txt @@ -74,6 +74,7 @@ Board compatible values (alphabetically, grouped by SoC): - "khadas,vim2" (Meson gxm s912) - "kingnovel,r-box-pro" (Meson gxm S912) - "nexbox,a1" (Meson gxm s912) + - "tronsmart,vega-s96" (Meson gxm s912) Amlogic Meson Firmware registers Interface ------------------------------------------ -- cgit v1.2.3 From 8c1b7dc9ba2294c6dbd1870a3d2e534bfda3047a Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Mon, 14 Aug 2017 15:46:18 -0700 Subject: firmware: qcom: scm: Expose download-mode control In order to aid post-mortem debugging the Qualcomm platforms provide a "memory download mode", where the boot loader will provide an interface for custom tools to "download" the content of RAM to a host machine. The mode is triggered by writing a magic value somewhere in RAM, that is read in the boot code path after a warm-restart. Two mechanism for setting this magic value are supported in modern platforms; a direct SCM call to enable the mode or through a secure io write of a magic value. In order for a normal reboot not to trigger "download mode" the magic must be cleared during a clean reboot. Download mode has to be enabled by including qcom_scm.download_mode=1 on the command line. Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Signed-off-by: Andy Gross --- Documentation/devicetree/bindings/firmware/qcom,scm.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index 20f26fbce875..7b40054be0d8 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -18,6 +18,8 @@ Required properties: * Core, iface, and bus clocks required for "qcom,scm" - clock-names: Must contain "core" for the core clock, "iface" for the interface clock and "bus" for the bus clock per the requirements of the compatible. +- qcom,dload-mode: phandle to the TCSR hardware block and offset of the + download mode control register (optional) Example for MSM8916: -- cgit v1.2.3 From 726b99c4f73c2e386c4ec5aa90d5124489573bd2 Mon Sep 17 00:00:00 2001 From: David Hildenbrand Date: Thu, 24 Aug 2017 20:51:35 +0200 Subject: KVM: x86: document special identity map address value MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Setting it to 0 leads to setting it to the default value, let's document this. Reviewed-by: Radim Krčmář Signed-off-by: David Hildenbrand Signed-off-by: Radim Krčmář --- Documentation/virtual/kvm/api.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index e63a35fafef0..22bc5a052a5d 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -1124,6 +1124,9 @@ guest physical address space and must not conflict with any memory slot or any mmio address. The guest may malfunction if it accesses this memory region. +Setting the address to 0 will result in resetting the address to its default +(0xfffbc000). + This ioctl is required on Intel-based hosts. This is needed on Intel hardware because of a quirk in the virtualization implementation (see the internals documentation when it pops into existence). -- cgit v1.2.3 From 1af1ac910bb3394ac1c0062f5781983dde40a8c0 Mon Sep 17 00:00:00 2001 From: David Hildenbrand Date: Thu, 24 Aug 2017 20:51:36 +0200 Subject: KVM: x86: allow setting identity map addr with no vcpus only MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Changing it afterwards doesn't make too much sense and will only result in inconsistencies. Reviewed-by: Radim Krčmář Signed-off-by: David Hildenbrand Signed-off-by: Radim Krčmář --- Documentation/virtual/kvm/api.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 22bc5a052a5d..dd2dd96927b8 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -1131,6 +1131,7 @@ This ioctl is required on Intel-based hosts. This is needed on Intel hardware because of a quirk in the virtualization implementation (see the internals documentation when it pops into existence). +Fails if any VCPU has already been created. 4.41 KVM_SET_BOOT_CPU_ID -- cgit v1.2.3 From a335b122ba277c879d224b41e52fcfdf334266b0 Mon Sep 17 00:00:00 2001 From: Hou Zhiqiang Date: Tue, 19 Sep 2017 17:26:56 +0800 Subject: PCI: layerscape: Add support for ls1012a Add support for ls1012a. Signed-off-by: Hou Zhiqiang Signed-off-by: Bjorn Helgaas Acked-by: Rob Herring Acked-by: Minghuan Lian Acked-by: Thomas Gleixner --- Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index c0484da0f20d..66df1e81e0b8 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -18,6 +18,7 @@ Required properties: "fsl,ls2088a-pcie" "fsl,ls1088a-pcie" "fsl,ls1046a-pcie" + "fsl,ls1012a-pcie" - reg: base addresses and lengths of the PCIe controller register blocks. - interrupts: A list of interrupt outputs of the controller. Must contain an entry for each entry in the interrupt-names property. -- cgit v1.2.3 From d5cdbb875f5c450bf9ee950008a2865343c1775c Mon Sep 17 00:00:00 2001 From: Shuah Khan Date: Mon, 2 Oct 2017 17:44:17 -0600 Subject: doc: dev-tools: kselftest.rst: update to include make O=dir support Update to include details on make O=dir support and other changes improve test results output. Signed-off-by: Shuah Khan [jc: Tweaked RST formatting slightly ] Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/kselftest.rst | 34 ++++++++++++++++++++++++++++++++-- 1 file changed, 32 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index ebd03d11d2c2..e80850eefe13 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst @@ -31,6 +31,17 @@ To build and run the tests with a single command, use:: Note that some tests will require root privileges. +Build and run from user specific object directory (make O=dir):: + + $ make O=/tmp/kselftest kselftest + +Build and run KBUILD_OUTPUT directory (make KBUILD_OUTPUT=):: + + $ make KBUILD_OUTPUT=/tmp/kselftest kselftest + +The above commands run the tests and print pass/fail summary to make it +easier to understand the test results. Please find the detailed individual +test results for each test in /tmp/testname file(s). Running a subset of selftests ============================= @@ -46,10 +57,21 @@ You can specify multiple tests to build and run:: $ make TARGETS="size timers" kselftest +Build and run from user specific object directory (make O=dir):: + + $ make O=/tmp/kselftest TARGETS="size timers" kselftest + +Build and run KBUILD_OUTPUT directory (make KBUILD_OUTPUT=):: + + $ make KBUILD_OUTPUT=/tmp/kselftest TARGETS="size timers" kselftest + +The above commands run the tests and print pass/fail summary to make it +easier to understand the test results. Please find the detailed individual +test results for each test in /tmp/testname file(s). + See the top-level tools/testing/selftests/Makefile for the list of all possible targets. - Running the full range hotplug selftests ======================================== @@ -113,9 +135,17 @@ Contributing new tests (details) * Use TEST_GEN_XXX if such binaries or files are generated during compiling. - TEST_PROGS, TEST_GEN_PROGS mean it is the excutable tested by + TEST_PROGS, TEST_GEN_PROGS mean it is the executable tested by default. + TEST_CUSTOM_PROGS should be used by tests that require custom build + rule and prevent common build rule use. + + TEST_PROGS are for test shell scripts. Please ensure shell script has + its exec bit set. Otherwise, lib.mk run_tests will generate a warning. + + TEST_CUSTOM_PROGS and TEST_PROGS will be run by common run_tests. + TEST_PROGS_EXTENDED, TEST_GEN_PROGS_EXTENDED mean it is the executable which is not tested by default. TEST_FILES, TEST_GEN_FILES mean it is the file which is used by -- cgit v1.2.3 From 9effc8f70b87cf0c02a2ce264257c34a5fe885d5 Mon Sep 17 00:00:00 2001 From: Shuah Khan Date: Mon, 2 Oct 2017 17:44:18 -0600 Subject: doc: enhance dochelp include default output location for doc build Enhance documentation help message to specify the default location for the generated documents. Signed-off-by: Shuah Khan Signed-off-by: Jonathan Corbet --- Documentation/Makefile | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/Makefile b/Documentation/Makefile index 85f7856f0092..5e65fa5c6ab7 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -116,3 +116,5 @@ dochelp: @echo @echo ' make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build' @echo ' configuration. This is e.g. useful to build with nit-picking config.' + @echo + @echo ' Default location for the generated documents is Documentation/output' -- cgit v1.2.3 From e8939222dced668fc5cae02b0b601af069801107 Mon Sep 17 00:00:00 2001 From: Jani Nikula Date: Mon, 9 Oct 2017 18:26:15 +0300 Subject: Documentation: add script and build target to check for broken file references Add a simple script and build target to do a treewide grep for references to files under Documentation, and report the non-existing file in stderr. It tries to take into account punctuation not part of the filename, and wildcards, but there are bound to be false positives too. Mostly seems accurate though. We've moved files around enough to make having this worthwhile. Signed-off-by: Jani Nikula Signed-off-by: Jonathan Corbet --- Documentation/Makefile | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/Makefile b/Documentation/Makefile index 5e65fa5c6ab7..2ca77ad0f238 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -97,6 +97,9 @@ endif # HAVE_SPHINX # The following targets are independent of HAVE_SPHINX, and the rules should # work or silently pass without Sphinx. +refcheckdocs: + $(Q)cd $(srctree);scripts/documentation-file-ref-check + cleandocs: $(Q)rm -rf $(BUILDDIR) $(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media clean @@ -109,6 +112,7 @@ dochelp: @echo ' epubdocs - EPUB' @echo ' xmldocs - XML' @echo ' linkcheckdocs - check for broken external links (will connect to external hosts)' + @echo ' refcheckdocs - check for references to non-existing files under Documentation' @echo ' cleandocs - clean all generated files' @echo @echo ' make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2' -- cgit v1.2.3 From 66ccc64f2c3b934f065811160be288cb9a2815ef Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Tue, 10 Oct 2017 12:36:09 -0500 Subject: Documentation: fix driver-api doc refs Make driver-api document refs valid. Signed-off-by: Tom Saeger Acked-by: Rafael J. Wysocki Signed-off-by: Jonathan Corbet --- Documentation/power/pci.txt | 10 +++++----- Documentation/power/runtime_pm.txt | 2 +- Documentation/process/submitting-drivers.rst | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt index a1b7f7158930..d17fdf8f45ef 100644 --- a/Documentation/power/pci.txt +++ b/Documentation/power/pci.txt @@ -8,7 +8,7 @@ management. Based on previous work by Patrick Mochel This document only covers the aspects of power management specific to PCI devices. For general description of the kernel's interfaces related to device -power management refer to Documentation/power/admin-guide/devices.rst and +power management refer to Documentation/driver-api/pm/devices.rst and Documentation/power/runtime_pm.txt. --------------------------------------------------------------------------- @@ -417,7 +417,7 @@ pm->runtime_idle() callback. 2.4. System-Wide Power Transitions ---------------------------------- There are a few different types of system-wide power transitions, described in -Documentation/power/admin-guide/devices.rst. Each of them requires devices to be handled +Documentation/driver-api/pm/devices.rst. Each of them requires devices to be handled in a specific way and the PM core executes subsystem-level power management callbacks for this purpose. They are executed in phases such that each phase involves executing the same subsystem-level callback for every device belonging @@ -623,7 +623,7 @@ System restore requires a hibernation image to be loaded into memory and the pre-hibernation memory contents to be restored before the pre-hibernation system activity can be resumed. -As described in Documentation/power/admin-guide/devices.rst, the hibernation image is loaded +As described in Documentation/driver-api/pm/devices.rst, the hibernation image is loaded into memory by a fresh instance of the kernel, called the boot kernel, which in turn is loaded and run by a boot loader in the usual way. After the boot kernel has loaded the image, it needs to replace its own code and data with the code @@ -677,7 +677,7 @@ controlling the runtime power management of their devices. At the time of this writing there are two ways to define power management callbacks for a PCI device driver, the recommended one, based on using a -dev_pm_ops structure described in Documentation/power/admin-guide/devices.rst, and the +dev_pm_ops structure described in Documentation/driver-api/pm/devices.rst, and the "legacy" one, in which the .suspend(), .suspend_late(), .resume_early(), and .resume() callbacks from struct pci_driver are used. The legacy approach, however, doesn't allow one to define runtime power management callbacks and is @@ -1046,5 +1046,5 @@ PCI Local Bus Specification, Rev. 3.0 PCI Bus Power Management Interface Specification, Rev. 1.2 Advanced Configuration and Power Interface (ACPI) Specification, Rev. 3.0b PCI Express Base Specification, Rev. 2.0 -Documentation/power/admin-guide/devices.rst +Documentation/driver-api/pm/devices.rst Documentation/power/runtime_pm.txt diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 625549d4c74a..57af2f7963ee 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -680,7 +680,7 @@ left in runtime suspend. If that happens, the PM core will not execute any system suspend and resume callbacks for all of those devices, except for the complete callback, which is then entirely responsible for handling the device as appropriate. This only applies to system suspend transitions that are not -related to hibernation (see Documentation/power/admin-guide/devices.rst for more +related to hibernation (see Documentation/driver-api/pm/devices.rst for more information). The PM core does its best to reduce the probability of race conditions between diff --git a/Documentation/process/submitting-drivers.rst b/Documentation/process/submitting-drivers.rst index afb82ee0cbea..b38bf2054ce3 100644 --- a/Documentation/process/submitting-drivers.rst +++ b/Documentation/process/submitting-drivers.rst @@ -117,7 +117,7 @@ PM support: anything. For the driver testing instructions see Documentation/power/drivers-testing.txt and for a relatively complete overview of the power management issues related to - drivers see Documentation/power/admin-guide/devices.rst . + drivers see Documentation/driver-api/pm/devices.rst. Control: In general if there is active maintenance of a driver by -- cgit v1.2.3 From 3ba9b1b814fe37ba3267b58917a73dc69eebde40 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Tue, 10 Oct 2017 12:36:16 -0500 Subject: Documentation: fix admin-guide doc refs Make admin-guide document refs valid. Signed-off-by: Tom Saeger Acked-by: Rafael J. Wysocki Signed-off-by: Jonathan Corbet --- Documentation/ABI/stable/sysfs-devices | 2 +- Documentation/ABI/testing/sysfs-devices-system-cpu | 6 ++++-- Documentation/ABI/testing/sysfs-power | 6 ++++-- Documentation/admin-guide/README.rst | 2 +- Documentation/admin-guide/kernel-parameters.txt | 2 +- Documentation/admin-guide/reporting-bugs.rst | 4 ++-- Documentation/laptops/laptop-mode.txt | 6 +++--- Documentation/media/v4l-drivers/bttv.rst | 2 +- Documentation/power/interface.txt | 3 ++- 9 files changed, 19 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-devices b/Documentation/ABI/stable/sysfs-devices index 35c457f8ce73..4404bd9b96c1 100644 --- a/Documentation/ABI/stable/sysfs-devices +++ b/Documentation/ABI/stable/sysfs-devices @@ -1,5 +1,5 @@ # Note: This documents additional properties of any device beyond what -# is documented in Documentation/sysfs-rules.txt +# is documented in Documentation/admin-guide/sysfs-rules.rst What: /sys/devices/*/of_node Date: February 2015 diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index f3d5817c4ef0..d6d862db3b5d 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -187,7 +187,8 @@ Description: Processor frequency boosting control This switch controls the boost setting for the whole system. Boosting allows the CPU and the firmware to run at a frequency beyound it's nominal limit. - More details can be found in Documentation/cpu-freq/boost.txt + More details can be found in + Documentation/admin-guide/pm/cpufreq.rst What: /sys/devices/system/cpu/cpu#/crash_notes @@ -223,7 +224,8 @@ Description: Parameters for the Intel P-state driver no_turbo: limits the driver to selecting P states below the turbo frequency range. - More details can be found in Documentation/cpu-freq/intel-pstate.txt + More details can be found in + Documentation/admin-guide/pm/intel_pstate.rst What: /sys/devices/system/cpu/cpu*/cache/index*/ Date: July 2014(documented, existed before August 2008) diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index 713cab1d5f12..4b2e13e5f020 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -18,7 +18,8 @@ Description: Writing one of the above strings to this file causes the system to transition into the corresponding state, if available. - See Documentation/power/states.txt for more information. + See Documentation/admin-guide/pm/sleep-states.rst for more + information. What: /sys/power/mem_sleep Date: November 2016 @@ -35,7 +36,8 @@ Description: represented by it to be used on subsequent attempts to suspend the system. - See Documentation/power/states.txt for more information. + See Documentation/admin-guide/pm/sleep-states.rst for more + information. What: /sys/power/disk Date: September 2006 diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst index b5343c5aa224..63066db39910 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst @@ -350,7 +350,7 @@ If something goes wrong help debugging the problem. The text above the dump is also important: it tells something about why the kernel dumped code (in the above example, it's due to a bad kernel pointer). More information - on making sense of the dump is in Documentation/admin-guide/oops-tracing.rst + on making sense of the dump is in Documentation/admin-guide/bug-hunting.rst - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump as is, otherwise you will have to use the ``ksymoops`` program to make diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a3427399fd07..957b931cc84c 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3134,7 +3134,7 @@ plip= [PPT,NET] Parallel port network link Format: { parport | timid | 0 } - See also Documentation/parport.txt. + See also Documentation/admin-guide/parport.rst. pmtmr= [X86] Manual setup of pmtmr I/O Port. Override pmtimer IOPort with a hex value. diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst index 26b60b419652..4650edb8840a 100644 --- a/Documentation/admin-guide/reporting-bugs.rst +++ b/Documentation/admin-guide/reporting-bugs.rst @@ -94,7 +94,7 @@ step-by-step instructions for how a user can trigger the bug. If the failure includes an "OOPS:", take a picture of the screen, capture a netconsole trace, or type the message from your screen into the bug -report. Please read "Documentation/admin-guide/oops-tracing.rst" before posting your +report. Please read "Documentation/admin-guide/bug-hunting.rst" before posting your bug report. This explains what you should do with the "Oops" information to make it useful to the recipient. @@ -120,7 +120,7 @@ summary from [1.]>" for easy identification by the developers:: [4.2.] Kernel .config file: [5.] Most recent kernel version which did not have the bug: [6.] Output of Oops.. message (if applicable) with symbolic information - resolved (see Documentation/admin-guide/oops-tracing.rst) + resolved (see Documentation/admin-guide/bug-hunting.rst) [7.] A small shell script or example program which triggers the problem (if possible) [8.] Environment diff --git a/Documentation/laptops/laptop-mode.txt b/Documentation/laptops/laptop-mode.txt index 19276f5d195c..1c707fc9b141 100644 --- a/Documentation/laptops/laptop-mode.txt +++ b/Documentation/laptops/laptop-mode.txt @@ -184,7 +184,7 @@ is done when dirty_ratio is reached. DO_CPU: Enable CPU frequency scaling when in laptop mode. (Requires CPUFreq to be setup. -See Documentation/cpu-freq/user-guide.txt for more info. Disabled by default.) +See Documentation/admin-guide/pm/cpufreq.rst for more info. Disabled by default.) CPU_MAXFREQ: @@ -287,7 +287,7 @@ MINIMUM_BATTERY_MINUTES=10 # Should the maximum CPU frequency be adjusted down while on battery? # Requires CPUFreq to be setup. -# See Documentation/cpu-freq/user-guide.txt for more info +# See Documentation/admin-guide/pm/cpufreq.rst for more info #DO_CPU=0 # When on battery what is the maximum CPU speed that the system should @@ -378,7 +378,7 @@ BATT_HD=${BATT_HD:-'4'} DIRTY_RATIO=${DIRTY_RATIO:-'40'} # cpu frequency scaling -# See Documentation/cpu-freq/user-guide.txt for more info +# See Documentation/admin-guide/pm/cpufreq.rst for more info DO_CPU=${CPU_MANAGE:-'0'} CPU_MAXFREQ=${CPU_MAXFREQ:-'slowest'} diff --git a/Documentation/media/v4l-drivers/bttv.rst b/Documentation/media/v4l-drivers/bttv.rst index 195ccaac2816..5f35e2fb5afa 100644 --- a/Documentation/media/v4l-drivers/bttv.rst +++ b/Documentation/media/v4l-drivers/bttv.rst @@ -307,7 +307,7 @@ console and let some terminal application log the messages. /me uses screen. See Documentation/admin-guide/serial-console.rst for details on setting up a serial console. -Read Documentation/admin-guide/oops-tracing.rst to learn how to get any useful +Read Documentation/admin-guide/bug-hunting.rst to learn how to get any useful information out of a register+stack dump printed by the kernel on protection faults (so-called "kernel oops"). diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt index 974916ff6608..7dc75f48e8bd 100644 --- a/Documentation/power/interface.txt +++ b/Documentation/power/interface.txt @@ -24,7 +24,8 @@ platform. If one of the strings listed in /sys/power/state is written to it, the system will attempt to transition into the corresponding sleep state. Refer to -Documentation/power/states.txt for a description of each of those states. +Documentation/admin-guide/pm/sleep-states.rst for a description of each of +those states. /sys/power/disk controls the operating mode of hibernation (Suspend-to-Disk). Specifically, it tells the kernel what to do after creating a hibernation image. -- cgit v1.2.3 From 1752118d48e7627756acf7fb8c13541305078fed Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Tue, 10 Oct 2017 12:36:23 -0500 Subject: Documentation: fix input related doc refs Make `input` document refs valid including: - joystick - joystick-parport Signed-off-by: Tom Saeger Reviewed-by: Takashi Iwai Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 10 +++++----- Documentation/hid/hiddev.txt | 2 +- Documentation/input/devices/xpad.rst | 3 ++- Documentation/sound/cards/joystick.rst | 2 +- 4 files changed, 9 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 957b931cc84c..f478f2402af1 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -314,7 +314,7 @@ amijoy.map= [HW,JOY] Amiga joystick support Map of devices attached to JOY0DAT and JOY1DAT Format: , - See also Documentation/input/joystick.txt + See also Documentation/input/joydev/joystick.rst analog.map= [HW,JOY] Analog joystick and gamepad support Specifies type or capabilities of an analog joystick @@ -724,7 +724,7 @@ db9.dev[2|3]= [HW,JOY] Multisystem joystick support via parallel port (one device per port) Format: , - See also Documentation/input/joystick-parport.txt + See also Documentation/input/devices/joystick-parport.rst ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot time. See @@ -1220,7 +1220,7 @@ [HW,JOY] Multisystem joystick and NES/SNES/PSX pad support via parallel port (up to 5 devices per port) Format: ,,,,, - See also Documentation/input/joystick-parport.txt + See also Documentation/input/devices/joystick-parport.rst gamma= [HW,DRM] @@ -1766,7 +1766,7 @@ ivrs_acpihid[00:14.5]=AMD0020:0 js= [HW,JOY] Analog joystick - See Documentation/input/joystick.txt. + See Documentation/input/joydev/joystick.rst. nokaslr [KNL] When CONFIG_RANDOMIZE_BASE is set, this disables @@ -4205,7 +4205,7 @@ TurboGraFX parallel port interface Format: ,,,,,,, - See also Documentation/input/joystick-parport.txt + See also Documentation/input/devices/joystick-parport.rst udbg-immortal [PPC] When debugging early kernel crashes that happen after console_init() and before a proper diff --git a/Documentation/hid/hiddev.txt b/Documentation/hid/hiddev.txt index 6e8c9f1d2f22..638448707aa2 100644 --- a/Documentation/hid/hiddev.txt +++ b/Documentation/hid/hiddev.txt @@ -12,7 +12,7 @@ To support these disparate requirements, the Linux USB system provides HID events to two separate interfaces: * the input subsystem, which converts HID events into normal input device interfaces (such as keyboard, mouse and joystick) and a -normalised event interface - see Documentation/input/input.txt +normalised event interface - see Documentation/input/input.rst * the hiddev interface, which provides fairly raw HID events The data flow for a HID event produced by a device is something like diff --git a/Documentation/input/devices/xpad.rst b/Documentation/input/devices/xpad.rst index 5a709ab77c8d..b8bd65962dd8 100644 --- a/Documentation/input/devices/xpad.rst +++ b/Documentation/input/devices/xpad.rst @@ -230,4 +230,5 @@ Historic Edits 2005-03-19 - Dominic Cerquetti - added stuff for dance pads, new d-pad->axes mappings -Later changes may be viewed with 'git log Documentation/input/xpad.txt' +Later changes may be viewed with +'git log --follow Documentation/input/devices/xpad.rst' diff --git a/Documentation/sound/cards/joystick.rst b/Documentation/sound/cards/joystick.rst index a6e468c81d02..488946fc1079 100644 --- a/Documentation/sound/cards/joystick.rst +++ b/Documentation/sound/cards/joystick.rst @@ -11,7 +11,7 @@ General First of all, you need to enable GAMEPORT support on Linux kernel for using a joystick with the ALSA driver. For the details of gameport -support, refer to Documentation/input/joystick.txt. +support, refer to Documentation/input/joydev/joystick.rst. The joystick support of ALSA drivers is different between ISA and PCI cards. In the case of ISA (PnP) cards, it's usually handled by the -- cgit v1.2.3 From c7f66400f504fd54bda6ec644853c07333e8cb87 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Tue, 10 Oct 2017 12:36:30 -0500 Subject: Documentation: fix security related doc refs Make security document refs valid. Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/ABI/testing/evm | 4 ++-- Documentation/security/LSM.rst | 2 +- Documentation/security/credentials.rst | 2 +- Documentation/security/keys/request-key.rst | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/evm b/Documentation/ABI/testing/evm index 8374d4557e5d..ca622c9aa24c 100644 --- a/Documentation/ABI/testing/evm +++ b/Documentation/ABI/testing/evm @@ -18,6 +18,6 @@ Description: in the initramfs, which has already been measured as part of the trusted boot. For more information on creating and loading existing trusted/encrypted keys, refer to: - Documentation/keys-trusted-encrypted.txt. (A sample dracut - patch, which loads the trusted/encrypted key and enables + Documentation/security/keys/trusted-encrypted.rst. (A sample + dracut patch, which loads the trusted/encrypted key and enables EVM, is available from http://linux-ima.sourceforge.net/#EVM.) diff --git a/Documentation/security/LSM.rst b/Documentation/security/LSM.rst index d75778b0fa10..98522e0e1ee2 100644 --- a/Documentation/security/LSM.rst +++ b/Documentation/security/LSM.rst @@ -5,7 +5,7 @@ Linux Security Module Development Based on https://lkml.org/lkml/2007/10/26/215, a new LSM is accepted into the kernel when its intent (a description of what it tries to protect against and in what cases one would expect to -use it) has been appropriately documented in ``Documentation/security/LSM``. +use it) has been appropriately documented in ``Documentation/security/LSM.rst``. This allows an LSM's code to be easily compared to its goals, and so that end users and distros can make a more informed decision about which LSMs suit their requirements. diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst index 038a7e19eff9..66a2e24939d8 100644 --- a/Documentation/security/credentials.rst +++ b/Documentation/security/credentials.rst @@ -196,7 +196,7 @@ The Linux kernel supports the following types of credentials: When a process accesses a key, if not already present, it will normally be cached on one of these keyrings for future accesses to find. - For more information on using keys, see Documentation/security/keys.txt. + For more information on using keys, see ``Documentation/security/keys/*``. 5. LSM diff --git a/Documentation/security/keys/request-key.rst b/Documentation/security/keys/request-key.rst index b2d16abaa9e9..21e27238cec6 100644 --- a/Documentation/security/keys/request-key.rst +++ b/Documentation/security/keys/request-key.rst @@ -3,7 +3,7 @@ Key Request Service =================== The key request service is part of the key retention service (refer to -Documentation/security/core.rst). This document explains more fully how +Documentation/security/keys/core.rst). This document explains more fully how the requesting algorithm works. The process starts by either the kernel requesting a service by calling -- cgit v1.2.3 From a405ed85ca170f5a6cc512a3ff492f77b5e63f15 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Tue, 10 Oct 2017 12:36:37 -0500 Subject: Documentation: fix media related doc refs Make media doc refs valid. Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 4 ++-- Documentation/media/dvb-drivers/bt8xx.rst | 8 ++++---- Documentation/media/uapi/v4l/dev-sliced-vbi.rst | 2 +- Documentation/media/uapi/v4l/extended-controls.rst | 2 +- Documentation/media/uapi/v4l/pixfmt-reserved.rst | 2 +- Documentation/media/v4l-drivers/max2175.rst | 2 +- 6 files changed, 10 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f478f2402af1..97a76eea7389 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -439,7 +439,7 @@ bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards) bttv.radio= Most important insmod options are available as kernel args too. - bttv.pll= See Documentation/video4linux/bttv/Insmod-options + bttv.pll= See Documentation/media/v4l-drivers/bttv.rst bttv.tuner= bulk_remove=off [PPC] This parameter disables the use of the pSeries @@ -2251,7 +2251,7 @@ See Documentation/admin-guide/pm/sleep-states.rst. meye.*= [HW] Set MotionEye Camera parameters - See Documentation/video4linux/meye.txt. + See Documentation/media/v4l-drivers/meye.rst. mfgpt_irq= [IA-32] Specify the IRQ to use for the Multi-Function General Purpose Timers on AMD Geode diff --git a/Documentation/media/dvb-drivers/bt8xx.rst b/Documentation/media/dvb-drivers/bt8xx.rst index b43958b7340c..e3e387bdf498 100644 --- a/Documentation/media/dvb-drivers/bt8xx.rst +++ b/Documentation/media/dvb-drivers/bt8xx.rst @@ -18,7 +18,7 @@ General information This class of cards has a bt878a as the PCI interface, and require the bttv driver for accessing the i2c bus and the gpio pins of the bt8xx chipset. -Please see Documentation/dvb/cards.txt => o Cards based on the Conexant Bt8xx PCI bridge: +Please see Documentation/media/dvb-drivers/cards.rst => o Cards based on the Conexant Bt8xx PCI bridge: Compiling kernel please enable: @@ -45,7 +45,7 @@ Loading Modules Regular case: If the bttv driver detects a bt8xx-based DVB card, all frontend and backend modules will be loaded automatically. Exceptions are: - Old TwinHan DST cards or clones with or without CA slot and not containing an Eeprom. -People running udev please see Documentation/dvb/udev.txt. +People running udev please see Documentation/media/dvb-drivers/udev.rst. In the following cases overriding the PCI type detection for dvb-bt8xx might be necessary: @@ -72,7 +72,7 @@ Useful parameters for verbosity level and debugging the dst module: The autodetected values are determined by the cards' "response string". In your logs see f. ex.: dst_get_device_id: Recognize [DSTMCI]. For bug reports please send in a complete log with verbose=4 activated. -Please also see Documentation/dvb/ci.txt. +Please also see Documentation/media/dvb-drivers/ci.rst. Running multiple cards ~~~~~~~~~~~~~~~~~~~~~~ @@ -100,7 +100,7 @@ Examples of card ID's: $ modprobe bttv card=113 card=135 -For a full list of card ID's please see Documentation/video4linux/CARDLIST.bttv. +For a full list of card ID's please see Documentation/media/v4l-drivers/bttv-cardlist.rst. In case of further problems please subscribe and send questions to the mailing list: linux-dvb@linuxtv.org. Probing the cards with broken PCI subsystem ID diff --git a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst index 9d6c860271cb..d311a6866b3b 100644 --- a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst +++ b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst @@ -431,7 +431,7 @@ MPEG stream. *Historical context*: This format specification originates from a custom, embedded, sliced VBI data format used by the ``ivtv`` driver. This format has already been informally specified in the kernel sources -in the file ``Documentation/video4linux/cx2341x/README.vbi`` . The +in the file ``Documentation/media/v4l-drivers/cx2341x.rst`` . The maximum size of the payload and other aspects of this format are driven by the CX23415 MPEG decoder's capabilities and limitations with respect to extracting, decoding, and displaying sliced VBI data embedded within diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index a3e81c1d276b..dfe49ae57e78 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -284,7 +284,7 @@ enum v4l2_mpeg_stream_vbi_fmt - * - ``V4L2_MPEG_STREAM_VBI_FMT_IVTV`` - VBI in private packets, IVTV format (documented in the kernel sources in the file - ``Documentation/video4linux/cx2341x/README.vbi``) + ``Documentation/media/v4l-drivers/cx2341x.rst``) diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst b/Documentation/media/uapi/v4l/pixfmt-reserved.rst index 521adb795535..38af1472a4b4 100644 --- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst +++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst @@ -52,7 +52,7 @@ please make a proposal on the linux-media mailing list. `http://www.ivtvdriver.org/ `__ The format is documented in the kernel sources in the file - ``Documentation/video4linux/cx2341x/README.hm12`` + ``Documentation/media/v4l-drivers/cx2341x.rst`` * .. _V4L2-PIX-FMT-CPIA1: - ``V4L2_PIX_FMT_CPIA1`` diff --git a/Documentation/media/v4l-drivers/max2175.rst b/Documentation/media/v4l-drivers/max2175.rst index 04478c25d57a..b1a4c89fd869 100644 --- a/Documentation/media/v4l-drivers/max2175.rst +++ b/Documentation/media/v4l-drivers/max2175.rst @@ -7,7 +7,7 @@ The MAX2175 driver implements the following driver-specific controls: ------------------------------- Enable/Disable I2S output of the tuner. This is a private control that can be accessed only using the subdev interface. - Refer to Documentation/media/kapi/v4l2-controls for more details. + Refer to Documentation/media/kapi/v4l2-controls.rst for more details. .. flat-table:: :header-rows: 0 -- cgit v1.2.3 From f495ae3c01dfa80e368a9330831023121b61006e Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Tue, 10 Oct 2017 12:36:45 -0500 Subject: Documentation: fix sound related doc refs Make sound doc refs valid. Signed-off-by: Tom Saeger Reviewed-by: Takashi Iwai Signed-off-by: Jonathan Corbet --- Documentation/sound/hd-audio/notes.rst | 2 +- Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/hd-audio/notes.rst b/Documentation/sound/hd-audio/notes.rst index f59c3cdbfaf4..9f7347830ba4 100644 --- a/Documentation/sound/hd-audio/notes.rst +++ b/Documentation/sound/hd-audio/notes.rst @@ -192,7 +192,7 @@ preset model instead of PCI (and codec-) SSID look-up. What ``model`` option values are available depends on the codec chip. Check your codec chip from the codec proc file (see "Codec Proc-File" section below). It will show the vendor/product name of your codec -chip. Then, see Documentation/sound/HD-Audio-Models.rst file, +chip. Then, see Documentation/sound/hd-audio/models.rst file, the section of HD-audio driver. You can find a list of codecs and ``model`` options belonging to each codec. For example, for Realtek ALC262 codec chip, pass ``model=ultra`` for devices that are compatible diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 58ffa3f5bda7..a0b268466cb1 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -2498,7 +2498,7 @@ Mic boost Mic-boost switch is set as “Mic Boost” or “Mic Boost (6dB)”. More precise information can be found in -``Documentation/sound/alsa/ControlNames.txt``. +``Documentation/sound/designs/control-names.rst``. Access Flags ------------ -- cgit v1.2.3 From 4269a691108aaaa6b107bba5fbde7d59f991b73e Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Tue, 10 Oct 2017 12:36:52 -0500 Subject: Documentation: fix usb related doc refs Update ref to usb proc_usb_info.txt. Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/driver-api/usb/usb.rst | 4 +--- Documentation/networking/cdc_mbim.txt | 4 ++-- Documentation/usb/gadget-testing.txt | 2 +- 3 files changed, 4 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/usb/usb.rst b/Documentation/driver-api/usb/usb.rst index dba0f876b36f..078e981e2b16 100644 --- a/Documentation/driver-api/usb/usb.rst +++ b/Documentation/driver-api/usb/usb.rst @@ -690,9 +690,7 @@ The USB devices are now exported via debugfs: This file is handy for status viewing tools in user mode, which can scan the text format and ignore most of it. More detailed device status (including class and vendor status) is available from device-specific -files. For information about the current format of this file, see the -``Documentation/usb/proc_usb_info.txt`` file in your Linux kernel -sources. +files. For information about the current format of this file, see below. This file, in combination with the poll() system call, can also be used to detect when devices are added or removed:: diff --git a/Documentation/networking/cdc_mbim.txt b/Documentation/networking/cdc_mbim.txt index e4c376abbdad..4e68f0bc5dba 100644 --- a/Documentation/networking/cdc_mbim.txt +++ b/Documentation/networking/cdc_mbim.txt @@ -332,8 +332,8 @@ References [5] "MBIM (Mobile Broadband Interface Model) Registry" - http://compliance.usb.org/mbim/ -[6] "/dev/bus/usb filesystem output" - - Documentation/usb/proc_usb_info.txt +[6] "/sys/kernel/debug/usb/devices output format" + - Documentation/driver-api/usb/usb.rst [7] "/sys/bus/usb/devices/.../descriptors" - Documentation/ABI/stable/sysfs-bus-usb diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index fbc397d17e98..441a4b9b666f 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -773,7 +773,7 @@ host: # cat /dev/usb/lp0 More advanced testing can be done with the prn_example -described in Documentation/usb/gadget-printer.txt. +described in Documentation/usb/gadget_printer.txt. 20. UAC1 function (virtual ALSA card, using u_audio API) -- cgit v1.2.3 From f2b41874240411a7d06aac2dc864a389c93183cc Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Tue, 10 Oct 2017 12:37:01 -0500 Subject: Documentation: fix networking related doc refs. Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/networking/checksum-offloads.txt | 2 +- Documentation/networking/packet_mmap.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/checksum-offloads.txt b/Documentation/networking/checksum-offloads.txt index d52d191bbb0c..27bc09cfcf6d 100644 --- a/Documentation/networking/checksum-offloads.txt +++ b/Documentation/networking/checksum-offloads.txt @@ -47,7 +47,7 @@ The requirements for GSO are more complicated, because when segmenting an (section 'E') for more details. A driver declares its offload capabilities in netdev->hw_features; see - Documentation/networking/netdev-features for more. Note that a device + Documentation/networking/netdev-features.txt for more. Note that a device which only advertises NETIF_F_IP[V6]_CSUM must still obey the csum_start and csum_offset given in the SKB; if it tries to deduce these itself in hardware (as some NICs do) the driver should check that the values in the diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index f3b9e507ab05..bf654845556e 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -1055,7 +1055,7 @@ TX_RING part only TP_STATUS_AVAILABLE is set, then the tp_sec and tp_{n,u}sec members do not contain a valid value. For TX_RINGs, by default no timestamp is generated! -See include/linux/net_tstamp.h and Documentation/networking/timestamping +See include/linux/net_tstamp.h and Documentation/networking/timestamping.txt for more information on hardware timestamps. ------------------------------------------------------------------------------- -- cgit v1.2.3 From 1ad6e3b2652b310e4ab1a544894c79d4f7cb39d3 Mon Sep 17 00:00:00 2001 From: Finn Thain Date: Thu, 12 Oct 2017 15:00:06 +1100 Subject: documentation: Update ide-cd documentation to reflect CONFIG_BLK_DEV_HD_IDE removal CONFIG_BLK_DEV_HD_IDE was removed in commit 80aa31cb460d ("ide: remove CONFIG_BLK_DEV_HD_IDE config option (take 2)") but the ide-cd documentation was not updated and still asks users to disable it, which is misleading and involves a fruitless search. Signed-off-by: Finn Thain Signed-off-by: Jonathan Corbet --- Documentation/cdrom/ide-cd | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cdrom/ide-cd b/Documentation/cdrom/ide-cd index f4dc9de2694e..a5f2a7f1ff46 100644 --- a/Documentation/cdrom/ide-cd +++ b/Documentation/cdrom/ide-cd @@ -55,13 +55,9 @@ This driver provides the following features: (to compile support as a module which can be loaded and unloaded) to the options: - Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support + ATA/ATAPI/MFM/RLL support Include IDE/ATAPI CDROM support - and `no' to - - Use old disk-only driver on primary interface - Depending on what type of IDE interface you have, you may need to specify additional configuration options. See Documentation/ide/ide.txt. -- cgit v1.2.3 From bc811c697b13dcb5abac9a410527859aca095a9c Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 28 Sep 2017 16:14:54 -0700 Subject: dt-bindings: Add documentation for Broadcom Hurricane 2 SoCs Add binding documentation for the Broadcom Hurricane 2 SoCs used in switching control planes. Acked-by: Jon Mason Signed-off-by: Florian Fainelli Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/arm/bcm/brcm,hr2.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,hr2.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,hr2.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,hr2.txt new file mode 100644 index 000000000000..a124c7fc4dcd --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,hr2.txt @@ -0,0 +1,14 @@ +Broadcom Hurricane 2 device tree bindings +--------------------------------------- + +Broadcom Hurricane 2 family of SoCs are used for switching control. These SoCs +are based on Broadcom's iProc SoC architecture and feature a single core Cortex +A9 ARM CPUs, DDR2/DDR3 memory, PCIe GEN-2, USB 2.0 and USB 3.0, serial and NAND +flash and a PCIe attached integrated switching engine. + +Boards with Hurricane SoCs shall have the following properties: + +Required root node property: + +BCM53342 +compatible = "brcm,bcm53342", "brcm,hr2"; -- cgit v1.2.3 From c6d2efd12744fc4c9c620eab9a92b0c4e9f5e4bd Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 28 Sep 2017 16:14:56 -0700 Subject: dt-bindings: Document Broadcom Hurricane 2 clocks Add a Device Tree binding document for the Broadcom Hurricane 2 SoC which is an iProc based system. Acked-by: Jon Mason Signed-off-by: Florian Fainelli Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- .../devicetree/bindings/clock/brcm,iproc-clocks.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt index f2c5f0e4a363..f8e4a93466cb 100644 --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt @@ -137,6 +137,20 @@ These clock IDs are defined in: ch1_audio audiopll 2 BCM_CYGNUS_AUDIOPLL_CH1 ch2_audio audiopll 3 BCM_CYGNUS_AUDIOPLL_CH2 +Hurricane 2 +------ +PLL and leaf clock compatible strings for Hurricane 2 are: + "brcm,hr2-armpll" + +The following table defines the set of PLL/clock for Hurricane 2: + + Clock Source Index ID + --- ----- ----- --------- + crystal N/A N/A N/A + + armpll crystal N/A N/A + + Northstar and Northstar Plus ------ PLL and leaf clock compatible strings for Northstar and Northstar Plus are: -- cgit v1.2.3 From e6ac8fc0823f9227a6ce65481adcbdbf529acfb9 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 28 Sep 2017 16:15:00 -0700 Subject: dt-bindings: Add Ubiquiti Networks vendor prefix Use the stock ticker: UBNT as the vendor prefix for Ubiquiti Networks. Acked-by: Jon Mason Signed-off-by: Florian Fainelli Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1ea1fd4232ab..91b6b5b36d4c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -351,6 +351,7 @@ truly Truly Semiconductors Limited tsd Theobroma Systems Design und Consulting GmbH tyan Tyan Computer Corporation ucrobotics uCRobotics +ubnt Ubiquiti Networks udoo Udoo uniwest United Western Technologies Corp (UniWest) upisemi uPI Semiconductor Corp. -- cgit v1.2.3 From cfc95173ba8e18e41d9a69d2747d0f2738a2a551 Mon Sep 17 00:00:00 2001 From: Joel Stanley Date: Wed, 23 Aug 2017 15:39:56 +0930 Subject: dt-bindings: aspeed-scu: Add clock and reset properties Signed-off-by: Joel Stanley Acked-by: Rob Herring Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt index 4fc5b83726d6..ce8cf0ec6279 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt +++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt @@ -9,10 +9,16 @@ Required properties: "aspeed,g5-scu", "syscon", "simple-mfd" - reg: contains the offset and length of the SCU memory region +- #clock-cells: should be set to <1> - the system controller is also a + clock provider +- #reset-cells: should be set to <1> - the system controller is also a + reset line provider Example: syscon: syscon@1e6e2000 { compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd"; reg = <0x1e6e2000 0x1a8>; + #clock-cells = <1>; + #reset-cells = <1>; }; -- cgit v1.2.3 From 4589515af30005a404bd34e4b7933f98e68849f4 Mon Sep 17 00:00:00 2001 From: Maciej Purski Date: Tue, 5 Sep 2017 15:50:27 +0200 Subject: mfd: max77693: Add muic of_compatible in mfd_cell This patch adds muic of_compatible in order to use the muic device driver in device tree. Signed-off-by: Maciej Purski Reviewed-by: Chanwoo Choi Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/max77693.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 6a1ae3a2b77f..e6754974a745 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -127,6 +127,12 @@ Required properties for the LED child node: Optional properties for the LED child node: - label : see Documentation/devicetree/bindings/leds/common.txt +Optional nodes: +- max77693-muic : + Node used only by extcon consumers. + Required properties: + - compatible : "maxim,max77693-muic" + Example: #include -- cgit v1.2.3 From 58ab243ef5ad1aee7600eb4bd8d9ce5a63401c5e Mon Sep 17 00:00:00 2001 From: Ray Jui Date: Wed, 6 Sep 2017 17:27:41 -0700 Subject: syscon: dt-bindings: Add binding doc for Broadcom iProc CDRU Add binding document for Broadcom iProc's Chip Device Resource Unit (CDRU). Multiple iProc based chips have this CDRU block that contains miscellaneous registers for chip or device configurations. Start with Stingray specific compatible string for the initial binding Signed-off-by: Ray Jui Reviewed-by: Scott Branden Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/brcm,iproc-cdru.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/brcm,iproc-cdru.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/brcm,iproc-cdru.txt b/Documentation/devicetree/bindings/mfd/brcm,iproc-cdru.txt new file mode 100644 index 000000000000..82f82e069563 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/brcm,iproc-cdru.txt @@ -0,0 +1,16 @@ +Broadcom iProc Chip Device Resource Unit (CDRU) + +Various Broadcom iProc SoCs have a set of registers that provide various +chip specific device and resource configurations. This node allows access to +these CDRU registers via syscon. + +Required properties: +- compatible: should contain: + "brcm,sr-cdru", "syscon" for Stingray +- reg: base address and range of the CDRU registers + +Example: + cdru: syscon@6641d000 { + compatible = "brcm,sr-cdru", "syscon"; + reg = <0 0x6641d000 0 0x400>; + }; -- cgit v1.2.3 From 88decb026d90c386b2a15adbe6fb094f6a86d144 Mon Sep 17 00:00:00 2001 From: Ray Jui Date: Wed, 6 Sep 2017 17:27:42 -0700 Subject: syscon: dt-bindings: Add binding document for iProc MHB block Add binding document for Broadcom iProc's Multi-Host Bridge (MHB) block Signed-off-by: Ray Jui Reviewed-by: Scott Branden Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/brcm,iproc-mhb.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/brcm,iproc-mhb.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/brcm,iproc-mhb.txt b/Documentation/devicetree/bindings/mfd/brcm,iproc-mhb.txt new file mode 100644 index 000000000000..4421e9771b8a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/brcm,iproc-mhb.txt @@ -0,0 +1,18 @@ +Broadcom iProc Multi Host Bridge (MHB) + +Certain Broadcom iProc SoCs have a multi host bridge (MHB) block that controls +the connection and configuration of 1) internal PCIe serdes; 2) PCIe endpoint +interface; 3) access to the Nitro (network processing) engine + +This node allows access to these MHB registers via syscon. + +Required properties: +- compatible: should contain: + "brcm,sr-mhb", "syscon" for Stingray +- reg: base address and range of the MHB registers + +Example: + mhb: syscon@60401000 { + compatible = "brcm,sr-mhb", "syscon"; + reg = <0 0x60401000 0 0x38c>; + }; -- cgit v1.2.3 From 4a40aedec653bb9e22c01ef4fe0a66278b1a666f Mon Sep 17 00:00:00 2001 From: Julien Grall Date: Tue, 3 Oct 2017 15:20:27 +0100 Subject: DT: arm,gic-v3: Update the ITS size in the examples Currently, the examples are using 2MB for the ITS size. Per the specification (section 8.18 in ARM IHI 0069D), the ITS address map is 128KB. Update the examples to match the specification. Signed-off-by: Julien Grall Signed-off-by: Marc Zyngier --- .../devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt index 4c29cdab0ea5..5eb108e180fa 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt @@ -99,7 +99,7 @@ Examples: compatible = "arm,gic-v3-its"; msi-controller; #msi-cells = <1>; - reg = <0x0 0x2c200000 0 0x200000>; + reg = <0x0 0x2c200000 0 0x20000>; }; }; @@ -124,14 +124,14 @@ Examples: compatible = "arm,gic-v3-its"; msi-controller; #msi-cells = <1>; - reg = <0x0 0x2c200000 0 0x200000>; + reg = <0x0 0x2c200000 0 0x20000>; }; gic-its@2c400000 { compatible = "arm,gic-v3-its"; msi-controller; #msi-cells = <1>; - reg = <0x0 0x2c400000 0 0x200000>; + reg = <0x0 0x2c400000 0 0x20000>; }; ppi-partitions { -- cgit v1.2.3 From d67ac3ae3a3ce464b4fec854c4c85407a99e8e2c Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 4 Oct 2017 14:33:08 +0200 Subject: dt-bindings: iommu: ipmmu-vmsa: Use generic node name Use the preferred generic node name in the example. Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt index 3ed027cfca95..857df929a654 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt @@ -53,7 +53,7 @@ Example: R8A7791 IPMMU-MX and VSP1-D0 bus master #iommu-cells = <1>; }; - vsp1@fe928000 { + vsp@fe928000 { ... iommus = <&ipmmu_mx 13>; ... -- cgit v1.2.3 From 23c4490d2b7f78a855f9c5675e26735fb61afe84 Mon Sep 17 00:00:00 2001 From: weiping zhang Date: Sat, 14 Oct 2017 00:26:28 +0800 Subject: null_blk: update usage hints for submit_queues update the range of submits_queues, and correct usage hints. Signed-off-by: weiping zhang Signed-off-by: Jens Axboe --- Documentation/block/null_blk.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/null_blk.txt b/Documentation/block/null_blk.txt index 3140dbd860d8..1f8d92c70458 100644 --- a/Documentation/block/null_blk.txt +++ b/Documentation/block/null_blk.txt @@ -55,10 +55,10 @@ irqmode=[0-2]: Default: 1-Soft-irq completion_nsec=[ns]: Default: 10.000ns Combined with irqmode=2 (timer). The time each completion event must wait. -submit_queues=[0..nr_cpus]: +submit_queues=[1..nr_cpus]: The number of submission queues attached to the device driver. If unset, it - defaults to 1 on single-queue and bio-based instances. For multi-queue, - it is ignored when use_per_node_hctx module parameter is 1. + defaults to 1. For multi-queue, it is ignored when use_per_node_hctx module + parameter is 1. hw_queue_depth=[0..qdepth]: Default: 64 The hardware queue depth of the device. -- cgit v1.2.3 From fc186311f2233bb3f69f22b96babdf16a57c88a9 Mon Sep 17 00:00:00 2001 From: weiping zhang Date: Sat, 14 Oct 2017 00:26:54 +0800 Subject: null_blk: add usage hints for no_sched This parameter provide an option to disable io scheduler when nullb* in multi-queue mode. Signed-off-by: weiping zhang Signed-off-by: Jens Axboe --- Documentation/block/null_blk.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/block/null_blk.txt b/Documentation/block/null_blk.txt index 1f8d92c70458..b7161c8e70f2 100644 --- a/Documentation/block/null_blk.txt +++ b/Documentation/block/null_blk.txt @@ -73,3 +73,7 @@ use_per_node_hctx=[0/1]: Default: 0 use_lightnvm=[0/1]: Default: 0 Register device with LightNVM. Requires blk-mq and CONFIG_NVM to be enabled. + +no_sched=[0/1]: Default: 0 + 0: nullb* use default blk-mq io scheduler. + 1: nullb* doesn't use io scheduler. -- cgit v1.2.3 From de18e4bea0784e8df67c908c6157acc05ecba0cf Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 9 Oct 2017 20:18:33 +0200 Subject: devicetree: Add vendor-prefix for DH electronics GmbH Add vendor prefix for DH electronics GmbH, https://www.dh-electronics.com . The company is a SoM and evaluation board manufacturer. Signed-off-by: Marek Vasut Cc: Rob Herring Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 5268738c3e7c..15c6b33f0b21 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -83,6 +83,7 @@ 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 -- cgit v1.2.3 From 20f97caf1120bd02e8ff4adbad3b44b63626feb5 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Fri, 13 Oct 2017 15:27:24 +0200 Subject: PM / QoS: Drop PM_QOS_FLAG_REMOTE_WAKEUP The PM QoS flag PM_QOS_FLAG_REMOTE_WAKEUP is not used consistently and the vast majority of code simply assumes that remote wakeup should be enabled for devices in runtime suspend if they can generate wakeup signals, so drop it. Signed-off-by: Rafael J. Wysocki Acked-by: Ulf Hansson Reviewed-by: Mika Westerberg --- Documentation/ABI/testing/sysfs-devices-power | 16 ---------------- Documentation/power/pm_qos_interface.txt | 13 ++++++------- 2 files changed, 6 insertions(+), 23 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 676fdf5f2a99..f4b24c327665 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -258,19 +258,3 @@ Description: This attribute has no effect on system-wide suspend/resume and hibernation. - -What: /sys/devices/.../power/pm_qos_remote_wakeup -Date: September 2012 -Contact: Rafael J. Wysocki -Description: - The /sys/devices/.../power/pm_qos_remote_wakeup attribute - is used for manipulating the PM QoS "remote wakeup required" - flag. If set, this flag indicates to the kernel that the - device is a source of user events that have to be signaled from - its low-power states. - - Not all drivers support this attribute. If it isn't supported, - it is not present. - - This attribute has no effect on system-wide suspend/resume and - hibernation. diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt index 21d2d48f87a2..19c5f7b1a7ba 100644 --- a/Documentation/power/pm_qos_interface.txt +++ b/Documentation/power/pm_qos_interface.txt @@ -98,8 +98,7 @@ Values are updated in response to changes of the request list. The target values of resume latency and active state latency tolerance are simply the minimum of the request values held in the parameter list elements. The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements' -values. Two device PM QoS flags are defined currently: PM_QOS_FLAG_NO_POWER_OFF -and PM_QOS_FLAG_REMOTE_WAKEUP. +values. One device PM QoS flag is defined currently: PM_QOS_FLAG_NO_POWER_OFF. Note: The aggregated target values are implemented in such a way that reading the aggregated value does not require any locking mechanism. @@ -153,14 +152,14 @@ PM QoS list of resume latency constraints and remove sysfs attribute pm_qos_resume_latency_us from the device's power directory. int dev_pm_qos_expose_flags(device, value) -Add a request to the device's PM QoS list of flags and create sysfs attributes -pm_qos_no_power_off and pm_qos_remote_wakeup under the device's power directory -allowing user space to change these flags' value. +Add a request to the device's PM QoS list of flags and create sysfs attribute +pm_qos_no_power_off under the device's power directory allowing user space to +change the value of the PM_QOS_FLAG_NO_POWER_OFF flag. void dev_pm_qos_hide_flags(device) Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list -of flags and remove sysfs attributes pm_qos_no_power_off and pm_qos_remote_wakeup -under the device's power directory. +of flags and remove sysfs attribute pm_qos_no_power_off from the device's power +directory. Notification mechanisms: The per-device PM QoS framework has a per-device notification tree. -- cgit v1.2.3 From 61b639723be5a9fc4812d5d85cb769589afa5a38 Mon Sep 17 00:00:00 2001 From: Huang Ying Date: Fri, 13 Oct 2017 15:58:29 -0700 Subject: mm, swap: use page-cluster as max window of VMA based swap readahead When the VMA based swap readahead was introduced, a new knob /sys/kernel/mm/swap/vma_ra_max_order was added as the max window of VMA swap readahead. This is to make it possible to use different max window for VMA based readahead and original physical readahead. But Minchan Kim pointed out that this will cause a regression because setting page-cluster sysctl to zero cannot disable swap readahead with the change. To fix the regression, the page-cluster sysctl is used as the max window of both the VMA based swap readahead and original physical swap readahead. If more fine grained control is needed in the future, more knobs can be added as the subordinate knobs of the page-cluster sysctl. The vma_ra_max_order knob is deleted. Because the knob was introduced in v4.14-rc1, and this patch is targeting being merged before v4.14 releasing, there should be no existing users of this newly added ABI. Link: http://lkml.kernel.org/r/20171011070847.16003-1-ying.huang@intel.com Fixes: ec560175c0b6fce ("mm, swap: VMA based swap readahead") Signed-off-by: "Huang, Ying" Reported-by: Minchan Kim Acked-by: Minchan Kim Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Rik van Riel Cc: Shaohua Li Cc: Hugh Dickins Cc: Fengguang Wu Cc: Tim Chen Cc: Dave Hansen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/ABI/testing/sysfs-kernel-mm-swap | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-swap b/Documentation/ABI/testing/sysfs-kernel-mm-swap index 587db52084c7..94672016c268 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-swap +++ b/Documentation/ABI/testing/sysfs-kernel-mm-swap @@ -14,13 +14,3 @@ Description: Enable/disable VMA based swap readahead. still used for tmpfs etc. other users. If set to false, the global swap readahead algorithm will be used for all swappable pages. - -What: /sys/kernel/mm/swap/vma_ra_max_order -Date: August 2017 -Contact: Linux memory management mailing list -Description: The max readahead size in order for VMA based swap readahead - - VMA based swap readahead algorithm will readahead at - most 1 << max_order pages for each readahead. The - real readahead size for each readahead will be scaled - according to the estimation algorithm. -- cgit v1.2.3 From 11af847446ed0d131cf24d16a7ef3d5ea7a49554 Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf Date: Fri, 13 Oct 2017 15:02:00 -0500 Subject: x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*' Rename the unwinder config options from: CONFIG_ORC_UNWINDER CONFIG_FRAME_POINTER_UNWINDER CONFIG_GUESS_UNWINDER to: CONFIG_UNWINDER_ORC CONFIG_UNWINDER_FRAME_POINTER CONFIG_UNWINDER_GUESS ... in order to give them a more logical config namespace. Suggested-by: Ingo Molnar Signed-off-by: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/73972fc7e2762e91912c6b9584582703d6f1b8cc.1507924831.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar --- Documentation/x86/orc-unwinder.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/x86/orc-unwinder.txt b/Documentation/x86/orc-unwinder.txt index af0c9a4c65a6..cd4b29be29af 100644 --- a/Documentation/x86/orc-unwinder.txt +++ b/Documentation/x86/orc-unwinder.txt @@ -4,7 +4,7 @@ ORC unwinder Overview -------- -The kernel CONFIG_ORC_UNWINDER option enables the ORC unwinder, which is +The kernel CONFIG_UNWINDER_ORC option enables the ORC unwinder, which is similar in concept to a DWARF unwinder. The difference is that the format of the ORC data is much simpler than DWARF, which in turn allows the ORC unwinder to be much simpler and faster. -- cgit v1.2.3 From d35d43d783bf770638098a8dd939e8fd270cafc9 Mon Sep 17 00:00:00 2001 From: Peter Meerwald-Stadler Date: Tue, 10 Oct 2017 15:48:46 +0200 Subject: Documentation: iio: Clarify meaning of IIO_DISTANCE channel type IIO_DISTANCE is used for two purposes: for pedometers to record the distance covered by a walker, and to measure the distance to an object IIO_DISTANCE is in meters while IIO_PROXIMITY is a unitless measure indirectly proportional to distance (higher value relates to a closer object) Signed-off-by: Peter Meerwald-Stadler Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 7eead5f97e02..3fc79185cc56 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -1242,9 +1242,9 @@ What: /sys/.../iio:deviceX/in_distance_raw KernelVersion: 4.0 Contact: linux-iio@vger.kernel.org Description: - This attribute is used to read the distance covered by the user - since the last reboot while activated. Units after application - of scale are meters. + This attribute is used to read the measured distance to an object + or the distance covered by the user since the last reboot while + activated. Units after application of scale are meters. What: /sys/bus/iio/devices/iio:deviceX/store_eeprom KernelVersion: 3.4.0 -- cgit v1.2.3 From 6d39a6cc38899d3f77b5f8bb03afcdc407e11933 Mon Sep 17 00:00:00 2001 From: Peter Meerwald-Stadler Date: Wed, 11 Oct 2017 11:09:07 +0200 Subject: dt-bindings: iio: health: Fix max30100 I2C chip address in example Should be in hex, not decimal or even octal Signed-off-by: Peter Meerwald-Stadler Acked-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/health/max30100.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/health/max30100.txt b/Documentation/devicetree/bindings/iio/health/max30100.txt index 295a9edfa4fd..8d8176459d09 100644 --- a/Documentation/devicetree/bindings/iio/health/max30100.txt +++ b/Documentation/devicetree/bindings/iio/health/max30100.txt @@ -20,9 +20,9 @@ Optional properties: Example: -max30100@057 { +max30100@57 { compatible = "maxim,max30100"; - reg = <57>; + reg = <0x57>; maxim,led-current-microamp = <24000 50000>; interrupt-parent = <&gpio1>; interrupts = <16 2>; -- cgit v1.2.3 From 446b3217a96c456ab8796605fbb3ce379b03a504 Mon Sep 17 00:00:00 2001 From: Peter Meerwald-Stadler Date: Wed, 11 Oct 2017 11:09:08 +0200 Subject: dt-bindings: iio: health: Use binding name for max30102 in example Signed-off-by: Peter Meerwald-Stadler Acked-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/health/max30102.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/health/max30102.txt b/Documentation/devicetree/bindings/iio/health/max30102.txt index c695e7cbeefb..8629c18b0e78 100644 --- a/Documentation/devicetree/bindings/iio/health/max30102.txt +++ b/Documentation/devicetree/bindings/iio/health/max30102.txt @@ -20,7 +20,7 @@ Optional properties: Example: -max30100@57 { +max30102@57 { compatible = "maxim,max30102"; reg = <0x57>; maxim,red-led-current-microamp = <7000>; -- cgit v1.2.3 From 11b86c7004ef14f9f8c1e2caf66bfaad6f3167a2 Mon Sep 17 00:00:00 2001 From: Gwendal Grignou Date: Thu, 12 Oct 2017 19:33:23 +0200 Subject: platform/chrome: Add cros_ec_accel_legacy driver Add driver to support older EC firmware that only support deprecated ec command. Rely on ACPI memory map register to access sensor information. Present same interface as the regular cros_ec sensor stack: - one iio device per accelerometer - use HTML5 axis definition - use iio abi units - accept calibration calls, but do nothing Chrome can use the same code than regular cros_ec sensor stack to calculate orientation and lid angle. Signed-off-by: Gwendal Grignou Signed-off-by: Thierry Escande Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio-cros-ec | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-cros-ec b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec index 297b9720f024..0e95c2ca105c 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-cros-ec +++ b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec @@ -16,3 +16,13 @@ Description: the motion sensor is placed. For example, in a laptop a motion sensor can be located on the base or on the lid. Current valid values are 'base' and 'lid'. + +What: /sys/bus/iio/devices/iio:deviceX/id +Date: Septembre 2017 +KernelVersion: 4.14 +Contact: linux-iio@vger.kernel.org +Description: + This attribute is exposed by the CrOS EC legacy accelerometer + driver and represents the sensor ID as exposed by the EC. This + ID is used by the Android sensor service hardware abstraction + layer (sensor HAL) through the Android container on ChromeOS. -- cgit v1.2.3 From 8d59598c35dc1071e6c36f86c9a95f26dd08b4e5 Mon Sep 17 00:00:00 2001 From: Nicolas Pitre Date: Thu, 12 Oct 2017 02:16:13 -0400 Subject: cramfs: rehabilitate it Update documentation, pointer to latest tools, appoint myself as maintainer. Given it's been unloved for so long, I don't expect anyone will protest. Signed-off-by: Nicolas Pitre Tested-by: Chris Brandt Signed-off-by: Al Viro --- Documentation/filesystems/cramfs.txt | 42 ++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/cramfs.txt b/Documentation/filesystems/cramfs.txt index 4006298f6707..8e19a53d648b 100644 --- a/Documentation/filesystems/cramfs.txt +++ b/Documentation/filesystems/cramfs.txt @@ -45,6 +45,48 @@ you can just change the #define in mkcramfs.c, so long as you don't mind the filesystem becoming unreadable to future kernels. +Memory Mapped cramfs image +-------------------------- + +The CRAMFS_MTD Kconfig option adds support for loading data directly from +a physical linear memory range (usually non volatile memory like Flash) +instead of going through the block device layer. This saves some memory +since no intermediate buffering is necessary to hold the data before +decompressing. + +And when data blocks are kept uncompressed and properly aligned, they will +automatically be mapped directly into user space whenever possible providing +eXecute-In-Place (XIP) from ROM of read-only segments. Data segments mapped +read-write (hence they have to be copied to RAM) may still be compressed in +the cramfs image in the same file along with non compressed read-only +segments. Both MMU and no-MMU systems are supported. This is particularly +handy for tiny embedded systems with very tight memory constraints. + +The location of the cramfs image in memory is system dependent. You must +know the proper physical address where the cramfs image is located and +configure an MTD device for it. Also, that MTD device must be supported +by a map driver that implements the "point" method. Examples of such +MTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap +(Flash device in physical memory map). MTD partitions based on such devices +are fine too. Then that device should be specified with the "mtd:" prefix +as the mount device argument. For example, to mount the MTD device named +"fs_partition" on the /mnt directory: + +$ mount -t cramfs mtd:fs_partition /mnt + +To boot a kernel with this as root filesystem, suffice to specify +something like "root=mtd:fs_partition" on the kernel command line. + + +Tools +----- + +A version of mkcramfs that can take advantage of the latest capabilities +described above can be found here: + +https://github.com/npitre/cramfs-tools + + For /usr/share/magic -------------------- -- cgit v1.2.3 From 3991e054832e52119b238b397e5e510d7fee5bb4 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 8 Oct 2017 14:26:28 +0200 Subject: dt-bindings: samsung: Document binding for new Odroid HC1 board Document the binding for new Hardkernel Odroid HC1 board. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt index 3c551894f621..5e95e3e81140 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt @@ -57,6 +57,7 @@ Required root node properties: - "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel Odroid XU3 Lite board. - "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4. + - "hardkernel,odroid-hc1" - for Exynos5422-based Hardkernel Odroid HC1. * Insignal - "insignal,arndale" - for Exynos5250-based Insignal Arndale board. -- cgit v1.2.3 From 70dfb1205224ed62acd46b31ebfa299685b0098a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20F=C3=A4rber?= Date: Sat, 12 Aug 2017 00:04:51 +0200 Subject: dt-bindings: Add vendor prefix for ProBox2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit PROBOX2 is a TV box brand by Hong Kong based online reseller W2COMP Company Limited. Cc: support@probox2.com Acked-by: Rob Herring Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1ea1fd4232ab..d17d01a160de 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -263,6 +263,7 @@ plathome Plat'Home Co., Ltd. plda PLDA 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 -- cgit v1.2.3 From f80ec175ba721fd6d56f407af64a6712d5bdfa1b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20F=C3=A4rber?= Date: Sat, 12 Aug 2017 00:22:30 +0200 Subject: dt-bindings: arm: realtek: Add ProBox2 AVA MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document a compatible string for the PROBOX2 AVA TV Box. Cc: support@probox2.com Acked-by: Rob Herring Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/realtek.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt index 13d755787b4f..297c15eb81e2 100644 --- a/Documentation/devicetree/bindings/arm/realtek.txt +++ b/Documentation/devicetree/bindings/arm/realtek.txt @@ -12,6 +12,7 @@ Required root node properties: Root node property compatible must contain, depending on board: + - ProBox2 AVA: "probox2,ava" - Zidoo X9S: "zidoo,x9s" -- cgit v1.2.3 From d93cc0e7888a7c650a9155ad70e2236d15785c1e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Br=C3=BCns?= Date: Thu, 28 Sep 2017 03:49:23 +0200 Subject: arm64: allwinner: a64: Add devicetree binding for DMA controller MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The A64 is register compatible with the H3, but has a different number of dma channels and request ports. Attach additional properties to the node to allow future reuse of the compatible for controllers with different number of channels/requests. If dma-requests is not specified, the register layout defined maximum of 32 is used. Signed-off-by: Stefan Brüns Acked-by: Rob Herring Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/sun6i-dma.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt b/Documentation/devicetree/bindings/dma/sun6i-dma.txt index 98fbe1a5c6dd..9700b1d00fed 100644 --- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt +++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt @@ -27,6 +27,32 @@ Example: #dma-cells = <1>; }; +------------------------------------------------------------------------------ +For A64 DMA controller: + +Required properties: +- compatible: "allwinner,sun50i-a64-dma" +- dma-channels: Number of DMA channels supported by the controller. + Refer to Documentation/devicetree/bindings/dma/dma.txt +- all properties above, i.e. reg, interrupts, clocks, resets and #dma-cells + +Optional properties: +- dma-requests: Number of DMA request signals supported by the controller. + Refer to Documentation/devicetree/bindings/dma/dma.txt + +Example: + dma: dma-controller@1c02000 { + compatible = "allwinner,sun50i-a64-dma"; + reg = <0x01c02000 0x1000>; + interrupts = ; + clocks = <&ccu CLK_BUS_DMA>; + dma-channels = <8>; + dma-requests = <27>; + resets = <&ccu RST_BUS_DMA>; + #dma-cells = <1>; + }; +------------------------------------------------------------------------------ + Clients: DMA clients connected to the A31 DMA controller must use the format -- cgit v1.2.3 From 9ed95129ffcabbde564b40ffbbf9c26e8702d858 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 4 Oct 2017 16:17:55 +0200 Subject: Documentation: Add a file explaining the Linux kernel license enforcement policy MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This adds a short document describing the views of how the Linux kernel community feels about enforcing the license of the kernel. Acked-by: Al Viro Acked-by: Alex Elder (Linaro) Acked-by: Andrea Arcangeli Acked-by: Andy Gross Acked-by: Aneesh Kumar K.V Acked-by: Anna Schumaker Acked-by: Ard Biesheuvel Acked-by: Arnd Bergmann Acked-by: Arvind Yadav Acked-by: Bart Van Assche Acked-by: Bhumika Goyal Acked-by: Bjorn Andersson Acked-by: Borislav Petkov Acked-by: Christian Borntraeger Acked-by: Christian König Acked-by: Christophe JAILLET Acked-by: Chuck Lever Acked-by: Colin Ian King Acked-by: Daniel Borkmann Acked-by: Daniel Lezcano Acked-by: Daniel Vetter Acked-by: Darrick J. Wong (Oracle) Acked-by: Darrick J. Wong Acked-by: David Kershner Acked-by: David S. Miller Acked-by: Dmitry Torokhov Acked-by: Doug Ledford Acked-by: Fabio Estevam Acked-by: Felipe Balbi Acked-by: Florian Westphal Acked-by: Geert Uytterhoeven Acked-by: Guenter Roeck Acked-by: Hannes Reinecke Acked-by: Hans de Goede Acked-by: Heiko Carstens Acked-by: Heiko Stuebner Acked-by: Heiner Kallweit Acked-by: Ingo Molnar Acked-by: Ivan Safonov Acked-by: Jaegeuk Kim Acked-by: Jan Kara (SUSE) Acked-by: Javier Martinez Canillas Acked-by: Jeff Kirsher Acked-by: Jens Axboe Acked-by: Jes Sorensen Acked-by: Jiri Kosina Acked-by: Jiri Pirko Acked-by: Joe Perches Acked-by: Joerg Roedel (SUSE) Acked-by: Johan Hovold Acked-by: Josh Poimboeuf Acked-by: Juergen Gross Acked-by: Julia Lawall Acked-by: K. Y. Srinivasan Acked-by: Khalid Aziz Acked-by: Krzysztof Kozlowski Acked-by: Kuninori Morimoto Acked-by: Larry Finger Acked-by: Laura Abbott Acked-by: Lee Jones Acked-by: Leon Romanovsky Acked-by: Linus Walleij (Linaro) Acked-by: Lv Zheng Acked-by: Martin K. Petersen (Oracle) Acked-by: Masahiro Yamada Acked-by: Masami Hiramatsu Acked-by: Mel Gorman Acked-by: Michael S. Tsirkin Acked-by: Michal Hocko Acked-by: Mike Marshall Acked-by: Namhyung Kim Acked-by: Neil Armstrong Acked-by: Olof Johansson Acked-by: Pablo Neira Ayuso Acked-by: Paolo Bonzini Acked-by: Paul Burton Acked-by: Paul E. McKenney Acked-by: Peter Zijlstra Acked-by: Rafael J. Wysocki Acked-by: Ralf Baechle Acked-by: Richard Weinberger Acked-by: Rik van Riel Acked-by: Rob Clark Acked-by: Rob Herring Acked-by: Sebastian Reichel (Collabora) Acked-by: Shawn Guo Acked-by: Shuah Khan Acked-by: Simon Horman Acked-by: Srinivas Kandagatla Acked-by: Steven Rostedt (VMware) Acked-by: Sven Eckelmann Acked-by: Takashi Iwai (SUSE) Acked-by: Tejun Heo Acked-by: Thierry Reding Acked-by: Tony Luck Acked-by: Ulf Hansson Acked-by: Vinod Koul Acked-by: Viresh Kumar Acked-by: Vivien Didelot Acked-by: Wei Yongjun Acked-by: Xin Long Signed-off-by: Greg Kroah-Hartman --- Documentation/process/index.rst | 1 + .../process/kernel-enforcement-statement.rst | 147 +++++++++++++++++++++ 2 files changed, 148 insertions(+) create mode 100644 Documentation/process/kernel-enforcement-statement.rst (limited to 'Documentation') diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 82fc399fcd33..61e43cc3ed17 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -25,6 +25,7 @@ Below are the essential guides that every developer should read. submitting-patches coding-style email-clients + kernel-enforcement-statement Other guides to the community that are of interest to most developers are: diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst new file mode 100644 index 000000000000..1e23d4227337 --- /dev/null +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -0,0 +1,147 @@ +Linux Kernel Enforcement Statement +---------------------------------- + +As developers of the Linux kernel, we have a keen interest in how our software +is used and how the license for our software is enforced. Compliance with the +reciprocal sharing obligations of GPL-2.0 is critical to the long-term +sustainability of our software and community. + +Although there is a right to enforce the separate copyright interests in the +contributions made to our community, we share an interest in ensuring that +individual enforcement actions are conducted in a manner that benefits our +community and do not have an unintended negative impact on the health and +growth of our software ecosystem. In order to deter unhelpful enforcement +actions, we agree that it is in the best interests of our development +community to undertake the following commitment to users of the Linux kernel +on behalf of ourselves and any successors to our copyright interests: + + Notwithstanding the termination provisions of the GPL-2.0, we agree that + it is in the best interests of our development community to adopt the + following provisions of GPL-3.0 as additional permissions under our + license with respect to any non-defensive assertion of rights under the + license. + + However, if you cease all violation of this License, then your license + from a particular copyright holder is reinstated (a) provisionally, + unless and until the copyright holder explicitly and finally + terminates your license, and (b) permanently, if the copyright holder + fails to notify you of the violation by some reasonable means prior to + 60 days after the cessation. + + Moreover, your license from a particular copyright holder is + reinstated permanently if the copyright holder notifies you of the + violation by some reasonable means, this is the first time you have + received notice of violation of this License (for any work) from that + copyright holder, and you cure the violation prior to 30 days after + your receipt of the notice. + +Our intent in providing these assurances is to encourage more use of the +software. We want companies and individuals to use, modify and distribute +this software. We want to work with users in an open and transparent way to +eliminate any uncertainty about our expectations regarding compliance or +enforcement that might limit adoption of our software. We view legal action +as a last resort, to be initiated only when other community efforts have +failed to resolve the problem. + +Finally, once a non-compliance issue is resolved, we hope the user will feel +welcome to join us in our efforts on this project. Working together, we will +be stronger. + +Except where noted below, we speak only for ourselves, and not for any company +we might work for today, have in the past, or will in the future. + + - Bjorn Andersson (Linaro) + - Andrea Arcangeli (Red Hat) + - Neil Armstrong + - Jens Axboe + - Pablo Neira Ayuso + - Khalid Aziz + - Ralf Baechle + - Felipe Balbi + - Arnd Bergmann + - Ard Biesheuvel + - Paolo Bonzini (Red Hat) + - Christian Borntraeger + - Mark Brown (Linaro) + - Paul Burton + - Javier Martinez Canillas + - Rob Clark + - Jonathan Corbet + - Vivien Didelot (Savoir-faire Linux) + - Hans de Goede (Red Hat) + - Mel Gorman (SUSE) + - Sven Eckelmann + - Alex Elder (Linaro) + - Fabio Estevam + - Larry Finger + - Bhumika Goyal + - Andy Gross + - Juergen Gross + - Shawn Guo + - Ulf Hansson + - Tejun Heo + - Rob Herring + - Masami Hiramatsu + - Michal Hocko + - Simon Horman + - Johan Hovold (Hovold Consulting AB) + - Christophe JAILLET + - Olof Johansson + - Lee Jones (Linaro) + - Heiner Kallweit + - Srinivas Kandagatla + - Jan Kara + - Shuah Khan (Samsung) + - David Kershner + - Jaegeuk Kim + - Namhyung Kim + - Colin Ian King + - Jeff Kirsher + - Greg Kroah-Hartman (Linux Foundation) + - Christian König + - Vinod Koul + - Krzysztof Kozlowski + - Viresh Kumar + - Aneesh Kumar K.V + - Julia Lawall + - Doug Ledford (Red Hat) + - Chuck Lever (Oracle) + - Daniel Lezcano + - Shaohua Li + - Xin Long (Red Hat) + - Tony Luck + - Mike Marshall + - Chris Mason + - Paul E. McKenney + - David S. Miller + - Ingo Molnar + - Kuninori Morimoto + - Borislav Petkov + - Jiri Pirko + - Josh Poimboeuf + - Sebastian Reichel (Collabora) + - Guenter Roeck + - Joerg Roedel + - Leon Romanovsky + - Steven Rostedt (VMware) + - Ivan Safonov + - Ivan Safonov + - Anna Schumaker + - Jes Sorensen + - K.Y. Srinivasan + - Heiko Stuebner + - Jiri Kosina (SUSE) + - Dmitry Torokhov + - Linus Torvalds + - Thierry Reding + - Rik van Riel + - Geert Uytterhoeven (Glider bvba) + - Daniel Vetter + - Linus Walleij + - Richard Weinberger + - Dan Williams + - Rafael J. Wysocki + - Arvind Yadav + - Masahiro Yamada + - Wei Yongjun + - Lv Zheng -- cgit v1.2.3 From 8ca8ac1024841781f544427b7ca5684e4c5637a9 Mon Sep 17 00:00:00 2001 From: Marek Szyprowski Date: Wed, 11 Oct 2017 11:25:12 +0200 Subject: clk: samsung: Add dt bindings for Exynos4412 ISP clock controller Some registers for the Exynos 4412 ISP (Camera subsystem) clocks are located in the ISP power domain. Because those registers are also located in a different memory region than the main clock controller, support for them can be provided by a separate clock controller. Signed-off-by: Marek Szyprowski Acked-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Sylwester Nawrocki --- .../devicetree/bindings/clock/exynos4-clock.txt | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index f5a5b19ed3b2..bc61c952cb0b 100644 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt @@ -41,3 +41,46 @@ Example 2: UART controller node that consumes the clock generated by the clock clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; clock-names = "uart", "clk_uart_baud0"; }; + +Exynos4412 SoC contains some additional clocks for FIMC-ISP (Camera ISP) +subsystem. Registers for those clocks are located in the ISP power domain. +Because those registers are also located in a different memory region than +the main clock controller, a separate clock controller has to be defined for +handling them. + +Required Properties: + +- compatible: should be "samsung,exynos4412-isp-clock". + +- reg: physical base address of the ISP clock controller and length of memory + mapped region. + +- #clock-cells: should be 1. + +- clocks: list of the clock controller input clock identifiers, + from common clock bindings, should point to CLK_ACLK200 and + CLK_ACLK400_MCUISP clocks from the main clock controller. + +- clock-names: list of the clock controller input clock names, + as described in clock-bindings.txt, should be "aclk200" and + "aclk400_mcuisp". + +- power-domains: a phandle to ISP power domain node as described by + generic PM domain bindings. + +Example 3: The clock controllers bindings for Exynos4412 SoCs. + + clock: clock-controller@10030000 { + compatible = "samsung,exynos4412-clock"; + reg = <0x10030000 0x18000>; + #clock-cells = <1>; + }; + + isp_clock: clock-controller@10048000 { + compatible = "samsung,exynos4412-isp-clock"; + reg = <0x10048000 0x1000>; + #clock-cells = <1>; + power-domains = <&pd_isp>; + clocks = <&clock CLK_ACLK200>, <&clock CLK_ACLK400_MCUISP>; + clock-names = "aclk200", "aclk400_mcuisp"; + }; -- cgit v1.2.3 From 503c3117d05c184b431e403cd05c463ac41370f0 Mon Sep 17 00:00:00 2001 From: Jan Kara Date: Mon, 16 Oct 2017 11:55:52 +0200 Subject: udf: Remove some outdate references from documentation Remove outdated references to maintainer and mailing list from the documentation - reference MAINTAINERS instead. Also update reference to current repository of udf-tools. Signed-off-by: Jan Kara --- Documentation/filesystems/udf.txt | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/udf.txt b/Documentation/filesystems/udf.txt index 902b95d0ee51..d3d0e3218f86 100644 --- a/Documentation/filesystems/udf.txt +++ b/Documentation/filesystems/udf.txt @@ -1,11 +1,9 @@ * * Documentation/filesystems/udf.txt * -UDF Filesystem version 0.9.8.1 If you encounter problems with reading UDF discs using this driver, -please report them to linux_udf@hpesjro.fc.hp.com, which is the -developer's list. +please report them according to MAINTAINERS file. Write support requires a block driver which supports writing. Currently dvd+rw drives and media support true random sector writes, and so a udf @@ -73,10 +71,8 @@ The following expect a offset from the partition root. For the latest version and toolset see: - http://linux-udf.sourceforge.net/ + https://github.com/pali/udftools Documentation on UDF and ECMA 167 is available FREE from: http://www.osta.org/ http://www.ecma-international.org/ - -Ben Fennema -- cgit v1.2.3 From 162d58c26d65e1486d18436eb151148a7f9886e5 Mon Sep 17 00:00:00 2001 From: Alexandre Torgue Date: Mon, 16 Oct 2017 13:45:58 +0200 Subject: ARM: dts: stm32: change pinctrl bindings definition Initially each pin was declared in "include/dt-bindings/stm32-pinfunc.h" and each definition contained SOC names (ex: STM32F429_PA9_FUNC_USART1_TX). Since this approach was approved, the number of supported MCU has increased (STM32F429/STM32F469/STM32f746/STM32H743). To avoid to add a new file in "include/dt-bindings" each time a new STM32 SOC arrives I propose a new approach which consist to use a macro to define pin muxing in device tree. All STM32 will use the common macro to define pinmux. Furthermore, it will make STM32 maintenance and integration of new SOC easier . Signed-off-by: Alexandre TORGUE Reviewed-by: Vikas MANOCHA Reviewed-by: Benjamin Gaignard Acked-by: Linus Walleij Acked-by: Rob Herring --- .../bindings/pinctrl/st,stm32-pinctrl.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt index 33e3d3c47552..58c2a4c229db 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt @@ -143,6 +143,24 @@ Required properties: * 16 : Alternate Function 15 * 17 : Analog + To simplify the usage, macro is available to generate "pinmux" field. + This macro is available here: + - include/dt-bindings/pinctrl/stm32-pinfunc.h + + Some examples of using macro: + /* GPIO A9 set as alernate function 2 */ + ... { + pinmux = ; + }; + /* GPIO A9 set as GPIO */ + ... { + pinmux = ; + }; + /* GPIO A9 set as analog */ + ... { + pinmux = ; + }; + Optional properties: - GENERIC_PINCONFIG: is the generic pinconfig options to use. Available options are: @@ -165,13 +183,13 @@ pin-controller { ... usart1_pins_a: usart1@0 { pins1 { - pinmux = ; + pinmux = ; bias-disable; drive-push-pull; slew-rate = <0>; }; pins2 { - pinmux = ; + pinmux = ; bias-disable; }; }; -- cgit v1.2.3 From fbe8749897710deffae4c77c1cdc34b31e2fc773 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Fri, 13 Oct 2017 11:01:46 +0200 Subject: pinctrl: dt-bindings: Fix A37xx uart2 group name Fix a typo in A37xx pin controllers documentation about uart2 pin group. Signed-off-by: Miquel Raynal Reviewed-by: Gregory CLEMENT Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt index f64060908d5a..c7c088d2dd50 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt @@ -97,8 +97,8 @@ group spi_quad - pins 15-16 - functions spi, gpio -group uart_2 - - pins 9-10 +group uart2 + - pins 9-10 and 18-19 - functions uart, gpio Available groups and functions for the South bridge: -- cgit v1.2.3 From 7ef3b44ceafb5456b7e43e2bd96e22bb696806c9 Mon Sep 17 00:00:00 2001 From: Jacob Chen Date: Wed, 11 Oct 2017 00:29:34 -0700 Subject: [media] dt-bindings: Document the Rockchip RGA bindings Add DT bindings documentation for Rockchip RGA Signed-off-by: Jacob Chen Signed-off-by: Yakir Yang Acked-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/rockchip-rga.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt b/Documentation/devicetree/bindings/media/rockchip-rga.txt new file mode 100644 index 000000000000..fd5276abfad6 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt @@ -0,0 +1,33 @@ +device-tree bindings for rockchip 2D raster graphic acceleration controller (RGA) + +RGA is a standalone 2D raster graphic acceleration unit. It accelerates 2D +graphics operations, such as point/line drawing, image scaling, rotation, +BitBLT, alpha blending and image blur/sharpness. + +Required properties: +- compatible: value should be one of the following + "rockchip,rk3288-rga"; + "rockchip,rk3399-rga"; + +- interrupts: RGA interrupt specifier. + +- clocks: phandle to RGA sclk/hclk/aclk clocks + +- clock-names: should be "aclk", "hclk" and "sclk" + +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: should be "core", "axi" and "ahb" + +Example: +SoC-specific DT entry: + rga: rga@ff680000 { + compatible = "rockchip,rk3399-rga"; + reg = <0xff680000 0x10000>; + interrupts = ; + clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru SCLK_RGA_CORE>; + clock-names = "aclk", "hclk", "sclk"; + + resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru SRST_H_RGA>; + reset-names = "core, "axi", "ahb"; + }; -- cgit v1.2.3 From defc3a47c53d54e933ecb923c064c36be4cf70e6 Mon Sep 17 00:00:00 2001 From: Hoegeun Kwon Date: Wed, 13 Sep 2017 04:41:52 -0700 Subject: media: exynos-gsc: Add compatible for Exynos 5250 and 5420 SoC version Exynos 5250 and 5420 have different hardware rotation limits. Since we have to distinguish between these two, we add different compatible: samsung,exynos5250-gsc and samsung,exynos5420-gsc. Signed-off-by: Hoegeun Kwon Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/exynos5-gsc.txt | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt b/Documentation/devicetree/bindings/media/exynos5-gsc.txt index 26ca25b6d264..0d4fdaedc6f1 100644 --- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt +++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt @@ -3,8 +3,11 @@ G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs. Required properties: -- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and - 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433) +- compatible: should be one of + "samsung,exynos5250-gsc" + "samsung,exynos5420-gsc" + "samsung,exynos5433-gsc" + "samsung,exynos5-gsc" (deprecated) - reg: should contain G-Scaler physical address location and length. - interrupts: should contain G-Scaler interrupt number @@ -15,7 +18,7 @@ Optional properties: Example: gsc_0: gsc@0x13e00000 { - compatible = "samsung,exynos5-gsc"; + compatible = "samsung,exynos5250-gsc"; reg = <0x13e00000 0x1000>; interrupts = <0 85 0>; }; -- cgit v1.2.3 From a197c7fccc0d8958ff73e323dcb1985c19d8166f Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Mon, 18 Sep 2017 01:15:53 -0700 Subject: media: dt: bindings: media: Document practices for DT bindings, ports, endpoints Port and endpoint numbering has been omitted in DT binding documentation for a large number of devices. Also common properties the device uses have been missed in binding documentation. Make it explicit that these things need to be documented. Signed-off-by: Sakari Ailus Acked-by: Rob Herring Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/video-interfaces.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 852041a7480c..bc8f18fb6730 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -55,6 +55,15 @@ divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width and data-shift properties can be used to assign physical data lines to each endpoint node (logical bus). +Documenting bindings for devices +-------------------------------- + +All required and optional bindings the device supports shall be explicitly +documented in device DT binding documentation. This also includes port and +endpoint nodes for the device, including unit-addresses and reg properties where +relevant. + +Please also see Documentation/devicetree/bindings/graph.txt . Required properties ------------------- -- cgit v1.2.3 From 7571358dd22dc91dea560f0dde62ce23c033b6b6 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Mon, 18 Sep 2017 01:20:59 -0700 Subject: media: dt: bindings: media: Document data lane numbering without lane reordering Most devices do not support lane reordering and in many cases the documentation of the data-lanes property is incomplete for such devices. Document that in case the lane reordering isn't supported, monotonically incremented values from 0 or 1 shall be used. Signed-off-by: Sakari Ailus Acked-by: Rob Herring Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/video-interfaces.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index bc8f18fb6730..bd6474920510 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -108,7 +108,10 @@ Optional endpoint properties determines the logical lane number, while the value of an entry indicates physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0. - This property is valid for serial busses only (e.g. MIPI CSI-2). + If the hardware does not support lane reordering, monotonically + incremented values shall be used from 0 or 1 onwards, depending on + whether or not there is also a clock lane. This property is valid for + serial busses only (e.g. MIPI CSI-2). - clock-lanes: an array of physical clock lane indexes. Position of an entry determines the logical lane number, while the value of an entry indicates physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;", -- cgit v1.2.3 From 4bb206bf4d8cbccaa2c2ee76168381f6c29a9e33 Mon Sep 17 00:00:00 2001 From: Jonathan Liu Date: Tue, 17 Oct 2017 20:17:59 +0800 Subject: drm/sun4i: tcon: Add support for A10 TCON The A10 has two TCONs that are similar to the ones found on other SoCs. Like the A31, TCON0 has a register used to mux the TCON outputs to the downstream encoders. The bit fields are slightly different. Signed-off-by: Jonathan Liu [wens@csie.org: Reworked for A10 and fixed up commit message] Signed-off-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-3-wens@csie.org --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 46df3b78ae9e..b2c08af73a95 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -86,6 +86,7 @@ The TCON acts as a timing controller for RGB, LVDS and TV interfaces. Required properties: - compatible: value must be either: + * allwinner,sun4i-a10-tcon * allwinner,sun5i-a13-tcon * allwinner,sun6i-a31-tcon * allwinner,sun6i-a31s-tcon -- cgit v1.2.3 From 7ea4291f9f1117d7f78b336629e8ff9d0c964919 Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Tue, 17 Oct 2017 20:18:00 +0800 Subject: drm/sun4i: hdmi: Support HDMI controller on A10 The HDMI controller in the A10 SoC is the same as the one currently supported in the A10s. It has slightly different setup parameters. Since these parameters are not thoroughly understood, we add support for this variant by copying these parameters verbatim. Signed-off-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-4-wens@csie.org --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index b2c08af73a95..5650efcfd2ac 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -40,6 +40,7 @@ CEC. It is one end of the pipeline. Required properties: - compatible: value must be one of: + * allwinner,sun4i-a10-hdmi * allwinner,sun5i-a10s-hdmi * allwinner,sun6i-a31-hdmi - reg: base address and size of memory-mapped region -- cgit v1.2.3 From 9a8187c00373bce839388574910f72711c9c4c33 Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Tue, 17 Oct 2017 20:18:01 +0800 Subject: drm/sun4i: Add support for A10 display pipeline components The A10 display pipeline has 2 frontends, 2 backends, and 2 TCONs. This patch adds support (or a compatible string in the frontend's case) for these components. The TCONs support directly outputting to CPU/RGB/LVDS LCD panels, or it can output to HDMI via an on-chip HDMI controller, or CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional encoders are not covered in this patch. Signed-off-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-5-wens@csie.org --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 5650efcfd2ac..8f9a58181f89 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -155,6 +155,7 @@ system. Required properties: - compatible: value must be one of: + * allwinner,sun4i-a10-display-backend * allwinner,sun5i-a13-display-backend * allwinner,sun6i-a31-display-backend * allwinner,sun8i-a33-display-backend @@ -187,6 +188,7 @@ deinterlacing and color space conversion. Required properties: - compatible: value must be one of: + * allwinner,sun4i-a10-display-frontend * allwinner,sun5i-a13-display-frontend * allwinner,sun6i-a31-display-frontend * allwinner,sun8i-a33-display-frontend @@ -233,6 +235,7 @@ extra node. Required properties: - compatible: value must be one of: + * allwinner,sun4i-a10-display-engine * allwinner,sun5i-a10s-display-engine * allwinner,sun5i-a13-display-engine * allwinner,sun6i-a31-display-engine -- cgit v1.2.3 From aaddb6d22a49923c5223a4703af7710c249503da Mon Sep 17 00:00:00 2001 From: Jonathan Liu Date: Tue, 17 Oct 2017 20:18:02 +0800 Subject: drm/sun4i: Add support for A20 display pipeline components The A20 display pipeline has 2 frontends, 2 backends, and 2 TCONs. This patch adds support (or a compatible string in the frontend's case) for these components. The TCONs support directly outputting to CPU/RGB/LVDS LCD panels, or it can output to HDMI via an on-chip HDMI controller, or CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional encoders are not covered in this patch. Signed-off-by: Jonathan Liu [wens@csie.org: Expand commit message] Signed-off-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-6-wens@csie.org --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 8f9a58181f89..013e76b348ba 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -91,6 +91,7 @@ Required properties: * allwinner,sun5i-a13-tcon * allwinner,sun6i-a31-tcon * allwinner,sun6i-a31s-tcon + * allwinner,sun7i-a20-tcon * allwinner,sun8i-a33-tcon * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region @@ -158,6 +159,7 @@ Required properties: * allwinner,sun4i-a10-display-backend * allwinner,sun5i-a13-display-backend * allwinner,sun6i-a31-display-backend + * allwinner,sun7i-a20-display-backend * allwinner,sun8i-a33-display-backend - reg: base address and size of the memory-mapped region. - interrupts: interrupt associated to this IP @@ -191,6 +193,7 @@ Required properties: * allwinner,sun4i-a10-display-frontend * allwinner,sun5i-a13-display-frontend * allwinner,sun6i-a31-display-frontend + * allwinner,sun7i-a20-display-frontend * allwinner,sun8i-a33-display-frontend - reg: base address and size of the memory-mapped region. - interrupts: interrupt associated to this IP @@ -240,6 +243,7 @@ Required properties: * allwinner,sun5i-a13-display-engine * allwinner,sun6i-a31-display-engine * allwinner,sun6i-a31s-display-engine + * allwinner,sun7i-a20-display-engine * allwinner,sun8i-a33-display-engine * allwinner,sun8i-v3s-display-engine -- cgit v1.2.3 From 18a3dde9db78076755275423b754846a2da000ad Mon Sep 17 00:00:00 2001 From: Vignesh R Date: Tue, 3 Oct 2017 10:49:20 +0530 Subject: mtd: spi-nor: cadence-quadspi: Add TI 66AK2G SoC specific compatible Update binding documentation to add a new compatible for TI 66AK2G SoC, to handle TI SoC specific quirks in the driver. Signed-off-by: Vignesh R Acked-by: Rob Herring Acked-by: Marek Vasut Signed-off-by: Cyrille Pitchen --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index f248056da24c..7dbe3bd9ac56 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -1,7 +1,9 @@ * Cadence Quad SPI controller Required properties: -- compatible : Should be "cdns,qspi-nor". +- compatible : should be one of the following: + Generic default - "cdns,qspi-nor". + For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- cgit v1.2.3 From 00df263560673cefe3341275990324730d4791d5 Mon Sep 17 00:00:00 2001 From: Vignesh R Date: Tue, 3 Oct 2017 10:49:22 +0530 Subject: mtd: spi-nor: cadence-quadspi: Add new binding to enable loop-back circuit Cadence QSPI IP has a adapted loop-back circuit which can be enabled by setting BYPASS field to 0 in READCAPTURE register. It enables use of QSPI return clock to latch the data rather than the internal QSPI reference clock. For high speed operations, adapted loop-back circuit using QSPI return clock helps to increase data valid window. Add DT parameter cdns,rclk-en to help enable adapted loop-back circuit for boards which do have QSPI return clock provided. Update binding documentation for the same. Signed-off-by: Vignesh R Acked-by: Rob Herring Acked-by: Marek Vasut Signed-off-by: Cyrille Pitchen --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index 7dbe3bd9ac56..bb2075df9b38 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -16,6 +16,9 @@ Required properties: Optional properties: - cdns,is-decoded-cs : Flag to indicate whether decoder is used or not. +- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch + the read data rather than the QSPI clock. Make sure that QSPI return + clock is populated on the board before using this property. Optional subnodes: Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional -- cgit v1.2.3 From 2ceec8be7d5c7c6b8f4e907c9d46ee3764c19016 Mon Sep 17 00:00:00 2001 From: Tom McLeod Date: Wed, 11 Oct 2017 11:57:50 -0700 Subject: dt-bindings: Add vendor prefix for Opal Kelly Inc Opal Kelly is a manufacturer of FPGA Integration Modules. Signed-off-by: Tom McLeod Cc: Rob Herring Cc: Mark Rutland Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 15c6b33f0b21..01500f2a399b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -247,6 +247,7 @@ olimex OLIMEX Ltd. onion Onion Corporation onnn ON Semiconductor Corp. ontat On Tat Industrial Company +opalkelly Opal Kelly Incorporated opencores OpenCores.org option Option NV ORCL Oracle Corporation -- cgit v1.2.3 From f2f5afd3845c88e96e863ae31f6a7587906af0e6 Mon Sep 17 00:00:00 2001 From: Divagar Mohandass Date: Tue, 10 Oct 2017 11:30:35 +0530 Subject: dt-bindings: add eeprom "size" property This adds eeprom "size" as optional property for i2c eeproms. The "size" property allows explicitly specifying the size of the EEPROM chip in bytes. Acked-by: Rob Herring Reviewed-by: Sakari Ailus Signed-off-by: Divagar Mohandass Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt index afc04589eadf..27f2bc15298a 100644 --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt @@ -36,6 +36,8 @@ Optional properties: - read-only: this parameterless property disables writes to the eeprom + - size: total eeprom size in bytes + Example: eeprom@52 { -- cgit v1.2.3 From 15e9833e22cc6e2f882639662b90eef02ef7583e Mon Sep 17 00:00:00 2001 From: Franklin S Cooper Jr Date: Mon, 11 Sep 2017 15:11:45 -0500 Subject: dt-bindings: i2c: i2c-davinci: Update binding for 66AK2Gx pwr dm property Add pm-domains property which is required for 66AK2Gx. Also document 66AK2G unique clocks property usage. Signed-off-by: Franklin S Cooper Jr Acked-by: Rob Herring Acked-by: Sekhar Nori Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-davinci.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt index 5b123e0e4cc2..64e6e656c345 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt @@ -6,6 +6,18 @@ davinci/keystone i2c interface contains. Required properties: - compatible: "ti,davinci-i2c" or "ti,keystone-i2c"; - reg : Offset and length of the register set for the device +- clocks: I2C functional clock phandle. + For 66AK2G this property should be set per binding, + Documentation/devicetree/bindings/clock/ti,sci-clk.txt + +SoC-specific Required Properties: + +The following are mandatory properties for Keystone 2 66AK2G SoCs only: + +- power-domains: Should contain a phandle to a PM domain provider node + and an args specifier containing the I2C device id + value. This property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt Recommended properties : - interrupts : standard interrupt property. -- cgit v1.2.3 From db6b78073ac135bb68cae77bb873371d0fe0efa6 Mon Sep 17 00:00:00 2001 From: Sergei Shtylyov Date: Fri, 13 Oct 2017 15:23:55 +0300 Subject: i2c: rcar: document R8A77970 bindings R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible I2C controller, so document the SoC specific bindings. Signed-off-by: Sergei Shtylyov Reviewed-by: Simon Horman Reviewed-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt index cad39aee9f73..a777477e4547 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt @@ -13,6 +13,7 @@ Required properties: "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC. "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC. "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC. + "renesas,i2c-r8a77970" if the device is a part of a R8A77970 SoC. "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device. "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible device. -- cgit v1.2.3 From 0290c4ca2536a35e55c53cfb9058465b1f987b17 Mon Sep 17 00:00:00 2001 From: Frank Rowand Date: Tue, 17 Oct 2017 16:36:23 -0700 Subject: of: overlay: rename identifiers to more reflect what they do This patch is aimed primarily at drivers/of/overlay.c, but those changes also have a small impact in a few other files. overlay.c is difficult to read and maintain. Improve readability: - Rename functions, types and variables to better reflect what they do and to be consistent with names in other places, such as the device tree overlay FDT (flattened device tree), and make the algorithms more clear - Use the same names consistently throughout the file - Update comments for name changes - Fix incorrect comments This patch is intended to not introduce any functional change. Signed-off-by: Frank Rowand Signed-off-by: Rob Herring --- Documentation/devicetree/overlay-notes.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/overlay-notes.txt b/Documentation/devicetree/overlay-notes.txt index eb7f2685fda1..c4aa0adf13ec 100644 --- a/Documentation/devicetree/overlay-notes.txt +++ b/Documentation/devicetree/overlay-notes.txt @@ -87,15 +87,15 @@ Overlay in-kernel API The API is quite easy to use. -1. Call of_overlay_create() to create and apply an overlay. The return value -is a cookie identifying this overlay. +1. Call of_overlay_apply() to create and apply an overlay changeset. The return +value is an error or a cookie identifying this overlay. -2. Call of_overlay_destroy() to remove and cleanup the overlay previously -created via the call to of_overlay_create(). Removal of an overlay that -is stacked by another will not be permitted. +2. Call of_overlay_remove() to remove and cleanup the overlay changeset +previously created via the call to of_overlay_apply(). Removal of an overlay +changeset that is stacked by another will not be permitted. Finally, if you need to remove all overlays in one-go, just call -of_overlay_destroy_all() which will remove every single one in the correct +of_overlay_remove_all() which will remove every single one in the correct order. Overlay DTS Format -- cgit v1.2.3 From 81a7bd4a3f4497af81694c017b5b91253009f8cb Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 17 Oct 2017 18:29:18 +0200 Subject: drm: some KMS todo ideas MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Inspired by discussions with Keith and Ville. Cc: Ville Syrjälä Cc: Keith Packard Acked-by: Sean Paul Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20171017162918.8380-1-daniel.vetter@ffwll.ch --- Documentation/gpu/todo.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 92ee2f982572..96f8ec7dbe4e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -304,6 +304,18 @@ There's a bunch of issues with it: Contact: Daniel Vetter +KMS cleanups +------------ + +Some of these date from the very introduction of KMS in 2008 ... + +- drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should + be renamed to drm_mode_config.object_idr. + +- drm_display_mode doesn't need to be derived from drm_mode_object. That's + leftovers from older (never merged into upstream) KMS designs where modes + where set using their ID, including support to add/remove modes. + Better Testing ============== -- cgit v1.2.3 From a68f4a27f55f1d54e35c270aff89383da4b1b656 Mon Sep 17 00:00:00 2001 From: David Howells Date: Wed, 18 Oct 2017 11:36:39 +0100 Subject: rxrpc: Support service upgrade from a kernel service Provide support for a kernel service to make use of the service upgrade facility. This involves: (1) Pass an upgrade request flag to rxrpc_kernel_begin_call(). (2) Make rxrpc_kernel_recv_data() return the call's current service ID so that the caller can detect service upgrade and see what the service was upgraded to. Signed-off-by: David Howells --- Documentation/networking/rxrpc.txt | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt index 810620153a44..9fb61a6bc7cf 100644 --- a/Documentation/networking/rxrpc.txt +++ b/Documentation/networking/rxrpc.txt @@ -782,7 +782,9 @@ The kernel interface functions are as follows: struct key *key, unsigned long user_call_ID, s64 tx_total_len, - gfp_t gfp); + gfp_t gfp, + rxrpc_notify_rx_t notify_rx, + bool upgrade); 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 @@ -803,6 +805,13 @@ The kernel interface functions are as follows: allows the kernel to encrypt directly to the packet buffers, thereby saving a copy. The value may not be less than -1. + notify_rx is a pointer to a function to be called when events such as + incoming data packets or remote aborts happen. + + upgrade should be set to true if a client operation should request that + the server upgrade the service to a better one. The resultant service ID + is returned by rxrpc_kernel_recv_data(). + 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. @@ -850,7 +859,8 @@ The kernel interface functions are as follows: size_t size, size_t *_offset, bool want_more, - u32 *_abort) + u32 *_abort, + u16 *_service) This is used to receive data from either the reply part of a client call or the request part of a service call. buf and size specify how much @@ -873,6 +883,9 @@ The kernel interface functions are as follows: If a remote ABORT is detected, the abort code received will be stored in *_abort and ECONNABORTED will be returned. + The service ID that the call ended up with is returned into *_service. + This can be used to see if a call got a service upgrade. + (*) Abort a call. void rxrpc_kernel_abort_call(struct socket *sock, -- cgit v1.2.3 From f4d15fb6f99af9b99f688bd87579137be44f85ee Mon Sep 17 00:00:00 2001 From: David Howells Date: Wed, 18 Oct 2017 11:07:31 +0100 Subject: rxrpc: Provide functions for allowing cleaner handling of signals Provide a couple of functions to allow cleaner handling of signals in a kernel service. They are: (1) rxrpc_kernel_get_rtt() This allows the kernel service to find out the RTT time for a call, so as to better judge how large a timeout to employ. Note, though, that whilst this returns a value in nanoseconds, the timeouts can only actually be in jiffies. (2) rxrpc_kernel_check_life() This returns a number that is updated when ACKs are received from the peer (notably including PING RESPONSE ACKs which we can elicit by sending PING ACKs to see if the call still exists on the server). The caller should compare the numbers of two calls to see if the call is still alive. These can be used to provide an extending timeout rather than returning immediately in the case that a signal occurs that would otherwise abort an RPC operation. The timeout would be extended if the server is still responsive and the call is still apparently alive on the server. For most operations this isn't that necessary - but for FS.StoreData it is: OpenAFS writes the data to storage as it comes in without making a backup, so if we immediately abort it when partially complete on a CTRL+C, say, we have no idea of the state of the file after the abort. Signed-off-by: David Howells --- Documentation/networking/rxrpc.txt | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt index 9fb61a6bc7cf..1fb5c553aedd 100644 --- a/Documentation/networking/rxrpc.txt +++ b/Documentation/networking/rxrpc.txt @@ -1033,6 +1033,30 @@ The kernel interface functions are as follows: It returns 0 if the call was requeued and an error otherwise. + (*) Get call RTT. + + u64 rxrpc_kernel_get_rtt(struct socket *sock, struct rxrpc_call *call); + + Get the RTT time to the peer in use by a call. The value returned is in + nanoseconds. + + (*) Check call still alive. + + u32 rxrpc_kernel_check_life(struct socket *sock, + struct rxrpc_call *call); + + This returns a number that is updated when ACKs are received from the peer + (notably including PING RESPONSE ACKs which we can elicit by sending PING + ACKs to see if the call still exists on the server). The caller should + compare the numbers of two calls to see if the call is still alive after + waiting for a suitable interval. + + This allows the caller to work out if the server is still contactable and + if the call is still alive on the server whilst waiting for the server to + process a client operation. + + This function may transmit a PING ACK. + ======================= CONFIGURABLE PARAMETERS -- cgit v1.2.3 From bc5e3a546d553e5223851fc199e69040eb70f68b Mon Sep 17 00:00:00 2001 From: David Howells Date: Wed, 18 Oct 2017 11:07:31 +0100 Subject: rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals Make AF_RXRPC accept MSG_WAITALL as a flag to sendmsg() to tell it to ignore signals whilst loading up the message queue, provided progress is being made in emptying the queue at the other side. Progress is defined as the base of the transmit window having being advanced within 2 RTT periods. If the period is exceeded with no progress, sendmsg() will return anyway, indicating how much data has been copied, if any. Once the supplied buffer is entirely decanted, the sendmsg() will return. Signed-off-by: David Howells --- Documentation/networking/rxrpc.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt index 1fb5c553aedd..b5407163d53b 100644 --- a/Documentation/networking/rxrpc.txt +++ b/Documentation/networking/rxrpc.txt @@ -280,6 +280,18 @@ Interaction with the user of the RxRPC socket: nominated by a socket option. +Notes on sendmsg: + + (*) MSG_WAITALL can be set to tell sendmsg to ignore signals if the peer is + making progress at accepting packets within a reasonable time such that we + manage to queue up all the data for transmission. This requires the + client to accept at least one packet per 2*RTT time period. + + If this isn't set, sendmsg() will return immediately, either returning + EINTR/ERESTARTSYS if nothing was consumed or returning the amount of data + consumed. + + Notes on recvmsg: (*) If there's a sequence of data messages belonging to a particular call on -- cgit v1.2.3 From 4b8b77a4ec807a5f14e02e84b1bb7a2fd43768c0 Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Thu, 22 Sep 2016 11:48:19 +0100 Subject: dt-bindings: Document devicetree binding for ARM SPE This patch documents the devicetree binding in use for ARM SPE. Cc: Rob Herring Acked-by: Mark Rutland Signed-off-by: Will Deacon --- Documentation/devicetree/bindings/arm/spe-pmu.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/spe-pmu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/spe-pmu.txt b/Documentation/devicetree/bindings/arm/spe-pmu.txt new file mode 100644 index 000000000000..93372f2a7df9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/spe-pmu.txt @@ -0,0 +1,20 @@ +* ARMv8.2 Statistical Profiling Extension (SPE) Performance Monitor Units (PMU) + +ARMv8.2 introduces the optional Statistical Profiling Extension for collecting +performance sample data using an in-memory trace buffer. + +** SPE Required properties: + +- compatible : should be one of: + "arm,statistical-profiling-extension-v1" + +- interrupts : Exactly 1 PPI must be listed. For heterogeneous systems where + SPE is only supported on a subset of the CPUs, please consult + the arm,gic-v3 binding for details on describing a PPI partition. + +** Example: + +spe-pmu { + compatible = "arm,statistical-profiling-extension-v1"; + interrupts = ; +}; -- cgit v1.2.3 From 28d1d6d2f314ff395ff67565d1145742614b21c8 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Wed, 18 Oct 2017 14:01:58 +0200 Subject: ALSA: hda - Add model string for Intel reference board quirk For allowing user to apply the existing quirk on a machine with a different SSID, add a new model string entry, alc700-ref. The quirk itself was introduced in the commit b84e843644f2: "ALSA: hda/realtek - Enable jack detection function for Intel ALC700") Signed-off-by: Takashi Iwai --- Documentation/sound/hd-audio/models.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/hd-audio/models.rst b/Documentation/sound/hd-audio/models.rst index 773d2bfacc6c..1fee5a4f6660 100644 --- a/Documentation/sound/hd-audio/models.rst +++ b/Documentation/sound/hd-audio/models.rst @@ -82,6 +82,8 @@ tpt460 Lenovo Thinkpad T460/560 setup dual-codecs Lenovo laptops with dual codecs +alc700-ref + Intel reference board with ALC700 codec ALC66x/67x/892 ============== -- cgit v1.2.3 From 686140a1a9c41d85a4212a1c26d671139b76404b Mon Sep 17 00:00:00 2001 From: Vasily Gorbik Date: Thu, 12 Oct 2017 13:01:47 +0200 Subject: s390: introduce CPU alternatives Implement CPU alternatives, which allows to optionally patch newer instructions at runtime, based on CPU facilities availability. A new kernel boot parameter "noaltinstr" disables patching. Current implementation is derived from x86 alternatives. Although ideal instructions padding (when altinstr is longer then oldinstr) is added at compile time, and no oldinstr nops optimization has to be done at runtime. Also couple of compile time sanity checks are done: 1. oldinstr and altinstr must be <= 254 bytes long, 2. oldinstr and altinstr must not have an odd length. alternative(oldinstr, altinstr, facility); alternative_2(oldinstr, altinstr1, facility1, altinstr2, facility2); Both compile time and runtime padding consists of either 6/4/2 bytes nop or a jump (brcl) + 2 bytes nop filler if padding is longer then 6 bytes. .altinstructions and .altinstr_replacement sections are part of __init_begin : __init_end region and are freed after initialization. Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 05496622b4ef..464f60c50c36 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2548,6 +2548,9 @@ noalign [KNL,ARM] + noaltinstr [S390] Disables alternative instructions patching + (CPU alternatives feature). + noapic [SMP,APIC] Tells the kernel to not make use of any IOAPICs that may be present in the system. -- cgit v1.2.3 From 904fb8e452b4a95490357841291fa523ad1d6442 Mon Sep 17 00:00:00 2001 From: Manikanta Maddireddy Date: Wed, 27 Sep 2017 17:28:34 +0530 Subject: dt-bindings: pci: tegra: Document Tegra186 PCIe DT Tegra186 PCIe controller DT properties has couple of differences wrt Tegra210 PCIe, rest of the DT properties are same. Tested-by: Mikko Perttunen Signed-off-by: Manikanta Maddireddy Signed-off-by: Bjorn Helgaas Reviewed-by: Mikko Perttunen Acked-by: Thierry Reding --- .../bindings/pci/nvidia,tegra20-pcie.txt | 134 ++++++++++++++++++++- 1 file changed, 130 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index 982a74ea6df9..33d2e2139333 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -1,10 +1,15 @@ NVIDIA Tegra PCIe controller Required properties: -- compatible: For Tegra20, must contain "nvidia,tegra20-pcie". For Tegra30, - "nvidia,tegra30-pcie". For Tegra124, must contain "nvidia,tegra124-pcie". - Otherwise, must contain "nvidia,-pcie", plus one of the above, where - is tegra132 or tegra210. +- compatible: Must be: + - "nvidia,tegra20-pcie": for Tegra20 + - "nvidia,tegra30-pcie": for Tegra30 + - "nvidia,tegra124-pcie": for Tegra124 and Tegra132 + - "nvidia,tegra210-pcie": for Tegra210 + - "nvidia,tegra186-pcie": for Tegra186 +- power-domains: To ungate power partition by BPMP powergate driver. Must + contain BPMP phandle and PCIe power partition ID. This is required only + for Tegra186. - device_type: Must be "pci" - reg: A list of physical base address and length for each set of controller registers. Must contain an entry for each entry in the reg-names property. @@ -124,6 +129,16 @@ Power supplies for Tegra210: - vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must supply 1.8 V. +Power supplies for Tegra186: +- Required: + - dvdd-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V. + - hvdd-pex-pll-supply: High-voltage supply for PLLE (shared with USB3). Must + supply 1.8 V. + - hvdd-pex-supply: High-voltage supply for PCIe I/O and PCIe output clocks. + Must supply 1.8 V. + - vddio-pexctl-aud-supply: Power supply for PCIe side band signals. Must + supply 1.8 V. + Root ports are defined as subnodes of the PCIe controller node. Required properties: @@ -546,3 +561,114 @@ Board DTS: status = "okay"; }; }; + +Tegra186: +--------- + +SoC DTSI: + + pcie@10003000 { + compatible = "nvidia,tegra186-pcie"; + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_PCX>; + device_type = "pci"; + reg = <0x0 0x10003000 0x0 0x00000800 /* PADS registers */ + 0x0 0x10003800 0x0 0x00000800 /* AFI registers */ + 0x0 0x40000000 0x0 0x10000000>; /* configuration space */ + reg-names = "pads", "afi", "cs"; + + interrupts = , /* controller interrupt */ + ; /* MSI interrupt */ + interrupt-names = "intr", "msi"; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; + + bus-range = <0x00 0xff>; + #address-cells = <3>; + #size-cells = <2>; + + ranges = <0x82000000 0 0x10000000 0x0 0x10000000 0 0x00001000 /* port 0 configuration space */ + 0x82000000 0 0x10001000 0x0 0x10001000 0 0x00001000 /* port 1 configuration space */ + 0x82000000 0 0x10004000 0x0 0x10004000 0 0x00001000 /* port 2 configuration space */ + 0x81000000 0 0x0 0x0 0x50000000 0 0x00010000 /* downstream I/O (64 KiB) */ + 0x82000000 0 0x50100000 0x0 0x50100000 0 0x07F00000 /* non-prefetchable memory (127 MiB) */ + 0xc2000000 0 0x58000000 0x0 0x58000000 0 0x28000000>; /* prefetchable memory (640 MiB) */ + + clocks = <&bpmp TEGRA186_CLK_AFI>, + <&bpmp TEGRA186_CLK_PCIE>, + <&bpmp TEGRA186_CLK_PLLE>; + clock-names = "afi", "pex", "pll_e"; + + resets = <&bpmp TEGRA186_RESET_AFI>, + <&bpmp TEGRA186_RESET_PCIE>, + <&bpmp TEGRA186_RESET_PCIEXCLK>; + reset-names = "afi", "pex", "pcie_x"; + + status = "disabled"; + + pci@1,0 { + device_type = "pci"; + assigned-addresses = <0x82000800 0 0x10000000 0 0x1000>; + reg = <0x000800 0 0 0 0>; + status = "disabled"; + + #address-cells = <3>; + #size-cells = <2>; + ranges; + + nvidia,num-lanes = <2>; + }; + + pci@2,0 { + device_type = "pci"; + assigned-addresses = <0x82001000 0 0x10001000 0 0x1000>; + reg = <0x001000 0 0 0 0>; + status = "disabled"; + + #address-cells = <3>; + #size-cells = <2>; + ranges; + + nvidia,num-lanes = <1>; + }; + + pci@3,0 { + device_type = "pci"; + assigned-addresses = <0x82001800 0 0x10004000 0 0x1000>; + reg = <0x001800 0 0 0 0>; + status = "disabled"; + + #address-cells = <3>; + #size-cells = <2>; + ranges; + + nvidia,num-lanes = <1>; + }; + }; + +Board DTS: + + pcie@10003000 { + status = "okay"; + + dvdd-pex-supply = <&vdd_pex>; + hvdd-pex-pll-supply = <&vdd_1v8>; + hvdd-pex-supply = <&vdd_1v8>; + vddio-pexctl-aud-supply = <&vdd_1v8>; + + pci@1,0 { + nvidia,num-lanes = <4>; + status = "okay"; + }; + + pci@2,0 { + nvidia,num-lanes = <0>; + status = "disabled"; + }; + + pci@3,0 { + nvidia,num-lanes = <1>; + status = "disabled"; + }; + }; -- cgit v1.2.3 From d950770f628d54f74f995d9ec495733ab2fe9e60 Mon Sep 17 00:00:00 2001 From: Stephen Hemminger Date: Wed, 18 Oct 2017 09:16:15 -0700 Subject: Documentation: add my name to supporters Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index 1e23d4227337..44c286b50e92 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -79,6 +79,7 @@ we might work for today, have in the past, or will in the future. - Juergen Gross - Shawn Guo - Ulf Hansson + - Stephen Hemminger (Microsoft) - Tejun Heo - Rob Herring - Masami Hiramatsu -- cgit v1.2.3 From e3aca5508d509363778bda04b1fd53731d809fce Mon Sep 17 00:00:00 2001 From: Eduardo Valentin Date: Tue, 17 Oct 2017 08:06:53 -0700 Subject: Documentation: update kernel enforcement support list Adding myself to the list as I missed the window to be in the original patch. Cc: Jonathan Corbet Cc: Bart Van Assche Cc: Namhyung Kim Cc: Olof Johansson Cc: Juergen Gross Cc: Javier Martinez Canillas Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index 44c286b50e92..e55c20f8e2d0 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -146,3 +146,4 @@ we might work for today, have in the past, or will in the future. - Masahiro Yamada - Wei Yongjun - Lv Zheng + - Eduardo Valentin -- cgit v1.2.3 From 3587cddfacf67cf50d288572453eb47ff2603575 Mon Sep 17 00:00:00 2001 From: Trond Myklebust Date: Wed, 18 Oct 2017 12:11:58 -0400 Subject: Add ack for Trond Myklebust to the enforcement statement Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index e55c20f8e2d0..b02c8cf8918f 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -117,6 +117,7 @@ we might work for today, have in the past, or will in the future. - David S. Miller - Ingo Molnar - Kuninori Morimoto + - Trond Myklebust - Borislav Petkov - Jiri Pirko - Josh Poimboeuf -- cgit v1.2.3 From 513a6f750b836dd17bb6fe69aa83be59557903f3 Mon Sep 17 00:00:00 2001 From: Dennis Dalessandro Date: Wed, 18 Oct 2017 12:34:54 -0700 Subject: Documentation: Sign kernel enforcement statement Add my name to the kernel enforcement statement as it is something I support speaking on my own behalf and not a statement of my current employer. Signed-off-by: Dennis Dalessandro Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index b02c8cf8918f..32b461f08f8b 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -67,6 +67,7 @@ we might work for today, have in the past, or will in the future. - Javier Martinez Canillas - Rob Clark - Jonathan Corbet + - Dennis Dalessandro - Vivien Didelot (Savoir-faire Linux) - Hans de Goede (Red Hat) - Mel Gorman (SUSE) -- cgit v1.2.3 From b4714784df6afdf90e8bb70c381110e4299fab40 Mon Sep 17 00:00:00 2001 From: Laura Abbott Date: Wed, 18 Oct 2017 16:20:47 -0700 Subject: Documentation: Add myself to the enforcement statement list I already Acked the patch, add my name to the list as well. Signed-off-by: Laura Abbott Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index 32b461f08f8b..421142690e7f 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -50,6 +50,7 @@ be stronger. Except where noted below, we speak only for ourselves, and not for any company we might work for today, have in the past, or will in the future. + - Laura Abbott - Bjorn Andersson (Linaro) - Andrea Arcangeli (Red Hat) - Neil Armstrong -- cgit v1.2.3 From 0f38672c629b79fa2b929d2c391bc063a08279eb Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Tue, 3 Oct 2017 20:09:14 +0900 Subject: usb: renesas_usbhs: add support for R-Car D3 This patch adds support for R-Car D3. This SoC needs to release the PLL reset by the UGCTRL register. So, since this is not the same as other R-Car Gen3 SoCs, this patch adds a new type as "USBHS_TYPE_RCAR_GEN3_WITH_PLL". Acked-by: Rob Herring Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index 9e18e000339e..e79f6e43061a 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -10,6 +10,7 @@ Required properties: - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device + - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device -- cgit v1.2.3 From 279d4bc6406022461713cd6a3e5411336d2ff26b Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Fri, 29 Sep 2017 20:45:01 +0900 Subject: usb: gadget: udc: renesas_usb3: add support for generic phy This patch adds support for generic phy as an optional. If you want to use a generic phy (e.g. phy-rcar-gen3-usb3 driver) on this driver, you have to do "insmod phy-rcar-gen3-usb3.ko" first for now. Acked-by: Rob Herring Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/renesas_usb3.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt b/Documentation/devicetree/bindings/usb/renesas_usb3.txt index e28025883b79..87a45e2f9b7f 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt @@ -15,6 +15,10 @@ Required properties: - interrupts: Interrupt specifier for the USB3.0 Peripheral - clocks: clock phandle and specifier pair +Optional properties: + - phys: phandle + phy specifier pair + - phy-names: must be "usb" + Example of R-Car H3 ES1.x: usb3_peri0: usb@ee020000 { compatible = "renesas,r8a7795-usb3-peri", -- cgit v1.2.3 From 000777dadc7e22d3656bc9f30dde2ba40d069a2f Mon Sep 17 00:00:00 2001 From: Amelie Delaunay Date: Thu, 17 Aug 2017 11:33:00 +0200 Subject: dt-bindings: usb: Document the STM32F7xx DWC2 USB OTG HS core binding This patch adds binding documentation for DWC2 controller in HS mode found on STMicroelectronics STM32F7xx SoC. Signed-off-by: Amelie Delaunay Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index fcf199b64d3d..e64d903bcbe8 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -19,6 +19,8 @@ Required properties: configured in FS mode; - "st,stm32f4x9-hsotg": The DWC2 USB HS controller instance in STM32F4x9 SoCs configured in HS mode; + - "st,stm32f7xx-hsotg": The DWC2 USB HS controller instance in STM32F7xx SoCs + configured in HS mode; - reg : Should contain 1 register range (address and length) - interrupts : Should contain 1 interrupt - clocks: clock provider specifier -- cgit v1.2.3 From 85a299d52766a60d3a1ce0dc168646656060fc89 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Fri, 13 Oct 2017 17:10:47 +0800 Subject: dt-bindings: usb: mtu3: add a optional property to disable u3ports Add a new optional property to disable u3ports Signed-off-by: Chunfeng Yun Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt index 49f54767cd21..7c611d14a0a0 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt @@ -44,6 +44,8 @@ Optional properties: - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup control register, it depends on "mediatek,enable-wakeup". + - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0, + bit1 for u3port1, ... etc; Sub-nodes: The xhci should be added as subnode to mtu3 as shown in the following example -- cgit v1.2.3 From fc3a41aa696ca588cde95ae348bce999bf08f234 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Fri, 13 Oct 2017 17:10:48 +0800 Subject: dt-bindings: usb: mtu3: remove dummy clocks and add optional ones Remove dummy clocks for usb wakeup and add optional ones for mcu_bus and dma_bus bus. Signed-off-by: Chunfeng Yun Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt index 7c611d14a0a0..49c982bb5bfc 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt @@ -14,9 +14,9 @@ Required properties: - vusb33-supply : regulator of USB avdd3.3v - clocks : a list of phandle + clock-specifier pairs, one for each entry in clock-names - - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller; - "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are - depends on "mediatek,enable-wakeup" + - clock-names : must contain "sys_ck" for clock of controller, + the following clocks are optional: + "ref_ck", "mcu_ck" and "dam_ck"; - phys : a list of phandle + phy specifier pairs - dr_mode : should be one of "host", "peripheral" or "otg", refer to usb/generic.txt @@ -65,9 +65,7 @@ ssusb: usb@11271000 { clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>, <&pericfg CLK_PERI_USB0>, <&pericfg CLK_PERI_USB1>; - clock-names = "sys_ck", "ref_ck", - "wakeup_deb_p0", - "wakeup_deb_p1"; + clock-names = "sys_ck", "ref_ck"; vusb33-supply = <&mt6397_vusb_reg>; vbus-supply = <&usb_p0_vbus>; extcon = <&extcon_usb>; -- cgit v1.2.3 From 32428aa22d08a1be660b571a0f71880e5a9dd926 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Fri, 13 Oct 2017 17:10:49 +0800 Subject: dt-bindings: usb: mtu3: remove optional pinctrls Remove optional pinctrls due to using FORCE/RG_IDDIG to implement manual switch function. Signed-off-by: Chunfeng Yun Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt index 49c982bb5bfc..b2271d8e6b50 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt @@ -30,9 +30,10 @@ Optional properties: when supports dual-role mode. - vbus-supply : reference to the VBUS regulator, needed when supports dual-role mode. - - pinctl-names : a pinctrl state named "default" must be defined, - "id_float" and "id_ground" are optinal which depends on - "mediatek,enable-manual-drd" + - pinctrl-names : a pinctrl state named "default" is optional, and need be + defined if auto drd switch is enabled, that means the property dr_mode + is set as "otg", and meanwhile the property "mediatek,enable-manual-drd" + is not set. - pinctrl-0 : pin control group See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt -- cgit v1.2.3 From e0d63c4083852e07655dfcda1320504c304218be Mon Sep 17 00:00:00 2001 From: Biju Das Date: Fri, 6 Oct 2017 17:49:34 +0100 Subject: usb: renesas_usbhs: Add compatible string for r8a7743/5 This patch adds support for r8a7743/5 SoCs. The Renesas RZ/G1[ME] (R8A7743/5) usbhs is identical to the R-Car Gen2 family. No driver change is needed due to the fallback compatible value "renesas,rcar-gen2-usbhs". Adding the SoC-specific compatible values here has two purposes: 1. Document which SoCs have this hardware module, 2. Allow checkpatch to validate compatible values. Acked-by: Rob Herring Acked-by: Simon Horman Signed-off-by: Biju Das Signed-off-by: Chris Paterson Reviewed-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index e79f6e43061a..47394ab788e3 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -3,6 +3,8 @@ Renesas Electronics USBHS driver Required properties: - compatible: Must contain one or more of the following: + - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device + - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device @@ -11,7 +13,7 @@ Required properties: - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device - - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device + - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device When compatible with the generic version, nodes must list the -- cgit v1.2.3 From 93862e385ded7c60351e09fcd2a541d273650905 Mon Sep 17 00:00:00 2001 From: Joe Lawrence Date: Fri, 13 Oct 2017 15:08:41 -0400 Subject: livepatch: add (un)patch callbacks Provide livepatch modules a klp_object (un)patching notification mechanism. Pre and post-(un)patch callbacks allow livepatch modules to setup or synchronize changes that would be difficult to support in only patched-or-unpatched code contexts. Callbacks can be registered for target module or vmlinux klp_objects, but each implementation is klp_object specific. - Pre-(un)patch callbacks run before any (un)patching transition starts. - Post-(un)patch callbacks run once an object has been (un)patched and the klp_patch fully transitioned to its target state. Example use cases include modification of global data and registration of newly available services/handlers. See Documentation/livepatch/callbacks.txt for details and samples/livepatch/ for examples. Signed-off-by: Joe Lawrence Acked-by: Josh Poimboeuf Acked-by: Miroslav Benes Signed-off-by: Jiri Kosina --- Documentation/livepatch/callbacks.txt | 605 ++++++++++++++++++++++++++++++++++ 1 file changed, 605 insertions(+) create mode 100644 Documentation/livepatch/callbacks.txt (limited to 'Documentation') diff --git a/Documentation/livepatch/callbacks.txt b/Documentation/livepatch/callbacks.txt new file mode 100644 index 000000000000..c9776f48e458 --- /dev/null +++ b/Documentation/livepatch/callbacks.txt @@ -0,0 +1,605 @@ +====================== +(Un)patching Callbacks +====================== + +Livepatch (un)patch-callbacks provide a mechanism for livepatch modules +to execute callback functions when a kernel object is (un)patched. They +can be considered a "power feature" that extends livepatching abilities +to include: + + - Safe updates to global data + + - "Patches" to init and probe functions + + - Patching otherwise unpatchable code (i.e. assembly) + +In most cases, (un)patch callbacks will need to be used in conjunction +with memory barriers and kernel synchronization primitives, like +mutexes/spinlocks, or even stop_machine(), to avoid concurrency issues. + +Callbacks differ from existing kernel facilities: + + - Module init/exit code doesn't run when disabling and re-enabling a + patch. + + - A module notifier can't stop a to-be-patched module from loading. + +Callbacks are part of the klp_object structure and their implementation +is specific to that klp_object. Other livepatch objects may or may not +be patched, irrespective of the target klp_object's current state. + +Callbacks can be registered for the following livepatch actions: + + * Pre-patch - before a klp_object is patched + + * Post-patch - after a klp_object has been patched and is active + across all tasks + + * Pre-unpatch - before a klp_object is unpatched (ie, patched code is + active), used to clean up post-patch callback + resources + + * Post-unpatch - after a klp_object has been patched, all code has + been restored and no tasks are running patched code, + used to cleanup pre-patch callback resources + +Each callback is optional, omitting one does not preclude specifying any +other. However, the livepatching core executes the handlers in +symmetry: pre-patch callbacks have a post-unpatch counterpart and +post-patch callbacks have a pre-unpatch counterpart. An unpatch +callback will only be executed if its corresponding patch callback was +executed. Typical use cases pair a patch handler that acquires and +configures resources with an unpatch handler tears down and releases +those same resources. + +A callback is only executed if its host klp_object is loaded. For +in-kernel vmlinux targets, this means that callbacks will always execute +when a livepatch is enabled/disabled. For patch target kernel modules, +callbacks will only execute if the target module is loaded. When a +module target is (un)loaded, its callbacks will execute only if the +livepatch module is enabled. + +The pre-patch callback, if specified, is expected to return a status +code (0 for success, -ERRNO on error). An error status code indicates +to the livepatching core that patching of the current klp_object is not +safe and to stop the current patching request. (When no pre-patch +callback is provided, the transition is assumed to be safe.) If a +pre-patch callback returns failure, the kernel's module loader will: + + - Refuse to load a livepatch, if the livepatch is loaded after + targeted code. + + or: + + - Refuse to load a module, if the livepatch was already successfully + loaded. + +No post-patch, pre-unpatch, or post-unpatch callbacks will be executed +for a given klp_object if the object failed to patch, due to a failed +pre_patch callback or for any other reason. + +If a patch transition is reversed, no pre-unpatch handlers will be run +(this follows the previously mentioned symmetry -- pre-unpatch callbacks +will only occur if their corresponding post-patch callback executed). + +If the object did successfully patch, but the patch transition never +started for some reason (e.g., if another object failed to patch), +only the post-unpatch callback will be called. + + +Example Use-cases +================= + +Update global data +------------------ + +A pre-patch callback can be useful to update a global variable. For +example, 75ff39ccc1bd ("tcp: make challenge acks less predictable") +changes a global sysctl, as well as patches the tcp_send_challenge_ack() +function. + +In this case, if we're being super paranoid, it might make sense to +patch the data *after* patching is complete with a post-patch callback, +so that tcp_send_challenge_ack() could first be changed to read +sysctl_tcp_challenge_ack_limit with READ_ONCE. + + +Support __init and probe function patches +----------------------------------------- + +Although __init and probe functions are not directly livepatch-able, it +may be possible to implement similar updates via pre/post-patch +callbacks. + +48900cb6af42 ("virtio-net: drop NETIF_F_FRAGLIST") change the way that +virtnet_probe() initialized its driver's net_device features. A +pre/post-patch callback could iterate over all such devices, making a +similar change to their hw_features value. (Client functions of the +value may need to be updated accordingly.) + + +Test cases +========== + +What follows is not an exhaustive test suite of every possible livepatch +pre/post-(un)patch combination, but a selection that demonstrates a few +important concepts. Each test case uses the kernel modules located in +the samples/livepatch/ and assumes that no livepatches are loaded at the +beginning of the test. + + +Test 1 +------ + +Test a combination of loading a kernel module and a livepatch that +patches a function in the first module. (Un)load the target module +before the livepatch module: + +- load target module +- load livepatch +- disable livepatch +- unload target module +- unload livepatch + +First load a target module: + + % insmod samples/livepatch/livepatch-callbacks-mod.ko + [ 34.475708] livepatch_callbacks_mod: livepatch_callbacks_mod_init + +On livepatch enable, before the livepatch transition starts, pre-patch +callbacks are executed for vmlinux and livepatch_callbacks_mod (those +klp_objects currently loaded). After klp_objects are patched according +to the klp_patch, their post-patch callbacks run and the transition +completes: + + % insmod samples/livepatch/livepatch-callbacks-demo.ko + [ 36.503719] livepatch: enabling patch 'livepatch_callbacks_demo' + [ 36.504213] livepatch: 'livepatch_callbacks_demo': initializing patching transition + [ 36.504238] livepatch_callbacks_demo: pre_patch_callback: vmlinux + [ 36.504721] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state + [ 36.505849] livepatch: 'livepatch_callbacks_demo': starting patching transition + [ 37.727133] livepatch: 'livepatch_callbacks_demo': completing patching transition + [ 37.727232] livepatch_callbacks_demo: post_patch_callback: vmlinux + [ 37.727860] livepatch_callbacks_demo: post_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state + [ 37.728792] livepatch: 'livepatch_callbacks_demo': patching complete + +Similarly, on livepatch disable, pre-patch callbacks run before the +unpatching transition starts. klp_objects are reverted, post-patch +callbacks execute and the transition completes: + + % echo 0 > /sys/kernel/livepatch/livepatch_callbacks_demo/enabled + [ 38.510209] livepatch: 'livepatch_callbacks_demo': initializing unpatching transition + [ 38.510234] livepatch_callbacks_demo: pre_unpatch_callback: vmlinux + [ 38.510982] livepatch_callbacks_demo: pre_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state + [ 38.512209] livepatch: 'livepatch_callbacks_demo': starting unpatching transition + [ 39.711132] livepatch: 'livepatch_callbacks_demo': completing unpatching transition + [ 39.711210] livepatch_callbacks_demo: post_unpatch_callback: vmlinux + [ 39.711779] livepatch_callbacks_demo: post_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state + [ 39.712735] livepatch: 'livepatch_callbacks_demo': unpatching complete + + % rmmod samples/livepatch/livepatch-callbacks-demo.ko + % rmmod samples/livepatch/livepatch-callbacks-mod.ko + [ 42.534183] livepatch_callbacks_mod: livepatch_callbacks_mod_exit + + +Test 2 +------ + +This test is similar to the previous test, but (un)load the livepatch +module before the target kernel module. This tests the livepatch core's +module_coming handler: + +- load livepatch +- load target module +- disable livepatch +- unload livepatch +- unload target module + + +On livepatch enable, only pre/post-patch callbacks are executed for +currently loaded klp_objects, in this case, vmlinux: + + % insmod samples/livepatch/livepatch-callbacks-demo.ko + [ 44.553328] livepatch: enabling patch 'livepatch_callbacks_demo' + [ 44.553997] livepatch: 'livepatch_callbacks_demo': initializing patching transition + [ 44.554049] livepatch_callbacks_demo: pre_patch_callback: vmlinux + [ 44.554845] livepatch: 'livepatch_callbacks_demo': starting patching transition + [ 45.727128] livepatch: 'livepatch_callbacks_demo': completing patching transition + [ 45.727212] livepatch_callbacks_demo: post_patch_callback: vmlinux + [ 45.727961] livepatch: 'livepatch_callbacks_demo': patching complete + +When a targeted module is subsequently loaded, only its pre/post-patch +callbacks are executed: + + % insmod samples/livepatch/livepatch-callbacks-mod.ko + [ 46.560845] livepatch: applying patch 'livepatch_callbacks_demo' to loading module 'livepatch_callbacks_mod' + [ 46.561988] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_COMING] Full formed, running module_init + [ 46.563452] livepatch_callbacks_demo: post_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_COMING] Full formed, running module_init + [ 46.565495] livepatch_callbacks_mod: livepatch_callbacks_mod_init + +On livepatch disable, all currently loaded klp_objects' (vmlinux and +livepatch_callbacks_mod) pre/post-unpatch callbacks are executed: + + % echo 0 > /sys/kernel/livepatch/livepatch_callbacks_demo/enabled + [ 48.568885] livepatch: 'livepatch_callbacks_demo': initializing unpatching transition + [ 48.568910] livepatch_callbacks_demo: pre_unpatch_callback: vmlinux + [ 48.569441] livepatch_callbacks_demo: pre_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state + [ 48.570502] livepatch: 'livepatch_callbacks_demo': starting unpatching transition + [ 49.759091] livepatch: 'livepatch_callbacks_demo': completing unpatching transition + [ 49.759171] livepatch_callbacks_demo: post_unpatch_callback: vmlinux + [ 49.759742] livepatch_callbacks_demo: post_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state + [ 49.760690] livepatch: 'livepatch_callbacks_demo': unpatching complete + + % rmmod samples/livepatch/livepatch-callbacks-demo.ko + % rmmod samples/livepatch/livepatch-callbacks-mod.ko + [ 52.592283] livepatch_callbacks_mod: livepatch_callbacks_mod_exit + + +Test 3 +------ + +Test loading the livepatch after a targeted kernel module, then unload +the kernel module before disabling the livepatch. This tests the +livepatch core's module_going handler: + +- load target module +- load livepatch +- unload target module +- disable livepatch +- unload livepatch + +First load a target module, then the livepatch: + + % insmod samples/livepatch/livepatch-callbacks-mod.ko + [ 54.607948] livepatch_callbacks_mod: livepatch_callbacks_mod_init + + % insmod samples/livepatch/livepatch-callbacks-demo.ko + [ 56.613919] livepatch: enabling patch 'livepatch_callbacks_demo' + [ 56.614411] livepatch: 'livepatch_callbacks_demo': initializing patching transition + [ 56.614436] livepatch_callbacks_demo: pre_patch_callback: vmlinux + [ 56.614818] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state + [ 56.615656] livepatch: 'livepatch_callbacks_demo': starting patching transition + [ 57.759070] livepatch: 'livepatch_callbacks_demo': completing patching transition + [ 57.759147] livepatch_callbacks_demo: post_patch_callback: vmlinux + [ 57.759621] livepatch_callbacks_demo: post_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state + [ 57.760307] livepatch: 'livepatch_callbacks_demo': patching complete + +When a target module is unloaded, the livepatch is only reverted from +that klp_object (livepatch_callbacks_mod). As such, only its pre and +post-unpatch callbacks are executed when this occurs: + + % rmmod samples/livepatch/livepatch-callbacks-mod.ko + [ 58.623409] livepatch_callbacks_mod: livepatch_callbacks_mod_exit + [ 58.623903] livepatch_callbacks_demo: pre_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_GOING] Going away + [ 58.624658] livepatch: reverting patch 'livepatch_callbacks_demo' on unloading module 'livepatch_callbacks_mod' + [ 58.625305] livepatch_callbacks_demo: post_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_GOING] Going away + +When the livepatch is disabled, pre and post-unpatch callbacks are run +for the remaining klp_object, vmlinux: + + % echo 0 > /sys/kernel/livepatch/livepatch_callbacks_demo/enabled + [ 60.638420] livepatch: 'livepatch_callbacks_demo': initializing unpatching transition + [ 60.638444] livepatch_callbacks_demo: pre_unpatch_callback: vmlinux + [ 60.638996] livepatch: 'livepatch_callbacks_demo': starting unpatching transition + [ 61.727088] livepatch: 'livepatch_callbacks_demo': completing unpatching transition + [ 61.727165] livepatch_callbacks_demo: post_unpatch_callback: vmlinux + [ 61.727985] livepatch: 'livepatch_callbacks_demo': unpatching complete + + % rmmod samples/livepatch/livepatch-callbacks-demo.ko + + +Test 4 +------ + +This test is similar to the previous test, however the livepatch is +loaded first. This tests the livepatch core's module_coming and +module_going handlers: + +- load livepatch +- load target module +- unload target module +- disable livepatch +- unload livepatch + +First load the livepatch: + + % insmod samples/livepatch/livepatch-callbacks-demo.ko + [ 64.661552] livepatch: enabling patch 'livepatch_callbacks_demo' + [ 64.662147] livepatch: 'livepatch_callbacks_demo': initializing patching transition + [ 64.662175] livepatch_callbacks_demo: pre_patch_callback: vmlinux + [ 64.662850] livepatch: 'livepatch_callbacks_demo': starting patching transition + [ 65.695056] livepatch: 'livepatch_callbacks_demo': completing patching transition + [ 65.695147] livepatch_callbacks_demo: post_patch_callback: vmlinux + [ 65.695561] livepatch: 'livepatch_callbacks_demo': patching complete + +When a targeted kernel module is subsequently loaded, only its +pre/post-patch callbacks are executed: + + % insmod samples/livepatch/livepatch-callbacks-mod.ko + [ 66.669196] livepatch: applying patch 'livepatch_callbacks_demo' to loading module 'livepatch_callbacks_mod' + [ 66.669882] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_COMING] Full formed, running module_init + [ 66.670744] livepatch_callbacks_demo: post_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_COMING] Full formed, running module_init + [ 66.672873] livepatch_callbacks_mod: livepatch_callbacks_mod_init + +When the target module is unloaded, the livepatch is only reverted from +the livepatch_callbacks_mod klp_object. As such, only pre and +post-unpatch callbacks are executed when this occurs: + + % rmmod samples/livepatch/livepatch-callbacks-mod.ko + [ 68.680065] livepatch_callbacks_mod: livepatch_callbacks_mod_exit + [ 68.680688] livepatch_callbacks_demo: pre_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_GOING] Going away + [ 68.681452] livepatch: reverting patch 'livepatch_callbacks_demo' on unloading module 'livepatch_callbacks_mod' + [ 68.682094] livepatch_callbacks_demo: post_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_GOING] Going away + + % echo 0 > /sys/kernel/livepatch/livepatch_callbacks_demo/enabled + [ 70.689225] livepatch: 'livepatch_callbacks_demo': initializing unpatching transition + [ 70.689256] livepatch_callbacks_demo: pre_unpatch_callback: vmlinux + [ 70.689882] livepatch: 'livepatch_callbacks_demo': starting unpatching transition + [ 71.711080] livepatch: 'livepatch_callbacks_demo': completing unpatching transition + [ 71.711481] livepatch_callbacks_demo: post_unpatch_callback: vmlinux + [ 71.711988] livepatch: 'livepatch_callbacks_demo': unpatching complete + + % rmmod samples/livepatch/livepatch-callbacks-demo.ko + + +Test 5 +------ + +A simple test of loading a livepatch without one of its patch target +klp_objects ever loaded (livepatch_callbacks_mod): + +- load livepatch +- disable livepatch +- unload livepatch + +Load the livepatch: + + % insmod samples/livepatch/livepatch-callbacks-demo.ko + [ 74.711081] livepatch: enabling patch 'livepatch_callbacks_demo' + [ 74.711595] livepatch: 'livepatch_callbacks_demo': initializing patching transition + [ 74.711639] livepatch_callbacks_demo: pre_patch_callback: vmlinux + [ 74.712272] livepatch: 'livepatch_callbacks_demo': starting patching transition + [ 75.743137] livepatch: 'livepatch_callbacks_demo': completing patching transition + [ 75.743219] livepatch_callbacks_demo: post_patch_callback: vmlinux + [ 75.743867] livepatch: 'livepatch_callbacks_demo': patching complete + +As expected, only pre/post-(un)patch handlers are executed for vmlinux: + + % echo 0 > /sys/kernel/livepatch/livepatch_callbacks_demo/enabled + [ 76.716254] livepatch: 'livepatch_callbacks_demo': initializing unpatching transition + [ 76.716278] livepatch_callbacks_demo: pre_unpatch_callback: vmlinux + [ 76.716666] livepatch: 'livepatch_callbacks_demo': starting unpatching transition + [ 77.727089] livepatch: 'livepatch_callbacks_demo': completing unpatching transition + [ 77.727194] livepatch_callbacks_demo: post_unpatch_callback: vmlinux + [ 77.727907] livepatch: 'livepatch_callbacks_demo': unpatching complete + + % rmmod samples/livepatch/livepatch-callbacks-demo.ko + + +Test 6 +------ + +Test a scenario where a vmlinux pre-patch callback returns a non-zero +status (ie, failure): + +- load target module +- load livepatch -ENODEV +- unload target module + +First load a target module: + + % insmod samples/livepatch/livepatch-callbacks-mod.ko + [ 80.740520] livepatch_callbacks_mod: livepatch_callbacks_mod_init + +Load the livepatch module, setting its 'pre_patch_ret' value to -19 +(-ENODEV). When its vmlinux pre-patch callback executed, this status +code will propagate back to the module-loading subsystem. The result is +that the insmod command refuses to load the livepatch module: + + % insmod samples/livepatch/livepatch-callbacks-demo.ko pre_patch_ret=-19 + [ 82.747326] livepatch: enabling patch 'livepatch_callbacks_demo' + [ 82.747743] livepatch: 'livepatch_callbacks_demo': initializing patching transition + [ 82.747767] livepatch_callbacks_demo: pre_patch_callback: vmlinux + [ 82.748237] livepatch: pre-patch callback failed for object 'vmlinux' + [ 82.748637] livepatch: failed to enable patch 'livepatch_callbacks_demo' + [ 82.749059] livepatch: 'livepatch_callbacks_demo': canceling transition, going to unpatch + [ 82.749060] livepatch: 'livepatch_callbacks_demo': completing unpatching transition + [ 82.749868] livepatch: 'livepatch_callbacks_demo': unpatching complete + [ 82.765809] insmod: ERROR: could not insert module samples/livepatch/livepatch-callbacks-demo.ko: No such device + + % rmmod samples/livepatch/livepatch-callbacks-mod.ko + [ 84.774238] livepatch_callbacks_mod: livepatch_callbacks_mod_exit + + +Test 7 +------ + +Similar to the previous test, setup a livepatch such that its vmlinux +pre-patch callback returns success. However, when a targeted kernel +module is later loaded, have the livepatch return a failing status code: + +- load livepatch +- setup -ENODEV +- load target module +- disable livepatch +- unload livepatch + +Load the livepatch, notice vmlinux pre-patch callback succeeds: + + % insmod samples/livepatch/livepatch-callbacks-demo.ko + [ 86.787845] livepatch: enabling patch 'livepatch_callbacks_demo' + [ 86.788325] livepatch: 'livepatch_callbacks_demo': initializing patching transition + [ 86.788427] livepatch_callbacks_demo: pre_patch_callback: vmlinux + [ 86.788821] livepatch: 'livepatch_callbacks_demo': starting patching transition + [ 87.711069] livepatch: 'livepatch_callbacks_demo': completing patching transition + [ 87.711143] livepatch_callbacks_demo: post_patch_callback: vmlinux + [ 87.711886] livepatch: 'livepatch_callbacks_demo': patching complete + +Set a trap so subsequent pre-patch callbacks to this livepatch will +return -ENODEV: + + % echo -19 > /sys/module/livepatch_callbacks_demo/parameters/pre_patch_ret + +The livepatch pre-patch callback for subsequently loaded target modules +will return failure, so the module loader refuses to load the kernel +module. Notice that no post-patch or pre/post-unpatch callbacks are +executed for this klp_object: + + % insmod samples/livepatch/livepatch-callbacks-mod.ko + [ 90.796976] livepatch: applying patch 'livepatch_callbacks_demo' to loading module 'livepatch_callbacks_mod' + [ 90.797834] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_COMING] Full formed, running module_init + [ 90.798900] livepatch: pre-patch callback failed for object 'livepatch_callbacks_mod' + [ 90.799652] livepatch: patch 'livepatch_callbacks_demo' failed for module 'livepatch_callbacks_mod', refusing to load module 'livepatch_callbacks_mod' + [ 90.819737] insmod: ERROR: could not insert module samples/livepatch/livepatch-callbacks-mod.ko: No such device + +However, pre/post-unpatch callbacks run for the vmlinux klp_object: + + % echo 0 > /sys/kernel/livepatch/livepatch_callbacks_demo/enabled + [ 92.823547] livepatch: 'livepatch_callbacks_demo': initializing unpatching transition + [ 92.823573] livepatch_callbacks_demo: pre_unpatch_callback: vmlinux + [ 92.824331] livepatch: 'livepatch_callbacks_demo': starting unpatching transition + [ 93.727128] livepatch: 'livepatch_callbacks_demo': completing unpatching transition + [ 93.727327] livepatch_callbacks_demo: post_unpatch_callback: vmlinux + [ 93.727861] livepatch: 'livepatch_callbacks_demo': unpatching complete + + % rmmod samples/livepatch/livepatch-callbacks-demo.ko + + +Test 8 +------ + +Test loading multiple targeted kernel modules. This test-case is +mainly for comparing with the next test-case. + +- load busy target module (0s sleep), +- load livepatch +- load target module +- unload target module +- disable livepatch +- unload livepatch +- unload busy target module + + +Load a target "busy" kernel module which kicks off a worker function +that immediately exits: + + % insmod samples/livepatch/livepatch-callbacks-busymod.ko sleep_secs=0 + [ 96.910107] livepatch_callbacks_busymod: livepatch_callbacks_mod_init + [ 96.910600] livepatch_callbacks_busymod: busymod_work_func, sleeping 0 seconds ... + [ 96.913024] livepatch_callbacks_busymod: busymod_work_func exit + +Proceed with loading the livepatch and another ordinary target module, +notice that the post-patch callbacks are executed and the transition +completes quickly: + + % insmod samples/livepatch/livepatch-callbacks-demo.ko + [ 98.917892] livepatch: enabling patch 'livepatch_callbacks_demo' + [ 98.918426] livepatch: 'livepatch_callbacks_demo': initializing patching transition + [ 98.918453] livepatch_callbacks_demo: pre_patch_callback: vmlinux + [ 98.918955] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_busymod -> [MODULE_STATE_LIVE] Normal state + [ 98.923835] livepatch: 'livepatch_callbacks_demo': starting patching transition + [ 99.743104] livepatch: 'livepatch_callbacks_demo': completing patching transition + [ 99.743156] livepatch_callbacks_demo: post_patch_callback: vmlinux + [ 99.743679] livepatch_callbacks_demo: post_patch_callback: livepatch_callbacks_busymod -> [MODULE_STATE_LIVE] Normal state + [ 99.744616] livepatch: 'livepatch_callbacks_demo': patching complete + + % insmod samples/livepatch/livepatch-callbacks-mod.ko + [ 100.930955] livepatch: applying patch 'livepatch_callbacks_demo' to loading module 'livepatch_callbacks_mod' + [ 100.931668] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_COMING] Full formed, running module_init + [ 100.932645] livepatch_callbacks_demo: post_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_COMING] Full formed, running module_init + [ 100.934125] livepatch_callbacks_mod: livepatch_callbacks_mod_init + + % rmmod samples/livepatch/livepatch-callbacks-mod.ko + [ 102.942805] livepatch_callbacks_mod: livepatch_callbacks_mod_exit + [ 102.943640] livepatch_callbacks_demo: pre_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_GOING] Going away + [ 102.944585] livepatch: reverting patch 'livepatch_callbacks_demo' on unloading module 'livepatch_callbacks_mod' + [ 102.945455] livepatch_callbacks_demo: post_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_GOING] Going away + + % echo 0 > /sys/kernel/livepatch/livepatch_callbacks_demo/enabled + [ 104.953815] livepatch: 'livepatch_callbacks_demo': initializing unpatching transition + [ 104.953838] livepatch_callbacks_demo: pre_unpatch_callback: vmlinux + [ 104.954431] livepatch_callbacks_demo: pre_unpatch_callback: livepatch_callbacks_busymod -> [MODULE_STATE_LIVE] Normal state + [ 104.955426] livepatch: 'livepatch_callbacks_demo': starting unpatching transition + [ 106.719073] livepatch: 'livepatch_callbacks_demo': completing unpatching transition + [ 106.722633] livepatch_callbacks_demo: post_unpatch_callback: vmlinux + [ 106.723282] livepatch_callbacks_demo: post_unpatch_callback: livepatch_callbacks_busymod -> [MODULE_STATE_LIVE] Normal state + [ 106.724279] livepatch: 'livepatch_callbacks_demo': unpatching complete + + % rmmod samples/livepatch/livepatch-callbacks-demo.ko + % rmmod samples/livepatch/livepatch-callbacks-busymod.ko + [ 108.975660] livepatch_callbacks_busymod: livepatch_callbacks_mod_exit + + +Test 9 +------ + +A similar test as the previous one, but force the "busy" kernel module +to do longer work. + +The livepatching core will refuse to patch a task that is currently +executing a to-be-patched function -- the consistency model stalls the +current patch transition until this safety-check is met. Test a +scenario where one of a livepatch's target klp_objects sits on such a +function for a long time. Meanwhile, load and unload other target +kernel modules while the livepatch transition is in progress. + +- load busy target module (30s sleep) +- load livepatch +- load target module +- unload target module +- disable livepatch +- unload livepatch +- unload busy target module + + +Load the "busy" kernel module, this time make it do 30 seconds worth of +work: + + % insmod samples/livepatch/livepatch-callbacks-busymod.ko sleep_secs=30 + [ 110.993362] livepatch_callbacks_busymod: livepatch_callbacks_mod_init + [ 110.994059] livepatch_callbacks_busymod: busymod_work_func, sleeping 30 seconds ... + +Meanwhile, the livepatch is loaded. Notice that the patch transition +does not complete as the targeted "busy" module is sitting on a +to-be-patched function: + + % insmod samples/livepatch/livepatch-callbacks-demo.ko + [ 113.000309] livepatch: enabling patch 'livepatch_callbacks_demo' + [ 113.000764] livepatch: 'livepatch_callbacks_demo': initializing patching transition + [ 113.000791] livepatch_callbacks_demo: pre_patch_callback: vmlinux + [ 113.001289] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_busymod -> [MODULE_STATE_LIVE] Normal state + [ 113.005208] livepatch: 'livepatch_callbacks_demo': starting patching transition + +Load a second target module (this one is an ordinary idle kernel +module). Note that *no* post-patch callbacks will be executed while the +livepatch is still in transition: + + % insmod samples/livepatch/livepatch-callbacks-mod.ko + [ 115.012740] livepatch: applying patch 'livepatch_callbacks_demo' to loading module 'livepatch_callbacks_mod' + [ 115.013406] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_COMING] Full formed, running module_init + [ 115.015315] livepatch_callbacks_mod: livepatch_callbacks_mod_init + +Request an unload of the simple kernel module. The patch is still +transitioning, so its pre-unpatch callbacks are skipped: + + % rmmod samples/livepatch/livepatch-callbacks-mod.ko + [ 117.022626] livepatch_callbacks_mod: livepatch_callbacks_mod_exit + [ 117.023376] livepatch: reverting patch 'livepatch_callbacks_demo' on unloading module 'livepatch_callbacks_mod' + [ 117.024533] livepatch_callbacks_demo: post_unpatch_callback: livepatch_callbacks_mod -> [MODULE_STATE_GOING] Going away + +Finally the livepatch is disabled. Since none of the patch's +klp_object's post-patch callbacks executed, the remaining klp_object's +pre-unpatch callbacks are skipped: + + % echo 0 > /sys/kernel/livepatch/livepatch_callbacks_demo/enabled + [ 119.035408] livepatch: 'livepatch_callbacks_demo': reversing transition from patching to unpatching + [ 119.035485] livepatch: 'livepatch_callbacks_demo': starting unpatching transition + [ 119.711166] livepatch: 'livepatch_callbacks_demo': completing unpatching transition + [ 119.714179] livepatch_callbacks_demo: post_unpatch_callback: vmlinux + [ 119.714653] livepatch_callbacks_demo: post_unpatch_callback: livepatch_callbacks_busymod -> [MODULE_STATE_LIVE] Normal state + [ 119.715437] livepatch: 'livepatch_callbacks_demo': unpatching complete + + % rmmod samples/livepatch/livepatch-callbacks-demo.ko + % rmmod samples/livepatch/livepatch-callbacks-busymod.ko + [ 141.279111] livepatch_callbacks_busymod: busymod_work_func exit + [ 141.279760] livepatch_callbacks_busymod: livepatch_callbacks_mod_exit -- cgit v1.2.3 From 06e733e41f87d75a60347b0c93a18fc0104d709d Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Wed, 18 Oct 2017 19:22:40 +0200 Subject: drm/panel: simple: add Toshiba LT089AC19000 Only exposes a single mode and not a complete display timing, as the datasheet is rather vague about the minimum/maximum values. Signed-off-by: Lucas Stach Acked-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20171018172240.8772-1-l.stach@pengutronix.de --- .../devicetree/bindings/display/panel/toshiba,lt089ac29000.txt | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt new file mode 100644 index 000000000000..4c0caaf246c9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt @@ -0,0 +1,8 @@ +Toshiba 8.9" WXGA (1280x768) TFT LCD panel + +Required properties: +- compatible: should be "toshiba,lt089ac29000.txt" +- power-supply: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.2.3 From bea173e5acd73d536dd234b34328cd52c1cadaab Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 6 Oct 2017 13:51:32 +0200 Subject: dt-bindings: irqchip: renesas-irqc: Document R-Car M3-W, V3M, D3 support Document support for the Interrupt Controller for Externel Devices (INTC-EX) in the Renesas M3-W (r8a7796), V3M (r8a77970), and D3 (r8a77995) SoCs. No driver update is needed. Reviewed-by: Simon Horman Signed-off-by: Geert Uytterhoeven Signed-off-by: Marc Zyngier --- .../devicetree/bindings/interrupt-controller/renesas,irqc.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt index e3f052d8c11a..33c9a10fdc91 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt @@ -13,6 +13,9 @@ Required properties: - "renesas,irqc-r8a7793" (R-Car M2-N) - "renesas,irqc-r8a7794" (R-Car E2) - "renesas,intc-ex-r8a7795" (R-Car H3) + - "renesas,intc-ex-r8a7796" (R-Car M3-W) + - "renesas,intc-ex-r8a77970" (R-Car V3M) + - "renesas,intc-ex-r8a77995" (R-Car D3) - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in interrupts.txt in this directory - clocks: Must contain a reference to the functional clock. -- cgit v1.2.3 From c0ca7262088ebab67452a39f27979d3faa4762f0 Mon Sep 17 00:00:00 2001 From: Doug Berger Date: Mon, 18 Sep 2017 18:00:00 -0700 Subject: irqchip/brcmstb-l2: Add support for the BCM7271 L2 controller Add the initialization of the generic irq chip for the BCM7271 L2 interrupt controller. This controller only supports level interrupts and uses the "brcm,bcm7271-l2-intc" compatibility string. Acked-by: Rob Herring Reviewed-by: Florian Fainelli Signed-off-by: Doug Berger Signed-off-by: Marc Zyngier --- .../devicetree/bindings/interrupt-controller/brcm,l2-intc.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt index 448273a30a11..36df06c5c567 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt @@ -2,7 +2,8 @@ Broadcom Generic Level 2 Interrupt Controller Required properties: -- compatible: should be "brcm,l2-intc" +- compatible: should be "brcm,l2-intc" for latched interrupt controllers + should be "brcm,bcm7271-l2-intc" for level interrupt controllers - reg: specifies the base physical address and size of the registers - interrupt-controller: identifies the node as an interrupt controller - #interrupt-cells: specifies the number of cells needed to encode an -- cgit v1.2.3 From 1000cec2f02263e081e7ad559da5e03329aab58a Mon Sep 17 00:00:00 2001 From: Yixun Lan Date: Sat, 14 Oct 2017 07:13:12 +0800 Subject: dt-bindings: arm: amlogic: Add Meson AXG binding MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Introduce new bindings for the Meson AXG SoC which now have different memory layout. Signed-off-by: Yixun Lan Reviewed-by: Andreas Färber Reviewed-by: Neil Armstrong Reviewed-by: Kevin Hilman Acked-by: Rob Herring Signed-off-by: Kevin Hilman --- Documentation/devicetree/bindings/arm/amlogic.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt index da379880abb6..f747f47922c5 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.txt +++ b/Documentation/devicetree/bindings/arm/amlogic.txt @@ -41,6 +41,10 @@ Boards with the Amlogic Meson GXM S912 SoC shall have the following properties: Required root node property: compatible: "amlogic,s912", "amlogic,meson-gxm"; +Boards with the Amlogic Meson AXG A113D SoC shall have the following properties: + Required root node property: + compatible: "amlogic,a113d", "amlogic,meson-axg"; + Board compatible values (alphabetically, grouped by SoC): - "geniatech,atv1200" (Meson6) @@ -76,6 +80,8 @@ Board compatible values (alphabetically, grouped by SoC): - "nexbox,a1" (Meson gxm s912) - "tronsmart,vega-s96" (Meson gxm s912) + - "amlogic,s400" (Meson axg a113d) + Amlogic Meson Firmware registers Interface ------------------------------------------ -- cgit v1.2.3 From 558b01654d92332d3b7b17bf773cdce8ce16ef46 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel Date: Tue, 17 Oct 2017 17:55:56 +0100 Subject: irqchip/gic-v3: Add workaround for Synquacer pre-ITS The Socionext Synquacer SoC's implementation of GICv3 has a so-called 'pre-ITS', which maps 32-bit writes targeted at a separate window of size '4 << device_id_bits' onto writes to GITS_TRANSLATER with device ID taken from bits [device_id_bits + 1:2] of the window offset. Writes that target GITS_TRANSLATER directly are reported as originating from device ID #0. So add a workaround for this. Given that this breaks isolation, clear the IRQ_DOMAIN_FLAG_MSI_REMAP flag as well. Acked-by: Rob Herring Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier --- Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt index 4c29cdab0ea5..c3e6092f3add 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt @@ -75,6 +75,10 @@ These nodes must have the following properties: - reg: Specifies the base physical address and size of the ITS registers. +Optional: +- socionext,synquacer-pre-its: (u32, u32) tuple describing the untranslated + address and size of the pre-ITS window. + The main GIC node must contain the appropriate #address-cells, #size-cells and ranges properties for the reg property of all ITS nodes. -- cgit v1.2.3 From 5c9a882e940dde2f3e80eb3c7635a3307be511b6 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Fri, 28 Jul 2017 21:20:37 +0100 Subject: irqchip/gic-v3-its: Workaround HiSilicon Hip07 redistributor addressing The ITSes on the Hip07 (as present in the Huawei D05) are broken when it comes to addressing the redistributors, and need to be explicitely told to address the VLPI page instead of the redistributor base address. So let's add yet another quirk, fixing up the target address in the command stream. Signed-off-by: Marc Zyngier --- Documentation/arm64/silicon-errata.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt index 66e8ce14d23d..304bf22bb83c 100644 --- a/Documentation/arm64/silicon-errata.txt +++ b/Documentation/arm64/silicon-errata.txt @@ -70,6 +70,7 @@ stable kernels. | | | | | | Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 | | Hisilicon | Hip0{6,7} | #161010701 | N/A | +| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 | | | | | | | Qualcomm Tech. | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 | | Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 | -- cgit v1.2.3 From df48d3b5ef276998e399846db12c241e6f9d318c Mon Sep 17 00:00:00 2001 From: Jerome Brunet Date: Mon, 18 Sep 2017 15:46:09 +0200 Subject: dt-bindings: interrupt-controller: Add DT binding for meson GPIO interrupt controller This commit adds the device tree bindings description for Amlogic's GPIO interrupt controller available on the meson8b, gxbb and gxl SoC families Cc: Heiner Kallweit Acked-by: Rob Herring Signed-off-by: Jerome Brunet Signed-off-by: Marc Zyngier --- .../amlogic,meson-gpio-intc.txt | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt new file mode 100644 index 000000000000..633e21ce4b17 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt @@ -0,0 +1,35 @@ +Amlogic meson GPIO interrupt controller + +Meson SoCs contains an interrupt controller which is able to watch the SoC +pads and generate an interrupt on edge or level. The controller is essentially +a 256 pads to 8 GIC interrupt multiplexer, with a filter block to select edge +or level and polarity. It does not expose all 256 mux inputs because the +documentation shows that the upper part is not mapped to any pad. The actual +number of interrupt exposed depends on the SoC. + +Required properties: + +- compatible : must have "amlogic,meson8-gpio-intc” and either + “amlogic,meson8b-gpio-intc” for meson8b SoCs (S805) or + “amlogic,meson-gxbb-gpio-intc” for GXBB SoCs (S905) or + “amlogic,meson-gxl-gpio-intc” for GXL SoCs (S905X, S912) +- interrupt-parent : a phandle to the GIC the interrupts are routed to. + Usually this is provided at the root level of the device tree as it is + common to most of the SoC. +- reg : Specifies base physical address and size of the registers. +- interrupt-controller : Identifies the node as an interrupt controller. +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The value must be 2. +- meson,channel-interrupts: Array with the 8 upstream hwirq numbers. These + are the hwirqs used on the parent interrupt controller. + +Example: + +gpio_interrupt: interrupt-controller@9880 { + compatible = "amlogic,meson-gxbb-gpio-intc", + "amlogic,meson-gpio-intc"; + reg = <0x0 0x9880 0x0 0x10>; + interrupt-controller; + #interrupt-cells = <2>; + meson,channel-interrupts = <64 65 66 67 68 69 70 71>; +}; -- cgit v1.2.3 From 3e09b155d58e44e33a699650128f8c6c833cb320 Mon Sep 17 00:00:00 2001 From: Mikko Perttunen Date: Mon, 24 Jul 2017 19:29:15 +0300 Subject: dt-bindings: Add bindings for nvidia,tegra186-bpmp-thermal In Tegra186, the BPMP (Boot and Power Management Processor) implements an interface that is used to read system temperatures, including CPU cluster and GPU temperatures. This binding describes the thermal sensor that is exposed by BPMP. Signed-off-by: Mikko Perttunen Acked-by: Rob Herring Signed-off-by: Thierry Reding --- .../thermal/nvidia,tegra186-bpmp-thermal.txt | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt new file mode 100644 index 000000000000..276387dd6815 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt @@ -0,0 +1,32 @@ +NVIDIA Tegra186 BPMP thermal sensor + +In Tegra186, the BPMP (Boot and Power Management Processor) implements an +interface that is used to read system temperatures, including CPU cluster +and GPU temperatures. This binding describes the thermal sensor that is +exposed by BPMP. + +The BPMP thermal node must be located directly inside the main BPMP node. See +../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding. + +This node represents a thermal sensor. See thermal.txt for details of the +core thermal binding. + +Required properties: +- compatible: + Array of strings. + One of: + - "nvidia,tegra186-bpmp-thermal". +- #thermal-sensor-cells: Cell for sensor index. + Single-cell integer. + Must be <1>. + +Example: + +bpmp { + ... + + bpmp_thermal: thermal { + compatible = "nvidia,tegra186-bpmp-thermal"; + #thermal-sensor-cells = <1>; + }; +}; -- cgit v1.2.3 From 3125b5b2a3b4400a2925b27ce1cede23f26b98dc Mon Sep 17 00:00:00 2001 From: Shaokun Zhang Date: Thu, 19 Oct 2017 19:05:16 +0800 Subject: Documentation: perf: hisi: Documentation for HiSilicon SoC PMU driver This patch adds documentation for the uncore PMUs on HiSilicon SoC. Acked-by: Mark Rutland Reviewed-by: Jonathan Cameron Signed-off-by: Shaokun Zhang Signed-off-by: Anurup M Signed-off-by: Will Deacon --- Documentation/perf/hisi-pmu.txt | 53 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 Documentation/perf/hisi-pmu.txt (limited to 'Documentation') diff --git a/Documentation/perf/hisi-pmu.txt b/Documentation/perf/hisi-pmu.txt new file mode 100644 index 000000000000..267a028b2741 --- /dev/null +++ b/Documentation/perf/hisi-pmu.txt @@ -0,0 +1,53 @@ +HiSilicon SoC uncore Performance Monitoring Unit (PMU) +====================================================== +The HiSilicon SoC chip includes various independent system device PMUs +such as L3 cache (L3C), Hydra Home Agent (HHA) and DDRC. These PMUs are +independent and have hardware logic to gather statistics and performance +information. + +The HiSilicon SoC encapsulates multiple CPU and IO dies. Each CPU cluster +(CCL) is made up of 4 cpu cores sharing one L3 cache; each CPU die is +called Super CPU cluster (SCCL) and is made up of 6 CCLs. Each SCCL has +two HHAs (0 - 1) and four DDRCs (0 - 3), respectively. + +HiSilicon SoC uncore PMU driver +--------------------------------------- +Each device PMU has separate registers for event counting, control and +interrupt, and the PMU driver shall register perf PMU drivers like L3C, +HHA and DDRC etc. The available events and configuration options shall +be described in the sysfs, see : +/sys/devices/hisi_sccl{X}_/, or +/sys/bus/event_source/devices/hisi_sccl{X}_. +The "perf list" command shall list the available events from sysfs. + +Each L3C, HHA and DDRC is registered as a separate PMU with perf. The PMU +name will appear in event listing as hisi_sccl_module. +where "sccl-id" is the identifier of the SCCL and "index-id" is the index of +module. +e.g. hisi_sccl3_l3c0/rd_hit_cpipe is READ_HIT_CPIPE event of L3C index #0 in +SCCL ID #3. +e.g. hisi_sccl1_hha0/rx_operations is RX_OPERATIONS event of HHA index #0 in +SCCL ID #1. + +The driver also provides a "cpumask" sysfs attribute, which shows the CPU core +ID used to count the uncore PMU event. + +Example usage of perf: +$# perf list +hisi_sccl3_l3c0/rd_hit_cpipe/ [kernel PMU event] +------------------------------------------ +hisi_sccl3_l3c0/wr_hit_cpipe/ [kernel PMU event] +------------------------------------------ +hisi_sccl1_l3c0/rd_hit_cpipe/ [kernel PMU event] +------------------------------------------ +hisi_sccl1_l3c0/wr_hit_cpipe/ [kernel PMU event] +------------------------------------------ + +$# perf stat -a -e hisi_sccl3_l3c0/rd_hit_cpipe/ sleep 5 +$# perf stat -a -e hisi_sccl3_l3c0/config=0x02/ sleep 5 + +The current driver does not support sampling. So "perf record" is unsupported. +Also attach to a task is unsupported as the events are all uncore. + +Note: Please contact the maintainer for a complete list of events supported for +the PMU devices in the SoC and its information if needed. -- cgit v1.2.3 From 4845688d6a86d411a7622148e4f39d29b51e92cd Mon Sep 17 00:00:00 2001 From: Julia Lawall Date: Sun, 15 Oct 2017 11:24:08 +0200 Subject: docs: dev-tools: correct Coccinelle version number There is no Coccinelle version 1.2. 1.0.2 must be what was intended. Signed-off-by: Julia Lawall Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/coccinelle.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index 4a64b4c69d3f..37e474ff6911 100644 --- a/Documentation/dev-tools/coccinelle.rst +++ b/Documentation/dev-tools/coccinelle.rst @@ -209,7 +209,7 @@ err.log will now have the profiling information, while stdout will provide some progress information as Coccinelle moves forward with work. -DEBUG_FILE support is only supported when using coccinelle >= 1.2. +DEBUG_FILE support is only supported when using coccinelle >= 1.0.2. .cocciconfig support -------------------- -- cgit v1.2.3 From 796cacdda786cb5466277ae51465a798f3c665b4 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Thu, 12 Oct 2017 15:23:36 -0500 Subject: Documentation: fix locking rt-mutex doc refs Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/locking/rt-mutex-design.txt | 2 +- Documentation/pi-futex.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/locking/rt-mutex-design.txt b/Documentation/locking/rt-mutex-design.txt index 6c6e8c2410de..3d7b865539cc 100644 --- a/Documentation/locking/rt-mutex-design.txt +++ b/Documentation/locking/rt-mutex-design.txt @@ -8,7 +8,7 @@ RT-mutex implementation design This document tries to describe the design of the rtmutex.c implementation. It doesn't describe the reasons why rtmutex.c exists. For that please see -Documentation/rt-mutex.txt. Although this document does explain problems +Documentation/locking/rt-mutex.txt. Although this document does explain problems that happen without this code, but that is in the concept to understand what the code actually is doing. diff --git a/Documentation/pi-futex.txt b/Documentation/pi-futex.txt index aafddbee7377..b154f6c0c36e 100644 --- a/Documentation/pi-futex.txt +++ b/Documentation/pi-futex.txt @@ -119,4 +119,4 @@ properties of futexes, and all four combinations are possible: futex, robust-futex, PI-futex, robust+PI-futex. More details about priority inheritance can be found in -Documentation/rt-mutex.txt. +Documentation/locking/rt-mutex.txt. -- cgit v1.2.3 From f66d9066c09fd65ed6fb418a422b17dcf9bdcd94 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Thu, 12 Oct 2017 15:23:42 -0500 Subject: Documentation: fix ref to sphinx/kerneldoc.py Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/doc-guide/kernel-doc.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst index b24854b5d6be..0268335414ce 100644 --- a/Documentation/doc-guide/kernel-doc.rst +++ b/Documentation/doc-guide/kernel-doc.rst @@ -65,7 +65,7 @@ Without options, the kernel-doc directive includes all documentation comments from the source file. The kernel-doc extension is included in the kernel source tree, at -``Documentation/sphinx/kernel-doc.py``. Internally, it uses the +``Documentation/sphinx/kerneldoc.py``. Internally, it uses the ``scripts/kernel-doc`` script to extract the documentation comments from the source. -- cgit v1.2.3 From d354a6f150d873440975263530a2e42121d50a51 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Thu, 12 Oct 2017 15:23:48 -0500 Subject: Documentation: fix ref to workqueue content Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- .../RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.html b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.html index e5d0bbd0230b..7394f034be65 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.html +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.html @@ -527,7 +527,7 @@ grace period also drove it to completion. This straightforward approach had the disadvantage of needing to account for POSIX signals sent to user tasks, so more recent implemementations use the Linux kernel's -workqueues. +workqueues.

The requesting task still does counter snapshotting and funnel-lock -- cgit v1.2.3 From 2c0c5c208bb8233d2d76327e3379375c01785c4d Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Thu, 12 Oct 2017 15:23:53 -0500 Subject: Documentation: fix ref to coccinelle content Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/process/4.Coding.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst index 6df19943dd4d..26b106071364 100644 --- a/Documentation/process/4.Coding.rst +++ b/Documentation/process/4.Coding.rst @@ -307,7 +307,7 @@ variety of potential coding problems; it can also propose fixes for those problems. Quite a few "semantic patches" for the kernel have been packaged under the scripts/coccinelle directory; running "make coccicheck" will run through those semantic patches and report on any problems found. See -Documentation/coccinelle.txt for more information. +Documentation/dev-tools/coccinelle.rst for more information. Other kinds of portability errors are best found by compiling your code for other architectures. If you do not happen to have an S/390 system or a -- cgit v1.2.3 From bb93e01b13821852a41f01b124cc71e94f5d3811 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Thu, 12 Oct 2017 15:23:59 -0500 Subject: Documentation: fix ref to trace stm content Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/trace/intel_th.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/intel_th.txt b/Documentation/trace/intel_th.txt index f92070e7dde0..7a57165c2492 100644 --- a/Documentation/trace/intel_th.txt +++ b/Documentation/trace/intel_th.txt @@ -37,7 +37,7 @@ description is at Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth. STH registers an stm class device, through which it provides interface to userspace and kernelspace software trace sources. See -Documentation/tracing/stm.txt for more information on that. +Documentation/trace/stm.txt for more information on that. MSU can be configured to collect trace data into a system memory buffer, which can later on be read from its device nodes via read() or -- cgit v1.2.3 From 4493c1f01b139192e2490457577dccff227987b7 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Thu, 12 Oct 2017 15:24:05 -0500 Subject: Documentation: fix ref to power basic-pm-debugging Signed-off-by: Tom Saeger Acked-by: Rafael J. Wysocki Signed-off-by: Jonathan Corbet --- Documentation/power/interface.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt index 7dc75f48e8bd..27df7f98668a 100644 --- a/Documentation/power/interface.txt +++ b/Documentation/power/interface.txt @@ -43,7 +43,7 @@ The currently selected option is printed in square brackets. The 'platform' option is only available if the platform provides a special mechanism to put the system to sleep after creating a hibernation image (ACPI does that, for example). The 'suspend' option is available if Suspend-to-RAM -is supported. Refer to Documentation/power/basic_pm_debugging.txt for the +is supported. Refer to Documentation/power/basic-pm-debugging.txt for the description of the 'test_resume' option. To select an option, write the string representing it to /sys/power/disk. -- cgit v1.2.3 From 718d50ec782caad13e0cc78fa6a76ff2226f3dd3 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Thu, 12 Oct 2017 15:24:10 -0500 Subject: Documentation: fix selftests related file refs Make refs to selftests files valid including: - watchdog-test.c - dnotify_test.c Signed-off-by: Tom Saeger Signed-off-by: Jonathan Corbet --- Documentation/filesystems/dnotify.txt | 2 +- Documentation/watchdog/hpwdt.txt | 2 +- Documentation/watchdog/pcwd-watchdog.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/dnotify.txt b/Documentation/filesystems/dnotify.txt index 6baf88f46859..15156883d321 100644 --- a/Documentation/filesystems/dnotify.txt +++ b/Documentation/filesystems/dnotify.txt @@ -62,7 +62,7 @@ disabled, fcntl(fd, F_NOTIFY, ...) will return -EINVAL. Example ------- -See Documentation/filesystems/dnotify_test.c for an example. +See tools/testing/selftests/filesystems/dnotify_test.c for an example. NOTE ---- diff --git a/Documentation/watchdog/hpwdt.txt b/Documentation/watchdog/hpwdt.txt index 7a9f635d0258..6d866c537127 100644 --- a/Documentation/watchdog/hpwdt.txt +++ b/Documentation/watchdog/hpwdt.txt @@ -15,7 +15,7 @@ Last reviewed: 05/20/2016 Watchdog functionality is enabled like any other common watchdog driver. That is, an application needs to be started that kicks off the watchdog timer. A - basic application exists in the Documentation/watchdog/src directory called + basic application exists in tools/testing/selftests/watchdog/ named watchdog-test.c. Simply compile the C file and kick it off. If the system gets into a bad state and hangs, the HPE ProLiant iLO timer register will not be updated in a timely fashion and a hardware system reset (also known as diff --git a/Documentation/watchdog/pcwd-watchdog.txt b/Documentation/watchdog/pcwd-watchdog.txt index 4f68052395c0..b8e60a441a43 100644 --- a/Documentation/watchdog/pcwd-watchdog.txt +++ b/Documentation/watchdog/pcwd-watchdog.txt @@ -25,7 +25,7 @@ Last reviewed: 10/05/2007 If you want to write a program to be compatible with the PC Watchdog driver, simply use of modify the watchdog test program: - Documentation/watchdog/src/watchdog-test.c + tools/testing/selftests/watchdog/watchdog-test.c Other IOCTL functions include: -- cgit v1.2.3 From 7d7363e403ce959941f80684cc5f33e747afff17 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 16 Oct 2017 16:32:51 -0700 Subject: documentation: kernel-api: add more info on bitmap functions There are some good comments about bitmap operations in lib/bitmap.c and include/linux/bitmap.h, so format them for document generation and pull them into core-api/kernel-api.rst. I converted the "tables" of functions from using tabs to using spaces so that they are more readable in the source file and in the generated output. Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Corbet --- Documentation/core-api/kernel-api.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 9c6902ba6e67..81754add8a49 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -53,6 +53,18 @@ The Linux kernel provides more basic utility functions. Bitmap Operations ----------------- +.. kernel-doc:: lib/bitmap.c + :doc: bitmap introduction + +.. kernel-doc:: include/linux/bitmap.h + :doc: declare bitmap + +.. kernel-doc:: include/linux/bitmap.h + :doc: bitmap overview + +.. kernel-doc:: include/linux/bitmap.h + :doc: bitmap bitops + .. kernel-doc:: lib/bitmap.c :export: -- cgit v1.2.3 From c8a8b7e672b74276abadcd987452acc8dc473aca Mon Sep 17 00:00:00 2001 From: Andrea Arcangeli Date: Wed, 18 Oct 2017 20:32:16 +0200 Subject: Documentation: kernel-enforcement-statement.rst: Remove Red Hat markings Doc update because significance of corporate affiliation was unclear. Acked-by: Doug Ledford Acked-by: Paolo Bonzini Acked-by: Hans de Goede Acked-by: Xin Long Signed-off-by: Andrea Arcangeli Signed-off-by: Richard Fontana Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index 421142690e7f..b2ae0405ccc0 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -52,7 +52,7 @@ we might work for today, have in the past, or will in the future. - Laura Abbott - Bjorn Andersson (Linaro) - - Andrea Arcangeli (Red Hat) + - Andrea Arcangeli - Neil Armstrong - Jens Axboe - Pablo Neira Ayuso @@ -61,7 +61,7 @@ we might work for today, have in the past, or will in the future. - Felipe Balbi - Arnd Bergmann - Ard Biesheuvel - - Paolo Bonzini (Red Hat) + - Paolo Bonzini - Christian Borntraeger - Mark Brown (Linaro) - Paul Burton @@ -70,7 +70,7 @@ we might work for today, have in the past, or will in the future. - Jonathan Corbet - Dennis Dalessandro - Vivien Didelot (Savoir-faire Linux) - - Hans de Goede (Red Hat) + - Hans de Goede - Mel Gorman (SUSE) - Sven Eckelmann - Alex Elder (Linaro) @@ -107,11 +107,11 @@ we might work for today, have in the past, or will in the future. - Viresh Kumar - Aneesh Kumar K.V - Julia Lawall - - Doug Ledford (Red Hat) + - Doug Ledford - Chuck Lever (Oracle) - Daniel Lezcano - Shaohua Li - - Xin Long (Red Hat) + - Xin Long - Tony Luck - Mike Marshall - Chris Mason -- cgit v1.2.3 From f76a2d9d7f9524c54dfd9c7b49ed26e488c4cf6c Mon Sep 17 00:00:00 2001 From: Sergei Shtylyov Date: Wed, 11 Oct 2017 22:51:59 +0300 Subject: gpio-rcar: document R8A77970 bindings Renesas R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible GPIO controllers, so document the SoC specific bindings. Signed-off-by: Sergei Shtylyov Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt index 51c86f69995e..41137a1cc099 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt @@ -14,6 +14,7 @@ Required Properties: - "renesas,gpio-r8a7794": for R8A7794 (R-Car E2) compatible GPIO controller. - "renesas,gpio-r8a7795": for R8A7795 (R-Car H3) compatible GPIO controller. - "renesas,gpio-r8a7796": for R8A7796 (R-Car M3-W) compatible GPIO controller. + - "renesas,gpio-r8a77970": for R8A77970 (R-Car V3M) compatible GPIO controller. - "renesas,rcar-gen1-gpio": for a generic R-Car Gen1 GPIO controller. - "renesas,rcar-gen2-gpio": for a generic R-Car Gen2 or RZ/G1 GPIO controller. - "renesas,rcar-gen3-gpio": for a generic R-Car Gen3 GPIO controller. -- cgit v1.2.3 From 07901a94f9f9b11cc3a4537e33229cb7e7df5d2a Mon Sep 17 00:00:00 2001 From: Alan Tull Date: Wed, 11 Oct 2017 11:34:44 -0500 Subject: gpio: gpio-dwapb: add optional reset Some platforms require reset to be released to allow register access. Signed-off-by: Alan Tull Reviewed-by: Philipp Zabel [Added DT bindings oneliner for standard reset binding] Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt index 4d6c8cdc8586..4a75da7051bd 100644 --- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt +++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt @@ -29,6 +29,7 @@ controller. - interrupts : The interrupt to the parent controller raised when GPIOs generate the interrupts. - snps,nr-gpios : The number of pins in the port, a single cell. +- resets : Reset line for the controller. Example: -- cgit v1.2.3 From eec1d566cdf94b57e8f5ba9fe60eea214929bcfc Mon Sep 17 00:00:00 2001 From: Lukas Wunner Date: Thu, 12 Oct 2017 12:40:10 +0200 Subject: gpio: Introduce ->get_multiple callback SPI-attached GPIO controllers typically read out all inputs in one go. If callers desire the values of multipe inputs, ideally a single readout should take place to return the desired values. However the current driver API only offers a ->get callback but no ->get_multiple (unlike ->set_multiple, which is present). Thus, to read multiple inputs, a full readout needs to be performed for every single value (barring driver-internal caching), which is inefficient. In fact, the lack of a ->get_multiple callback has been bemoaned repeatedly by the gpio subsystem maintainer: http://www.spinics.net/lists/linux-gpio/msg10571.html http://www.spinics.net/lists/devicetree/msg121734.html Introduce the missing callback. Add corresponding consumer functions such as gpiod_get_array_value(). Amend linehandle_ioctl() to take advantage of the newly added infrastructure. Update the documentation. Cc: Rojhalat Ibrahim Signed-off-by: Lukas Wunner Signed-off-by: Linus Walleij --- Documentation/gpio/consumer.txt | 41 ++++++++++++++++++++++++++++++----------- 1 file changed, 30 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt index ddbfa775a78a..63e1bd1d88e3 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/gpio/consumer.txt @@ -295,9 +295,22 @@ as possible, especially by drivers which should not care about the actual physical line level and worry about the logical value instead. -Set multiple GPIO outputs with a single function call ------------------------------------------------------ -The following functions set the output values of an array of GPIOs: +Access multiple GPIOs with a single function call +------------------------------------------------- +The following functions get or set the values of an array of GPIOs: + + int gpiod_get_array_value(unsigned int array_size, + struct gpio_desc **desc_array, + int *value_array); + int gpiod_get_raw_array_value(unsigned int array_size, + struct gpio_desc **desc_array, + int *value_array); + int gpiod_get_array_value_cansleep(unsigned int array_size, + struct gpio_desc **desc_array, + int *value_array); + int gpiod_get_raw_array_value_cansleep(unsigned int array_size, + struct gpio_desc **desc_array, + int *value_array); void gpiod_set_array_value(unsigned int array_size, struct gpio_desc **desc_array, @@ -312,34 +325,40 @@ The following functions set the output values of an array of GPIOs: struct gpio_desc **desc_array, int *value_array) -The array can be an arbitrary set of GPIOs. The functions will try to set +The array can be an arbitrary set of GPIOs. The functions will try to access GPIOs belonging to the same bank or chip simultaneously if supported by the corresponding chip driver. In that case a significantly improved performance -can be expected. If simultaneous setting is not possible the GPIOs will be set -sequentially. +can be expected. If simultaneous access is not possible the GPIOs will be +accessed sequentially. -The gpiod_set_array() functions take three arguments: +The functions take three arguments: * array_size - the number of array elements * desc_array - an array of GPIO descriptors - * value_array - an array of values to assign to the GPIOs + * value_array - an array to store the GPIOs' values (get) or + an array of values to assign to the GPIOs (set) The descriptor array can be obtained using the gpiod_get_array() function or one of its variants. If the group of descriptors returned by that function -matches the desired group of GPIOs, those GPIOs can be set by simply using +matches the desired group of GPIOs, those GPIOs can be accessed by simply using the struct gpio_descs returned by gpiod_get_array(): struct gpio_descs *my_gpio_descs = gpiod_get_array(...); gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc, my_gpio_values); -It is also possible to set a completely arbitrary array of descriptors. The +It is also possible to access a completely arbitrary array of descriptors. The descriptors may be obtained using any combination of gpiod_get() and gpiod_get_array(). Afterwards the array of descriptors has to be setup -manually before it can be used with gpiod_set_array(). +manually before it can be passed to one of the above functions. Note that for optimal performance GPIOs belonging to the same chip should be contiguous within the array of descriptors. +The return value of gpiod_get_array_value() and its variants is 0 on success +or negative on error. Note the difference to gpiod_get_value(), which returns +0 or 1 on success to convey the GPIO value. With the array functions, the GPIO +values are stored in value_array rather than passed back as return value. + GPIOs mapped to IRQs -------------------- -- cgit v1.2.3 From 0747c3ecfbed25cb6e31b09a834091757a3ef866 Mon Sep 17 00:00:00 2001 From: Tom Saeger Date: Thu, 12 Oct 2017 15:24:16 -0500 Subject: Documentation: fix ref to gpio.txt Signed-off-by: Tom Saeger Signed-off-by: Linus Walleij --- Documentation/ABI/obsolete/sysfs-gpio | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/obsolete/sysfs-gpio b/Documentation/ABI/obsolete/sysfs-gpio index 867c1fab20e2..32513dc2eec9 100644 --- a/Documentation/ABI/obsolete/sysfs-gpio +++ b/Documentation/ABI/obsolete/sysfs-gpio @@ -11,7 +11,7 @@ Description: Kernel code may export it for complete or partial access. GPIOs are identified as they are inside the kernel, using integers in - the range 0..INT_MAX. See Documentation/gpio.txt for more information. + the range 0..INT_MAX. See Documentation/gpio/gpio.txt for more information. /sys/class/gpio /export ... asks the kernel to export a GPIO to userspace -- cgit v1.2.3 From 1f63fab955dbcb8f6db56d67a4c63fc0746e4fe1 Mon Sep 17 00:00:00 2001 From: Lukas Wunner Date: Thu, 12 Oct 2017 12:40:10 +0200 Subject: dt-bindings: Document common property for daisy-chained devices Many serially-attached GPIO and IIO devices are daisy-chainable. Examples for GPIO devices are Maxim MAX3191x and TI SN65HVS88x: https://datasheets.maximintegrated.com/en/ds/MAX31913.pdf http://www.ti.com/lit/ds/symlink/sn65hvs880.pdf Examples for IIO devices are TI DAC128S085 and TI DAC161S055: http://www.ti.com/lit/ds/symlink/dac128s085.pdf http://www.ti.com/lit/ds/symlink/dac161s055.pdf We already have drivers for daisy-chainable devices in the tree but their devicetree bindings are somewhat inconsistent and ill-named: The gpio-74x164.c driver uses "registers-number" to convey the number of devices in the daisy-chain. (Sans vendor prefix, multiple vendors sell compatible versions of this chip.) The gpio-pisosr.c driver takes a different approach and calculates the number of devices in the daisy-chain by dividing the common "ngpios" property (Documentation/devicetree/bindings/gpio/gpio.txt) by 8 (which assumes that each chip has 8 inputs). Let's standardize on a common "#daisy-chained-devices" property. That name was chosen because it's the term most frequently used in datasheets. (A less frequently used synonym is "cascaded devices".) Signed-off-by: Lukas Wunner Acked-by: Jonathan Cameron Acked-by: Rob Herring Signed-off-by: Linus Walleij --- .../devicetree/bindings/common-properties.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/common-properties.txt b/Documentation/devicetree/bindings/common-properties.txt index 697714f8d75c..a3448bfa1c82 100644 --- a/Documentation/devicetree/bindings/common-properties.txt +++ b/Documentation/devicetree/bindings/common-properties.txt @@ -1,4 +1,8 @@ Common properties +================= + +Endianness +---------- The Devicetree Specification does not define any properties related to hardware byteswapping, but endianness issues show up frequently in porting Linux to @@ -58,3 +62,25 @@ dev: dev@40031000 { ... little-endian; }; + +Daisy-chained devices +--------------------- + +Many serially-attached GPIO and IIO devices are daisy-chainable. To the +host controller, a daisy-chain appears as a single device, but the number +of inputs and outputs it provides is the sum of inputs and outputs provided +by all of its devices. The driver needs to know how many devices the +daisy-chain comprises to determine the amount of data exchanged, how many +inputs and outputs to register and so on. + +Optional properties: + - #daisy-chained-devices: Number of devices in the daisy-chain (default is 1). + +Example: +gpio@0 { + compatible = "name"; + reg = <0>; + gpio-controller; + #gpio-cells = <2>; + #daisy-chained-devices = <3>; +}; -- cgit v1.2.3 From c019c18da10dae244308f584707804d0c148fe0b Mon Sep 17 00:00:00 2001 From: Lukas Wunner Date: Thu, 12 Oct 2017 12:40:10 +0200 Subject: dt-bindings: gpio: max3191x: Document new driver Add device tree bindings for Maxim MAX3191x industrial serializer. Cc: Mathias Duckeck Signed-off-by: Lukas Wunner Acked-by: Rob Herring Signed-off-by: Linus Walleij --- .../devicetree/bindings/gpio/gpio-max3191x.txt | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-max3191x.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-max3191x.txt b/Documentation/devicetree/bindings/gpio/gpio-max3191x.txt new file mode 100644 index 000000000000..b3a6444b8f45 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-max3191x.txt @@ -0,0 +1,59 @@ +GPIO driver for Maxim MAX3191x industrial serializer + +Required properties: + - compatible: Must be one of: + "maxim,max31910" + "maxim,max31911" + "maxim,max31912" + "maxim,max31913" + "maxim,max31953" + "maxim,max31963" + - reg: Chip select number. + - gpio-controller: Marks the device node as a GPIO controller. + - #gpio-cells: Should be two. For consumer use see gpio.txt. + +Optional properties: + - #daisy-chained-devices: + Number of chips in the daisy-chain (default is 1). + - maxim,modesel-gpios: GPIO pins to configure modesel of each chip. + The number of GPIOs must equal "#daisy-chained-devices" + (if each chip is driven by a separate pin) or 1 + (if all chips are wired to the same pin). + - maxim,fault-gpios: GPIO pins to read fault of each chip. + The number of GPIOs must equal "#daisy-chained-devices" + or 1. + - maxim,db0-gpios: GPIO pins to configure debounce of each chip. + The number of GPIOs must equal "#daisy-chained-devices" + or 1. + - maxim,db1-gpios: GPIO pins to configure debounce of each chip. + The number of GPIOs must equal "maxim,db0-gpios". + - maxim,modesel-8bit: Boolean whether the modesel pin of the chips is + pulled high (8-bit mode). Use this if the modesel pin + is hardwired and consequently "maxim,modesel-gpios" + cannot be specified. By default if neither this nor + "maxim,modesel-gpios" is given, the driver assumes + that modesel is pulled low (16-bit mode). + - maxim,ignore-undervoltage: + Boolean whether to ignore undervoltage alarms signaled + by the "maxim,fault-gpios" or by the status byte + (in 16-bit mode). Use this if the chips are powered + through 5VOUT instead of VCC24V, in which case they + will constantly signal undervoltage. + +For other required and optional properties of SPI slave nodes please refer to +../spi/spi-bus.txt. + +Example: + gpio@0 { + compatible = "maxim,max31913"; + reg = <0>; + gpio-controller; + #gpio-cells = <2>; + + maxim,modesel-gpios = <&gpio2 23>; + maxim,fault-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>; + maxim,db0-gpios = <&gpio2 25>; + maxim,db1-gpios = <&gpio2 26>; + + spi-max-frequency = <25000000>; + }; -- cgit v1.2.3 From e20824e944c3bf4352fcd8d9f446c41b53901e7b Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 18 Sep 2017 15:46:41 +0200 Subject: dt-bindings: timer: renesas, cmt: Fix SoC-specific compatible values While the new family-specific compatible values introduced by commit 6f54cc1adcc8957f ("devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings") use the recommended order ",-", the new SoC-specific compatible values still use the old and deprecated order ",-". Switch the SoC-specific compatible values to the recommended order while there are no upstream users of these compatible values yet. Fixes: 7f03a0ecfdc786c1 ("devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings") Fixes: 63d9e8ca0dd4bfa4 ("devicetree: bindings: Deprecate property, update example") Signed-off-by: Geert Uytterhoeven Acked-by: Rob Herring Reviewed-by: Laurent Pinchart Signed-off-by: Daniel Lezcano --- .../devicetree/bindings/timer/renesas,cmt.txt | 24 +++++++++++----------- 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt b/Documentation/devicetree/bindings/timer/renesas,cmt.txt index 6ca6b9e582a0..d740989eb569 100644 --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt @@ -20,16 +20,16 @@ Required Properties: (CMT1 on sh73a0 and r8a7740) This is a fallback for the above renesas,cmt-48-* entries. - - "renesas,cmt0-r8a73a4" for the 32-bit CMT0 device included in r8a73a4. - - "renesas,cmt1-r8a73a4" for the 48-bit CMT1 device included in r8a73a4. - - "renesas,cmt0-r8a7790" for the 32-bit CMT0 device included in r8a7790. - - "renesas,cmt1-r8a7790" for the 48-bit CMT1 device included in r8a7790. - - "renesas,cmt0-r8a7791" for the 32-bit CMT0 device included in r8a7791. - - "renesas,cmt1-r8a7791" for the 48-bit CMT1 device included in r8a7791. - - "renesas,cmt0-r8a7793" for the 32-bit CMT0 device included in r8a7793. - - "renesas,cmt1-r8a7793" for the 48-bit CMT1 device included in r8a7793. - - "renesas,cmt0-r8a7794" for the 32-bit CMT0 device included in r8a7794. - - "renesas,cmt1-r8a7794" for the 48-bit CMT1 device included in r8a7794. + - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4. + - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4. + - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790. + - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790. + - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791. + - "renesas,r8a7791-cmt1" for the 48-bit CMT1 device included in r8a7791. + - "renesas,r8a7793-cmt0" for the 32-bit CMT0 device included in r8a7793. + - "renesas,r8a7793-cmt1" for the 48-bit CMT1 device included in r8a7793. + - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794. + - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794. - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2. - "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2. @@ -46,7 +46,7 @@ Required Properties: Example: R8A7790 (R-Car H2) CMT0 and CMT1 nodes cmt0: timer@ffca0000 { - compatible = "renesas,cmt0-r8a7790", "renesas,rcar-gen2-cmt0"; + compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0"; reg = <0 0xffca0000 0 0x1004>; interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>, <0 142 IRQ_TYPE_LEVEL_HIGH>; @@ -55,7 +55,7 @@ Example: R8A7790 (R-Car H2) CMT0 and CMT1 nodes }; cmt1: timer@e6130000 { - compatible = "renesas,cmt1-r8a7790", "renesas,rcar-gen2-cmt1"; + compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1"; reg = <0 0xe6130000 0 0x1004>; interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>, <0 121 IRQ_TYPE_LEVEL_HIGH>, -- cgit v1.2.3 From 055f624e1eb9cae28211a7e1e140111d29228e13 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 19 Oct 2017 16:21:05 -0700 Subject: Input: gpio_mouse - add DT bindings This adds DT bindings for simple mice attached to GPIO lines. As the properties are very general and pertains to all mice I can think of, we use very generic names for the 4-7 GPIO lines, "up", "down" etc. Acked-by: Hans-Christian Noren Egtvedt Signed-off-by: Linus Walleij Acked-by: Rob Herring Signed-off-by: Dmitry Torokhov --- .../devicetree/bindings/input/gpio-mouse.txt | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/gpio-mouse.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/gpio-mouse.txt b/Documentation/devicetree/bindings/input/gpio-mouse.txt new file mode 100644 index 000000000000..519510a11af9 --- /dev/null +++ b/Documentation/devicetree/bindings/input/gpio-mouse.txt @@ -0,0 +1,32 @@ +Device-Tree bindings for GPIO attached mice + +This simply uses standard GPIO handles to define a simple mouse connected +to 5-7 GPIO lines. + +Required properties: + - compatible: must be "gpio-mouse" + - scan-interval-ms: The scanning interval in milliseconds + - up-gpios: GPIO line phandle to the line indicating "up" + - down-gpios: GPIO line phandle to the line indicating "down" + - left-gpios: GPIO line phandle to the line indicating "left" + - right-gpios: GPIO line phandle to the line indicating "right" + +Optional properties: + - button-left-gpios: GPIO line handle to the left mouse button + - button-middle-gpios: GPIO line handle to the middle mouse button + - button-right-gpios: GPIO line handle to the right mouse button +Example: + +#include + +gpio-mouse { + compatible = "gpio-mouse"; + scan-interval-ms = <50>; + up-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>; + down-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>; + left-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>; + right-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>; + button-left-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>; + button-middle-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>; + button-right-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>; +}; -- cgit v1.2.3 From 07fd1761e1cd2b5ecdb470fc228d52ccdf75e05b Mon Sep 17 00:00:00 2001 From: Cyril Bur Date: Thu, 12 Oct 2017 21:17:16 +1100 Subject: powerpc/tm: Add commandline option to disable hardware transactional memory Currently the kernel relies on firmware to inform it whether or not the CPU supports HTM and as long as the kernel was built with CONFIG_PPC_TRANSACTIONAL_MEM=y then it will allow userspace to make use of the facility. There may be situations where it would be advantageous for the kernel to not allow userspace to use HTM, currently the only way to achieve this is to recompile the kernel with CONFIG_PPC_TRANSACTIONAL_MEM=n. This patch adds a simple commandline option so that HTM can be disabled at boot time. Signed-off-by: Cyril Bur [mpe: Simplify to a bool, move to prom.c, put doco in the right place. Always disable, regardless of initial state, to avoid user confusion.] Signed-off-by: Michael Ellerman --- Documentation/admin-guide/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 05496622b4ef..ef03e6e16bdb 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3185,6 +3185,10 @@ allowed (eg kernel_enable_fpu()/kernel_disable_fpu()). There is some performance impact when enabling this. + ppc_tm= [PPC] + Format: {"off"} + Disable Hardware Transactional Memory + print-fatal-signals= [KNL] debug: print fatal signals -- cgit v1.2.3 From 533966c8ad9ec779d81179ea6a182055066c62a3 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 19 Oct 2017 14:26:20 -0700 Subject: doc: Fix RCU's docbook options Commit 764f80798b95 ("doc: Add RCU files to docbook-generation files") added :external: options for RCU source files in the file Documentation/core-api/kernel-api.rst. However, this now means nothing, so this commit removes them. Reported-by: Randy Dunlap Reported-by: Akira Yokosawa Signed-off-by: Paul E. McKenney Signed-off-by: Linus Torvalds --- Documentation/core-api/kernel-api.rst | 14 -------------- 1 file changed, 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 8282099e0cbf..5da10184d908 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -352,44 +352,30 @@ Read-Copy Update (RCU) ---------------------- .. kernel-doc:: include/linux/rcupdate.h - :external: .. kernel-doc:: include/linux/rcupdate_wait.h - :external: .. kernel-doc:: include/linux/rcutree.h - :external: .. kernel-doc:: kernel/rcu/tree.c - :external: .. kernel-doc:: kernel/rcu/tree_plugin.h - :external: .. kernel-doc:: kernel/rcu/tree_exp.h - :external: .. kernel-doc:: kernel/rcu/update.c - :external: .. kernel-doc:: include/linux/srcu.h - :external: .. kernel-doc:: kernel/rcu/srcutree.c - :external: .. kernel-doc:: include/linux/rculist_bl.h - :external: .. kernel-doc:: include/linux/rculist.h - :external: .. kernel-doc:: include/linux/rculist_nulls.h - :external: .. kernel-doc:: include/linux/rcu_sync.h - :external: .. kernel-doc:: kernel/rcu/sync.c - :external: -- cgit v1.2.3 From 87d9fa647020fb65985ec08826f6c77b9b4084af Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Wed, 18 Oct 2017 09:21:26 +0200 Subject: dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings Add fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant of the former or vice versa. We can, however, by examining the documentation and behaviour of the hardware at run-time observe that the current driver implementation appears to be compatible with the IP blocks on SoCs within a given generation. For the above reasons and convenience when enabling new SoCs a per-generation fallback compatibility string scheme is being adopted for drivers for Renesas SoCs. Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The approach that has been consistently taken for other IP blocks is to name common code, compatibility strings and so on after R-Car Gen2. Signed-off-by: Simon Horman Reviewed-by: Geert Uytterhoeven Reviewed-by: Sergei Shtylyov Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/sh_eth.txt | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/sh_eth.txt b/Documentation/devicetree/bindings/net/sh_eth.txt index 0115c85a2425..5172799a7f1a 100644 --- a/Documentation/devicetree/bindings/net/sh_eth.txt +++ b/Documentation/devicetree/bindings/net/sh_eth.txt @@ -4,7 +4,8 @@ This file provides information on what the device node for the SH EtherMAC interface contains. Required properties: -- compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC. +- compatible: Must contain one or more of the following: + "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC. "renesas,ether-r8a7743" if the device is a part of R8A7743 SoC. "renesas,ether-r8a7745" if the device is a part of R8A7745 SoC. "renesas,ether-r8a7778" if the device is a part of R8A7778 SoC. @@ -14,6 +15,14 @@ Required properties: "renesas,ether-r8a7793" if the device is a part of R8A7793 SoC. "renesas,ether-r8a7794" if the device is a part of R8A7794 SoC. "renesas,ether-r7s72100" if the device is a part of R7S72100 SoC. + "renesas,rcar-gen1-ether" for a generic R-Car Gen1 device. + "renesas,rcar-gen2-ether" for a generic R-Car Gen2 or RZ/G1 + device. + + When compatible with the generic version, nodes must list + the SoC-specific version corresponding to the platform + first followed by the generic version. + - reg: offset and length of (1) the E-DMAC/feLic register block (required), (2) the TSU register block (optional). - interrupts: interrupt specifier for the sole interrupt. @@ -36,7 +45,8 @@ Optional properties: Example (Lager board): ethernet@ee700000 { - compatible = "renesas,ether-r8a7790"; + compatible = "renesas,ether-r8a7790", + "renesas,rcar-gen2-ether"; reg = <0 0xee700000 0 0x400>; interrupt-parent = <&gic>; interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>; -- cgit v1.2.3 From d454cecc637b90996ab15b2e61a6cc51b7e1463c Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 12 Oct 2017 10:54:22 +0200 Subject: clk: renesas: rz: clk-rz is meant for RZ/A1 The RZ family of Renesas SoCs has several different subfamilies (RZ/A, RZ/G, RZ/N, and RZ/T). Clarify that the renesas,rz-cpg-clocks DT bindings and clk-rz driver apply to RZ/A1 only. Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt index bb5d942075fb..8ff3e2774ed8 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt +++ b/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt @@ -1,6 +1,6 @@ -* Renesas RZ Clock Pulse Generator (CPG) +* Renesas RZ/A1 Clock Pulse Generator (CPG) -The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable +The CPG generates core clocks for the RZ/A1 SoCs. It includes the PLL, variable CPU and GPU clocks, and several fixed ratio dividers. The CPG also provides a Clock Domain for SoC devices, in combination with the CPG Module Stop (MSTP) Clocks. -- cgit v1.2.3 From 9b17374e11c7ce2cf0b2b990fa4aa0360921aa2b Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu Date: Fri, 6 Oct 2017 08:16:37 +0900 Subject: kprobes/docs: Remove jprobes related documents Remove jprobes related documentation from kprobes.txt. Also add some migration advice for the people who are still using jprobes. Signed-off-by: Masami Hiramatsu Cc: Alexei Starovoitov Cc: Ananth N Mavinakayanahalli Cc: Anil S Keshavamurthy Cc: David S . Miller Cc: Ian McDonald Cc: Kees Cook Cc: Linus Torvalds Cc: Paul E . McKenney Cc: Peter Zijlstra Cc: Stephen Hemminger Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vlad Yasevich Link: http://lkml.kernel.org/r/150724539698.5014.7300022363980503141.stgit@devbox [ Fixes to the new documentation. ] Signed-off-by: Ingo Molnar --- Documentation/kprobes.txt | 159 +++++++++++++++++----------------------------- 1 file changed, 57 insertions(+), 102 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 2335715bf471..22208bf2386d 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt @@ -8,7 +8,7 @@ Kernel Probes (Kprobes) .. CONTENTS - 1. Concepts: Kprobes, Jprobes, Return Probes + 1. Concepts: Kprobes, and Return Probes 2. Architectures Supported 3. Configuring Kprobes 4. API Reference @@ -16,12 +16,12 @@ Kernel Probes (Kprobes) 6. Probe Overhead 7. TODO 8. Kprobes Example - 9. Jprobes Example - 10. Kretprobes Example + 9. Kretprobes Example + 10. Deprecated Features Appendix A: The kprobes debugfs interface Appendix B: The kprobes sysctl interface -Concepts: Kprobes, Jprobes, Return Probes +Concepts: Kprobes and Return Probes ========================================= Kprobes enables you to dynamically break into any kernel routine and @@ -32,12 +32,10 @@ routine to be invoked when the breakpoint is hit. .. [1] some parts of the kernel code can not be trapped, see :ref:`kprobes_blacklist`) -There are currently three types of probes: kprobes, jprobes, and -kretprobes (also called return probes). A kprobe can be inserted -on virtually any instruction in the kernel. A jprobe is inserted at -the entry to a kernel function, and provides convenient access to the -function's arguments. A return probe fires when a specified function -returns. +There are currently two types of probes: kprobes, and kretprobes +(also called return probes). A kprobe can be inserted on virtually +any instruction in the kernel. A return probe fires when a specified +function returns. In the typical case, Kprobes-based instrumentation is packaged as a kernel module. The module's init function installs ("registers") @@ -82,45 +80,6 @@ After the instruction is single-stepped, Kprobes executes the "post_handler," if any, that is associated with the kprobe. Execution then continues with the instruction following the probepoint. -How Does a Jprobe Work? ------------------------ - -A jprobe is implemented using a kprobe that is placed on a function's -entry point. It employs a simple mirroring principle to allow -seamless access to the probed function's arguments. The jprobe -handler routine should have the same signature (arg list and return -type) as the function being probed, and must always end by calling -the Kprobes function jprobe_return(). - -Here's how it works. When the probe is hit, Kprobes makes a copy of -the saved registers and a generous portion of the stack (see below). -Kprobes then points the saved instruction pointer at the jprobe's -handler routine, and returns from the trap. As a result, control -passes to the handler, which is presented with the same register and -stack contents as the probed function. When it is done, the handler -calls jprobe_return(), which traps again to restore the original stack -contents and processor state and switch to the probed function. - -By convention, the callee owns its arguments, so gcc may produce code -that unexpectedly modifies that portion of the stack. This is why -Kprobes saves a copy of the stack and restores it after the jprobe -handler has run. Up to MAX_STACK_SIZE bytes are copied -- e.g., -64 bytes on i386. - -Note that the probed function's args may be passed on the stack -or in registers. The jprobe will work in either case, so long as the -handler's prototype matches that of the probed function. - -Note that in some architectures (e.g.: arm64 and sparc64) the stack -copy is not done, as the actual location of stacked parameters may be -outside of a reasonable MAX_STACK_SIZE value and because that location -cannot be determined by the jprobes code. In this case the jprobes -user must be careful to make certain the calling signature of the -function does not cause parameters to be passed on the stack (e.g.: -more than eight function arguments, an argument of more than sixteen -bytes, or more than 64 bytes of argument data, depending on -architecture). - Return Probes ------------- @@ -245,8 +204,7 @@ Pre-optimization After preparing the detour buffer, Kprobes verifies that none of the following situations exist: -- The probe has either a break_handler (i.e., it's a jprobe) or a - post_handler. +- The probe has a post_handler. - Other instructions in the optimized region are probed. - The probe is disabled. @@ -331,7 +289,7 @@ rejects registering it, if the given address is in the blacklist. Architectures Supported ======================= -Kprobes, jprobes, and return probes are implemented on the following +Kprobes and return probes are implemented on the following architectures: - i386 (Supports jump optimization) @@ -446,27 +404,6 @@ architecture-specific trap number associated with the fault (e.g., on i386, 13 for a general protection fault or 14 for a page fault). Returns 1 if it successfully handled the exception. -register_jprobe ---------------- - -:: - - #include - int register_jprobe(struct jprobe *jp) - -Sets a breakpoint at the address jp->kp.addr, which must be the address -of the first instruction of a function. When the breakpoint is hit, -Kprobes runs the handler whose address is jp->entry. - -The handler should have the same arg list and return type as the probed -function; and just before it returns, it must call jprobe_return(). -(The handler never actually returns, since jprobe_return() returns -control to Kprobes.) If the probed function is declared asmlinkage -or anything else that affects how args are passed, the handler's -declaration must match. - -register_jprobe() returns 0 on success, or a negative errno otherwise. - register_kretprobe ------------------ @@ -513,7 +450,6 @@ unregister_*probe #include void unregister_kprobe(struct kprobe *kp); - void unregister_jprobe(struct jprobe *jp); void unregister_kretprobe(struct kretprobe *rp); Removes the specified probe. The unregister function can be called @@ -532,7 +468,6 @@ register_*probes #include int register_kprobes(struct kprobe **kps, int num); int register_kretprobes(struct kretprobe **rps, int num); - int register_jprobes(struct jprobe **jps, int num); Registers each of the num probes in the specified array. If any error occurs during registration, all probes in the array, up to @@ -555,7 +490,6 @@ unregister_*probes #include void unregister_kprobes(struct kprobe **kps, int num); void unregister_kretprobes(struct kretprobe **rps, int num); - void unregister_jprobes(struct jprobe **jps, int num); Removes each of the num probes in the specified array at once. @@ -574,7 +508,6 @@ disable_*probe #include int disable_kprobe(struct kprobe *kp); int disable_kretprobe(struct kretprobe *rp); - int disable_jprobe(struct jprobe *jp); Temporarily disables the specified ``*probe``. You can enable it again by using enable_*probe(). You must specify the probe which has been registered. @@ -587,7 +520,6 @@ enable_*probe #include int enable_kprobe(struct kprobe *kp); int enable_kretprobe(struct kretprobe *rp); - int enable_jprobe(struct jprobe *jp); Enables ``*probe`` which has been disabled by disable_*probe(). You must specify the probe which has been registered. @@ -595,12 +527,10 @@ the probe which has been registered. Kprobes Features and Limitations ================================ -Kprobes allows multiple probes at the same address. Currently, -however, there cannot be multiple jprobes on the same function at -the same time. Also, a probepoint for which there is a jprobe or -a post_handler cannot be optimized. So if you install a jprobe, -or a kprobe with a post_handler, at an optimized probepoint, the -probepoint will be unoptimized automatically. +Kprobes allows multiple probes at the same address. Also, +a probepoint for which there is a post_handler cannot be optimized. +So if you install a kprobe with a post_handler, at an optimized +probepoint, the probepoint will be unoptimized automatically. In general, you can install a probe anywhere in the kernel. In particular, you can probe interrupt handlers. Known exceptions @@ -662,7 +592,7 @@ We're unaware of other specific cases where this could be a problem. If, upon entry to or exit from a function, the CPU is running on a stack other than that of the current task, registering a return probe on that function may produce undesirable results. For this -reason, Kprobes doesn't support return probes (or kprobes or jprobes) +reason, Kprobes doesn't support return probes (or kprobes) on the x86_64 version of __switch_to(); the registration functions return -EINVAL. @@ -706,24 +636,24 @@ Probe Overhead On a typical CPU in use in 2005, a kprobe hit takes 0.5 to 1.0 microseconds to process. Specifically, a benchmark that hits the same probepoint repeatedly, firing a simple handler each time, reports 1-2 -million hits per second, depending on the architecture. A jprobe or -return-probe hit typically takes 50-75% longer than a kprobe hit. +million hits per second, depending on the architecture. A return-probe +hit typically takes 50-75% longer than a kprobe hit. When you have a return probe set on a function, adding a kprobe at the entry to that function adds essentially no overhead. Here are sample overhead figures (in usec) for different architectures:: - k = kprobe; j = jprobe; r = return probe; kr = kprobe + return probe - on same function; jr = jprobe + return probe on same function:: + k = kprobe; r = return probe; kr = kprobe + return probe + on same function i386: Intel Pentium M, 1495 MHz, 2957.31 bogomips - k = 0.57 usec; j = 1.00; r = 0.92; kr = 0.99; jr = 1.40 + k = 0.57 usec; r = 0.92; kr = 0.99 x86_64: AMD Opteron 246, 1994 MHz, 3971.48 bogomips - k = 0.49 usec; j = 0.76; r = 0.80; kr = 0.82; jr = 1.07 + k = 0.49 usec; r = 0.80; kr = 0.82 ppc64: POWER5 (gr), 1656 MHz (SMT disabled, 1 virtual CPU per physical CPU) - k = 0.77 usec; j = 1.31; r = 1.26; kr = 1.45; jr = 1.99 + k = 0.77 usec; r = 1.26; kr = 1.45 Optimized Probe Overhead ------------------------ @@ -755,11 +685,6 @@ Kprobes Example See samples/kprobes/kprobe_example.c -Jprobes Example -=============== - -See samples/kprobes/jprobe_example.c - Kretprobes Example ================== @@ -772,6 +697,37 @@ For additional information on Kprobes, refer to the following URLs: - http://www-users.cs.umn.edu/~boutcher/kprobes/ - http://www.linuxsymposium.org/2006/linuxsymposium_procv2.pdf (pages 101-115) +Deprecated Features +=================== + +Jprobes is now a deprecated feature. People who are depending on it should +migrate to other tracing features or use older kernels. Please consider to +migrate your tool to one of the following options: + +- Use trace-event to trace target function with arguments. + + trace-event is a low-overhead (and almost no visible overhead if it + is off) statically defined event interface. You can define new events + and trace it via ftrace or any other tracing tools. + + See the following urls: + + - https://lwn.net/Articles/379903/ + - https://lwn.net/Articles/381064/ + - https://lwn.net/Articles/383362/ + +- Use ftrace dynamic events (kprobe event) with perf-probe. + + If you build your kernel with debug info (CONFIG_DEBUG_INFO=y), you can + find which register/stack is assigned to which local variable or arguments + by using perf-probe and set up new event to trace it. + + See following documents: + + - Documentation/trace/kprobetrace.txt + - Documentation/trace/events.txt + - tools/perf/Documentation/perf-probe.txt + The kprobes debugfs interface ============================= @@ -783,14 +739,13 @@ under the /sys/kernel/debug/kprobes/ directory (assuming debugfs is mounted at / /sys/kernel/debug/kprobes/list: Lists all registered probes on the system:: c015d71a k vfs_read+0x0 - c011a316 j do_fork+0x0 c03dedc5 r tcp_v4_rcv+0x0 The first column provides the kernel address where the probe is inserted. -The second column identifies the type of probe (k - kprobe, r - kretprobe -and j - jprobe), while the third column specifies the symbol+offset of -the probe. If the probed function belongs to a module, the module name -is also specified. Following columns show probe status. If the probe is on +The second column identifies the type of probe (k - kprobe and r - kretprobe) +while the third column specifies the symbol+offset of the probe. +If the probed function belongs to a module, the module name is also +specified. Following columns show probe status. If the probe is on a virtual address that is no longer valid (module init sections, module virtual addresses that correspond to modules that've been unloaded), such probes are marked with [GONE]. If the probe is temporarily disabled, -- cgit v1.2.3 From c77d3b8d0ce856836c682617eeaac2ac00164c53 Mon Sep 17 00:00:00 2001 From: Sean Wang Date: Wed, 18 Oct 2017 16:28:42 +0800 Subject: dt-bindings: arm: mediatek: add MT7622 string to the PMIC wrapper doc Signed-off-by: Chenglin Xu Signed-off-by: Sean Wang Acked-by: Rob Herring Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt index 107700d00df4..bf80e3f96f8c 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt @@ -19,6 +19,7 @@ IP Pairing Required properties in pwrap device node. - compatible: "mediatek,mt2701-pwrap" for MT2701/7623 SoCs + "mediatek,mt7622-pwrap" for MT7622 SoCs "mediatek,mt8135-pwrap" for MT8135 SoCs "mediatek,mt8173-pwrap" for MT8173 SoCs - interrupts: IRQ for pwrap in SOC @@ -36,9 +37,12 @@ Required properties in pwrap device node. - clocks: Must contain an entry for each entry in clock-names. Optional properities: -- pmic: Mediatek PMIC MFD is the child device of pwrap +- pmic: Using either MediaTek PMIC MFD as the child device of pwrap See the following for child node definitions: Documentation/devicetree/bindings/mfd/mt6397.txt + or the regulator-only device as the child device of pwrap, such as MT6380. + See the following definitions for such kinds of devices. + Documentation/devicetree/bindings/regulator/mt6380-regulator.txt Example: pwrap: pwrap@1000f000 { -- cgit v1.2.3 From 12a8cc7fcf54a8575f094be1e99032ec38aa045c Mon Sep 17 00:00:00 2001 From: Andrey Ryabinin Date: Fri, 29 Sep 2017 17:08:18 +0300 Subject: x86/kasan: Use the same shadow offset for 4- and 5-level paging We are going to support boot-time switching between 4- and 5-level paging. For KASAN it means we cannot have different KASAN_SHADOW_OFFSET for different paging modes: the constant is passed to gcc to generate code and cannot be changed at runtime. This patch changes KASAN code to use 0xdffffc0000000000 as shadow offset for both 4- and 5-level paging. For 5-level paging it means that shadow memory region is not aligned to PGD boundary anymore and we have to handle unaligned parts of the region properly. In addition, we have to exclude paravirt code from KASAN instrumentation as we now use set_pgd() before KASAN is fully ready. [kirill.shutemov@linux.intel.com: clenaup, changelog message] Signed-off-by: Andrey Ryabinin Signed-off-by: Kirill A. Shutemov Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Cyrill Gorcunov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20170929140821.37654-4-kirill.shutemov@linux.intel.com Signed-off-by: Ingo Molnar --- Documentation/x86/x86_64/mm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt index b0798e281aa6..3448e675b462 100644 --- a/Documentation/x86/x86_64/mm.txt +++ b/Documentation/x86/x86_64/mm.txt @@ -34,7 +34,7 @@ ff92000000000000 - ffd1ffffffffffff (=54 bits) vmalloc/ioremap space ffd2000000000000 - ffd3ffffffffffff (=49 bits) hole ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB) ... unused hole ... -ffd8000000000000 - fff7ffffffffffff (=53 bits) kasan shadow memory (8PB) +ffdf000000000000 - fffffc0000000000 (=53 bits) kasan shadow memory (8PB) ... unused hole ... ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks ... unused hole ... -- cgit v1.2.3 From 17c918840fb07e5819f8df03345d7f4a5e5b791c Mon Sep 17 00:00:00 2001 From: Donald Sharp Date: Wed, 18 Oct 2017 10:24:28 -0400 Subject: doc: Update VRF documentation metric Two things: 1) Update examples to show usage of metric 2) Discuss reasoning for using such a high metric. Signed-off-by: Donald Sharp Acked-by: David Ahern Signed-off-by: David S. Miller --- Documentation/networking/vrf.txt | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/vrf.txt b/Documentation/networking/vrf.txt index 3918dae964d4..8ff7b4c8f91b 100644 --- a/Documentation/networking/vrf.txt +++ b/Documentation/networking/vrf.txt @@ -71,7 +71,12 @@ Setup ip ru add iif vrf-blue table 10 3. Set the default route for the table (and hence default route for the VRF). - ip route add table 10 unreachable default + ip route add table 10 unreachable default metric 4278198272 + + This high metric value ensures that the default unreachable route can + be overridden by a routing protocol suite. FRRouting interprets + kernel metrics as a combined admin distance (upper byte) and priority + (lower 3 bytes). Thus the above metric translates to [255/8192]. 4. Enslave L3 interfaces to a VRF device. ip link set dev eth1 master vrf-blue @@ -256,7 +261,7 @@ older form without it. For example: $ ip route show vrf red - prohibit default + unreachable default metric 4278198272 broadcast 10.2.1.0 dev eth1 proto kernel scope link src 10.2.1.2 10.2.1.0/24 dev eth1 proto kernel scope link src 10.2.1.2 local 10.2.1.2 dev eth1 proto kernel scope host src 10.2.1.2 @@ -282,7 +287,7 @@ older form without it. ff00::/8 dev red metric 256 pref medium ff00::/8 dev eth1 metric 256 pref medium ff00::/8 dev eth2 metric 256 pref medium - + unreachable default dev lo metric 4278198272 error -101 pref medium 8. Route Lookup for a VRF @@ -331,7 +336,7 @@ function vrf_create ip link add ${VRF} type vrf table ${TBID} if [ "${VRF}" != "mgmt" ]; then - ip route add table ${TBID} unreachable default + ip route add table ${TBID} unreachable default metric 4278198272 fi ip link set dev ${VRF} up } -- cgit v1.2.3 From d3b3efa1705833aa1b7f55ea9b2ed09e48e957a7 Mon Sep 17 00:00:00 2001 From: Mikko Perttunen Date: Tue, 5 Sep 2017 11:43:04 +0300 Subject: dt-bindings: host1x: Add Tegra186 information Add the Tegra186-specific hypervisor-related register range properties. Signed-off-by: Mikko Perttunen Acked-by: Rob Herring Signed-off-by: Thierry Reding --- .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt index 74e1e8add5a1..844e0103fb0d 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt @@ -3,6 +3,10 @@ NVIDIA Tegra host1x Required properties: - compatible: "nvidia,tegra-host1x" - reg: Physical base address and length of the controller's registers. + For pre-Tegra186, one entry describing the whole register area. + For Tegra186, one entry for each entry in reg-names: + "vm" - VM region assigned to Linux + "hypervisor" - Hypervisor region (only if Linux acts as hypervisor) - interrupts: The interrupt outputs from the controller. - #address-cells: The number of cells used to represent physical base addresses in the host1x address space. Should be 1. -- cgit v1.2.3 From 24f0d316fd14c8e61592f580e0075dd3433fde40 Mon Sep 17 00:00:00 2001 From: Leo Yan Date: Tue, 10 Oct 2017 14:32:13 -0600 Subject: doc: coresight: correct usage for disabling idle states In the coresight CPU debug document it suggests to use 'echo' command to set latency request to /dev/cpu_dma_latency so can disable all CPU idle states, but in fact this doesn't work. This is because when the command 'echo' exits, it releases the device node's file descriptor and the kernel release function removes the QoS constraint; finally when the command 'echo' finished there have no constraint imposed on cpu_dma_latency. This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the command 'exec' can avoid the file descriptor to be closed so we can keep the constraint on cpu_dma_latency. This patch also adds the info for reference docs for PM QoS and cpuidle sysfs. Cc: Jonathan Corbet Cc: Sudeep Holla Reported-by: Kim Phillips Suggested-by: Mathieu Poirier Signed-off-by: Leo Yan Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman --- Documentation/trace/coresight-cpu-debug.txt | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.txt index b3da1f90b861..2b9b51cd501e 100644 --- a/Documentation/trace/coresight-cpu-debug.txt +++ b/Documentation/trace/coresight-cpu-debug.txt @@ -149,11 +149,23 @@ If you want to limit idle states at boot time, you can use "nohlt" or At the runtime you can disable idle states with below methods: -Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle -states (if latency = 0uS then disable all idle states): -# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency - -Disable specific CPU's specific idle state: +It is possible to disable CPU idle states by way of the PM QoS +subsystem, more specifically by using the "/dev/cpu_dma_latency" +interface (see Documentation/power/pm_qos_interface.txt for more +details). As specified in the PM QoS documentation the requested +parameter will stay in effect until the file descriptor is released. +For example: + +# exec 3<> /dev/cpu_dma_latency; echo 0 >&3 +... +Do some work... +... +# exec 3<>- + +The same can also be done from an application program. + +Disable specific CPU's specific idle state from cpuidle sysfs (see +Documentation/cpuidle/sysfs.txt): # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable -- cgit v1.2.3 From 7a15cf2af480440bacf2fc0010f1fa1a1f3980d6 Mon Sep 17 00:00:00 2001 From: Romain Perier Date: Mon, 9 Oct 2017 15:26:38 +0200 Subject: nvmem: rockchip: add support for RK3368 This adds the necessary function for handling support on RK3368 SoCs Signed-off-by: Romain Perier Acked-by: Rob Herring Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt index 1ff02afdc55a..60bec4782806 100644 --- a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt +++ b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt @@ -6,6 +6,7 @@ Required properties: - "rockchip,rk3188-efuse" - for RK3188 SoCs. - "rockchip,rk3228-efuse" - for RK3228 SoCs. - "rockchip,rk3288-efuse" - for RK3288 SoCs. + - "rockchip,rk3368-efuse" - for RK3368 SoCs. - "rockchip,rk3399-efuse" - for RK3399 SoCs. - reg: Should contain the registers location and exact eFuse size - clocks: Should be the clock id of eFuse -- cgit v1.2.3 From 41e043498978ad3c8d5a70613f41195faf09663f Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl Date: Mon, 9 Oct 2017 15:26:39 +0200 Subject: dt-bindings: nvmem: Describe the Amlogic Meson6/Meson8/Meson8b efuse Amlogic Meson6, Meson8 and Meson8b SoCs have an efuse which contains calibration data from the factory (for the internal temperature sensor and some CVBS connector settings). Some manufacturers also store the MAC address or serial number in the efuse. This documents the devicetree bindings for the efuse on these SoCs. Signed-off-by: Martin Blumenstingl Signed-off-by: Srinivas Kandagatla Acked-by: Rob Herring Signed-off-by: Greg Kroah-Hartman --- .../bindings/nvmem/amlogic-meson-mx-efuse.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt new file mode 100644 index 000000000000..a3c63954a1a4 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt @@ -0,0 +1,22 @@ +Amlogic Meson6/Meson8/Meson8b efuse + +Required Properties: +- compatible: depending on the SoC this should be one of: + - "amlogic,meson6-efuse" + - "amlogic,meson8-efuse" + - "amlogic,meson8b-efuse" +- reg: base address and size of the efuse registers +- clocks: a reference to the efuse core gate clock +- clock-names: must be "core" + +All properties and sub-nodes as well as the consumer bindings +defined in nvmem.txt in this directory are also supported. + + +Example: + efuse: nvmem@0 { + compatible = "amlogic,meson8-efuse"; + reg = <0x0 0x2000>; + clocks = <&clkc CLKID_EFUSE>; + clock-names = "core"; + }; -- cgit v1.2.3 From 9593ad32b8be82f3abd6002336a93c405361b9fd Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl Date: Mon, 9 Oct 2017 15:26:40 +0200 Subject: nvmem: meson-efuse: indicate that this driver is only for Meson GX SoCs The current Amlogic Meson eFuse driver only supports the 64-bit SoCs (GXBB and newer). Older SoCs cannot be supported by the same driver because they do not use the meson secure monitor firmware to access the hardware. Signed-off-by: Martin Blumenstingl Signed-off-by: Srinivas Kandagatla Acked-by: Rob Herring Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt index fafd85bd67a6..e3298e18de26 100644 --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt @@ -1,4 +1,4 @@ -= Amlogic eFuse device tree bindings = += Amlogic Meson GX eFuse device tree bindings = Required properties: - compatible: should be "amlogic,meson-gxbb-efuse" -- cgit v1.2.3 From f6755643d62e14c55c2f864a7995fd8001ae3f51 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 11 Oct 2017 15:50:13 +0200 Subject: dt-bindings: PCI: rcar: Correct example to match reality Correct the USB subnodes in the example, as in f7d569c1e6a6 ("ARM: dts: r8a779x: Fix PCI bus dtc warnings"). 1. Drop the bogus 'device_type = "pci"' properties, 2. Correct the unit addresses. Update other bits in the example to match real use: 1. Rename the USB subnodes from "pci" to "usb", 2. Update the "phys" property. Signed-off-by: Geert Uytterhoeven Signed-off-by: Bjorn Helgaas Acked-by: Sergei Shtylyov Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt index 3d038638612b..9fe7e12a7bf3 100644 --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt @@ -60,17 +60,15 @@ Example SoC configuration: 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>; - pci@0,1 { + usb@1,0 { reg = <0x800 0 0 0 0>; - device_type = "pci"; - phys = <&usbphy 0 0>; + phys = <&usb0 0>; phy-names = "usb"; }; - pci@0,2 { + usb@2,0 { reg = <0x1000 0 0 0 0>; - device_type = "pci"; - phys = <&usbphy 0 0>; + phys = <&usb0 0>; phy-names = "usb"; }; }; -- cgit v1.2.3 From d92f842bb30f52beedad63a4a850b39ca0dbc45f Mon Sep 17 00:00:00 2001 From: Scott Tsai Date: Wed, 20 Sep 2017 02:16:00 +0800 Subject: memory-barriers.txt: Fix typo in pairing example In the "general barrier pairing with implicit control depdendency" example, the last write by CPU 1 was meant to change variable x and not y. The example would be pretty uninteresting if no CPU ever changes x and the variable was initialized to zero. Signed-off-by: Scott Tsai Signed-off-by: Paul E. McKenney --- Documentation/memory-barriers.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 7deee1441640..f37375544d71 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -947,7 +947,7 @@ Or even: =============== =============================== r1 = READ_ONCE(y); - WRITE_ONCE(y, 1); if (r2 = READ_ONCE(x)) { + WRITE_ONCE(x, 1); if (r2 = READ_ONCE(x)) { WRITE_ONCE(y, 1); } -- cgit v1.2.3 From 5692fcc671ac8a10bfd0e75d52f0259fe767b56c Mon Sep 17 00:00:00 2001 From: "Guilherme G. Piccoli" Date: Thu, 21 Sep 2017 16:29:01 -0300 Subject: doc: Rewrite confusing statement about memory barriers The "Write (or store) memory barriers" bullet of the "Variety of memory barriers" section, calls out a sequential order of stores, which is confusing since sequential ordering is not guaranteed. This commit therefore rewords to avoid mentioning a sequence of stores to clarify the intent. Cc: Paul E. McKenney Signed-off-by: Guilherme G. Piccoli Signed-off-by: Paul E. McKenney --- Documentation/memory-barriers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index f37375544d71..519940ec767f 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -383,8 +383,8 @@ Memory barriers come in four basic varieties: to have any effect on loads. A CPU can be viewed as committing a sequence of store operations to the - memory system as time progresses. All stores before a write barrier will - occur in the sequence _before_ all the stores after the write barrier. + memory system as time progresses. All stores _before_ a write barrier + will occur _before_ all the stores after the write barrier. [!] Note that write barriers should normally be paired with read or data dependency barriers; see the "SMP barrier pairing" subsection. -- cgit v1.2.3 From b92ca54eb563df0d1963d2a4f5cac1713c581a8a Mon Sep 17 00:00:00 2001 From: Catalin Marinas Date: Fri, 20 Oct 2017 18:15:26 +0100 Subject: Documentation: Add Arm Ltd to kernel-enforcement-statement.rst Adding a couple of names on behalf of Arm Ltd. Acked-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index b2ae0405ccc0..3f884ebfb844 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -113,6 +113,7 @@ we might work for today, have in the past, or will in the future. - Shaohua Li - Xin Long - Tony Luck + - Catalin Marinas (Arm Ltd) - Mike Marshall - Chris Mason - Paul E. McKenney @@ -150,3 +151,4 @@ we might work for today, have in the past, or will in the future. - Wei Yongjun - Lv Zheng - Eduardo Valentin + - Marc Zyngier (Arm Ltd) -- cgit v1.2.3 From 14f0e5f8d97e632695d92f41f2e91d10d8005d47 Mon Sep 17 00:00:00 2001 From: Olivier Moysan Date: Thu, 19 Oct 2017 15:03:17 +0200 Subject: ASoC: stm32: Add synchronization to SAI bindings Add synchronization configuration to STM32 SAI bindings. This patch also adds peripheral clock which is required to access synchronization register. Signed-off-by: Olivier Moysan Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/st,stm32-sai.txt | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt index f1c5ae59e7c9..1f9cd7095337 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt @@ -10,13 +10,21 @@ Required properties: - reg: Base address and size of SAI common register set. - clocks: Must contain phandle and clock specifier pairs for each entry in clock-names. - - clock-names: Must contain "x8k" and "x11k" + - clock-names: Must contain "pclk" "x8k" and "x11k" + "pclk": Clock which feeds the peripheral bus interface. + Mandatory for "st,stm32h7-sai" compatible. + Not used for "st,stm32f4-sai" compatible. "x8k": SAI parent clock for sampling rates multiple of 8kHz. "x11k": SAI parent clock for sampling rates multiple of 11.025kHz. - interrupts: cpu DAI interrupt line shared by SAI sub-blocks Optional properties: - resets: Reference to a reset controller asserting the SAI + - st,sync: specify synchronization mode. + By default SAI sub-block is in asynchronous mode. + This property sets SAI sub-block as slave of another SAI sub-block. + Must contain the phandle and index of the sai sub-block providing + the synchronization. SAI subnodes: Two subnodes corresponding to SAI sub-block instances A et B can be defined. @@ -52,8 +60,8 @@ sai1: sai1@40015800 { #size-cells = <1>; ranges = <0 0x40015800 0x400>; reg = <0x40015800 0x4>; - clocks = <&rcc PLL1_Q>, <&rcc PLL2_P>; - clock-names = "x8k", "x11k"; + clocks = <&rcc SAI1_CK>, <&rcc PLL1_Q>, <&rcc PLL2_P>; + clock-names = "pclk", "x8k", "x11k"; interrupts = <87>; sai1a: audio-controller@40015804 { -- cgit v1.2.3 From 05c006145054a86430ed4fdd4f8c1b4139a44bee Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Tue, 17 Oct 2017 06:57:19 +0000 Subject: ASoC: audio-graph-scu-card: add missing Capture routing on Example Both cases have 1 Capture path. Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt b/Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt index 8b8afe9fcb31..a10daf54aa0c 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt +++ b/Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt @@ -43,7 +43,8 @@ Example 1. Sampling Rate Conversion label = "sound-card"; prefix = "codec"; routing = "codec Playback", "DAI0 Playback", - "codec Playback", "DAI1 Playback"; + "codec Playback", "DAI1 Playback", + "DAI0 Capture", "codec Capture"; convert-rate = <48000>; dais = <&cpu_port>; @@ -79,7 +80,8 @@ Example 2. 2 CPU 1 Codec (Mixing) label = "sound-card"; prefix = "codec"; routing = "codec Playback", "DAI0 Playback", - "codec Playback", "DAI1 Playback"; + "codec Playback", "DAI1 Playback", + "DAI0 Capture", "codec Capture"; convert-rate = <48000>; dais = <&cpu_port0 -- cgit v1.2.3 From 86d5b2c20d8ec255ef7646533b81dabc935e0eff Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Tue, 17 Oct 2017 06:57:49 +0000 Subject: ASoC: audio-graph-scu-card: remove unnecessary route patch from Example 1 Example 1 is for "Sampling Rate Conversion", sample has only 1 CPU, 1 Codec. Thus, "codec Playback", "DAI1 Playback" route is unnecessary. Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt b/Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt index a10daf54aa0c..441dd6f29df1 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt +++ b/Documentation/devicetree/bindings/sound/audio-graph-scu-card.txt @@ -43,7 +43,6 @@ Example 1. Sampling Rate Conversion label = "sound-card"; prefix = "codec"; routing = "codec Playback", "DAI0 Playback", - "codec Playback", "DAI1 Playback", "DAI0 Capture", "codec Capture"; convert-rate = <48000>; -- cgit v1.2.3 From 7e95d9134e3851de57075254737bc434462bb293 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 19 Oct 2017 01:18:57 +0200 Subject: PM: docs: Fix formatting typo in devices.rst There is one word too many under formatting markup in one place in device.rst, so fix it. Signed-off-by: Rafael J. Wysocki --- Documentation/driver-api/pm/devices.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index a0dc2879a152..b8f1e3bdb743 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -274,7 +274,7 @@ sleep states and the hibernation state ("suspend-to-disk"). Each phase involves executing callbacks for every device before the next phase begins. Not all buses or classes support all these callbacks and not all drivers use all the callbacks. The various phases always run after tasks have been frozen and -before they are unfrozen. Furthermore, the ``*_noirq phases`` run at a time +before they are unfrozen. Furthermore, the ``*_noirq`` phases run at a time when IRQ handlers have been disabled (except for those marked with the IRQF_NO_SUSPEND flag). -- cgit v1.2.3 From 191643403b770d6adbc10a5bb5ed539845e9d1ad Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 21 Oct 2017 17:01:49 +0200 Subject: Documentation: kernel-enforcement-statement.rst: proper sort names Eduardo was not in the correct alphabetical order, and Ivan was somehow listed twice, so fix these sorting issues up. Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index 3f884ebfb844..ba8c525eeee1 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -130,7 +130,6 @@ we might work for today, have in the past, or will in the future. - Leon Romanovsky - Steven Rostedt (VMware) - Ivan Safonov - - Ivan Safonov - Anna Schumaker - Jes Sorensen - K.Y. Srinivasan @@ -141,6 +140,7 @@ we might work for today, have in the past, or will in the future. - Thierry Reding - Rik van Riel - Geert Uytterhoeven (Glider bvba) + - Eduardo Valentin (Amazon.com) - Daniel Vetter - Linus Walleij - Richard Weinberger @@ -150,5 +150,4 @@ we might work for today, have in the past, or will in the future. - Masahiro Yamada - Wei Yongjun - Lv Zheng - - Eduardo Valentin - Marc Zyngier (Arm Ltd) -- cgit v1.2.3 From 930cc2d27847a4235bb3dc1e3817504dcf230dcb Mon Sep 17 00:00:00 2001 From: Lukas Wunner Date: Tue, 17 Oct 2017 12:42:00 +0200 Subject: dt-bindings: iio: dac: ti-dac082s085: Document new driver Add device tree bindings for Texas Instruments 8/10/12-bit 2/4-channel DAC driver. Cc: Mathias Duckeck Acked-by: Rob Herring Signed-off-by: Lukas Wunner Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/dac/ti-dac082s085.txt | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt b/Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt new file mode 100644 index 000000000000..9cb0e10df704 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt @@ -0,0 +1,34 @@ +Texas Instruments 8/10/12-bit 2/4-channel DAC driver + +Required properties: + - compatible: Must be one of: + "ti,dac082s085" + "ti,dac102s085" + "ti,dac122s085" + "ti,dac084s085" + "ti,dac104s085" + "ti,dac124s085" + - reg: Chip select number. + - spi-cpha, spi-cpol: SPI mode (0,1) or (1,0) must be used, so specify + either spi-cpha or spi-cpol (but not both). + - vref-supply: Phandle to the external reference voltage supply. + +For other required and optional properties of SPI slave nodes please refer to +../../spi/spi-bus.txt. + +Example: + vref_2v5_reg: regulator-vref { + compatible = "regulator-fixed"; + regulator-name = "2v5"; + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <2500000>; + regulator-always-on; + }; + + dac@0 { + compatible = "ti,dac082s085"; + reg = <0>; + spi-max-frequency = <40000000>; + spi-cpol; + vref-supply = <&vref_2v5_reg>; + }; -- cgit v1.2.3 From 61011264c1afd8c075fb9028ccc78e7f2e63ce48 Mon Sep 17 00:00:00 2001 From: Lukas Wunner Date: Tue, 17 Oct 2017 12:42:00 +0200 Subject: iio: dac: Add Texas Instruments 8/10/12-bit 2/4-channel DAC driver The DACrrcS085 (rr = 08/10/12, c = 2/4) family of SPI DACs was inherited by TI when they acquired National Semiconductor in 2011. This driver was developed for and tested with the DAC082S085 built into the Revolution Pi by KUNBUS, but should work with any of the other chips as they share the same programming interface. There is also a family of I2C DACs with just a single channel called DACrr1C08x (rr = 08/10/12, x = 1/5). Their programming interface is very similar and it should be possible to extend the driver for these chips with moderate effort. Alternatively they could be integrated into ad5446.c. (The AD5301/AD5311/AD5321 use different power-down modes but otherwise appear to be comparable.) Furthermore there is a family of 8-channel DACs called DACrr8S085 (rr = 08/10/12) as well as two 16-bit DACs called DAC161Sxxx (xxx = 055/997). These are more complicated devices with support for daisy-chaining and the ability to power down each channel separately. They could either be handled by a separate driver or integrated into the present driver with a larger effort. Cc: Mathias Duckeck Signed-off-by: Lukas Wunner Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 3fc79185cc56..2e3f919485f4 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -522,6 +522,7 @@ Description: Specifies the output powerdown mode. DAC output stage is disconnected from the amplifier and 1kohm_to_gnd: connected to ground via an 1kOhm resistor, + 2.5kohm_to_gnd: connected to ground via a 2.5kOhm resistor, 6kohm_to_gnd: connected to ground via a 6kOhm resistor, 20kohm_to_gnd: connected to ground via a 20kOhm resistor, 90kohm_to_gnd: connected to ground via a 90kOhm resistor, -- cgit v1.2.3 From 2501ec14048d24d98651d2204cdf9cb33a127199 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Tue, 10 Oct 2017 22:08:55 -0700 Subject: dt-binding: soc: qcom: Add binding for rmtfs memory This adds the binding for describing shared memory used to exchange file system blocks between the RMTFS client and service. A client for this is generally found in the modem firmware and is used for accessing persistent storage for things such as radio calibration. Acked-by: Rob Herring Signed-off-by: Bjorn Andersson Signed-off-by: Andy Gross --- .../bindings/reserved-memory/qcom,rmtfs-mem.txt | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt new file mode 100644 index 000000000000..8562ba1dce69 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt @@ -0,0 +1,51 @@ +Qualcomm Remote File System Memory binding + +This binding describes the Qualcomm remote filesystem memory, which serves the +purpose of describing the shared memory region used for remote processors to +access block device data using the Remote Filesystem protocol. + +- compatible: + Usage: required + Value type: + Definition: must be: + "qcom,rmtfs-mem" + +- reg: + Usage: required for static allocation + Value type: + Definition: must specify base address and size of the memory region, + as described in reserved-memory.txt + +- size: + Usage: required for dynamic allocation + Value type: + Definition: must specify a size of the memory region, as described in + reserved-memory.txt + +- qcom,client-id: + Usage: required + Value type: + Definition: identifier of the client to use this region for buffers. + +- qcom,vmid: + Usage: optional + Value type: + Definition: vmid of the remote processor, to set up memory protection. + += EXAMPLE +The following example shows the remote filesystem memory setup for APQ8016, +with the rmtfs region for the Hexagon DSP (id #1) located at 0x86700000. + + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + ranges; + + rmtfs@86700000 { + compatible = "qcom,rmtfs-mem"; + reg = <0x0 0x86700000 0x0 0xe0000>; + no-map; + + qcom,client-id = <1>; + }; + }; -- cgit v1.2.3 From f7da4e6d29539bad2c29dd8ccb4ac628fe19f82b Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 9 Oct 2017 11:22:23 +0100 Subject: phy: rcar-gen2: Add r8a7743/5 support Add USB PHY support for r8a7743/5 SoC. Renesas RZ/G1[ME] (R8A7743/5) USB PHY is identical to the R-Car Gen2 family. Signed-off-by: Biju Das Acked-by: Simon Horman Acked-by: Rob Herring Reviewed-by: Geert Uytterhoeven Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt index 91da947ae9b6..eeb9e1874ea6 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt @@ -4,10 +4,13 @@ This file provides information on what the device node for the R-Car generation 2 USB PHY contains. Required properties: -- compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC. +- compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC. + "renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC. + "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC. "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC. "renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC. - "renesas,rcar-gen2-usb-phy" for a generic R-Car Gen2 compatible device. + "renesas,rcar-gen2-usb-phy" for a generic R-Car Gen2 or + RZ/G1 compatible device. When compatible with the generic version, nodes must list the SoC-specific version corresponding to the platform first -- cgit v1.2.3 From 6100ef093ba7b99efbb8b6c62b6af3c72fc82ddb Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Thu, 12 Oct 2017 15:34:48 +0900 Subject: phy: rcar-gen3-usb2: add binding for r8a77995 This patch adds binding for r8a77995 (R-Car D3). Since r8a77995 doesn't have dedicated pins (ID, VBUS), this will match against the generic fallback on R-Car D3. For now, this driver doesn't support usb role swap for r8a77995. Signed-off-by: Yoshihiro Shimoda Reviewed-by: Simon Horman Acked-by: Rob Herring Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt index ace9cce2704a..99b651b33110 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt @@ -8,6 +8,8 @@ Required properties: SoC. "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796 SoC. + "renesas,usb2-phy-r8a77995" if the device is a part of an + R8A77995 SoC. "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible device. When compatible with the generic version, nodes must list the -- cgit v1.2.3 From a7ac6570f67061576c51c5204a51f034af54adec Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Wed, 11 Oct 2017 17:53:10 -0700 Subject: dt-bindings: phy: Add RX equalizer properties for Broadcom SATA PHY Define two new properties: brcm,rx-aeq-mode which allows configuring the SATA PHY RX equalizers and when "manual" is used, brcm,rx-aeq can be used to set the exact value. Signed-off-by: Florian Fainelli Acked-by: Rob Herring Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/phy/brcm-sata-phy.txt | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt b/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt index 97977cd29a98..0aced97d8092 100644 --- a/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt +++ b/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt @@ -27,7 +27,16 @@ Sub-nodes optional properties: This property is not applicable for "brcm,iproc-ns2-sata-phy", "brcm,iproc-nsp-sata-phy" and "brcm,iproc-sr-sata-phy". -Example: +- brcm,rxaeq-mode: string that indicates the desired RX equalizer + mode, possible values are: + "off" (equivalent to not specifying the property) + "auto" + "manual" (brcm,rxaeq-value is used in that case) + +- brcm,rxaeq-value: when 'rxaeq-mode' is set to "manual", provides the RX + equalizer value that should be used. Allowed range is 0..63. + +Example sata-phy@f0458100 { compatible = "brcm,bcm7445-sata-phy", "brcm,phy-sata3"; reg = <0xf0458100 0x1e00>, <0xf045804c 0x10>; -- cgit v1.2.3 From 864326523fd58c5f33dc9fd8cb0585ff887ca837 Mon Sep 17 00:00:00 2001 From: "Martin K. Petersen" Date: Thu, 19 Oct 2017 10:20:03 -0400 Subject: scsi: Clarify SCSI core module parameter documentation Ever since it became possible to compile the SCSI core code as a module, the documentation describing the module parameters has been incorrect. Update the documentation to add a "scsi_mod." prefix to the relevant options. Reported-by: Laurence Oberman Signed-off-by: Martin K. Petersen --- Documentation/scsi/scsi-parameters.txt | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 8477655c0e46..453d4b79c78d 100644 --- a/Documentation/scsi/scsi-parameters.txt +++ b/Documentation/scsi/scsi-parameters.txt @@ -50,10 +50,11 @@ parameters may be changed at runtime by the command mac5380= [HW,SCSI] See drivers/scsi/mac_scsi.c. - max_luns= [SCSI] Maximum number of LUNs to probe. + scsi_mod.max_luns= + [SCSI] Maximum number of LUNs to probe. Should be between 1 and 2^32-1. - max_report_luns= + scsi_mod.max_report_luns= [SCSI] Maximum number of LUNs received. Should be between 1 and 16384. @@ -80,15 +81,17 @@ parameters may be changed at runtime by the command scsi_debug_*= [SCSI] See drivers/scsi/scsi_debug.c. - scsi_default_dev_flags= + scsi_mod.default_dev_flags= [SCSI] SCSI default device flags Format: - scsi_dev_flags= [SCSI] Black/white list entry for vendor and model + scsi_mod.dev_flags= + [SCSI] Black/white list entry for vendor and model Format: :: (flags are integer value) - scsi_logging_level= [SCSI] a bit mask of logging levels + scsi_mod.scsi_logging_level= + [SCSI] a bit mask of logging levels See drivers/scsi/scsi_logging.h for bits. Also settable via sysctl at dev.scsi.logging_level (/proc/sys/dev/scsi/logging_level). -- cgit v1.2.3 From fcc27785400a9993f258417f2ce7240890359565 Mon Sep 17 00:00:00 2001 From: Don Brace Date: Fri, 20 Oct 2017 14:11:51 -0500 Subject: scsi: smartpqi: correct spelling error in documentation Correct spelling error. Signed-off-by: Kevin Barnett Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen --- Documentation/scsi/smartpqi.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/scsi/smartpqi.txt b/Documentation/scsi/smartpqi.txt index ab377d9e5d1b..201f80c7c050 100644 --- a/Documentation/scsi/smartpqi.txt +++ b/Documentation/scsi/smartpqi.txt @@ -21,7 +21,7 @@ http://www.t10.org/members/w_pqi2.htm Supported devices: ------------------ - + smartpqi specific entries in /sys ----------------------------- -- cgit v1.2.3 From 1c59d045058750904926d5883ce8acdedbc52df3 Mon Sep 17 00:00:00 2001 From: Masahiro Yamada Date: Thu, 12 Oct 2017 20:36:15 +0900 Subject: dt-bindings: gpio: uniphier: add UniPhier GPIO binding This GPIO controller is used on UniPhier SoC family. The vendor specific property "socionext,interrupt-ranges" is for specifying interrupt mapping to the parent interrupt controller because the mapping is not contiguous. It works like "ranges", but transforms "interrupts" instead of "reg". Signed-off-by: Masahiro Yamada Acked-by: Rob Herring Signed-off-by: Linus Walleij --- .../devicetree/bindings/gpio/gpio-uniphier.txt | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-uniphier.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-uniphier.txt b/Documentation/devicetree/bindings/gpio/gpio-uniphier.txt new file mode 100644 index 000000000000..fed9158dd913 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-uniphier.txt @@ -0,0 +1,52 @@ +UniPhier GPIO controller + +Required properties: +- compatible: Should be "socionext,uniphier-gpio". +- reg: Specifies offset and length of the register set for the device. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells: Should be 2. The first cell is the pin number and the second + cell is used to specify optional parameters. +- interrupt-parent: Specifies the parent interrupt controller. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be 2. The first cell defines the interrupt number. + The second cell bits[3:0] is used to specify trigger type as follows: + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 4 = active high level-sensitive + 8 = active low level-sensitive + Valid combinations are 1, 2, 3, 4, 8. +- ngpios: Specifies the number of GPIO lines. +- gpio-ranges: Mapping to pin controller pins (as described in gpio.txt) +- socionext,interrupt-ranges: Specifies an interrupt number mapping between + this GPIO controller and its interrupt parent, in the form of arbitrary + number of triplets. + +Optional properties: +- gpio-ranges-group-names: Used for named gpio ranges (as described in gpio.txt) + +Example: + gpio: gpio@55000000 { + compatible = "socionext,uniphier-gpio"; + reg = <0x55000000 0x200>; + interrupt-parent = <&aidet>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl 0 0 0>; + gpio-ranges-group-names = "gpio_range"; + ngpios = <248>; + socionext,interrupt-ranges = <0 48 16>, <16 154 5>, <21 217 3>; + }; + +Consumer Example: + + sdhci0_pwrseq { + compatible = "mmc-pwrseq-emmc"; + reset-gpios = <&gpio UNIPHIER_GPIO_PORT(29, 4) GPIO_ACTIVE_LOW>; + }; + +Please note UNIPHIER_GPIO_PORT(29, 4) represents PORT294 in the SoC document. +Unfortunately, only the one's place is octal in the port numbering. (That is, +PORT 8, 9, 18, 19, 28, 29, ... are missing.) UNIPHIER_GPIO_PORT() is a helper +macro to calculate 29 * 8 + 4. -- cgit v1.2.3 From 2fbf8050dde85ed14a944035e1d7ca7eb8240eec Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Fri, 13 Oct 2017 16:26:40 +0800 Subject: dt-bindings: usb: mtk-xhci: add a optional property to disable u3ports Add a new optional property to disable u3ports Signed-off-by: Chunfeng Yun Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt index 5611a2e4ddf0..2d9b459bd890 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt @@ -38,6 +38,8 @@ Optional properties: mode; - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup control register, it depends on "mediatek,wakeup-src". + - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0, + bit1 for u3port1, ... etc; - vbus-supply : reference to the VBUS regulator; - usb3-lpm-capable : supports USB3.0 LPM - pinctrl-names : a pinctrl state named "default" must be defined -- cgit v1.2.3 From e7eef2ced8e7b2b4a06fd66e7d03df1f90fa67c9 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Fri, 13 Oct 2017 16:26:41 +0800 Subject: dt-bindings: usb: mtk-xhci: remove dummy clocks and add optional ones Remove dummy clocks for usb wakeup and add optional ones for MCU_BUS_CK and DMA_BUS_CK. Signed-off-by: Chunfeng Yun Acked-by: Rob Herring Reviewed-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/mediatek,mtk-xhci.txt | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt index 2d9b459bd890..30595964876a 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt @@ -26,10 +26,11 @@ Required properties: - clocks : a list of phandle + clock-specifier pairs, one for each entry in clock-names - clock-names : must contain - "sys_ck": for clock of xHCI MAC - "ref_ck": for reference clock of xHCI MAC - "wakeup_deb_p0": for USB wakeup debounce clock of port0 - "wakeup_deb_p1": for USB wakeup debounce clock of port1 + "sys_ck": controller clock used by normal mode, + the following ones are optional: + "ref_ck": reference clock used by low power mode etc, + "mcu_ck": mcu_bus clock for register access, + "dma_ck": dma_bus clock for data transfer by DMA - phys : a list of phandle + phy specifier pairs @@ -57,9 +58,7 @@ usb30: usb@11270000 { clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>, <&pericfg CLK_PERI_USB0>, <&pericfg CLK_PERI_USB1>; - clock-names = "sys_ck", "ref_ck", - "wakeup_deb_p0", - "wakeup_deb_p1"; + clock-names = "sys_ck", "ref_ck"; phys = <&phy_port0 PHY_TYPE_USB3>, <&phy_port1 PHY_TYPE_USB2>; vusb33-supply = <&mt6397_vusb_reg>; @@ -91,9 +90,8 @@ Required properties: - clocks : a list of phandle + clock-specifier pairs, one for each entry in clock-names - - clock-names : must be - "sys_ck": for clock of xHCI MAC - "ref_ck": for reference clock of xHCI MAC + - clock-names : must contain "sys_ck", and the following ones are optional: + "ref_ck", "mcu_ck" and "dma_ck" Optional properties: - vbus-supply : reference to the VBUS regulator; -- cgit v1.2.3 From 9053f4b9855c91f8905114c2108d5397be83bcf3 Mon Sep 17 00:00:00 2001 From: Anurag Kumar Vulisha Date: Mon, 21 Aug 2017 13:17:16 +0200 Subject: devicetree: bindings: Add sata port phy config parameters in ahci-ceva This patch adds device tree bindings for sata port phy parameters in the ahci-ceva.txt file. Signed-off-by: Anurag Kumar Vulisha Signed-off-by: Michal Simek Acked-by: Rob Herring Signed-off-by: Tejun Heo --- .../devicetree/bindings/ata/ahci-ceva.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/ahci-ceva.txt b/Documentation/devicetree/bindings/ata/ahci-ceva.txt index 7ca8b976c13a..7561cc4de371 100644 --- a/Documentation/devicetree/bindings/ata/ahci-ceva.txt +++ b/Documentation/devicetree/bindings/ata/ahci-ceva.txt @@ -5,6 +5,36 @@ Required properties: - compatible: Compatibility string. Must be 'ceva,ahci-1v84'. - clocks: Input clock specifier. Refer to common clock bindings. - interrupts: Interrupt specifier. Refer to interrupt binding. + - ceva,p0-cominit-params: OOB timing value for COMINIT parameter for port 0. + - ceva,p1-cominit-params: OOB timing value for COMINIT parameter for port 1. + The fields for the above parameter must be as shown below: + ceva,pN-cominit-params = /bits/ 8 ; + CINMP : COMINIT Negate Minimum Period. + CIBGN : COMINIT Burst Gap Nominal. + CIBGMX: COMINIT Burst Gap Maximum. + CIBGMN: COMINIT Burst Gap Minimum. + - ceva,p0-comwake-params: OOB timing value for COMWAKE parameter for port 0. + - ceva,p1-comwake-params: OOB timing value for COMWAKE parameter for port 1. + The fields for the above parameter must be as shown below: + ceva,pN-comwake-params = /bits/ 8 ; + CWBGMN: COMWAKE Burst Gap Minimum. + CWBGMX: COMWAKE Burst Gap Maximum. + CWBGN: COMWAKE Burst Gap Nominal. + CWNMP: COMWAKE Negate Minimum Period. + - ceva,p0-burst-params: Burst timing value for COM parameter for port 0. + - ceva,p1-burst-params: Burst timing value for COM parameter for port 1. + The fields for the above parameter must be as shown below: + ceva,pN-burst-params = /bits/ 8 ; + BMX: COM Burst Maximum. + BNM: COM Burst Nominal. + SFD: Signal Failure Detection value. + PTST: Partial to Slumber timer value. + - ceva,p0-retry-params: Retry interval timing value for port 0. + - ceva,p1-retry-params: Retry interval timing value for port 1. + The fields for the above parameter must be as shown below: + ceva,pN-retry-params = /bits/ 16 ; + RIT: Retry Interval Timer. + RCT: Rate Change Timer. Optional properties: - ceva,broken-gen2: limit to gen1 speed instead of gen2. @@ -16,5 +46,14 @@ Examples: interrupt-parent = <&gic>; interrupts = <0 133 4>; clocks = <&clkc SATA_CLK_ID>; + ceva,p0-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>; + ceva,p0-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>; + ceva,p0-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>; + ceva,p0-retry-params = /bits/ 16 <0x0216 0x7F06>; + + ceva,p1-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>; + ceva,p1-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>; + ceva,p1-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>; + ceva,p1-retry-params = /bits/ 16 <0x0216 0x7F06>; ceva,broken-gen2; }; -- cgit v1.2.3 From 8e0f1168f80acf6de4bcf68482e5e10d363d653c Mon Sep 17 00:00:00 2001 From: "Martin K. Petersen" Date: Mon, 23 Oct 2017 09:03:20 -0400 Subject: Documentation: Add my name to kernel enforcement statement The kernel enforcement statement commit had my Acked-by: but missed my name in the document signatures. Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index ba8c525eeee1..ce2c5130d37f 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -121,6 +121,7 @@ we might work for today, have in the past, or will in the future. - Ingo Molnar - Kuninori Morimoto - Trond Myklebust + - Martin K. Petersen (Oracle) - Borislav Petkov - Jiri Pirko - Josh Poimboeuf -- cgit v1.2.3 From 3f3d60d6254cfe0b1a2ab675ec1f72f232314eff Mon Sep 17 00:00:00 2001 From: Jacek Anaszewski Date: Mon, 9 Oct 2017 20:59:11 +0200 Subject: Documentation: leds: Update 00-INDEX file Add missing entries for the following documentation files: - leds-class-flash.txt - leds-lm3556.txt - leds-mlxcpld.txt - ledtrig-usbport.txt - uleds.txt Signed-off-by: Jacek Anaszewski Acked-by: Pavel Machek --- Documentation/leds/00-INDEX | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX index b4ef1f34e25f..ae626b29a740 100644 --- a/Documentation/leds/00-INDEX +++ b/Documentation/leds/00-INDEX @@ -4,6 +4,10 @@ leds-blinkm.txt - Driver for BlinkM LED-devices. leds-class.txt - documents LED handling under Linux. +leds-class-flash.txt + - documents flash LED handling under Linux. +leds-lm3556.txt + - notes on how to use the leds-lm3556 driver. leds-lp3944.txt - notes on how to use the leds-lp3944 driver. leds-lp5521.txt @@ -16,7 +20,13 @@ leds-lp55xx.txt - description about lp55xx common driver. leds-lm3556.txt - notes on how to use the leds-lm3556 driver. +leds-mlxcpld.txt + - notes on how to use the leds-mlxcpld driver. ledtrig-oneshot.txt - One-shot LED trigger for both sporadic and dense events. ledtrig-transient.txt - LED Transient Trigger, one shot timer activation. +ledtrig-usbport.txt + - notes on how to use the drivers/usb/core/ledtrig-usbport.c trigger. +uleds.txt + - notes on how to use the uleds driver. -- cgit v1.2.3 From d87e47e13a9b347801be08da81f16ae65f1eda0f Mon Sep 17 00:00:00 2001 From: Cao jin Date: Thu, 19 Oct 2017 11:17:05 +0800 Subject: kbuild doc: a bundle of fixes on makefiles.txt It does several fixes: 1. move the displaced ld example to its reasonable place. 2. add new example for command gzip. 3. fix 2 number errors. 4. fix format of chapter 7.x, make it looks the same as other chapters. Signed-off-by: Cao jin Signed-off-by: Masahiro Yamada --- Documentation/kbuild/makefiles.txt | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 329e740adea7..f6f80380dff2 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1108,14 +1108,6 @@ When kbuild executes, the following steps are followed (roughly): ld Link target. Often, LDFLAGS_$@ is used to set specific options to ld. - objcopy - Copy binary. Uses OBJCOPYFLAGS usually specified in - arch/$(ARCH)/Makefile. - OBJCOPYFLAGS_$@ may be used to set additional options. - - gzip - Compress target. Use maximum compression to compress target. - Example: #arch/x86/boot/Makefile LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary @@ -1139,6 +1131,19 @@ When kbuild executes, the following steps are followed (roughly): resulting in the target file being recompiled for no obvious reason. + objcopy + Copy binary. Uses OBJCOPYFLAGS usually specified in + arch/$(ARCH)/Makefile. + OBJCOPYFLAGS_$@ may be used to set additional options. + + gzip + Compress target. Use maximum compression to compress target. + + Example: + #arch/x86/boot/compressed/Makefile + $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE + $(call if_changed,gzip) + dtc Create flattened device tree blob object suitable for linking into vmlinux. Device tree blobs linked into vmlinux are placed @@ -1219,7 +1224,7 @@ When kbuild executes, the following steps are followed (roughly): that may be shared between individual architectures. The recommended approach how to use a generic header file is to list the file in the Kbuild file. - See "7.3 generic-y" for further info on syntax etc. + See "7.2 generic-y" for further info on syntax etc. --- 6.11 Post-link pass @@ -1254,13 +1259,13 @@ A Kbuild file may be defined under arch//include/uapi/asm/ and arch//include/asm/ to list asm files coming from asm-generic. See subsequent chapter for the syntax of the Kbuild file. - --- 7.1 no-export-headers +--- 7.1 no-export-headers no-export-headers is essentially used by include/uapi/linux/Kbuild to avoid exporting specific headers (e.g. kvm.h) on architectures that do not support it. It should be avoided as much as possible. - --- 7.2 generic-y +--- 7.2 generic-y If an architecture uses a verbatim copy of a header from include/asm-generic then this is listed in the file @@ -1287,7 +1292,7 @@ See subsequent chapter for the syntax of the Kbuild file. Example: termios.h #include - --- 7.3 generated-y +--- 7.3 generated-y If an architecture generates other header files alongside generic-y wrappers, generated-y specifies them. @@ -1299,7 +1304,7 @@ See subsequent chapter for the syntax of the Kbuild file. #arch/x86/include/asm/Kbuild generated-y += syscalls_32.h - --- 7.5 mandatory-y +--- 7.4 mandatory-y mandatory-y is essentially used by include/uapi/asm-generic/Kbuild.asm to define the minimum set of headers that must be exported in -- cgit v1.2.3 From 59ecbbe7b31cd2d86ff9a9f461a00f7e7533aedc Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Tue, 24 Oct 2017 11:22:49 +0100 Subject: locking/barriers: Kill lockless_dereference() lockless_dereference() is a nice idea, but it gained little traction in kernel code since its introduction three years ago. This is partly because it's a pain to type, but also because using READ_ONCE() instead has worked correctly on all architectures apart from Alpha, which is a fully supported but somewhat niche architecture these days. Now that READ_ONCE() has been upgraded to contain an implicit smp_read_barrier_depends() and the few callers of lockless_dereference() have been converted, we can remove lockless_dereference() altogether. Signed-off-by: Will Deacon Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1508840570-22169-5-git-send-email-will.deacon@arm.com Signed-off-by: Ingo Molnar --- Documentation/memory-barriers.txt | 12 ------------ Documentation/translations/ko_KR/memory-barriers.txt | 12 ------------ 2 files changed, 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index b759a60624fd..470a682f3fa4 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1886,18 +1886,6 @@ There are some more advanced barrier functions: See Documentation/atomic_{t,bitops}.txt for more information. - (*) lockless_dereference(); - - This can be thought of as a pointer-fetch wrapper around the - smp_read_barrier_depends() data-dependency barrier. - - This is also similar to rcu_dereference(), but in cases where - object lifetime is handled by some mechanism other than RCU, for - example, when the objects removed only when the system goes down. - In addition, lockless_dereference() is used in some data structures - that can be used both with and without RCU. - - (*) dma_wmb(); (*) dma_rmb(); diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index a7a813258013..ec3b46e27b7a 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -1858,18 +1858,6 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 참고하세요. - (*) lockless_dereference(); - - 이 함수는 smp_read_barrier_depends() 데이터 의존성 배리어를 사용하는 - 포인터 읽어오기 래퍼(wrapper) 함수로 생각될 수 있습니다. - - 객체의 라이프타임이 RCU 외의 메커니즘으로 관리된다는 점을 제외하면 - rcu_dereference() 와도 유사한데, 예를 들면 객체가 시스템이 꺼질 때에만 - 제거되는 경우 등입니다. 또한, lockless_dereference() 은 RCU 와 함께 - 사용될수도, RCU 없이 사용될 수도 있는 일부 데이터 구조에 사용되고 - 있습니다. - - (*) dma_wmb(); (*) dma_rmb(); -- cgit v1.2.3 From 0cc2b4e5a020fc7f4d1795741c116c983e9467d7 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 24 Oct 2017 15:20:45 +0200 Subject: PM / QoS: Fix device resume latency PM QoS The special value of 0 for device resume latency PM QoS means "no restriction", but there are two problems with that. First, device resume latency PM QoS requests with 0 as the value are always put in front of requests with positive values in the priority lists used internally by the PM QoS framework, causing 0 to be chosen as an effective constraint value. However, that 0 is then interpreted as "no restriction" effectively overriding the other requests with specific restrictions which is incorrect. Second, the users of device resume latency PM QoS have no way to specify that *any* resume latency at all should be avoided, which is an artificial limitation in general. To address these issues, modify device resume latency PM QoS to use S32_MAX as the "no constraint" value and 0 as the "no latency at all" one and rework its users (the cpuidle menu governor, the genpd QoS governor and the runtime PM framework) to follow these changes. Also add a special "n/a" value to the corresponding user space I/F to allow user space to indicate that it cannot accept any resume latencies at all for the given device. Fixes: 85dc0b8a4019 (PM / QoS: Make it possible to expose PM QoS latency constraints) Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323 Reported-by: Reinette Chatre Tested-by: Reinette Chatre Signed-off-by: Rafael J. Wysocki Acked-by: Alex Shi Cc: All applicable --- Documentation/ABI/testing/sysfs-devices-power | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 676fdf5f2a99..5cbb6f038615 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -211,7 +211,9 @@ Description: device, after it has been suspended at run time, from a resume request to the moment the device will be ready to process I/O, in microseconds. If it is equal to 0, however, this means that - the PM QoS resume latency may be arbitrary. + the PM QoS resume latency may be arbitrary and the special value + "n/a" means that user space cannot accept any resume latency at + all for the given device. Not all drivers support this attribute. If it isn't supported, it is not present. -- cgit v1.2.3 From ea09ec8c444c61446fb71952c6c50c8f7e8a8731 Mon Sep 17 00:00:00 2001 From: Baolin Wang Date: Tue, 24 Oct 2017 13:47:49 +0800 Subject: dt-bindings: dmaengine: Add Spreadtrum SC9860 DMA controller This patch adds the binding documentation for Spreadtrum SC9860 DMA controller device. Signed-off-by: Baolin Wang Acked-by: Rob Herring Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/sprd-dma.txt | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/sprd-dma.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/sprd-dma.txt b/Documentation/devicetree/bindings/dma/sprd-dma.txt new file mode 100644 index 000000000000..7a10fea2e51b --- /dev/null +++ b/Documentation/devicetree/bindings/dma/sprd-dma.txt @@ -0,0 +1,41 @@ +* Spreadtrum DMA controller + +This binding follows the generic DMA bindings defined in dma.txt. + +Required properties: +- compatible: Should be "sprd,sc9860-dma". +- reg: Should contain DMA registers location and length. +- interrupts: Should contain one interrupt shared by all channel. +- #dma-cells: must be <1>. Used to represent the number of integer + cells in the dmas property of client device. +- #dma-channels : Number of DMA channels supported. Should be 32. +- clock-names: Should contain the clock of the DMA controller. +- clocks: Should contain a clock specifier for each entry in clock-names. + +Example: + +Controller: +apdma: dma-controller@20100000 { + compatible = "sprd,sc9860-dma"; + reg = <0x20100000 0x4000>; + interrupts = ; + #dma-cells = <1>; + #dma-channels = <32>; + clock-names = "enable"; + clocks = <&clk_ap_ahb_gates 5>; +}; + + +Client: +DMA clients connected to the Spreadtrum DMA controller must use the format +described in the dma.txt file, using a two-cell specifier for each channel. +The two cells in order are: +1. A phandle pointing to the DMA controller. +2. The channel id. + +spi0: spi@70a00000{ + ... + dma-names = "rx_chn", "tx_chn"; + dmas = <&apdma 11>, <&apdma 12>; + ... +}; -- cgit v1.2.3 From 25309004c0e761986c9dc23526a03928a85188c0 Mon Sep 17 00:00:00 2001 From: Marcin Niestroj Date: Tue, 24 Oct 2017 11:06:41 -0700 Subject: Input: goodix - support gt1151 touchpanel Support was added based on Goodix GitHub repo [1]. There are two major differences between gt1151 and currently supported devices (gt9x): * CONFIG_DATA register has 0x8050 address instead of 0x8047, * config data checksum has 16-bit width instead of 8-bit. Also update goodix_i2c_test() function, so it reads ID register (which has the same address for all devices) instead of CONFIG_DATA (because its address is known only after reading ID of the device). [1] https://github.com/goodix/gt1x_driver_generic Signed-off-by: Marcin Niestroj Acked-by: Rob Herring Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt index c98757a69110..0c369d8ebcab 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt @@ -2,7 +2,8 @@ Device tree bindings for Goodix GT9xx series touchscreen controller Required properties: - - compatible : Should be "goodix,gt911" + - compatible : Should be "goodix,gt1151" + or "goodix,gt911" or "goodix,gt9110" or "goodix,gt912" or "goodix,gt927" -- cgit v1.2.3 From bbd11bddb398c4278c06892bd6498da34c47a00a Mon Sep 17 00:00:00 2001 From: Jianguo Sun Date: Mon, 23 Oct 2017 19:17:50 +0800 Subject: PCI: hisi: Add HiSilicon STB SoC PCIe controller driver Add a HiSilicon STB SoC PCIe controller driver. This controller is based on the DesignWare PCIe core. Signed-off-by: Jianguo Sun Signed-off-by: Shawn Guo Signed-off-by: Bjorn Helgaas --- .../bindings/pci/hisilicon-histb-pcie.txt | 68 ++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt new file mode 100644 index 000000000000..c84bc027930b --- /dev/null +++ b/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt @@ -0,0 +1,68 @@ +HiSilicon STB PCIe host bridge DT description + +The HiSilicon STB PCIe host controller is based on the DesignWare PCIe core. +It shares common functions with the DesignWare PCIe core driver and inherits +common properties defined in +Documentation/devicetree/bindings/pci/designware-pcie.txt. + +Additional properties are described here: + +Required properties +- compatible: Should be one of the following strings: + "hisilicon,hi3798cv200-pcie" +- reg: Should contain sysctl, rc_dbi, config registers location and length. +- reg-names: Must include the following entries: + "control": control registers of PCIe controller; + "rc-dbi": configuration space of PCIe controller; + "config": configuration transaction space of PCIe controller. +- bus-range: PCI bus numbers covered. +- interrupts: MSI interrupt. +- interrupt-names: Must include "msi" entries. +- clocks: List of phandle and clock specifier pairs as listed in clock-names + property. +- clock-name: Must include the following entries: + "aux": auxiliary gate clock; + "pipe": pipe gate clock; + "sys": sys gate clock; + "bus": bus gate clock. +- resets: List of phandle and reset specifier pairs as listed in reset-names + property. +- reset-names: Must include the following entries: + "soft": soft reset; + "sys": sys reset; + "bus": bus reset. + +Optional properties: +- reset-gpios: The gpio to generate PCIe PERST# assert and deassert signal. +- phys: List of phandle and phy mode specifier, should be 0. +- phy-names: Must be "phy". + +Example: + pcie@f9860000 { + compatible = "hisilicon,hi3798cv200-pcie"; + reg = <0xf9860000 0x1000>, + <0xf0000000 0x2000>, + <0xf2000000 0x01000000>; + reg-names = "control", "rc-dbi", "config"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + bus-range = <0 15>; + num-lanes = <1>; + ranges=<0x81000000 0 0 0xf4000000 0 0x00010000 + 0x82000000 0 0xf3000000 0xf3000000 0 0x01000000>; + interrupts = ; + interrupt-names = "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&crg PCIE_AUX_CLK>, + <&crg PCIE_PIPE_CLK>, + <&crg PCIE_SYS_CLK>, + <&crg PCIE_BUS_CLK>; + clock-names = "aux", "pipe", "sys", "bus"; + resets = <&crg 0x18c 6>, <&crg 0x18c 5>, <&crg 0x18c 4>; + reset-names = "soft", "sys", "bus"; + phys = <&combphy1 PHY_TYPE_PCIE>; + phy-names = "phy"; + }; -- cgit v1.2.3 From 3c535c94a0ba94e9852de3aae7b6c62413eb2af7 Mon Sep 17 00:00:00 2001 From: Guochun Mao Date: Thu, 21 Sep 2017 20:45:05 +0800 Subject: dt-bindings: mtd: add new compatible strings and improve description Add "mediatak,mt2712-nor" and "mediatek,mt7622-nor" for nor flash node's compatible strings. Explicate the fallback compatible. Acked-by: Rob Herring Signed-off-by: Guochun Mao Signed-off-by: Cyrille Pitchen --- Documentation/devicetree/bindings/mtd/mtk-quadspi.txt | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt index 840f9405dcf0..56d3668e2c50 100644 --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt @@ -1,13 +1,16 @@ * Serial NOR flash controller for MTK MT81xx (and similar) Required properties: -- compatible: The possible values are: - "mediatek,mt2701-nor" - "mediatek,mt7623-nor" +- compatible: For mt8173, compatible should be "mediatek,mt8173-nor", + and it's the fallback compatible for other Soc. + For every other SoC, should contain both the SoC-specific compatible + string and "mediatek,mt8173-nor". + The possible values are: + "mediatek,mt2701-nor", "mediatek,mt8173-nor" + "mediatek,mt2712-nor", "mediatek,mt8173-nor" + "mediatek,mt7622-nor", "mediatek,mt8173-nor" + "mediatek,mt7623-nor", "mediatek,mt8173-nor" "mediatek,mt8173-nor" - For mt8173, compatible should be "mediatek,mt8173-nor". - For every other SoC, should contain both the SoC-specific compatible string - and "mediatek,mt8173-nor". - reg: physical base address and length of the controller's register - clocks: the phandle of the clocks needed by the nor controller - clock-names: the names of the clocks -- cgit v1.2.3 From 3587679d93d0b0e4c31e5a2ad1dffdfcb77e8526 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Mon, 23 Oct 2017 14:07:24 -0700 Subject: locking/atomics, doc/filesystems: Convert ACCESS_ONCE() references For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is necessary to instrument reads and writes separately, which is not possible with ACCESS_ONCE(). This distinction is critical to correct operation. It's possible to transform the bulk of kernel code using the Coccinelle script below. However, this doesn't handle documentation, leaving references to ACCESS_ONCE() instances which have been removed. As a preparatory step, this patch converts the filesystems documentation to use {READ,WRITE}_ONCE() consistently. ---- virtual patch @ depends on patch @ expression E1, E2; @@ - ACCESS_ONCE(E1) = E2 + WRITE_ONCE(E1, E2) @ depends on patch @ expression E; @@ - ACCESS_ONCE(E) + READ_ONCE(E) ---- Signed-off-by: Paul E. McKenney Acked-by: Will Deacon Acked-by: Mark Rutland Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: davem@davemloft.net Cc: linux-arch@vger.kernel.org Cc: mpe@ellerman.id.au Cc: shuah@kernel.org Cc: snitzer@redhat.com Cc: thor.thayer@linux.intel.com Cc: tj@kernel.org Cc: viro@zeniv.linux.org.uk Link: http://lkml.kernel.org/r/1508792849-3115-14-git-send-email-paulmck@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- Documentation/filesystems/path-lookup.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.md b/Documentation/filesystems/path-lookup.md index 1b39e084a2b2..1933ef734e63 100644 --- a/Documentation/filesystems/path-lookup.md +++ b/Documentation/filesystems/path-lookup.md @@ -826,9 +826,9 @@ If the filesystem may need to revalidate dcache entries, then *is* passed the dentry but does not have access to the `inode` or the `seq` number from the `nameidata`, so it needs to be extra careful when accessing fields in the dentry. This "extra care" typically -involves using `ACCESS_ONCE()` or the newer [`READ_ONCE()`] to access -fields, and verifying the result is not NULL before using it. This -pattern can be see in `nfs_lookup_revalidate()`. +involves using [`READ_ONCE()`] to access fields, and verifying the +result is not NULL before using it. This pattern can be seen in +`nfs_lookup_revalidate()`. A pair of patterns ------------------ -- cgit v1.2.3 From d141babe4244945f1d001118578e0eb3ce12729d Mon Sep 17 00:00:00 2001 From: Byungchul Park Date: Wed, 25 Oct 2017 17:56:00 +0900 Subject: locking/lockdep: Add a boot parameter allowing unwind in cross-release and disable it by default Johan Hovold reported a heavy performance regression caused by lockdep cross-release: > Boot time (from "Linux version" to login prompt) had in fact doubled > since 4.13 where it took 17 seconds (with my current config) compared to > the 35 seconds I now see with 4.14-rc4. > > I quick bisect pointed to lockdep and specifically the following commit: > > 28a903f63ec0 ("locking/lockdep: Handle non(or multi)-acquisition > of a crosslock") > > which I've verified is the commit which doubled the boot time (compared > to 28a903f63ec0^) (added by lockdep crossrelease series [1]). Currently cross-release performs unwind on every acquisition, but that is very expensive. This patch makes unwind optional and disables it by default and only records acquire_ip. Full stack traces are sometimes required for full analysis, in which case a boot paramter, crossrelease_fullstack, can be specified. On my qemu Ubuntu machine (x86_64, 4 cores, 512M), the regression was fixed. We measure boot times with 'perf stat --null --repeat 10 $QEMU', where $QEMU launches a kernel with init=/bin/true: 1. No lockdep enabled: Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 2.756558155 seconds time elapsed ( +- 0.09% ) 2. Lockdep enabled: Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 2.968710420 seconds time elapsed ( +- 0.12% ) 3. Lockdep enabled + cross-release enabled: Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 3.153839636 seconds time elapsed ( +- 0.31% ) 4. Lockdep enabled + cross-release enabled + this patch applied: Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 2.963669551 seconds time elapsed ( +- 0.11% ) I.e. lockdep cross-release performance is now indistinguishable from vanilla lockdep. Bisected-by: Johan Hovold Analyzed-by: Thomas Gleixner Suggested-by: Thomas Gleixner Reported-by: Johan Hovold Signed-off-by: Byungchul Park Cc: Linus Torvalds Cc: Peter Zijlstra Cc: amir73il@gmail.com Cc: axboe@kernel.dk Cc: darrick.wong@oracle.com Cc: david@fromorbit.com Cc: hch@infradead.org Cc: idryomov@gmail.com Cc: johannes.berg@intel.com Cc: kernel-team@lge.com Cc: linux-block@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-xfs@vger.kernel.org Cc: oleg@redhat.com Cc: tj@kernel.org Link: http://lkml.kernel.org/r/1508921765-15396-5-git-send-email-byungchul.park@lge.com Signed-off-by: Ingo Molnar --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 05496622b4ef..f20ed5e0a720 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -709,6 +709,9 @@ It will be ignored when crashkernel=X,high is not used or memory reserved is below 4G. + crossrelease_fullstack + [KNL] Allow to record full stack trace in cross-release + cryptomgr.notests [KNL] Disable crypto self-tests -- cgit v1.2.3 From 1901142ba8d5bf9f21b86d33770be8309071c25d Mon Sep 17 00:00:00 2001 From: Sean Wang Date: Mon, 23 Oct 2017 15:16:44 +0800 Subject: dt-bindings: rtc: mediatek: add bindings for MediaTek SoC based RTC Add device-tree binding for MediaTek SoC based RTC Cc: devicetree@vger.kernel.org Signed-off-by: Sean Wang Acked-by: Rob Herring Signed-off-by: Alexandre Belloni --- .../devicetree/bindings/rtc/rtc-mt7622.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt7622.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt7622.txt b/Documentation/devicetree/bindings/rtc/rtc-mt7622.txt new file mode 100644 index 000000000000..09fe8f51476f --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-mt7622.txt @@ -0,0 +1,21 @@ +Device-Tree bindings for MediaTek SoC based RTC + +Required properties: +- compatible : Should be + "mediatek,mt7622-rtc", "mediatek,soc-rtc" : for MT7622 SoC +- reg : Specifies base physical address and size of the registers; +- interrupts : Should contain the interrupt for RTC alarm; +- clocks : Specifies list of clock specifiers, corresponding to + entries in clock-names property; +- clock-names : Should contain "rtc" entries + +Example: + +rtc: rtc@10212800 { + compatible = "mediatek,mt7622-rtc", + "mediatek,soc-rtc"; + reg = <0 0x10212800 0 0x200>; + interrupts = ; + clocks = <&topckgen CLK_TOP_RTC>; + clock-names = "rtc"; +}; -- cgit v1.2.3 From 7e577a17f2eefeef32f1106ebf91e7cd143ba654 Mon Sep 17 00:00:00 2001 From: Ahmet Inan Date: Sat, 14 Oct 2017 10:10:53 -0700 Subject: Input: add I2C attached EETI EXC3000 multi touch driver The 3000 series have a new protocol which allows to report up to 5 points in a single 66 byte frame. One must always read in 66 byte frames. To support up to 10 points, two consecutive frames need to be read: The first frame says how many points until sync. The second frame must say zero points or both frames must be discarded. To be able to work with the higher 400KHz I2C bus rate, one must successfully send a special package prior _each_ read or the controller will refuse to cooperate. This is a minimal implementation based on egalax_i2c.c (which can be found on the internet) and egalax_ts.c but without the vendor interface and no power management support. Signed-off-by: Ahmet Inan Acked-by: Rob Herring Signed-off-by: Dmitry Torokhov --- .../bindings/input/touchscreen/exc3000.txt | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/exc3000.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/exc3000.txt b/Documentation/devicetree/bindings/input/touchscreen/exc3000.txt new file mode 100644 index 000000000000..1dcff4a43eaa --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/exc3000.txt @@ -0,0 +1,27 @@ +* EETI EXC3000 Multiple Touch Controller + +Required properties: +- compatible: must be "eeti,exc3000" +- reg: i2c slave address +- interrupt-parent: the phandle for the interrupt controller +- interrupts: touch controller interrupt +- touchscreen-size-x: See touchscreen.txt +- touchscreen-size-y: See touchscreen.txt + +Optional properties: +- touchscreen-inverted-x: See touchscreen.txt +- touchscreen-inverted-y: See touchscreen.txt +- touchscreen-swapped-x-y: See touchscreen.txt + +Example: + + touchscreen@2a { + compatible = "eeti,exc3000"; + reg = <0x2a>; + interrupt-parent = <&gpio1>; + interrupts = <9 IRQ_TYPE_LEVEL_LOW>; + touchscreen-size-x = <4096>; + touchscreen-size-y = <4096>; + touchscreen-inverted-x; + touchscreen-swapped-x-y; + }; -- cgit v1.2.3 From 50be28a654ff04b282dfcb06ad5d0b20556242cb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20F=C3=A4rber?= Date: Sun, 1 Oct 2017 15:45:52 +0200 Subject: dt-bindings: Add vendor prefix for MeLE MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MeLE is a Chinese manufacturer of TV boxes and Mini PCs. Cc: meleservice@mele.cn Acked-by: Rob Herring Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index d17d01a160de..3618b23fa067 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -197,6 +197,7 @@ 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 -- cgit v1.2.3 From d109cbf1842fbfca57ab33323ca63be48a8efa53 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20F=C3=A4rber?= Date: Mon, 16 Oct 2017 04:45:54 +0200 Subject: dt-bindings: arm: realtek: Document MeLE V9 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Define a compatible string for MeLE V9 Media Player. Cc: meleservice@mele.cn Acked-by: Rob Herring Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/realtek.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt index 297c15eb81e2..95839e19ae92 100644 --- a/Documentation/devicetree/bindings/arm/realtek.txt +++ b/Documentation/devicetree/bindings/arm/realtek.txt @@ -12,6 +12,7 @@ Required root node properties: Root node property compatible must contain, depending on board: + - MeLE V9: "mele,v9" - ProBox2 AVA: "probox2,ava" - Zidoo X9S: "zidoo,x9s" -- cgit v1.2.3 From 3fa30ae9ff4a29e677b4800036f755517a27dd9e Mon Sep 17 00:00:00 2001 From: Marco Franchi Date: Wed, 25 Oct 2017 15:24:50 -0200 Subject: ASoC: sgtl5000: Remove leading zero from '@0a' notation Improve the binding example by removing the leading 0 from '@0a' notation, which fixes the following build warning: Warning (unit_address_format): Node /sgtl5000@0a unit name should not have leading 0s Signed-off-by: Marco Franchi Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/sgtl5000.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.txt b/Documentation/devicetree/bindings/sound/sgtl5000.txt index 7a73a9d62015..060cb4a3b47e 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.txt +++ b/Documentation/devicetree/bindings/sound/sgtl5000.txt @@ -37,7 +37,7 @@ VDDIO 1.8V 2.5V 3.3V Example: -codec: sgtl5000@0a { +codec: sgtl5000@a { compatible = "fsl,sgtl5000"; reg = <0x0a>; clocks = <&clks 150>; -- cgit v1.2.3 From 26284ca918e4e271bae4e96129fc3791b9bf0983 Mon Sep 17 00:00:00 2001 From: Marco Franchi Date: Wed, 25 Oct 2017 16:57:13 -0200 Subject: ASoC: pfuze100: Remove leading zero from '@08' notation Improve the binding example by removing the leading 0 from '@08' notation, which fixes the following build warnings: Warning (unit_address_format): Node /pfuze100@08 unit name should not have leading 0s Warning (unit_address_format): Node /pfuze200@08 unit name should not have leading 0s Warning (unit_address_format): Node /pfuze3000@08 unit name should not have leading 0s Signed-off-by: Marco Franchi Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/pfuze100.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt b/Documentation/devicetree/bindings/regulator/pfuze100.txt index 444c47831a40..c6dd3f5e485b 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.txt +++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt @@ -21,7 +21,7 @@ Each regulator is defined using the standard binding for regulators. Example 1: PFUZE100 - pmic: pfuze100@08 { + pmic: pfuze100@8 { compatible = "fsl,pfuze100"; reg = <0x08>; @@ -122,7 +122,7 @@ Example 1: PFUZE100 Example 2: PFUZE200 - pmic: pfuze200@08 { + pmic: pfuze200@8 { compatible = "fsl,pfuze200"; reg = <0x08>; @@ -216,7 +216,7 @@ Example 2: PFUZE200 Example 3: PFUZE3000 - pmic: pfuze3000@08 { + pmic: pfuze3000@8 { compatible = "fsl,pfuze3000"; reg = <0x08>; -- cgit v1.2.3 From d41bf8c9deaed1a90b18d3ffc5639d4c19f0259a Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Mon, 23 Oct 2017 16:18:27 -0700 Subject: cgroup, sched: Move basic cpu stats from cgroup.stat to cpu.stat The basic cpu stat is currently shown with "cpu." prefix in cgroup.stat, and the same information is duplicated in cpu.stat when cpu controller is enabled. This is ugly and not very scalable as we want to expand the coverage of stat information which is always available. This patch makes cgroup core always create "cpu.stat" file and show the basic cpu stat there and calls the cpu controller to show the extra stats when enabled. This ensures that the same information isn't presented in multiple places and makes future expansion of basic stats easier. Signed-off-by: Tejun Heo Acked-by: Peter Zijlstra (Intel) --- Documentation/cgroup-v2.txt | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt index 0bbdc720dd7c..779211fbb69f 100644 --- a/Documentation/cgroup-v2.txt +++ b/Documentation/cgroup-v2.txt @@ -886,15 +886,6 @@ All cgroup core files are prefixed with "cgroup." A dying cgroup can consume system resources not exceeding limits, which were active at the moment of cgroup deletion. - cpu.usage_usec - CPU time consumed in the subtree. - - cpu.user_usec - User CPU time consumed in the subtree. - - cpu.system_usec - System CPU time consumed in the subtree. - Controllers =========== @@ -915,12 +906,16 @@ All time durations are in microseconds. cpu.stat A read-only flat-keyed file which exists on non-root cgroups. + This file exists whether the controller is enabled or not. - It reports the following six stats: + It always reports the following three stats: - usage_usec - user_usec - system_usec + + and the following three when the controller is enabled: + - nr_periods - nr_throttled - throttled_usec -- cgit v1.2.3 From b2b60bcc7d0940f02858b1721499df9674f685e5 Mon Sep 17 00:00:00 2001 From: Leon Luo Date: Thu, 5 Oct 2017 02:06:20 +0200 Subject: media: imx274: device tree binding file MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The binding file for imx274 CMOS sensor V4l2 driver Signed-off-by: Leon Luo Acked-by: Sören Brinkmann Acked-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/i2c/imx274.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/imx274.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/imx274.txt b/Documentation/devicetree/bindings/media/i2c/imx274.txt new file mode 100644 index 000000000000..80f2e89568e1 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/imx274.txt @@ -0,0 +1,33 @@ +* Sony 1/2.5-Inch 8.51Mp CMOS Digital Image Sensor + +The Sony imx274 is a 1/2.5-inch CMOS active pixel digital image sensor with +an active array size of 3864H x 2202V. It is programmable through I2C +interface. The I2C address is fixed to 0x1a as per sensor data sheet. +Image data is sent through MIPI CSI-2, which is configured as 4 lanes +at 1440 Mbps. + + +Required Properties: +- compatible: value should be "sony,imx274" for imx274 sensor +- reg: I2C bus address of the device + +Optional Properties: +- reset-gpios: Sensor reset GPIO + +The imx274 device node should contain one 'port' child node with +an 'endpoint' subnode. For further reading on port node refer to +Documentation/devicetree/bindings/media/video-interfaces.txt. + +Example: + sensor@1a { + compatible = "sony,imx274"; + reg = <0x1a>; + #address-cells = <1>; + #size-cells = <0>; + reset-gpios = <&gpio_sensor 0 0>; + port { + sensor_out: endpoint { + remote-endpoint = <&csiss_in>; + }; + }; + }; -- cgit v1.2.3 From d524b8fc75f1ad8132b6661b48a8cbfba37ecc2b Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sat, 15 Jul 2017 10:51:24 +0200 Subject: media: dt-bindings: document the tegra CEC bindings This documents the binding for the Tegra CEC module. Signed-off-by: Hans Verkuil Acked-by: Rob Herring Acked-by: Thierry Reding Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/tegra-cec.txt | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt b/Documentation/devicetree/bindings/media/tegra-cec.txt new file mode 100644 index 000000000000..c503f06f3b84 --- /dev/null +++ b/Documentation/devicetree/bindings/media/tegra-cec.txt @@ -0,0 +1,27 @@ +* Tegra HDMI CEC hardware + +The HDMI CEC module is present in Tegra SoCs and its purpose is to +handle communication between HDMI connected devices over the CEC bus. + +Required properties: + - compatible : value should be one of the following: + "nvidia,tegra114-cec" + "nvidia,tegra124-cec" + "nvidia,tegra210-cec" + - reg : Physical base address of the IP registers and length of memory + mapped region. + - interrupts : HDMI CEC interrupt number to the CPU. + - clocks : from common clock binding: handle to HDMI CEC clock. + - clock-names : from common clock binding: must contain "cec", + corresponding to the entry in the clocks property. + - hdmi-phandle : phandle to the HDMI controller, see also cec.txt. + +Example: + +cec@70015000 { + compatible = "nvidia,tegra124-cec"; + reg = <0x0 0x70015000 0x0 0x00001000>; + interrupts = ; + clocks = <&tegra_car TEGRA124_CLK_CEC>; + clock-names = "cec"; +}; -- cgit v1.2.3 From fcc046801b934ad27ba80e20e3e0f4c97957af58 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 21 Sep 2017 14:52:29 +0200 Subject: dt-bindings: i2c: i2c-mux: spelling s/required is/required if/ Fix both instances. Signed-off-by: Geert Uytterhoeven Signed-off-by: Peter Rosin --- Documentation/devicetree/bindings/i2c/i2c-mux.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux.txt index 212e6779dc5c..b38f58a1c878 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux.txt @@ -6,10 +6,10 @@ multiplexer/switch will have one child node for each child bus. Optional properties: - #address-cells = <1>; - This property is required is the i2c-mux child node does not exist. + This property is required if the i2c-mux child node does not exist. - #size-cells = <0>; - This property is required is the i2c-mux child node does not exist. + This property is required if the i2c-mux child node does not exist. - i2c-mux For i2c multiplexers/switches that have child nodes that are a mixture -- cgit v1.2.3 From 63d51e36b5add80bb2d94e67de3d643854faaf10 Mon Sep 17 00:00:00 2001 From: Rob Clark Date: Mon, 16 Oct 2017 17:04:16 -0400 Subject: dt-bindings: display: msm: update clk names Now that drm/msm is converted over to use msm_get_clk() everywhere (that matters), which handles falling back to looking for a clock with the "_clk" suffix, we can remove "_clk" from the documentation so that new dts files added do not include "_clk" in the name. Previously we were doing this for the more recently upstreamed bindings but not for (nearly) all. Signed-off-by: Rob Clark Acked-by: Rob Herring --- .../devicetree/bindings/display/msm/dsi.txt | 36 +++++++++++----------- .../devicetree/bindings/display/msm/edp.txt | 20 ++++++------ .../devicetree/bindings/display/msm/hdmi.txt | 8 ++--- .../devicetree/bindings/display/msm/mdp5.txt | 32 +++++++++---------- 4 files changed, 48 insertions(+), 48 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index fa00e62e1cf6..a6671bd2c85a 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -13,16 +13,16 @@ Required properties: - power-domains: Should be <&mmcc MDSS_GDSC>. - clocks: Phandles to device clocks. - clock-names: the following clocks are required: - * "mdp_core_clk" - * "iface_clk" - * "bus_clk" - * "core_mmss_clk" - * "byte_clk" - * "pixel_clk" - * "core_clk" + * "mdp_core" + * "iface" + * "bus" + * "core_mmss" + * "byte" + * "pixel" + * "core" For DSIv2, we need an additional clock: - * "src_clk" -- assigned-clocks: Parents of "byte_clk" and "pixel_clk" for the given platform. + * "src" +- assigned-clocks: Parents of "byte" and "pixel" for the given platform. - assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block. See [1] for details on clock bindings. - vdd-supply: phandle to vdd regulator device node @@ -101,7 +101,7 @@ Required properties: - power-domains: Should be <&mmcc MDSS_GDSC>. - clocks: Phandles to device clocks. See [1] for details on clock bindings. - clock-names: the following clocks are required: - * "iface_clk" + * "iface" - vddio-supply: phandle to vdd-io regulator device node Optional properties: @@ -123,13 +123,13 @@ Example: reg = <0xfd922800 0x200>; power-domains = <&mmcc MDSS_GDSC>; clock-names = - "bus_clk", - "byte_clk", - "core_clk", - "core_mmss_clk", - "iface_clk", - "mdp_core_clk", - "pixel_clk"; + "bus", + "byte", + "core", + "core_mmss", + "iface", + "mdp_core", + "pixel"; clocks = <&mmcc MDSS_AXI_CLK>, <&mmcc MDSS_BYTE0_CLK>, @@ -207,7 +207,7 @@ Example: reg = <0xfd922a00 0xd4>, <0xfd922b00 0x2b0>, <0xfd922d80 0x7b>; - clock-names = "iface_clk"; + clock-names = "iface"; clocks = <&mmcc MDSS_AHB_CLK>; #clock-cells = <1>; vddio-supply = <&pma8084_l12>; diff --git a/Documentation/devicetree/bindings/display/msm/edp.txt b/Documentation/devicetree/bindings/display/msm/edp.txt index e63032be5401..95ce19ca7bc5 100644 --- a/Documentation/devicetree/bindings/display/msm/edp.txt +++ b/Documentation/devicetree/bindings/display/msm/edp.txt @@ -12,11 +12,11 @@ Required properties: - clocks: device clocks See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. - clock-names: the following clocks are required: - * "core_clk" - * "iface_clk" - * "mdp_core_clk" - * "pixel_clk" - * "link_clk" + * "core" + * "iface" + * "mdp_core" + * "pixel" + * "link" - #clock-cells: The value should be 1. - vdda-supply: phandle to vdda regulator device node - lvl-vdd-supply: phandle to regulator device node which is used to supply power @@ -41,11 +41,11 @@ Example: interrupts = <12 0>; power-domains = <&mmcc MDSS_GDSC>; clock-names = - "core_clk", - "pixel_clk", - "iface_clk", - "link_clk", - "mdp_core_clk"; + "core", + "pixel", + "iface", + "link", + "mdp_core"; clocks = <&mmcc MDSS_EDPAUX_CLK>, <&mmcc MDSS_EDPPIXEL_CLK>, diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt b/Documentation/devicetree/bindings/display/msm/hdmi.txt index 2d306f402d18..5f90a40da51b 100644 --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt +++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt @@ -64,9 +64,9 @@ Example: interrupts = ; power-domains = <&mmcc MDSS_GDSC>; clock-names = - "core_clk", - "master_iface_clk", - "slave_iface_clk"; + "core", + "master_iface", + "slave_iface"; clocks = <&mmcc HDMI_APP_CLK>, <&mmcc HDMI_M_AHB_CLK>, @@ -92,7 +92,7 @@ Example: <0x4a00500 0x100>; #phy-cells = <0>; power-domains = <&mmcc MDSS_GDSC>; - clock-names = "slave_iface_clk"; + clock-names = "slave_iface"; clocks = <&mmcc HDMI_S_AHB_CLK>; core-vdda-supply = <&pm8921_hdmi_mvs>; }; diff --git a/Documentation/devicetree/bindings/display/msm/mdp5.txt b/Documentation/devicetree/bindings/display/msm/mdp5.txt index 30c11ea83754..1b31977a68ba 100644 --- a/Documentation/devicetree/bindings/display/msm/mdp5.txt +++ b/Documentation/devicetree/bindings/display/msm/mdp5.txt @@ -22,16 +22,16 @@ Required properties: Documentation/devicetree/bindings/power/power_domain.txt - clocks: device clocks. See ../clocks/clock-bindings.txt for details. - clock-names: the following clocks are required. - * "iface_clk" - * "bus_clk" - * "vsync_clk" + * "iface" + * "bus" + * "vsync" - #address-cells: number of address cells for the MDSS children. Should be 1. - #size-cells: Should be 1. - ranges: parent bus address space is the same as the child bus address space. Optional properties: - clock-names: the following clocks are optional: - * "lut_clk" + * "lut" MDP5: Required properties: @@ -45,10 +45,10 @@ Required properties: through MDP block - clocks: device clocks. See ../clocks/clock-bindings.txt for details. - clock-names: the following clocks are required. -- * "bus_clk" -- * "iface_clk" -- * "core_clk" -- * "vsync_clk" +- * "bus" +- * "iface" +- * "core" +- * "vsync" - ports: contains the list of output ports from MDP. These connect to interfaces that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a special case since it is a part of the MDP block itself). @@ -77,7 +77,7 @@ Required properties: Optional properties: - clock-names: the following clocks are optional: - * "lut_clk" + * "lut" Example: @@ -95,9 +95,9 @@ Example: clocks = <&gcc GCC_MDSS_AHB_CLK>, <&gcc GCC_MDSS_AXI_CLK>, <&gcc GCC_MDSS_VSYNC_CLK>; - clock-names = "iface_clk", - "bus_clk", - "vsync_clk" + clock-names = "iface", + "bus", + "vsync" interrupts = <0 72 0>; @@ -120,10 +120,10 @@ Example: <&gcc GCC_MDSS_AXI_CLK>, <&gcc GCC_MDSS_MDP_CLK>, <&gcc GCC_MDSS_VSYNC_CLK>; - clock-names = "iface_clk", - "bus_clk", - "core_clk", - "vsync_clk"; + clock-names = "iface", + "bus", + "core", + "vsync"; ports { #address-cells = <1>; -- cgit v1.2.3 From 69d17246ab255dda8e71c8d65396b4aa6121b7ad Mon Sep 17 00:00:00 2001 From: Phil Reid Date: Thu, 24 Aug 2017 17:31:03 +0800 Subject: i2c: i2c-smbus: add of_i2c_setup_smbus_alert This commit adds of_i2c_setup_smbus_alert which allows the smbalert driver to be attached to an i2c adapter via the device tree. Signed-off-by: Phil Reid Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index cee9d5055fa2..11263982470e 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -59,8 +59,8 @@ wants to support one of the below features, it should adapt the bindings below. interrupts used by the device. - interrupt-names - "irq" and "wakeup" names are recognized by I2C core, other names are - left to individual drivers. + "irq", "wakeup" and "smbus_alert" names are recognized by I2C core, + other names are left to individual drivers. - host-notify device uses SMBus host notify protocol instead of interrupt line. -- cgit v1.2.3 From 26b61a652f6d52ec9c14f6be7c5a854a4fe831ae Mon Sep 17 00:00:00 2001 From: Karl-Heinz Schneider Date: Thu, 24 Aug 2017 17:31:07 +0800 Subject: Documentation: Add sbs-manager device tree node documentation This patch adds device tree documentation for the sbs-manager Signed-off-by: Karl-Heinz Schneider Signed-off-by: Phil Reid Acked-by: Rob Herring Reviewed-by: Sebastian Reichel Signed-off-by: Wolfram Sang --- .../bindings/power/supply/sbs,sbs-manager.txt | 66 ++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt new file mode 100644 index 000000000000..4b2195571a49 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt @@ -0,0 +1,66 @@ +Binding for sbs-manager + +Required properties: +- compatible: ",", "sbs,sbs-charger" as fallback. The part + number compatible string might be used in order to take care of vendor + specific registers. +- reg: integer, i2c address of the device. Should be <0xa>. +Optional properties: +- gpio-controller: Marks the port as GPIO controller. + See "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt. +- #gpio-cells: Should be <2>. The first cell is the pin number, the second cell + is used to specify optional parameters: + See "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt. + +From OS view the device is basically an i2c-mux used to communicate with up to +four smart battery devices at address 0xb. The driver actually implements this +behaviour. So standard i2c-mux nodes can be used to register up to four slave +batteries. Channels will be numerated starting from 1 to 4. + +Example: + +batman@a { + compatible = "lltc,ltc1760", "sbs,sbs-manager"; + reg = <0x0a>; + #address-cells = <1>; + #size-cells = <0>; + + gpio-controller; + #gpio-cells = <2>; + + i2c@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + battery@b { + compatible = "ti,bq2060", "sbs,sbs-battery"; + reg = <0x0b>; + sbs,battery-detect-gpios = <&batman 1 1>; + }; + }; + + i2c@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + + battery@b { + compatible = "ti,bq2060", "sbs,sbs-battery"; + reg = <0x0b>; + sbs,battery-detect-gpios = <&batman 2 1>; + }; + }; + + i2c@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + + battery@b { + compatible = "ti,bq2060", "sbs,sbs-battery"; + reg = <0x0b>; + sbs,battery-detect-gpios = <&batman 3 1>; + }; + }; +}; -- cgit v1.2.3 From a190d04db93710ae166749055b6985397c6d13f5 Mon Sep 17 00:00:00 2001 From: Mahesh Bandewar Date: Thu, 26 Oct 2017 15:09:21 -0700 Subject: ipvlan: introduce 'private' attribute for all existing modes. IPvlan has always operated in bridge mode. However there are scenarios where each slave should be able to talk through the master device but not necessarily across each other. Think of an environment where each of a namespace is a private and independant customer. In this scenario the machine which is hosting these namespaces neither want to tell who their neighbor is nor the individual namespaces care to talk to neighbor on short-circuited network path. This patch implements the mode that is very similar to the 'private' mode in macvlan where individual slaves can send and receive traffic through the master device, just that they can not talk among slave devices. Signed-off-by: Mahesh Bandewar Signed-off-by: David S. Miller --- Documentation/networking/ipvlan.txt | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ipvlan.txt b/Documentation/networking/ipvlan.txt index 1fe42a874aae..bfa91c77a4c9 100644 --- a/Documentation/networking/ipvlan.txt +++ b/Documentation/networking/ipvlan.txt @@ -22,9 +22,19 @@ The driver can be built into the kernel (CONFIG_IPVLAN=y) or as a module There are no module parameters for this driver and it can be configured using IProute2/ip utility. - ip link add link name type ipvlan mode { l2 | l3 | l3s } + ip link add link name type ipvlan [ mode MODE ] [ FLAGS ] + where + MODE: l3 (default) | l3s | l2 + FLAGS: bridge (default) | private - e.g. ip link add link eth0 name ipvl0 type ipvlan mode l2 + e.g. + (a) Following will create IPvlan link with eth0 as master in + L3 bridge mode + bash# ip link add link eth0 name ipvl0 type ipvlan + (b) This command will create IPvlan link in L2 bridge mode. + bash# ip link add link eth0 name ipvl0 type ipvlan mode l2 bridge + (c) This command will create an IPvlan device in L2 private mode. + bash# ip link add link eth0 name ipvlan type ipvlan mode l2 private 4. Operating modes: @@ -54,7 +64,21 @@ works in this mode and hence it is L3-symmetric (L3s). This will have slightly l performance but that shouldn't matter since you are choosing this mode over plain-L3 mode to make conn-tracking work. -5. What to choose (macvlan vs. ipvlan)? +5. Mode flags: + At this time following mode flags are available + +5.1 bridge: + This is the default option. To configure the IPvlan port in this mode, +user can choose to either add this option on the command-line or don't specify +anything. This is the traditional mode where slaves can cross-talk among +themseleves apart from talking through the master device. + +5.2 private: + If this option is added to the command-line, the port is set in private +mode. i.e. port wont allow cross communication between slaves. + + +6. What to choose (macvlan vs. ipvlan)? These two devices are very similar in many regards and the specific use case could very well define which device to choose. if one of the following situations defines your use case then you can choose to use ipvlan - -- cgit v1.2.3 From fe89aa6b250c1011ccf425fbb7998e96bd54263f Mon Sep 17 00:00:00 2001 From: Mahesh Bandewar Date: Thu, 26 Oct 2017 15:09:25 -0700 Subject: ipvlan: implement VEPA mode This is very similar to the Macvlan VEPA mode, however, there is some difference. IPvlan uses the mac-address of the lower device, so the VEPA mode has implications of ICMP-redirects for packets destined for its immediate neighbors sharing same master since the packets will have same source and dest mac. The external switch/router will send redirect msg. Having said that, this will be useful tool in terms of debugging since IPvlan will not switch packets within its slaves and rely completely on the external entity as intended in 802.1Qbg. Signed-off-by: Mahesh Bandewar Signed-off-by: David S. Miller --- Documentation/networking/ipvlan.txt | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/ipvlan.txt b/Documentation/networking/ipvlan.txt index bfa91c77a4c9..812ef003e0a8 100644 --- a/Documentation/networking/ipvlan.txt +++ b/Documentation/networking/ipvlan.txt @@ -25,7 +25,7 @@ using IProute2/ip utility. ip link add link name type ipvlan [ mode MODE ] [ FLAGS ] where MODE: l3 (default) | l3s | l2 - FLAGS: bridge (default) | private + FLAGS: bridge (default) | private | vepa e.g. (a) Following will create IPvlan link with eth0 as master in @@ -35,6 +35,8 @@ using IProute2/ip utility. bash# ip link add link eth0 name ipvl0 type ipvlan mode l2 bridge (c) This command will create an IPvlan device in L2 private mode. bash# ip link add link eth0 name ipvlan type ipvlan mode l2 private + (d) This command will create an IPvlan device in L2 vepa mode. + bash# ip link add link eth0 name ipvlan type ipvlan mode l2 vepa 4. Operating modes: @@ -77,6 +79,14 @@ themseleves apart from talking through the master device. If this option is added to the command-line, the port is set in private mode. i.e. port wont allow cross communication between slaves. +5.3 vepa: + If this is added to the command-line, the port is set in VEPA mode. +i.e. port will offload switching functionality to the external entity as +described in 802.1Qbg +Note: VEPA mode in IPvlan has limitations. IPvlan uses the mac-address of the +master-device, so the packets which are emitted in this mode for the adjacent +neighbor will have source and destination mac same. This will make the switch / +router send the redirect message. 6. What to choose (macvlan vs. ipvlan)? These two devices are very similar in many regards and the specific use -- cgit v1.2.3 From 8fca9e95243128961357577ba394ec1d4bd8c92c Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Sat, 28 Oct 2017 18:40:17 +0200 Subject: dt-bindings: power: add amlogic meson power domain bindings Acked-by: Rob Herring Signed-off-by: Neil Armstrong [khilman: minor whitespace fixups] Signed-off-by: Kevin Hilman --- .../bindings/power/amlogic,meson-gx-pwrc.txt | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt b/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt new file mode 100644 index 000000000000..1cd050b4054c --- /dev/null +++ b/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt @@ -0,0 +1,61 @@ +Amlogic Meson Power Controller +============================== + +The Amlogic Meson SoCs embeds an internal Power domain controller. + +VPU Power Domain +---------------- + +The Video Processing Unit power domain is controlled by this power controller, +but the domain requires some external resources to meet the correct power +sequences. +The bindings must respect the power domain bindings as described in the file +power_domain.txt + +Device Tree Bindings: +--------------------- + +Required properties: +- compatible: should be "amlogic,meson-gx-pwrc-vpu" for the Meson GX 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 + as described in ../reset/reset.txt +- clocks: from common clock binding: handle to VPU and VAPB clocks +- clock-names: from common clock binding: must contain "vpu", "vapb" + corresponding to entry in the clocks property. + +Parent node should have the following properties : +- compatible: "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd" +- reg: base address and size of the AO system control register space. + +Example: +------- + +ao_sysctrl: sys-ctrl@0 { + compatible = "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd"; + reg = <0x0 0x0 0x0 0x100>; + + pwrc_vpu: power-controller-vpu { + compatible = "amlogic,meson-gx-pwrc-vpu"; + #power-domain-cells = <0>; + amlogic,hhi-sysctrl = <&sysctrl>; + resets = <&reset RESET_VIU>, + <&reset RESET_VENC>, + <&reset RESET_VCBUS>, + <&reset RESET_BT656>, + <&reset RESET_DVIN_RESET>, + <&reset RESET_RDMA>, + <&reset RESET_VENCI>, + <&reset RESET_VENCP>, + <&reset RESET_VDAC>, + <&reset RESET_VDI6>, + <&reset RESET_VENCL>, + <&reset RESET_VID_LOCK>; + clocks = <&clkc CLKID_VPU>, + <&clkc CLKID_VAPB>; + clock-names = "vpu", "vapb"; + }; +}; + + -- cgit v1.2.3 From 9c52aaf756ecaec195517e17875b136eb4d176bf Mon Sep 17 00:00:00 2001 From: Carlo Caione Date: Sun, 17 Sep 2017 18:45:18 +0200 Subject: dt-bindings: Amlogic: Add Meson8 and Meson8b SMP related documentation With this patch we add documentation for: * power-management-unit: the PMU is used to bring up the cores during SMP operations * sram: among other things the sram is used to store the first code executed by the core when it is powered up * cpu-enable-method: the CPU enable method used by Amlogic Meson8 and Meson8b SoCs Signed-off-by: Carlo Caione [also add Meson8 to the documentation] Signed-off-by: Martin Blumenstingl Acked-by: Rob Herring Signed-off-by: Kevin Hilman --- .../devicetree/bindings/arm/amlogic/pmu.txt | 18 ++++++++++++ .../devicetree/bindings/arm/amlogic/smp-sram.txt | 32 ++++++++++++++++++++++ Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ 3 files changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/amlogic/pmu.txt create mode 100644 Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic/pmu.txt b/Documentation/devicetree/bindings/arm/amlogic/pmu.txt new file mode 100644 index 000000000000..72f8d08198b6 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amlogic/pmu.txt @@ -0,0 +1,18 @@ +Amlogic Meson8 and Meson8b power-management-unit: +------------------------------------------------- + +The pmu is used to turn off and on different power domains of the SoCs +This includes the power to the CPU cores. + +Required node properties: +- compatible value : depending on the SoC this should be one of: + "amlogic,meson8-pmu" + "amlogic,meson8b-pmu" +- reg : physical base address and the size of the registers window + +Example: + + pmu@c81000e4 { + compatible = "amlogic,meson8b-pmu", "syscon"; + reg = <0xc81000e0 0x18>; + }; diff --git a/Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt b/Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt new file mode 100644 index 000000000000..3473ddaadfac --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt @@ -0,0 +1,32 @@ +Amlogic Meson8 and Meson8b SRAM for smp bringup: +------------------------------------------------ + +Amlogic's SMP-capable SoCs use part of the sram for the bringup of the cores. +Once the core gets powered up it executes the code that is residing at a +specific location. + +Therefore a reserved section sub-node has to be added to the mmio-sram +declaration. + +Required sub-node properties: +- compatible : depending on the SoC this should be one of: + "amlogic,meson8-smp-sram" + "amlogic,meson8b-smp-sram" + +The rest of the properties should follow the generic mmio-sram discription +found in ../../misc/sram.txt + +Example: + + sram: sram@d9000000 { + compatible = "mmio-sram"; + reg = <0xd9000000 0x20000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xd9000000 0x20000>; + + smp-sram@1ff80 { + compatible = "amlogic,meson8b-smp-sram"; + reg = <0x1ff80 0x8>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index b92f12bd5244..a0009b72e9be 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -197,6 +197,8 @@ described below. "actions,s500-smp" "allwinner,sun6i-a31" "allwinner,sun8i-a23" + "amlogic,meson8-smp" + "amlogic,meson8b-smp" "arm,realview-smp" "brcm,bcm11351-cpu-method" "brcm,bcm23550" -- cgit v1.2.3 From 282e45dc64d1832c9b51d2c6f6eb0a634c924fa7 Mon Sep 17 00:00:00 2001 From: Philipp Puschmann Date: Thu, 19 Oct 2017 10:12:47 +0200 Subject: mtd: spi-nor: Add support for mr25h128 Add Everspin mr25h128 16KB MRAM to the list of supported chips. Signed-off-by: Philipp Puschmann Signed-off-by: Cyrille Pitchen --- Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt index 9ce35af8507c..956bb046e599 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt @@ -13,6 +13,7 @@ Required properties: at25df321a at25df641 at26df081a + mr25h128 mr25h256 mr25h10 mr25h40 -- cgit v1.2.3 From 186731145f920fb1514200043bcaf9c689693857 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sun, 10 Sep 2017 11:44:46 +0200 Subject: hwmon: (sht15) Root out platform data After finding out there are active users of this sensor I noticed: - It has a single PXA27x board file using the platform data - The platform data is only used to carry two GPIO pins, all other fields are unused - The driver does not use GPIO descriptors but the legacy GPIO API I saw we can swiftly fix this by: - Killing off the platform data entirely - Define a GPIO descriptor lookup table in the board file - Use the standard devm_gpiod_get() to grab the GPIO descriptors from either the device tree or the board file table. This compiles, but needs testing. Cc: arm@kernel.org Cc: Marco Franchi Cc: Davide Hug Cc: Jonathan Cameron Signed-off-by: Linus Walleij Acked-by: Arnd Bergmann Tested-by: Marco Franchi Acked-by: Arnd Bergmann Signed-off-by: Guenter Roeck --- Documentation/hwmon/sht15 | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sht15 b/Documentation/hwmon/sht15 index 778987d1856f..5e3207c3b177 100644 --- a/Documentation/hwmon/sht15 +++ b/Documentation/hwmon/sht15 @@ -42,8 +42,7 @@ chip. These coefficients are used to internally calibrate the signals from the sensors. Disabling the reload of those coefficients allows saving 10ms for each measurement and decrease power consumption, while losing on precision. -Some options may be set directly in the sht15_platform_data structure -or via sysfs attributes. +Some options may be set via sysfs attributes. Notes: * The regulator supply name is set to "vcc". -- cgit v1.2.3 From 0ec54a2e8ee22b13e9a89dfd76e66e5b75ca9885 Mon Sep 17 00:00:00 2001 From: Alan Tull Date: Mon, 11 Sep 2017 14:16:48 -0500 Subject: dt-bindings: hwmon: add compatible for max1619 Add new device tree bindings document for max1619 device including a new compatible string. Signed-off-by: Alan Tull Cc: Jean Delvare Cc: Guenter Roeck Cc: Rob Herring Cc: Mark Rutland Acked-by: Rob Herring Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/hwmon/max1619.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/max1619.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwmon/max1619.txt b/Documentation/devicetree/bindings/hwmon/max1619.txt new file mode 100644 index 000000000000..c70dbbe1e56f --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/max1619.txt @@ -0,0 +1,12 @@ +Bindings for MAX1619 Temperature Sensor + +Required properties: +- compatible : "maxim,max1619" +- reg : I2C address, one of 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b, 0x4c, or + 0x4d, 0x4e + +Example: + temp@4c { + compatible = "maxim,max1619"; + reg = <0x4c>; + }; -- cgit v1.2.3 From 24fae2b5b61da0cec6b94059552ae97ccc498ccc Mon Sep 17 00:00:00 2001 From: Vadim Pasternak Date: Tue, 3 Oct 2017 18:08:28 +0000 Subject: Documentation: devicetree: add max6621 device Add device record for Maxim MAX6621 temperature sensor device. Signed-off-by: Vadim Pasternak Acked-by: Rob Herring Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/trivial-devices.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt index af284fbd4d23..8bcac6ee73da 100644 --- a/Documentation/devicetree/bindings/trivial-devices.txt +++ b/Documentation/devicetree/bindings/trivial-devices.txt @@ -71,6 +71,7 @@ isil,isl29028 Intersil ISL29028 Ambient Light and Proximity Sensor isil,isl29030 Intersil ISL29030 Ambient Light and Proximity Sensor maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs +maxim,max6621 PECI-to-I2C translator for PECI-to-SMBus/I2C protocol conversion maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface mc,rv3029c2 Real Time Clock Module with I2C-Bus mcube,mc3230 mCube 3-axis 8-bit digital accelerometer -- cgit v1.2.3 From 9dfe310ed5f0802cba5ec29f2b5f5f92ba8ad9e9 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 26 Sep 2017 01:09:03 +0200 Subject: hwmon: (gpio-fan) Move DT bindings to the right place This moves the GPIO fan bindings to the hwmon bindings. The GPIO fan is a hwmon class hardware, not related to GPIO other than being a consumer of GPIOs. Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Acked-by: Rob Herring Signed-off-by: Guenter Roeck --- .../devicetree/bindings/gpio/gpio-fan.txt | 40 ---------------------- .../devicetree/bindings/hwmon/gpio-fan.txt | 40 ++++++++++++++++++++++ 2 files changed, 40 insertions(+), 40 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-fan.txt create mode 100644 Documentation/devicetree/bindings/hwmon/gpio-fan.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-fan.txt b/Documentation/devicetree/bindings/gpio/gpio-fan.txt deleted file mode 100644 index 439a7430fc68..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-fan.txt +++ /dev/null @@ -1,40 +0,0 @@ -Bindings for fan connected to GPIO lines - -Required properties: -- compatible : "gpio-fan" - -Optional properties: -- gpios: Specifies the pins that map to bits in the control value, - ordered MSB-->LSB. -- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the - control value that should be set to achieve them. This array - must have the RPM values in ascending order. -- alarm-gpios: This pin going active indicates something is wrong with - the fan, and a udev event will be fired. -- cooling-cells: If used as a cooling device, must be <2> - Also see: Documentation/devicetree/bindings/thermal/thermal.txt - min and max states are derived from the speed-map of the fan. - -Note: At least one the "gpios" or "alarm-gpios" properties must be set. - -Examples: - - gpio_fan { - compatible = "gpio-fan"; - gpios = <&gpio1 14 1 - &gpio1 13 1>; - gpio-fan,speed-map = <0 0 - 3000 1 - 6000 2>; - alarm-gpios = <&gpio1 15 1>; - }; - gpio_fan_cool: gpio_fan { - compatible = "gpio-fan"; - gpios = <&gpio2 14 1 - &gpio2 13 1>; - gpio-fan,speed-map = <0 0>, - <3000 1>, - <6000 2>; - alarm-gpios = <&gpio2 15 1>; - #cooling-cells = <2>; /* min followed by max */ - }; diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt new file mode 100644 index 000000000000..439a7430fc68 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt @@ -0,0 +1,40 @@ +Bindings for fan connected to GPIO lines + +Required properties: +- compatible : "gpio-fan" + +Optional properties: +- gpios: Specifies the pins that map to bits in the control value, + ordered MSB-->LSB. +- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the + control value that should be set to achieve them. This array + must have the RPM values in ascending order. +- alarm-gpios: This pin going active indicates something is wrong with + the fan, and a udev event will be fired. +- cooling-cells: If used as a cooling device, must be <2> + Also see: Documentation/devicetree/bindings/thermal/thermal.txt + min and max states are derived from the speed-map of the fan. + +Note: At least one the "gpios" or "alarm-gpios" properties must be set. + +Examples: + + gpio_fan { + compatible = "gpio-fan"; + gpios = <&gpio1 14 1 + &gpio1 13 1>; + gpio-fan,speed-map = <0 0 + 3000 1 + 6000 2>; + alarm-gpios = <&gpio1 15 1>; + }; + gpio_fan_cool: gpio_fan { + compatible = "gpio-fan"; + gpios = <&gpio2 14 1 + &gpio2 13 1>; + gpio-fan,speed-map = <0 0>, + <3000 1>, + <6000 2>; + alarm-gpios = <&gpio2 15 1>; + #cooling-cells = <2>; /* min followed by max */ + }; -- cgit v1.2.3 From 7d29f509d2cfd807b2fccc643ac1f7066b9b1949 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 24 Aug 2017 09:21:12 +0200 Subject: dt-bindings: i2c: i2c-gpio: Add support for named gpios The current i2c-gpio DT bindings use a single unnamed "gpios" property to refer to the SDA and SCL signal lines by index. This is error-prone for the casual DT writer and reviewer, as one has to look up the order in the DT bindings. Fix this by amending the DT bindings to use two separate named gpios properties, and deprecate the old unnamed variant. Take this opportunity to clearly deprecate the "i2c-gpio,sda-open-drain" and "i2c-gpio,scl-open-drain" flags as well. The commit describes in detail what these flags actually mean, and why they should not be used in new device trees. Cc: devicetree@vger.kernel.org Signed-off-by: Geert Uytterhoeven [Augmented to what I and Rob would like] Tested-by: Geert Uytterhoeven Acked-by: Rob Herring Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/i2c/i2c-gpio.txt | 32 ++++++++++++++++------ 1 file changed, 23 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-gpio.txt index 4f8ec947c6bd..38a05562d1d2 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-gpio.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-gpio.txt @@ -2,25 +2,39 @@ Device-Tree bindings for i2c gpio driver Required properties: - compatible = "i2c-gpio"; - - gpios: sda and scl gpio - + - sda-gpios: gpio used for the sda signal, this should be flagged as + active high using open drain with (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN) + from since the signal is by definition + open drain. + - scl-gpios: gpio used for the scl signal, this should be flagged as + active high using open drain with (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN) + from since the signal is by definition + open drain. Optional properties: - - i2c-gpio,sda-open-drain: sda as open drain - - i2c-gpio,scl-open-drain: scl as open drain - i2c-gpio,scl-output-only: scl as output only - i2c-gpio,delay-us: delay between GPIO operations (may depend on each platform) - i2c-gpio,timeout-ms: timeout to get data +Deprecated properties, do not use in new device tree sources: + - gpios: sda and scl gpio, alternative for {sda,scl}-gpios + - i2c-gpio,sda-open-drain: this means that something outside of our + control has put the GPIO line used for SDA into open drain mode, and + that something is not the GPIO chip. It is essentially an + inconsistency flag. + - i2c-gpio,scl-open-drain: this means that something outside of our + control has put the GPIO line used for SCL into open drain mode, and + that something is not the GPIO chip. It is essentially an + inconsistency flag. + Example nodes: +#include + i2c@0 { compatible = "i2c-gpio"; - gpios = <&pioA 23 0 /* sda */ - &pioA 24 0 /* scl */ - >; - i2c-gpio,sda-open-drain; - i2c-gpio,scl-open-drain; + sda-gpios = <&pioA 23 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; + scl-gpios = <&pioA 24 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; i2c-gpio,delay-us = <2>; /* ~100 kHz */ #address-cells = <1>; #size-cells = <0>; -- cgit v1.2.3 From 4946b3af5e8e96f0f0ceec53701541f1faae714d Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Fri, 15 Sep 2017 16:35:24 -0700 Subject: mmc: sdhci-msm: Enable delay circuit calibration clocks The delay circuit used to support HS400 is calibrated based on two additional clocks. When these clocks are not available and FF_CLK_SW_RST_DIS is not set in CORE_HC_MODE, reset might fail. But on some platforms this doesn't work properly and below dump can be seen in the kernel log. mmc0: Reset 0x1 never completed. mmc0: sdhci: ============ SDHCI REGISTER DUMP =========== mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001102 mmc0: sdhci: Blk size: 0x00004000 | Blk cnt: 0x00000000 mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000 mmc0: sdhci: Present: 0x01f80000 | Host ctl: 0x00000000 mmc0: sdhci: Power: 0x00000000 | Blk gap: 0x00000000 mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000002 mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000 mmc0: sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000 mmc0: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000 mmc0: sdhci: Caps: 0x742dc8b2 | Caps_1: 0x00008007 mmc0: sdhci: Cmd: 0x00000000 | Max curr: 0x00000000 mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000 mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 mmc0: sdhci: Host ctl2: 0x00000000 mmc0: sdhci: ============================================ Add support for the additional calibration clocks to allow these platforms to be configured appropriately. Cc: Venkat Gopalakrishnan Cc: Ritesh Harjani Signed-off-by: Bjorn Andersson Acked-by: Rob Herring Tested-by: Jeremy McNicoll Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 0576264eab5e..bfdcdc4ccdff 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -18,6 +18,8 @@ Required properties: "core" - SDC MMC clock (MCLK) (required) "bus" - SDCC bus voter clock (optional) "xo" - TCXO clock (optional) + "cal" - reference clock for RCLK delay calibration (optional) + "sleep" - sleep clock for RCLK delay calibration (optional) Example: -- cgit v1.2.3 From 17f5e716703b3281293790e83ad3d6a0bd8b9681 Mon Sep 17 00:00:00 2001 From: Carlo Caione Date: Tue, 3 Oct 2017 13:24:16 +0200 Subject: dt-bindings: mmc: Document the Amlogic Meson8 and Meson8b SDIO bindings This documents the devicetree bindings for the SDIO/MMC host found in Amlogic Meson8 and Meson8b SoCs. It supports the SD specification v2.0 and the eMMC specification v4.41. It has an internal "mux" which allows connecting up to three MMC devices to it. The maximum supported bus-width is 4-bits. Amlogic's GPL kernel sources call it "SDIO" to differentiate it from the other MMC controller in (at least the Meson8 and Meson8b) the SoCs (they call the other one "SDHC", which supports a bus-width of up to 8-bits). Signed-off-by: Carlo Caione Signed-off-by: Martin Blumenstingl Acked-by: Rob Herring Signed-off-by: Ulf Hansson --- .../bindings/mmc/amlogic,meson-mx-sdio.txt | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt new file mode 100644 index 000000000000..8765c605e6bc --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt @@ -0,0 +1,54 @@ +* Amlogic Meson6, Meson8 and Meson8b SDIO/MMC controller + +The highspeed MMC host controller on Amlogic SoCs provides an interface +for MMC, SD, SDIO and SDHC types of memory cards. + +Supported maximum speeds are the ones of the eMMC standard 4.41 as well +as the speed of SD standard 2.0. + +The hardware provides an internal "mux" which allows up to three slots +to be controlled. Only one slot can be accessed at a time. + +Required properties: + - compatible : must be one of + - "amlogic,meson8-sdio" + - "amlogic,meson8b-sdio" + along with the generic "amlogic,meson-mx-sdio" + - reg : mmc controller base registers + - interrupts : mmc controller interrupt + - #address-cells : must be 1 + - size-cells : must be 0 + - clocks : phandle to clock providers + - clock-names : must contain "core" and "clkin" + +Required child nodes: +A node for each slot provided by the MMC controller is required. +NOTE: due to a driver limitation currently only one slot (= child node) + is supported! + +Required properties on each child node (= slot): + - compatible : must be "mmc-slot" (see mmc.txt within this directory) + - reg : the slot (or "port") ID + +Optional properties on each child node (= slot): + - bus-width : must be 1 or 4 (8-bit bus is not supported) + - for cd and all other additional generic mmc parameters + please refer to mmc.txt within this directory + +Examples: + mmc@c1108c20 { + compatible = "amlogic,meson8-sdio", "amlogic,meson-mx-sdio"; + reg = <0xc1108c20 0x20>; + interrupts = <0 28 1>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clkc CLKID_SDIO>, <&clkc CLKID_CLK81>; + clock-names = "core", "clkin"; + + slot@1 { + compatible = "mmc-slot"; + reg = <1>; + + bus-width = <4>; + }; + }; -- cgit v1.2.3 From 04fa0540255ee5707a1addf4c7c2a5ba4ac2c407 Mon Sep 17 00:00:00 2001 From: Jin Qian Date: Thu, 12 Oct 2017 10:46:59 -0700 Subject: mmc: core: export emmc revision Expose emmc revision as part of device attributes. Signed-off-by: Jin Qian Signed-off-by: Ulf Hansson --- Documentation/ABI/testing/sysfs-bus-mmc | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-mmc (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-mmc b/Documentation/ABI/testing/sysfs-bus-mmc new file mode 100644 index 000000000000..519f028d19cc --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-mmc @@ -0,0 +1,4 @@ +What: /sys/bus/mmc/devices/.../rev +Date: October 2017 +Contact: Jin Qian +Description: Extended CSD revision number -- cgit v1.2.3 From f7834cbd907abb5d4d84f85dba5a7321e5a37b83 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Sun, 15 Oct 2017 14:46:13 +0200 Subject: dt-bindings: mmc: describe new eMMC binding for fixed driver type Some boards may have to use a certain driver type (or drive strength) to achieve stable eMMC communication. Describe a binding to set this up via DT. Signed-off-by: Wolfram Sang Acked-by: Rob Herring Reviewed-by: Simon Horman Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/mmc.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index b32ade645ad9..94a90b49a692 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -53,6 +53,9 @@ Optional properties: - no-sdio: controller is limited to send sdio cmd during initialization - no-sd: controller is limited to send sd cmd during initialization - no-mmc: controller is limited to send mmc cmd during initialization +- fixed-emmc-driver-type: for non-removable eMMC, enforce this driver type. + The value is the driver type as specified in the eMMC specification + (table 206 in spec version 5.1). *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the "normal" and "inverted" -- cgit v1.2.3 From 95e91ade6900547a74ac8e3ce35213aacfbdd0d3 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Wed, 18 Oct 2017 09:00:21 +0200 Subject: dt-bindings: mmc: renesas_sdhi: provide example in bindings documentation Provide an example of the usage of the DT bindings for TMIO in their documentation. The example given is for the r8a7790 (R-Car H2). Signed-off-by: Simon Horman Reviewed-by: Geert Uytterhoeven Acked-by: Wolfram Sang Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt index 54ef642f23a0..b63392d9cc47 100644 --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -43,3 +43,61 @@ Optional properties: - pinctrl-names: should be "default", "state_uhs" - pinctrl-0: should contain default/high speed pin ctrl - pinctrl-1: should contain uhs mode pin ctrl + +Example: R8A7790 (R-Car H2) SDHI controller nodes + + sdhi0: sd@ee100000 { + compatible = "renesas,sdhi-r8a7790"; + reg = <0 0xee100000 0 0x328>; + interrupts = ; + clocks = <&cpg CPG_MOD 314>; + dmas = <&dmac0 0xcd>, <&dmac0 0xce>, + <&dmac1 0xcd>, <&dmac1 0xce>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <195000000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 314>; + status = "disabled"; + }; + + sdhi1: sd@ee120000 { + compatible = "renesas,sdhi-r8a7790"; + reg = <0 0xee120000 0 0x328>; + interrupts = ; + clocks = <&cpg CPG_MOD 313>; + dmas = <&dmac0 0xc9>, <&dmac0 0xca>, + <&dmac1 0xc9>, <&dmac1 0xca>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <195000000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 313>; + status = "disabled"; + }; + + sdhi2: sd@ee140000 { + compatible = "renesas,sdhi-r8a7790"; + reg = <0 0xee140000 0 0x100>; + interrupts = ; + clocks = <&cpg CPG_MOD 312>; + dmas = <&dmac0 0xc1>, <&dmac0 0xc2>, + <&dmac1 0xc1>, <&dmac1 0xc2>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <97500000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 312>; + status = "disabled"; + }; + + sdhi3: sd@ee160000 { + compatible = "renesas,sdhi-r8a7790"; + reg = <0 0xee160000 0 0x100>; + interrupts = ; + clocks = <&cpg CPG_MOD 311>; + dmas = <&dmac0 0xd3>, <&dmac0 0xd4>, + <&dmac1 0xd3>, <&dmac1 0xd4>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <97500000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 311>; + status = "disabled"; + }; -- cgit v1.2.3 From 54839d012d5f98cde2fa102fdcd22e1da661d138 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Wed, 18 Oct 2017 09:00:22 +0200 Subject: dt-bindings: mmc: renesas_sdhi: add R-Car Gen[123] fallback compatibility strings Add fallback compatibility strings for R-Car Gen 1, 2 and 3. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant of the former or vice versa. We can, however, by examining the documentation and behaviour of the hardware at run-time observe that the current driver implementation appears to be compatible with the IP blocks on SoCs within a given generation. For the above reasons and convenience when enabling new SoCs a per-generation fallback compatibility string scheme is being adopted for drivers for Renesas SoCs. Signed-off-by: Simon Horman Reviewed-by: Geert Uytterhoeven Acked-by: Wolfram Sang Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt index b63392d9cc47..3c6762430fd9 100644 --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -10,7 +10,7 @@ described in mmc.txt, can be used. Additionally the following tmio_mmc-specific optional bindings can be used. Required properties: -- compatible: "renesas,sdhi-shmobile" - a generic sh-mobile SDHI unit +- compatible: should contain one or more of the following: "renesas,sdhi-sh73a0" - SDHI IP on SH73A0 SoC "renesas,sdhi-r7s72100" - SDHI IP on R7S72100 SoC "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC @@ -26,6 +26,16 @@ Required properties: "renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC "renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC + "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller + "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller + "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 or RZ/G1 + SDHI controller + "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 SDHI controller + + + When compatible with the generic version, nodes must list + the SoC-specific version corresponding to the platform + first followed by the generic version. - clocks: Most controllers only have 1 clock source per channel. However, on some variations of this controller, the internal card detection @@ -47,7 +57,7 @@ Optional properties: Example: R8A7790 (R-Car H2) SDHI controller nodes sdhi0: sd@ee100000 { - compatible = "renesas,sdhi-r8a7790"; + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; reg = <0 0xee100000 0 0x328>; interrupts = ; clocks = <&cpg CPG_MOD 314>; @@ -61,7 +71,7 @@ Example: R8A7790 (R-Car H2) SDHI controller nodes }; sdhi1: sd@ee120000 { - compatible = "renesas,sdhi-r8a7790"; + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; reg = <0 0xee120000 0 0x328>; interrupts = ; clocks = <&cpg CPG_MOD 313>; @@ -75,7 +85,7 @@ Example: R8A7790 (R-Car H2) SDHI controller nodes }; sdhi2: sd@ee140000 { - compatible = "renesas,sdhi-r8a7790"; + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; reg = <0 0xee140000 0 0x100>; interrupts = ; clocks = <&cpg CPG_MOD 312>; @@ -89,7 +99,7 @@ Example: R8A7790 (R-Car H2) SDHI controller nodes }; sdhi3: sd@ee160000 { - compatible = "renesas,sdhi-r8a7790"; + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; reg = <0 0xee160000 0 0x100>; interrupts = ; clocks = <&cpg CPG_MOD 311>; -- cgit v1.2.3 From d91ca84edeb04fad89faf0f723029b692f6b13b4 Mon Sep 17 00:00:00 2001 From: Chaotian Jing Date: Mon, 16 Oct 2017 09:46:28 +0800 Subject: mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings Change the comptiable for support of multi-platform Make compatible explicit, as MMC host of mt8173 has difference with mt8135(mt8173 supports hs400 and hs400_tune),so that need separate mt8173/mt8135 compatible name. Add description for reg Add description for source_cg Add description for mediatek,latch-ck Note that source_cg and mediatek,latch-ck are optional for some projects, eg, MT2701 do not have source_cg, and MT2712 do not need mediatek,latch-ck Signed-off-by: Chaotian Jing Acked-by: Rob Herring Tested-by: Sean Wang Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/mtk-sd.txt | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt index 4182ea36ca5b..72d2a734ab85 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt @@ -7,10 +7,18 @@ This file documents differences between the core properties in mmc.txt and the properties used by the msdc driver. Required properties: -- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc" +- compatible: value should be either of the following. + "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135 + "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173 + "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701 + "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712 +- reg: physical base address of the controller and length - interrupts: Should contain MSDC interrupt number -- clocks: MSDC source clock, HCLK -- clock-names: "source", "hclk" +- clocks: Should contain phandle for the clock feeding the MMC controller +- clock-names: Should contain the following: + "source" - source clock (required) + "hclk" - HCLK which used for host (required) + "source_cg" - independent source clock gate (required for MT2712) - pinctrl-names: should be "default", "state_uhs" - pinctrl-0: should contain default/high speed pin ctrl - pinctrl-1: should contain uhs mode pin ctrl @@ -30,6 +38,10 @@ Optional properties: - mediatek,hs400-cmd-resp-sel-rising: HS400 command response sample selection If present,HS400 command responses are sampled on rising edges. If not present,HS400 command responses are sampled on falling edges. +- mediatek,latch-ck: Some SoCs do not support enhance_rx, need set correct latch-ck to avoid data crc + error caused by stop clock(fifo full) + Valid range = [0:0x7]. if not present, default value is 0. + applied to compatible "mediatek,mt2701-mmc". Examples: mmc0: mmc@11230000 { -- cgit v1.2.3 From 00aa61d36da1969b139dc10b9b555677ebb03c42 Mon Sep 17 00:00:00 2001 From: Stafford Horne Date: Tue, 19 Sep 2017 22:55:54 +0900 Subject: Documentation: Move OpenRISC docs out of arch/ The OpenRISC docs have traditionally been in arch/ but that does not seem like the correct place to be. Move them so they will be more visible to others. Also update MAINTAINERS to make sure we get notifications of changes. Signed-off-by: Stafford Horne --- Documentation/openrisc/README | 99 +++++++++++++++++++++++++++++++++++++++++++ Documentation/openrisc/TODO | 12 ++++++ 2 files changed, 111 insertions(+) create mode 100644 Documentation/openrisc/README create mode 100644 Documentation/openrisc/TODO (limited to 'Documentation') diff --git a/Documentation/openrisc/README b/Documentation/openrisc/README new file mode 100644 index 000000000000..072069ab5100 --- /dev/null +++ b/Documentation/openrisc/README @@ -0,0 +1,99 @@ +OpenRISC Linux +============== + +This is a port of Linux to the OpenRISC class of microprocessors; the initial +target architecture, specifically, is the 32-bit OpenRISC 1000 family (or1k). + +For information about OpenRISC processors and ongoing development: + + website http://openrisc.io + +For more information about Linux on OpenRISC, please contact South Pole AB. + + email: info@southpole.se + + website: http://southpole.se + http://southpoleconsulting.com + +--------------------------------------------------------------------- + +Build instructions for OpenRISC toolchain and Linux +=================================================== + +In order to build and run Linux for OpenRISC, you'll need at least a basic +toolchain and, perhaps, the architectural simulator. Steps to get these bits +in place are outlined here. + +1) The toolchain can be obtained from openrisc.io. Instructions for building +a toolchain can be found at: + +https://github.com/openrisc/tutorials + +2) or1ksim (optional) + +or1ksim is the architectural simulator which will allow you to actually run +your OpenRISC Linux kernel if you don't have an OpenRISC processor at hand. + + git clone https://github.com/openrisc/or1ksim.git + + cd or1ksim + ./configure --prefix=$OPENRISC_PREFIX + make + make install + +3) Linux kernel + +Build the kernel as usual + + make ARCH=openrisc defconfig + make ARCH=openrisc + +4) Run in architectural simulator + +Grab the or1ksim platform configuration file (from the or1ksim source) and +together with your freshly built vmlinux, run your kernel with the following +incantation: + + sim -f arch/openrisc/or1ksim.cfg vmlinux + +--------------------------------------------------------------------- + +Terminology +=========== + +In the code, the following particles are used on symbols to limit the scope +to more or less specific processor implementations: + +openrisc: the OpenRISC class of processors +or1k: the OpenRISC 1000 family of processors +or1200: the OpenRISC 1200 processor + +--------------------------------------------------------------------- + +History +======== + +18. 11. 2003 Matjaz Breskvar (phoenix@bsemi.com) + initial port of linux to OpenRISC/or32 architecture. + all the core stuff is implemented and seams usable. + +08. 12. 2003 Matjaz Breskvar (phoenix@bsemi.com) + complete change of TLB miss handling. + rewrite of exceptions handling. + fully functional sash-3.6 in default initrd. + a much improved version with changes all around. + +10. 04. 2004 Matjaz Breskvar (phoenix@bsemi.com) + alot of bugfixes all over. + ethernet support, functional http and telnet servers. + running many standard linux apps. + +26. 06. 2004 Matjaz Breskvar (phoenix@bsemi.com) + port to 2.6.x + +30. 11. 2004 Matjaz Breskvar (phoenix@bsemi.com) + lots of bugfixes and enhancments. + added opencores framebuffer driver. + +09. 10. 2010 Jonas Bonn (jonas@southpole.se) + major rewrite to bring up to par with upstream Linux 2.6.36 diff --git a/Documentation/openrisc/TODO b/Documentation/openrisc/TODO new file mode 100644 index 000000000000..c43d4e1d14eb --- /dev/null +++ b/Documentation/openrisc/TODO @@ -0,0 +1,12 @@ +The OpenRISC Linux port is fully functional and has been tracking upstream +since 2.6.35. There are, however, remaining items to be completed within +the coming months. Here's a list of known-to-be-less-than-stellar items +that are due for investigation shortly, i.e. our TODO list: + +-- Implement the rest of the DMA API... dma_map_sg, etc. + +-- Finish the renaming cleanup... there are references to or32 in the code + which was an older name for the architecture. The name we've settled on is + or1k and this change is slowly trickling through the stack. For the time + being, or32 is equivalent to or1k. + -- cgit v1.2.3 From e4082de21c5c4f9001b8e44b39b5e72f7ed3b2a7 Mon Sep 17 00:00:00 2001 From: Stafford Horne Date: Sat, 21 Oct 2017 22:39:09 +0900 Subject: Documentation: openrisc: Updates to README Update the OpenRISC readme to provide some more up-to-date information on how to get started with OpenRISC. This includes: - remove references to southpole who no longer are consulting for OpenRISC (confirmed with Jonas) - suggested QEMU instead of the old or1ksim as QEMU is well supported - include instructions on how to get an FPGA board running Suggested-by: Pavel Machek Signed-off-by: Stafford Horne --- Documentation/openrisc/README | 65 +++++++++++++++++++++++++------------------ 1 file changed, 38 insertions(+), 27 deletions(-) (limited to 'Documentation') diff --git a/Documentation/openrisc/README b/Documentation/openrisc/README index 072069ab5100..777a893d533d 100644 --- a/Documentation/openrisc/README +++ b/Documentation/openrisc/README @@ -7,13 +7,7 @@ target architecture, specifically, is the 32-bit OpenRISC 1000 family (or1k). For information about OpenRISC processors and ongoing development: website http://openrisc.io - -For more information about Linux on OpenRISC, please contact South Pole AB. - - email: info@southpole.se - - website: http://southpole.se - http://southpoleconsulting.com + email openrisc@lists.librecores.org --------------------------------------------------------------------- @@ -24,37 +18,54 @@ In order to build and run Linux for OpenRISC, you'll need at least a basic toolchain and, perhaps, the architectural simulator. Steps to get these bits in place are outlined here. -1) The toolchain can be obtained from openrisc.io. Instructions for building -a toolchain can be found at: +1) Toolchain + +Toolchain binaries can be obtained from openrisc.io or our github releases page. +Instructions for building the different toolchains can be found on openrisc.io +or Stafford's toolchain build and release scripts. + + binaries https://github.com/openrisc/or1k-gcc/releases + toolchains https://openrisc.io/software + building https://github.com/stffrdhrn/or1k-toolchain-build -https://github.com/openrisc/tutorials +2) Building -2) or1ksim (optional) +Build the Linux kernel as usual -or1ksim is the architectural simulator which will allow you to actually run -your OpenRISC Linux kernel if you don't have an OpenRISC processor at hand. + make ARCH=openrisc defconfig + make ARCH=openrisc - git clone https://github.com/openrisc/or1ksim.git +3) Running on FPGA (optional) - cd or1ksim - ./configure --prefix=$OPENRISC_PREFIX - make - make install +The OpenRISC community typically uses FuseSoC to manage building and programming +an SoC into an FPGA. The below is an example of programming a De0 Nano +development board with the OpenRISC SoC. During the build FPGA RTL is code +downloaded from the FuseSoC IP cores repository and built using the FPGA vendor +tools. Binaries are loaded onto the board with openocd. -3) Linux kernel + git clone https://github.com/olofk/fusesoc + cd fusesoc + sudo pip install -e . -Build the kernel as usual + fusesoc init + fusesoc build de0_nano + fusesoc pgm de0_nano - make ARCH=openrisc defconfig - make ARCH=openrisc + openocd -f interface/altera-usb-blaster.cfg \ + -f board/or1k_generic.cfg + + telnet localhost 4444 + > init + > halt; load_image vmlinux ; reset -4) Run in architectural simulator +4) Running on a Simulator (optional) -Grab the or1ksim platform configuration file (from the or1ksim source) and -together with your freshly built vmlinux, run your kernel with the following -incantation: +QEMU is a processor emulator which we recommend for simulating the OpenRISC +platform. Please follow the OpenRISC instructions on the QEMU website to get +Linux running on QEMU. You can build QEMU yourself, but your Linux distribution +likely provides binary packages to support OpenRISC. - sim -f arch/openrisc/or1ksim.cfg vmlinux + qemu openrisc https://wiki.qemu.org/Documentation/Platforms/OpenRISC --------------------------------------------------------------------- -- cgit v1.2.3 From 9f058fa2efb10cd75884c4ee6c357bab07715f02 Mon Sep 17 00:00:00 2001 From: Avaneesh Kumar Dwivedi Date: Tue, 24 Oct 2017 21:22:27 +0530 Subject: remoteproc: qcom: Add support for mss remoteproc on msm8996 This patch add support for mss boot on msm8996. Major changes include initializing mss rproc for msm8996, making appropriate change for executing mss reset sequence etc. Tested-and-acked-by: Bjorn Andersson Signed-off-by: Avaneesh Kumar Dwivedi Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 7ff3f7903f26..00d3d58a102f 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -10,6 +10,7 @@ on the Qualcomm Hexagon core. "qcom,q6v5-pil", "qcom,msm8916-mss-pil", "qcom,msm8974-mss-pil" + "qcom,msm8996-mss-pil" - reg: Usage: required -- cgit v1.2.3 From eace566c3406cac3131d44198f05b7b55f79651f Mon Sep 17 00:00:00 2001 From: Chris Lew Date: Thu, 26 Oct 2017 15:28:54 -0700 Subject: dt-bindings: soc: qcom: Support GLINK intents Virtual GLINK channels may know what throughput to expect from a remoteproc. An intent advertises to the remoteproc this channel is ready to receive data. Allow a channel to define the size and amount of intents to be prequeued. Acked-by: Rob Herring Signed-off-by: Chris Lew Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt index b277eca861f7..9663cab52246 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt @@ -39,6 +39,14 @@ of these nodes are defined by the individual bindings for the specific function Definition: a list of channels tied to this function, used for matching the function to a set of virtual channels +- qcom,intents: + Usage: optional + Value type: + Definition: a list of size,amount pairs describing what intents should + be preallocated for this virtual channel. This can be used + to tweak the default intents available for the channel to + meet expectations of the remote. + = EXAMPLE The following example represents the GLINK RPM node on a MSM8996 device, with the function for the "rpm_request" channel defined, which is used for @@ -69,6 +77,8 @@ regualtors and root clocks. compatible = "qcom,rpm-msm8996"; qcom,glink-channels = "rpm_requests"; + qcom,intents = <0x400 5 + 0x800 1>; ... }; }; -- cgit v1.2.3 From ed6e26baa7431ebfad890f275e191e32b5a4103c Mon Sep 17 00:00:00 2001 From: Christophe JAILLET Date: Fri, 20 Oct 2017 21:49:14 +0200 Subject: bug-hunting.rst: Fix an example and a typo in a Sphinx tag - Use the same file name in the explanation and in the example (conex.c vs sonixj.c) - Add a missing ':' in a :ref: tag which leads to incorrect Shpinx output - Add some missing ',' and ';' Signed-off-by: Christophe JAILLET Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/bug-hunting.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst index 08c4b1308189..f278b289e260 100644 --- a/Documentation/admin-guide/bug-hunting.rst +++ b/Documentation/admin-guide/bug-hunting.rst @@ -240,7 +240,7 @@ In order to report it upstream, you should identify the mailing list used for the development of the affected code. This can be done by using the ``get_maintainer.pl`` script. -For example, if you find a bug at the gspca's conex.c file, you can get +For example, if you find a bug at the gspca's sonixj.c file, you can get their maintainers with:: $ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c @@ -257,7 +257,7 @@ Please notice that it will point to: Tejun and Bhaktipriya (in this specific case, none really envolved on the development of this file); - The driver maintainer (Hans Verkuil); -- The subsystem maintainer (Mauro Carvalho Chehab) +- The subsystem maintainer (Mauro Carvalho Chehab); - The driver and/or subsystem mailing list (linux-media@vger.kernel.org); - the Linux Kernel mailing list (linux-kernel@vger.kernel.org). @@ -274,14 +274,14 @@ Fixing the bug -------------- If you know programming, you could help us by not only reporting the bug, -but also providing us with a solution. After all open source is about +but also providing us with a solution. After all, open source is about sharing what you do and don't you want to be recognised for your genius? If you decide to take this way, once you have worked out a fix please submit it upstream. Please do read -ref:`Documentation/process/submitting-patches.rst ` though +:ref:`Documentation/process/submitting-patches.rst ` though to help your code get accepted. -- cgit v1.2.3 From b0d40d2b22fe48cfcbbfb137fd198be0a1cd8a85 Mon Sep 17 00:00:00 2001 From: Frederic Weisbecker Date: Tue, 31 Oct 2017 04:18:34 +0100 Subject: sched/isolation: Document isolcpus= boot parameter flags, mark it deprecated Document the latest updates on the isolcpus= boot option. While at it, let's also fix the details about the preferred way to isolate a set of CPUs from the scheduler general domains. Cpusets offer a much better interface to achieve that. Signed-off-by: Frederic Weisbecker Acked-by: Thomas Gleixner Acked-by: Peter Zijlstra Cc: Chris Metcalf Cc: Christoph Lameter Cc: Linus Torvalds Cc: Luiz Capitulino Cc: Mike Galbraith Cc: Paul E. McKenney Cc: Rik van Riel Cc: Wanpeng Li Link: http://lkml.kernel.org/r/1509419914-16179-1-git-send-email-frederic@kernel.org [ Clarified the text some more, marked the boot option deprecated. ] Signed-off-by: Ingo Molnar --- Documentation/admin-guide/kernel-parameters.txt | 39 ++++++++++++++++--------- 1 file changed, 26 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 6b99c8b77c59..17eb0234d5be 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1727,20 +1727,33 @@ isapnp= [ISAPNP] Format: ,,, - isolcpus= [KNL,SMP] Isolate CPUs from the general scheduler. - The argument is a cpu list, as described above. + isolcpus= [KNL,SMP] Isolate a given set of CPUs from disturbance. + [Deprecated - use cpusets instead] + Format: [flag-list,] + + Specify one or more CPUs to isolate from disturbances + specified in the flag list (default: domain): + + nohz + Disable the tick when a single task runs. + domain + Isolate from the general SMP balancing and scheduling + algorithms. Note that performing domain isolation this way + is irreversible: it's not possible to bring back a CPU to + the domains once isolated through isolcpus. It's strongly + advised to use cpusets instead to disable scheduler load + balancing through the "cpuset.sched_load_balance" file. + It offers a much more flexible interface where CPUs can + move in and out of an isolated set anytime. + + You can move a process onto or off an "isolated" CPU via + the CPU affinity syscalls or cpuset. + begins at 0 and the maximum value is + "number of CPUs in system - 1". + + The format of is described above. + - This option can be used to specify one or more CPUs - to isolate from the general SMP balancing and scheduling - algorithms. You can move a process onto or off an - "isolated" CPU via the CPU affinity syscalls or cpuset. - begins at 0 and the maximum value is - "number of CPUs in system - 1". - - This option is the preferred way to isolate CPUs. The - alternative -- manually setting the CPU mask of all - tasks in the system -- can cause problems and - suboptimal load balancer performance. iucv= [HW,NET] -- cgit v1.2.3 From 727dede0ba8afbd8d19116d39f2ae8d19d00033d Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Tue, 24 Oct 2017 09:15:23 +0200 Subject: sound: Retire OSS Since no complaints have been raised after disabling the build of OSS (Open Sound System) by the commit 31cbee6a5611 ("sound: Disable the build of OSS drivers"), let's finally drop the whole code and documentation. Some glue codes are still left intact since sound/oss/dmasound stuff remains -- which is an independent implementation solely for m68k, and it's not covered by ALSA yet. Also, a couple of API header files (linux/sound.h and linux/soundcard.h) are kept remaining as well, since the OSS API itself is still supported by ALSA OSS emulation, and applications can refer to these. Where we're at it, some help texts in the top-level Kconfig are adjusted, too (who still needs to specify I/O port in kbuild nowadays?). Reviewed-by: Jaroslav Kysela Signed-off-by: Takashi Iwai --- Documentation/sound/oss/ALS | 66 -- Documentation/sound/oss/AudioExcelDSP16 | 101 -- Documentation/sound/oss/CMI8330 | 152 --- Documentation/sound/oss/ESS | 34 - Documentation/sound/oss/ESS1868 | 55 -- Documentation/sound/oss/Introduction | 459 --------- Documentation/sound/oss/MultiSound | 1137 ---------------------- Documentation/sound/oss/OPL3 | 6 - Documentation/sound/oss/Opti | 218 ----- Documentation/sound/oss/PAS16 | 162 ---- Documentation/sound/oss/PSS | 41 - Documentation/sound/oss/PSS-updates | 88 -- Documentation/sound/oss/README.OSS | 1455 ---------------------------- Documentation/sound/oss/README.modules | 106 -- Documentation/sound/oss/README.ymfsb | 107 -- Documentation/sound/oss/SoundPro | 105 -- Documentation/sound/oss/Soundblaster | 53 - Documentation/sound/oss/Tropez+ | 26 - Documentation/sound/oss/VIBRA16 | 80 -- Documentation/sound/oss/WaveArtist | 170 ---- Documentation/sound/oss/btaudio | 92 -- Documentation/sound/oss/mwave | 185 ---- Documentation/sound/oss/oss-parameters.txt | 51 - Documentation/sound/oss/ultrasound | 30 - 24 files changed, 4979 deletions(-) delete mode 100644 Documentation/sound/oss/ALS delete mode 100644 Documentation/sound/oss/AudioExcelDSP16 delete mode 100644 Documentation/sound/oss/CMI8330 delete mode 100644 Documentation/sound/oss/ESS delete mode 100644 Documentation/sound/oss/ESS1868 delete mode 100644 Documentation/sound/oss/Introduction delete mode 100644 Documentation/sound/oss/MultiSound delete mode 100644 Documentation/sound/oss/OPL3 delete mode 100644 Documentation/sound/oss/Opti delete mode 100644 Documentation/sound/oss/PAS16 delete mode 100644 Documentation/sound/oss/PSS delete mode 100644 Documentation/sound/oss/PSS-updates delete mode 100644 Documentation/sound/oss/README.OSS delete mode 100644 Documentation/sound/oss/README.modules delete mode 100644 Documentation/sound/oss/README.ymfsb delete mode 100644 Documentation/sound/oss/SoundPro delete mode 100644 Documentation/sound/oss/Soundblaster delete mode 100644 Documentation/sound/oss/Tropez+ delete mode 100644 Documentation/sound/oss/VIBRA16 delete mode 100644 Documentation/sound/oss/WaveArtist delete mode 100644 Documentation/sound/oss/btaudio delete mode 100644 Documentation/sound/oss/mwave delete mode 100644 Documentation/sound/oss/oss-parameters.txt delete mode 100644 Documentation/sound/oss/ultrasound (limited to 'Documentation') diff --git a/Documentation/sound/oss/ALS b/Documentation/sound/oss/ALS deleted file mode 100644 index bf10bed4574b..000000000000 --- a/Documentation/sound/oss/ALS +++ /dev/null @@ -1,66 +0,0 @@ -ALS-007/ALS-100/ALS-200 based sound cards -========================================= - -Support for sound cards based around the Avance Logic -ALS-007/ALS-100/ALS-200 chip is included. These chips are a single -chip PnP sound solution which is mostly hardware compatible with the -Sound Blaster 16 card, with most differences occurring in the use of -the mixer registers. For this reason the ALS code is integrated -as part of the Sound Blaster 16 driver (adding only 800 bytes to the -SB16 driver). - -To use an ALS sound card under Linux, enable the following options as -modules in the sound configuration section of the kernel config: - - 100% Sound Blaster compatibles (SB16/32/64, ESS, Jazz16) support - - FM synthesizer (YM3812/OPL-3) support - - standalone MPU401 support may be required for some cards; for the - ALS-007, when using isapnptools, it is required -Since the ALS-007/100/200 are PnP cards, ISAPnP support should probably be -compiled in. If kernel level PnP support is not included, isapnptools will -be required to configure the card before the sound modules are loaded. - -When using kernel level ISAPnP, the kernel should correctly identify and -configure all resources required by the card when the "sb" module is -inserted. Note that the ALS-007 does not have a 16 bit DMA channel and that -the MPU401 interface on this card uses a different interrupt to the audio -section. This should all be correctly configured by the kernel; if problems -with the MPU401 interface surface, try using the standalone MPU401 module, -passing "0" as the "sb" module's "mpu_io" module parameter to prevent the -soundblaster driver attempting to register the MPU401 itself. The onboard -synth device can be accessed using the "opl3" module. - -If isapnptools is used to wake up the sound card (as in 2.2.x), the settings -of the card's resources should be passed to the kernel modules ("sb", "opl3" -and "mpu401") using the module parameters. When configuring an ALS-007, be -sure to specify different IRQs for the audio and MPU401 sections - this card -requires they be different. For "sb", "io", "irq" and "dma" should be set -to the same values used to configure the audio section of the card with -isapnp. "dma16" should be explicitly set to "-1" for an ALS-007 since this -card does not have a 16 bit dma channel; if not specified the kernel will -default to using channel 5 anyway which will cause audio not to work. -"mpu_io" should be set to 0. The "io" parameter of the "opl3" module should -also agree with the setting used by isapnp. To get the MPU401 interface -working on an ALS-007 card, the "mpu401" module will be required since this -card uses separate IRQs for the audio and MPU401 sections and there is no -parameter available to pass a different IRQ to the "sb" driver (whose -inbuilt MPU401 driver would otherwise be fine). Insert the mpu401 module -passing appropriate values using the "io" and "irq" parameters. - -The resulting sound driver will provide the following capabilities: - - 8 and 16 bit audio playback - - 8 and 16 bit audio recording - - Software selection of record source (line in, CD, FM, mic, master) - - Record and playback of midi data via the external MPU-401 - - Playback of midi data using inbuilt FM synthesizer - - Control of the ALS-007 mixer via any OSS-compatible mixer programs. - Controls available are Master (L&R), Line in (L&R), CD (L&R), - DSP/PCM/audio out (L&R), FM (L&R) and Mic in (mono). - -Jonathan Woithe -jwoithe@just42.net -30 March 1998 - -Modified 2000-02-26 by Dave Forrest, drf5n@virginia.edu to add ALS100/ALS200 -Modified 2000-04-10 by Paul Laufer, pelaufer@csupomona.edu to add ISAPnP info. -Modified 2000-11-19 by Jonathan Woithe, jwoithe@just42.net - - updated information for kernel 2.4.x. diff --git a/Documentation/sound/oss/AudioExcelDSP16 b/Documentation/sound/oss/AudioExcelDSP16 deleted file mode 100644 index ea8549faede9..000000000000 --- a/Documentation/sound/oss/AudioExcelDSP16 +++ /dev/null @@ -1,101 +0,0 @@ -Driver ------- - -Information about Audio Excel DSP 16 driver can be found in the source -file aedsp16.c -Please, read the head of the source before using it. It contain useful -information. - -Configuration -------------- - -The Audio Excel configuration, is now done with the standard Linux setup. -You have to configure the sound card (Sound Blaster or Microsoft Sound System) -and, if you want it, the Roland MPU-401 (do not use the Sound Blaster MPU-401, -SB-MPU401) in the main driver menu. Activate the lowlevel drivers then select -the Audio Excel hardware that you want to initialize. Check the IRQ/DMA/MIRQ -of the Audio Excel initialization: it must be the same as the SBPRO (or MSS) -setup. If the parameters are different, correct it. -I you own a Gallant's audio card based on SC-6600, activate the SC-6600 support. -If you want to change the configuration of the sound board, be sure to -check off all the configuration items before re-configure it. - -Module parameters ------------------ -To use this driver as a module, you must configure some module parameters, to -set up I/O addresses, IRQ lines and DMA channels. Some parameters are -mandatory while some others are optional. Here a list of parameters you can -use with this module: - -Name Description -==== =========== -MANDATORY -io I/O base address (0x220 or 0x240) -irq irq line (5, 7, 9, 10 or 11) -dma dma channel (0, 1 or 3) - -OPTIONAL -mss_base I/O base address for activate MSS mode (default SBPRO) - (0x530 or 0xE80) -mpu_base I/O base address for activate MPU-401 mode - (0x300, 0x310, 0x320 or 0x330) -mpu_irq MPU-401 irq line (5, 7, 9, 10 or 0) - -A configuration file in /etc/modprobe.d/ directory will have lines like this: - -options opl3 io=0x388 -options ad1848 io=0x530 irq=11 dma=3 -options aedsp16 io=0x220 irq=11 dma=3 mss_base=0x530 - -Where the aedsp16 options are the options for this driver while opl3 and -ad1848 are the corresponding options for the MSS and OPL3 modules. - -Loading MSS and OPL3 needs to pre load the aedsp16 module to set up correctly -the sound card. Installation dependencies must be written in configuration -files under /etc/modprobe.d/ directory: - -softdep ad1848 pre: aedsp16 -softdep opl3 pre: aedsp16 - -Then you must load the sound modules stack in this order: -sound -> aedsp16 -> [ ad1848, opl3 ] - -With the above configuration, loading ad1848 or opl3 modules, will -automatically load all the sound stack. - -Sound cards supported ---------------------- -This driver supports the SC-6000 and SC-6600 based Gallant's sound card. -It don't support the Audio Excel DSP 16 III (try the SC-6600 code). -I'm working on the III version of the card: if someone have useful -information about it, please let me know. -For all the non-supported audio cards, you have to boot MS-DOS (or WIN95) -activating the audio card with the MS-DOS device driver, then you have to --- and boot Linux. -Follow these steps: - -1) Compile Linux kernel with standard sound driver, using the emulation - you want, with the parameters of your audio card, - e.g. Microsoft Sound System irq10 dma3 -2) Install your new kernel as the default boot kernel. -3) Boot MS-DOS and configure the audio card with the boot time device - driver, for MSS irq10 dma3 in our example. -4) -- and boot Linux. This will maintain the DOS configuration - and will boot the new kernel with sound driver. The sound driver will find - the audio card and will recognize and attach it. - -Reports on User successes -------------------------- - -> Date: Mon, 29 Jul 1996 08:35:40 +0100 -> From: Mr S J Greenaway -> To: riccardo@cdc8g5.cdc.polimi.it (Riccardo Facchetti) -> Subject: Re: Audio Excel DSP 16 initialization code -> -> Just to let you know got my Audio Excel (emulating a MSS) working -> with my original SB16, thanks for the driver! - - -Last revised: 20 August 1998 -Riccardo Facchetti -fizban@tin.it diff --git a/Documentation/sound/oss/CMI8330 b/Documentation/sound/oss/CMI8330 deleted file mode 100644 index 8a5fd1611c6f..000000000000 --- a/Documentation/sound/oss/CMI8330 +++ /dev/null @@ -1,152 +0,0 @@ -Documentation for CMI 8330 (SoundPRO) -------------------------------------- -Alessandro Zummo - -( Be sure to read Documentation/sound/oss/SoundPro too ) - - -This adapter is now directly supported by the sb driver. - - The only thing you have to do is to compile the kernel sound -support as a module and to enable kernel ISAPnP support, -as shown below. - - -CONFIG_SOUND=m -CONFIG_SOUND_SB=m - -CONFIG_PNP=y -CONFIG_ISAPNP=y - - -and optionally: - - -CONFIG_SOUND_MPU401=m - - for MPU401 support. - - -(I suggest you to use "make menuconfig" or "make xconfig" - for a more comfortable configuration editing) - - - -Then you can do - - modprobe sb - -and everything will be (hopefully) configured. - -You should get something similar in syslog: - -sb: CMI8330 detected. -sb: CMI8330 sb base located at 0x220 -sb: CMI8330 mpu base located at 0x330 -sb: CMI8330 mail reports to Alessandro Zummo -sb: ISAPnP reports CMI 8330 SoundPRO at i/o 0x220, irq 7, dma 1,5 - - - - -The old documentation file follows for reference -purposes. - - -How to enable CMI 8330 (SOUNDPRO) soundchip on Linux ------------------------------------------- -Stefan Laudat - -[Note: The CMI 8338 is unrelated and is supported by cmpci.o] - - - In order to use CMI8330 under Linux you just have to use a proper isapnp.conf, a good isapnp and a little bit of patience. I use isapnp 1.17, but -you may get a better one I guess at http://www.roestock.demon.co.uk/isapnptools/. - - Of course you will have to compile kernel sound support as module, as shown below: - -CONFIG_SOUND=m -CONFIG_SOUND_OSS=m -CONFIG_SOUND_SB=m -CONFIG_SOUND_ADLIB=m -CONFIG_SOUND_MPU401=m -# Mikro$chaft sound system (kinda useful here ;)) -CONFIG_SOUND_MSS=m - - The /etc/isapnp.conf file will be: - - - - -(READPORT 0x0203) -(ISOLATE PRESERVE) -(IDENTIFY *) -(VERBOSITY 2) -(CONFLICT (IO FATAL)(IRQ FATAL)(DMA FATAL)(MEM FATAL)) # or WARNING -(VERIFYLD N) - - -# WSS - -(CONFIGURE CMI0001/16777472 (LD 0 -(IO 0 (SIZE 8) (BASE 0x0530)) -(IO 1 (SIZE 8) (BASE 0x0388)) -(INT 0 (IRQ 7 (MODE +E))) -(DMA 0 (CHANNEL 0)) -(NAME "CMI0001/16777472[0]{CMI8330/C3D Audio Adapter}") -(ACT Y) -)) - -# MPU - -(CONFIGURE CMI0001/16777472 (LD 1 -(IO 0 (SIZE 2) (BASE 0x0330)) -(INT 0 (IRQ 11 (MODE +E))) -(NAME "CMI0001/16777472[1]{CMI8330/C3D Audio Adapter}") -(ACT Y) -)) - -# Joystick - -(CONFIGURE CMI0001/16777472 (LD 2 -(IO 0 (SIZE 8) (BASE 0x0200)) -(NAME "CMI0001/16777472[2]{CMI8330/C3D Audio Adapter}") -(ACT Y) -)) - -# SoundBlaster - -(CONFIGURE CMI0001/16777472 (LD 3 -(IO 0 (SIZE 16) (BASE 0x0220)) -(INT 0 (IRQ 5 (MODE +E))) -(DMA 0 (CHANNEL 1)) -(DMA 1 (CHANNEL 5)) -(NAME "CMI0001/16777472[3]{CMI8330/C3D Audio Adapter}") -(ACT Y) -)) - - -(WAITFORKEY) - - - - The module sequence is trivial: - -/sbin/insmod soundcore -/sbin/insmod sound -/sbin/insmod uart401 -# insert this first -/sbin/insmod ad1848 io=0x530 irq=7 dma=0 soundpro=1 -# The sb module is an alternative to the ad1848 (Microsoft Sound System) -# Anyhow, this is full duplex and has MIDI -/sbin/insmod sb io=0x220 dma=1 dma16=5 irq=5 mpu_io=0x330 - - - -Alma Chao suggests the following in -a /etc/modprobe.d/*conf file: - -alias sound ad1848 -alias synth0 opl3 -options ad1848 io=0x530 irq=7 dma=0 soundpro=1 -options opl3 io=0x388 diff --git a/Documentation/sound/oss/ESS b/Documentation/sound/oss/ESS deleted file mode 100644 index bba93b4d2def..000000000000 --- a/Documentation/sound/oss/ESS +++ /dev/null @@ -1,34 +0,0 @@ -Documentation for the ESS AudioDrive chips - -In 2.4 kernels the SoundBlaster driver not only tries to detect an ESS chip, it -tries to detect the type of ESS chip too. The correct detection of the chip -doesn't always succeed however, so unless you use the kernel isapnp facilities -(and you chip is pnp capable) the default behaviour is 2.0 behaviour which -means: only detect ES688 and ES1688. - -All ESS chips now have a recording level setting. This is a need-to-have for -people who want to use their ESS for recording sound. - -Every chip that's detected as a later-than-es1688 chip has a 6 bits logarithmic -master volume control. - -Every chip that's detected as a ES1887 now has Full Duplex support. Made a -little testprogram that shows that is works, haven't seen a real program that -needs this however. - -For ESS chips an additional parameter "esstype" can be specified. This controls -the (auto) detection of the ESS chips. It can have 3 kinds of values: - --1 Act like 2.0 kernels: only detect ES688 or ES1688. -0 Try to auto-detect the chip (may fail for ES1688) -688 The chip will be treated as ES688 -1688 ,, ,, ,, ,, ,, ,, ES1688 -1868 ,, ,, ,, ,, ,, ,, ES1868 -1869 ,, ,, ,, ,, ,, ,, ES1869 -1788 ,, ,, ,, ,, ,, ,, ES1788 -1887 ,, ,, ,, ,, ,, ,, ES1887 -1888 ,, ,, ,, ,, ,, ,, ES1888 - -Because Full Duplex is supported for ES1887 you can specify a second DMA -channel by specifying module parameter dma16. It can be one of: 0, 1, 3 or 5. - diff --git a/Documentation/sound/oss/ESS1868 b/Documentation/sound/oss/ESS1868 deleted file mode 100644 index 55e922f21bc0..000000000000 --- a/Documentation/sound/oss/ESS1868 +++ /dev/null @@ -1,55 +0,0 @@ -Documentation for the ESS1868F AudioDrive PnP sound card - -The ESS1868 sound card is a PnP ESS1688-compatible 16-bit sound card. - -It should be automatically detected by the Linux Kernel isapnp support when you -load the sb.o module. Otherwise you should take care of: - - * The ESS1868 does not allow use of a 16-bit DMA, thus DMA 0, 1, 2, and 3 - may only be used. - - * isapnptools version 1.14 does work with ESS1868. Earlier versions might - not. - - * Sound support MUST be compiled as MODULES, not statically linked - into the kernel. - - -NOTE: this is only needed when not using the kernel isapnp support! - -For configuring the sound card's I/O addresses, IRQ and DMA, here is a -sample copy of the isapnp.conf directives regarding the ESS1868: - -(CONFIGURE ESS1868/-1 (LD 1 -(IO 0 (BASE 0x0220)) -(IO 1 (BASE 0x0388)) -(IO 2 (BASE 0x0330)) -(DMA 0 (CHANNEL 1)) -(INT 0 (IRQ 5 (MODE +E))) -(ACT Y) -)) - -(for a full working isapnp.conf file, remember the -(ISOLATE) -(IDENTIFY *) -at the beginning and the -(WAITFORKEY) -at the end.) - -In this setup, the main card I/O is 0x0220, FM synthesizer is 0x0388, and -the MPU-401 MIDI port is located at 0x0330. IRQ is IRQ 5, DMA is channel 1. - -After configuring the sound card via isapnp, to use the card you must load -the sound modules with the proper I/O information. Here is my setup: - -# ESS1868F AudioDrive initialization - -/sbin/modprobe sound -/sbin/insmod uart401 -/sbin/insmod sb io=0x220 irq=5 dma=1 dma16=-1 -/sbin/insmod mpu401 io=0x330 -/sbin/insmod opl3 io=0x388 -/sbin/insmod v_midi - -opl3 is the FM synthesizer -/sbin/insmod opl3 io=0x388 diff --git a/Documentation/sound/oss/Introduction b/Documentation/sound/oss/Introduction deleted file mode 100644 index 42da2d8fa372..000000000000 --- a/Documentation/sound/oss/Introduction +++ /dev/null @@ -1,459 +0,0 @@ -Introduction Notes on Modular Sound Drivers and Soundcore -Wade Hampton -2/14/2001 - -Purpose: -======== -This document provides some general notes on the modular -sound drivers and their configuration, along with the -support modules sound.o and soundcore.o. - -Note, some of this probably should be added to the Sound-HOWTO! - -Note, soundlow.o was present with 2.2 kernels but is not -required for 2.4.x kernels. References have been removed -to this. - - -Copying: -======== -none - - -History: -======== -0.1.0 11/20/1998 First version, draft -1.0.0 11/1998 Alan Cox changes, incorporation in 2.2.0 - as Documentation/sound/oss/Introduction -1.1.0 6/30/1999 Second version, added notes on making the drivers, - added info on multiple sound cards of similar types,] - added more diagnostics info, added info about esd. - added info on OSS and ALSA. -1.1.1 19991031 Added notes on sound-slot- and sound-service. - (Alan Cox) -1.1.2 20000920 Modified for Kernel 2.4 (Christoph Hellwig) -1.1.3 20010214 Minor notes and corrections (Wade Hampton) - Added examples of sound-slot-0, etc. - - -Modular Sound Drivers: -====================== - -Thanks to the GREAT work by Alan Cox (alan@lxorguk.ukuu.org.uk), - -[And Oleg Drokin, Thomas Sailer, Andrew Veliath and more than a few - others - not to mention Hannu's original code being designed well - enough to cope with that kind of chopping up](Alan) - -the standard Linux kernels support a modular sound driver. From -Alan's comments in linux/drivers/sound/README.FIRST: - - The modular sound driver patches were funded by Red Hat Software - (www.redhat.com). The sound driver here is thus a modified version of - Hannu's code. Please bear that in mind when considering the appropriate - forums for bug reporting. - -The modular sound drivers may be loaded via insmod or modprobe. -To support all the various sound modules, there are two general -support modules that must be loaded first: - - soundcore.o: Top level handler for the sound system, provides - a set of functions for registration of devices - by type. - - sound.o: Common sound functions required by all modules. - -For the specific sound modules (e.g., sb.o for the Soundblaster), -read the documentation on that module to determine what options -are available, for example IRQ, address, DMA. - -Warning, the options for different cards sometime use different names -for the same or a similar feature (dma1= versus dma16=). As a last -resort, inspect the code (search for module_param). - -Notes: - -1. There is a new OpenSource sound driver called ALSA which is - currently under development: http://www.alsa-project.org/ - The ALSA drivers support some newer hardware that may not - be supported by this sound driver and also provide some - additional features. - -2. The commercial OSS driver may be obtained from the site: - http://www.opensound.com. This may be used for cards that - are unsupported by the kernel driver, or may be used - by other operating systems. - -3. The enlightenment sound daemon may be used for playing - multiple sounds at the same time via a single card, eliminating - some of the requirements for multiple sound card systems. For - more information, see: http://www.tux.org/~ricdude/EsounD.html - The "esd" program may be used with the real-player and mpeg - players like mpg123 and x11amp. The newer real-player - and some games even include built-in support for ESD! - - -Building the Modules: -===================== - -This document does not provide full details on building the -kernel, etc. The notes below apply only to making the kernel -sound modules. If this conflicts with the kernel's README, -the README takes precedence. - -1. To make the kernel sound modules, cd to your /usr/src/linux - directory (typically) and type make config, make menuconfig, - or make xconfig (to start the command line, dialog, or x-based - configuration tool). - -2. Select the Sound option and a dialog will be displayed. - -3. Select M (module) for "Sound card support". - -4. Select your sound driver(s) as a module. For ProAudio, Sound - Blaster, etc., select M (module) for OSS sound modules. - [thanks to Marvin Stodolsky ]A - -5. Make the kernel (e.g., make bzImage), and install the kernel. - -6. Make the modules and install them (make modules; make modules_install). - -Note, for 2.5.x kernels, make sure you have the newer module-init-tools -installed or modules will not be loaded properly. 2.5.x requires an -updated module-init-tools. - - -Plug and Play (PnP: -=================== - -If the sound card is an ISA PnP card, isapnp may be used -to configure the card. See the file isapnp.txt in the -directory one level up (e.g., /usr/src/linux/Documentation). - -Also the 2.4.x kernels provide PnP capabilities, see the -file NEWS in this directory. - -PCI sound cards are highly recommended, as they are far -easier to configure and from what I have read, they use -less resources and are more CPU efficient. - - -INSMOD: -======= - -If loading via insmod, the common modules must be loaded in the -order below BEFORE loading the other sound modules. The card-specific -modules may then be loaded (most require parameters). For example, -I use the following via a shell script to load my SoundBlaster: - -SB_BASE=0x240 -SB_IRQ=9 -SB_DMA=3 -SB_DMA2=5 -SB_MPU=0x300 -# -echo Starting sound -/sbin/insmod soundcore -/sbin/insmod sound -# -echo Starting sound blaster.... -/sbin/insmod uart401 -/sbin/insmod sb io=$SB_BASE irq=$SB_IRQ dma=$SB_DMA dma16=$SB_DMA2 mpu_io=$SB_MP - -When using sound as a module, I typically put these commands -in a file such as /root/soundon.sh. - - -MODPROBE: -========= - -If loading via modprobe, these common files are automatically loaded when -requested by modprobe. For example, my /etc/modprobe.d/oss.conf contains: - -alias sound sb -options sb io=0x240 irq=9 dma=3 dma16=5 mpu_io=0x300 - -All you need to do to load the module is: - - /sbin/modprobe sb - - -Sound Status: -============= - -The status of sound may be read/checked by: - cat (anyfile).au >/dev/audio - -[WWH: This may not work properly for SoundBlaster PCI 128 cards -such as the es1370/1 (see the es1370/1 files in this directory) -as they do not automatically support uLaw on /dev/audio.] - -The status of the modules and which modules depend on -which other modules may be checked by: - /sbin/lsmod - -/sbin/lsmod should show something like the following: - sb 26280 0 - uart401 5640 0 [sb] - sound 57112 0 [sb uart401] - soundcore 1968 8 [sb sound] - - -Removing Sound: -=============== - -Sound may be removed by using /sbin/rmmod in the reverse order -in which you load the modules. Note, if a program has a sound device -open (e.g., xmixer), that module (and the modules on which it -depends) may not be unloaded. - -For example, I use the following to remove my Soundblaster (rmmod -in the reverse order in which I loaded the modules): - -/sbin/rmmod sb -/sbin/rmmod uart401 -/sbin/rmmod sound -/sbin/rmmod soundcore - -When using sound as a module, I typically put these commands -in a script such as /root/soundoff.sh. - - -Removing Sound for use with OSS: -================================ - -If you get really stuck or have a card that the kernel modules -will not support, you can get a commercial sound driver from -http://www.opensound.com. Before loading the commercial sound -driver, you should do the following: - -1. remove sound modules (detailed above) -2. remove the sound modules from /etc/modprobe.d/*.conf -3. move the sound modules from /lib/modules//misc - (for example, I make a /lib/modules//misc/tmp - directory and copy the sound module files to that - directory). - - -Multiple Sound Cards: -===================== - -The sound drivers will support multiple sound cards and there -are some great applications like multitrack that support them. -Typically, you need two sound cards of different types. Note, this -uses more precious interrupts and DMA channels and sometimes -can be a configuration nightmare. I have heard reports of 3-4 -sound cards (typically I only use 2). You can sometimes use -multiple PCI sound cards of the same type. - -On my machine I have two sound cards (cs4232 and Soundblaster Vibra -16). By loading sound as modules, I can control which is the first -sound device (/dev/dsp, /dev/audio, /dev/mixer) and which is -the second. Normally, the cs4232 (Dell sound on the motherboard) -would be the first sound device, but I prefer the Soundblaster. -All you have to do is to load the one you want as /dev/dsp -first (in my case "sb") and then load the other one -(in my case "cs4232"). - -If you have two cards of the same type that are jumpered -cards or different PnP revisions, you may load the same -module twice. For example, I have a SoundBlaster vibra 16 -and an older SoundBlaster 16 (jumpers). To load the module -twice, you need to do the following: - -1. Copy the sound modules to a new name. For example - sb.o could be copied (or symlinked) to sb1.o for the - second SoundBlaster. - -2. Make a second entry in /etc/modprobe.d/*conf, for example, - sound1 or sb1. This second entry should refer to the - new module names for example sb1, and should include - the I/O, etc. for the second sound card. - -3. Update your soundon.sh script, etc. - -Warning: I have never been able to get two PnP sound cards of the -same type to load at the same time. I have tried this several times -with the Soundblaster Vibra 16 cards. OSS has indicated that this -is a PnP problem.... If anyone has any luck doing this, please -send me an E-MAIL. PCI sound cards should not have this problem.a -Since this was originally release, I have received a couple of -mails from people who have accomplished this! - -NOTE: In Linux 2.4 the Sound Blaster driver (and only this one yet) -supports multiple cards with one module by default. -Read the file 'Soundblaster' in this directory for details. - - -Sound Problems: -=============== - -First RTFM (including the troubleshooting section -in the Sound-HOWTO). - -1) If you are having problems loading the modules (for - example, if you get device conflict errors) try the - following: - - A) If you have Win95 or NT on the same computer, - write down what addresses, IRQ, and DMA channels - those were using for the same hardware. You probably - can use these addresses, IRQs, and DMA channels. - You should really do this BEFORE attempting to get - sound working! - - B) Check (cat) /proc/interrupts, /proc/ioports, - and /proc/dma. Are you trying to use an address, - IRQ or DMA port that another device is using? - - C) Check (cat) /proc/isapnp - - D) Inspect your /var/log/messages file. Often that will - indicate what IRQ or IO port could not be obtained. - - E) Try another port or IRQ. Note this may involve - using the PnP tools to move the sound card to - another location. Sometimes this is the only way - and it is more or less trial and error. - -2) If you get motor-boating (the same sound or part of a - sound clip repeated), you probably have either an IRQ - or DMA conflict. Move the card to another IRQ or DMA - port. This has happened to me when playing long files - when I had an IRQ conflict. - -3. If you get dropouts or pauses when playing high sample - rate files such as using mpg123 or x11amp/xmms, you may - have too slow of a CPU and may have to use the options to - play the files at 1/2 speed. For example, you may use - the -2 or -4 option on mpg123. You may also get this - when trying to play mpeg files stored on a CD-ROM - (my Toshiba T8000 PII/366 sometimes has this problem). - -4. If you get "cannot access device" errors, your /dev/dsp - files, etc. may be set to owner root, mode 600. You - may have to use the command: - chmod 666 /dev/dsp /dev/mixer /dev/audio - -5. If you get "device busy" errors, another program has the - sound device open. For example, if using the Enlightenment - sound daemon "esd", the "esd" program has the sound device. - If using "esd", please RTFM the docs on ESD. For example, - esddsp may be used to play files via a non-esd - aware program. - -6) Ask for help on the sound list or send E-MAIL to the - sound driver author/maintainer. - -7) Turn on debug in drivers/sound/sound_config.h (DEB, DDB, MDB). - -8) If the system reports insufficient DMA memory then you may want to - load sound with the "dmabufs=1" option. Or in /etc/conf.modules add - - preinstall sound dmabufs=1 - - This makes the sound system allocate its buffers and hang onto them. - - You may also set persistent DMA when building a 2.4.x kernel. - - -Configuring Sound: -================== - -There are several ways of configuring your sound: - -1) On the kernel command line (when using the sound driver(s) - compiled in the kernel). Check the driver source and - documentation for details. - -2) On the command line when using insmod or in a bash script - using command line calls to load sound. - -3) In /etc/modprobe.d/*conf when using modprobe. - -4) Via Red Hat's GPL'd /usr/sbin/sndconfig program (text based). - -5) Via the OSS soundconf program (with the commercial version - of the OSS driver. - -6) By just loading the module and let isapnp do everything relevant - for you. This works only with a few drivers yet and - of course - - only with isapnp hardware. - -And I am sure, several other ways. - -Anyone want to write a linuxconf module for configuring sound? - - -Module Loading: -=============== - -When a sound card is first referenced and sound is modular, the sound system -will ask for the sound devices to be loaded. Initially it requests that -the driver for the sound system is loaded. It then will ask for -sound-slot-0, where 0 is the first sound card. (sound-slot-1 the second and -so on). Thus you can do - -alias sound-slot-0 sb - -To load a soundblaster at this point. If the slot loading does not provide -the desired device - for example a soundblaster does not directly provide -a midi synth in all cases then it will request "sound-service-0-n" where n -is - - 0 Mixer - - 2 MIDI - - 3, 4 DSP audio - - -For example, I use the following to load my Soundblaster PCI 128 -(ES 1371) card first, followed by my SoundBlaster Vibra 16 card, -then by my TV card: - -# Load the Soundblaster PCI 128 as /dev/dsp, /dev/dsp1, /dev/mixer -alias sound-slot-0 es1371 - -# Load the Soundblaster Vibra 16 as /dev/dsp2, /dev/mixer1 -alias sound-slot-1 sb -options sb io=0x240 irq=5 dma=1 dma16=5 mpu_io=0x330 - -# Load the BTTV (TV card) as /dev/mixer2 -alias sound-slot-2 bttv -alias sound-service-2-0 tvmixer - -pre-install bttv modprobe tuner ; modprobe tvmixer -pre-install tvmixer modprobe msp3400; modprobe tvaudio -options tuner debug=0 type=8 -options bttv card=0 radio=0 pll=0 - - -For More Information (RTFM): -============================ -1) Information on kernel modules: manual pages for insmod and modprobe. - -2) Information on PnP, RTFM manual pages for isapnp. - -3) Sound-HOWTO and Sound-Playing-HOWTO. - -4) OSS's WWW site at http://www.opensound.com. - -5) All the files in Documentation/sound. - -6) The comments and code in linux/drivers/sound. - -7) The sndconfig and rhsound documentation from Red Hat. - -8) The Linux-sound mailing list: sound-list@redhat.com. - -9) Enlightenment documentation (for info on esd) - http://www.tux.org/~ricdude/EsounD.html. - -10) ALSA home page: http://www.alsa-project.org/ - - -Contact Information: -==================== -Wade Hampton: (whampton@staffnet.com) - diff --git a/Documentation/sound/oss/MultiSound b/Documentation/sound/oss/MultiSound deleted file mode 100644 index e4a18bb7f73a..000000000000 --- a/Documentation/sound/oss/MultiSound +++ /dev/null @@ -1,1137 +0,0 @@ -#! /bin/sh -# -# Turtle Beach MultiSound Driver Notes -# -- Andrew Veliath -# -# Last update: September 10, 1998 -# Corresponding msnd driver: 0.8.3 -# -# ** This file is a README (top part) and shell archive (bottom part). -# The corresponding archived utility sources can be unpacked by -# running `sh MultiSound' (the utilities are only needed for the -# Pinnacle and Fiji cards). ** -# -# -# -=-=- Getting Firmware -=-=- -# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -# -# See the section `Obtaining and Creating Firmware Files' in this -# document for instructions on obtaining the necessary firmware -# files. -# -# -# Supported Features -# ~~~~~~~~~~~~~~~~~~ -# -# Currently, full-duplex digital audio (/dev/dsp only, /dev/audio is -# not currently available) and mixer functionality (/dev/mixer) are -# supported (memory mapped digital audio is not yet supported). -# Digital transfers and monitoring can be done as well if you have -# the digital daughterboard (see the section on using the S/PDIF port -# for more information). -# -# Support for the Turtle Beach MultiSound Hurricane architecture is -# composed of the following modules (these can also operate compiled -# into the kernel): -# -# msnd - MultiSound base (requires soundcore) -# -# msnd_classic - Base audio/mixer support for Classic, Monetery and -# Tahiti cards -# -# msnd_pinnacle - Base audio/mixer support for Pinnacle and Fiji cards -# -# -# Important Notes - Read Before Using -# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -# -# The firmware files are not included (may change in future). You -# must obtain these images from Turtle Beach (they are included in -# the MultiSound Development Kits), and place them in /etc/sound for -# example, and give the full paths in the Linux configuration. If -# you are compiling in support for the MultiSound driver rather than -# using it as a module, these firmware files must be accessible -# during kernel compilation. -# -# Please note these files must be binary files, not assembler. See -# the section later in this document for instructions to obtain these -# files. -# -# -# Configuring Card Resources -# ~~~~~~~~~~~~~~~~~~~~~~~~~~ -# -# ** This section is very important, as your card may not work at all -# or your machine may crash if you do not do this correctly. ** -# -# * Classic/Monterey/Tahiti -# -# These cards are configured through the driver msnd_classic. You must -# know the io port, then the driver will select the irq and memory resources -# on the card. It is up to you to know if these are free locations or now, -# a conflict can lock the machine up. -# -# * Pinnacle/Fiji -# -# The Pinnacle and Fiji cards have an extra config port, either -# 0x250, 0x260 or 0x270. This port can be disabled to have the card -# configured strictly through PnP, however you lose the ability to -# access the IDE controller and joystick devices on this card when -# using PnP. The included pinnaclecfg program in this shell archive -# can be used to configure the card in non-PnP mode, and in PnP mode -# you can use isapnptools. These are described briefly here. -# -# pinnaclecfg is not required; you can use the msnd_pinnacle module -# to fully configure the card as well. However, pinnaclecfg can be -# used to change the resource values of a particular device after the -# msnd_pinnacle module has been loaded. If you are compiling the -# driver into the kernel, you must set these values during compile -# time, however other peripheral resource values can be changed with -# the pinnaclecfg program after the kernel is loaded. -# -# -# *** PnP mode -# -# Use pnpdump to obtain a sample configuration if you can; I was able -# to obtain one with the command `pnpdump 1 0x203' -- this may vary -# for you (running pnpdump by itself did not work for me). Then, -# edit this file and use isapnp to uncomment and set the card values. -# Use these values when inserting the msnd_pinnacle module. Using -# this method, you can set the resources for the DSP and the Kurzweil -# synth (Pinnacle). Since Linux does not directly support PnP -# devices, you may have difficulty when using the card in PnP mode -# when it the driver is compiled into the kernel. Using non-PnP mode -# is preferable in this case. -# -# Here is an example mypinnacle.conf for isapnp that sets the card to -# io base 0x210, irq 5 and mem 0xd8000, and also sets the Kurzweil -# synth to 0x330 and irq 9 (may need editing for your system): -# -# (READPORT 0x0203) -# (CSN 2) -# (IDENTIFY *) -# -# # DSP -# (CONFIGURE BVJ0440/-1 (LD 0 -# (INT 0 (IRQ 5 (MODE +E))) (IO 0 (BASE 0x0210)) (MEM 0 (BASE 0x0d8000)) -# (ACT Y))) -# -# # Kurzweil Synth (Pinnacle Only) -# (CONFIGURE BVJ0440/-1 (LD 1 -# (IO 0 (BASE 0x0330)) (INT 0 (IRQ 9 (MODE +E))) -# (ACT Y))) -# -# (WAITFORKEY) -# -# -# *** Non-PnP mode -# -# The second way is by running the card in non-PnP mode. This -# actually has some advantages in that you can access some other -# devices on the card, such as the joystick and IDE controller. To -# configure the card, unpack this shell archive and build the -# pinnaclecfg program. Using this program, you can assign the -# resource values to the card's devices, or disable the devices. As -# an alternative to using pinnaclecfg, you can specify many of the -# configuration values when loading the msnd_pinnacle module (or -# during kernel configuration when compiling the driver into the -# kernel). -# -# If you specify cfg=0x250 for the msnd_pinnacle module, it -# automatically configure the card to the given io, irq and memory -# values using that config port (the config port is jumper selectable -# on the card to 0x250, 0x260 or 0x270). -# -# See the `msnd_pinnacle Additional Options' section below for more -# information on these parameters (also, if you compile the driver -# directly into the kernel, these extra parameters can be useful -# here). -# -# -# ** It is very easy to cause problems in your machine if you choose a -# resource value which is incorrect. ** -# -# -# Examples -# ~~~~~~~~ -# -# * MultiSound Classic/Monterey/Tahiti: -# -# modprobe soundcore -# insmod msnd -# insmod msnd_classic io=0x290 irq=7 mem=0xd0000 -# -# * MultiSound Pinnacle in PnP mode: -# -# modprobe soundcore -# insmod msnd -# isapnp mypinnacle.conf -# insmod msnd_pinnacle io=0x210 irq=5 mem=0xd8000 <-- match mypinnacle.conf values -# -# * MultiSound Pinnacle in non-PnP mode (replace 0x250 with your configuration port, -# one of 0x250, 0x260 or 0x270): -# -# insmod soundcore -# insmod msnd -# insmod msnd_pinnacle cfg=0x250 io=0x290 irq=5 mem=0xd0000 -# -# * To use the MPU-compatible Kurzweil synth on the Pinnacle in PnP -# mode, add the following (assumes you did `isapnp mypinnacle.conf'): -# -# insmod sound -# insmod mpu401 io=0x330 irq=9 <-- match mypinnacle.conf values -# -# * To use the MPU-compatible Kurzweil synth on the Pinnacle in non-PnP -# mode, add the following. Note how we first configure the peripheral's -# resources, _then_ install a Linux driver for it: -# -# insmod sound -# pinnaclecfg 0x250 mpu 0x330 9 -# insmod mpu401 io=0x330 irq=9 -# -# -- OR you can use the following sequence without pinnaclecfg in non-PnP mode: -# -# insmod soundcore -# insmod msnd -# insmod msnd_pinnacle cfg=0x250 io=0x290 irq=5 mem=0xd0000 mpu_io=0x330 mpu_irq=9 -# insmod sound -# insmod mpu401 io=0x330 irq=9 -# -# * To setup the joystick port on the Pinnacle in non-PnP mode (though -# you have to find the actual Linux joystick driver elsewhere), you -# can use pinnaclecfg: -# -# pinnaclecfg 0x250 joystick 0x200 -# -# -- OR you can configure this using msnd_pinnacle with the following: -# -# insmod soundcore -# insmod msnd -# insmod msnd_pinnacle cfg=0x250 io=0x290 irq=5 mem=0xd0000 joystick_io=0x200 -# -# -# msnd_classic, msnd_pinnacle Required Options -# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -# -# If the following options are not given, the module will not load. -# Examine the kernel message log for informative error messages. -# WARNING--probing isn't supported so try to make sure you have the -# correct shared memory area, otherwise you may experience problems. -# -# io I/O base of DSP, e.g. io=0x210 -# irq IRQ number, e.g. irq=5 -# mem Shared memory area, e.g. mem=0xd8000 -# -# -# msnd_classic, msnd_pinnacle Additional Options -# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -# -# fifosize The digital audio FIFOs, in kilobytes. If not -# specified, the default will be used. Increasing -# this value will reduce the chance of a FIFO -# underflow at the expense of increasing overall -# latency. For example, fifosize=512 will -# allocate 512kB read and write FIFOs (1MB total). -# While this may reduce dropouts, a heavy machine -# load will undoubtedly starve the FIFO of data -# and you will eventually get dropouts. One -# option is to alter the scheduling priority of -# the playback process, using `nice' or some form -# of POSIX soft real-time scheduling. -# -# calibrate_signal Setting this to one calibrates the ADCs to the -# signal, zero calibrates to the card (defaults -# to zero). -# -# -# msnd_pinnacle Additional Options -# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -# -# digital Specify digital=1 to enable the S/PDIF input -# if you have the digital daughterboard -# adapter. This will enable access to the -# DIGITAL1 input for the soundcard in the mixer. -# Some mixer programs might have trouble setting -# the DIGITAL1 source as an input. If you have -# trouble, you can try the setdigital.c program -# at the bottom of this document. -# -# cfg Non-PnP configuration port for the Pinnacle -# and Fiji (typically 0x250, 0x260 or 0x270, -# depending on the jumper configuration). If -# this option is omitted, then it is assumed -# that the card is in PnP mode, and that the -# specified DSP resource values are already -# configured with PnP (i.e. it won't attempt to -# do any sort of configuration). -# -# When the Pinnacle is in non-PnP mode, you can use the following -# options to configure particular devices. If a full specification -# for a device is not given, then the device is not configured. Note -# that you still must use a Linux driver for any of these devices -# once their resources are setup (such as the Linux joystick driver, -# or the MPU401 driver from OSS for the Kurzweil synth). -# -# mpu_io I/O port of MPU (on-board Kurzweil synth) -# mpu_irq IRQ of MPU (on-board Kurzweil synth) -# ide_io0 First I/O port of IDE controller -# ide_io1 Second I/O port of IDE controller -# ide_irq IRQ IDE controller -# joystick_io I/O port of joystick -# -# -# Obtaining and Creating Firmware Files -# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -# -# For the Classic/Tahiti/Monterey -# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -# -# Download to /tmp and unzip the following file from Turtle Beach: -# -# ftp://ftp.voyetra.com/pub/tbs/msndcl/msndvkit.zip -# -# When unzipped, unzip the file named MsndFiles.zip. Then copy the -# following firmware files to /etc/sound (note the file renaming): -# -# cp DSPCODE/MSNDINIT.BIN /etc/sound/msndinit.bin -# cp DSPCODE/MSNDPERM.REB /etc/sound/msndperm.bin -# -# When configuring the Linux kernel, specify /etc/sound/msndinit.bin and -# /etc/sound/msndperm.bin for the two firmware files (Linux kernel -# versions older than 2.2 do not ask for firmware paths, and are -# hardcoded to /etc/sound). -# -# If you are compiling the driver into the kernel, these files must -# be accessible during compilation, but will not be needed later. -# The files must remain, however, if the driver is used as a module. -# -# -# For the Pinnacle/Fiji -# ~~~~~~~~~~~~~~~~~~~~~ -# -# Download to /tmp and unzip the following file from Turtle Beach (be -# sure to use the entire URL; some have had trouble navigating to the -# URL): -# -# ftp://ftp.voyetra.com/pub/tbs/pinn/pnddk100.zip -# -# Unpack this shell archive, and run make in the created directory -# (you need a C compiler and flex to build the utilities). This -# should give you the executables conv, pinnaclecfg and setdigital. -# conv is only used temporarily here to create the firmware files, -# while pinnaclecfg is used to configure the Pinnacle or Fiji card in -# non-PnP mode, and setdigital can be used to set the S/PDIF input on -# the mixer (pinnaclecfg and setdigital should be copied to a -# convenient place, possibly run during system initialization). -# -# To generating the firmware files with the `conv' program, we create -# the binary firmware files by doing the following conversion -# (assuming the archive unpacked into a directory named PINNDDK): -# -# ./conv < PINNDDK/dspcode/pndspini.asm > /etc/sound/pndspini.bin -# ./conv < PINNDDK/dspcode/pndsperm.asm > /etc/sound/pndsperm.bin -# -# The conv (and conv.l) program is not needed after conversion and can -# be safely deleted. Then, when configuring the Linux kernel, specify -# /etc/sound/pndspini.bin and /etc/sound/pndsperm.bin for the two -# firmware files (Linux kernel versions older than 2.2 do not ask for -# firmware paths, and are hardcoded to /etc/sound). -# -# If you are compiling the driver into the kernel, these files must -# be accessible during compilation, but will not be needed later. -# The files must remain, however, if the driver is used as a module. -# -# -# Using Digital I/O with the S/PDIF Port -# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -# -# If you have a Pinnacle or Fiji with the digital daughterboard and -# want to set it as the input source, you can use this program if you -# have trouble trying to do it with a mixer program (be sure to -# insert the module with the digital=1 option, or say Y to the option -# during compiled-in kernel operation). Upon selection of the S/PDIF -# port, you should be able monitor and record from it. -# -# There is something to note about using the S/PDIF port. Digital -# timing is taken from the digital signal, so if a signal is not -# connected to the port and it is selected as recording input, you -# will find PCM playback to be distorted in playback rate. Also, -# attempting to record at a sampling rate other than the DAT rate may -# be problematic (i.e. trying to record at 8000Hz when the DAT signal -# is 44100Hz). If you have a problem with this, set the recording -# input to analog if you need to record at a rate other than that of -# the DAT rate. -# -# -# -- Shell archive attached below, just run `sh MultiSound' to extract. -# Contains Pinnacle/Fiji utilities to convert firmware, configure -# in non-PnP mode, and select the DIGITAL1 input for the mixer. -# -# -#!/bin/sh -# This is a shell archive (produced by GNU sharutils 4.2). -# To extract the files from this archive, save it to some FILE, remove -# everything before the `!/bin/sh' line above, then type `sh FILE'. -# -# Made on 1998-12-04 10:07 EST by . -# Source directory was `/home/andrewtv/programming/pinnacle/pinnacle'. -# -# Existing files will *not* be overwritten unless `-c' is specified. -# -# This shar contains: -# length mode name -# ------ ---------- ------------------------------------------ -# 2046 -rw-rw-r-- MultiSound.d/setdigital.c -# 10235 -rw-rw-r-- MultiSound.d/pinnaclecfg.c -# 106 -rw-rw-r-- MultiSound.d/Makefile -# 141 -rw-rw-r-- MultiSound.d/conv.l -# 1472 -rw-rw-r-- MultiSound.d/msndreset.c -# -save_IFS="${IFS}" -IFS="${IFS}:" -gettext_dir=FAILED -locale_dir=FAILED -first_param="$1" -for dir in $PATH -do - if test "$gettext_dir" = FAILED && test -f $dir/gettext \ - && ($dir/gettext --version >/dev/null 2>&1) - then - set `$dir/gettext --version 2>&1` - if test "$3" = GNU - then - gettext_dir=$dir - fi - fi - if test "$locale_dir" = FAILED && test -f $dir/shar \ - && ($dir/shar --print-text-domain-dir >/dev/null 2>&1) - then - locale_dir=`$dir/shar --print-text-domain-dir` - fi -done -IFS="$save_IFS" -if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED -then - echo=echo -else - TEXTDOMAINDIR=$locale_dir - export TEXTDOMAINDIR - TEXTDOMAIN=sharutils - export TEXTDOMAIN - echo="$gettext_dir/gettext -s" -fi -touch -am 1231235999 $$.touch >/dev/null 2>&1 -if test ! -f 1231235999 && test -f $$.touch; then - shar_touch=touch -else - shar_touch=: - echo - $echo 'WARNING: not restoring timestamps. Consider getting and' - $echo "installing GNU \`touch', distributed in GNU File Utilities..." - echo -fi -rm -f 1231235999 $$.touch -# -if mkdir _sh01426; then - $echo 'x -' 'creating lock directory' -else - $echo 'failed to create lock directory' - exit 1 -fi -# ============= MultiSound.d/setdigital.c ============== -if test ! -d 'MultiSound.d'; then - $echo 'x -' 'creating directory' 'MultiSound.d' - mkdir 'MultiSound.d' -fi -if test -f 'MultiSound.d/setdigital.c' && test "$first_param" != -c; then - $echo 'x -' SKIPPING 'MultiSound.d/setdigital.c' '(file already exists)' -else - $echo 'x -' extracting 'MultiSound.d/setdigital.c' '(text)' - sed 's/^X//' << 'SHAR_EOF' > 'MultiSound.d/setdigital.c' && -/********************************************************************* -X * -X * setdigital.c - sets the DIGITAL1 input for a mixer -X * -X * Copyright (C) 1998 Andrew Veliath -X * -X * This program is free software; you can redistribute it and/or modify -X * it under the terms of the GNU General Public License as published by -X * the Free Software Foundation; either version 2 of the License, or -X * (at your option) any later version. -X * -X * This program is distributed in the hope that it will be useful, -X * but WITHOUT ANY WARRANTY; without even the implied warranty of -X * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -X * GNU General Public License for more details. -X * -X * You should have received a copy of the GNU General Public License -X * along with this program; if not, write to the Free Software -X * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -X * -X ********************************************************************/ -X -#include -#include -#include -#include -#include -#include -#include -X -int main(int argc, char *argv[]) -{ -X int fd; -X unsigned long recmask, recsrc; -X -X if (argc != 2) { -X fprintf(stderr, "usage: setdigital \n"); -X exit(1); -X } -X -X if ((fd = open(argv[1], O_RDWR)) < 0) { -X perror(argv[1]); -X exit(1); -X } -X -X if (ioctl(fd, SOUND_MIXER_READ_RECMASK, &recmask) < 0) { -X fprintf(stderr, "error: ioctl read recording mask failed\n"); -X perror("ioctl"); -X close(fd); -X exit(1); -X } -X -X if (!(recmask & SOUND_MASK_DIGITAL1)) { -X fprintf(stderr, "error: cannot find DIGITAL1 device in mixer\n"); -X close(fd); -X exit(1); -X } -X -X if (ioctl(fd, SOUND_MIXER_READ_RECSRC, &recsrc) < 0) { -X fprintf(stderr, "error: ioctl read recording source failed\n"); -X perror("ioctl"); -X close(fd); -X exit(1); -X } -X -X recsrc |= SOUND_MASK_DIGITAL1; -X -X if (ioctl(fd, SOUND_MIXER_WRITE_RECSRC, &recsrc) < 0) { -X fprintf(stderr, "error: ioctl write recording source failed\n"); -X perror("ioctl"); -X close(fd); -X exit(1); -X } -X -X close(fd); -X -X return 0; -} -SHAR_EOF - $shar_touch -am 1204092598 'MultiSound.d/setdigital.c' && - chmod 0664 'MultiSound.d/setdigital.c' || - $echo 'restore of' 'MultiSound.d/setdigital.c' 'failed' - if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \ - && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then - md5sum -c << SHAR_EOF >/dev/null 2>&1 \ - || $echo 'MultiSound.d/setdigital.c:' 'MD5 check failed' -e87217fc3e71288102ba41fd81f71ec4 MultiSound.d/setdigital.c -SHAR_EOF - else - shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'MultiSound.d/setdigital.c'`" - test 2046 -eq "$shar_count" || - $echo 'MultiSound.d/setdigital.c:' 'original size' '2046,' 'current size' "$shar_count!" - fi -fi -# ============= MultiSound.d/pinnaclecfg.c ============== -if test -f 'MultiSound.d/pinnaclecfg.c' && test "$first_param" != -c; then - $echo 'x -' SKIPPING 'MultiSound.d/pinnaclecfg.c' '(file already exists)' -else - $echo 'x -' extracting 'MultiSound.d/pinnaclecfg.c' '(text)' - sed 's/^X//' << 'SHAR_EOF' > 'MultiSound.d/pinnaclecfg.c' && -/********************************************************************* -X * -X * pinnaclecfg.c - Pinnacle/Fiji Device Configuration Program -X * -X * This is for NON-PnP mode only. For PnP mode, use isapnptools. -X * -X * This is Linux-specific, and must be run with root permissions. -X * -X * Part of the Turtle Beach MultiSound Sound Card Driver for Linux -X * -X * Copyright (C) 1998 Andrew Veliath -X * -X * This program is free software; you can redistribute it and/or modify -X * it under the terms of the GNU General Public License as published by -X * the Free Software Foundation; either version 2 of the License, or -X * (at your option) any later version. -X * -X * This program is distributed in the hope that it will be useful, -X * but WITHOUT ANY WARRANTY; without even the implied warranty of -X * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -X * GNU General Public License for more details. -X * -X * You should have received a copy of the GNU General Public License -X * along with this program; if not, write to the Free Software -X * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -X * -X ********************************************************************/ -X -#include -#include -#include -#include -#include -#include -#include -X -#define IREG_LOGDEVICE 0x07 -#define IREG_ACTIVATE 0x30 -#define LD_ACTIVATE 0x01 -#define LD_DISACTIVATE 0x00 -#define IREG_EECONTROL 0x3F -#define IREG_MEMBASEHI 0x40 -#define IREG_MEMBASELO 0x41 -#define IREG_MEMCONTROL 0x42 -#define IREG_MEMRANGEHI 0x43 -#define IREG_MEMRANGELO 0x44 -#define MEMTYPE_8BIT 0x00 -#define MEMTYPE_16BIT 0x02 -#define MEMTYPE_RANGE 0x00 -#define MEMTYPE_HIADDR 0x01 -#define IREG_IO0_BASEHI 0x60 -#define IREG_IO0_BASELO 0x61 -#define IREG_IO1_BASEHI 0x62 -#define IREG_IO1_BASELO 0x63 -#define IREG_IRQ_NUMBER 0x70 -#define IREG_IRQ_TYPE 0x71 -#define IRQTYPE_HIGH 0x02 -#define IRQTYPE_LOW 0x00 -#define IRQTYPE_LEVEL 0x01 -#define IRQTYPE_EDGE 0x00 -X -#define HIBYTE(w) ((BYTE)(((WORD)(w) >> 8) & 0xFF)) -#define LOBYTE(w) ((BYTE)(w)) -#define MAKEWORD(low,hi) ((WORD)(((BYTE)(low))|(((WORD)((BYTE)(hi)))<<8))) -X -typedef __u8 BYTE; -typedef __u16 USHORT; -typedef __u16 WORD; -X -static int config_port = -1; -X -static int msnd_write_cfg(int cfg, int reg, int value) -{ -X outb(reg, cfg); -X outb(value, cfg + 1); -X if (value != inb(cfg + 1)) { -X fprintf(stderr, "error: msnd_write_cfg: I/O error\n"); -X return -EIO; -X } -X return 0; -} -X -static int msnd_read_cfg(int cfg, int reg) -{ -X outb(reg, cfg); -X return inb(cfg + 1); -} -X -static int msnd_write_cfg_io0(int cfg, int num, WORD io) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X if (msnd_write_cfg(cfg, IREG_IO0_BASEHI, HIBYTE(io))) -X return -EIO; -X if (msnd_write_cfg(cfg, IREG_IO0_BASELO, LOBYTE(io))) -X return -EIO; -X return 0; -} -X -static int msnd_read_cfg_io0(int cfg, int num, WORD *io) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X -X *io = MAKEWORD(msnd_read_cfg(cfg, IREG_IO0_BASELO), -X msnd_read_cfg(cfg, IREG_IO0_BASEHI)); -X -X return 0; -} -X -static int msnd_write_cfg_io1(int cfg, int num, WORD io) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X if (msnd_write_cfg(cfg, IREG_IO1_BASEHI, HIBYTE(io))) -X return -EIO; -X if (msnd_write_cfg(cfg, IREG_IO1_BASELO, LOBYTE(io))) -X return -EIO; -X return 0; -} -X -static int msnd_read_cfg_io1(int cfg, int num, WORD *io) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X -X *io = MAKEWORD(msnd_read_cfg(cfg, IREG_IO1_BASELO), -X msnd_read_cfg(cfg, IREG_IO1_BASEHI)); -X -X return 0; -} -X -static int msnd_write_cfg_irq(int cfg, int num, WORD irq) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X if (msnd_write_cfg(cfg, IREG_IRQ_NUMBER, LOBYTE(irq))) -X return -EIO; -X if (msnd_write_cfg(cfg, IREG_IRQ_TYPE, IRQTYPE_EDGE)) -X return -EIO; -X return 0; -} -X -static int msnd_read_cfg_irq(int cfg, int num, WORD *irq) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X -X *irq = msnd_read_cfg(cfg, IREG_IRQ_NUMBER); -X -X return 0; -} -X -static int msnd_write_cfg_mem(int cfg, int num, int mem) -{ -X WORD wmem; -X -X mem >>= 8; -X mem &= 0xfff; -X wmem = (WORD)mem; -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X if (msnd_write_cfg(cfg, IREG_MEMBASEHI, HIBYTE(wmem))) -X return -EIO; -X if (msnd_write_cfg(cfg, IREG_MEMBASELO, LOBYTE(wmem))) -X return -EIO; -X if (wmem && msnd_write_cfg(cfg, IREG_MEMCONTROL, (MEMTYPE_HIADDR | MEMTYPE_16BIT))) -X return -EIO; -X return 0; -} -X -static int msnd_read_cfg_mem(int cfg, int num, int *mem) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X -X *mem = MAKEWORD(msnd_read_cfg(cfg, IREG_MEMBASELO), -X msnd_read_cfg(cfg, IREG_MEMBASEHI)); -X *mem <<= 8; -X -X return 0; -} -X -static int msnd_activate_logical(int cfg, int num) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X if (msnd_write_cfg(cfg, IREG_ACTIVATE, LD_ACTIVATE)) -X return -EIO; -X return 0; -} -X -static int msnd_write_cfg_logical(int cfg, int num, WORD io0, WORD io1, WORD irq, int mem) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X if (msnd_write_cfg_io0(cfg, num, io0)) -X return -EIO; -X if (msnd_write_cfg_io1(cfg, num, io1)) -X return -EIO; -X if (msnd_write_cfg_irq(cfg, num, irq)) -X return -EIO; -X if (msnd_write_cfg_mem(cfg, num, mem)) -X return -EIO; -X if (msnd_activate_logical(cfg, num)) -X return -EIO; -X return 0; -} -X -static int msnd_read_cfg_logical(int cfg, int num, WORD *io0, WORD *io1, WORD *irq, int *mem) -{ -X if (msnd_write_cfg(cfg, IREG_LOGDEVICE, num)) -X return -EIO; -X if (msnd_read_cfg_io0(cfg, num, io0)) -X return -EIO; -X if (msnd_read_cfg_io1(cfg, num, io1)) -X return -EIO; -X if (msnd_read_cfg_irq(cfg, num, irq)) -X return -EIO; -X if (msnd_read_cfg_mem(cfg, num, mem)) -X return -EIO; -X return 0; -} -X -static void usage(void) -{ -X fprintf(stderr, -X "\n" -X "pinnaclecfg 1.0\n" -X "\n" -X "usage: pinnaclecfg [device config]\n" -X "\n" -X "This is for use with the card in NON-PnP mode only.\n" -X "\n" -X "Available devices (not all available for Fiji):\n" -X "\n" -X " Device Description\n" -X " -------------------------------------------------------------------\n" -X " reset Reset all devices (i.e. disable)\n" -X " show Display current device configurations\n" -X "\n" -X " dsp Audio device\n" -X " mpu Internal Kurzweil synth\n" -X " ide On-board IDE controller\n" -X " joystick Joystick port\n" -X "\n"); -X exit(1); -} -X -static int cfg_reset(void) -{ -X int i; -X -X for (i = 0; i < 4; ++i) -X msnd_write_cfg_logical(config_port, i, 0, 0, 0, 0); -X -X return 0; -} -X -static int cfg_show(void) -{ -X int i; -X int count = 0; -X -X for (i = 0; i < 4; ++i) { -X WORD io0, io1, irq; -X int mem; -X msnd_read_cfg_logical(config_port, i, &io0, &io1, &irq, &mem); -X switch (i) { -X case 0: -X if (io0 || irq || mem) { -X printf("dsp 0x%x %d 0x%x\n", io0, irq, mem); -X ++count; -X } -X break; -X case 1: -X if (io0 || irq) { -X printf("mpu 0x%x %d\n", io0, irq); -X ++count; -X } -X break; -X case 2: -X if (io0 || io1 || irq) { -X printf("ide 0x%x 0x%x %d\n", io0, io1, irq); -X ++count; -X } -X break; -X case 3: -X if (io0) { -X printf("joystick 0x%x\n", io0); -X ++count; -X } -X break; -X } -X } -X -X if (count == 0) -X fprintf(stderr, "no devices configured\n"); -X -X return 0; -} -X -static int cfg_dsp(int argc, char *argv[]) -{ -X int io, irq, mem; -X -X if (argc < 3 || -X sscanf(argv[0], "0x%x", &io) != 1 || -X sscanf(argv[1], "%d", &irq) != 1 || -X sscanf(argv[2], "0x%x", &mem) != 1) -X usage(); -X -X if (!(io == 0x290 || -X io == 0x260 || -X io == 0x250 || -X io == 0x240 || -X io == 0x230 || -X io == 0x220 || -X io == 0x210 || -X io == 0x3e0)) { -X fprintf(stderr, "error: io must be one of " -X "210, 220, 230, 240, 250, 260, 290, or 3E0\n"); -X usage(); -X } -X -X if (!(irq == 5 || -X irq == 7 || -X irq == 9 || -X irq == 10 || -X irq == 11 || -X irq == 12)) { -X fprintf(stderr, "error: irq must be one of " -X "5, 7, 9, 10, 11 or 12\n"); -X usage(); -X } -X -X if (!(mem == 0xb0000 || -X mem == 0xc8000 || -X mem == 0xd0000 || -X mem == 0xd8000 || -X mem == 0xe0000 || -X mem == 0xe8000)) { -X fprintf(stderr, "error: mem must be one of " -X "0xb0000, 0xc8000, 0xd0000, 0xd8000, 0xe0000 or 0xe8000\n"); -X usage(); -X } -X -X return msnd_write_cfg_logical(config_port, 0, io, 0, irq, mem); -} -X -static int cfg_mpu(int argc, char *argv[]) -{ -X int io, irq; -X -X if (argc < 2 || -X sscanf(argv[0], "0x%x", &io) != 1 || -X sscanf(argv[1], "%d", &irq) != 1) -X usage(); -X -X return msnd_write_cfg_logical(config_port, 1, io, 0, irq, 0); -} -X -static int cfg_ide(int argc, char *argv[]) -{ -X int io0, io1, irq; -X -X if (argc < 3 || -X sscanf(argv[0], "0x%x", &io0) != 1 || -X sscanf(argv[0], "0x%x", &io1) != 1 || -X sscanf(argv[1], "%d", &irq) != 1) -X usage(); -X -X return msnd_write_cfg_logical(config_port, 2, io0, io1, irq, 0); -} -X -static int cfg_joystick(int argc, char *argv[]) -{ -X int io; -X -X if (argc < 1 || -X sscanf(argv[0], "0x%x", &io) != 1) -X usage(); -X -X return msnd_write_cfg_logical(config_port, 3, io, 0, 0, 0); -} -X -int main(int argc, char *argv[]) -{ -X char *device; -X int rv = 0; -X -X --argc; ++argv; -X -X if (argc < 2) -X usage(); -X -X sscanf(argv[0], "0x%x", &config_port); -X if (config_port != 0x250 && config_port != 0x260 && config_port != 0x270) { -X fprintf(stderr, "error: must be 0x250, 0x260 or 0x270\n"); -X exit(1); -X } -X if (ioperm(config_port, 2, 1)) { -X perror("ioperm"); -X fprintf(stderr, "note: pinnaclecfg must be run as root\n"); -X exit(1); -X } -X device = argv[1]; -X -X argc -= 2; argv += 2; -X -X if (strcmp(device, "reset") == 0) -X rv = cfg_reset(); -X else if (strcmp(device, "show") == 0) -X rv = cfg_show(); -X else if (strcmp(device, "dsp") == 0) -X rv = cfg_dsp(argc, argv); -X else if (strcmp(device, "mpu") == 0) -X rv = cfg_mpu(argc, argv); -X else if (strcmp(device, "ide") == 0) -X rv = cfg_ide(argc, argv); -X else if (strcmp(device, "joystick") == 0) -X rv = cfg_joystick(argc, argv); -X else { -X fprintf(stderr, "error: unknown device %s\n", device); -X usage(); -X } -X -X if (rv) -X fprintf(stderr, "error: device configuration failed\n"); -X -X return 0; -} -SHAR_EOF - $shar_touch -am 1204092598 'MultiSound.d/pinnaclecfg.c' && - chmod 0664 'MultiSound.d/pinnaclecfg.c' || - $echo 'restore of' 'MultiSound.d/pinnaclecfg.c' 'failed' - if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \ - && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then - md5sum -c << SHAR_EOF >/dev/null 2>&1 \ - || $echo 'MultiSound.d/pinnaclecfg.c:' 'MD5 check failed' -366bdf27f0db767a3c7921d0a6db20fe MultiSound.d/pinnaclecfg.c -SHAR_EOF - else - shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'MultiSound.d/pinnaclecfg.c'`" - test 10235 -eq "$shar_count" || - $echo 'MultiSound.d/pinnaclecfg.c:' 'original size' '10235,' 'current size' "$shar_count!" - fi -fi -# ============= MultiSound.d/Makefile ============== -if test -f 'MultiSound.d/Makefile' && test "$first_param" != -c; then - $echo 'x -' SKIPPING 'MultiSound.d/Makefile' '(file already exists)' -else - $echo 'x -' extracting 'MultiSound.d/Makefile' '(text)' - sed 's/^X//' << 'SHAR_EOF' > 'MultiSound.d/Makefile' && -CC = gcc -CFLAGS = -O -PROGS = setdigital msndreset pinnaclecfg conv -X -all: $(PROGS) -X -clean: -X rm -f $(PROGS) -SHAR_EOF - $shar_touch -am 1204092398 'MultiSound.d/Makefile' && - chmod 0664 'MultiSound.d/Makefile' || - $echo 'restore of' 'MultiSound.d/Makefile' 'failed' - if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \ - && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then - md5sum -c << SHAR_EOF >/dev/null 2>&1 \ - || $echo 'MultiSound.d/Makefile:' 'MD5 check failed' -76ca8bb44e3882edcf79c97df6c81845 MultiSound.d/Makefile -SHAR_EOF - else - shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'MultiSound.d/Makefile'`" - test 106 -eq "$shar_count" || - $echo 'MultiSound.d/Makefile:' 'original size' '106,' 'current size' "$shar_count!" - fi -fi -# ============= MultiSound.d/conv.l ============== -if test -f 'MultiSound.d/conv.l' && test "$first_param" != -c; then - $echo 'x -' SKIPPING 'MultiSound.d/conv.l' '(file already exists)' -else - $echo 'x -' extracting 'MultiSound.d/conv.l' '(text)' - sed 's/^X//' << 'SHAR_EOF' > 'MultiSound.d/conv.l' && -%% -[ \n\t,\r] -\;.* -DB -[0-9A-Fa-f]+H { int n; sscanf(yytext, "%xH", &n); printf("%c", n); } -%% -int yywrap() { return 1; } -main() { yylex(); } -SHAR_EOF - $shar_touch -am 0828231798 'MultiSound.d/conv.l' && - chmod 0664 'MultiSound.d/conv.l' || - $echo 'restore of' 'MultiSound.d/conv.l' 'failed' - if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \ - && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then - md5sum -c << SHAR_EOF >/dev/null 2>&1 \ - || $echo 'MultiSound.d/conv.l:' 'MD5 check failed' -d2411fc32cd71a00dcdc1f009e858dd2 MultiSound.d/conv.l -SHAR_EOF - else - shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'MultiSound.d/conv.l'`" - test 141 -eq "$shar_count" || - $echo 'MultiSound.d/conv.l:' 'original size' '141,' 'current size' "$shar_count!" - fi -fi -# ============= MultiSound.d/msndreset.c ============== -if test -f 'MultiSound.d/msndreset.c' && test "$first_param" != -c; then - $echo 'x -' SKIPPING 'MultiSound.d/msndreset.c' '(file already exists)' -else - $echo 'x -' extracting 'MultiSound.d/msndreset.c' '(text)' - sed 's/^X//' << 'SHAR_EOF' > 'MultiSound.d/msndreset.c' && -/********************************************************************* -X * -X * msndreset.c - resets the MultiSound card -X * -X * Copyright (C) 1998 Andrew Veliath -X * -X * This program is free software; you can redistribute it and/or modify -X * it under the terms of the GNU General Public License as published by -X * the Free Software Foundation; either version 2 of the License, or -X * (at your option) any later version. -X * -X * This program is distributed in the hope that it will be useful, -X * but WITHOUT ANY WARRANTY; without even the implied warranty of -X * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -X * GNU General Public License for more details. -X * -X * You should have received a copy of the GNU General Public License -X * along with this program; if not, write to the Free Software -X * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -X * -X ********************************************************************/ -X -#include -#include -#include -#include -#include -#include -#include -X -int main(int argc, char *argv[]) -{ -X int fd; -X -X if (argc != 2) { -X fprintf(stderr, "usage: msndreset \n"); -X exit(1); -X } -X -X if ((fd = open(argv[1], O_RDWR)) < 0) { -X perror(argv[1]); -X exit(1); -X } -X -X if (ioctl(fd, SOUND_MIXER_PRIVATE1, 0) < 0) { -X fprintf(stderr, "error: msnd ioctl reset failed\n"); -X perror("ioctl"); -X close(fd); -X exit(1); -X } -X -X close(fd); -X -X return 0; -} -SHAR_EOF - $shar_touch -am 1204100698 'MultiSound.d/msndreset.c' && - chmod 0664 'MultiSound.d/msndreset.c' || - $echo 'restore of' 'MultiSound.d/msndreset.c' 'failed' - if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \ - && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then - md5sum -c << SHAR_EOF >/dev/null 2>&1 \ - || $echo 'MultiSound.d/msndreset.c:' 'MD5 check failed' -c52f876521084e8eb25e12e01dcccb8a MultiSound.d/msndreset.c -SHAR_EOF - else - shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'MultiSound.d/msndreset.c'`" - test 1472 -eq "$shar_count" || - $echo 'MultiSound.d/msndreset.c:' 'original size' '1472,' 'current size' "$shar_count!" - fi -fi -rm -fr _sh01426 -exit 0 diff --git a/Documentation/sound/oss/OPL3 b/Documentation/sound/oss/OPL3 deleted file mode 100644 index 2468ff827688..000000000000 --- a/Documentation/sound/oss/OPL3 +++ /dev/null @@ -1,6 +0,0 @@ -A pure OPL3 card is nice and easy to configure. Simply do - -insmod opl3 io=0x388 - -Change the I/O address in the very unlikely case this card is differently -configured diff --git a/Documentation/sound/oss/Opti b/Documentation/sound/oss/Opti deleted file mode 100644 index 4cd5d9ab3580..000000000000 --- a/Documentation/sound/oss/Opti +++ /dev/null @@ -1,218 +0,0 @@ -Support for the OPTi 82C931 chip --------------------------------- -Note: parts of this README file apply also to other -cards that use the mad16 driver. - -Some items in this README file are based on features -added to the sound driver after Linux-2.1.91 was out. -By the time of writing this I do not know which official -kernel release will include these features. -Please do not report inconsistencies on older Linux -kernels. - -The OPTi 82C931 is supported in its non-PnP mode. -Usually you do not need to set jumpers, etc. The sound driver -will check the card status and if it is required it will -force the card into a mode in which it can be programmed. - -If you have another OS installed on your computer it is recommended -that Linux and the other OS use the same resources. - -Also, it is recommended that resources specified in /etc/modprobe.d/*.conf -and resources specified in /etc/isapnp.conf agree. - -Compiling the sound driver --------------------------- -I highly recommend that you build a modularized sound driver. -This document does not cover a sound-driver which is built in -the kernel. - -Sound card support should be enabled as a module (chose m). -Answer 'm' for these items: - Generic OPL2/OPL3 FM synthesizer support (CONFIG_SOUND_ADLIB) - Microsoft Sound System support (CONFIG_SOUND_MSS) - Support for OPTi MAD16 and/or Mozart based cards (CONFIG_SOUND_MAD16) - FM synthesizer (YM3812/OPL-3) support (CONFIG_SOUND_YM3812) - -The configuration menu may ask for addresses, IRQ lines or DMA -channels. If the card is used as a module the module loading -options will override these values. - -For the OPTi 931 you can answer 'n' to: - Support MIDI in older MAD16 based cards (requires SB) (CONFIG_SOUND_MAD16_OLDCARD) -If you do need MIDI support in a Mozart or C928 based card you -need to answer 'm' to the above question. In that case you will -also need to answer 'm' to: - '100% Sound Blaster compatibles (SB16/32/64, ESS, Jazz16) support' (CONFIG_SOUND_SB) - -Go on and compile your kernel and modules. Install the modules. Run depmod -a. - -Using isapnptools ------------------ -In most systems with a PnP BIOS you do not need to use isapnp. The -initialization provided by the BIOS is sufficient for the driver -to pick up the card and continue initialization. - -If that fails, or if you have other PnP cards, you need to use isapnp -to initialize the card. -This was tested with isapnptools-1.11 but I recommend that you use -isapnptools-1.13 (or newer). Run pnpdump to dump the information -about your PnP cards. Then edit the resulting file and select -the options of your choice. This file is normally installed as -/etc/isapnp.conf. - -The driver has one limitation with respect to I/O port resources: -IO3 base must be 0x0E0C. Although isapnp allows other ports, this -address is hard-coded into the driver. - -Using kmod and autoloading the sound driver -------------------------------------------- -Config files in '/etc/modprobe.d/' are used as below: - -alias mixer0 mad16 -alias audio0 mad16 -alias midi0 mad16 -alias synth0 opl3 -options sb mad16=1 -options mad16 irq=10 dma=0 dma16=1 io=0x530 joystick=1 cdtype=0 -options opl3 io=0x388 -install mad16 /sbin/modprobe -i mad16 && /sbin/ad1848_mixer_reroute 14 8 15 3 16 6 - -If you have an MPU daughtercard or onboard MPU you will want to add to the -"options mad16" line - eg - -options mad16 irq=5 dma=0 dma16=3 io=0x530 mpu_io=0x330 mpu_irq=9 - -To set the I/O and IRQ of the MPU. - - -Explain: - -alias mixer0 mad16 -alias audio0 mad16 -alias midi0 mad16 -alias synth0 opl3 - -When any sound device is opened the kernel requests auto-loading -of char-major-14. There is a built-in alias that translates this -request to loading the main sound module. - -The sound module in its turn will request loading of a sub-driver -for mixer, audio, midi or synthesizer device. The first 3 are -supported by the mad16 driver. The synth device is supported -by the opl3 driver. - -There is currently no way to autoload the sound device driver -if more than one card is installed. - -options sb mad16=1 - -This is left for historical reasons. If you enable the -config option 'Support MIDI in older MAD16 based cards (requires SB)' -or if you use an older mad16 driver it will force loading of the -SoundBlaster driver. This option tells the SB driver not to look -for a SB card but to wait for the mad16 driver. - -options mad16 irq=10 dma=0 dma16=1 io=0x530 joystick=1 cdtype=0 -options opl3 io=0x388 - -post-install mad16 /sbin/ad1848_mixer_reroute 14 8 15 3 16 6 - -This sets resources and options for the mad16 and opl3 drivers. -I use two DMA channels (only one is required) to enable full duplex. -joystick=1 enables the joystick port. cdtype=0 disables the cd port. -You can also set mpu_io and mpu_irq in the mad16 options for the -uart401 driver. - -This tells modprobe to run /sbin/ad1848_mixer_reroute after -mad16 is successfully loaded and initialized. The source -for ad1848_mixer_reroute is appended to the end of this readme -file. It is impossible for the sound driver to know the actual -connections to the mixer. The 3 inputs intended for cd, synth -and line-in are mapped to the generic inputs line1, line2 and -line3. This program reroutes these mixer channels to their -right names (note the right mapping depends on the actual sound -card that you use). -The numeric parameters mean: - 14=line1 8=cd - reroute line1 to the CD input. - 15=line2 3=synth - reroute line2 to the synthesizer input. - 16=line3 6=line - reroute line3 to the line input. -For reference on other input names look at the file -/usr/include/linux/soundcard.h. - -Using a joystick ------------------ -You must enable a joystick in the mad16 options. (also -in /etc/isapnp.conf if you use it). -Tested with regular analog joysticks. - -A CDROM drive connected to the sound card ------------------------------------------ -The 82C931 chip has support only for secondary ATAPI cdrom. -(cdtype=8). Loading the mad16 driver resets the C931 chip -and if a cdrom was already mounted it may cause a complete -system hang. Do not use the sound card if you have an alternative. -If you do use the sound card it is important that you load -the mad16 driver (use "modprobe mad16" to prevent auto-unloading) -before the cdrom is accessed the first time. - -Using the sound driver built-in to the kernel may help here, but... -Most new systems have a PnP BIOS and also two IDE controllers. -The IDE controller on the sound card may be needed only on older -systems (which have only one IDE controller) but these systems -also do not have a PnP BIOS - requiring isapnptools and a modularized -driver. - -Known problems --------------- -1. See the section on "A CDROM drive connected to the sound card". - -2. On my system the codec cannot capture companded sound samples. - (eg., recording from /dev/audio). When any companded capture is - requested I get stereo-16 bit samples instead. Playback of - companded samples works well. Apparently this problem is not common - to all C931 based cards. I do not know how to identify cards that - have this problem. - -Source for ad1848_mixer_reroute.c ---------------------------------- -#include -#include -#include - -static char *mixer_names[SOUND_MIXER_NRDEVICES] = - SOUND_DEVICE_LABELS; - -int -main(int argc, char **argv) { - int val, from, to; - int i, fd; - - fd = open("/dev/mixer", O_RDWR); - if(fd < 0) { - perror("/dev/mixer"); - return 1; - } - - for(i = 2; i < argc; i += 2) { - from = atoi(argv[i-1]); - to = atoi(argv[i]); - - if(to == SOUND_MIXER_NONE) - fprintf(stderr, "%s: turning off mixer %s\n", - argv[0], mixer_names[to]); - else - fprintf(stderr, "%s: rerouting mixer %s to %s\n", - argv[0], mixer_names[from], mixer_names[to]); - - val = from << 8 | to; - - if(ioctl(fd, SOUND_MIXER_PRIVATE2, &val)) { - perror("AD1848 mixer reroute"); - return 1; - } - } - - return 0; -} - diff --git a/Documentation/sound/oss/PAS16 b/Documentation/sound/oss/PAS16 deleted file mode 100644 index 5c27229eec8c..000000000000 --- a/Documentation/sound/oss/PAS16 +++ /dev/null @@ -1,162 +0,0 @@ -Pro Audio Spectrum 16 for 2.3.99 and later -========================================= -by Thomas Molina (tmolina@home.com) -last modified 3 Mar 2001 -Acknowledgement to Axel Boldt (boldt@math.ucsb.edu) for stuff taken -from Configure.help, Riccardo Facchetti for stuff from README.OSS, -and others whose names I could not find. - -This documentation is relevant for the PAS16 driver (pas2_card.c and -friends) under kernel version 2.3.99 and later. If you are -unfamiliar with configuring sound under Linux, please read the -Sound-HOWTO, Documentation/sound/oss/Introduction and other -relevant docs first. - -The following information is relevant information from README.OSS -and legacy docs for the Pro Audio Spectrum 16 (PAS16): -================================================================== - -The pas2_card.c driver supports the following cards -- -Pro Audio Spectrum 16 (PAS16) and compatibles: - Pro Audio Spectrum 16 - Pro Audio Studio 16 - Logitech Sound Man 16 - NOTE! The original Pro Audio Spectrum as well as the PAS+ are not - and will not be supported by the driver. - -The sound driver configuration dialog -------------------------------------- - -Sound configuration starts by making some yes/no questions. Be careful -when answering to these questions since answering y to a question may -prevent some later ones from being asked. For example don't answer y to -the question about (PAS16) if you don't really have a PAS16. Sound -configuration may also be made modular by answering m to configuration -options presented. - -Note also that all questions may not be asked. The configuration program -may disable some questions depending on the earlier choices. It may also -select some options automatically as well. - - "ProAudioSpectrum 16 support", - - Answer 'y'_ONLY_ if you have a Pro Audio Spectrum _16_, - Pro Audio Studio 16 or Logitech SoundMan 16 (be sure that - you read the above list correctly). Don't answer 'y' if you - have some other card made by Media Vision or Logitech since they - are not PAS16 compatible. - NOTE! Since 3.5-beta10 you need to enable SB support (next question) - if you want to use the SB emulation of PAS16. It's also possible to - the emulation if you want to use a true SB card together with PAS16 - (there is another question about this that is asked later). - - "Generic OPL2/OPL3 FM synthesizer support", - - Answer 'y' if your card has a FM chip made by Yamaha (OPL2/OPL3/OPL4). - The PAS16 has an OPL3-compatible FM chip. - -With PAS16 you can use two audio device files at the same time. /dev/dsp (and -/dev/audio) is connected to the 8/16 bit native codec and the /dev/dsp1 (and -/dev/audio1) is connected to the SB emulation (8 bit mono only). - - -The new stuff for 2.3.99 and later -============================================================================ -The following configuration options are relevant to configuring the PAS16: - -Sound card support -CONFIG_SOUND - If you have a sound card in your computer, i.e. if it can say more - than an occasional beep, say Y. Be sure to have all the information - about your sound card and its configuration down (I/O port, - interrupt and DMA channel), because you will be asked for it. - - You want to read the Sound-HOWTO, available from - http://www.tldp.org/docs.html#howto . General information - about the modular sound system is contained in the files - Documentation/sound/oss/Introduction. The file - Documentation/sound/oss/README.OSS contains some slightly outdated but - still useful information as well. - -OSS sound modules -CONFIG_SOUND_OSS - OSS is the Open Sound System suite of sound card drivers. They make - sound programming easier since they provide a common API. Say Y or M - here (the module will be called sound.o) if you haven't found a - driver for your sound card above, then pick your driver from the - list below. - -Persistent DMA buffers -CONFIG_SOUND_DMAP - Linux can often have problems allocating DMA buffers for ISA sound - cards on machines with more than 16MB of RAM. This is because ISA - DMA buffers must exist below the 16MB boundary and it is quite - possible that a large enough free block in this region cannot be - found after the machine has been running for a while. If you say Y - here the DMA buffers (64Kb) will be allocated at boot time and kept - until the shutdown. This option is only useful if you said Y to - "OSS sound modules", above. If you said M to "OSS sound modules" - then you can get the persistent DMA buffer functionality by passing - the command-line argument "dmabuf=1" to the sound.o module. - - Say y here for PAS16. - -ProAudioSpectrum 16 support -CONFIG_SOUND_PAS - Answer Y only if you have a Pro Audio Spectrum 16, ProAudio Studio - 16 or Logitech SoundMan 16 sound card. Don't answer Y if you have - some other card made by Media Vision or Logitech since they are not - PAS16 compatible. It is not necessary to enable the separate - Sound Blaster support; it is included in the PAS driver. - - If you compile the driver into the kernel, you have to add - "pas2=,,,,,,, - to the kernel command line. - -FM Synthesizer (YM3812/OPL-3) support -CONFIG_SOUND_YM3812 - Answer Y if your card has a FM chip made by Yamaha (OPL2/OPL3/OPL4). - Answering Y is usually a safe and recommended choice, however some - cards may have software (TSR) FM emulation. Enabling FM support with - these cards may cause trouble (I don't currently know of any such - cards, however). - Please read the file Documentation/sound/oss/OPL3 if your card has an - OPL3 chip. - If you compile the driver into the kernel, you have to add - "opl3=" to the kernel command line. - - If you compile your drivers into the kernel, you MUST configure - OPL3 support as a module for PAS16 support to work properly. - You can then get OPL3 functionality by issuing the command: - insmod opl3 - In addition, you must either add the following line to - /etc/modprobe.d/*.conf: - options opl3 io=0x388 - or else add the following line to /etc/lilo.conf: - opl3=0x388 - - -EXAMPLES -=================================================================== -To use the PAS16 in my computer I have enabled the following sound -configuration options: - -CONFIG_SOUND=y -CONFIG_SOUND_OSS=y -CONFIG_SOUND_TRACEINIT=y -CONFIG_SOUND_DMAP=y -CONFIG_SOUND_PAS=y -CONFIG_SOUND_SB=n -CONFIG_SOUND_YM3812=m - -I have also included the following append line in /etc/lilo.conf: -append="pas2=0x388,10,3,-1,0x220,5,1,-1 sb=0x220,5,1,-1 opl3=0x388" - -The io address of 0x388 is default configuration on the PAS16. The -irq of 10 and dma of 3 may not match your installation. The above -configuration enables PAS16, 8-bit Soundblaster and OPL3 -functionality. If Soundblaster functionality is not desired, the -following line would be appropriate: -append="pas2=0x388,10,3,-1,0,-1,-1,-1 opl3=0x388" - -If sound is built totally modular, the above options may be -specified in /etc/modprobe.d/*.conf for pas2, sb and opl3 -respectively. diff --git a/Documentation/sound/oss/PSS b/Documentation/sound/oss/PSS deleted file mode 100644 index 187b9525e1f6..000000000000 --- a/Documentation/sound/oss/PSS +++ /dev/null @@ -1,41 +0,0 @@ -The PSS cards and other ECHO based cards provide an onboard DSP with -downloadable programs and also has an AD1848 "Microsoft Sound System" -device. The PSS driver enables MSS and MPU401 modes of the card. SB -is not enabled since it doesn't work concurrently with MSS. - -If you build this driver as a module then the driver takes the following -parameters - -pss_io. The I/O base the PSS card is configured at (normally 0x220 - or 0x240) - -mss_io The base address of the Microsoft Sound System interface. - This is normally 0x530, but may be 0x604 or other addresses. - -mss_irq The interrupt assigned to the Microsoft Sound System - emulation. IRQ's 3,5,7,9,10,11 and 12 are available. If you - get IRQ errors be sure to check the interrupt is set to - "ISA/Legacy" in the BIOS on modern machines. - -mss_dma The DMA channel used by the Microsoft Sound System. - This can be 0, 1, or 3. DMA 0 is not available on older - machines and will cause a crash on them. - -mpu_io The MPU emulation base address. This sets the base of the - synthesizer. It is typically 0x330 but can be altered. - -mpu_irq The interrupt to use for the synthesizer. It must differ - from the IRQ used by the Microsoft Sound System port. - - -The mpu_io/mpu_irq fields are optional. If they are not specified the -synthesizer parts are not configured. - -When the module is loaded it looks for a file called -/etc/sound/pss_synth. This is the firmware file from the DOS install disks. -This fil holds a general MIDI emulation. The file expected is called -genmidi.ld on newer DOS driver install disks and synth.ld on older ones. - -You can also load alternative DSP algorithms into the card if you wish. One -alternative driver can be found at http://www.mpg123.de/ - diff --git a/Documentation/sound/oss/PSS-updates b/Documentation/sound/oss/PSS-updates deleted file mode 100644 index 11914a1dc7e7..000000000000 --- a/Documentation/sound/oss/PSS-updates +++ /dev/null @@ -1,88 +0,0 @@ - This file contains notes for users of PSS sound cards who wish to use the -newly added features of the newest version of this driver. - - The major enhancements present in this new revision of this driver is the -addition of two new module parameters that allow you to take full advantage of -all the features present on your PSS sound card. These features include the -ability to enable both the builtin CDROM and joystick ports. - -pss_enable_joystick - - This parameter is basically a flag. A 0 will leave the joystick port -disabled, while a non-zero value would enable the joystick port. The default -setting is pss_enable_joystick=0 as this keeps this driver fully compatible -with systems that were using previous versions of this driver. If you wish to -enable the joystick port you will have to add pss_enable_joystick=1 as an -argument to the driver. To actually use the joystick port you will then have -to load the joystick driver itself. Just remember to load the joystick driver -AFTER the pss sound driver. - -pss_cdrom_port - - This parameter takes a port address as its parameter. Any available port -address can be specified to enable the CDROM port, except for 0x0 and -1 as -these values would leave the port disabled. Like the joystick port, the cdrom -port will require that an appropriate CDROM driver be loaded before you can make -use of the newly enabled CDROM port. Like the joystick port option above, -remember to load the CDROM driver AFTER the pss sound driver. While it may -differ on some PSS sound cards, all the PSS sound cards that I have seen have a -builtin Wearnes CDROM port. If this is the case with your PSS sound card you -should load aztcd with the appropriate port option that matches the port you -assigned to the CDROM port when you loaded your pss sound driver. (ex. -modprobe pss pss_cdrom_port=0x340 && modprobe aztcd aztcd=0x340) The default -setting of this parameter leaves the CDROM port disabled to maintain full -compatibility with systems using previous versions of this driver. - - Other options have also been added for the added convenience and utility -of the user. These options are only available if this driver is loaded as a -module. - -pss_no_sound - - This module parameter is a flag that can be used to tell the driver to -just configure non-sound components. 0 configures all components, a non-0 -value will only attempt to configure the CDROM and joystick ports. This -parameter can be used by a user who only wished to use the builtin joystick -and/or CDROM port(s) of his PSS sound card. If this driver is loaded with this -parameter and with the parameter below set to true then a user can safely unload -this driver with the following command "rmmod pss && rmmod ad1848 && rmmod -mpu401 && rmmod sound && rmmod soundcore" and retain the full functionality of -his CDROM and/or joystick port(s) while gaining back the memory previously used -by the sound drivers. This default setting of this parameter is 0 to retain -full behavioral compatibility with previous versions of this driver. - -pss_keep_settings - - This parameter can be used to specify whether you want the driver to reset -all emulations whenever its unloaded. This can be useful for those who are -sharing resources (io ports, IRQ's, DMA's) between different ISA cards. This -flag can also be useful in that future versions of this driver may reset all -emulations by default on the driver's unloading (as it probably should), so -specifying it now will ensure that all future versions of this driver will -continue to work as expected. The default value of this parameter is 1 to -retain full behavioral compatibility with previous versions of this driver. - -pss_firmware - - This parameter can be used to specify the file containing the firmware -code so that a user could tell the driver where that file is located instead -of having to put it in a predefined location with a predefined name. The -default setting of this parameter is "/etc/sound/pss_synth" as this was the -path and filename the hardcoded value in the previous versions of this driver. - -Examples: - -# Normal PSS sound card system, loading of drivers. -# Should be specified in an rc file (ex. Slackware uses /etc/rc.d/rc.modules). - -/sbin/modprobe pss pss_io=0x220 mpu_io=0x338 mpu_irq=9 mss_io=0x530 mss_irq=10 mss_dma=1 pss_cdrom_port=0x340 pss_enable_joystick=1 -/sbin/modprobe aztcd aztcd=0x340 -/sbin/modprobe joystick - -# System using the PSS sound card just for its CDROM and joystick ports. -# Should be specified in an rc file (ex. Slackware uses /etc/rc.d/rc.modules). - -/sbin/modprobe pss pss_io=0x220 pss_cdrom_port=0x340 pss_enable_joystick=1 pss_no_sound=1 -/sbin/rmmod pss && /sbin/rmmod ad1848 && /sbin/rmmod mpu401 && /sbin/rmmod sound && /sbin/rmmod soundcore # This line not needed, but saves memory. -/sbin/modprobe aztcd aztcd=0x340 -/sbin/modprobe joystick diff --git a/Documentation/sound/oss/README.OSS b/Documentation/sound/oss/README.OSS deleted file mode 100644 index a085ea3611a1..000000000000 --- a/Documentation/sound/oss/README.OSS +++ /dev/null @@ -1,1455 +0,0 @@ -Introduction ------------- - -This file is a collection of all the old Readme files distributed with -OSS/Lite by Hannu Savolainen. Since the new Linux sound driver is founded -on it I think these information may still be interesting for users that -have to configure their sound system. - -Be warned: Alan Cox is the current maintainer of the Linux sound driver so if -you have problems with it, please contact him or the current device-specific -driver maintainer (e.g. for aedsp16 specific problems contact me). If you have -patches, contributions or suggestions send them to Alan: I'm sure they are -welcome. - -In this document you will find a lot of references about OSS/Lite or ossfree: -they are gone forever. Keeping this in mind and with a grain of salt this -document can be still interesting and very helpful. - -[ File edited 17.01.1999 - Riccardo Facchetti ] -[ Edited miroSOUND section 19.04.2001 - Robert Siemer ] - -OSS/Free version 3.8 release notes ----------------------------------- - -Please read the SOUND-HOWTO (available from sunsite.unc.edu and other Linux FTP -sites). It gives instructions about using sound with Linux. It's bit out of -date but still very useful. Information about bug fixes and such things -is available from the web page (see above). - -Please check http://www.opensound.com/pguide for more info about programming -with OSS API. - - ==================================================== -- THIS VERSION ____REQUIRES____ Linux 2.1.57 OR LATER. - ==================================================== - -Packages "snd-util-3.8.tar.gz" and "snd-data-0.1.tar.Z" -contain useful utilities to be used with this driver. -See http://www.opensound.com/ossfree/ for -download instructions. - -If you are looking for the installation instructions, please -look forward into this document. - -Supported sound cards ---------------------- - -See below. - -Contributors ------------- - -This driver contains code by several contributors. In addition several other -persons have given useful suggestions. The following is a list of major -contributors. (I could have forgotten some names.) - - Craig Metz 1/2 of the PAS16 Mixer and PCM support - Rob Hooft Volume computation algorithm for the FM synth. - Mika Liljeberg uLaw encoding and decoding routines - Jeff Tranter Linux SOUND HOWTO document - Greg Lee Volume computation algorithm for the GUS and - lots of valuable suggestions. - Andy Warner ISC port - Jim Lowe, - Amancio Hasty Jr FreeBSD/NetBSD port - Anders Baekgaard Bug hunting and valuable suggestions. - Joerg Schubert SB16 DSP support (initial version). - Andrew Robinson Improvements to the GUS driver - Megens SA MIDI recording for SB and SB Pro (initial version). - Mikael Nordqvist Linear volume support for GUS and - nonblocking /dev/sequencer. - Ian Hartas SVR4.2 port - Markus Aroharju and - Risto Kankkunen Major contributions to the mixer support - of GUS v3.7. - Hunyue Yau Mixer support for SG NX Pro. - Marc Hoffman PSS support (initial version). - Rainer Vranken Initialization for Jazz16 (initial version). - Peter Trattler Initial version of loadable module support for Linux. - JRA Gibson 16 bit mode for Jazz16 (initial version) - Davor Jadrijevic MAD16 support (initial version) - Gregor Hoffleit Mozart support (initial version) - Riccardo Facchetti Audio Excel DSP 16 (aedsp16) support - James Hightower Spotting a tiny but important bug in CS423x support. - Denis Sablic OPTi 82C924 specific enhancements (non PnP mode) - Tim MacKenzie Full duplex support for OPTi 82C930. - - Please look at lowlevel/README for more contributors. - -There are probably many other names missing. If you have sent me some -patches and your name is not in the above list, please inform me. - -Sending your contributions or patches -------------------------------------- - -First of all it's highly recommended to contact me before sending anything -or before even starting to do any work. Tell me what you suggest to be -changed or what you have planned to do. Also ensure you are using the -very latest (development) version of OSS/Free since the change may already be -implemented there. In general it's a major waste of time to try to improve a -several months old version. Information about the latest version can be found -from http://www.opensound.com/ossfree. In general there is no point in -sending me patches relative to production kernels. - -Sponsors etc. -------------- - -The following companies have greatly helped development of this driver -in form of a free copy of their product: - -Novell, Inc. UnixWare personal edition + SDK -The Santa Cruz Operation, Inc. A SCO OpenServer + SDK -Ensoniq Corp, a SoundScape card and extensive amount of assistance -MediaTrix Peripherals Inc, a AudioTrix Pro card + SDK -Acer, Inc. a pair of AcerMagic S23 cards. - -In addition the following companies have provided me sufficient amount -of technical information at least some of their products (free or $$$): - -Advanced Gravis Computer Technology Ltd. -Media Vision Inc. -Analog Devices Inc. -Logitech Inc. -Aztech Labs Inc. -Crystal Semiconductor Corporation, -Integrated Circuit Systems Inc. -OAK Technology -OPTi -Turtle Beach -miro -Ad Lib Inc. ($$) -Music Quest Inc. ($$) -Creative Labs ($$$) - -If you have some problems -========================= - -Read the sound HOWTO (sunsite.unc.edu:/pub/Linux/docs/...?). -Also look at the home page (http://www.opensound.com/ossfree). It may -contain info about some recent bug fixes. - -It's likely that you have some problems when trying to use the sound driver -first time. Sound cards don't have standard configuration so there are no -good default configuration to use. Please try to use same I/O, DMA and IRQ -values for the sound card than with DOS. - -If you get an error message when trying to use the driver, please look -at /var/adm/messages for more verbose error message. - - -The following errors are likely with /dev/dsp and /dev/audio. - - - "No such device or address". - This error indicates that there are no suitable hardware for the - device file or the sound driver has been compiled without support for - this particular device. For example /dev/audio and /dev/dsp will not - work if "digitized voice support" was not enabled during "make config". - - - "Device or resource busy". Probably the IRQ (or DMA) channel - required by the sound card is in use by some other device/driver. - - - "I/O error". Almost certainly (99%) it's an IRQ or DMA conflict. - Look at the kernel messages in /var/adm/notice for more info. - - - "Invalid argument". The application is calling ioctl() - with impossible parameters. Check that the application is - for sound driver version 2.X or later. - -Linux installation -================== - -IMPORTANT! Read this if you are installing a separately - distributed version of this driver. - - Check that your kernel version works with this - release of the driver (see Readme). Also verify - that your current kernel version doesn't have more - recent sound driver version than this one. IT'S HIGHLY - RECOMMENDED THAT YOU USE THE SOUND DRIVER VERSION THAT - IS DISTRIBUTED WITH KERNEL SOURCES. - -- When installing separately distributed sound driver you should first - read the above notice. Then try to find proper directory where and how - to install the driver sources. You should not try to install a separately - distributed driver version if you are not able to find the proper way - yourself (in this case use the version that is distributed with kernel - sources). Remove old version of linux/drivers/sound directory before - installing new files. - -- To build the device files you need to run the enclosed shell script - (see below). You need to do this only when installing sound driver - first time or when upgrading to much recent version than the earlier - one. - -- Configure and compile Linux as normally (remember to include the - sound support during "make config"). Please refer to kernel documentation - for instructions about configuring and compiling kernel. File Readme.cards - contains card specific instructions for configuring this driver for - use with various sound cards. - -Boot time configuration (using lilo and insmod) ------------------------------------------------ - -This information has been removed. Too many users didn't believe -that it's really not necessary to use this method. Please look at -Readme of sound driver version 3.0.1 if you still want to use this method. - -Problems --------- - -Common error messages: - -- /dev/???????: No such file or directory. -Run the script at the end of this file. - -- /dev/???????: No such device. -You are not running kernel which contains the sound driver. When using -modularized sound driver this error means that the sound driver is not -loaded. - -- /dev/????: No such device or address. -Sound driver didn't detect suitable card when initializing. Please look at -Readme.cards for info about configuring the driver with your card. Also -check for possible boot (insmod) time error messages in /var/adm/messages. - -- Other messages or problems -Please check http://www.opensound.com/ossfree for more info. - -Configuring version 3.8 (for Linux) with some common sound cards -================================================================ - -This document describes configuring sound cards with the freeware version of -Open Sound Systems (OSS/Free). Information about the commercial version -(OSS/Linux) and its configuration is available from -http://www.opensound.com/linux.html. Information presented here is -not valid for OSS/Linux. - -If you are unsure about how to configure OSS/Free -you can download the free evaluation version of OSS/Linux from the above -address. There is a chance that it can autodetect your sound card. In this case -you can use the information included in soundon.log when configuring OSS/Free. - - -IMPORTANT! This document covers only cards that were "known" when - this driver version was released. Please look at - http://www.opensound.com/ossfree for info about - cards introduced recently. - - When configuring the sound driver, you should carefully - check each sound configuration option (particularly - "Support for /dev/dsp and /dev/audio"). The default values - offered by these programs are not necessarily valid. - - -THE BIGGEST MISTAKES YOU CAN MAKE -================================= - -1. Assuming that the card is Sound Blaster compatible when it's not. --------------------------------------------------------------------- - -The number one mistake is to assume that your card is compatible with -Sound Blaster. Only the cards made by Creative Technology or which have -one or more chips labeled by Creative are SB compatible. In addition there -are few sound chipsets which are SB compatible in Linux such as ESS1688 or -Jazz16. Note that SB compatibility in DOS/Windows does _NOT_ mean anything -in Linux. - -IF YOU REALLY ARE 150% SURE YOU HAVE A SOUND BLASTER YOU CAN SKIP THE REST OF -THIS CHAPTER. - -For most other "supposed to be SB compatible" cards you have to use other -than SB drivers (see below). It is possible to get most sound cards to work -in SB mode but in general it's a complete waste of time. There are several -problems which you will encounter by using SB mode with cards that are not -truly SB compatible: - -- The SB emulation is at most SB Pro (DSP version 3.x) which means that -you get only 8 bit audio (there is always an another ("native") mode which -gives the 16 bit capability). The 8 bit only operation is the reason why -many users claim that sound quality in Linux is much worse than in DOS. -In addition some applications require 16 bit mode and they produce just -noise with a 8 bit only device. -- The card may work only in some cases but refuse to work most of the -time. The SB compatible mode always requires special initialization which is -done by the DOS/Windows drivers. This kind of cards work in Linux after -you have warm booted it after DOS but they don't work after cold boot -(power on or reset). -- You get the famous "DMA timed out" messages. Usually all SB clones have -software selectable IRQ and DMA settings. If the (power on default) values -currently used by the card don't match configuration of the driver you will -get the above error message whenever you try to record or play. There are -few other reasons to the DMA timeout message but using the SB mode seems -to be the most common cause. - -2. Trying to use a PnP (Plug & Play) card just like an ordinary sound card --------------------------------------------------------------------------- - -Plug & Play is a protocol defined by Intel and Microsoft. It lets operating -systems to easily identify and reconfigure I/O ports, IRQs and DMAs of ISA -cards. The problem with PnP cards is that the standard Linux doesn't currently -(versions 2.1.x and earlier) don't support PnP. This means that you will have -to use some special tricks (see later) to get a PnP card alive. Many PnP cards -work after they have been initialized but this is not always the case. - -There are sometimes both PnP and non-PnP versions of the same sound card. -The non-PnP version is the original model which usually has been discontinued -more than an year ago. The PnP version has the same name but with "PnP" -appended to it (sometimes not). This causes major confusion since the non-PnP -model works with Linux but the PnP one doesn't. - -You should carefully check if "Plug & Play" or "PnP" is mentioned in the name -of the card or in the documentation or package that came with the card. -Everything described in the rest of this document is not necessarily valid for -PnP models of sound cards even you have managed to wake up the card properly. -Many PnP cards are simply too different from their non-PnP ancestors which are -covered by this document. - - -Cards that are not (fully) supported by this driver -=================================================== - -See http://www.opensound.com/ossfree for information about sound cards -to be supported in future. - - -How to use sound without recompiling kernel and/or sound driver -=============================================================== - -There is a commercial sound driver which comes in precompiled form and doesn't -require recompiling of the kernel. See http://www.4Front-tech.com/oss.html for -more info. - - -Configuring PnP cards -===================== - -New versions of most sound cards use the so-called ISA PnP protocol for -soft configuring their I/O, IRQ, DMA and shared memory resources. -Currently at least cards made by Creative Technology (SB32 and SB32AWE -PnP), Gravis (GUS PnP and GUS PnP Pro), Ensoniq (Soundscape PnP) and -Aztech (some Sound Galaxy models) use PnP technology. The CS4232/4236 audio -chip by Crystal Semiconductor (Intel Atlantis, HP Pavilion and many other -motherboards) is also based on PnP technology but there is a "native" driver -available for it (see information about CS4232 later in this document). - -PnP sound cards (as well as most other PnP ISA cards) are not supported -by this version of the driver . Proper -support for them should be released during 97 once the kernel level -PnP support is available. - -There is a method to get most of the PnP cards to work. The basic method -is the following: - -1) Boot DOS so the card's DOS drivers have a chance to initialize it. -2) _Cold_ boot to Linux by using "loadlin.exe". Hitting ctrl-alt-del -works with older machines but causes a hard reset of all cards on recent -(Pentium) machines. -3) If you have the sound driver in Linux configured properly, the card should -work now. "Proper" means that I/O, IRQ and DMA settings are the same as in -DOS. The hard part is to find which settings were used. See the documentation of -your card for more info. - -Windows 95 could work as well as DOS but running loadlin may be difficult. -Probably you should "shut down" your machine to MS-DOS mode before running it. - -Some machines have a BIOS utility for setting PnP resources. This is a good -way to configure some cards. In this case you don't need to boot DOS/Win95 -before starting Linux. - -Another way to initialize PnP cards without DOS/Win95 is a Linux based -PnP isolation tool. When writing this there is a pre alpha test version -of such a tool available from ftp://ftp.demon.co.uk/pub/unix/linux/utils. The -file is called isapnptools-*. Please note that this tool is just a temporary -solution which may be incompatible with future kernel versions having proper -support for PnP cards. There are bugs in setting DMA channels in earlier -versions of isapnptools so at least version 1.6 is required with sound cards. - -Yet another way to use PnP cards is to use (commercial) OSS/Linux drivers. See -http://www.opensound.com/linux.html for more info. This is probably the way you -should do it if you don't want to spend time recompiling the kernel and -required tools. - - -Read this before trying to configure the driver -=============================================== - -There are currently many cards that work with this driver. Some of the cards -have native support while others work since they emulate some other -card (usually SB, MSS/WSS and/or MPU401). The following cards have native -support in the driver. Detailed instructions for configuring these cards -will be given later in this document. - -Pro Audio Spectrum 16 (PAS16) and compatibles: - Pro Audio Spectrum 16 - Pro Audio Studio 16 - Logitech Sound Man 16 - NOTE! The original Pro Audio Spectrum as well as the PAS+ are not - and will not be supported by the driver. - -Media Vision Jazz16 based cards - Pro Sonic 16 - Logitech SoundMan Wave - (Other Jazz based cards should work but I don't have any reports - about them). - -Sound Blasters - SB 1.0 to 2.0 - SB Pro - SB 16 - SB32/64/AWE - Configure SB32/64/AWE just like SB16. See lowlevel/README.awe - for information about using the wave table synth. - NOTE! AWE63/Gold and 16/32/AWE "PnP" cards need to be activated - using isapnptools before they work with OSS/Free. - SB16 compatible cards by other manufacturers than Creative. - You have been fooled since there are _no_ SB16 compatible - cards on the market (as of May 1997). It's likely that your card - is compatible just with SB Pro but there is also a non-SB- - compatible 16 bit mode. Usually it's MSS/WSS but it could also - be a proprietary one like MV Jazz16 or ESS ES688. OPTi - MAD16 chips are very common in so called "SB 16 bit cards" - (try with the MAD16 driver). - - ====================================================================== - "Supposed to be SB compatible" cards. - Forget the SB compatibility and check for other alternatives - first. The only cards that work with the SB driver in - Linux have been made by Creative Technology (there is at least - one chip on the card with "CREATIVE" printed on it). The - only other SB compatible chips are ESS and Jazz16 chips - (maybe ALSxxx chips too but they probably don't work). - Most other "16 bit SB compatible" cards such as "OPTi/MAD16" or - "Crystal" are _NOT_ SB compatible in Linux. - - Practically all sound cards have some kind of SB emulation mode - in addition to their native (16 bit) mode. In most cases this - (8 bit only) SB compatible mode doesn't work with Linux. If - you get it working it may cause problems with games and - applications which require 16 bit audio. Some 16 bit only - applications don't check if the card actually supports 16 bits. - They just dump 16 bit data to a 8 bit card which produces just - noise. - - In most cases the 16 bit native mode is supported by Linux. - Use the SB mode with "clones" only if you don't find anything - better from the rest of this doc. - ====================================================================== - -Gravis Ultrasound (GUS) - GUS - GUS + the 16 bit option - GUS MAX - GUS ACE (No MIDI port and audio recording) - GUS PnP (with RAM) - -MPU-401 and compatibles - The driver works both with the full (intelligent mode) MPU-401 - cards (such as MPU IPC-T and MQX-32M) and with the UART only - dumb MIDI ports. MPU-401 is currently the most common MIDI - interface. Most sound cards are compatible with it. However, - don't enable MPU401 mode blindly. Many cards with native support - in the driver have their own MPU401 driver. Enabling the standard one - will cause a conflict with these cards. So check if your card is - in the list of supported cards before enabling MPU401. - -Windows Sound System (MSS/WSS) - Even when Microsoft has discontinued their own Sound System card - they managed to make it a standard. MSS compatible cards are based on - a codec chip which is easily available from at least two manufacturers - (AD1848 by Analog Devices and CS4231/CS4248 by Crystal Semiconductor). - Currently most sound cards are based on one of the MSS compatible codec - chips. The CS4231 is used in the high quality cards such as GUS MAX, - MediaTrix AudioTrix Pro and TB Tropez (GUS MAX is not MSS compatible). - - Having a AD1848, CS4248 or CS4231 codec chip on the card is a good - sign. Even if the card is not MSS compatible, it could be easy to write - support for it. Note also that most MSS compatible cards - require special boot time initialization which may not be present - in the driver. Also, some MSS compatible cards have native support. - Enabling the MSS support with these cards is likely to - cause a conflict. So check if your card is listed in this file before - enabling the MSS support. - -Yamaha FM synthesizers (OPL2, OPL3 (not OPL3-SA) and OPL4) - Most sound cards have a FM synthesizer chip. The OPL2 is a 2 - operator chip used in the original AdLib card. Currently it's used - only in the cheapest (8 bit mono) cards. The OPL3 is a 4 operator - FM chip which provides better sound quality and/or more available - voices than the OPL2. The OPL4 is a new chip that has an OPL3 and - a wave table synthesizer packed onto the same chip. The driver supports - just the OPL3 mode directly. Most cards with an OPL4 (like - SM Wave and AudioTrix Pro) support the OPL4 mode using MPU401 - emulation. Writing a native OPL4 support is difficult - since Yamaha doesn't give information about their sample ROM chip. - - Enable the generic OPL2/OPL3 FM synthesizer support if your - card has a FM chip made by Yamaha. Don't enable it if your card - has a software (TRS) based FM emulator. - - ---------------------------------------------------------------- - NOTE! OPL3-SA is different chip than the ordinary OPL3. In addition - to the FM synth this chip has also digital audio (WSS) and - MIDI (MPU401) capabilities. Support for OPL3-SA is described below. - ---------------------------------------------------------------- - -Yamaha OPL3-SA1 - - Yamaha OPL3-SA1 (YMF701) is an audio controller chip used on some - (Intel) motherboards and on cheap sound cards. It should not be - confused with the original OPL3 chip (YMF278) which is entirely - different chip. OPL3-SA1 has support for MSS, MPU401 and SB Pro - (not used in OSS/Free) in addition to the OPL3 FM synth. - - There are also chips called OPL3-SA2, OPL3-SA3, ..., OPL3SA-N. They - are PnP chips and will not work with the OPL3-SA1 driver. You should - use the standard MSS, MPU401 and OPL3 options with these chips and to - activate the card using isapnptools. - -4Front Technologies SoftOSS - - SoftOSS is a software based wave table emulation which works with - any 16 bit stereo sound card. Due to its nature a fast CPU is - required (P133 is minimum). Although SoftOSS does _not_ use MMX - instructions it has proven out that recent processors (which appear - to have MMX) perform significantly better with SoftOSS than earlier - ones. For example a P166MMX beats a PPro200. SoftOSS should not be used - on 486 or 386 machines. - - The amount of CPU load caused by SoftOSS can be controlled by - selecting the CONFIG_SOFTOSS_RATE and CONFIG_SOFTOSS_VOICES - parameters properly (they will be prompted by make config). It's - recommended to set CONFIG_SOFTOSS_VOICES to 32. If you have a - P166MMX or faster (PPro200 is not faster) you can set - CONFIG_SOFTOSS_RATE to 44100 (kHz). However with slower systems it - recommended to use sampling rates around 22050 or even 16000 kHz. - Selecting too high values for these parameters may hang your - system when playing MIDI files with hight degree of polyphony - (number of concurrently playing notes). It's also possible to - decrease CONFIG_SOFTOSS_VOICES. This makes it possible to use - higher sampling rates. However using fewer voices decreases - playback quality more than decreasing the sampling rate. - - SoftOSS keeps the samples loaded on the system's RAM so much RAM is - required. SoftOSS should never be used on machines with less than 16 MB - of RAM since this is potentially dangerous (you may accidentally run out - of memory which probably crashes the machine). - - SoftOSS implements the wave table API originally designed for GUS. For - this reason all applications designed for GUS should work (at least - after minor modifications). For example gmod/xgmod and playmidi -g are - known to work. - - To work SoftOSS will require GUS compatible - patch files to be installed on the system (in /dos/ultrasnd/midi). You - can use the public domain MIDIA patchset available from several ftp - sites. - - ********************************************************************* - IMPORTANT NOTICE! The original patch set distributed with the Gravis - Ultrasound card is not in public domain (even though it's available from - some FTP sites). You should contact Voice Crystal (www.voicecrystal.com) - if you like to use these patches with SoftOSS included in OSS/Free. - ********************************************************************* - -PSS based cards (AD1848 + ADSP-2115 + Echo ESC614 ASIC) - Analog Devices and Echo Speech have together defined a sound card - architecture based on the above chips. The DSP chip is used - for emulation of SB Pro, FM and General MIDI/MT32. - - There are several cards based on this architecture. The most known - ones are Orchid SW32 and Cardinal DSP16. - - The driver supports downloading DSP algorithms to these cards. - - NOTE! You will have to use the "old" config script when configuring - PSS cards. - -MediaTrix AudioTrix Pro - The ATP card is built around a CS4231 codec and an OPL4 synthesizer - chips. The OPL4 mode is supported by a microcontroller running a - General MIDI emulator. There is also a SB 1.5 compatible playback mode. - -Ensoniq SoundScape and compatibles - Ensoniq has designed a sound card architecture based on the - OTTO synthesizer chip used in their professional MIDI synthesizers. - Several companies (including Ensoniq, Reveal and Spea) are selling - cards based on this architecture. - - NOTE! The SoundScape PnP is not supported by OSS/Free. Ensoniq VIVO and - VIVO90 cards are not compatible with Soundscapes so the Soundscape - driver will not work with them. You may want to use OSS/Linux with these - cards. - -OPTi MAD16 and Mozart based cards - The Mozart (OAK OTI-601), MAD16 (OPTi 82C928), MAD16 Pro (OPTi 82C929), - OPTi 82C924/82C925 (in _non_ PnP mode) and OPTi 82C930 interface - chips are used in many different sound cards, including some - cards by Reveal miro and Turtle Beach (Tropez). The purpose of these - chips is to connect other audio components to the PC bus. The - interface chip performs address decoding for the other chips. - NOTE! Tropez Plus is not MAD16 but CS4232 based. - NOTE! MAD16 PnP cards (82C924, 82C925, 82C931) are not MAD16 compatible - in the PnP mode. You will have to use them in MSS mode after having - initialized them using isapnptools or DOS. 82C931 probably requires - initialization using DOS/Windows (running isapnptools is not enough). - It's possible to use 82C931 with OSS/Free by jumpering it to non-PnP - mode (provided that the card has a jumper for this). In non-PnP mode - 82C931 is compatible with 82C930 and should work with the MAD16 driver - (without need to use isapnptools or DOS to initialize it). All OPTi - chips are supported by OSS/Linux (both in PnP and non-PnP modes). - -Audio Excel DSP16 - Support for this card was written by Riccardo Faccetti - (riccardo@cdc8g5.cdc.polimi.it). The AEDSP16 driver included in - the lowlevel/ directory. To use it you should enable the - "Additional low level drivers" option. - -Crystal CS4232 and CS4236 based cards such as AcerMagic S23, TB Tropez _Plus_ and - many PC motherboards (Compaq, HP, Intel, ...) - CS4232 is a PnP multimedia chip which contains a CS3231A codec, - SB and MPU401 emulations. There is support for OPL3 too. - Unfortunately the MPU401 mode doesn't work (I don't know how to - initialize it). CS4236 is an enhanced (compatible) version of CS4232. - NOTE! Don't ever try to use isapnptools with CS4232 since this will just - freeze your machine (due to chip bugs). If you have problems in getting - CS4232 working you could try initializing it with DOS (CS4232C.EXE) and - then booting Linux using loadlin. CS4232C.EXE loads a secret firmware - patch which is not documented by Crystal. - -Turtle Beach Maui and Tropez "classic" - This driver version supports sample, patch and program loading commands - described in the Maui/Tropez User's manual. - There is now full initialization support too. The audio side of - the Tropez is based on the MAD16 chip (see above). - NOTE! Tropez Plus is different card than Tropez "classic" and will not - work fully in Linux. You can get audio features working by configuring - the card as a CS4232 based card (above). - - -Jumpers and software configuration -================================== - -Some of the earliest sound cards were jumper configurable. You have to -configure the driver use I/O, IRQ and DMA settings -that match the jumpers. Just few 8 bit cards are fully jumper -configurable (SB 1.x/2.x, SB Pro and clones). -Some cards made by Aztech have an EEPROM which contains the -config info. These cards behave much like hardware jumpered cards. - -Most cards have jumper for the base I/O address but other parameters -are software configurable. Sometimes there are few other jumpers too. - -Latest cards are fully software configurable or they are PnP ISA -compatible. There are no jumpers on the board. - -The driver handles software configurable cards automatically. Just configure -the driver to use I/O, IRQ and DMA settings which are known to work. -You could usually use the same values than with DOS and/or Windows. -Using different settings is possible but not recommended since it may cause -some trouble (for example when warm booting from an OS to another or -when installing new hardware to the machine). - -Sound driver sets the soft configurable parameters of the card automatically -during boot. Usually you don't need to run any extra initialization -programs when booting Linux but there are some exceptions. See the -card-specific instructions below for more info. - -The drawback of software configuration is that the driver needs to know -how the card must be initialized. It cannot initialize unknown cards -even if they are otherwise compatible with some other cards (like SB, -MPU401 or Windows Sound System). - - -What if your card was not listed above? -======================================= - -The first thing to do is to look at the major IC chips on the card. -Many of the latest sound cards are based on some standard chips. If you -are lucky, all of them could be supported by the driver. The most common ones -are the OPTi MAD16, Mozart, SoundScape (Ensoniq) and the PSS architectures -listed above. Also look at the end of this file for list of unsupported -cards and the ones which could be supported later. - -The last resort is to send _exact_ name and model information of the card -to me together with a list of the major IC chips (manufactured, model) to -me. I could then try to check if your card looks like something familiar. - -There are many more cards in the world than listed above. The first thing to -do with these cards is to check if they emulate some other card or interface -such as SB, MSS and/or MPU401. In this case there is a chance to get the -card to work by booting DOS before starting Linux (boot DOS, hit ctrl-alt-del -and boot Linux without hard resetting the machine). In this method the -DOS based driver initializes the hardware to use known I/O, IRQ and DMA -settings. If sound driver is configured to use the same settings, everything -should work OK. - - -Configuring sound driver (with Linux) -===================================== - -The sound driver is currently distributed as part of the Linux kernel. The -files are in /usr/src/linux/drivers/sound/. - -**************************************************************************** -* ALWAYS USE THE SOUND DRIVER VERSION WHICH IS DISTRIBUTED WITH * -* THE KERNEL SOURCE PACKAGE YOU ARE USING. SOME ALPHA AND BETA TEST * -* VERSIONS CAN BE INSTALLED FROM A SEPARATELY DISTRIBUTED PACKAGE * -* BUT CHECK THAT THE PACKAGE IS NOT MUCH OLDER (OR NEWER) THAN THE * -* KERNEL YOU ARE USING. IT'S POSSIBLE THAT THE KERNEL/DRIVER * -* INTERFACE CHANGES BETWEEN KERNEL RELEASES WHICH MAY CAUSE SOME * -* INCOMPATIBILITY PROBLEMS. * -* * -* IN CASE YOU INSTALL A SEPARATELY DISTRIBUTED SOUND DRIVER VERSION, * -* BE SURE TO REMOVE OR RENAME THE OLD SOUND DRIVER DIRECTORY BEFORE * -* INSTALLING THE NEW ONE. LEAVING OLD FILES TO THE SOUND DRIVER * -* DIRECTORY _WILL_ CAUSE PROBLEMS WHEN THE DRIVER IS USED OR * -* COMPILED. * -**************************************************************************** - -To configure the driver, run "make config" in the kernel source directory -(/usr/src/linux). Answer "y" or "m" to the question about Sound card support -(after the questions about mouse, CD-ROM, ftape, etc. support). Questions -about options for sound will then be asked. - -After configuring the kernel and sound driver and compile the kernel -following instructions in the kernel README. - -The sound driver configuration dialog -------------------------------------- - -Sound configuration starts by making some yes/no questions. Be careful -when answering to these questions since answering y to a question may -prevent some later ones from being asked. For example don't answer y to -the first question (PAS16) if you don't really have a PAS16. Don't enable -more cards than you really need since they just consume memory. Also -some drivers (like MPU401) may conflict with your SCSI controller and -prevent kernel from booting. If you card was in the list of supported -cards (above), please look at the card specific config instructions -(later in this file) before starting to configure. Some cards must be -configured in way which is not obvious. - -So here is the beginning of the config dialog. Answer 'y' or 'n' to these -questions. The default answer is shown so that (y/n) means 'y' by default and -(n/y) means 'n'. To use the default value, just hit ENTER. But be careful -since using the default _doesn't_ guarantee anything. - -Note also that all questions may not be asked. The configuration program -may disable some questions depending on the earlier choices. It may also -select some options automatically as well. - - "ProAudioSpectrum 16 support", - - Answer 'y'_ONLY_ if you have a Pro Audio Spectrum _16_, - Pro Audio Studio 16 or Logitech SoundMan 16 (be sure that - you read the above list correctly). Don't answer 'y' if you - have some other card made by Media Vision or Logitech since they - are not PAS16 compatible. - NOTE! Since 3.5-beta10 you need to enable SB support (next question) - if you want to use the SB emulation of PAS16. It's also possible to - the emulation if you want to use a true SB card together with PAS16 - (there is another question about this that is asked later). - "Sound Blaster support", - - Answer 'y' if you have an original SB card made by Creative Labs - or a full 100% hardware compatible clone (like Thunderboard or - SM Games). If your card was in the list of supported cards (above), - please look at the card specific instructions later in this file - before answering this question. For an unknown card you may answer - 'y' if the card claims to be SB compatible. - Enable this option also with PAS16 (changed since v3.5-beta9). - - Don't enable SB if you have a MAD16 or Mozart compatible card. - - "Generic OPL2/OPL3 FM synthesizer support", - - Answer 'y' if your card has a FM chip made by Yamaha (OPL2/OPL3/OPL4). - Answering 'y' is usually a safe and recommended choice. However some - cards may have software (TSR) FM emulation. Enabling FM support - with these cards may cause trouble. However I don't currently know - such cards. - "Gravis Ultrasound support", - - Answer 'y' if you have GUS or GUS MAX. Answer 'n' if you don't - have GUS since the GUS driver consumes much memory. - Currently I don't have experiences with the GUS ACE so I don't - know what to answer with it. - "MPU-401 support (NOT for SB16)", - - Be careful with this question. The MPU401 interface is supported - by almost any sound card today. However some natively supported cards - have their own driver for MPU401. Enabling the MPU401 option with - these cards will cause a conflict. Also enabling MPU401 on a system - that doesn't really have a MPU401 could cause some trouble. If your - card was in the list of supported cards (above), please look at - the card specific instructions later in this file. - - In MOST cases this MPU401 driver should only be used with "true" - MIDI-only MPU401 professional cards. In most other cases there - is another way to get the MPU401 compatible interface of a - sound card to work. - Support for the MPU401 compatible MIDI port of SB16, ESS1688 - and MV Jazz16 cards is included in the SB driver. Use it instead - of this separate MPU401 driver with these cards. As well - Soundscape, PSS and Maui drivers include their own MPU401 - options. - - It's safe to answer 'y' if you have a true MPU401 MIDI interface - card. - "6850 UART Midi support", - - It's safe to answer 'n' to this question in all cases. The 6850 - UART interface is so rarely used. - "PSS (ECHO-ADI2111) support", - - Answer 'y' only if you have Orchid SW32, Cardinal DSP16 or some - other card based on the PSS chipset (AD1848 codec + ADSP-2115 - DSP chip + Echo ESC614 ASIC CHIP). - "16 bit sampling option of GUS (_NOT_ GUS MAX)", - - Answer 'y' if you have installed the 16 bit sampling daughtercard - to your GUS. Answer 'n' if you have GUS MAX. Enabling this option - disables GUS MAX support. - "GUS MAX support", - - Answer 'y' only if you have a GUS MAX. - "Microsoft Sound System support", - - Again think carefully before answering 'y' to this question. It's - safe to answer 'y' in case you have the original Windows Sound - System card made by Microsoft or Aztech SG 16 Pro (or NX16 Pro). - Also you may answer 'y' in case your card was not listed earlier - in this file. For cards having native support in the driver, consult - the card specific instructions later in this file. Some drivers - have their own MSS support and enabling this option will cause a - conflict. - Note! The MSS driver permits configuring two DMA channels. This is a - "nonstandard" feature and works only with very few cards (if any). - In most cases the second DMA channel should be disabled or set to - the same channel than the first one. Trying to configure two separate - channels with cards that don't support this feature will prevent - audio (at least recording) from working. - "Ensoniq Soundscape support", - - Answer 'y' if you have a sound card based on the Ensoniq SoundScape - chipset. Such cards are being manufactured at least by Ensoniq, - Spea and Reveal (note that Reveal makes other cards also). The oldest - cards made by Spea don't work properly with Linux. - Soundscape PnP as well as Ensoniq VIVO work only with the commercial - OSS/Linux version. - "MediaTrix AudioTrix Pro support", - - Answer 'y' if you have the AudioTrix Pro. - "Support for MAD16 and/or Mozart based cards", - - Answer y if your card has a Mozart (OAK OTI-601) or MAD16 - (OPTi 82C928, 82C929, 82C924/82C925 or 82C930) audio interface chip. - These chips are - currently quite common so it's possible that many no-name cards - have one of them. In addition the MAD16 chip is used in some - cards made by known manufacturers such as Turtle Beach (Tropez), - Reveal (some models) and Diamond (some recent models). - Note OPTi 82C924 and 82C925 are MAD16 compatible only in non PnP - mode (jumper selectable on many cards). - "Support for TB Maui" - - This enables TB Maui specific initialization. Works with TB Maui - and TB Tropez (may not work with Tropez Plus). - - -Then the configuration program asks some y/n questions about the higher -level services. It's recommended to answer 'y' to each of these questions. -Answer 'n' only if you know you will not need the option. - - "MIDI interface support", - - Answering 'n' disables /dev/midi## devices and access to any - MIDI ports using /dev/sequencer and /dev/music. This option - also affects any MPU401 and/or General MIDI compatible devices. - "FM synthesizer (YM3812/OPL-3) support", - - Answer 'y' here. - "/dev/sequencer support", - - Answering 'n' disables /dev/sequencer and /dev/music. - -Entering the I/O, IRQ and DMA config parameters ------------------------------------------------ - -After the above questions the configuration program prompts for the -card specific configuration information. Usually just a set of -I/O address, IRQ and DMA numbers are asked. With some cards the program -asks for some files to be used during initialization of the card. For example -many cards have a DSP chip or microprocessor which must be initialized by -downloading a program (microcode) file to the card. - -Instructions for answering these questions are given in the next section. - - -Card specific information -========================= - -This section gives additional instructions about configuring some cards. -Please refer manual of your card for valid I/O, IRQ and DMA numbers. Using -the same settings with DOS/Windows and Linux is recommended. Using -different values could cause some problems when switching between -different operating systems. - -Sound Blasters (the original ones by Creative) ---------------------------------------------- - -NOTE! Check if you have a PnP Sound Blaster (cards sold after summer 1995 - are almost certainly PnP ones). With PnP cards you should use isapnptools - to activate them (see above). - -It's possible to configure these cards to use different I/O, IRQ and -DMA settings. Since the possible/default settings have changed between various -models, you have to consult manual of your card for the proper ones. It's -a good idea to use the same values than with DOS/Windows. With SB and SB Pro -it's the only choice. SB16 has software selectable IRQ and DMA channels but -using different values with DOS and Linux is likely to cause troubles. The -DOS driver is not able to reset the card properly after warm boot from Linux -if Linux has used different IRQ or DMA values. - -The original (steam) Sound Blaster (versions 1.x and 2.x) use always -DMA1. There is no way to change it. - -The SB16 needs two DMA channels. A 8 bit one (1 or 3) is required for -8 bit operation and a 16 bit one (5, 6 or 7) for the 16 bit mode. In theory -it's possible to use just one (8 bit) DMA channel by answering the 8 bit -one when the configuration program asks for the 16 bit one. This may work -in some systems but is likely to cause terrible noise on some other systems. - -It's possible to use two SB16/32/64 at the same time. To do this you should -first configure OSS/Free for one card. Then edit local.h manually and define -SB2_BASE, SB2_IRQ, SB2_DMA and SB2_DMA2 for the second one. You can't get -the OPL3, MIDI and EMU8000 devices of the second card to work. If you are -going to use two PnP Sound Blasters, ensure that they are of different model -and have different PnP IDs. There is no way to get two cards with the same -card ID and serial number to work. The easiest way to check this is trying -if isapnptools can see both cards or just one. - -NOTE! Don't enable the SM Games option (asked by the configuration program) - if you are not 101% sure that your card is a Logitech Soundman Games - (not a SM Wave or SM16). - -SB Clones ---------- - -First of all: There are no SB16 clones. There are SB Pro clones with a -16 bit mode which is not SB16 compatible. The most likely alternative is that -the 16 bit mode means MSS/WSS. - -There are just a few fully 100% hardware SB or SB Pro compatible cards. -I know just Thunderboard and SM Games. Other cards require some kind of -hardware initialization before they become SB compatible. Check if your card -was listed in the beginning of this file. In this case you should follow -instructions for your card later in this file. - -For other not fully SB clones you may try initialization using DOS in -the following way: - - - Boot DOS so that the card specific driver gets run. - - Hit ctrl-alt-del (or use loadlin) to boot Linux. Don't - switch off power or press the reset button. - - If you use the same I/O, IRQ and DMA settings in Linux, the - card should work. - -If your card is both SB and MSS compatible, I recommend using the MSS mode. -Most cards of this kind are not able to work in the SB and the MSS mode -simultaneously. Using the MSS mode provides 16 bit recording and playback. - -ProAudioSpectrum 16 and compatibles ------------------------------------ - -PAS16 has a SB emulation chip which can be used together with the native -(16 bit) mode of the card. To enable this emulation you should configure -the driver to have SB support too (this has been changed since version -3.5-beta9 of this driver). - -With current driver versions it's also possible to use PAS16 together with -another SB compatible card. In this case you should configure SB support -for the other card and to disable the SB emulation of PAS16 (there is a -separate questions about this). - -With PAS16 you can use two audio device files at the same time. /dev/dsp (and -/dev/audio) is connected to the 8/16 bit native codec and the /dev/dsp1 (and -/dev/audio1) is connected to the SB emulation (8 bit mono only). - -Gravis Ultrasound ------------------ - -There are many different revisions of the Ultrasound card (GUS). The -earliest ones (pre 3.7) don't have a hardware mixer. With these cards -the driver uses a software emulation for synth and pcm playbacks. It's -also possible to switch some of the inputs (line in, mic) off by setting -mixer volume of the channel level below 10%. For recording you have -to select the channel as a recording source and to use volume above 10%. - -GUS 3.7 has a hardware mixer. - -GUS MAX and the 16 bit sampling daughtercard have a CS4231 codec chip which -also contains a mixer. - -Configuring GUS is simple. Just enable the GUS support and GUS MAX or -the 16 bit daughtercard if you have them. Note that enabling the daughter -card disables GUS MAX driver. - -NOTE for owners of the 16 bit daughtercard: By default the daughtercard -uses /dev/dsp (and /dev/audio). Command "ln -sf /dev/dsp1 /dev/dsp" -selects the daughter card as the default device. - -With just the standard GUS enabled the configuration program prompts -for the I/O, IRQ and DMA numbers for the card. Use the same values than -with DOS. - -With the daughter card option enabled you will be prompted for the I/O, -IRQ and DMA numbers for the daughter card. You have to use different I/O -and DMA values than for the standard GUS. The daughter card permits -simultaneous recording and playback. Use /dev/dsp (the daughtercard) for -recording and /dev/dsp1 (GUS GF1) for playback. - -GUS MAX uses the same I/O address and IRQ settings than the original GUS -(GUS MAX = GUS + a CS4231 codec). In addition an extra DMA channel may be used. -Using two DMA channels permits simultaneous playback using two devices -(dev/dsp0 and /dev/dsp1). The second DMA channel is required for -full duplex audio. -To enable the second DMA channels, give a valid DMA channel when the config -program asks for the GUS MAX DMA (entering -1 disables the second DMA). -Using 16 bit DMA channels (5,6 or 7) is recommended. - -If you have problems in recording with GUS MAX, you could try to use -just one 8 bit DMA channel. Recording will not work with one DMA -channel if it's a 16 bit one. - -Microphone input of GUS MAX is connected to mixer in little bit nonstandard -way. There is actually two microphone volume controls. Normal "mic" controls -only recording level. Mixer control "speaker" is used to control volume of -microphone signal connected directly to line/speaker out. So just decrease -volume of "speaker" if you have problems with microphone feedback. - -GUS ACE works too but any attempt to record or to use the MIDI port -will fail. - -GUS PnP (with RAM) is partially supported but it needs to be initialized using -DOS or isapnptools before starting the driver. - -MPU401 and Windows Sound System -------------------------------- - -Again. Don't enable these options in case your card is listed -somewhere else in this file. - -Configuring these cards is obvious (or it should be). With MSS -you should probably enable the OPL3 synth also since -most MSS compatible cards have it. However check that this is true -before enabling OPL3. - -Sound driver supports more than one MPU401 compatible cards at the same time -but the config program asks config info for just the first of them. -Adding the second or third MPU interfaces must be done manually by -editing sound/local.h (after running the config program). Add defines for -MPU2_BASE & MPU2_IRQ (and MPU3_BASE & MPU3_IRQ) to the file. - -CAUTION! - -The default I/O base of Adaptec AHA-1542 SCSI controller is 0x330 which -is also the default of the MPU401 driver. Don't configure the sound driver to -use 0x330 as the MPU401 base if you have a AHA1542. The kernel will not boot -if you make this mistake. - -PSS ---- - -Even the PSS cards are compatible with SB, MSS and MPU401, you must not -enable these options when configuring the driver. The configuration -program handles these options itself. (You may use the SB, MPU and MSS options -together with PSS if you have another card on the system). - -The PSS driver enables MSS and MPU401 modes of the card. SB is not enabled -since it doesn't work concurrently with MSS. The driver loads also a -DSP algorithm which is used to for the general MIDI emulation. The -algorithm file (.ld) is read by the config program and written to a -file included when the pss.c is compiled. For this reason the config -program asks if you want to download the file. Use the genmidi.ld file -distributed with the DOS/Windows drivers of the card (don't use the mt32.ld). -With some cards the file is called 'synth.ld'. You must have access to -the file when configuring the driver. The easiest way is to mount the DOS -partition containing the file with Linux. - -It's possible to load your own DSP algorithms and run them with the card. -Look at the directory pss_test of snd-util-3.0.tar.gz for more info. - -AudioTrix Pro -------------- - -You have to enable the OPL3 and SB (not SB Pro or SB16) drivers in addition -to the native AudioTrix driver. Don't enable MSS or MPU drivers. - -Configuring ATP is little bit tricky since it uses so many I/O, IRQ and -DMA numbers. Using the same values than with DOS/Win is a good idea. Don't -attempt to use the same IRQ or DMA channels twice. - -The SB mode of ATP is implemented so the ATP driver just enables SB -in the proper address. The SB driver handles the rest. You have to configure -both the SB driver and the SB mode of ATP to use the same IRQ, DMA and I/O -settings. - -Also the ATP has a microcontroller for the General MIDI emulation (OPL4). -For this reason the driver asks for the name of a file containing the -microcode (TRXPRO.HEX). This file is usually located in the directory -where the DOS drivers were installed. You must have access to this file -when configuring the driver. - -If you have the effects daughtercard, it must be initialized by running -the setfx program of snd-util-3.0.tar.gz package. This step is not required -when using the (future) binary distribution version of the driver. - -Ensoniq SoundScape ------------------- - -NOTE! The new PnP SoundScape is not supported yet. Soundscape compatible - cards made by Reveal don't work with Linux. They use older revision - of the Soundscape chipset which is not fully compatible with - newer cards made by Ensoniq. - -The SoundScape driver handles initialization of MSS and MPU supports -itself so you don't need to enable other drivers than SoundScape -(enable also the /dev/dsp, /dev/sequencer and MIDI supports). - -!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -!!!!! !!!! -!!!!! NOTE! Before version 3.5-beta6 there WERE two sets of audio !!!! -!!!!! device files (/dev/dsp0 and /dev/dsp1). The first one WAS !!!! -!!!!! used only for card initialization and the second for audio !!!! -!!!!! purposes. It WAS required to change /dev/dsp (a symlink) to !!!! -!!!!! point to /dev/dsp1. !!!! -!!!!! !!!! -!!!!! This is not required with OSS versions 3.5-beta6 and later !!!! -!!!!! since there is now just one audio device file. Please !!!! -!!!!! change /dev/dsp to point back to /dev/dsp0 if you are !!!! -!!!!! upgrading from an earlier driver version using !!!! -!!!!! (cd /dev;rm dsp;ln -s dsp0 dsp). !!!! -!!!!! !!!! -!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - -The configuration program asks one DMA channel and two interrupts. One IRQ -and one DMA is used by the MSS codec. The second IRQ is required for the -MPU401 mode (you have to use different IRQs for both purposes). -There were earlier two DMA channels for SoundScape but the current driver -version requires just one. - -The SoundScape card has a Motorola microcontroller which must initialized -_after_ boot (the driver doesn't initialize it during boot). -The initialization is done by running the 'ssinit' program which is -distributed in the snd-util-3.0.tar.gz package. You have to edit two -defines in the ssinit.c and then compile the program. You may run ssinit -manually (after each boot) or add it to /etc/rc.d/rc.local. - -The ssinit program needs the microcode file that comes with the DOS/Windows -driver of the card. You will need to use version 1.30.00 or later -of the microcode file (sndscape.co0 or sndscape.co1 depending on -your card model). THE OLD sndscape.cod WILL NOT WORK. IT WILL HANG YOUR -MACHINE. The only way to get the new microcode file is to download -and install the DOS/Windows driver from ftp://ftp.ensoniq.com/pub. - -Then you have to select the proper microcode file to use: soundscape.co0 -is the right one for most cards and sndscape.co1 is for few (older) cards -made by Reveal and/or Spea. The driver has capability to detect the card -version during boot. Look at the boot log messages in /var/adm/messages -and locate the sound driver initialization message for the SoundScape -card. If the driver displays string , you have -an old card and you will need to use sndscape.co1. For other cards use -soundscape.co0. New Soundscape revisions such as Elite and PnP use -code files with higher numbers (.co2, .co3, etc.). - -NOTE! Ensoniq Soundscape VIVO is not compatible with other Soundscape cards. - Currently it's possible to use it in Linux only with OSS/Linux - drivers. - -Check /var/adm/messages after running ssinit. The driver prints -the board version after downloading the microcode file. That version -number must match the number in the name of the microcode file (extension). - -Running ssinit with a wrong version of the sndscape.co? file is not -dangerous as long as you don't try to use a file called sndscape.cod. -If you have initialized the card using a wrong microcode file (sounds -are terrible), just modify ssinit.c to use another microcode file and try -again. It's possible to use an earlier version of sndscape.co[01] but it -may sound weird. - -MAD16 (Pro) and Mozart ----------------------- - -You need to enable just the MAD16 /Mozart support when configuring -the driver. _Don't_ enable SB, MPU401 or MSS. However you will need the -/dev/audio, /dev/sequencer and MIDI supports. - -Mozart and OPTi 82C928 (the original MAD16) chips don't support -MPU401 mode so enter just 0 when the configuration program asks the -MPU/MIDI I/O base. The MAD16 Pro (OPTi 82C929) and 82C930 chips have MPU401 -mode. - -TB Tropez is based on the 82C929 chip. It has two MIDI ports. -The one connected to the MAD16 chip is the second one (there is a second -MIDI connector/pins somewhere??). If you have not connected the second MIDI -port, just disable the MIDI port of MAD16. The 'Maui' compatible synth of -Tropez is jumper configurable and not connected to the MAD16 chip (the -Maui driver can be used with it). - -Some MAD16 based cards may cause feedback, whistle or terrible noise if the -line3 mixer channel is turned too high. This happens at least with Shuttle -Sound System. Current driver versions set volume of line3 low enough so -this should not be a problem. - -If you have a MAD16 card which have an OPL4 (FM + Wave table) synthesizer -chip (_not_ an OPL3), you have to append a line containing #define MAD16_OPL4 -to the file linux/drivers/sound/local.h (after running make config). - -MAD16 cards having a CS4231 codec support full duplex mode. This mode -can be enabled by configuring the card to use two DMA channels. Possible -DMA channel pairs are: 0&1, 1&0 and 3&0. - -NOTE! Cards having an OPTi 82C924/82C925 chip work with OSS/Free only in -non-PnP mode (usually jumper selectable). The PnP mode is supported only -by OSS/Linux. - -MV Jazz (ProSonic) ------------------- - -The Jazz16 driver is just a hack made to the SB Pro driver. However it works -fairly well. You have to enable SB, SB Pro (_not_ SB16) and MPU401 supports -when configuring the driver. The configuration program asks later if you -want support for MV Jazz16 based cards (after asking SB base address). Answer -'y' here and the driver asks the second (16 bit) DMA channel. - -The Jazz16 driver uses the MPU401 driver in a way which will cause -problems if you have another MPU401 compatible card. In this case you must -give address of the Jazz16 based MPU401 interface when the config -program prompts for the MPU401 information. Then look at the MPU401 -specific section for instructions about configuring more than one MPU401 cards. - -Logitech Soundman Wave ----------------------- - -Read the above MV Jazz specific instructions first. - -The Logitech SoundMan Wave (don't confuse this with the SM16 or SM Games) is -a MV Jazz based card which has an additional OPL4 based wave table -synthesizer. The OPL4 chip is handled by an on board microcontroller -which must be initialized during boot. The config program asks if -you have a SM Wave immediately after asking the second DMA channel of jazz16. -If you answer 'y', the config program will ask name of the file containing -code to be loaded to the microcontroller. The file is usually called -MIDI0001.BIN and it's located in the DOS/Windows driver directory. The file -may also be called as TSUNAMI.BIN or something else (older cards?). - -The OPL4 synth will be inaccessible without loading the microcontroller code. - -Also remember to enable SB MPU401 support if you want to use the OPL4 mode. -(Don't enable the 'normal' MPU401 device as with some earlier driver -versions (pre 3.5-alpha8)). - -NOTE! Don't answer 'y' when the driver asks about SM Games support - (the next question after the MIDI0001.BIN name). However - answering 'y' doesn't cause damage your computer so don't panic. - -Sound Galaxies --------------- - -There are many different Sound Galaxy cards made by Aztech. The 8 bit -ones are fully SB or SB Pro compatible and there should be no problems -with them. - -The older 16 bit cards (SG Pro16, SG NX Pro16, Nova and Lyra) have -an EEPROM chip for storing the configuration data. There is a microcontroller -which initializes the card to match the EEPROM settings when the machine -is powered on. These cards actually behave just like they have jumpers -for all of the settings. Configure driver for MSS, MPU, SB/SB Pro and OPL3 -supports with these cards. - -There are some new Sound Galaxies in the market. I have no experience with -them so read the card's manual carefully. - -ESS ES1688 and ES688 'AudioDrive' based cards ---------------------------------------------- - -Support for these two ESS chips is embedded in the SB driver. -Configure these cards just like SB. Enable the 'SB MPU401 MIDI port' -if you want to use MIDI features of ES1688. ES688 doesn't have MPU mode -so you don't need to enable it (the driver uses normal SB MIDI automatically -with ES688). - -NOTE! ESS cards are not compatible with MSS/WSS so don't worry if MSS support -of OSS doesn't work with it. - -There are some ES1688/688 based sound cards and (particularly) motherboards -which use software configurable I/O port relocation feature of the chip. -This ESS proprietary feature is supported only by OSS/Linux. - -There are ES1688 based cards which use different interrupt pin assignment than -recommended by ESS (5, 7, 9/2 and 10). In this case all IRQs don't work. -At least a card called (Pearl?) Hypersound 16 supports IRQ 15 but it doesn't -work. - -ES1868 is a PnP chip which is (supposed to be) compatible with ESS1688 -probably works with OSS/Free after initialization using isapnptools. - -Reveal cards ------------- - -There are several different cards made/marketed by Reveal. Some of them -are compatible with SoundScape and some use the MAD16 chip. You may have -to look at the card and try to identify its origin. - -Diamond -------- - -The oldest (Sierra Aria based) sound cards made by Diamond are not supported -(they may work if the card is initialized using DOS). The recent (LX?) -models are based on the MAD16 chip which is supported by the driver. - -Audio Excel DSP16 ------------------ - -Support for this card is currently not functional. A new driver for it -should be available later this year. - -PCMCIA cards ------------- - -Sorry, can't help. Some cards may work and some don't. - -TI TM4000M notebooks --------------------- - -These computers have a built in sound support based on the Jazz chipset. -Look at the instructions for MV Jazz (above). It's also important to note -that there is something wrong with the mouse port and sound at least on -some TM models. Don't enable the "C&T 82C710 mouse port support" when -configuring Linux. Having it enabled is likely to cause mysterious problems -and kernel failures when sound is used. - -miroSOUND ---------- - -The miroSOUND PCM1-pro, PCM12 and PCM20 radio has been used -successfully. These cards are based on the MAD16, OPL4, and CS4231A chips -and everything said in the section about MAD16 cards applies here, -too. The only major difference between the PCMxx and other MAD16 cards -is that instead of the mixer in the CS4231 codec a separate mixer -controlled by an on-board 80C32 microcontroller is used. Control of -the mixer takes place via the ACI (miro's audio control interface) -protocol that is implemented in a separate lowlevel driver. Make sure -you compile this ACI driver together with the normal MAD16 support -when you use a miroSOUND PCMxx card. The ACI mixer is controlled by -/dev/mixer and the CS4231 mixer by /dev/mixer1 (depends on load -time). Only in special cases you want to change something regularly on -the CS4231 mixer. - -The miroSOUND PCM12 and PCM20 radio is capable of full duplex -operation (simultaneous PCM replay and recording), which allows you to -implement nice real-time signal processing audio effect software and -network telephones. The ACI mixer has to be switched into the "solo" -mode for duplex operation in order to avoid feedback caused by the -mixer (input hears output signal). You can de-/activate this mode -through toggling the record button for the wave controller with an -OSS-mixer. - -The PCM20 contains a radio tuner, which is also controlled by -ACI. This radio tuner is supported by the ACI driver together with the -miropcm20.o module. Also the 7-band equalizer is integrated -(limited by the OSS-design). Development has started and maybe -finished for the RDS decoder on this card, too. You will be able to -read RadioText, the Programme Service name, Programme TYpe and -others. Even the v4l radio module benefits from it with a refined -strength value. See aci.[ch] and miropcm20*.[ch] for more details. - -The following configuration parameters have worked fine for the PCM12 -in Markus Kuhn's system, many other configurations might work, too: -CONFIG_MAD16_BASE=0x530, CONFIG_MAD16_IRQ=11, CONFIG_MAD16_DMA=3, -CONFIG_MAD16_DMA2=0, CONFIG_MAD16_MPU_BASE=0x330, CONFIG_MAD16_MPU_IRQ=10, -DSP_BUFFSIZE=65536, SELECTED_SOUND_OPTIONS=0x00281000. - -Bas van der Linden is using his PCM1-pro with a configuration that -differs in: CONFIG_MAD16_IRQ=7, CONFIG_MAD16_DMA=1, CONFIG_MAD16_MPU_IRQ=9 - -Compaq Deskpro XL ------------------ - -The builtin sound hardware of Compaq Deskpro XL is now supported. -You need to configure the driver with MSS and OPL3 supports enabled. -In addition you need to manually edit linux/drivers/sound/local.h and -to add a line containing "#define DESKPROXL" if you used -make menuconfig/xconfig. - -Others? -------- - -Since there are so many different sound cards, it's likely that I have -forgotten to mention many of them. Please inform me if you know yet another -card which works with Linux, please inform me (or is anybody else -willing to maintain a database of supported cards (just like in XF86)?). - -Cards not supported yet -======================= - -Please check the version of sound driver you are using before -complaining that your card is not supported. It's possible you are -using a driver version which was released months before your card was -introduced. - -First of all, there is an easy way to make most sound cards work with Linux. -Just use the DOS based driver to initialize the card to a known state, then use -loadlin.exe to boot Linux. If Linux is configured to use the same I/O, IRQ and -DMA numbers as DOS, the card could work. -(ctrl-alt-del can be used in place of loadlin.exe but it doesn't work with -new motherboards). This method works also with all/most PnP sound cards. - -Don't get fooled with SB compatibility. Most cards are compatible with -SB but that may require a TSR which is not possible with Linux. If -the card is compatible with MSS, it's a better choice. Some cards -don't work in the SB and MSS modes at the same time. - -Then there are cards which are no longer manufactured and/or which -are relatively rarely used (such as the 8 bit ProAudioSpectrum -models). It's extremely unlikely that such cards ever get supported. -Adding support for a new card requires much work and increases time -required in maintaining the driver (some changes need to be done -to all low level drivers and be tested too, maybe with multiple -operating systems). For this reason I have made a decision to not support -obsolete cards. It's possible that someone else makes a separately -distributed driver (diffs) for the card. - -Writing a driver for a new card is not possible if there are no -programming information available about the card. If you don't -find your new card from this file, look from the home page -(http://www.opensound.com/ossfree). Then please contact -manufacturer of the card and ask if they have (or are willing to) -released technical details of the card. Do this before contacting me. I -can only answer 'no' if there are no programming information available. - -I have made decision to not accept code based on reverse engineering -to the driver. There are three main reasons: First I don't want to break -relationships to sound card manufacturers. The second reason is that -maintaining and supporting a driver without any specs will be a pain. -The third reason is that companies have freedom to refuse selling their -products to other than Windows users. - -Some companies don't give low level technical information about their -products to public or at least their require signing a NDA. It's not -possible to implement a freeware driver for them. However it's possible -that support for such cards become available in the commercial version -of this driver (see http://www.4Front-tech.com/oss.html for more info). - -There are some common audio chipsets that are not supported yet. For example -Sierra Aria and IBM Mwave. It's possible that these architectures -get some support in future but I can't make any promises. Just look -at the home page (http://www.opensound.com/ossfree/) -for latest info. - -Information about unsupported sound cards and chipsets is welcome as well -as free copies of sound cards, SDKs and operating systems. - -If you have any corrections and/or comments, please contact me. - -Hannu Savolainen -hannu@opensound.com - -home page of OSS/Free: http://www.opensound.com/ossfree - -home page of commercial OSS -(Open Sound System) drivers: http://www.opensound.com/oss.html diff --git a/Documentation/sound/oss/README.modules b/Documentation/sound/oss/README.modules deleted file mode 100644 index cdc039421a46..000000000000 --- a/Documentation/sound/oss/README.modules +++ /dev/null @@ -1,106 +0,0 @@ -Building a modular sound driver -================================ - - The following information is current as of linux-2.1.85. Check the other -readme files, especially README.OSS, for information not specific to -making sound modular. - - First, configure your kernel. This is an idea of what you should be -setting in the sound section: - - Sound card support - - 100% Sound Blaster compatibles (SB16/32/64, ESS, Jazz16) support - - I have SoundBlaster. Select your card from the list. - - Generic OPL2/OPL3 FM synthesizer support - FM synthesizer (YM3812/OPL-3) support - - If you don't set these, you will probably find you can play .wav files -but not .midi. As the help for them says, set them unless you know your -card does not use one of these chips for FM support. - - Once you are configured, make zlilo, modules, modules_install; reboot. -Note that it is no longer necessary or possible to configure sound in the -drivers/sound dir. Now one simply configures and makes one's kernel and -modules in the usual way. - - Then, add to your /etc/modprobe.d/oss.conf something like: - -alias char-major-14-* sb -install sb /sbin/modprobe -i sb && /sbin/modprobe adlib_card -options sb io=0x220 irq=7 dma=1 dma16=5 mpu_io=0x330 -options adlib_card io=0x388 # FM synthesizer - - Alternatively, if you have compiled in kernel level ISAPnP support: - -alias char-major-14 sb -softdep sb post: adlib_card -options adlib_card io=0x388 - - The effect of this is that the sound driver and all necessary bits and -pieces autoload on demand, assuming you use kerneld (a sound choice) and -autoclean when not in use. Also, options for the device drivers are -set. They will not work without them. Change as appropriate for your card. -If you are not yet using the very cool kerneld, you will have to "modprobe --k sb" yourself to get things going. Eventually things may be fixed so -that this kludgery is not necessary; for the time being, it seems to work -well. - - Replace 'sb' with the driver for your card, and give it the right -options. To find the filename of the driver, look in -/lib/modules//misc. Mine looks like: - -adlib_card.o # This is the generic OPLx driver -opl3.o # The OPL3 driver -sb.o # <> -sound.o # The sound driver -uart401.o # Used by sb, maybe other cards - - Whichever card you have, try feeding it the options that would be the -default if you were making the driver wired, not as modules. You can -look at function referred to by module_init() for the card to see what -args are expected. - - Note that at present there is no way to configure the io, irq and other -parameters for the modular drivers as one does for the wired drivers.. One -needs to pass the modules the necessary parameters as arguments, either -with /etc/modprobe.d/*.conf or with command-line args to modprobe, e.g. - -modprobe sb io=0x220 irq=7 dma=1 dma16=5 mpu_io=0x330 -modprobe adlib_card io=0x388 - - recommend using /etc/modprobe.d/*.conf. - -Persistent DMA Buffers: - -The sound modules normally allocate DMA buffers during open() and -deallocate them during close(). Linux can often have problems allocating -DMA buffers for ISA cards on machines with more than 16MB RAM. This is -because ISA DMA buffers must exist below the 16MB boundary and it is quite -possible that we can't find a large enough free block in this region after -the machine has been running for any amount of time. The way to avoid this -problem is to allocate the DMA buffers during module load and deallocate -them when the module is unloaded. For this to be effective we need to load -the sound modules right after the kernel boots, either manually or by an -init script, and keep them around until we shut down. This is a little -wasteful of RAM, but it guarantees that sound always works. - -To make the sound driver use persistent DMA buffers we need to pass the -sound.o module a "dmabuf=1" command-line argument. This is normally done -in /etc/modprobe.d/*.conf files like so: - -options sound dmabuf=1 - -If you have 16MB or less RAM or a PCI sound card, this is wasteful and -unnecessary. It is possible that machine with 16MB or less RAM will find -this option useful, but if your machine is so memory-starved that it -cannot find a 64K block free, you will be wasting even more RAM by keeping -the sound modules loaded and the DMA buffers allocated when they are not -needed. The proper solution is to upgrade your RAM. But you do also have -this improper solution as well. Use it wisely. - - I'm afraid I know nothing about anything but my setup, being more of a -text-mode guy anyway. If you have options for other cards or other helpful -hints, send them to me, Jim Bray, jb@as220.org, http://as220.org/jb. diff --git a/Documentation/sound/oss/README.ymfsb b/Documentation/sound/oss/README.ymfsb deleted file mode 100644 index b6b77906b58d..000000000000 --- a/Documentation/sound/oss/README.ymfsb +++ /dev/null @@ -1,107 +0,0 @@ -Legacy audio driver for YMF7xx PCI cards. - - -FIRST OF ALL -============ - - This code references YAMAHA's sample codes and data sheets. - I respect and thank for all people they made open the information - about YMF7xx cards. - - And this codes heavily based on Jeff Garzik 's - old VIA 82Cxxx driver (via82cxxx.c). I also respect him. - - -DISCLIMER -========= - - This driver is currently at early ALPHA stage. It may cause serious - damage to your computer when used. - PLEASE USE IT AT YOUR OWN RISK. - - -ABOUT THIS DRIVER -================= - - This code enables you to use your YMF724[A-F], YMF740[A-C], YMF744, YMF754 - cards. When enabled, your card acts as "SoundBlaster Pro" compatible card. - It can only play 22.05kHz / 8bit / Stereo samples, control external MIDI - port. - If you want to use your card as recent "16-bit" card, you should use - Alsa or OSS/Linux driver. Of course you can write native PCI driver for - your cards :) - - -USAGE -===== - - # modprobe ymfsb (options) - - -OPTIONS FOR MODULE -================== - - io : SB base address (0x220, 0x240, 0x260, 0x280) - synth_io : OPL3 base address (0x388, 0x398, 0x3a0, 0x3a8) - dma : DMA number (0,1,3) - master_volume: AC'97 PCM out Vol (0-100) - spdif_out : SPDIF-out flag (0:disable 1:enable) - - These options will change in future... - - -FREQUENCY -========= - - When playing sounds via this driver, you will hear its pitch is slightly - lower than original sounds. Since this driver recognizes your card acts - with 21.739kHz sample rates rather than 22.050kHz (I think it must be - hardware restriction). So many players become tone deafness. - To prevent this, you should express some options to your sound player - that specify correct sample frequency. For example, to play your MP3 file - correctly with mpg123, specify the frequency like following: - - % mpg123 -r 21739 foo.mp3 - - -SPDIF OUT -========= - - With installing modules with option 'spdif_out=1', you can enjoy your - sounds from SPDIF-out of your card (if it had). - Its Fs is fixed to 48kHz (It never means the sample frequency become - up to 48kHz. All sounds via SPDIF-out also 22kHz samples). So your - digital-in capable components has to be able to handle 48kHz Fs. - - -COPYING -======= - - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2, or (at your option) - any later version. - - This program is distributed in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - -TODO -==== - * support for multiple cards - (set the different SB_IO,MPU_IO,OPL_IO for each cards) - - * support for OPL (dmfm) : There will be no requirements... :-< - - -AUTHOR -====== - - Daisuke Nagano - diff --git a/Documentation/sound/oss/SoundPro b/Documentation/sound/oss/SoundPro deleted file mode 100644 index 9d4db1f29d3c..000000000000 --- a/Documentation/sound/oss/SoundPro +++ /dev/null @@ -1,105 +0,0 @@ -Documentation for the SoundPro CMI8330 extensions in the WSS driver (ad1848.o) ------------------------------------------------------------------------------- - -( Be sure to read Documentation/sound/oss/CMI8330 too ) - -Ion Badulescu, ionut@cs.columbia.edu -February 24, 1999 - -(derived from the OPL3-SA2 documentation by Scott Murray) - -The SoundPro CMI8330 (ISA) is a chip usually found on some Taiwanese -motherboards. The official name in the documentation is CMI8330, SoundPro -is the nickname and the big inscription on the chip itself. - -The chip emulates a WSS as well as a SB16, but it has certain differences -in the mixer section which require separate support. It also emulates an -MPU401 and an OPL3 synthesizer, so you probably want to enable support -for these, too. - -The chip identifies itself as an AD1848, but its mixer is significantly -more advanced than the original AD1848 one. If your system works with -either WSS or SB16 and you are having problems with some mixer controls -(no CD audio, no line-in, etc), you might want to give this driver a try. -Detection should work, but it hasn't been widely tested, so it might still -mis-identify the chip. You can still force soundpro=1 in the modprobe -parameters for ad1848. Please let me know if it happens to you, so I can -adjust the detection routine. - -The chip is capable of doing full-duplex, but since the driver sees it as an -AD1848, it cannot take advantage of this. Moreover, the full-duplex mode is -not achievable through the WSS interface, b/c it needs a dma16 line which is -assigned only to the SB16 subdevice (with isapnp). Windows documentation -says the user must use WSS Playback and SB16 Recording for full-duplex, so -it might be possible to do the same thing under Linux. You can try loading -up both ad1848 and sb then use one for playback and the other for -recording. I don't know if this works, b/c I haven't tested it. Anyway, if -you try it, be very careful: the SB16 mixer *mostly* works, but certain -settings can have unexpected effects. Use the WSS mixer for best results. - -There is also a PCI SoundPro chip. I have not seen this chip, so I have -no idea if the driver will work with it. I suspect it won't. - -As with PnP cards, some configuration is required. There are two ways -of doing this. The most common is to use the isapnptools package to -initialize the card, and use the kernel module form of the sound -subsystem and sound drivers. Alternatively, some BIOS's allow manual -configuration of installed PnP devices in a BIOS menu, which should -allow using the non-modular sound drivers, i.e. built into the kernel. -Since in this latter case you cannot use module parameters, you will -have to enable support for the SoundPro at compile time. - -The IRQ and DMA values can be any that are considered acceptable for a -WSS. Assuming you've got isapnp all happy, then you should be able to -do something like the following (which *must* match the isapnp/BIOS -configuration): - -modprobe ad1848 io=0x530 irq=11 dma=0 soundpro=1 --and maybe- -modprobe sb io=0x220 irq=5 dma=1 dma16=5 - --then- -modprobe mpu401 io=0x330 irq=9 -modprobe opl3 io=0x388 - -If all goes well and you see no error messages, you should be able to -start using the sound capabilities of your system. If you get an -error message while trying to insert the module(s), then make -sure that the values of the various arguments match what you specified -in your isapnp configuration file, and that there is no conflict with -another device for an I/O port or interrupt. Checking the contents of -/proc/ioports and /proc/interrupts can be useful to see if you're -butting heads with another device. - -If you do not see the chipset version message, and none of the other -messages present in the system log are helpful, try adding 'debug=1' -to the ad1848 parameters, email me the syslog results and I'll do -my best to help. - -Lastly, if you're using modules and want to set up automatic module -loading with kmod, the kernel module loader, here is the section I -currently use in my conf.modules file: - -# Sound -post-install sound modprobe -k ad1848; modprobe -k mpu401; modprobe -k opl3 -options ad1848 io=0x530 irq=11 dma=0 -options sb io=0x220 irq=5 dma=1 dma16=5 -options mpu401 io=0x330 irq=9 -options opl3 io=0x388 - -The above ensures that ad1848 will be loaded whenever the sound system -is being used. - -Good luck. - -Ion - -NOT REALLY TESTED: -- recording -- recording device selection -- full-duplex - -TODO: -- implement mixer support for surround, loud, digital CD switches. -- come up with a scheme which allows recording volumes for each subdevice. -This is a major OSS API change. diff --git a/Documentation/sound/oss/Soundblaster b/Documentation/sound/oss/Soundblaster deleted file mode 100644 index b288d464ba8b..000000000000 --- a/Documentation/sound/oss/Soundblaster +++ /dev/null @@ -1,53 +0,0 @@ -modprobe sound -insmod uart401 -insmod sb ... - -This loads the driver for the Sound Blaster and assorted clones. Cards that -are covered by other drivers should not be using this driver. - -The Sound Blaster module takes the following arguments - -io I/O address of the Sound Blaster chip (0x220,0x240,0x260,0x280) -irq IRQ of the Sound Blaster chip (5,7,9,10) -dma 8-bit DMA channel for the Sound Blaster (0,1,3) -dma16 16-bit DMA channel for SB16 and equivalent cards (5,6,7) -mpu_io I/O for MPU chip if present (0x300,0x330) - -sm_games=1 Set if you have a Logitech soundman games -acer=1 Set this to detect cards in some ACER notebooks -mwave_bug=1 Set if you are trying to use this driver with mwave (see on) -type Use this to specify a specific card type - -The following arguments are taken if ISAPnP support is compiled in - -isapnp=0 Set this to disable ISAPnP detection (use io=0xXXX etc. above) -multiple=0 Set to disable detection of multiple Soundblaster cards. - Consider it a bug if this option is needed, and send in a - report. -pnplegacy=1 Set this to be able to use a PnP card(s) along with a single - non-PnP (legacy) card. Above options for io, irq, etc. are - needed, and will apply only to the legacy card. -reverse=1 Reverses the order of the search in the PnP table. -uart401=1 Set to enable detection of mpu devices on some clones. -isapnpjump=n Jumps to slot n in the driver's PnP table. Use the source, - Luke. - -You may well want to load the opl3 driver for synth music on most SB and -clone SB devices - -insmod opl3 io=0x388 - -Using Mwave - -To make this driver work with Mwave you must set mwave_bug. You also need -to warm boot from DOS/Windows with the required firmware loaded under this -OS. IBM are being difficult about documenting how to load this firmware. - -Avance Logic ALS007 - -This card is supported; see the separate file ALS007 for full details. - -Avance Logic ALS100 - -This card is supported; setup should be as for a standard Sound Blaster 16. -The driver will identify the audio device as a "Sound Blaster 16 (ALS-100)". diff --git a/Documentation/sound/oss/Tropez+ b/Documentation/sound/oss/Tropez+ deleted file mode 100644 index b93a6b734fc0..000000000000 --- a/Documentation/sound/oss/Tropez+ +++ /dev/null @@ -1,26 +0,0 @@ -From: Paul Barton-Davis - -Here is the configuration I use with a Tropez+ and my modular -driver: - - alias char-major-14 wavefront - alias synth0 wavefront - alias mixer0 cs4232 - alias audio0 cs4232 - pre-install wavefront modprobe "-k" "cs4232" - post-install wavefront modprobe "-k" "opl3" - options wavefront io=0x200 irq=9 - options cs4232 synthirq=9 synthio=0x200 io=0x530 irq=5 dma=1 dma2=0 - options opl3 io=0x388 - -Things to note: - - the wavefront options "io" and "irq" ***MUST*** match the "synthio" - and "synthirq" cs4232 options. - - you can do without the opl3 module if you don't - want to use the OPL/[34] synth on the soundcard - - the opl3 io parameter is conventionally not adjustable. - -Please see drivers/sound/README.wavefront for more details. diff --git a/Documentation/sound/oss/VIBRA16 b/Documentation/sound/oss/VIBRA16 deleted file mode 100644 index 68a5a46beb88..000000000000 --- a/Documentation/sound/oss/VIBRA16 +++ /dev/null @@ -1,80 +0,0 @@ -Sound Blaster 16X Vibra addendum --------------------------------- -by Marius Ilioaea - Stefan Laudat - -Sat Mar 6 23:55:27 EET 1999 - - Hello again, - - Playing with a SB Vibra 16x soundcard we found it very difficult -to setup because the kernel reported a lot of DMA errors and wouldn't -simply play any sound. - A good starting point is that the vibra16x chip full-duplex facility -is neither still exploited by the sb driver found in the linux kernel -(tried it with a 2.2.2-ac7), nor in the commercial OSS package (it reports -it as half-duplex soundcard). Oh, I almost forgot, the RedHat sndconfig -failed detecting it ;) - So, the big problem still remains, because the sb module wants a -8-bit and a 16-bit dma, which we could not allocate for vibra... it supports -only two 8-bit dma channels, the second one will be passed to the module -as a 16 bit channel, the kernel will yield about that but everything will -be okay, trust us. - The only inconvenient you may find is that you will have -some sound playing jitters if you have HDD dma support enabled - but this -will happen with almost all soundcards... - - A fully working isapnp.conf is just here: - - - -(READPORT 0x0203) -(ISOLATE PRESERVE) -(IDENTIFY *) -(VERBOSITY 2) -(CONFLICT (IO FATAL)(IRQ FATAL)(DMA FATAL)(MEM FATAL)) # or WARNING -# SB 16 and OPL3 devices -(CONFIGURE CTL00f0/-1 (LD 0 -(INT 0 (IRQ 5 (MODE +E))) -(DMA 0 (CHANNEL 1)) -(DMA 1 (CHANNEL 3)) -(IO 0 (SIZE 16) (BASE 0x0220)) -(IO 2 (SIZE 4) (BASE 0x0388)) -(NAME "CTL00f0/-1[0]{Audio }") -(ACT Y) -)) - -# Joystick device - only if you need it :-/ - -(CONFIGURE CTL00f0/-1 (LD 1 -(IO 0 (SIZE 1) (BASE 0x0200)) -(NAME "CTL00f0/-1[1]{Game }") -(ACT Y) -)) -(WAITFORKEY) - - - - So, after a good kernel modules compilation and a 'depmod -a kernel_ver' -you may want to: - -modprobe sb io=0x220 irq=5 dma=1 dma16=3 - - Or, take the hard way: - -modprobe soundcore -modprobe sound -modprobe uart401 -modprobe sb io=0x220 irq=5 dma=1 dma16=3 -# do you need MIDI? -modprobe opl3=0x388 - - Just in case, the kernel sound support should be: - -CONFIG_SOUND=m -CONFIG_SOUND_OSS=m -CONFIG_SOUND_SB=m - - Enjoy your new noisy Linux box! ;) - - diff --git a/Documentation/sound/oss/WaveArtist b/Documentation/sound/oss/WaveArtist deleted file mode 100644 index f4f3407cd818..000000000000 --- a/Documentation/sound/oss/WaveArtist +++ /dev/null @@ -1,170 +0,0 @@ - - (the following is from the armlinux CVS) - - WaveArtist mixer and volume levels can be accessed via these commands: - - nn30 read registers nn, where nn = 00 - 09 for mixer settings - 0a - 13 for channel volumes - mm31 write the volume setting in pairs, where mm = (nn - 10) / 2 - rr32 write the mixer settings in pairs, where rr = nn/2 - xx33 reset all settings to default - 0y34 select mono source, y=0 = left, y=1 = right - - bits - nn 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 00 | 0 | 0 0 1 1 | left line mixer gain | left aux1 mixer gain |lmute| -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 01 | 0 | 0 1 0 1 | left aux2 mixer gain | right 2 left mic gain |mmute| -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 02 | 0 | 0 1 1 1 | left mic mixer gain | left mic | left mixer gain |dith | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 03 | 0 | 1 0 0 1 | left mixer input select |lrfg | left ADC gain | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 04 | 0 | 1 0 1 1 | right line mixer gain | right aux1 mixer gain |rmute| -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 05 | 0 | 1 1 0 1 | right aux2 mixer gain | left 2 right mic gain |test | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 06 | 0 | 1 1 1 1 | right mic mixer gain | right mic |right mixer gain |rbyps| -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 07 | 1 | 0 0 0 1 | right mixer select |rrfg | right ADC gain | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 08 | 1 | 0 0 1 1 | mono mixer gain |right ADC mux sel|left ADC mux sel | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 09 | 1 | 0 1 0 1 |loopb|left linout|loop|ADCch|TxFch|OffCD|test |loopb|loopb|osamp| -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 0a | 0 | left PCM channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 0b | 0 | right PCM channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 0c | 0 | left FM channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 0d | 0 | right FM channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 0e | 0 | left wavetable channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 0f | 0 | right wavetable channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 10 | 0 | left PCM expansion channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 11 | 0 | right PCM expansion channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 12 | 0 | left FM expansion channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - 13 | 0 | right FM expansion channel volume | -----+---+------------+-----+-----+-----+----+-----+-----+-----+-----+-----+-----+-----+ - - lmute: left mute - mmute: mono mute - dith: dithds - lrfg: - rmute: right mute - rbyps: right bypass - rrfg: - ADCch: - TxFch: - OffCD: - osamp: - - And the following diagram is derived from the description in the CVS archive: - - MIC L (mouthpiece) - +------+ - -->PreAmp>-\ - +--^---+ | - | | - r2b4-5 | +--------+ - /----*-------------------------------->5 | - | | | - | /----------------------------------->4 | - | | | | - | | /--------------------------------->3 1of5 | +---+ - | | | | mux >-->AMP>--> ADC L - | | | /------------------------------->2 | +-^-+ - | | | | | | | - Line | | | | +----+ +------+ +---+ /---->1 | r3b3-0 - ------------*->mute>--> Gain >--> | | | | - L | | | +----+ +------+ | | | *->0 | - | | | | | | +---^----+ - Aux2 | | | +----+ +------+ | | | | - ----------*--->mute>--> Gain >--> M | | r8b0-2 - L | | +----+ +------+ | | | - | | | | \------\ - Aux1 | | +----+ +------+ | | | - --------*----->mute>--> Gain >--> I | | - L | +----+ +------+ | | | - | | | | - | +----+ +------+ | | +---+ | - *------->mute>--> Gain >--> X >-->AMP>--* - | +----+ +------+ | | +-^-+ | - | | | | | - | +----+ +------+ | | r2b1-3 | - | /----->mute>--> Gain >--> E | | - | | +----+ +------+ | | | - | | | | | - | | +----+ +------+ | | | - | | /--->mute>--> Gain >--> R | | - | | | +----+ +------+ | | | - | | | | | | r9b8-9 - | | | +----+ +------+ | | | | - | | | /->mute>--> Gain >--> | | +---v---+ - | | | | +----+ +------+ +---+ /-*->0 | - DAC | | | | | | | - ------------*----------------------------------->? | +----+ - L | | | | | Mux >-->mute>--> L output - | | | | /->? | +--^-+ - | | | | | | | | - | | | /--------->? | r0b0 - | | | | | | +-------+ - | | | | | | - Mono | | | | | | +-------+ - ----------* | \---> | +----+ - | | | | | | Mix >-->mute>--> Mono output - | | | | *-> | +--^-+ - | | | | | +-------+ | - | | | | | r1b0 - DAC | | | | | +-------+ - ------------*-------------------------*--------->1 | +----+ - R | | | | | | Mux >-->mute>--> R output - | | | | +----+ +------+ +---+ *->0 | +--^-+ - | | | \->mute>--> Gain >--> | | +---^---+ | - | | | +----+ +------+ | | | | r5b0 - | | | | | | r6b0 - | | | +----+ +------+ | | | - | | \--->mute>--> Gain >--> M | | - | | +----+ +------+ | | | - | | | | | - | | +----+ +------+ | | | - | *----->mute>--> Gain >--> I | | - | | +----+ +------+ | | | - | | | | | - | | +----+ +------+ | | +---+ | - \------->mute>--> Gain >--> X >-->AMP>--* - | +----+ +------+ | | +-^-+ | - /--/ | | | | - Aux1 | +----+ +------+ | | r6b1-3 | - -------*------>mute>--> Gain >--> E | | - R | | +----+ +------+ | | | - | | | | | - Aux2 | | +----+ +------+ | | /------/ - ---------*---->mute>--> Gain >--> R | | - R | | | +----+ +------+ | | | - | | | | | | +--------+ - Line | | | +----+ +------+ | | | *->0 | - -----------*-->mute>--> Gain >--> | | | | - R | | | | +----+ +------+ +---+ \---->1 | - | | | | | | - | | | \-------------------------------->2 | +---+ - | | | | Mux >-->AMP>--> ADC R - | | \---------------------------------->3 | +-^-+ - | | | | | - | \------------------------------------>4 | r7b3-0 - | | | - \-----*-------------------------------->5 | - | +---^----+ - r6b4-5 | | - | | r8b3-5 - +--v---+ | - -->PreAmp>-/ - +------+ - MIC R (electret mic) diff --git a/Documentation/sound/oss/btaudio b/Documentation/sound/oss/btaudio deleted file mode 100644 index effdb9a3f898..000000000000 --- a/Documentation/sound/oss/btaudio +++ /dev/null @@ -1,92 +0,0 @@ - -Intro -===== - -people start bugging me about this with questions, looks like I -should write up some documentation for this beast. That way I -don't have to answer that much mails I hope. Yes, I'm lazy... - - -You might have noticed that the bt878 grabber cards have actually -_two_ PCI functions: - -$ lspci -[ ... ] -00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02) -00:0a.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02) -[ ... ] - -The first does video, it is backward compatible to the bt848. The second -does audio. btaudio is a driver for the second function. It's a sound -driver which can be used for recording sound (and _only_ recording, no -playback). As most TV cards come with a short cable which can be plugged -into your sound card's line-in you probably don't need this driver if all -you want to do is just watching TV... - - -Driver Status -============= - -Still somewhat experimental. The driver should work stable, i.e. it -should'nt crash your box. It might not work as expected, have bugs, -not being fully OSS API compliant, ... - -Latest versions are available from http://bytesex.org/bttv/, the -driver is in the bttv tarball. Kernel patches might be available too, -have a look at http://bytesex.org/bttv/listing.html. - -The chip knows two different modes. btaudio registers two dsp -devices, one for each mode. They can not be used at the same time. - - -Digital audio mode -================== - -The chip gives you 16 bit stereo sound. The sample rate depends on -the external source which feeds the bt878 with digital sound via I2S -interface. There is a insmod option (rate) to tell the driver which -sample rate the hardware uses (32000 is the default). - -One possible source for digital sound is the msp34xx audio processor -chip which provides digital sound via I2S with 32 kHz sample rate. My -Hauppauge board works this way. - -The Osprey-200 reportly gives you digital sound with 44100 Hz sample -rate. It is also possible that you get no sound at all. - - -analog mode (A/D) -================= - -You can tell the driver to use this mode with the insmod option "analog=1". -The chip has three analog inputs. Consequently you'll get a mixer device -to control these. - -The analog mode supports mono only. Both 8 + 16 bit. Both are _signed_ -int, which is uncommon for the 8 bit case. Sample rate range is 119 kHz -to 448 kHz. Yes, the number of digits is correct. The driver supports -downsampling by powers of two, so you can ask for more usual sample rates -like 44 kHz too. - -With my Hauppauge I get noisy sound on the second input (mapped to line2 -by the mixer device). Others get a useable signal on line1. - - -some examples -============= - -* read audio data from btaudio (dsp2), send to es1730 (dsp,dsp1): - $ sox -w -r 32000 -t ossdsp /dev/dsp2 -t ossdsp /dev/dsp - -* read audio data from btaudio, send to esound daemon (which might be - running on another host): - $ sox -c 2 -w -r 32000 -t ossdsp /dev/dsp2 -t sw - | esdcat -r 32000 - $ sox -c 1 -w -r 32000 -t ossdsp /dev/dsp2 -t sw - | esdcat -m -r 32000 - - -Have fun, - - Gerd - --- -Gerd Knorr diff --git a/Documentation/sound/oss/mwave b/Documentation/sound/oss/mwave deleted file mode 100644 index 5fbcb1609275..000000000000 --- a/Documentation/sound/oss/mwave +++ /dev/null @@ -1,185 +0,0 @@ - How to try to survive an IBM Mwave under Linux SB drivers - - -+ IBM have now released documentation of sorts and Torsten is busy - trying to make the Mwave work. This is not however a trivial task. - ----------------------------------------------------------------------------- - -OK, first thing - the IRQ problem IS a problem, whether the test is bypassed or -not. It is NOT a Linux problem, but an MWAVE problem that is fixed with the -latest MWAVE patches. So, in other words, don't bypass the test for MWAVES! - -I have Windows 95 on /dev/hda1, swap on /dev/hda2, and Red Hat 5 on /dev/hda3. - -The steps, then: - - Boot to Linux. - Mount Windows 95 file system (assume mount point = /dos95). - mkdir /dos95/linux - mkdir /dos95/linux/boot - mkdir /dos95/linux/boot/parms - - Copy the kernel, any initrd image, and loadlin to /dos95/linux/boot/. - - Reboot to Windows 95. - - Edit C:/msdos.sys and add or change the following: - - Logo=0 - BootGUI=0 - - Note that msdos.sys is a text file but it needs to be made 'unhidden', - readable and writable before it can be edited. This can be done with - DOS' "attrib" command. - - Edit config.sys to have multiple config menus. I have one for windows 95 and - five for Linux, like this: ------------- -[menu] -menuitem=W95, Windows 95 -menuitem=LINTP, Linux - ThinkPad -menuitem=LINTP3, Linux - ThinkPad Console -menuitem=LINDOC, Linux - Docked -menuitem=LINDOC3, Linux - Docked Console -menuitem=LIN1, Linux - Single User Mode -REM menudefault=W95,10 - -[W95] - -[LINTP] - -[LINDOC] - -[LINTP3] - -[LINDOC3] - -[LIN1] - -[COMMON] -FILES=30 -REM Please read README.TXT in C:\MWW subdirectory before changing the DOS= statement. -DOS=HIGH,UMB -DEVICE=C:\MWW\MANAGER\MWD50430.EXE -SHELL=c:\command.com /e:2048 -------------------- - -The important things are the SHELL and DEVICE statements. - - Then change autoexec.bat. Basically everything in there originally should be - done ONLY when Windows 95 is booted. Then you add new things specifically - for Linux. Mine is as follows - ---------------- -@ECHO OFF -if "%CONFIG%" == "W95" goto W95 - -REM -REM Linux stuff -REM -SET MWPATH=C:\MWW\DLL;C:\MWW\MWGAMES;C:\MWW\DSP -SET BLASTER=A220 I5 D1 -SET MWROOT=C:\MWW -SET LIBPATH=C:\MWW\DLL -SET PATH=C:\WINDOWS;C:\MWW\DLL; -CALL MWAVE START NOSHOW -c:\linux\boot\loadlin.exe @c:\linux\boot\parms\%CONFIG%.par - -:W95 -REM -REM Windows 95 stuff -REM -c:\toolkit\guard -SET MSINPUT=C:\MSINPUT -SET MWPATH=C:\MWW\DLL;C:\MWW\MWGAMES;C:\MWW\DSP -REM The following is used by DOS games to recognize Sound Blaster hardware. -REM If hardware settings are changed, please change this line as well. -REM See the Mwave README file for instructions. -SET BLASTER=A220 I5 D1 -SET MWROOT=C:\MWW -SET LIBPATH=C:\MWW\DLL -SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;E:\ORAWIN95\BIN;f:\msdev\bin;e:\v30\bin.dbg;v:\devt\v30\bin;c:\JavaSDK\Bin;C:\MWW\DLL; -SET INCLUDE=f:\MSDEV\INCLUDE;F:\MSDEV\MFC\INCLUDE -SET LIB=F:\MSDEV\LIB;F:\MSDEV\MFC\LIB -win - ------------------------- - -Now build a file in c:\linux\boot\parms for each Linux config that you have. - -For example, my LINDOC3 config is for a docked Thinkpad at runlevel 3 with no -initrd image, and has a parameter file named LINDOC3.PAR in c:\linux\boot\parms: - ------------------------ -# LOADLIN @param_file image=other_image root=/dev/other -# -# Linux Console in docking station -# -c:\linux\boot\zImage.krn # First value must be filename of Linux kernel. -root=/dev/hda3 # device which gets mounted as root FS -ro # Other kernel arguments go here. -apm=off -doc=yes -3 ------------------------ - -The doc=yes parameter is an environment variable used by my init scripts, not -a kernel argument. - -However, the apm=off parameter IS a kernel argument! APM, at least in my setup, -causes the kernel to crash when loaded via loadlin (but NOT when loaded via -LILO). The APM stuff COULD be forced out of the kernel via the kernel compile -options. Instead, I got an unofficial patch to the APM drivers that allows them -to be dynamically deactivated via kernel arguments. Whatever you chose to -document, APM, it seems, MUST be off for setups like mine. - -Now make sure C:\MWW\MWCONFIG.REF looks like this: - ----------------------- -[NativeDOS] -Default=SB1.5 -SBInputSource=CD -SYNTH=FM -QSound=OFF -Reverb=OFF -Chorus=OFF -ReverbDepth=5 -ChorusDepth=5 -SBInputVolume=5 -SBMainVolume=10 -SBWaveVolume=10 -SBSynthVolume=10 -WaveTableVolume=10 -AudioPowerDriver=ON - -[FastCFG] -Show=No -HideOption=Off ------------------------------ - -OR the Default= line COULD be - -Default=SBPRO - -Reboot to Windows 95 and choose Linux. When booted, use sndconfig to configure -the sound modules and voilà - ThinkPad sound with Linux. - -Now the gotchas - you can either have CD sound OR Mixers but not both. That's a -problem with the SB1.5 (CD sound) or SBPRO (Mixers) settings. No one knows why -this is! - -For some reason MPEG3 files, when played through mpg123, sound like they -are playing at 1/8th speed - not very useful! If you have ANY insight -on why this second thing might be happening, I would be grateful. - -=========================================================== - _/ _/_/_/_/ - _/_/ _/_/ _/ - _/ _/_/ _/_/_/_/ Martin John Bartlett - _/ _/ _/ _/ (martin@nitram.demon.co.uk) -_/ _/_/_/_/ - _/ -_/ _/ - _/_/ -=========================================================== diff --git a/Documentation/sound/oss/oss-parameters.txt b/Documentation/sound/oss/oss-parameters.txt deleted file mode 100644 index cc675f25eee4..000000000000 --- a/Documentation/sound/oss/oss-parameters.txt +++ /dev/null @@ -1,51 +0,0 @@ - OSS Kernel Parameters - ~~~~~~~~~~~~~~~~~~~~~ - -See Documentation/admin-guide/kernel-parameters.rst for general information on -specifying module parameters. - -This document may not be entirely up to date and comprehensive. The command -"modinfo -p ${modulename}" shows a current list of all parameters of a loadable -module. Loadable modules, after being loaded into the running kernel, also -reveal their parameters in /sys/module/${modulename}/parameters/. Some of these -parameters may be changed at runtime by the command -"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}". - - - ad1848= [HW,OSS] - Format: ,,,, - - aedsp16= [HW,OSS] Audio Excel DSP 16 - Format: ,,,,, - See also header of sound/oss/aedsp16.c. - - dmasound= [HW,OSS] Sound subsystem buffers - - mpu401= [HW,OSS] - Format: , - - opl3= [HW,OSS] - Format: - - pas2= [HW,OSS] Format: - ,,,,,,, - - pss= [HW,OSS] Personal Sound System (ECHO ESC614) - Format: - ,,,,, - - sscape= [HW,OSS] - Format: ,,,, - - trix= [HW,OSS] MediaTrix AudioTrix Pro - Format: - ,,,,,,,, - - uart401= [HW,OSS] - Format: , - - uart6850= [HW,OSS] - Format: , - - waveartist= [HW,OSS] - Format: ,,, diff --git a/Documentation/sound/oss/ultrasound b/Documentation/sound/oss/ultrasound deleted file mode 100644 index eed331c738a3..000000000000 --- a/Documentation/sound/oss/ultrasound +++ /dev/null @@ -1,30 +0,0 @@ -modprobe sound -insmod ad1848 -insmod gus io=* irq=* dma=* ... - -This loads the driver for the Gravis Ultrasound family of sound cards. - -The gus module takes the following arguments - -io I/O address of the Ultrasound card (eg. io=0x220) -irq IRQ of the Sound Blaster card -dma DMA channel for the Sound Blaster -dma16 2nd DMA channel, only needed for full duplex operation -type 1 for PnP card -gus16 1 for using 16 bit sampling daughter board -no_wave_dma Set to disable DMA usage for wavetable (see note) -db16 ??? - - -no_wave_dma option - -This option defaults to a value of 0, which allows the Ultrasound wavetable -DSP to use DMA for playback and downloading samples. This is the same -as the old behaviour. If set to 1, no DMA is needed for downloading samples, -and allows owners of a GUS MAX to make use of simultaneous digital audio -(/dev/dsp), MIDI, and wavetable playback. - - -If you have problems in recording with GUS MAX, you could try to use -just one 8 bit DMA channel. Recording will not work with one DMA -channel if it's a 16 bit one. -- cgit v1.2.3 From 707ce9eac5fc3b68f98c887dddea3911a8fc4f9f Mon Sep 17 00:00:00 2001 From: James Ban Date: Mon, 30 Oct 2017 11:32:38 +0900 Subject: regulator: da9211: update for supporting da9223/4/5 This is update for supporting additional devices da9223/4/5. Only device strings is added because only package type is different. Signed-off-by: James Ban Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/da9211.txt | 82 ++++++++++++++++++++-- 1 file changed, 75 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/da9211.txt b/Documentation/devicetree/bindings/regulator/da9211.txt index 0f2a6f8fcafd..27717e816e71 100644 --- a/Documentation/devicetree/bindings/regulator/da9211.txt +++ b/Documentation/devicetree/bindings/regulator/da9211.txt @@ -1,8 +1,9 @@ -* Dialog Semiconductor DA9211/DA9212/DA9213/DA9214/DA9215 Voltage Regulator +* Dialog Semiconductor DA9211/DA9212/DA9213/DA9223/DA9214/DA9224/DA9215/DA9225 + Voltage Regulator Required properties: -- compatible: "dlg,da9211" or "dlg,da9212" or "dlg,da9213" - or "dlg,da9214" or "dlg,da9215" +- compatible: "dlg,da9211" or "dlg,da9212" or "dlg,da9213" or "dlg,da9223" + or "dlg,da9214" or "dlg,da9224" or "dlg,da9215" or "dlg,da9225" - reg: I2C slave address, usually 0x68. - interrupts: the interrupt outputs of the controller - regulators: A node that houses a sub-node for each regulator within the @@ -16,7 +17,6 @@ Optional properties: - Any optional property defined in regulator.txt Example 1) DA9211 - pmic: da9211@68 { compatible = "dlg,da9211"; reg = <0x68>; @@ -35,7 +35,6 @@ Example 1) DA9211 }; Example 2) DA9212 - pmic: da9212@68 { compatible = "dlg,da9212"; reg = <0x68>; @@ -79,7 +78,25 @@ Example 3) DA9213 }; }; -Example 4) DA9214 +Example 4) DA9223 + pmic: da9223@68 { + compatible = "dlg,da9223"; + reg = <0x68>; + interrupts = <3 27>; + + regulators { + BUCKA { + regulator-name = "VBUCKA"; + regulator-min-microvolt = < 300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <3000000>; + regulator-max-microamp = <6000000>; + enable-gpios = <&gpio 27 0>; + }; + }; + }; + +Example 5) DA9214 pmic: da9214@68 { compatible = "dlg,da9214"; reg = <0x68>; @@ -105,7 +122,33 @@ Example 4) DA9214 }; }; -Example 5) DA9215 +Example 6) DA9224 + pmic: da9224@68 { + compatible = "dlg,da9224"; + reg = <0x68>; + interrupts = <3 27>; + + regulators { + BUCKA { + regulator-name = "VBUCKA"; + regulator-min-microvolt = < 300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <3000000>; + regulator-max-microamp = <6000000>; + enable-gpios = <&gpio 27 0>; + }; + BUCKB { + regulator-name = "VBUCKB"; + regulator-min-microvolt = < 300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <3000000>; + regulator-max-microamp = <6000000>; + enable-gpios = <&gpio 17 0>; + }; + }; + }; + +Example 7) DA9215 pmic: da9215@68 { compatible = "dlg,da9215"; reg = <0x68>; @@ -131,3 +174,28 @@ Example 5) DA9215 }; }; +Example 8) DA9225 + pmic: da9225@68 { + compatible = "dlg,da9225"; + reg = <0x68>; + interrupts = <3 27>; + + regulators { + BUCKA { + regulator-name = "VBUCKA"; + regulator-min-microvolt = < 300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <4000000>; + regulator-max-microamp = <7000000>; + enable-gpios = <&gpio 27 0>; + }; + BUCKB { + regulator-name = "VBUCKB"; + regulator-min-microvolt = < 300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <4000000>; + regulator-max-microamp = <7000000>; + enable-gpios = <&gpio 17 0>; + }; + }; + }; -- cgit v1.2.3 From 6981fbf3780366093858c5d2dcdaadcd1fbb04be Mon Sep 17 00:00:00 2001 From: Stephen Hemminger Date: Sun, 29 Oct 2017 11:33:40 -0700 Subject: Drivers: hv: vmbus: Expose per-channel interrupts and events counters When investigating performance, it is useful to be able to look at the number of host and guest events per-channel. This is equivalent to per-device interrupt statistics. Signed-off-by: Stephen Hemminger Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/stable/sysfs-bus-vmbus | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus b/Documentation/ABI/stable/sysfs-bus-vmbus index 0ebd8a1537a0..d4077cc60d55 100644 --- a/Documentation/ABI/stable/sysfs-bus-vmbus +++ b/Documentation/ABI/stable/sysfs-bus-vmbus @@ -61,39 +61,53 @@ Date: September. 2017 KernelVersion: 4.14 Contact: Stephen Hemminger Description: Inbound channel signaling state -Users: Debuggig tools +Users: Debugging tools What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/latency Date: September. 2017 KernelVersion: 4.14 Contact: Stephen Hemminger Description: Channel signaling latency -Users: Debuggig tools +Users: Debugging tools What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/out_mask Date: September. 2017 KernelVersion: 4.14 Contact: Stephen Hemminger Description: Outbound channel signaling state -Users: Debuggig tools +Users: Debugging tools What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/pending Date: September. 2017 KernelVersion: 4.14 Contact: Stephen Hemminger Description: Channel interrupt pending state -Users: Debuggig tools +Users: Debugging tools What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/read_avail Date: September. 2017 KernelVersion: 4.14 Contact: Stephen Hemminger Description: Bytes availabble to read -Users: Debuggig tools +Users: Debugging tools What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/write_avail Date: September. 2017 KernelVersion: 4.14 Contact: Stephen Hemminger Description: Bytes availabble to write -Users: Debuggig tools +Users: Debugging tools + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/events +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: Number of times we have signaled the host +Users: Debugging tools + +What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/interrupts +Date: September. 2017 +KernelVersion: 4.14 +Contact: Stephen Hemminger +Description: Number of times we have taken an interrupt (incoming) +Users: Debugging tools -- cgit v1.2.3 From 2bf209b8e28a5cf0a843d16005cfc7a432db888b Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Tue, 31 Oct 2017 09:19:08 +0100 Subject: dt-bindings: net: Restore sun8i dwmac binding The original dwmac-sun8i DT bindings have some issue on how to handle integrated PHY and was reverted in last RC of 4.13. But now we have a solution so we need to get back that was reverted. This patch restore dt-bindings documentation about dwmac-sun8i This reverts commit 8aa33ec2f481 ("dt-bindings: net: Revert sun8i dwmac binding") Signed-off-by: Corentin Labbe Acked-by: Rob Herring Acked-by: Florian Fainelli Signed-off-by: Maxime Ripard --- .../devicetree/bindings/net/dwmac-sun8i.txt | 84 ++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt new file mode 100644 index 000000000000..725f3b187886 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt @@ -0,0 +1,84 @@ +* Allwinner sun8i GMAC ethernet controller + +This device is a platform glue layer for stmmac. +Please see stmmac.txt for the other unchanged properties. + +Required properties: +- compatible: should be one of the following string: + "allwinner,sun8i-a83t-emac" + "allwinner,sun8i-h3-emac" + "allwinner,sun8i-v3s-emac" + "allwinner,sun50i-a64-emac" +- reg: address and length of the register for the device. +- interrupts: interrupt for the device +- interrupt-names: should be "macirq" +- clocks: A phandle to the reference clock for this device +- clock-names: should be "stmmaceth" +- resets: A phandle to the reset control for this device +- reset-names: should be "stmmaceth" +- phy-mode: See ethernet.txt +- phy-handle: See ethernet.txt +- #address-cells: shall be 1 +- #size-cells: shall be 0 +- syscon: A phandle to the syscon of the SoC with one of the following + compatible string: + - allwinner,sun8i-h3-system-controller + - allwinner,sun8i-v3s-system-controller + - allwinner,sun50i-a64-system-controller + - allwinner,sun8i-a83t-system-controller + +Optional properties: +- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0) +- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0) +Both delay properties need to be a multiple of 100. They control the delay for +external PHY. + +Optional properties for the following compatibles: + - "allwinner,sun8i-h3-emac", + - "allwinner,sun8i-v3s-emac": +- allwinner,leds-active-low: EPHY LEDs are active low + +Required child node of emac: +- mdio bus node: should be named mdio + +Required properties of the mdio node: +- #address-cells: shall be 1 +- #size-cells: shall be 0 + +The device node referenced by "phy" or "phy-handle" should be a child node +of the mdio node. See phy.txt for the generic PHY bindings. + +Required properties of the phy node with the following compatibles: + - "allwinner,sun8i-h3-emac", + - "allwinner,sun8i-v3s-emac": +- clocks: a phandle to the reference clock for the EPHY +- resets: a phandle to the reset control for the EPHY + +Example: + +emac: ethernet@1c0b000 { + compatible = "allwinner,sun8i-h3-emac"; + syscon = <&syscon>; + reg = <0x01c0b000 0x104>; + interrupts = ; + interrupt-names = "macirq"; + resets = <&ccu RST_BUS_EMAC>; + reset-names = "stmmaceth"; + clocks = <&ccu CLK_BUS_EMAC>; + clock-names = "stmmaceth"; + #address-cells = <1>; + #size-cells = <0>; + + phy-handle = <&int_mii_phy>; + phy-mode = "mii"; + allwinner,leds-active-low; + mdio: mdio { + #address-cells = <1>; + #size-cells = <0>; + int_mii_phy: ethernet-phy@1 { + reg = <1>; + clocks = <&ccu CLK_BUS_EPHY>; + resets = <&ccu RST_BUS_EPHY>; + }; + }; +}; -- cgit v1.2.3 From d5919dcc349d2a16d805ef8096d36e4f519e42ae Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 31 Oct 2017 18:26:15 +0100 Subject: Revert "PM / QoS: Fix device resume latency PM QoS" This reverts commit 0cc2b4e5a020 (PM / QoS: Fix device resume latency PM QoS) as it introduced regressions on multiple systems and the fix-up in commit 2a9a86d5c813 (PM / QoS: Fix default runtime_pm device resume latency) does not address all of them. The original problem that commit 0cc2b4e5a020 was attempting to fix will be addressed later. Fixes: 0cc2b4e5a020 (PM / QoS: Fix device resume latency PM QoS) Reported-by: Geert Uytterhoeven Signed-off-by: Rafael J. Wysocki --- Documentation/ABI/testing/sysfs-devices-power | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 5cbb6f038615..676fdf5f2a99 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -211,9 +211,7 @@ Description: device, after it has been suspended at run time, from a resume request to the moment the device will be ready to process I/O, in microseconds. If it is equal to 0, however, this means that - the PM QoS resume latency may be arbitrary and the special value - "n/a" means that user space cannot accept any resume latency at - all for the given device. + the PM QoS resume latency may be arbitrary. Not all drivers support this attribute. If it isn't supported, it is not present. -- cgit v1.2.3 From d65b34135ff86e8e04144ccdfcc2824127e0a7e8 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Tue, 29 Aug 2017 06:17:06 -0400 Subject: media: v4l: async: Add V4L2 async documentation to the documentation build MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The V4L2 async wasn't part of the documentation build. Fix this. Signed-off-by: Sakari Ailus Reviewed-by: Niklas Söderlund Acked-by: Hans Verkuil Reviewed-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-async.rst | 3 +++ Documentation/media/kapi/v4l2-core.rst | 1 + 2 files changed, 4 insertions(+) create mode 100644 Documentation/media/kapi/v4l2-async.rst (limited to 'Documentation') diff --git a/Documentation/media/kapi/v4l2-async.rst b/Documentation/media/kapi/v4l2-async.rst new file mode 100644 index 000000000000..523ff9eb09a0 --- /dev/null +++ b/Documentation/media/kapi/v4l2-async.rst @@ -0,0 +1,3 @@ +V4L2 async kAPI +^^^^^^^^^^^^^^^ +.. kernel-doc:: include/media/v4l2-async.h diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst index c7434f38fd9c..5cf292037a48 100644 --- a/Documentation/media/kapi/v4l2-core.rst +++ b/Documentation/media/kapi/v4l2-core.rst @@ -19,6 +19,7 @@ Video4Linux devices v4l2-mc v4l2-mediabus v4l2-mem2mem + v4l2-async v4l2-fwnode v4l2-rect v4l2-tuner -- cgit v1.2.3 From f4f864c1219cd88c01fd6359ffc870da9b4acf92 Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Sun, 29 Oct 2017 06:30:14 -0400 Subject: fscrypt: add a documentation file for filesystem-level encryption Perhaps long overdue, add a documentation file for filesystem-level encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation directory. The new file is based loosely on the latest version of the "EXT4 Encryption Design Document (public version)" Google Doc, but with many improvements made, including: - Reflect the reality that it is not specific to ext4 anymore. - More thoroughly document the design and user-visible API/behavior. - Replace outdated information, such as the outdated explanation of how encrypted filenames are hashed for indexed directories and how encrypted filenames are presented to userspace without the key. (This was changed just before release.) For now the focus is on the design and user-visible API/behavior, not on how to add encryption support to a filesystem --- since the internal API is still pretty messy and any standalone documentation for it would become outdated as things get refactored over time. Reviewed-by: Michael Halcrow Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o --- Documentation/filesystems/fscrypt.rst | 610 ++++++++++++++++++++++++++++++++++ Documentation/filesystems/index.rst | 11 + 2 files changed, 621 insertions(+) create mode 100644 Documentation/filesystems/fscrypt.rst (limited to 'Documentation') diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst new file mode 100644 index 000000000000..776ddc655f79 --- /dev/null +++ b/Documentation/filesystems/fscrypt.rst @@ -0,0 +1,610 @@ +===================================== +Filesystem-level encryption (fscrypt) +===================================== + +Introduction +============ + +fscrypt is a library which filesystems can hook into to support +transparent encryption of files and directories. + +Note: "fscrypt" in this document refers to the kernel-level portion, +implemented in ``fs/crypto/``, as opposed to the userspace tool +`fscrypt `_. This document only +covers the kernel-level portion. For command-line examples of how to +use encryption, see the documentation for the userspace tool `fscrypt +`_. Also, it is recommended to use +the fscrypt userspace tool, or other existing userspace tools such as +`fscryptctl `_ or `Android's key +management system +`_, over +using the kernel's API directly. Using existing tools reduces the +chance of introducing your own security bugs. (Nevertheless, for +completeness this documentation covers the kernel's API anyway.) + +Unlike dm-crypt, fscrypt operates at the filesystem level rather than +at the block device level. This allows it to encrypt different files +with different keys and to have unencrypted files on the same +filesystem. This is useful for multi-user systems where each user's +data-at-rest needs to be cryptographically isolated from the others. +However, except for filenames, fscrypt does not encrypt filesystem +metadata. + +Unlike eCryptfs, which is a stacked filesystem, fscrypt is integrated +directly into supported filesystems --- currently ext4, F2FS, and +UBIFS. This allows encrypted files to be read and written without +caching both the decrypted and encrypted pages in the pagecache, +thereby nearly halving the memory used and bringing it in line with +unencrypted files. Similarly, half as many dentries and inodes are +needed. eCryptfs also limits encrypted filenames to 143 bytes, +causing application compatibility issues; fscrypt allows the full 255 +bytes (NAME_MAX). Finally, unlike eCryptfs, the fscrypt API can be +used by unprivileged users, with no need to mount anything. + +fscrypt does not support encrypting files in-place. Instead, it +supports marking an empty directory as encrypted. Then, after +userspace provides the key, all regular files, directories, and +symbolic links created in that directory tree are transparently +encrypted. + +Threat model +============ + +Offline attacks +--------------- + +Provided that userspace chooses a strong encryption key, fscrypt +protects the confidentiality of file contents and filenames in the +event of a single point-in-time permanent offline compromise of the +block device content. fscrypt does not protect the confidentiality of +non-filename metadata, e.g. file sizes, file permissions, file +timestamps, and extended attributes. Also, the existence and location +of holes (unallocated blocks which logically contain all zeroes) in +files is not protected. + +fscrypt is not guaranteed to protect confidentiality or authenticity +if an attacker is able to manipulate the filesystem offline prior to +an authorized user later accessing the filesystem. + +Online attacks +-------------- + +fscrypt (and storage encryption in general) can only provide limited +protection, if any at all, against online attacks. In detail: + +fscrypt is only resistant to side-channel attacks, such as timing or +electromagnetic attacks, to the extent that the underlying Linux +Cryptographic API algorithms are. If a vulnerable algorithm is used, +such as a table-based implementation of AES, it may be possible for an +attacker to mount a side channel attack against the online system. +Side channel attacks may also be mounted against applications +consuming decrypted data. + +After an encryption key has been provided, fscrypt is not designed to +hide the plaintext file contents or filenames from other users on the +same system, regardless of the visibility of the keyring key. +Instead, existing access control mechanisms such as file mode bits, +POSIX ACLs, LSMs, or mount namespaces should be used for this purpose. +Also note that as long as the encryption keys are *anywhere* in +memory, an online attacker can necessarily compromise them by mounting +a physical attack or by exploiting any kernel security vulnerability +which provides an arbitrary memory read primitive. + +While it is ostensibly possible to "evict" keys from the system, +recently accessed encrypted files will remain accessible at least +until the filesystem is unmounted or the VFS caches are dropped, e.g. +using ``echo 2 > /proc/sys/vm/drop_caches``. Even after that, if the +RAM is compromised before being powered off, it will likely still be +possible to recover portions of the plaintext file contents, if not +some of the encryption keys as well. (Since Linux v4.12, all +in-kernel keys related to fscrypt are sanitized before being freed. +However, userspace would need to do its part as well.) + +Currently, fscrypt does not prevent a user from maliciously providing +an incorrect key for another user's existing encrypted files. A +protection against this is planned. + +Key hierarchy +============= + +Master Keys +----------- + +Each encrypted directory tree is protected by a *master key*. Master +keys can be up to 64 bytes long, and must be at least as long as the +greater of the key length needed by the contents and filenames +encryption modes being used. For example, if AES-256-XTS is used for +contents encryption, the master key must be 64 bytes (512 bits). Note +that the XTS mode is defined to require a key twice as long as that +required by the underlying block cipher. + +To "unlock" an encrypted directory tree, userspace must provide the +appropriate master key. There can be any number of master keys, each +of which protects any number of directory trees on any number of +filesystems. + +Userspace should generate master keys either using a cryptographically +secure random number generator, or by using a KDF (Key Derivation +Function). Note that whenever a KDF is used to "stretch" a +lower-entropy secret such as a passphrase, it is critical that a KDF +designed for this purpose be used, such as scrypt, PBKDF2, or Argon2. + +Per-file keys +------------- + +Master keys are not used to encrypt file contents or names directly. +Instead, a unique key is derived for each encrypted file, including +each regular file, directory, and symbolic link. This has several +advantages: + +- In cryptosystems, the same key material should never be used for + different purposes. Using the master key as both an XTS key for + contents encryption and as a CTS-CBC key for filenames encryption + would violate this rule. +- Per-file keys simplify the choice of IVs (Initialization Vectors) + for contents encryption. Without per-file keys, to ensure IV + uniqueness both the inode and logical block number would need to be + encoded in the IVs. This would make it impossible to renumber + inodes, which e.g. ``resize2fs`` can do when resizing an ext4 + filesystem. With per-file keys, it is sufficient to encode just the + logical block number in the IVs. +- Per-file keys strengthen the encryption of filenames, where IVs are + reused out of necessity. With a unique key per directory, IV reuse + is limited to within a single directory. +- Per-file keys allow individual files to be securely erased simply by + securely erasing their keys. (Not yet implemented.) + +A KDF (Key Derivation Function) is used to derive per-file keys from +the master key. This is done instead of wrapping a randomly-generated +key for each file because it reduces the size of the encryption xattr, +which for some filesystems makes the xattr more likely to fit in-line +in the filesystem's inode table. With a KDF, only a 16-byte nonce is +required --- long enough to make key reuse extremely unlikely. A +wrapped key, on the other hand, would need to be up to 64 bytes --- +the length of an AES-256-XTS key. Furthermore, currently there is no +requirement to support unlocking a file with multiple alternative +master keys or to support rotating master keys. Instead, the master +keys may be wrapped in userspace, e.g. as done by the `fscrypt +`_ tool. + +The current KDF encrypts the master key using the 16-byte nonce as an +AES-128-ECB key. The output is used as the derived key. If the +output is longer than needed, then it is truncated to the needed +length. Truncation is the norm for directories and symlinks, since +those use the CTS-CBC encryption mode which requires a key half as +long as that required by the XTS encryption mode. + +Note: this KDF meets the primary security requirement, which is to +produce unique derived keys that preserve the entropy of the master +key, assuming that the master key is already a good pseudorandom key. +However, it is nonstandard and has some problems such as being +reversible, so it is generally considered to be a mistake! It may be +replaced with HKDF or another more standard KDF in the future. + +Encryption modes and usage +========================== + +fscrypt allows one encryption mode to be specified for file contents +and one encryption mode to be specified for filenames. Different +directory trees are permitted to use different encryption modes. +Currently, the following pairs of encryption modes are supported: + +- AES-256-XTS for contents and AES-256-CTS-CBC for filenames +- AES-128-CBC for contents and AES-128-CTS-CBC for filenames + +It is strongly recommended to use AES-256-XTS for contents encryption. +AES-128-CBC was added only for low-powered embedded devices with +crypto accelerators such as CAAM or CESA that do not support XTS. + +New encryption modes can be added relatively easily, without changes +to individual filesystems. However, authenticated encryption (AE) +modes are not currently supported because of the difficulty of dealing +with ciphertext expansion. + +For file contents, each filesystem block is encrypted independently. +Currently, only the case where the filesystem block size is equal to +the system's page size (usually 4096 bytes) is supported. With the +XTS mode of operation (recommended), the logical block number within +the file is used as the IV. With the CBC mode of operation (not +recommended), ESSIV is used; specifically, the IV for CBC is the +logical block number encrypted with AES-256, where the AES-256 key is +the SHA-256 hash of the inode's data encryption key. + +For filenames, the full filename is encrypted at once. Because of the +requirements to retain support for efficient directory lookups and +filenames of up to 255 bytes, a constant initialization vector (IV) is +used. However, each encrypted directory uses a unique key, which +limits IV reuse to within a single directory. Note that IV reuse in +the context of CTS-CBC encryption means that when the original +filenames share a common prefix at least as long as the cipher block +size (16 bytes for AES), the corresponding encrypted filenames will +also share a common prefix. This is undesirable; it may be fixed in +the future by switching to an encryption mode that is a strong +pseudorandom permutation on arbitrary-length messages, e.g. the HEH +(Hash-Encrypt-Hash) mode. + +Since filenames are encrypted with the CTS-CBC mode of operation, the +plaintext and ciphertext filenames need not be multiples of the AES +block size, i.e. 16 bytes. However, the minimum size that can be +encrypted is 16 bytes, so shorter filenames are NUL-padded to 16 bytes +before being encrypted. In addition, to reduce leakage of filename +lengths via their ciphertexts, all filenames are NUL-padded to the +next 4, 8, 16, or 32-byte boundary (configurable). 32 is recommended +since this provides the best confidentiality, at the cost of making +directory entries consume slightly more space. Note that since NUL +(``\0``) is not otherwise a valid character in filenames, the padding +will never produce duplicate plaintexts. + +Symbolic link targets are considered a type of filename and are +encrypted in the same way as filenames in directory entries. Each +symlink also uses a unique key; hence, the hardcoded IV is not a +problem for symlinks. + +User API +======== + +Setting an encryption policy +---------------------------- + +The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an +empty directory or verifies that a directory or regular file already +has the specified encryption policy. It takes in a pointer to a +:c:type:`struct fscrypt_policy`, defined as follows:: + + #define FS_KEY_DESCRIPTOR_SIZE 8 + + struct fscrypt_policy { + __u8 version; + __u8 contents_encryption_mode; + __u8 filenames_encryption_mode; + __u8 flags; + __u8 master_key_descriptor[FS_KEY_DESCRIPTOR_SIZE]; + }; + +This structure must be initialized as follows: + +- ``version`` must be 0. + +- ``contents_encryption_mode`` and ``filenames_encryption_mode`` must + be set to constants from ```` which identify the + encryption modes to use. If unsure, use + FS_ENCRYPTION_MODE_AES_256_XTS (1) for ``contents_encryption_mode`` + and FS_ENCRYPTION_MODE_AES_256_CTS (4) for + ``filenames_encryption_mode``. + +- ``flags`` must be set to a value from ```` which + identifies the amount of NUL-padding to use when encrypting + filenames. If unsure, use FS_POLICY_FLAGS_PAD_32 (0x3). + +- ``master_key_descriptor`` specifies how to find the master key in + the keyring; see `Adding keys`_. It is up to userspace to choose a + unique ``master_key_descriptor`` for each master key. The e4crypt + and fscrypt tools use the first 8 bytes of + ``SHA-512(SHA-512(master_key))``, but this particular scheme is not + required. Also, the master key need not be in the keyring yet when + FS_IOC_SET_ENCRYPTION_POLICY is executed. However, it must be added + before any files can be created in the encrypted directory. + +If the file is not yet encrypted, then FS_IOC_SET_ENCRYPTION_POLICY +verifies that the file is an empty directory. If so, the specified +encryption policy is assigned to the directory, turning it into an +encrypted directory. After that, and after providing the +corresponding master key as described in `Adding keys`_, all regular +files, directories (recursively), and symlinks created in the +directory will be encrypted, inheriting the same encryption policy. +The filenames in the directory's entries will be encrypted as well. + +Alternatively, if the file is already encrypted, then +FS_IOC_SET_ENCRYPTION_POLICY validates that the specified encryption +policy exactly matches the actual one. If they match, then the ioctl +returns 0. Otherwise, it fails with EEXIST. This works on both +regular files and directories, including nonempty directories. + +Note that the ext4 filesystem does not allow the root directory to be +encrypted, even if it is empty. Users who want to encrypt an entire +filesystem with one key should consider using dm-crypt instead. + +FS_IOC_SET_ENCRYPTION_POLICY can fail with the following errors: + +- ``EACCES``: the file is not owned by the process's uid, nor does the + process have the CAP_FOWNER capability in a namespace with the file + owner's uid mapped +- ``EEXIST``: the file is already encrypted with an encryption policy + different from the one specified +- ``EINVAL``: an invalid encryption policy was specified (invalid + version, mode(s), or flags) +- ``ENOTDIR``: the file is unencrypted and is a regular file, not a + directory +- ``ENOTEMPTY``: the file is unencrypted and is a nonempty directory +- ``ENOTTY``: this type of filesystem does not implement encryption +- ``EOPNOTSUPP``: the kernel was not configured with encryption + support for this filesystem, or the filesystem superblock has not + had encryption enabled on it. (For example, to use encryption on an + ext4 filesystem, CONFIG_EXT4_ENCRYPTION must be enabled in the + kernel config, and the superblock must have had the "encrypt" + feature flag enabled using ``tune2fs -O encrypt`` or ``mkfs.ext4 -O + encrypt``.) +- ``EPERM``: this directory may not be encrypted, e.g. because it is + the root directory of an ext4 filesystem +- ``EROFS``: the filesystem is readonly + +Getting an encryption policy +---------------------------- + +The FS_IOC_GET_ENCRYPTION_POLICY ioctl retrieves the :c:type:`struct +fscrypt_policy`, if any, for a directory or regular file. See above +for the struct definition. No additional permissions are required +beyond the ability to open the file. + +FS_IOC_GET_ENCRYPTION_POLICY can fail with the following errors: + +- ``EINVAL``: the file is encrypted, but it uses an unrecognized + encryption context format +- ``ENODATA``: the file is not encrypted +- ``ENOTTY``: this type of filesystem does not implement encryption +- ``EOPNOTSUPP``: the kernel was not configured with encryption + support for this filesystem + +Note: if you only need to know whether a file is encrypted or not, on +most filesystems it is also possible to use the FS_IOC_GETFLAGS ioctl +and check for FS_ENCRYPT_FL, or to use the statx() system call and +check for STATX_ATTR_ENCRYPTED in stx_attributes. + +Getting the per-filesystem salt +------------------------------- + +Some filesystems, such as ext4 and F2FS, also support the deprecated +ioctl FS_IOC_GET_ENCRYPTION_PWSALT. This ioctl retrieves a randomly +generated 16-byte value stored in the filesystem superblock. This +value is intended to used as a salt when deriving an encryption key +from a passphrase or other low-entropy user credential. + +FS_IOC_GET_ENCRYPTION_PWSALT is deprecated. Instead, prefer to +generate and manage any needed salt(s) in userspace. + +Adding keys +----------- + +To provide a master key, userspace must add it to an appropriate +keyring using the add_key() system call (see: +``Documentation/security/keys/core.rst``). The key type must be +"logon"; keys of this type are kept in kernel memory and cannot be +read back by userspace. The key description must be "fscrypt:" +followed by the 16-character lower case hex representation of the +``master_key_descriptor`` that was set in the encryption policy. The +key payload must conform to the following structure:: + + #define FS_MAX_KEY_SIZE 64 + + struct fscrypt_key { + u32 mode; + u8 raw[FS_MAX_KEY_SIZE]; + u32 size; + }; + +``mode`` is ignored; just set it to 0. The actual key is provided in +``raw`` with ``size`` indicating its size in bytes. That is, the +bytes ``raw[0..size-1]`` (inclusive) are the actual key. + +The key description prefix "fscrypt:" may alternatively be replaced +with a filesystem-specific prefix such as "ext4:". However, the +filesystem-specific prefixes are deprecated and should not be used in +new programs. + +There are several different types of keyrings in which encryption keys +may be placed, such as a session keyring, a user session keyring, or a +user keyring. Each key must be placed in a keyring that is "attached" +to all processes that might need to access files encrypted with it, in +the sense that request_key() will find the key. Generally, if only +processes belonging to a specific user need to access a given +encrypted directory and no session keyring has been installed, then +that directory's key should be placed in that user's user session +keyring or user keyring. Otherwise, a session keyring should be +installed if needed, and the key should be linked into that session +keyring, or in a keyring linked into that session keyring. + +Note: introducing the complex visibility semantics of keyrings here +was arguably a mistake --- especially given that by design, after any +process successfully opens an encrypted file (thereby setting up the +per-file key), possessing the keyring key is not actually required for +any process to read/write the file until its in-memory inode is +evicted. In the future there probably should be a way to provide keys +directly to the filesystem instead, which would make the intended +semantics clearer. + +Access semantics +================ + +With the key +------------ + +With the encryption key, encrypted regular files, directories, and +symlinks behave very similarly to their unencrypted counterparts --- +after all, the encryption is intended to be transparent. However, +astute users may notice some differences in behavior: + +- Unencrypted files, or files encrypted with a different encryption + policy (i.e. different key, modes, or flags), cannot be renamed or + linked into an encrypted directory; see `Encryption policy + enforcement`_. Attempts to do so will fail with EPERM. However, + encrypted files can be renamed within an encrypted directory, or + into an unencrypted directory. + +- Direct I/O is not supported on encrypted files. Attempts to use + direct I/O on such files will fall back to buffered I/O. + +- The fallocate operations FALLOC_FL_COLLAPSE_RANGE, + FALLOC_FL_INSERT_RANGE, and FALLOC_FL_ZERO_RANGE are not supported + on encrypted files and will fail with EOPNOTSUPP. + +- Online defragmentation of encrypted files is not supported. The + EXT4_IOC_MOVE_EXT and F2FS_IOC_MOVE_RANGE ioctls will fail with + EOPNOTSUPP. + +- The ext4 filesystem does not support data journaling with encrypted + regular files. It will fall back to ordered data mode instead. + +- DAX (Direct Access) is not supported on encrypted files. + +- The st_size of an encrypted symlink will not necessarily give the + length of the symlink target as required by POSIX. It will actually + give the length of the ciphertext, which may be slightly longer than + the plaintext due to the NUL-padding. + +Note that mmap *is* supported. This is possible because the pagecache +for an encrypted file contains the plaintext, not the ciphertext. + +Without the key +--------------- + +Some filesystem operations may be performed on encrypted regular +files, directories, and symlinks even before their encryption key has +been provided: + +- File metadata may be read, e.g. using stat(). + +- Directories may be listed, in which case the filenames will be + listed in an encoded form derived from their ciphertext. The + current encoding algorithm is described in `Filename hashing and + encoding`_. The algorithm is subject to change, but it is + guaranteed that the presented filenames will be no longer than + NAME_MAX bytes, will not contain the ``/`` or ``\0`` characters, and + will uniquely identify directory entries. + + The ``.`` and ``..`` directory entries are special. They are always + present and are not encrypted or encoded. + +- Files may be deleted. That is, nondirectory files may be deleted + with unlink() as usual, and empty directories may be deleted with + rmdir() as usual. Therefore, ``rm`` and ``rm -r`` will work as + expected. + +- Symlink targets may be read and followed, but they will be presented + in encrypted form, similar to filenames in directories. Hence, they + are unlikely to point to anywhere useful. + +Without the key, regular files cannot be opened or truncated. +Attempts to do so will fail with ENOKEY. This implies that any +regular file operations that require a file descriptor, such as +read(), write(), mmap(), fallocate(), and ioctl(), are also forbidden. + +Also without the key, files of any type (including directories) cannot +be created or linked into an encrypted directory, nor can a name in an +encrypted directory be the source or target of a rename, nor can an +O_TMPFILE temporary file be created in an encrypted directory. All +such operations will fail with ENOKEY. + +It is not currently possible to backup and restore encrypted files +without the encryption key. This would require special APIs which +have not yet been implemented. + +Encryption policy enforcement +============================= + +After an encryption policy has been set on a directory, all regular +files, directories, and symbolic links created in that directory +(recursively) will inherit that encryption policy. Special files --- +that is, named pipes, device nodes, and UNIX domain sockets --- will +not be encrypted. + +Except for those special files, it is forbidden to have unencrypted +files, or files encrypted with a different encryption policy, in an +encrypted directory tree. Attempts to link or rename such a file into +an encrypted directory will fail with EPERM. This is also enforced +during ->lookup() to provide limited protection against offline +attacks that try to disable or downgrade encryption in known locations +where applications may later write sensitive data. It is recommended +that systems implementing a form of "verified boot" take advantage of +this by validating all top-level encryption policies prior to access. + +Implementation details +====================== + +Encryption context +------------------ + +An encryption policy is represented on-disk by a :c:type:`struct +fscrypt_context`. It is up to individual filesystems to decide where +to store it, but normally it would be stored in a hidden extended +attribute. It should *not* be exposed by the xattr-related system +calls such as getxattr() and setxattr() because of the special +semantics of the encryption xattr. (In particular, there would be +much confusion if an encryption policy were to be added to or removed +from anything other than an empty directory.) The struct is defined +as follows:: + + #define FS_KEY_DESCRIPTOR_SIZE 8 + #define FS_KEY_DERIVATION_NONCE_SIZE 16 + + struct fscrypt_context { + u8 format; + u8 contents_encryption_mode; + u8 filenames_encryption_mode; + u8 flags; + u8 master_key_descriptor[FS_KEY_DESCRIPTOR_SIZE]; + u8 nonce[FS_KEY_DERIVATION_NONCE_SIZE]; + }; + +Note that :c:type:`struct fscrypt_context` contains the same +information as :c:type:`struct fscrypt_policy` (see `Setting an +encryption policy`_), except that :c:type:`struct fscrypt_context` +also contains a nonce. The nonce is randomly generated by the kernel +and is used to derive the inode's encryption key as described in +`Per-file keys`_. + +Data path changes +----------------- + +For the read path (->readpage()) of regular files, filesystems can +read the ciphertext into the page cache and decrypt it in-place. The +page lock must be held until decryption has finished, to prevent the +page from becoming visible to userspace prematurely. + +For the write path (->writepage()) of regular files, filesystems +cannot encrypt data in-place in the page cache, since the cached +plaintext must be preserved. Instead, filesystems must encrypt into a +temporary buffer or "bounce page", then write out the temporary +buffer. Some filesystems, such as UBIFS, already use temporary +buffers regardless of encryption. Other filesystems, such as ext4 and +F2FS, have to allocate bounce pages specially for encryption. + +Filename hashing and encoding +----------------------------- + +Modern filesystems accelerate directory lookups by using indexed +directories. An indexed directory is organized as a tree keyed by +filename hashes. When a ->lookup() is requested, the filesystem +normally hashes the filename being looked up so that it can quickly +find the corresponding directory entry, if any. + +With encryption, lookups must be supported and efficient both with and +without the encryption key. Clearly, it would not work to hash the +plaintext filenames, since the plaintext filenames are unavailable +without the key. (Hashing the plaintext filenames would also make it +impossible for the filesystem's fsck tool to optimize encrypted +directories.) Instead, filesystems hash the ciphertext filenames, +i.e. the bytes actually stored on-disk in the directory entries. When +asked to do a ->lookup() with the key, the filesystem just encrypts +the user-supplied name to get the ciphertext. + +Lookups without the key are more complicated. The raw ciphertext may +contain the ``\0`` and ``/`` characters, which are illegal in +filenames. Therefore, readdir() must base64-encode the ciphertext for +presentation. For most filenames, this works fine; on ->lookup(), the +filesystem just base64-decodes the user-supplied name to get back to +the raw ciphertext. + +However, for very long filenames, base64 encoding would cause the +filename length to exceed NAME_MAX. To prevent this, readdir() +actually presents long filenames in an abbreviated form which encodes +a strong "hash" of the ciphertext filename, along with the optional +filesystem-specific hash(es) needed for directory lookups. This +allows the filesystem to still, with a high degree of confidence, map +the filename given in ->lookup() back to a particular directory entry +that was previously listed by readdir(). See :c:type:`struct +fscrypt_digested_name` in the source for more details. + +Note that the precise way that filenames are presented to userspace +without the key is subject to change in the future. It is only meant +as a way to temporarily present valid filenames so that commands like +``rm -r`` work as expected on encrypted directories. diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index 256e10eedba4..53b89d0edc15 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -315,3 +315,14 @@ exported for use by modules. :internal: .. kernel-doc:: fs/pipe.c + +Encryption API +============== + +A library which filesystems can hook into to support transparent +encryption of files and directories. + +.. toctree:: + :maxdepth: 2 + + fscrypt -- cgit v1.2.3 From 26baf6dd63ddd2808561926cae6ecf16f56de38c Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Fri, 3 Mar 2017 13:14:02 -0500 Subject: media: dt: bindings: Add a binding for flash LED devices associated to a sensor Camera flash drivers (and LEDs) are separate from the sensor devices in DT. In order to make an association between the two, provide the association information to the software. Signed-off-by: Sakari Ailus Cc: devicetree@vger.kernel.org Acked-by: Hans Verkuil Acked-by: Pavel Machek Acked-by: Rob Herring Reviewed-by: Sebastian Reichel Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/video-interfaces.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index bd6474920510..dc66e3224692 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -76,6 +76,14 @@ are required in a relevant parent node: identifier, should be 1. - #size-cells : should be zero. + +Optional properties +------------------- + +- flash-leds: An array of phandles, each referring to a flash LED, a sub-node + of the LED driver device node. + + Optional endpoint properties ---------------------------- -- cgit v1.2.3 From 95293f79d53995142ed1f66be70216a6cbfc36f4 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Fri, 3 Mar 2017 17:07:51 -0500 Subject: media: dt: bindings: Add lens-focus binding for image sensors The lens-focus property contains a phandle to the lens voice coil driver that is associated to the sensor; typically both are contained in the same camera module. Signed-off-by: Sakari Ailus Cc: devicetree@vger.kernel.org Acked-by: Pavel Machek Reviewed-by: Sebastian Reichel Acked-by: Rob Herring Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index dc66e3224692..3994b0143dd1 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -83,6 +83,8 @@ Optional properties - flash-leds: An array of phandles, each referring to a flash LED, a sub-node of the LED driver device node. +- lens-focus: A phandle to the node of the focus lens controller. + Optional endpoint properties ---------------------------- -- cgit v1.2.3 From e4219f9f9c98ae28874c2b7390a561a2a77e6f64 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Sun, 3 Sep 2017 15:41:53 -0400 Subject: media: dt: bindings: smiapp: Document lens-focus and flash-leds properties Document optional lens-focus and flash-leds properties for the smiapp driver. Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Acked-by: Pavel Machek Acked-by: Rob Herring Reviewed-by: Sebastian Reichel Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/i2c/nokia,smia.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt index 855e1faf73e2..33f10a94c381 100644 --- a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt +++ b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt @@ -27,6 +27,8 @@ Optional properties - nokia,nvm-size: The size of the NVM, in bytes. If the size is not given, the NVM contents will not be read. - reset-gpios: XSHUTDOWN GPIO +- flash-leds: See ../video-interfaces.txt +- lens-focus: See ../video-interfaces.txt Endpoint node mandatory properties -- cgit v1.2.3 From 1027d759c9517a255f663d4365d98d78d8680b20 Mon Sep 17 00:00:00 2001 From: Rocky Hao Date: Thu, 24 Aug 2017 18:27:51 +0800 Subject: dt-bindings: rockchip-thermal: Support the RV1108 SoC compatible Add a new compatible for thermal founding on RV1108 SoCs. Acked-by: Rob Herring Signed-off-by: Rocky Hao Signed-off-by: Eduardo Valentin --- Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index e3a6234fb1ac..43d744e5305e 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,-tsadc" + "rockchip,rv1108-tsadc": found on RV1108 SoCs "rockchip,rk3228-tsadc": found on RK3228 SoCs "rockchip,rk3288-tsadc": found on RK3288 SoCs "rockchip,rk3328-tsadc": found on RK3328 SoCs -- cgit v1.2.3 From b590c51c9b956f465acc73a2864d3a1444c76c3b Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 26 Sep 2017 14:27:58 -0700 Subject: Documentation: devicetree: add binding for Broadcom STB AVS TMON Add binding for Broadcom STB thermal. Signed-off-by: Brian Norris Acked-by: Rob Herring Signed-off-by: Markus Mayer Signed-off-by: Eduardo Valentin --- .../devicetree/bindings/thermal/brcm,avs-tmon.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt new file mode 100644 index 000000000000..9d43553a8d39 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt @@ -0,0 +1,20 @@ +* Broadcom STB thermal management + +Thermal management core, provided by the AVS TMON hardware block. + +Required properties: +- compatible: must be "brcm,avs-tmon" and/or "brcm,avs-tmon-bcm7445" +- reg: address range for the AVS TMON registers +- interrupts: temperature monitor interrupt, for high/low threshold triggers +- interrupt-names: should be "tmon" +- interrupt-parent: the parent interrupt controller + +Example: + + thermal@f04d1500 { + compatible = "brcm,avs-tmon-bcm7445", "brcm,avs-tmon"; + reg = <0xf04d1500 0x28>; + interrupts = <0x6>; + interrupt-names = "tmon"; + interrupt-parent = <&avs_host_l2_intc>; + }; -- cgit v1.2.3 From 9f17ceaa01133e9a67fd796617446e9499570e3d Mon Sep 17 00:00:00 2001 From: Baolin Wang Date: Wed, 1 Nov 2017 10:32:07 +0800 Subject: dt-bindings: mfd: Add Spreadtrum SC27xx PMIC documentation This patch adds the binding documentation for Spreadtrum SC27xx series PMIC device. Signed-off-by: Baolin Wang Acked-by: Rob Herring Acked-by: Lee Jones Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/sprd,sc27xx-pmic.txt | 40 ++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/sprd,sc27xx-pmic.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/sprd,sc27xx-pmic.txt b/Documentation/devicetree/bindings/mfd/sprd,sc27xx-pmic.txt new file mode 100644 index 000000000000..21b9a897fca5 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/sprd,sc27xx-pmic.txt @@ -0,0 +1,40 @@ +Spreadtrum SC27xx Power Management Integrated Circuit (PMIC) + +The Spreadtrum SC27xx series PMICs contain SC2720, SC2721, SC2723, SC2730 +and SC2731. The Spreadtrum PMIC belonging to SC27xx series integrates all +mobile handset power management, audio codec, battery management and user +interface support function in a single chip. It has 6 major functional +blocks: +- DCDCs to support CPU, memory. +- LDOs to support both internal and external requirement. +- Battery management system, such as charger, fuel gauge. +- Audio codec. +- User interface function, such as indicator, flash LED and so on. +- IC level interface, such as power on/off control, RTC and typec and so on. + +Required properties: +- compatible: Should be one of the following: + "sprd,sc2720" + "sprd,sc2721" + "sprd,sc2723" + "sprd,sc2730" + "sprd,sc2731" +- reg: The address of the device chip select, should be 0. +- spi-max-frequency: Typically set to 26000000. +- interrupts: The interrupt line the device is connected to. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: The number of cells to describe an PMIC IRQ, must be 2. +- #address-cells: Child device offset number of cells, must be 1. +- #size-cells: Child device size number of cells, must be 0. + +Example: +pmic@0 { + compatible = "sprd,sc2731"; + reg = <0>; + spi-max-frequency = <26000000>; + interrupts = ; + interrupt-controller; + #interrupt-cells = <2>; + #address-cells = <1>; + #size-cells = <0>; +}; -- cgit v1.2.3 From 2e39748a4231a893f057567e9b880ab34ea47aef Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov Date: Mon, 30 Oct 2017 19:39:56 -0700 Subject: bpf: document answers to common questions about BPF to address common misconceptions about what BPF is and what it's not add short BPF Q&A that clarifies core BPF design principles and answers some common questions. Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Jakub Kicinski Signed-off-by: David S. Miller --- Documentation/bpf/bpf_design_QA.txt | 156 ++++++++++++++++++++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 Documentation/bpf/bpf_design_QA.txt (limited to 'Documentation') diff --git a/Documentation/bpf/bpf_design_QA.txt b/Documentation/bpf/bpf_design_QA.txt new file mode 100644 index 000000000000..f3e458a0bb2f --- /dev/null +++ b/Documentation/bpf/bpf_design_QA.txt @@ -0,0 +1,156 @@ +BPF extensibility and applicability to networking, tracing, security +in the linux kernel and several user space implementations of BPF +virtual machine led to a number of misunderstanding on what BPF actually is. +This short QA is an attempt to address that and outline a direction +of where BPF is heading long term. + +Q: Is BPF a generic instruction set similar to x64 and arm64? +A: NO. + +Q: Is BPF a generic virtual machine ? +A: NO. + +BPF is generic instruction set _with_ C calling convention. + +Q: Why C calling convention was chosen? +A: Because BPF programs are designed to run in the linux kernel + which is written in C, hence BPF defines instruction set compatible + with two most used architectures x64 and arm64 (and takes into + consideration important quirks of other architectures) and + defines calling convention that is compatible with C calling + convention of the linux kernel on those architectures. + +Q: can multiple return values be supported in the future? +A: NO. BPF allows only register R0 to be used as return value. + +Q: can more than 5 function arguments be supported in the future? +A: NO. BPF calling convention only allows registers R1-R5 to be used + as arguments. BPF is not a standalone instruction set. + (unlike x64 ISA that allows msft, cdecl and other conventions) + +Q: can BPF programs access instruction pointer or return address? +A: NO. + +Q: can BPF programs access stack pointer ? +A: NO. Only frame pointer (register R10) is accessible. + From compiler point of view it's necessary to have stack pointer. + For example LLVM defines register R11 as stack pointer in its + BPF backend, but it makes sure that generated code never uses it. + +Q: Does C-calling convention diminishes possible use cases? +A: YES. BPF design forces addition of major functionality in the form + of kernel helper functions and kernel objects like BPF maps with + seamless interoperability between them. It lets kernel call into + BPF programs and programs call kernel helpers with zero overhead. + As all of them were native C code. That is particularly the case + for JITed BPF programs that are indistinguishable from + native kernel C code. + +Q: Does it mean that 'innovative' extensions to BPF code are disallowed? +A: Soft yes. At least for now until BPF core has support for + bpf-to-bpf calls, indirect calls, loops, global variables, + jump tables, read only sections and all other normal constructs + that C code can produce. + +Q: Can loops be supported in a safe way? +A: It's not clear yet. BPF developers are trying to find a way to + support bounded loops where the verifier can guarantee that + the program terminates in less than 4096 instructions. + +Q: How come LD_ABS and LD_IND instruction are present in BPF whereas + C code cannot express them and has to use builtin intrinsics? +A: This is artifact of compatibility with classic BPF. Modern + networking code in BPF performs better without them. + See 'direct packet access'. + +Q: It seems not all BPF instructions are one-to-one to native CPU. + For example why BPF_JNE and other compare and jumps are not cpu-like? +A: This was necessary to avoid introducing flags into ISA which are + impossible to make generic and efficient across CPU architectures. + +Q: why BPF_DIV instruction doesn't map to x64 div? +A: Because if we picked one-to-one relationship to x64 it would have made + it more complicated to support on arm64 and other archs. Also it + needs div-by-zero runtime check. + +Q: why there is no BPF_SDIV for signed divide operation? +A: Because it would be rarely used. llvm errors in such case and + prints a suggestion to use unsigned divide instead + +Q: Why BPF has implicit prologue and epilogue? +A: Because architectures like sparc have register windows and in general + there are enough subtle differences between architectures, so naive + store return address into stack won't work. Another reason is BPF has + to be safe from division by zero (and legacy exception path + of LD_ABS insn). Those instructions need to invoke epilogue and + return implicitly. + +Q: Why BPF_JLT and BPF_JLE instructions were not introduced in the beginning? +A: Because classic BPF didn't have them and BPF authors felt that compiler + workaround would be acceptable. Turned out that programs lose performance + due to lack of these compare instructions and they were added. + These two instructions is a perfect example what kind of new BPF + instructions are acceptable and can be added in the future. + These two already had equivalent instructions in native CPUs. + New instructions that don't have one-to-one mapping to HW instructions + will not be accepted. + +Q: BPF 32-bit subregisters have a requirement to zero upper 32-bits of BPF + registers which makes BPF inefficient virtual machine for 32-bit + CPU architectures and 32-bit HW accelerators. Can true 32-bit registers + be added to BPF in the future? +A: NO. The first thing to improve performance on 32-bit archs is to teach + LLVM to generate code that uses 32-bit subregisters. Then second step + is to teach verifier to mark operations where zero-ing upper bits + is unnecessary. Then JITs can take advantage of those markings and + drastically reduce size of generated code and improve performance. + +Q: Does BPF have a stable ABI? +A: YES. BPF instructions, arguments to BPF programs, set of helper + functions and their arguments, recognized return codes are all part + of ABI. However when tracing programs are using bpf_probe_read() helper + to walk kernel internal datastructures and compile with kernel + internal headers these accesses can and will break with newer + kernels. The union bpf_attr -> kern_version is checked at load time + to prevent accidentally loading kprobe-based bpf programs written + for a different kernel. Networking programs don't do kern_version check. + +Q: How much stack space a BPF program uses? +A: Currently all program types are limited to 512 bytes of stack + space, but the verifier computes the actual amount of stack used + and both interpreter and most JITed code consume necessary amount. + +Q: Can BPF be offloaded to HW? +A: YES. BPF HW offload is supported by NFP driver. + +Q: Does classic BPF interpreter still exist? +A: NO. Classic BPF programs are converted into extend BPF instructions. + +Q: Can BPF call arbitrary kernel functions? +A: NO. BPF programs can only call a set of helper functions which + is defined for every program type. + +Q: Can BPF overwrite arbitrary kernel memory? +A: NO. Tracing bpf programs can _read_ arbitrary memory with bpf_probe_read() + and bpf_probe_read_str() helpers. Networking programs cannot read + arbitrary memory, since they don't have access to these helpers. + Programs can never read or write arbitrary memory directly. + +Q: Can BPF overwrite arbitrary user memory? +A: Sort-of. Tracing BPF programs can overwrite the user memory + of the current task with bpf_probe_write_user(). Every time such + program is loaded the kernel will print warning message, so + this helper is only useful for experiments and prototypes. + Tracing BPF programs are root only. + +Q: When bpf_trace_printk() helper is used the kernel prints nasty + warning message. Why is that? +A: This is done to nudge program authors into better interfaces when + programs need to pass data to user space. Like bpf_perf_event_output() + can be used to efficiently stream data via perf ring buffer. + BPF maps can be used for asynchronous data sharing between kernel + and user space. bpf_trace_printk() should only be used for debugging. + +Q: Can BPF functionality such as new program or map types, new + helpers, etc be added out of kernel module code? +A: NO. -- cgit v1.2.3 From 9b796ffcd16dfaf820ecc6a9dc287e6d758a556e Mon Sep 17 00:00:00 2001 From: Jules Maselbas Date: Tue, 31 Oct 2017 11:32:57 +0100 Subject: dt-bindings: usb: max3421: Interrupt-parent is optional Documentation modification, now interrupt-parent is an optional property. Also fix few typos. Signed-off-by: Jules Maselbas Reported-by: Sergei Shtylyov Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/maxim,max3421.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/maxim,max3421.txt b/Documentation/devicetree/bindings/usb/maxim,max3421.txt index 7536c3ab3e5a..8cdbe0c85188 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max3421.txt +++ b/Documentation/devicetree/bindings/usb/maxim,max3421.txt @@ -1,17 +1,19 @@ Maxim Integrated SPI-based USB 2.0 host controller MAX3421E Required properties: - - compatible: "maxim,max3421" + - compatible: Should be "maxim,max3421" - spi-max-frequency: maximum frequency for this device must not exceed 26 MHz. - reg: chip select number to which this device is connected. - maxim,vbus-en-pin: GPOUTx is the number (1-8) of the GPOUT pin of MAX3421E to drive Vbus. ACTIVE_LEVEL is 0 or 1. - - interrupt-parent: the phandle of the associated interrupt controller. - - interrupts: the interuption line description for the interrupt controller. + - interrupts: the interrupt line description for the interrupt controller. The driver configures MAX3421E for active low level triggered interrupts, configure your interrupt line accordingly. +Optional property: + - interrupt-parent: the phandle to the associated interrupt controller. + Example: usb@0 { -- cgit v1.2.3 From a8a5267756c32308681a1c9a42bd8079a76ff4a4 Mon Sep 17 00:00:00 2001 From: Serge Semin Date: Sun, 22 Oct 2017 23:38:03 +0300 Subject: usb: usb251xb: Update usb251xb bindings Since hub usb2517 is going to be supported by the usb251xb driver, the bindings need to be properly updated. Particularly: - add "microchip,usb2517" and "microchip,usb2517i" compatible strings. - add "boolean" description to all the properties, which really accept a boolean value including a new one "led-{usb,speed}-mode". - move reset-gpios property to the optional section. It isn't defined as required in the code and shouldn't be required at all, since hardware may handle reset pins by itself. - add new led-{usb,speed}-mode mode property. USB2517 device supports two LED modes: USB mode and speed (default) indication mode. The last one can be switched on by this property. - add {bp,sp}-max-{total,removable}-current-microamp property measured in microamp. It hasn't been defined as property before. Since the limitation specified by these parameters is hardware specific it needs to be defined in dts. Signed-off-by: Serge Semin Acked-by: Rob Herring Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb251xb.txt | 46 +++++++++++++++------- 1 file changed, 32 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt b/Documentation/devicetree/bindings/usb/usb251xb.txt index 3957d4edaa74..168ff819e827 100644 --- a/Documentation/devicetree/bindings/usb/usb251xb.txt +++ b/Documentation/devicetree/bindings/usb/usb251xb.txt @@ -1,16 +1,17 @@ Microchip USB 2.0 Hi-Speed Hub Controller -The device node for the configuration of a Microchip USB251xB/xBi USB 2.0 +The device node for the configuration of a Microchip USB251x/xBi USB 2.0 Hi-Speed Controller. Required properties : - compatible : Should be "microchip,usb251xb" or one of the specific types: "microchip,usb2512b", "microchip,usb2512bi", "microchip,usb2513b", - "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi" - - reset-gpios : Should specify the gpio for hub reset + "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi", + "microchip,usb2517", "microchip,usb2517i" - reg : I2C address on the selected bus (default is <0x2C>) Optional properties : + - reset-gpios : Should specify the gpio for hub reset - skip-config : Skip Hub configuration, but only send the USB-Attach command - vendor-id : Set USB Vendor ID of the hub (16 bit, default is 0x0424) - product-id : Set USB Product ID of the hub (16 bit, default depends on type) @@ -19,29 +20,47 @@ Optional properties : - manufacturer : Set USB Manufacturer string (max 31 characters long) - product : Set USB Product string (max 31 characters long) - serial : Set USB Serial string (max 31 characters long) - - {bus,self}-powered : selects between self- and bus-powered operation (default - is self-powered) - - disable-hi-speed : disable USB Hi-Speed support + - {bus,self}-powered : selects between self- and bus-powered operation + (boolean, default is self-powered) + - disable-hi-speed : disable USB Hi-Speed support (boolean) - {multi,single}-tt : selects between multi- and single-transaction-translator - (default is multi-tt) - - disable-eop : disable End of Packet generation in full-speed mode + (boolean, default is multi-tt) + - disable-eop : disable End of Packet generation in full-speed mode (boolean) - {ganged,individual}-sensing : select over-current sense type in self-powered - mode (default is individual) + mode (boolean, default is individual) - {ganged,individual}-port-switching : select port power switching mode - (default is individual) + (boolean, default is individual) - dynamic-power-switching : enable auto-switching from self- to bus-powered - operation if the local power source is removed or unavailable + operation if the local power source is removed or unavailable (boolean) - oc-delay-us : Delay time (in microseconds) for filtering the over-current sense inputs. Valid values are 100, 4000, 8000 (default) and 16000. If an invalid value is given, the default is used instead. - - compound-device : indicate the hub is part of a compound device - - port-mapping-mode : enable port mapping mode + - compound-device : indicate the hub is part of a compound device (boolean) + - port-mapping-mode : enable port mapping mode (boolean) + - led-{usb,speed}-mode : led usb/speed indication mode selection + (boolean, default is speed mode) - string-support : enable string descriptor support (required for manufacturer, product and serial string configuration) - non-removable-ports : Should specify the ports which have a non-removable device connected. - sp-disabled-ports : Specifies the ports which will be self-power disabled - bp-disabled-ports : Specifies the ports which will be bus-power disabled + - sp-max-total-current-microamp: Specifies max current consumed by the hub + from VBUS when operating in self-powered hub. It includes the hub + silicon along with all associated circuitry including a permanently + attached peripheral (range: 0 - 100000 uA, default 1000 uA) + - bp-max-total-current-microamp: Specifies max current consumed by the hub + from VBUS when operating in self-powered hub. It includes the hub + silicon along with all associated circuitry including a permanently + attached peripheral (range: 0 - 510000 uA, default 100000 uA) + - sp-max-removable-current-microamp: Specifies max current consumed by the hub + from VBUS when operating in self-powered hub. It includes the hub + silicon along with all associated circuitry excluding a permanently + attached peripheral (range: 0 - 100000 uA, default 1000 uA) + - bp-max-removable-current-microamp: Specifies max current consumed by the hub + from VBUS when operating in self-powered hub. It includes the hub + silicon along with all associated circuitry excluding a permanently + attached peripheral (range: 0 - 510000 uA, default 100000 uA) - power-on-time-ms : Specifies the time it takes from the time the host initiates the power-on sequence to a port until the port has adequate power. The value is given in ms in a 0 - 510 range (default is 100ms). @@ -56,7 +75,6 @@ Examples: usb2514b@2c { compatible = "microchip,usb2514b"; reg = <0x2c>; - reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>; vendor-id = /bits/ 16 <0x0000>; product-id = /bits/ 16 <0x0000>; string-support; -- cgit v1.2.3 From efb5b43a5410fefa0516691af8e73f255260f598 Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl Date: Sun, 29 Oct 2017 14:25:48 +0100 Subject: dt-bindings: add vendor prefix for Next Thing Co. Next Thing Co. is the company behind the C.H.I.P. and C.H.I.P. Pro miniature single board computers. The "nextthing" vendor-prefix is already used for these two board as well as their own "GR8" SoC. Cc: Alexander Kaplan Signed-off-by: Martin Blumenstingl Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 01500f2a399b..b2c1b8d80367 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -230,6 +230,7 @@ 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 -- cgit v1.2.3 From f0e230ad877855567607fe2f40802b6317ad38f3 Mon Sep 17 00:00:00 2001 From: Guoqing Jiang Date: Tue, 24 Oct 2017 15:11:53 +0800 Subject: md-cluster: update document for raid10 Signed-off-by: Guoqing Jiang Signed-off-by: Shaohua Li --- Documentation/md/md-cluster.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/md/md-cluster.txt b/Documentation/md/md-cluster.txt index 82ee51604e9a..e1055f105cf5 100644 --- a/Documentation/md/md-cluster.txt +++ b/Documentation/md/md-cluster.txt @@ -1,4 +1,5 @@ -The cluster MD is a shared-device RAID for a cluster. +The cluster MD is a shared-device RAID for a cluster, it supports +two levels: raid1 and raid10 (limited support). 1. On-disk format -- cgit v1.2.3 From aa795c41d9cd41dc9c915dd1956ddd0e4ae44485 Mon Sep 17 00:00:00 2001 From: Stephen Boyd Date: Fri, 1 Sep 2017 16:16:40 -0700 Subject: clk: Add devm_of_clk_add_hw_provider()/del_provider() APIs Sometimes we only have one of_clk_del_provider() call in driver error and remove paths, because we're missing a devm_of_clk_add_hw_provider() API. Introduce the API so we can convert drivers to use this and potentially reduce the amount of code needed to remove providers in drivers. Signed-off-by: Stephen Boyd --- Documentation/driver-model/devres.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 69f08c0f23a8..c180045eb43b 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -237,6 +237,7 @@ CLOCK devm_clk_get() devm_clk_put() devm_clk_hw_register() + devm_of_clk_add_hw_provider() DMA dmam_alloc_coherent() -- cgit v1.2.3 From 5e70ca8753c8d9749d206a4fdb14f22a6ba1d893 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 13 Oct 2017 13:26:35 +0200 Subject: clk: qcom: Elaborate on "active" clocks in the RPM clock bindings The concept of "active" clocks is just explained in a bried comment in the device driver, let's explain it a bit more in the device tree bindings so everyone understands this. Cc: devicetree@vger.kernel.org Acked-by: Rob Herring Signed-off-by: Linus Walleij Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt index a7235e9e1c97..32c6e9ce64c3 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -16,6 +16,14 @@ Required properties : - #clock-cells : shall contain 1 +The clock enumerators are defined in +and come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock +is an "active" clock, which means that the consumer only care that the +clock is available when the apps CPU subsystem is active, i.e. not +suspended or in deep idle. If it is important that the clock keeps running +during system suspend, you need to specify the non-active clock, the one +not containing *_A_* in the enumerator name. + Example: smd { compatible = "qcom,smd"; -- cgit v1.2.3 From 856e6bb91e198c4fb0ca2f4f3ee0e7f660b3e0ca Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 13 Oct 2017 13:59:16 +0200 Subject: clk: qcom: Update DT bindings for the MSM8660/APQ8060 RPMCC These compatible strings need to be added to extend support for the RPM CC to cover MSM8660/APQ8060. We also need to add enumberators to the include file for a few clocks that were missing. Cc: devicetree@vger.kernel.org Acked-by: Rob Herring Signed-off-by: Linus Walleij Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt index 32c6e9ce64c3..833a89f06ae0 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -10,6 +10,8 @@ Required properties : - compatible : shall contain only one of the following. The generic compatible "qcom,rpmcc" should be also included. + "qcom,rpmcc-msm8660", "qcom,rpmcc" + "qcom,rpmcc-apq8060", "qcom,rpmcc" "qcom,rpmcc-msm8916", "qcom,rpmcc" "qcom,rpmcc-msm8974", "qcom,rpmcc" "qcom,rpmcc-apq8064", "qcom,rpmcc" -- cgit v1.2.3 From 7066fdd0d7427f1ba455d186e75213c442c9663b Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Tue, 10 Oct 2017 14:27:13 +0530 Subject: clk: qcom: clk-smd-rpm: add msm8996 rpmclks Add all RPM controlled clocks on msm8996 platform [srini: Fixed various issues with offsets and made names specific to msm8996] Signed-off-by: Srinivas Kandagatla Signed-off-by: Rajendra Nayak Acked-by: Rob Herring Acked-by: Bjorn Andersson Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt index 833a89f06ae0..4491d1c104aa 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -15,6 +15,7 @@ Required properties : "qcom,rpmcc-msm8916", "qcom,rpmcc" "qcom,rpmcc-msm8974", "qcom,rpmcc" "qcom,rpmcc-apq8064", "qcom,rpmcc" + "qcom,rpmcc-msm8996", "qcom,rpmcc" - #clock-cells : shall contain 1 -- cgit v1.2.3 From eb522df40e41915210856f1d654e0c31650cb526 Mon Sep 17 00:00:00 2001 From: "weiyi.lu@mediatek.com" Date: Mon, 23 Oct 2017 12:10:32 +0800 Subject: dt-bindings: ARM: Mediatek: Document bindings for MT2712 This patch adds the binding documentation for apmixedsys, bdpsys, imgsys, imgsys, infracfg, mcucfg, mfgcfg, mmsys, pericfg, topckgen, vdecsys and vencsys for Mediatek MT2712. Acked-by: Rob Herring Signed-off-by: Weiyi Lu Signed-off-by: Stephen Boyd --- .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 1 + .../bindings/arm/mediatek/mediatek,bdpsys.txt | 1 + .../bindings/arm/mediatek/mediatek,imgsys.txt | 1 + .../bindings/arm/mediatek/mediatek,infracfg.txt | 1 + .../bindings/arm/mediatek/mediatek,jpgdecsys.txt | 22 ++++++++++++++++++++++ .../bindings/arm/mediatek/mediatek,mcucfg.txt | 22 ++++++++++++++++++++++ .../bindings/arm/mediatek/mediatek,mfgcfg.txt | 22 ++++++++++++++++++++++ .../bindings/arm/mediatek/mediatek,mmsys.txt | 1 + .../bindings/arm/mediatek/mediatek,pericfg.txt | 1 + .../bindings/arm/mediatek/mediatek,topckgen.txt | 1 + .../bindings/arm/mediatek/mediatek,vdecsys.txt | 1 + .../bindings/arm/mediatek/mediatek,vencsys.txt | 1 + 12 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt index cd977db7630c..19fc116346d6 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-apmixedsys" + - "mediatek,mt2712-apmixedsys", "syscon" - "mediatek,mt6797-apmixedsys" - "mediatek,mt8135-apmixedsys" - "mediatek,mt8173-apmixedsys" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt index 4137196dd686..4010e37c53a0 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be: - "mediatek,mt2701-bdpsys", "syscon" + - "mediatek,mt2712-bdpsys", "syscon" - #clock-cells: Must be 1 The bdpsys controller uses the common clk binding from diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt index 047b11ae5f45..868bd51a98be 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-imgsys", "syscon" + - "mediatek,mt2712-imgsys", "syscon" - "mediatek,mt6797-imgsys", "syscon" - "mediatek,mt8173-imgsys", "syscon" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt index 58d58e2006b8..a3430cd96d0f 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt @@ -8,6 +8,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-infracfg", "syscon" + - "mediatek,mt2712-infracfg", "syscon" - "mediatek,mt6797-infracfg", "syscon" - "mediatek,mt8135-infracfg", "syscon" - "mediatek,mt8173-infracfg", "syscon" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt new file mode 100644 index 000000000000..2df799cd06a7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt @@ -0,0 +1,22 @@ +Mediatek jpgdecsys controller +============================ + +The Mediatek jpgdecsys controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be: + - "mediatek,mt2712-jpgdecsys", "syscon" +- #clock-cells: Must be 1 + +The jpgdecsys controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +jpgdecsys: syscon@19000000 { + compatible = "mediatek,mt2712-jpgdecsys", "syscon"; + reg = <0 0x19000000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt new file mode 100644 index 000000000000..b8fb03f3613e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt @@ -0,0 +1,22 @@ +Mediatek mcucfg controller +============================ + +The Mediatek mcucfg controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be one of: + - "mediatek,mt2712-mcucfg", "syscon" +- #clock-cells: Must be 1 + +The mcucfg controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +mcucfg: syscon@10220000 { + compatible = "mediatek,mt2712-mcucfg", "syscon"; + reg = <0 0x10220000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt new file mode 100644 index 000000000000..859e67b416d5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt @@ -0,0 +1,22 @@ +Mediatek mfgcfg controller +============================ + +The Mediatek mfgcfg controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be one of: + - "mediatek,mt2712-mfgcfg", "syscon" +- #clock-cells: Must be 1 + +The mfgcfg controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +mfgcfg: syscon@13000000 { + compatible = "mediatek,mt2712-mfgcfg", "syscon"; + reg = <0 0x13000000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt index 70529e0b58e9..4eb8bbe15c01 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-mmsys", "syscon" + - "mediatek,mt2712-mmsys", "syscon" - "mediatek,mt6797-mmsys", "syscon" - "mediatek,mt8173-mmsys", "syscon" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt index e494366782aa..d9f092eb3550 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt @@ -8,6 +8,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-pericfg", "syscon" + - "mediatek,mt2712-pericfg", "syscon" - "mediatek,mt8135-pericfg", "syscon" - "mediatek,mt8173-pericfg", "syscon" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt index ec93ecbb9f3c..2024fc909d69 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-topckgen" + - "mediatek,mt2712-topckgen", "syscon" - "mediatek,mt6797-topckgen" - "mediatek,mt8135-topckgen" - "mediatek,mt8173-topckgen" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt index d150104f928a..ea40d05089f8 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-vdecsys", "syscon" + - "mediatek,mt2712-vdecsys", "syscon" - "mediatek,mt6797-vdecsys", "syscon" - "mediatek,mt8173-vdecsys", "syscon" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt index 8a93be643647..851545357e94 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt @@ -6,6 +6,7 @@ The Mediatek vencsys controller provides various clocks to the system. Required Properties: - compatible: Should be one of: + - "mediatek,mt2712-vencsys", "syscon" - "mediatek,mt6797-vencsys", "syscon" - "mediatek,mt8173-vencsys", "syscon" - #clock-cells: Must be 1 -- cgit v1.2.3 From 079573e373d3714acd53aad02a3c52355fb177ab Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Tue, 31 Oct 2017 09:19:09 +0100 Subject: dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY This patch add documentation about the MDIO switch used on sun8i-h3-emac for integrated PHY. Signed-off-by: Corentin Labbe Acked-by: Florian Fainelli Acked-by: Rob Herring Reviewed-by: Andrew Lunn Signed-off-by: Maxime Ripard --- .../devicetree/bindings/net/dwmac-sun8i.txt | 147 +++++++++++++++++++-- 1 file changed, 135 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt index 725f3b187886..3d6d5fa0c4d5 100644 --- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt @@ -4,18 +4,18 @@ This device is a platform glue layer for stmmac. Please see stmmac.txt for the other unchanged properties. Required properties: -- compatible: should be one of the following string: +- compatible: must be one of the following string: "allwinner,sun8i-a83t-emac" "allwinner,sun8i-h3-emac" "allwinner,sun8i-v3s-emac" "allwinner,sun50i-a64-emac" - reg: address and length of the register for the device. - interrupts: interrupt for the device -- interrupt-names: should be "macirq" +- interrupt-names: must be "macirq" - clocks: A phandle to the reference clock for this device -- clock-names: should be "stmmaceth" +- clock-names: must be "stmmaceth" - resets: A phandle to the reset control for this device -- reset-names: should be "stmmaceth" +- reset-names: must be "stmmaceth" - phy-mode: See ethernet.txt - phy-handle: See ethernet.txt - #address-cells: shall be 1 @@ -39,23 +39,42 @@ Optional properties for the following compatibles: - allwinner,leds-active-low: EPHY LEDs are active low Required child node of emac: -- mdio bus node: should be named mdio +- mdio bus node: should be named mdio with compatible "snps,dwmac-mdio" Required properties of the mdio node: - #address-cells: shall be 1 - #size-cells: shall be 0 -The device node referenced by "phy" or "phy-handle" should be a child node +The device node referenced by "phy" or "phy-handle" must be a child node of the mdio node. See phy.txt for the generic PHY bindings. -Required properties of the phy node with the following compatibles: +The following compatibles require that the emac node have a mdio-mux child +node called "mdio-mux": + - "allwinner,sun8i-h3-emac" + - "allwinner,sun8i-v3s-emac": +Required properties for the mdio-mux node: + - compatible = "allwinner,sun8i-h3-mdio-mux" + - mdio-parent-bus: a phandle to EMAC mdio + - one child mdio for the integrated mdio with the compatible + "allwinner,sun8i-h3-mdio-internal" + - one child mdio for the external mdio if present (V3s have none) +Required properties for the mdio-mux children node: + - reg: 1 for internal MDIO bus, 2 for external MDIO bus + +The following compatibles require a PHY node representing the integrated +PHY, under the integrated MDIO bus node if an mdio-mux node is used: - "allwinner,sun8i-h3-emac", - "allwinner,sun8i-v3s-emac": + +Additional information regarding generic multiplexer properties can be found +at Documentation/devicetree/bindings/net/mdio-mux.txt + +Required properties of the integrated phy node: - clocks: a phandle to the reference clock for the EPHY - resets: a phandle to the reset control for the EPHY +- Must be a child of the integrated mdio -Example: - +Example with integrated PHY: emac: ethernet@1c0b000 { compatible = "allwinner,sun8i-h3-emac"; syscon = <&syscon>; @@ -72,13 +91,117 @@ emac: ethernet@1c0b000 { phy-handle = <&int_mii_phy>; phy-mode = "mii"; allwinner,leds-active-low; + + mdio: mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + }; + + mdio-mux { + compatible = "mdio-mux", "allwinner,sun8i-h3-mdio-mux"; + #address-cells = <1>; + #size-cells = <0>; + + mdio-parent-bus = <&mdio>; + + int_mdio: mdio@1 { + compatible = "allwinner,sun8i-h3-mdio-internal"; + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + int_mii_phy: ethernet-phy@1 { + reg = <1>; + clocks = <&ccu CLK_BUS_EPHY>; + resets = <&ccu RST_BUS_EPHY>; + phy-is-integrated; + }; + }; + ext_mdio: mdio@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; +}; + +Example with external PHY: +emac: ethernet@1c0b000 { + compatible = "allwinner,sun8i-h3-emac"; + syscon = <&syscon>; + reg = <0x01c0b000 0x104>; + interrupts = ; + interrupt-names = "macirq"; + resets = <&ccu RST_BUS_EMAC>; + reset-names = "stmmaceth"; + clocks = <&ccu CLK_BUS_EMAC>; + clock-names = "stmmaceth"; + #address-cells = <1>; + #size-cells = <0>; + + phy-handle = <&ext_rgmii_phy>; + phy-mode = "rgmii"; + allwinner,leds-active-low; + + mdio: mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + }; + + mdio-mux { + compatible = "allwinner,sun8i-h3-mdio-mux"; + #address-cells = <1>; + #size-cells = <0>; + + mdio-parent-bus = <&mdio>; + + int_mdio: mdio@1 { + compatible = "allwinner,sun8i-h3-mdio-internal"; + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + int_mii_phy: ethernet-phy@1 { + reg = <1>; + clocks = <&ccu CLK_BUS_EPHY>; + resets = <&ccu RST_BUS_EPHY>; + }; + }; + ext_mdio: mdio@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + ext_rgmii_phy: ethernet-phy@1 { + reg = <1>; + }; + }: + }; +}; + +Example with SoC without integrated PHY + +emac: ethernet@1c0b000 { + compatible = "allwinner,sun8i-a83t-emac"; + syscon = <&syscon>; + reg = <0x01c0b000 0x104>; + interrupts = ; + interrupt-names = "macirq"; + resets = <&ccu RST_BUS_EMAC>; + reset-names = "stmmaceth"; + clocks = <&ccu CLK_BUS_EMAC>; + clock-names = "stmmaceth"; + #address-cells = <1>; + #size-cells = <0>; + + phy-handle = <&ext_rgmii_phy>; + phy-mode = "rgmii"; + mdio: mdio { + compatible = "snps,dwmac-mdio"; #address-cells = <1>; #size-cells = <0>; - int_mii_phy: ethernet-phy@1 { + ext_rgmii_phy: ethernet-phy@1 { reg = <1>; - clocks = <&ccu CLK_BUS_EPHY>; - resets = <&ccu RST_BUS_EPHY>; }; }; }; -- cgit v1.2.3 From 808ecf4ad087f80c2eee99af67549f05d5315694 Mon Sep 17 00:00:00 2001 From: Sean Wang Date: Thu, 5 Oct 2017 11:50:22 +0800 Subject: dt-bindings: clock: mediatek: document clk bindings for MediaTek MT7622 SoC This patch adds the binding documentation for apmixedsys, ethsys, hifsys, infracfg, pericfg, topckgen and audsys for MT7622. Signed-off-by: Chen Zhong Signed-off-by: Sean Wang Acked-by: Rob Herring Signed-off-by: Stephen Boyd --- .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 1 + .../bindings/arm/mediatek/mediatek,audsys.txt | 22 ++++++++++++++++++++++ .../bindings/arm/mediatek/mediatek,ethsys.txt | 1 + .../bindings/arm/mediatek/mediatek,hifsys.txt | 1 + .../bindings/arm/mediatek/mediatek,infracfg.txt | 1 + .../bindings/arm/mediatek/mediatek,pciesys.txt | 22 ++++++++++++++++++++++ .../bindings/arm/mediatek/mediatek,pericfg.txt | 1 + .../bindings/arm/mediatek/mediatek,sgmiisys.txt | 22 ++++++++++++++++++++++ .../bindings/arm/mediatek/mediatek,ssusbsys.txt | 22 ++++++++++++++++++++++ .../bindings/arm/mediatek/mediatek,topckgen.txt | 1 + 10 files changed, 94 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt index 19fc116346d6..b404d592ce58 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt @@ -9,6 +9,7 @@ Required Properties: - "mediatek,mt2701-apmixedsys" - "mediatek,mt2712-apmixedsys", "syscon" - "mediatek,mt6797-apmixedsys" + - "mediatek,mt7622-apmixedsys" - "mediatek,mt8135-apmixedsys" - "mediatek,mt8173-apmixedsys" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt new file mode 100644 index 000000000000..9b8f578d5e19 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt @@ -0,0 +1,22 @@ +MediaTek AUDSYS controller +============================ + +The MediaTek AUDSYS controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be one of: + - "mediatek,mt7622-audsys", "syscon" +- #clock-cells: Must be 1 + +The AUDSYS controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +audsys: audsys@11220000 { + compatible = "mediatek,mt7622-audsys", "syscon"; + reg = <0 0x11220000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt index 768f3a5bc055..7aa3fa167668 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be: - "mediatek,mt2701-ethsys", "syscon" + - "mediatek,mt7622-ethsys", "syscon" - #clock-cells: Must be 1 The ethsys controller uses the common clk binding from diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt index beed7b594cea..f5629d64cef2 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt @@ -8,6 +8,7 @@ Required Properties: - compatible: Should be: - "mediatek,mt2701-hifsys", "syscon" + - "mediatek,mt7622-hifsys", "syscon" - #clock-cells: Must be 1 The hifsys controller uses the common clk binding from diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt index a3430cd96d0f..566f153f9f83 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt @@ -10,6 +10,7 @@ Required Properties: - "mediatek,mt2701-infracfg", "syscon" - "mediatek,mt2712-infracfg", "syscon" - "mediatek,mt6797-infracfg", "syscon" + - "mediatek,mt7622-infracfg", "syscon" - "mediatek,mt8135-infracfg", "syscon" - "mediatek,mt8173-infracfg", "syscon" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt new file mode 100644 index 000000000000..d5d5f1227665 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt @@ -0,0 +1,22 @@ +MediaTek PCIESYS controller +============================ + +The MediaTek PCIESYS controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be: + - "mediatek,mt7622-pciesys", "syscon" +- #clock-cells: Must be 1 + +The PCIESYS controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +pciesys: pciesys@1a100800 { + compatible = "mediatek,mt7622-pciesys", "syscon"; + reg = <0 0x1a100800 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt index d9f092eb3550..fb58ca8c2770 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt @@ -9,6 +9,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-pericfg", "syscon" - "mediatek,mt2712-pericfg", "syscon" + - "mediatek,mt7622-pericfg", "syscon" - "mediatek,mt8135-pericfg", "syscon" - "mediatek,mt8173-pericfg", "syscon" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt new file mode 100644 index 000000000000..d113b8e741f3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt @@ -0,0 +1,22 @@ +MediaTek SGMIISYS controller +============================ + +The MediaTek SGMIISYS controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be: + - "mediatek,mt7622-sgmiisys", "syscon" +- #clock-cells: Must be 1 + +The SGMIISYS controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +sgmiisys: sgmiisys@1b128000 { + compatible = "mediatek,mt7622-sgmiisys", "syscon"; + reg = <0 0x1b128000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt new file mode 100644 index 000000000000..00760019da00 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt @@ -0,0 +1,22 @@ +MediaTek SSUSBSYS controller +============================ + +The MediaTek SSUSBSYS controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be: + - "mediatek,mt7622-ssusbsys", "syscon" +- #clock-cells: Must be 1 + +The SSUSBSYS controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +ssusbsys: ssusbsys@1a000000 { + compatible = "mediatek,mt7622-ssusbsys", "syscon"; + reg = <0 0x1a000000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt index 2024fc909d69..24014a7e2332 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt @@ -9,6 +9,7 @@ Required Properties: - "mediatek,mt2701-topckgen" - "mediatek,mt2712-topckgen", "syscon" - "mediatek,mt6797-topckgen" + - "mediatek,mt7622-topckgen" - "mediatek,mt8135-topckgen" - "mediatek,mt8173-topckgen" - #clock-cells: Must be 1 -- cgit v1.2.3 From ca5cd8c9400c7eeeda84e34fa773c6c245e65c82 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Thu, 2 Nov 2017 14:54:00 +0530 Subject: regulator: qcom_spmi: Add support for pmi8994 Document the regulators available on pmi8994 and add support for this PMIC to the SPMI PMIC regulator driver. Signed-off-by: Rajendra Nayak Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/qcom,spmi-regulator.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt index 0fa3b0fac129..57d2c65899df 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt @@ -8,6 +8,7 @@ Qualcomm SPMI Regulators "qcom,pm8916-regulators" "qcom,pm8941-regulators" "qcom,pm8994-regulators" + "qcom,pmi8994-regulators" - interrupts: Usage: optional @@ -100,6 +101,15 @@ Qualcomm SPMI Regulators Definition: Reference to regulator supplying the input pin, as described in the data sheet. +- vdd_s1-supply: +- vdd_s2-supply: +- vdd_s3-supply: +- vdd_l1-supply: + Usage: optional (pmi8994 only) + Value type: + Definition: Reference to regulator supplying the input pin, as + described in the data sheet. + The regulator node houses sub-nodes for each regulator within the device. Each sub-node is identified using the node's name, with valid values listed for each @@ -122,6 +132,9 @@ pm8994: l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, lvs1, lvs2 +pmi8994: + s1, s2, s3, l1 + The content of each sub-node is defined by the standard binding for regulators - see regulator.txt - with additional custom properties described below: -- cgit v1.2.3 From b35be415499ad257954813f8def9c84f49f1ff34 Mon Sep 17 00:00:00 2001 From: Egil Hjelmeland Date: Thu, 2 Nov 2017 10:20:58 +0100 Subject: net: dsa: lan9303: Added Documentation/networking/dsa/lan9303.txt Provide a rough overview of the state of the driver. And explain that the driver operates in two modes: bridged and port-separated. Signed-off-by: Egil Hjelmeland Signed-off-by: David S. Miller --- Documentation/networking/dsa/lan9303.txt | 37 ++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/networking/dsa/lan9303.txt (limited to 'Documentation') diff --git a/Documentation/networking/dsa/lan9303.txt b/Documentation/networking/dsa/lan9303.txt new file mode 100644 index 000000000000..ec28683d107d --- /dev/null +++ b/Documentation/networking/dsa/lan9303.txt @@ -0,0 +1,37 @@ +LAN9303 Ethernet switch driver +============================== + +The LAN9303 is a three port 10/100 ethernet switch with integrated phys for the +two external ethernet ports. The third port is an RMII/MII interface to a host +master network interface (e.g. fixed link). + + +Driver details +============== + +The driver is implemented as a DSA driver, see +Documentation/networking/dsa/dsa.txt. + +See Documentation/devicetree/bindings/net/dsa/lan9303.txt for device tree +binding. + +The LAN9303 can be managed both via MDIO and I2C, both supported by this driver. + +At startup the driver configures the device to provide two separate network +interfaces (which is the default state of a DSA device). Due to HW limitations, +no HW MAC learning takes place in this mode. + +When both user ports are joined to the same bridge, the normal HW MAC learning +is enabled. This means that unicast traffic is forwarded in HW. Broadcast and +multicast is flooded in HW. STP is also supported in this mode. The driver +support fdb/mdb operations as well, meaning IGMP snooping is supported. + +If one of the user ports leave the bridge, the ports goes back to the initial +separated operation. + + +Driver limitations +================== + + - Support for VLAN filtering is not implemented + - The HW does not support VLAN-specific fdb entries -- cgit v1.2.3 From 0962289b1cd91534f7111e763d3e6a17dcd47ecb Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Fri, 27 Oct 2017 10:34:22 +0200 Subject: irqchip/gic: Deal with broken firmware exposing only 4kB of GICv2 CPU interface There is a lot of broken firmware out there that don't really expose the information the kernel requires when it comes with dealing with GICv2: (1) Firmware that only describes the first 4kB of GICv2 (2) Firmware that describe 128kB of CPU interface, while the usable portion of the address space is between 60 and 68kB So far, we only deal with (2). But we have platforms exhibiting behaviour (1), resulting in two sub-cases: (a) The GIC is occupying 8kB, as required by the GICv2 architecture (b) It is actually spread 128kB, and this is likely to be a version of (2) This patch tries to work around both (a) and (b) by poking at the outside of the described memory region, and try to work out what is actually there. This is of course unsafe, and should only be enabled if there is no way to otherwise fix the DT provided by the firmware (we provide a "irqchip.gicv2_force_probe" option to that effect). Note that for the time being, we restrict ourselves to GICv2 implementations provided by ARM, since there I have no knowledge of an alternative implementations. This could be relaxed if such an implementation comes to light on a broken platform. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier --- Documentation/admin-guide/kernel-parameters.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 05496622b4ef..3daa0a590236 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1713,6 +1713,13 @@ irqaffinity= [SMP] Set the default irq affinity mask The argument is a cpu list, as described above. + irqchip.gicv2_force_probe= + [ARM, ARM64] + Format: + Force the kernel to look for the second 4kB page + of a GICv2 controller even if the memory range + exposed by the device tree is too small. + irqfixup [HW] When an interrupt is not handled search all handlers for it. Intended to get systems with badly broken -- cgit v1.2.3 From 4e4cb1b183d6e9df57f4e54c8b1a5231995da820 Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl Date: Mon, 30 Oct 2017 00:05:21 +0100 Subject: irqchip/meson-gpio: add support for Meson8 SoCs Meson8 uses the same GPIO interrupt controller IP block as the other Meson SoCs. A total of 134 pins can be spied on, which is the sum of: - 22 pins on bank GPIOX - 17 pins on bank GPIOY - 30 pins on bank GPIODV - 10 pins on bank GPIOH - 15 pins on bank GPIOZ - 7 pins on bank CARD - 19 pins on bank BOOT - 14 pins in the AO domain Acked-by: Kevin Hilman Acked-by: Rob Herring Signed-off-by: Martin Blumenstingl Signed-off-by: Marc Zyngier --- .../devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt index 633e21ce4b17..a83f9a5734ca 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt @@ -10,6 +10,7 @@ number of interrupt exposed depends on the SoC. Required properties: - compatible : must have "amlogic,meson8-gpio-intc” and either + “amlogic,meson8-gpio-intc” for meson8 SoCs (S802) or “amlogic,meson8b-gpio-intc” for meson8b SoCs (S805) or “amlogic,meson-gxbb-gpio-intc” for GXBB SoCs (S905) or “amlogic,meson-gxl-gpio-intc” for GXL SoCs (S905X, S912) -- cgit v1.2.3 From 47d3d7ac656a1ffb9d0f0d3c845663ed6fd7e78d Mon Sep 17 00:00:00 2001 From: Tom Herbert Date: Mon, 30 Oct 2017 14:16:00 -0700 Subject: ipv6: Implement limits on Hop-by-Hop and Destination options RFC 8200 (IPv6) defines Hop-by-Hop options and Destination options extension headers. Both of these carry a list of TLVs which is only limited by the maximum length of the extension header (2048 bytes). By the spec a host must process all the TLVs in these options, however these could be used as a fairly obvious denial of service attack. I think this could in fact be a significant DOS vector on the Internet, one mitigating factor might be that many FWs drop all packets with EH (and obviously this is only IPv6) so an Internet wide attack might not be so effective (yet!). By my calculation, the worse case packet with TLVs in a standard 1500 byte MTU packet that would be processed by the stack contains 1282 invidual TLVs (including pad TLVS) or 724 two byte TLVs. I wrote a quick test program that floods a whole bunch of these packets to a host and sure enough there is substantial time spent in ip6_parse_tlv. These packets contain nothing but unknown TLVS (that are ignored), TLV padding, and bogus UDP header with zero payload length. 25.38% [kernel] [k] __fib6_clean_all 21.63% [kernel] [k] ip6_parse_tlv 4.21% [kernel] [k] __local_bh_enable_ip 2.18% [kernel] [k] ip6_pol_route.isra.39 1.98% [kernel] [k] fib6_walk_continue 1.88% [kernel] [k] _raw_write_lock_bh 1.65% [kernel] [k] dst_release This patch adds configurable limits to Destination and Hop-by-Hop options. There are three limits that may be set: - Limit the number of options in a Hop-by-Hop or Destination options extension header. - Limit the byte length of a Hop-by-Hop or Destination options extension header. - Disallow unrecognized options in a Hop-by-Hop or Destination options extension header. The limits are set in corresponding sysctls: ipv6.sysctl.max_dst_opts_cnt ipv6.sysctl.max_hbh_opts_cnt ipv6.sysctl.max_dst_opts_len ipv6.sysctl.max_hbh_opts_len If a max_*_opts_cnt is less than zero then unknown TLVs are disallowed. The number of known TLVs that are allowed is the absolute value of this number. If a limit is exceeded when processing an extension header the packet is dropped. Default values are set to 8 for options counts, and set to INT_MAX for maximum length. Note the choice to limit options to 8 is an arbitrary guess (roughly based on the fact that the stack supports three HBH options and just one destination option). These limits have being proposed in draft-ietf-6man-rfc6434-bis. Tested (by Martin Lau) I tested out 1 thread (i.e. one raw_udp process). I changed the net.ipv6.max_dst_(opts|hbh)_number between 8 to 2048. With sysctls setting to 2048, the softirq% is packed to 100%. With 8, the softirq% is almost unnoticable from mpstat. v2; - Code and documention cleanup. - Change references of RFC2460 to be RFC8200. - Add reference to RFC6434-bis where the limits will be in standard. Signed-off-by: Tom Herbert Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 77f4de59dc9c..e6661b205f72 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -1385,6 +1385,30 @@ mld_qrv - INTEGER Default: 2 (as specified by RFC3810 9.1) Minimum: 1 (as specified by RFC6636 4.5) +max_dst_opts_cnt - INTEGER + Maximum number of non-padding TLVs allowed in a Destination + options extension header. If this value is less than zero + then unknown options are disallowed and the number of known + TLVs allowed is the absolute value of this number. + Default: 8 + +max_hbh_opts_cnt - INTEGER + Maximum number of non-padding TLVs allowed in a Hop-by-Hop + options extension header. If this value is less than zero + then unknown options are disallowed and the number of known + TLVs allowed is the absolute value of this number. + Default: 8 + +max dst_opts_len - INTEGER + Maximum length allowed for a Destination options extension + header. + Default: INT_MAX (unlimited) + +max hbh_opts_len - INTEGER + Maximum length allowed for a Hop-by-Hop options extension + header. + Default: INT_MAX (unlimited) + IPv6 Fragmentation: ip6frag_high_thresh - INTEGER -- cgit v1.2.3 From ddc92bec6d7d7e8a07794a8dbeade19476891b53 Mon Sep 17 00:00:00 2001 From: Stafford Horne Date: Sat, 21 Oct 2017 22:39:35 +0900 Subject: dt-bindings: openrisc: Add OpenRISC platform SoC Add devicetree binding documentation for the OpenRISC platform opencores,or1ksim. This is the main OpenRISC reference platform supporting multiple FPGA SoC's. This format is based on some of the mips binding docs as we have similar requirements. Also, update maintainers so openrisc related binding changes are visible to the openrisc team. Acked-by: Rob Herring Suggested-by: Pavel Machek Signed-off-by: Stafford Horne --- .../bindings/openrisc/opencores/or1ksim.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/openrisc/opencores/or1ksim.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/openrisc/opencores/or1ksim.txt b/Documentation/devicetree/bindings/openrisc/opencores/or1ksim.txt new file mode 100644 index 000000000000..4950c794ecbb --- /dev/null +++ b/Documentation/devicetree/bindings/openrisc/opencores/or1ksim.txt @@ -0,0 +1,39 @@ +OpenRISC Generic SoC +==================== + +Boards and FPGA SoC's which support the OpenRISC standard platform. The +platform essentially follows the conventions of the OpenRISC architecture +specification, however some aspects, such as the boot protocol have been defined +by the Linux port. + +Required properties +------------------- + - compatible: Must include "opencores,or1ksim" + +CPU nodes: +---------- +A "cpus" node is required. Required properties: + - #address-cells: Must be 1. + - #size-cells: Must be 0. +A CPU sub-node is also required for at least CPU 0. Since the topology may +be probed via CPS, it is not necessary to specify secondary CPUs. Required +properties: + - compatible: Must be "opencores,or1200-rtlsvn481". + - reg: CPU number. + - clock-frequency: The CPU clock frequency in Hz. +Example: + cpus { + #address-cells = <1>; + #size-cells = <0>; + cpu@0 { + compatible = "opencores,or1200-rtlsvn481"; + reg = <0>; + clock-frequency = <20000000>; + }; + }; + + +Boot protocol +------------- +The bootloader may pass the following arguments to the kernel: + - r3: address of a flattened device-tree blob or 0x0. -- cgit v1.2.3 From fab8be88ac0478b0157859f74fad5088c292356b Mon Sep 17 00:00:00 2001 From: Stafford Horne Date: Thu, 7 Sep 2017 22:55:18 +0900 Subject: dt-bindings: add openrisc to vendor prefixes list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add OpenRISC.io to vendor prefixes. This is reserved for softcores developed by the OpenRISC community. The OpenRISC community has separated from OpenCores.org requiring a new prefix. Reviewed-by: Andreas Färber Acked-by: Rob Herring Signed-off-by: Stafford Horne --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1afd298eddd7..b1eeca851d6f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -246,6 +246,7 @@ onion Onion Corporation onnn ON Semiconductor Corp. ontat On Tat Industrial Company opencores OpenCores.org +openrisc OpenRISC.io option Option NV ORCL Oracle Corporation ortustech Ortus Technology Co., Ltd. -- cgit v1.2.3 From 9b54470afd836278a7e6f0f08194e2e2dca4b6eb Mon Sep 17 00:00:00 2001 From: Stafford Horne Date: Mon, 30 Oct 2017 21:38:35 +0900 Subject: irqchip: add initial support for ompic IPI driver for the Open Multi-Processor Interrupt Controller (ompic) as described in the Multi-core support section of the OpenRISC 1.2 architecture specification: https://github.com/openrisc/doc/raw/master/openrisc-arch-1.2-rev0.pdf Each OpenRISC core contains a full interrupt controller which is used in the SMP architecture for interrupt balancing. This IPI device, the ompic, is the only external device required for enabling SMP on OpenRISC. Pending ops are stored in a memory bit mask which can allow multiple pending operations to be set and serviced at a time. This is mostly borrowed from the alpha IPI implementation. Reviewed-by: Marc Zyngier Acked-by: Rob Herring Signed-off-by: Stefan Kristiansson [shorne@gmail.com: converted ops to bitmask, wrote commit message] Signed-off-by: Stafford Horne --- .../interrupt-controller/openrisc,ompic.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt new file mode 100644 index 000000000000..caec07cc7149 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt @@ -0,0 +1,22 @@ +Open Multi-Processor Interrupt Controller + +Required properties: + +- compatible : This should be "openrisc,ompic" +- reg : Specifies base physical address and size of the register space. The + size is based on the number of cores the controller has been configured + to handle, this should be set to 8 bytes per cpu core. +- interrupt-controller : Identifies the node as an interrupt controller. +- #interrupt-cells : This should be set to 0 as this will not be an irq + parent. +- interrupts : Specifies the interrupt line to which the ompic is wired. + +Example: + +ompic: interrupt-controller@98000000 { + compatible = "openrisc,ompic"; + reg = <0x98000000 16>; + interrupt-controller; + #interrupt-cells = <0>; + interrupts = <1>; +}; -- cgit v1.2.3 From e16e437024abdbb8d08d8371fb2d9c99522df136 Mon Sep 17 00:00:00 2001 From: "Bird, Timothy" Date: Thu, 2 Nov 2017 20:30:46 +0000 Subject: Documentation: Add Tim Bird to list of enforcement statement endorsers Add my name to the list. Signed-off-by: Tim Bird Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index ce2c5130d37f..d03b1a419dd6 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -61,6 +61,7 @@ we might work for today, have in the past, or will in the future. - Felipe Balbi - Arnd Bergmann - Ard Biesheuvel + - Tim Bird - Paolo Bonzini - Christian Borntraeger - Mark Brown (Linaro) -- cgit v1.2.3 From aba973c69e3658e3190d8983eed7dddd3c44dd1e Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef Date: Wed, 18 Oct 2017 08:00:52 +0100 Subject: crypto: doc - adapt api sample to use async. op wait The code sample is waiting for an async. crypto op completion. Adapt sample to use the new generic infrastructure to do the same. This also fixes a possible data coruption bug created by the use of wait_for_completion_interruptible() without dealing correctly with an interrupt aborting the wait prior to the async op finishing. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu --- Documentation/crypto/api-samples.rst | 52 +++++++----------------------------- 1 file changed, 10 insertions(+), 42 deletions(-) (limited to 'Documentation') diff --git a/Documentation/crypto/api-samples.rst b/Documentation/crypto/api-samples.rst index 2531948db89f..006827e30d06 100644 --- a/Documentation/crypto/api-samples.rst +++ b/Documentation/crypto/api-samples.rst @@ -7,59 +7,27 @@ Code Example For Symmetric Key Cipher Operation :: - struct tcrypt_result { - struct completion completion; - int err; - }; - /* tie all data structures together */ struct skcipher_def { struct scatterlist sg; struct crypto_skcipher *tfm; struct skcipher_request *req; - struct tcrypt_result result; + struct crypto_wait wait; }; - /* Callback function */ - static void test_skcipher_cb(struct crypto_async_request *req, int error) - { - struct tcrypt_result *result = req->data; - - if (error == -EINPROGRESS) - return; - result->err = error; - complete(&result->completion); - pr_info("Encryption finished successfully\n"); - } - /* Perform cipher operation */ static unsigned int test_skcipher_encdec(struct skcipher_def *sk, int enc) { - int rc = 0; + int rc; if (enc) - rc = crypto_skcipher_encrypt(sk->req); + rc = crypto_wait_req(crypto_skcipher_encrypt(sk->req), &sk->wait); else - rc = crypto_skcipher_decrypt(sk->req); - - switch (rc) { - case 0: - break; - case -EINPROGRESS: - case -EBUSY: - rc = wait_for_completion_interruptible( - &sk->result.completion); - if (!rc && !sk->result.err) { - reinit_completion(&sk->result.completion); - break; - } - default: - pr_info("skcipher encrypt returned with %d result %d\n", - rc, sk->result.err); - break; - } - init_completion(&sk->result.completion); + rc = crypto_wait_req(crypto_skcipher_decrypt(sk->req), &sk->wait); + + if (rc) + pr_info("skcipher encrypt returned with result %d\n", rc); return rc; } @@ -89,8 +57,8 @@ Code Example For Symmetric Key Cipher Operation } skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, - test_skcipher_cb, - &sk.result); + crypto_req_done, + &sk.wait); /* AES 256 with random key */ get_random_bytes(&key, 32); @@ -122,7 +90,7 @@ Code Example For Symmetric Key Cipher Operation /* We encrypt one block */ sg_init_one(&sk.sg, scratchpad, 16); skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata); - init_completion(&sk.result.completion); + crypto_init_wait(&sk.wait); /* encrypt data */ ret = test_skcipher_encdec(&sk, 1); -- cgit v1.2.3 From 43994d824e8443263dc98b151e6326bf677be52e Mon Sep 17 00:00:00 2001 From: Dave Martin Date: Tue, 31 Oct 2017 15:51:19 +0000 Subject: arm64/sve: Detect SVE and activate runtime support This patch enables detection of hardware SVE support via the cpufeatures framework, and reports its presence to the kernel and userspace via the new ARM64_SVE cpucap and HWCAP_SVE hwcap respectively. Userspace can also detect SVE using ID_AA64PFR0_EL1, using the cpufeatures MRS emulation. When running on hardware that supports SVE, this enables runtime kernel support for SVE, and allows user tasks to execute SVE instructions and make of the of the SVE-specific user/kernel interface extensions implemented by this series. Signed-off-by: Dave Martin Reviewed-by: Suzuki K Poulose Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon --- Documentation/arm64/cpu-feature-registers.txt | 6 +++++- Documentation/arm64/elf_hwcaps.txt | 4 ++++ 2 files changed, 9 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt index 011ddfc1e570..bd9b3faab2c4 100644 --- a/Documentation/arm64/cpu-feature-registers.txt +++ b/Documentation/arm64/cpu-feature-registers.txt @@ -142,7 +142,11 @@ infrastructure: x--------------------------------------------------x | Name | bits | visible | |--------------------------------------------------| - | RES0 | [63-28] | n | + | RES0 | [63-36] | n | + |--------------------------------------------------| + | SVE | [35-32] | y | + |--------------------------------------------------| + | RES0 | [31-28] | n | |--------------------------------------------------| | GIC | [27-24] | n | |--------------------------------------------------| diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt index 0ba180522e3c..89edba12a9e0 100644 --- a/Documentation/arm64/elf_hwcaps.txt +++ b/Documentation/arm64/elf_hwcaps.txt @@ -154,3 +154,7 @@ HWCAP_ASIMDDP HWCAP_SHA512 Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0002. + +HWCAP_SVE + + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001. -- cgit v1.2.3 From ce6990813f15f4cabadf325791e35bd4af8152f5 Mon Sep 17 00:00:00 2001 From: Dave Martin Date: Tue, 31 Oct 2017 15:51:20 +0000 Subject: arm64/sve: Add documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch adds basic documentation of the user/kernel interface provided by the for SVE. Signed-off-by: Dave Martin Reviewed-by: Catalin Marinas Cc: Alan Hayward Cc: Alex Bennée Cc: Mark Rutland Cc: Michael Kerrisk Cc: Szabolcs Nagy Cc: linux-api@vger.kernel.org Signed-off-by: Will Deacon --- Documentation/arm64/sve.txt | 508 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 508 insertions(+) create mode 100644 Documentation/arm64/sve.txt (limited to 'Documentation') diff --git a/Documentation/arm64/sve.txt b/Documentation/arm64/sve.txt new file mode 100644 index 000000000000..f128f736b4a5 --- /dev/null +++ b/Documentation/arm64/sve.txt @@ -0,0 +1,508 @@ + Scalable Vector Extension support for AArch64 Linux + =================================================== + +Author: Dave Martin +Date: 4 August 2017 + +This document outlines briefly the interface provided to userspace by Linux in +order to support use of the ARM Scalable Vector Extension (SVE). + +This is an outline of the most important features and issues only and not +intended to be exhaustive. + +This document does not aim to describe the SVE architecture or programmer's +model. To aid understanding, a minimal description of relevant programmer's +model features for SVE is included in Appendix A. + + +1. General +----------- + +* SVE registers Z0..Z31, P0..P15 and FFR and the current vector length VL, are + tracked per-thread. + +* The presence of SVE is reported to userspace via HWCAP_SVE in the aux vector + AT_HWCAP entry. Presence of this flag implies the presence of the SVE + instructions and registers, and the Linux-specific system interfaces + described in this document. SVE is reported in /proc/cpuinfo as "sve". + +* Support for the execution of SVE instructions in userspace can also be + detected by reading the CPU ID register ID_AA64PFR0_EL1 using an MRS + instruction, and checking that the value of the SVE field is nonzero. [3] + + It does not guarantee the presence of the system interfaces described in the + following sections: software that needs to verify that those interfaces are + present must check for HWCAP_SVE instead. + +* Debuggers should restrict themselves to interacting with the target via the + NT_ARM_SVE regset. The recommended way of detecting support for this regset + is to connect to a target process first and then attempt a + ptrace(PTRACE_GETREGSET, pid, NT_ARM_SVE, &iov). + + +2. Vector length terminology +----------------------------- + +The size of an SVE vector (Z) register is referred to as the "vector length". + +To avoid confusion about the units used to express vector length, the kernel +adopts the following conventions: + +* Vector length (VL) = size of a Z-register in bytes + +* Vector quadwords (VQ) = size of a Z-register in units of 128 bits + +(So, VL = 16 * VQ.) + +The VQ convention is used where the underlying granularity is important, such +as in data structure definitions. In most other situations, the VL convention +is used. This is consistent with the meaning of the "VL" pseudo-register in +the SVE instruction set architecture. + + +3. System call behaviour +------------------------- + +* On syscall, V0..V31 are preserved (as without SVE). Thus, bits [127:0] of + Z0..Z31 are preserved. All other bits of Z0..Z31, and all of P0..P15 and FFR + become unspecified on return from a syscall. + +* The SVE registers are not used to pass arguments to or receive results from + any syscall. + +* In practice the affected registers/bits will be preserved or will be replaced + with zeros on return from a syscall, but userspace should not make + assumptions about this. The kernel behaviour may vary on a case-by-case + basis. + +* All other SVE state of a thread, including the currently configured vector + length, the state of the PR_SVE_VL_INHERIT flag, and the deferred vector + length (if any), is preserved across all syscalls, subject to the specific + exceptions for execve() described in section 6. + + In particular, on return from a fork() or clone(), the parent and new child + process or thread share identical SVE configuration, matching that of the + parent before the call. + + +4. Signal handling +------------------- + +* A new signal frame record sve_context encodes the SVE registers on signal + delivery. [1] + +* This record is supplementary to fpsimd_context. The FPSR and FPCR registers + are only present in fpsimd_context. For convenience, the content of V0..V31 + is duplicated between sve_context and fpsimd_context. + +* The signal frame record for SVE always contains basic metadata, in particular + the thread's vector length (in sve_context.vl). + +* The SVE registers may or may not be included in the record, depending on + whether the registers are live for the thread. The registers are present if + and only if: + sve_context.head.size >= SVE_SIG_CONTEXT_SIZE(sve_vq_from_vl(sve_context.vl)). + +* If the registers are present, the remainder of the record has a vl-dependent + size and layout. Macros SVE_SIG_* are defined [1] to facilitate access to + the members. + +* If the SVE context is too big to fit in sigcontext.__reserved[], then extra + space is allocated on the stack, an extra_context record is written in + __reserved[] referencing this space. sve_context is then written in the + extra space. Refer to [1] for further details about this mechanism. + + +5. Signal return +----------------- + +When returning from a signal handler: + +* If there is no sve_context record in the signal frame, or if the record is + present but contains no register data as desribed in the previous section, + then the SVE registers/bits become non-live and take unspecified values. + +* If sve_context is present in the signal frame and contains full register + data, the SVE registers become live and are populated with the specified + data. However, for backward compatibility reasons, bits [127:0] of Z0..Z31 + are always restored from the corresponding members of fpsimd_context.vregs[] + and not from sve_context. The remaining bits are restored from sve_context. + +* Inclusion of fpsimd_context in the signal frame remains mandatory, + irrespective of whether sve_context is present or not. + +* The vector length cannot be changed via signal return. If sve_context.vl in + the signal frame does not match the current vector length, the signal return + attempt is treated as illegal, resulting in a forced SIGSEGV. + + +6. prctl extensions +-------------------- + +Some new prctl() calls are added to allow programs to manage the SVE vector +length: + +prctl(PR_SVE_SET_VL, unsigned long arg) + + Sets the vector length of the calling thread and related flags, where + arg == vl | flags. Other threads of the calling process are unaffected. + + vl is the desired vector length, where sve_vl_valid(vl) must be true. + + flags: + + PR_SVE_SET_VL_INHERIT + + Inherit the current vector length across execve(). Otherwise, the + vector length is reset to the system default at execve(). (See + Section 9.) + + PR_SVE_SET_VL_ONEXEC + + Defer the requested vector length change until the next execve() + performed by this thread. + + The effect is equivalent to implicit exceution of the following + call immediately after the next execve() (if any) by the thread: + + prctl(PR_SVE_SET_VL, arg & ~PR_SVE_SET_VL_ONEXEC) + + This allows launching of a new program with a different vector + length, while avoiding runtime side effects in the caller. + + + Without PR_SVE_SET_VL_ONEXEC, the requested change takes effect + immediately. + + + Return value: a nonnegative on success, or a negative value on error: + EINVAL: SVE not supported, invalid vector length requested, or + invalid flags. + + + On success: + + * Either the calling thread's vector length or the deferred vector length + to be applied at the next execve() by the thread (dependent on whether + PR_SVE_SET_VL_ONEXEC is present in arg), is set to the largest value + supported by the system that is less than or equal to vl. If vl == + SVE_VL_MAX, the value set will be the largest value supported by the + system. + + * Any previously outstanding deferred vector length change in the calling + thread is cancelled. + + * The returned value describes the resulting configuration, encoded as for + PR_SVE_GET_VL. The vector length reported in this value is the new + current vector length for this thread if PR_SVE_SET_VL_ONEXEC was not + present in arg; otherwise, the reported vector length is the deferred + vector length that will be applied at the next execve() by the calling + thread. + + * Changing the vector length causes all of P0..P15, FFR and all bits of + Z0..V31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become + unspecified. Calling PR_SVE_SET_VL with vl equal to the thread's current + vector length, or calling PR_SVE_SET_VL with the PR_SVE_SET_VL_ONEXEC + flag, does not constitute a change to the vector length for this purpose. + + +prctl(PR_SVE_GET_VL) + + Gets the vector length of the calling thread. + + The following flag may be OR-ed into the result: + + PR_SVE_SET_VL_INHERIT + + Vector length will be inherited across execve(). + + There is no way to determine whether there is an outstanding deferred + vector length change (which would only normally be the case between a + fork() or vfork() and the corresponding execve() in typical use). + + To extract the vector length from the result, and it with + PR_SVE_VL_LEN_MASK. + + Return value: a nonnegative value on success, or a negative value on error: + EINVAL: SVE not supported. + + +7. ptrace extensions +--------------------- + +* A new regset NT_ARM_SVE is defined for use with PTRACE_GETREGSET and + PTRACE_SETREGSET. + + Refer to [2] for definitions. + +The regset data starts with struct user_sve_header, containing: + + size + + Size of the complete regset, in bytes. + This depends on vl and possibly on other things in the future. + + If a call to PTRACE_GETREGSET requests less data than the value of + size, the caller can allocate a larger buffer and retry in order to + read the complete regset. + + max_size + + Maximum size in bytes that the regset can grow to for the target + thread. The regset won't grow bigger than this even if the target + thread changes its vector length etc. + + vl + + Target thread's current vector length, in bytes. + + max_vl + + Maximum possible vector length for the target thread. + + flags + + either + + SVE_PT_REGS_FPSIMD + + SVE registers are not live (GETREGSET) or are to be made + non-live (SETREGSET). + + The payload is of type struct user_fpsimd_state, with the same + meaning as for NT_PRFPREG, starting at offset + SVE_PT_FPSIMD_OFFSET from the start of user_sve_header. + + Extra data might be appended in the future: the size of the + payload should be obtained using SVE_PT_FPSIMD_SIZE(vq, flags). + + vq should be obtained using sve_vq_from_vl(vl). + + or + + SVE_PT_REGS_SVE + + SVE registers are live (GETREGSET) or are to be made live + (SETREGSET). + + The payload contains the SVE register data, starting at offset + SVE_PT_SVE_OFFSET from the start of user_sve_header, and with + size SVE_PT_SVE_SIZE(vq, flags); + + ... OR-ed with zero or more of the following flags, which have the same + meaning and behaviour as the corresponding PR_SET_VL_* flags: + + SVE_PT_VL_INHERIT + + SVE_PT_VL_ONEXEC (SETREGSET only). + +* The effects of changing the vector length and/or flags are equivalent to + those documented for PR_SVE_SET_VL. + + The caller must make a further GETREGSET call if it needs to know what VL is + actually set by SETREGSET, unless is it known in advance that the requested + VL is supported. + +* In the SVE_PT_REGS_SVE case, the size and layout of the payload depends on + the header fields. The SVE_PT_SVE_*() macros are provided to facilitate + access to the members. + +* In either case, for SETREGSET it is permissible to omit the payload, in which + case only the vector length and flags are changed (along with any + consequences of those changes). + +* For SETREGSET, if an SVE_PT_REGS_SVE payload is present and the + requested VL is not supported, the effect will be the same as if the + payload were omitted, except that an EIO error is reported. No + attempt is made to translate the payload data to the correct layout + for the vector length actually set. The thread's FPSIMD state is + preserved, but the remaining bits of the SVE registers become + unspecified. It is up to the caller to translate the payload layout + for the actual VL and retry. + +* The effect of writing a partial, incomplete payload is unspecified. + + +8. ELF coredump extensions +--------------------------- + +* A NT_ARM_SVE note will be added to each coredump for each thread of the + dumped process. The contents will be equivalent to the data that would have + been read if a PTRACE_GETREGSET of NT_ARM_SVE were executed for each thread + when the coredump was generated. + + +9. System runtime configuration +-------------------------------- + +* To mitigate the ABI impact of expansion of the signal frame, a policy + mechanism is provided for administrators, distro maintainers and developers + to set the default vector length for userspace processes: + +/proc/sys/abi/sve_default_vector_length + + Writing the text representation of an integer to this file sets the system + default vector length to the specified value, unless the value is greater + than the maximum vector length supported by the system in which case the + default vector length is set to that maximum. + + The result can be determined by reopening the file and reading its + contents. + + At boot, the default vector length is initially set to 64 or the maximum + supported vector length, whichever is smaller. This determines the initial + vector length of the init process (PID 1). + + Reading this file returns the current system default vector length. + +* At every execve() call, the new vector length of the new process is set to + the system default vector length, unless + + * PR_SVE_SET_VL_INHERIT (or equivalently SVE_PT_VL_INHERIT) is set for the + calling thread, or + + * a deferred vector length change is pending, established via the + PR_SVE_SET_VL_ONEXEC flag (or SVE_PT_VL_ONEXEC). + +* Modifying the system default vector length does not affect the vector length + of any existing process or thread that does not make an execve() call. + + +Appendix A. SVE programmer's model (informative) +================================================= + +This section provides a minimal description of the additions made by SVE to the +ARMv8-A programmer's model that are relevant to this document. + +Note: This section is for information only and not intended to be complete or +to replace any architectural specification. + +A.1. Registers +--------------- + +In A64 state, SVE adds the following: + +* 32 8VL-bit vector registers Z0..Z31 + For each Zn, Zn bits [127:0] alias the ARMv8-A vector register Vn. + + A register write using a Vn register name zeros all bits of the corresponding + Zn except for bits [127:0]. + +* 16 VL-bit predicate registers P0..P15 + +* 1 VL-bit special-purpose predicate register FFR (the "first-fault register") + +* a VL "pseudo-register" that determines the size of each vector register + + The SVE instruction set architecture provides no way to write VL directly. + Instead, it can be modified only by EL1 and above, by writing appropriate + system registers. + +* The value of VL can be configured at runtime by EL1 and above: + 16 <= VL <= VLmax, where VL must be a multiple of 16. + +* The maximum vector length is determined by the hardware: + 16 <= VLmax <= 256. + + (The SVE architecture specifies 256, but permits future architecture + revisions to raise this limit.) + +* FPSR and FPCR are retained from ARMv8-A, and interact with SVE floating-point + operations in a similar way to the way in which they interact with ARMv8 + floating-point operations. + + 8VL-1 128 0 bit index + +---- //// -----------------+ + Z0 | : V0 | + : : + Z7 | : V7 | + Z8 | : * V8 | + : : : + Z15 | : *V15 | + Z16 | : V16 | + : : + Z31 | : V31 | + +---- //// -----------------+ + 31 0 + VL-1 0 +-------+ + +---- //// --+ FPSR | | + P0 | | +-------+ + : | | *FPCR | | + P15 | | +-------+ + +---- //// --+ + FFR | | +-----+ + +---- //// --+ VL | | + +-----+ + +(*) callee-save: + This only applies to bits [63:0] of Z-/V-registers. + FPCR contains callee-save and caller-save bits. See [4] for details. + + +A.2. Procedure call standard +----------------------------- + +The ARMv8-A base procedure call standard is extended as follows with respect to +the additional SVE register state: + +* All SVE register bits that are not shared with FP/SIMD are caller-save. + +* Z8 bits [63:0] .. Z15 bits [63:0] are callee-save. + + This follows from the way these bits are mapped to V8..V15, which are caller- + save in the base procedure call standard. + + +Appendix B. ARMv8-A FP/SIMD programmer's model +=============================================== + +Note: This section is for information only and not intended to be complete or +to replace any architectural specification. + +Refer to [4] for for more information. + +ARMv8-A defines the following floating-point / SIMD register state: + +* 32 128-bit vector registers V0..V31 +* 2 32-bit status/control registers FPSR, FPCR + + 127 0 bit index + +---------------+ + V0 | | + : : : + V7 | | + * V8 | | + : : : : + *V15 | | + V16 | | + : : : + V31 | | + +---------------+ + + 31 0 + +-------+ + FPSR | | + +-------+ + *FPCR | | + +-------+ + +(*) callee-save: + This only applies to bits [63:0] of V-registers. + FPCR contains a mixture of callee-save and caller-save bits. + + +References +========== + +[1] arch/arm64/include/uapi/asm/sigcontext.h + AArch64 Linux signal ABI definitions + +[2] arch/arm64/include/uapi/asm/ptrace.h + AArch64 Linux ptrace ABI definitions + +[3] linux/Documentation/arm64/cpu-feature-registers.txt + +[4] ARM IHI0055C + http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf + http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html + Procedure Call Standard for the ARM 64-bit Architecture (AArch64) -- cgit v1.2.3 From fb615d61b5583db92e3793709b97e35dc9499c2a Mon Sep 17 00:00:00 2001 From: Paul Burton Date: Wed, 25 Oct 2017 17:04:33 -0700 Subject: Update MIPS email addresses MIPS will soon not be a part of Imagination Technologies, and as such many @imgtec.com email addresses will no longer be valid. This patch updates the addresses for those who: - Have 10 or more patches in mainline authored using an @imgtec.com email address, or any patches dated within the past year. - Are still with Imagination but leaving as part of the MIPS business unit, as determined from an internal email address list. - Haven't already updated their email address (ie. JamesH) or expressed a desire to be excluded (ie. Maciej). - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt & myself. New addresses are of the form firstname.lastname@mips.com, and all verified against an internal email address list. An entry is added to .mailmap for each person such that get_maintainer.pl will report the new addresses rather than @imgtec.com addresses which will soon be dead. Instances of the affected addresses throughout the tree are then mechanically replaced with the new @mips.com address. Signed-off-by: Paul Burton Cc: Deng-Cheng Zhu Cc: Deng-Cheng Zhu Acked-by: Dengcheng Zhu Cc: Matt Redfearn Cc: Matt Redfearn Acked-by: Matt Redfearn Cc: Andrew Morton Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: trivial@kernel.org Signed-off-by: Linus Torvalds --- Documentation/ABI/testing/sysfs-class-remoteproc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-remoteproc b/Documentation/ABI/testing/sysfs-class-remoteproc index d188afebc8ba..c3afe9fab646 100644 --- a/Documentation/ABI/testing/sysfs-class-remoteproc +++ b/Documentation/ABI/testing/sysfs-class-remoteproc @@ -1,6 +1,6 @@ What: /sys/class/remoteproc/.../firmware Date: October 2016 -Contact: Matt Redfearn +Contact: Matt Redfearn Description: Remote processor firmware Reports the name of the firmware currently loaded to the @@ -11,7 +11,7 @@ Description: Remote processor firmware What: /sys/class/remoteproc/.../state Date: October 2016 -Contact: Matt Redfearn +Contact: Matt Redfearn Description: Remote processor state Reports the state of the remote processor, which will be one of: -- cgit v1.2.3 From 33b9ca1e53b45f7cacdba9d4fba5cb1387b26827 Mon Sep 17 00:00:00 2001 From: Mario Limonciello Date: Wed, 1 Nov 2017 14:25:30 -0500 Subject: platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens Currently userspace tools can access system tokens via the dcdbas kernel module and a SMI call that will cause the platform to execute SMM code. With a goal in mind of deprecating the dcdbas kernel module a different method for accessing these tokens from userspace needs to be created. This is intentionally marked to only be readable as a process with CAP_SYS_ADMIN as it can contain sensitive information about the platform's configuration. While adding this interface I found that some tokens are duplicated. These need to be ignored from sysfs to avoid duplicate files. MAINTAINERS was missing for this driver. Add myself and Pali to maintainers list for it. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Signed-off-by: Darren Hart (VMware) --- .../ABI/testing/sysfs-platform-dell-smbios | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-smbios (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-platform-dell-smbios b/Documentation/ABI/testing/sysfs-platform-dell-smbios new file mode 100644 index 000000000000..205d3b6361e0 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-dell-smbios @@ -0,0 +1,21 @@ +What: /sys/devices/platform//tokens/* +Date: November 2017 +KernelVersion: 4.15 +Contact: "Mario Limonciello" +Description: + A read-only description of Dell platform tokens + available on the machine. + + Each token attribute is available as a pair of + sysfs attributes readable by a process with + CAP_SYS_ADMIN. + + For example the token ID "5" would be available + as the following attributes: + + 0005_location + 0005_value + + Tokens will vary from machine to machine, and + only tokens available on that machine will be + displayed. -- cgit v1.2.3 From f2645fa317b8905b8934f06a0601d5b7fa66aba0 Mon Sep 17 00:00:00 2001 From: Mario Limonciello Date: Wed, 1 Nov 2017 14:25:36 -0500 Subject: platform/x86: dell-smbios-wmi: introduce userspace interface It's important for the driver to provide a R/W ioctl to ensure that two competing userspace processes don't race to provide or read each others data. This userspace character device will be used to perform SMBIOS calls from any applications. It provides an ioctl that will allow passing the WMI calling interface buffer between userspace and kernel space. This character device is intended to deprecate the dcdbas kernel module and the interface that it provides to userspace. To perform an SMBIOS IOCTL call using the character device userspace will perform a read() on the the character device. The WMI bus will provide a u64 variable containing the necessary size of the IOCTL buffer. The API for interacting with this interface is defined in documentation as well as the WMI uapi header provides the format of the structures. Not all userspace requests will be accepted. The dell-smbios filtering functionality will be used to prevent access to certain tokens and calls. All whitelisted commands and tokens are now shared out to userspace so applications don't need to define them in their own headers. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Signed-off-by: Darren Hart (VMware) --- Documentation/ABI/testing/dell-smbios-wmi | 41 +++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/ABI/testing/dell-smbios-wmi (limited to 'Documentation') diff --git a/Documentation/ABI/testing/dell-smbios-wmi b/Documentation/ABI/testing/dell-smbios-wmi new file mode 100644 index 000000000000..fc919ce16008 --- /dev/null +++ b/Documentation/ABI/testing/dell-smbios-wmi @@ -0,0 +1,41 @@ +What: /dev/wmi/dell-smbios +Date: November 2017 +KernelVersion: 4.15 +Contact: "Mario Limonciello" +Description: + Perform SMBIOS calls on supported Dell machines. + through the Dell ACPI-WMI interface. + + IOCTL's and buffer formats are defined in: + + + 1) To perform an SMBIOS call from userspace, you'll need to + first determine the minimum size of the calling interface + buffer for your machine. + Platforms that contain larger buffers can return larger + objects from the system firmware. + Commonly this size is either 4k or 32k. + + To determine the size of the buffer read() a u64 dword from + the WMI character device /dev/wmi/dell-smbios. + + 2) After you've determined the minimum size of the calling + interface buffer, you can allocate a structure that represents + the structure documented above. + + 3) In the 'length' object store the size of the buffer you + determined above and allocated. + + 4) In this buffer object, prepare as necessary for the SMBIOS + call you're interested in. Typically SMBIOS buffers have + "class", "select", and "input" defined to values that coincide + with the data you are interested in. + Documenting class/select/input values is outside of the scope + of this documentation. Check with the libsmbios project for + further documentation on these values. + + 6) Run the call by using ioctl() as described in the header. + + 7) The output will be returned in the buffer object. + + 8) Be sure to free up your allocated object. -- cgit v1.2.3 From fa687604fa750f934dbbebb7a5b6cda570e88cb8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20F=C3=A4rber?= Date: Mon, 11 Sep 2017 00:31:52 +0200 Subject: dt-bindings: arm: actions: Add CubieBoard6 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Define a compatible string for Cubietech CubieBoard6. Cc: support@cubietech.com Acked-by: Rob Herring Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/actions.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/actions.txt b/Documentation/devicetree/bindings/arm/actions.txt index 3bc7ea575564..ced764a8549e 100644 --- a/Documentation/devicetree/bindings/arm/actions.txt +++ b/Documentation/devicetree/bindings/arm/actions.txt @@ -21,6 +21,7 @@ Boards: Root node property compatible must contain, depending on board: + - Cubietech CubieBoard6: "cubietech,cubieboard6" - LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar" -- cgit v1.2.3 From 707f5a0ff5e5c21422d5fb8797782d3fe8b51f35 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Fri, 3 Nov 2017 07:54:11 +0100 Subject: doc: add Willy Tarreau to the list of enforcement statement endorsers add me to the list. Signed-off-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index d03b1a419dd6..3f2d44e492c1 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -137,6 +137,7 @@ we might work for today, have in the past, or will in the future. - K.Y. Srinivasan - Heiko Stuebner - Jiri Kosina (SUSE) + - Willy Tarreau - Dmitry Torokhov - Linus Torvalds - Thierry Reding -- cgit v1.2.3 From e1b48c209ebf99487f9941193b6c4e0a684a7c8c Mon Sep 17 00:00:00 2001 From: Frank Rowand Date: Fri, 3 Nov 2017 12:50:58 -0700 Subject: Documentation: Add Frank Rowand to list of enforcement statement endorsers Add my name to the list. Signed-off-by: Frank Rowand Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index 3f2d44e492c1..b3170671a1df 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -131,6 +131,7 @@ we might work for today, have in the past, or will in the future. - Joerg Roedel - Leon Romanovsky - Steven Rostedt (VMware) + - Frank Rowand - Ivan Safonov - Anna Schumaker - Jes Sorensen -- cgit v1.2.3 From 4d420a6a9ddd72bd25baa6e667dd0581506eeacb Mon Sep 17 00:00:00 2001 From: Andrew Jeffery Date: Fri, 3 Nov 2017 15:53:02 +1100 Subject: pmbus: Add driver for Maxim MAX31785 Intelligent Fan Controller The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan management with temperature and remote voltage sensing. It supports various fan control features, including PWM frequency control, temperature hysteresis, dual tachometer measurements, and fan health monitoring. This patch presents a basic driver using only the existing features of the PMBus subsystem. Signed-off-by: Andrew Jeffery [groeck: Modified description to clarify that fan control is not yet provided] Signed-off-by: Guenter Roeck --- Documentation/hwmon/max31785 | 51 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/hwmon/max31785 (limited to 'Documentation') diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785 new file mode 100644 index 000000000000..45fb6093dec2 --- /dev/null +++ b/Documentation/hwmon/max31785 @@ -0,0 +1,51 @@ +Kernel driver max31785 +====================== + +Supported chips: + * Maxim MAX31785, MAX31785A + Prefix: 'max31785' or 'max31785a' + Addresses scanned: - + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf + +Author: Andrew Jeffery + +Description +----------- + +The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan +management with temperature and remote voltage sensing. Various fan control +features are provided, including PWM frequency control, temperature hysteresis, +dual tachometer measurements, and fan health monitoring. + +For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of the +two in the fan[1-4]_input attributes. + +Usage Notes +----------- + +This driver does not probe for PMBus devices. You will have to instantiate +devices explicitly. + +Sysfs attributes +---------------- + +fan[1-4]_alarm Fan alarm. +fan[1-4]_fault Fan fault. +fan[1-4]_input Fan RPM. + +in[1-6]_crit Critical maximum output voltage +in[1-6]_crit_alarm Output voltage critical high alarm +in[1-6]_input Measured output voltage +in[1-6]_label "vout[18-23]" +in[1-6]_lcrit Critical minimum output voltage +in[1-6]_lcrit_alarm Output voltage critical low alarm +in[1-6]_max Maximum output voltage +in[1-6]_max_alarm Output voltage high alarm +in[1-6]_min Minimum output voltage +in[1-6]_min_alarm Output voltage low alarm + +temp[1-11]_crit Critical high temperature +temp[1-11]_crit_alarm Chip temperature critical high alarm +temp[1-11]_input Measured temperature +temp[1-11]_max Maximum temperature +temp[1-11]_max_alarm Chip temperature high alarm -- cgit v1.2.3 From 1f2556916d974cfb62b6af51660186b5f58bd869 Mon Sep 17 00:00:00 2001 From: Priyaranjan Jha Date: Fri, 3 Nov 2017 16:38:48 -0700 Subject: tcp: higher throughput under reordering with adaptive RACK reordering wnd Currently TCP RACK loss detection does not work well if packets are being reordered beyond its static reordering window (min_rtt/4).Under such reordering it may falsely trigger loss recoveries and reduce TCP throughput significantly. This patch improves that by increasing and reducing the reordering window based on DSACK, which is now supported in major TCP implementations. It makes RACK's reo_wnd adaptive based on DSACK and no. of recoveries. - If DSACK is received, increment reo_wnd by min_rtt/4 (upper bounded by srtt), since there is possibility that spurious retransmission was due to reordering delay longer than reo_wnd. - Persist the current reo_wnd value for TCP_RACK_RECOVERY_THRESH (16) no. of successful recoveries (accounts for full DSACK-based loss recovery undo). After that, reset it to default (min_rtt/4). - At max, reo_wnd is incremented only once per rtt. So that the new DSACK on which we are reacting, is due to the spurious retx (approx) after the reo_wnd has been updated last time. - reo_wnd is tracked in terms of steps (of min_rtt/4), rather than absolute value to account for change in rtt. In our internal testing, we observed significant increase in throughput, in scenarios where reordering exceeds min_rtt/4 (previous static value). Signed-off-by: Priyaranjan Jha Signed-off-by: Yuchung Cheng Signed-off-by: Neal Cardwell Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index e6661b205f72..54410a1d4065 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -454,6 +454,7 @@ tcp_recovery - INTEGER RACK: 0x1 enables the RACK loss detection for fast detection of lost retransmissions and tail drops. + RACK: 0x2 makes RACK's reordering window static (min_rtt/4). Default: 0x1 -- cgit v1.2.3 From b4d9421098f863bc7f92a7be8fb21e32fa5df99e Mon Sep 17 00:00:00 2001 From: Steven Rostedt Date: Tue, 31 Oct 2017 10:07:05 -0400 Subject: ftrace/docs: Add documentation on how to use ftrace from within the kernel With the coming removal of jprobes, using ftrace callbacks is one of the utilities that replace the jprobes functionality. Having a document that explains how to use ftrace as such will help in the transition from jprobes to ftrace. This document is for kernel developers that require attaching a callback to a function within the kernel. Link: http://lkml.kernel.org/r/150724519527.5014.10207042218696587159.stgit@devbox Signed-off-by: Steven Rostedt (VMware) [jc: fixed one formatting issue that broke the docs build] Signed-off-by: Jonathan Corbet --- Documentation/trace/ftrace-uses.rst | 293 ++++++++++++++++++++++++++++++++++++ 1 file changed, 293 insertions(+) create mode 100644 Documentation/trace/ftrace-uses.rst (limited to 'Documentation') diff --git a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst new file mode 100644 index 000000000000..8494a801d341 --- /dev/null +++ b/Documentation/trace/ftrace-uses.rst @@ -0,0 +1,293 @@ +================================= +Using ftrace to hook to functions +================================= + +.. Copyright 2017 VMware Inc. +.. Author: Steven Rostedt +.. License: The GNU Free Documentation License, Version 1.2 +.. (dual licensed under the GPL v2) + +Written for: 4.14 + +Introduction +============ + +The ftrace infrastructure was originially created to attach callbacks to the +beginning of functions in order to record and trace the flow of the kernel. +But callbacks to the start of a function can have other use cases. Either +for live kernel patching, or for security monitoring. This document describes +how to use ftrace to implement your own function callbacks. + + +The ftrace context +================== + +WARNING: The ability to add a callback to almost any function within the +kernel comes with risks. A callback can be called from any context +(normal, softirq, irq, and NMI). Callbacks can also be called just before +going to idle, during CPU bring up and takedown, or going to user space. +This requires extra care to what can be done inside a callback. A callback +can be called outside the protective scope of RCU. + +The ftrace infrastructure has some protections agains recursions and RCU +but one must still be very careful how they use the callbacks. + + +The ftrace_ops structure +======================== + +To register a function callback, a ftrace_ops is required. This structure +is used to tell ftrace what function should be called as the callback +as well as what protections the callback will perform and not require +ftrace to handle. + +There is only one field that is needed to be set when registering +an ftrace_ops with ftrace:: + +.. code-block: c + + struct ftrace_ops ops = { + .func = my_callback_func, + .flags = MY_FTRACE_FLAGS + .private = any_private_data_structure, + }; + +Both .flags and .private are optional. Only .func is required. + +To enable tracing call:: + +.. c:function:: register_ftrace_function(&ops); + +To disable tracing call:: + +.. c:function:: unregister_ftrace_function(&ops); + +The above is defined by including the header:: + +.. c:function:: #include + +The registered callback will start being called some time after the +register_ftrace_function() is called and before it returns. The exact time +that callbacks start being called is dependent upon architecture and scheduling +of services. The callback itself will have to handle any synchronization if it +must begin at an exact moment. + +The unregister_ftrace_function() will guarantee that the callback is +no longer being called by functions after the unregister_ftrace_function() +returns. Note that to perform this guarantee, the unregister_ftrace_function() +may take some time to finish. + + +The callback function +===================== + +The prototype of the callback function is as follows (as of v4.14):: + +.. code-block: c + + void callback_func(unsigned long ip, unsigned long parent_ip, + struct ftrace_ops *op, struct pt_regs *regs); + +@ip + This is the instruction pointer of the function that is being traced. + (where the fentry or mcount is within the function) + +@parent_ip + This is the instruction pointer of the function that called the + the function being traced (where the call of the function occurred). + +@op + This is a pointer to ftrace_ops that was used to register the callback. + This can be used to pass data to the callback via the private pointer. + +@regs + If the FTRACE_OPS_FL_SAVE_REGS or FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED + flags are set in the ftrace_ops structure, then this will be pointing + to the pt_regs structure like it would be if an breakpoint was placed + at the start of the function where ftrace was tracing. Otherwise it + either contains garbage, or NULL. + + +The ftrace FLAGS +================ + +The ftrace_ops flags are all defined and documented in include/linux/ftrace.h. +Some of the flags are used for internal infrastructure of ftrace, but the +ones that users should be aware of are the following: + +FTRACE_OPS_FL_SAVE_REGS + If the callback requires reading or modifying the pt_regs + passed to the callback, then it must set this flag. Registering + a ftrace_ops with this flag set on an architecture that does not + support passing of pt_regs to the callback will fail. + +FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED + Similar to SAVE_REGS but the registering of a + ftrace_ops on an architecture that does not support passing of regs + will not fail with this flag set. But the callback must check if + regs is NULL or not to determine if the architecture supports it. + +FTRACE_OPS_FL_RECURSION_SAFE + By default, a wrapper is added around the callback to + make sure that recursion of the function does not occur. That is, + if a function that is called as a result of the callback's execution + is also traced, ftrace will prevent the callback from being called + again. But this wrapper adds some overhead, and if the callback is + safe from recursion, it can set this flag to disable the ftrace + protection. + + Note, if this flag is set, and recursion does occur, it could cause + the system to crash, and possibly reboot via a triple fault. + + It is OK if another callback traces a function that is called by a + callback that is marked recursion safe. Recursion safe callbacks + must never trace any function that are called by the callback + itself or any nested functions that those functions call. + + If this flag is set, it is possible that the callback will also + be called with preemption enabled (when CONFIG_PREEMPT is set), + but this is not guaranteed. + +FTRACE_OPS_FL_IPMODIFY + Requires FTRACE_OPS_FL_SAVE_REGS set. If the callback is to "hijack" + the traced function (have another function called instead of the + traced function), it requires setting this flag. This is what live + kernel patches uses. Without this flag the pt_regs->ip can not be + modified. + + Note, only one ftrace_ops with FTRACE_OPS_FL_IPMODIFY set may be + registered to any given function at a time. + +FTRACE_OPS_FL_RCU + If this is set, then the callback will only be called by functions + where RCU is "watching". This is required if the callback function + performs any rcu_read_lock() operation. + + RCU stops watching when the system goes idle, the time when a CPU + is taken down and comes back online, and when entering from kernel + to user space and back to kernel space. During these transitions, + a callback may be executed and RCU synchronization will not protect + it. + + +Filtering which functions to trace +================================== + +If a callback is only to be called from specific functions, a filter must be +set up. The filters are added by name, or ip if it is known. + +.. code-block: c + + int ftrace_set_filter(struct ftrace_ops *ops, unsigned char *buf, + int len, int reset); + +@ops + The ops to set the filter with + +@buf + The string that holds the function filter text. +@len + The length of the string. + +@reset + Non-zero to reset all filters before applying this filter. + +Filters denote which functions should be enabled when tracing is enabled. +If @buf is NULL and reset is set, all functions will be enabled for tracing. + +The @buf can also be a glob expression to enable all functions that +match a specific pattern. + +See Filter Commands in :file:`Documentation/trace/ftrace.txt`. + +To just trace the schedule function:: + +.. code-block: c + + ret = ftrace_set_filter(&ops, "schedule", strlen("schedule"), 0); + +To add more functions, call the ftrace_set_filter() more than once with the +@reset parameter set to zero. To remove the current filter set and replace it +with new functions defined by @buf, have @reset be non-zero. + +To remove all the filtered functions and trace all functions:: + +.. code-block: c + + ret = ftrace_set_filter(&ops, NULL, 0, 1); + + +Sometimes more than one function has the same name. To trace just a specific +function in this case, ftrace_set_filter_ip() can be used. + +.. code-block: c + + ret = ftrace_set_filter_ip(&ops, ip, 0, 0); + +Although the ip must be the address where the call to fentry or mcount is +located in the function. This function is used by perf and kprobes that +gets the ip address from the user (usually using debug info from the kernel). + +If a glob is used to set the filter, functions can be added to a "notrace" +list that will prevent those functions from calling the callback. +The "notrace" list takes precedence over the "filter" list. If the +two lists are non-empty and contain the same functions, the callback will not +be called by any function. + +An empty "notrace" list means to allow all functions defined by the filter +to be traced. + +.. code-block: c + + int ftrace_set_notrace(struct ftrace_ops *ops, unsigned char *buf, + int len, int reset); + +This takes the same parameters as ftrace_set_filter() but will add the +functions it finds to not be traced. This is a separate list from the +filter list, and this function does not modify the filter list. + +A non-zero @reset will clear the "notrace" list before adding functions +that match @buf to it. + +Clearing the "notrace" list is the same as clearing the filter list + +.. code-block: c + + ret = ftrace_set_notrace(&ops, NULL, 0, 1); + +The filter and notrace lists may be changed at any time. If only a set of +functions should call the callback, it is best to set the filters before +registering the callback. But the changes may also happen after the callback +has been registered. + +If a filter is in place, and the @reset is non-zero, and @buf contains a +matching glob to functions, the switch will happen during the time of +the ftrace_set_filter() call. At no time will all functions call the callback. + +.. code-block: c + + ftrace_set_filter(&ops, "schedule", strlen("schedule"), 1); + + register_ftrace_function(&ops); + + msleep(10); + + ftrace_set_filter(&ops, "try_to_wake_up", strlen("try_to_wake_up"), 1); + +is not the same as: + +.. code-block: c + + ftrace_set_filter(&ops, "schedule", strlen("schedule"), 1); + + register_ftrace_function(&ops); + + msleep(10); + + ftrace_set_filter(&ops, NULL, 0, 1); + + ftrace_set_filter(&ops, "try_to_wake_up", strlen("try_to_wake_up"), 0); + +As the latter will have a short time where all functions will call +the callback, between the time of the reset, and the time of the +new setting of the filter. -- cgit v1.2.3 From 8a0698c19e37019562d2504d4d724811d7fd411c Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Fri, 3 Nov 2017 10:19:37 +0530 Subject: dmaengine: doc: Add ReST style dmaengine document This removes the index file and adds the index.rst as placeholder and update driver-api index to add dmaengine. As a consequence dmaengine documentation will be in driver-api/ Signed-off-by: Vinod Koul Signed-off-by: Jonathan Corbet --- Documentation/dmaengine/00-INDEX | 8 -------- Documentation/driver-api/dmaengine/index.rst | 13 +++++++++++++ Documentation/driver-api/index.rst | 1 + 3 files changed, 14 insertions(+), 8 deletions(-) delete mode 100644 Documentation/dmaengine/00-INDEX create mode 100644 Documentation/driver-api/dmaengine/index.rst (limited to 'Documentation') diff --git a/Documentation/dmaengine/00-INDEX b/Documentation/dmaengine/00-INDEX deleted file mode 100644 index 07de6573d22b..000000000000 --- a/Documentation/dmaengine/00-INDEX +++ /dev/null @@ -1,8 +0,0 @@ -00-INDEX - - this file. -client.txt - -the DMA Engine API Guide. -dmatest.txt - - how to compile, configure and use the dmatest system. -provider.txt - - the DMA controller API. \ No newline at end of file diff --git a/Documentation/driver-api/dmaengine/index.rst b/Documentation/driver-api/dmaengine/index.rst new file mode 100644 index 000000000000..8c90a6443810 --- /dev/null +++ b/Documentation/driver-api/dmaengine/index.rst @@ -0,0 +1,13 @@ +======================= +DMAEngine documentation +======================= + +DMAEngine documentation provides documents for various aspects of DMAEngine +framework. + +.. only:: subproject + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 9c20624842b7..d17a9876b473 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -46,6 +46,7 @@ available subsections can be seen below. pinctl gpio misc_devices + dmaengine/index .. only:: subproject and html -- cgit v1.2.3 From 77fe661214d784878d666a226116057191de097b Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Fri, 3 Nov 2017 10:19:38 +0530 Subject: dmaengine: doc: ReSTize provider doc This moves and converts provider file with some format changes for RST style Signed-off-by: Vinod Koul Signed-off-by: Jonathan Corbet --- Documentation/dmaengine/provider.txt | 424 -------------------- Documentation/driver-api/dmaengine/index.rst | 11 + Documentation/driver-api/dmaengine/provider.rst | 508 ++++++++++++++++++++++++ 3 files changed, 519 insertions(+), 424 deletions(-) delete mode 100644 Documentation/dmaengine/provider.txt create mode 100644 Documentation/driver-api/dmaengine/provider.rst (limited to 'Documentation') diff --git a/Documentation/dmaengine/provider.txt b/Documentation/dmaengine/provider.txt deleted file mode 100644 index 5dbe054a40ad..000000000000 --- a/Documentation/dmaengine/provider.txt +++ /dev/null @@ -1,424 +0,0 @@ -DMAengine controller documentation -================================== - -Hardware Introduction -+++++++++++++++++++++ - -Most of the Slave DMA controllers have the same general principles of -operations. - -They have a given number of channels to use for the DMA transfers, and -a given number of requests lines. - -Requests and channels are pretty much orthogonal. Channels can be used -to serve several to any requests. To simplify, channels are the -entities that will be doing the copy, and requests what endpoints are -involved. - -The request lines actually correspond to physical lines going from the -DMA-eligible devices to the controller itself. Whenever the device -will want to start a transfer, it will assert a DMA request (DRQ) by -asserting that request line. - -A very simple DMA controller would only take into account a single -parameter: the transfer size. At each clock cycle, it would transfer a -byte of data from one buffer to another, until the transfer size has -been reached. - -That wouldn't work well in the real world, since slave devices might -require a specific number of bits to be transferred in a single -cycle. For example, we may want to transfer as much data as the -physical bus allows to maximize performances when doing a simple -memory copy operation, but our audio device could have a narrower FIFO -that requires data to be written exactly 16 or 24 bits at a time. This -is why most if not all of the DMA controllers can adjust this, using a -parameter called the transfer width. - -Moreover, some DMA controllers, whenever the RAM is used as a source -or destination, can group the reads or writes in memory into a buffer, -so instead of having a lot of small memory accesses, which is not -really efficient, you'll get several bigger transfers. This is done -using a parameter called the burst size, that defines how many single -reads/writes it's allowed to do without the controller splitting the -transfer into smaller sub-transfers. - -Our theoretical DMA controller would then only be able to do transfers -that involve a single contiguous block of data. However, some of the -transfers we usually have are not, and want to copy data from -non-contiguous buffers to a contiguous buffer, which is called -scatter-gather. - -DMAEngine, at least for mem2dev transfers, require support for -scatter-gather. So we're left with two cases here: either we have a -quite simple DMA controller that doesn't support it, and we'll have to -implement it in software, or we have a more advanced DMA controller, -that implements in hardware scatter-gather. - -The latter are usually programmed using a collection of chunks to -transfer, and whenever the transfer is started, the controller will go -over that collection, doing whatever we programmed there. - -This collection is usually either a table or a linked list. You will -then push either the address of the table and its number of elements, -or the first item of the list to one channel of the DMA controller, -and whenever a DRQ will be asserted, it will go through the collection -to know where to fetch the data from. - -Either way, the format of this collection is completely dependent on -your hardware. Each DMA controller will require a different structure, -but all of them will require, for every chunk, at least the source and -destination addresses, whether it should increment these addresses or -not and the three parameters we saw earlier: the burst size, the -transfer width and the transfer size. - -The one last thing is that usually, slave devices won't issue DRQ by -default, and you have to enable this in your slave device driver first -whenever you're willing to use DMA. - -These were just the general memory-to-memory (also called mem2mem) or -memory-to-device (mem2dev) kind of transfers. Most devices often -support other kind of transfers or memory operations that dmaengine -support and will be detailed later in this document. - -DMA Support in Linux -++++++++++++++++++++ - -Historically, DMA controller drivers have been implemented using the -async TX API, to offload operations such as memory copy, XOR, -cryptography, etc., basically any memory to memory operation. - -Over time, the need for memory to device transfers arose, and -dmaengine was extended. Nowadays, the async TX API is written as a -layer on top of dmaengine, and acts as a client. Still, dmaengine -accommodates that API in some cases, and made some design choices to -ensure that it stayed compatible. - -For more information on the Async TX API, please look the relevant -documentation file in Documentation/crypto/async-tx-api.txt. - -DMAEngine Registration -++++++++++++++++++++++ - -struct dma_device Initialization --------------------------------- - -Just like any other kernel framework, the whole DMAEngine registration -relies on the driver filling a structure and registering against the -framework. In our case, that structure is dma_device. - -The first thing you need to do in your driver is to allocate this -structure. Any of the usual memory allocators will do, but you'll also -need to initialize a few fields in there: - - * channels: should be initialized as a list using the - INIT_LIST_HEAD macro for example - - * src_addr_widths: - - should contain a bitmask of the supported source transfer width - - * dst_addr_widths: - - should contain a bitmask of the supported destination transfer - width - - * directions: - - should contain a bitmask of the supported slave directions - (i.e. excluding mem2mem transfers) - - * residue_granularity: - - Granularity of the transfer residue reported to dma_set_residue. - - This can be either: - + Descriptor - -> Your device doesn't support any kind of residue - reporting. The framework will only know that a particular - transaction descriptor is done. - + Segment - -> Your device is able to report which chunks have been - transferred - + Burst - -> Your device is able to report which burst have been - transferred - - * dev: should hold the pointer to the struct device associated - to your current driver instance. - -Supported transaction types ---------------------------- - -The next thing you need is to set which transaction types your device -(and driver) supports. - -Our dma_device structure has a field called cap_mask that holds the -various types of transaction supported, and you need to modify this -mask using the dma_cap_set function, with various flags depending on -transaction types you support as an argument. - -All those capabilities are defined in the dma_transaction_type enum, -in include/linux/dmaengine.h - -Currently, the types available are: - * DMA_MEMCPY - - The device is able to do memory to memory copies - - * DMA_XOR - - The device is able to perform XOR operations on memory areas - - Used to accelerate XOR intensive tasks, such as RAID5 - - * DMA_XOR_VAL - - The device is able to perform parity check using the XOR - algorithm against a memory buffer. - - * DMA_PQ - - The device is able to perform RAID6 P+Q computations, P being a - simple XOR, and Q being a Reed-Solomon algorithm. - - * DMA_PQ_VAL - - The device is able to perform parity check using RAID6 P+Q - algorithm against a memory buffer. - - * DMA_INTERRUPT - - The device is able to trigger a dummy transfer that will - generate periodic interrupts - - Used by the client drivers to register a callback that will be - called on a regular basis through the DMA controller interrupt - - * DMA_PRIVATE - - The devices only supports slave transfers, and as such isn't - available for async transfers. - - * DMA_ASYNC_TX - - Must not be set by the device, and will be set by the framework - if needed - - /* TODO: What is it about? */ - - * DMA_SLAVE - - The device can handle device to memory transfers, including - scatter-gather transfers. - - While in the mem2mem case we were having two distinct types to - deal with a single chunk to copy or a collection of them, here, - we just have a single transaction type that is supposed to - handle both. - - If you want to transfer a single contiguous memory buffer, - simply build a scatter list with only one item. - - * DMA_CYCLIC - - The device can handle cyclic transfers. - - A cyclic transfer is a transfer where the chunk collection will - loop over itself, with the last item pointing to the first. - - It's usually used for audio transfers, where you want to operate - on a single ring buffer that you will fill with your audio data. - - * DMA_INTERLEAVE - - The device supports interleaved transfer. - - These transfers can transfer data from a non-contiguous buffer - to a non-contiguous buffer, opposed to DMA_SLAVE that can - transfer data from a non-contiguous data set to a continuous - destination buffer. - - It's usually used for 2d content transfers, in which case you - want to transfer a portion of uncompressed data directly to the - display to print it - -These various types will also affect how the source and destination -addresses change over time. - -Addresses pointing to RAM are typically incremented (or decremented) -after each transfer. In case of a ring buffer, they may loop -(DMA_CYCLIC). Addresses pointing to a device's register (e.g. a FIFO) -are typically fixed. - -Device operations ------------------ - -Our dma_device structure also requires a few function pointers in -order to implement the actual logic, now that we described what -operations we were able to perform. - -The functions that we have to fill in there, and hence have to -implement, obviously depend on the transaction types you reported as -supported. - - * device_alloc_chan_resources - * device_free_chan_resources - - These functions will be called whenever a driver will call - dma_request_channel or dma_release_channel for the first/last - time on the channel associated to that driver. - - They are in charge of allocating/freeing all the needed - resources in order for that channel to be useful for your - driver. - - These functions can sleep. - - * device_prep_dma_* - - These functions are matching the capabilities you registered - previously. - - These functions all take the buffer or the scatterlist relevant - for the transfer being prepared, and should create a hardware - descriptor or a list of hardware descriptors from it - - These functions can be called from an interrupt context - - Any allocation you might do should be using the GFP_NOWAIT - flag, in order not to potentially sleep, but without depleting - the emergency pool either. - - Drivers should try to pre-allocate any memory they might need - during the transfer setup at probe time to avoid putting to - much pressure on the nowait allocator. - - - It should return a unique instance of the - dma_async_tx_descriptor structure, that further represents this - particular transfer. - - - This structure can be initialized using the function - dma_async_tx_descriptor_init. - - You'll also need to set two fields in this structure: - + flags: - TODO: Can it be modified by the driver itself, or - should it be always the flags passed in the arguments - - + tx_submit: A pointer to a function you have to implement, - that is supposed to push the current - transaction descriptor to a pending queue, waiting - for issue_pending to be called. - - In this structure the function pointer callback_result can be - initialized in order for the submitter to be notified that a - transaction has completed. In the earlier code the function pointer - callback has been used. However it does not provide any status to the - transaction and will be deprecated. The result structure defined as - dmaengine_result that is passed in to callback_result has two fields: - + result: This provides the transfer result defined by - dmaengine_tx_result. Either success or some error - condition. - + residue: Provides the residue bytes of the transfer for those that - support residue. - - * device_issue_pending - - Takes the first transaction descriptor in the pending queue, - and starts the transfer. Whenever that transfer is done, it - should move to the next transaction in the list. - - This function can be called in an interrupt context - - * device_tx_status - - Should report the bytes left to go over on the given channel - - Should only care about the transaction descriptor passed as - argument, not the currently active one on a given channel - - The tx_state argument might be NULL - - Should use dma_set_residue to report it - - In the case of a cyclic transfer, it should only take into - account the current period. - - This function can be called in an interrupt context. - - * device_config - - Reconfigures the channel with the configuration given as - argument - - This command should NOT perform synchronously, or on any - currently queued transfers, but only on subsequent ones - - In this case, the function will receive a dma_slave_config - structure pointer as an argument, that will detail which - configuration to use. - - Even though that structure contains a direction field, this - field is deprecated in favor of the direction argument given to - the prep_* functions - - This call is mandatory for slave operations only. This should NOT be - set or expected to be set for memcpy operations. - If a driver support both, it should use this call for slave - operations only and not for memcpy ones. - - * device_pause - - Pauses a transfer on the channel - - This command should operate synchronously on the channel, - pausing right away the work of the given channel - - * device_resume - - Resumes a transfer on the channel - - This command should operate synchronously on the channel, - resuming right away the work of the given channel - - * device_terminate_all - - Aborts all the pending and ongoing transfers on the channel - - For aborted transfers the complete callback should not be called - - Can be called from atomic context or from within a complete - callback of a descriptor. Must not sleep. Drivers must be able - to handle this correctly. - - Termination may be asynchronous. The driver does not have to - wait until the currently active transfer has completely stopped. - See device_synchronize. - - * device_synchronize - - Must synchronize the termination of a channel to the current - context. - - Must make sure that memory for previously submitted - descriptors is no longer accessed by the DMA controller. - - Must make sure that all complete callbacks for previously - submitted descriptors have finished running and none are - scheduled to run. - - May sleep. - - -Misc notes (stuff that should be documented, but don't really know -where to put them) ------------------------------------------------------------------- - * dma_run_dependencies - - Should be called at the end of an async TX transfer, and can be - ignored in the slave transfers case. - - Makes sure that dependent operations are run before marking it - as complete. - - * dma_cookie_t - - it's a DMA transaction ID that will increment over time. - - Not really relevant any more since the introduction of virt-dma - that abstracts it away. - - * DMA_CTRL_ACK - - If clear, the descriptor cannot be reused by provider until the - client acknowledges receipt, i.e. has has a chance to establish any - dependency chains - - This can be acked by invoking async_tx_ack() - - If set, does not mean descriptor can be reused - - * DMA_CTRL_REUSE - - If set, the descriptor can be reused after being completed. It should - not be freed by provider if this flag is set. - - The descriptor should be prepared for reuse by invoking - dmaengine_desc_set_reuse() which will set DMA_CTRL_REUSE. - - dmaengine_desc_set_reuse() will succeed only when channel support - reusable descriptor as exhibited by capabilities - - As a consequence, if a device driver wants to skip the dma_map_sg() and - dma_unmap_sg() in between 2 transfers, because the DMA'd data wasn't used, - it can resubmit the transfer right after its completion. - - Descriptor can be freed in few ways - - Clearing DMA_CTRL_REUSE by invoking dmaengine_desc_clear_reuse() - and submitting for last txn - - Explicitly invoking dmaengine_desc_free(), this can succeed only - when DMA_CTRL_REUSE is already set - - Terminating the channel - - * DMA_PREP_CMD - - If set, the client driver tells DMA controller that passed data in DMA - API is command data. - - Interpretation of command data is DMA controller specific. It can be - used for issuing commands to other peripherals/register reads/register - writes for which the descriptor should be in different format from - normal data descriptors. - -General Design Notes --------------------- - -Most of the DMAEngine drivers you'll see are based on a similar design -that handles the end of transfer interrupts in the handler, but defer -most work to a tasklet, including the start of a new transfer whenever -the previous transfer ended. - -This is a rather inefficient design though, because the inter-transfer -latency will be not only the interrupt latency, but also the -scheduling latency of the tasklet, which will leave the channel idle -in between, which will slow down the global transfer rate. - -You should avoid this kind of practice, and instead of electing a new -transfer in your tasklet, move that part to the interrupt handler in -order to have a shorter idle window (that we can't really avoid -anyway). - -Glossary --------- - -Burst: A number of consecutive read or write operations - that can be queued to buffers before being flushed to - memory. -Chunk: A contiguous collection of bursts -Transfer: A collection of chunks (be it contiguous or not) diff --git a/Documentation/driver-api/dmaengine/index.rst b/Documentation/driver-api/dmaengine/index.rst index 8c90a6443810..eee0377e0d7b 100644 --- a/Documentation/driver-api/dmaengine/index.rst +++ b/Documentation/driver-api/dmaengine/index.rst @@ -5,6 +5,17 @@ DMAEngine documentation DMAEngine documentation provides documents for various aspects of DMAEngine framework. +DMAEngine documentation +----------------------- + +This book helps with DMAengine internal APIs and guide for DMAEngine device +driver writers. + +.. toctree:: + :maxdepth: 1 + + provider + .. only:: subproject Indices diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst new file mode 100644 index 000000000000..814acb4d2294 --- /dev/null +++ b/Documentation/driver-api/dmaengine/provider.rst @@ -0,0 +1,508 @@ +================================== +DMAengine controller documentation +================================== + +Hardware Introduction +===================== + +Most of the Slave DMA controllers have the same general principles of +operations. + +They have a given number of channels to use for the DMA transfers, and +a given number of requests lines. + +Requests and channels are pretty much orthogonal. Channels can be used +to serve several to any requests. To simplify, channels are the +entities that will be doing the copy, and requests what endpoints are +involved. + +The request lines actually correspond to physical lines going from the +DMA-eligible devices to the controller itself. Whenever the device +will want to start a transfer, it will assert a DMA request (DRQ) by +asserting that request line. + +A very simple DMA controller would only take into account a single +parameter: the transfer size. At each clock cycle, it would transfer a +byte of data from one buffer to another, until the transfer size has +been reached. + +That wouldn't work well in the real world, since slave devices might +require a specific number of bits to be transferred in a single +cycle. For example, we may want to transfer as much data as the +physical bus allows to maximize performances when doing a simple +memory copy operation, but our audio device could have a narrower FIFO +that requires data to be written exactly 16 or 24 bits at a time. This +is why most if not all of the DMA controllers can adjust this, using a +parameter called the transfer width. + +Moreover, some DMA controllers, whenever the RAM is used as a source +or destination, can group the reads or writes in memory into a buffer, +so instead of having a lot of small memory accesses, which is not +really efficient, you'll get several bigger transfers. This is done +using a parameter called the burst size, that defines how many single +reads/writes it's allowed to do without the controller splitting the +transfer into smaller sub-transfers. + +Our theoretical DMA controller would then only be able to do transfers +that involve a single contiguous block of data. However, some of the +transfers we usually have are not, and want to copy data from +non-contiguous buffers to a contiguous buffer, which is called +scatter-gather. + +DMAEngine, at least for mem2dev transfers, require support for +scatter-gather. So we're left with two cases here: either we have a +quite simple DMA controller that doesn't support it, and we'll have to +implement it in software, or we have a more advanced DMA controller, +that implements in hardware scatter-gather. + +The latter are usually programmed using a collection of chunks to +transfer, and whenever the transfer is started, the controller will go +over that collection, doing whatever we programmed there. + +This collection is usually either a table or a linked list. You will +then push either the address of the table and its number of elements, +or the first item of the list to one channel of the DMA controller, +and whenever a DRQ will be asserted, it will go through the collection +to know where to fetch the data from. + +Either way, the format of this collection is completely dependent on +your hardware. Each DMA controller will require a different structure, +but all of them will require, for every chunk, at least the source and +destination addresses, whether it should increment these addresses or +not and the three parameters we saw earlier: the burst size, the +transfer width and the transfer size. + +The one last thing is that usually, slave devices won't issue DRQ by +default, and you have to enable this in your slave device driver first +whenever you're willing to use DMA. + +These were just the general memory-to-memory (also called mem2mem) or +memory-to-device (mem2dev) kind of transfers. Most devices often +support other kind of transfers or memory operations that dmaengine +support and will be detailed later in this document. + +DMA Support in Linux +==================== + +Historically, DMA controller drivers have been implemented using the +async TX API, to offload operations such as memory copy, XOR, +cryptography, etc., basically any memory to memory operation. + +Over time, the need for memory to device transfers arose, and +dmaengine was extended. Nowadays, the async TX API is written as a +layer on top of dmaengine, and acts as a client. Still, dmaengine +accommodates that API in some cases, and made some design choices to +ensure that it stayed compatible. + +For more information on the Async TX API, please look the relevant +documentation file in Documentation/crypto/async-tx-api.txt. + +DMAEngine APIs +============== + +``struct dma_device`` Initialization +------------------------------------ + +Just like any other kernel framework, the whole DMAEngine registration +relies on the driver filling a structure and registering against the +framework. In our case, that structure is dma_device. + +The first thing you need to do in your driver is to allocate this +structure. Any of the usual memory allocators will do, but you'll also +need to initialize a few fields in there: + +- channels: should be initialized as a list using the + INIT_LIST_HEAD macro for example + +- src_addr_widths: + should contain a bitmask of the supported source transfer width + +- dst_addr_widths: + should contain a bitmask of the supported destination transfer width + +- directions: + should contain a bitmask of the supported slave directions + (i.e. excluding mem2mem transfers) + +- residue_granularity: + + - Granularity of the transfer residue reported to dma_set_residue. + This can be either: + + - Descriptor + + - Your device doesn't support any kind of residue + reporting. The framework will only know that a particular + transaction descriptor is done. + + - Segment + + - Your device is able to report which chunks have been transferred + + - Burst + + - Your device is able to report which burst have been transferred + + - dev: should hold the pointer to the ``struct device`` associated + to your current driver instance. + +Supported transaction types +--------------------------- + +The next thing you need is to set which transaction types your device +(and driver) supports. + +Our ``dma_device structure`` has a field called cap_mask that holds the +various types of transaction supported, and you need to modify this +mask using the dma_cap_set function, with various flags depending on +transaction types you support as an argument. + +All those capabilities are defined in the ``dma_transaction_type enum``, +in ``include/linux/dmaengine.h`` + +Currently, the types available are: + +- DMA_MEMCPY + + - The device is able to do memory to memory copies + +- DMA_XOR + + - The device is able to perform XOR operations on memory areas + + - Used to accelerate XOR intensive tasks, such as RAID5 + +- DMA_XOR_VAL + + - The device is able to perform parity check using the XOR + algorithm against a memory buffer. + +- DMA_PQ + + - The device is able to perform RAID6 P+Q computations, P being a + simple XOR, and Q being a Reed-Solomon algorithm. + +- DMA_PQ_VAL + + - The device is able to perform parity check using RAID6 P+Q + algorithm against a memory buffer. + +- DMA_INTERRUPT + + - The device is able to trigger a dummy transfer that will + generate periodic interrupts + + - Used by the client drivers to register a callback that will be + called on a regular basis through the DMA controller interrupt + +- DMA_PRIVATE + + - The devices only supports slave transfers, and as such isn't + available for async transfers. + +- DMA_ASYNC_TX + + - Must not be set by the device, and will be set by the framework + if needed + + - TODO: What is it about? + +- DMA_SLAVE + + - The device can handle device to memory transfers, including + scatter-gather transfers. + + - While in the mem2mem case we were having two distinct types to + deal with a single chunk to copy or a collection of them, here, + we just have a single transaction type that is supposed to + handle both. + + - If you want to transfer a single contiguous memory buffer, + simply build a scatter list with only one item. + +- DMA_CYCLIC + + - The device can handle cyclic transfers. + + - A cyclic transfer is a transfer where the chunk collection will + loop over itself, with the last item pointing to the first. + + - It's usually used for audio transfers, where you want to operate + on a single ring buffer that you will fill with your audio data. + +- DMA_INTERLEAVE + + - The device supports interleaved transfer. + + - These transfers can transfer data from a non-contiguous buffer + to a non-contiguous buffer, opposed to DMA_SLAVE that can + transfer data from a non-contiguous data set to a continuous + destination buffer. + + - It's usually used for 2d content transfers, in which case you + want to transfer a portion of uncompressed data directly to the + display to print it + +These various types will also affect how the source and destination +addresses change over time. + +Addresses pointing to RAM are typically incremented (or decremented) +after each transfer. In case of a ring buffer, they may loop +(DMA_CYCLIC). Addresses pointing to a device's register (e.g. a FIFO) +are typically fixed. + +Device operations +----------------- + +Our dma_device structure also requires a few function pointers in +order to implement the actual logic, now that we described what +operations we were able to perform. + +The functions that we have to fill in there, and hence have to +implement, obviously depend on the transaction types you reported as +supported. + +- ``device_alloc_chan_resources`` + +- ``device_free_chan_resources`` + + - These functions will be called whenever a driver will call + ``dma_request_channel`` or ``dma_release_channel`` for the first/last + time on the channel associated to that driver. + + - They are in charge of allocating/freeing all the needed + resources in order for that channel to be useful for your driver. + + - These functions can sleep. + +- ``device_prep_dma_*`` + + - These functions are matching the capabilities you registered + previously. + + - These functions all take the buffer or the scatterlist relevant + for the transfer being prepared, and should create a hardware + descriptor or a list of hardware descriptors from it + + - These functions can be called from an interrupt context + + - Any allocation you might do should be using the GFP_NOWAIT + flag, in order not to potentially sleep, but without depleting + the emergency pool either. + + - Drivers should try to pre-allocate any memory they might need + during the transfer setup at probe time to avoid putting to + much pressure on the nowait allocator. + + - It should return a unique instance of the + ``dma_async_tx_descriptor structure``, that further represents this + particular transfer. + + - This structure can be initialized using the function + ``dma_async_tx_descriptor_init``. + + - You'll also need to set two fields in this structure: + + - flags: + TODO: Can it be modified by the driver itself, or + should it be always the flags passed in the arguments + + - tx_submit: A pointer to a function you have to implement, + that is supposed to push the current transaction descriptor to a + pending queue, waiting for issue_pending to be called. + + - In this structure the function pointer callback_result can be + initialized in order for the submitter to be notified that a + transaction has completed. In the earlier code the function pointer + callback has been used. However it does not provide any status to the + transaction and will be deprecated. The result structure defined as + ``dmaengine_result`` that is passed in to callback_result + has two fields: + + - result: This provides the transfer result defined by + ``dmaengine_tx_result``. Either success or some error condition. + + - residue: Provides the residue bytes of the transfer for those that + support residue. + +- ``device_issue_pending`` + + - Takes the first transaction descriptor in the pending queue, + and starts the transfer. Whenever that transfer is done, it + should move to the next transaction in the list. + + - This function can be called in an interrupt context + +- ``device_tx_status`` + + - Should report the bytes left to go over on the given channel + + - Should only care about the transaction descriptor passed as + argument, not the currently active one on a given channel + + - The tx_state argument might be NULL + + - Should use dma_set_residue to report it + + - In the case of a cyclic transfer, it should only take into + account the current period. + + - This function can be called in an interrupt context. + +- device_config + + - Reconfigures the channel with the configuration given as argument + + - This command should NOT perform synchronously, or on any + currently queued transfers, but only on subsequent ones + + - In this case, the function will receive a ``dma_slave_config`` + structure pointer as an argument, that will detail which + configuration to use. + + - Even though that structure contains a direction field, this + field is deprecated in favor of the direction argument given to + the prep_* functions + + - This call is mandatory for slave operations only. This should NOT be + set or expected to be set for memcpy operations. + If a driver support both, it should use this call for slave + operations only and not for memcpy ones. + +- device_pause + + - Pauses a transfer on the channel + + - This command should operate synchronously on the channel, + pausing right away the work of the given channel + +- device_resume + + - Resumes a transfer on the channel + + - This command should operate synchronously on the channel, + resuming right away the work of the given channel + +- device_terminate_all + + - Aborts all the pending and ongoing transfers on the channel + + - For aborted transfers the complete callback should not be called + + - Can be called from atomic context or from within a complete + callback of a descriptor. Must not sleep. Drivers must be able + to handle this correctly. + + - Termination may be asynchronous. The driver does not have to + wait until the currently active transfer has completely stopped. + See device_synchronize. + +- device_synchronize + + - Must synchronize the termination of a channel to the current + context. + + - Must make sure that memory for previously submitted + descriptors is no longer accessed by the DMA controller. + + - Must make sure that all complete callbacks for previously + submitted descriptors have finished running and none are + scheduled to run. + + - May sleep. + + +Misc notes +========== + +(stuff that should be documented, but don't really know +where to put them) + +``dma_run_dependencies`` + +- Should be called at the end of an async TX transfer, and can be + ignored in the slave transfers case. + +- Makes sure that dependent operations are run before marking it + as complete. + +dma_cookie_t + +- it's a DMA transaction ID that will increment over time. + +- Not really relevant any more since the introduction of ``virt-dma`` + that abstracts it away. + +DMA_CTRL_ACK + +- If clear, the descriptor cannot be reused by provider until the + client acknowledges receipt, i.e. has has a chance to establish any + dependency chains + +- This can be acked by invoking async_tx_ack() + +- If set, does not mean descriptor can be reused + +DMA_CTRL_REUSE + +- If set, the descriptor can be reused after being completed. It should + not be freed by provider if this flag is set. + +- The descriptor should be prepared for reuse by invoking + ``dmaengine_desc_set_reuse()`` which will set DMA_CTRL_REUSE. + +- ``dmaengine_desc_set_reuse()`` will succeed only when channel support + reusable descriptor as exhibited by capabilities + +- As a consequence, if a device driver wants to skip the + ``dma_map_sg()`` and ``dma_unmap_sg()`` in between 2 transfers, + because the DMA'd data wasn't used, it can resubmit the transfer right after + its completion. + +- Descriptor can be freed in few ways + + - Clearing DMA_CTRL_REUSE by invoking + ``dmaengine_desc_clear_reuse()`` and submitting for last txn + + - Explicitly invoking ``dmaengine_desc_free()``, this can succeed only + when DMA_CTRL_REUSE is already set + + - Terminating the channel + +- DMA_PREP_CMD + + - If set, the client driver tells DMA controller that passed data in DMA + API is command data. + + - Interpretation of command data is DMA controller specific. It can be + used for issuing commands to other peripherals/register reads/register + writes for which the descriptor should be in different format from + normal data descriptors. + +General Design Notes +==================== + +Most of the DMAEngine drivers you'll see are based on a similar design +that handles the end of transfer interrupts in the handler, but defer +most work to a tasklet, including the start of a new transfer whenever +the previous transfer ended. + +This is a rather inefficient design though, because the inter-transfer +latency will be not only the interrupt latency, but also the +scheduling latency of the tasklet, which will leave the channel idle +in between, which will slow down the global transfer rate. + +You should avoid this kind of practice, and instead of electing a new +transfer in your tasklet, move that part to the interrupt handler in +order to have a shorter idle window (that we can't really avoid +anyway). + +Glossary +======== + +- Burst: A number of consecutive read or write operations that + can be queued to buffers before being flushed to memory. + +- Chunk: A contiguous collection of bursts + +- Transfer: A collection of chunks (be it contiguous or not) -- cgit v1.2.3 From eeb1c6435293e9d3c30b21579bd5154c013f2843 Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Fri, 3 Nov 2017 10:19:39 +0530 Subject: dmaengine: doc: ReSTize client API doc This converts and moves client API file with some format changes for RST style Signed-off-by: Vinod Koul Signed-off-by: Jonathan Corbet --- Documentation/dmaengine/client.txt | 222 --------------------- Documentation/driver-api/dmaengine/client.rst | 275 ++++++++++++++++++++++++++ Documentation/driver-api/dmaengine/index.rst | 11 ++ 3 files changed, 286 insertions(+), 222 deletions(-) delete mode 100644 Documentation/dmaengine/client.txt create mode 100644 Documentation/driver-api/dmaengine/client.rst (limited to 'Documentation') diff --git a/Documentation/dmaengine/client.txt b/Documentation/dmaengine/client.txt deleted file mode 100644 index c72b4563de10..000000000000 --- a/Documentation/dmaengine/client.txt +++ /dev/null @@ -1,222 +0,0 @@ - DMA Engine API Guide - ==================== - - Vinod Koul - -NOTE: For DMA Engine usage in async_tx please see: - Documentation/crypto/async-tx-api.txt - - -Below is a guide to device driver writers on how to use the Slave-DMA API of the -DMA Engine. This is applicable only for slave DMA usage only. - -The slave DMA usage consists of following steps: -1. Allocate a DMA slave channel -2. Set slave and controller specific parameters -3. Get a descriptor for transaction -4. Submit the transaction -5. Issue pending requests and wait for callback notification - -1. Allocate a DMA slave channel - - Channel allocation is slightly different in the slave DMA context, - client drivers typically need a channel from a particular DMA - controller only and even in some cases a specific channel is desired. - To request a channel dma_request_chan() API is used. - - Interface: - struct dma_chan *dma_request_chan(struct device *dev, const char *name); - - Which will find and return the 'name' DMA channel associated with the 'dev' - device. The association is done via DT, ACPI or board file based - dma_slave_map matching table. - - A channel allocated via this interface is exclusive to the caller, - until dma_release_channel() is called. - -2. Set slave and controller specific parameters - - Next step is always to pass some specific information to the DMA - driver. Most of the generic information which a slave DMA can use - is in struct dma_slave_config. This allows the clients to specify - DMA direction, DMA addresses, bus widths, DMA burst lengths etc - for the peripheral. - - If some DMA controllers have more parameters to be sent then they - should try to embed struct dma_slave_config in their controller - specific structure. That gives flexibility to client to pass more - parameters, if required. - - Interface: - int dmaengine_slave_config(struct dma_chan *chan, - struct dma_slave_config *config) - - Please see the dma_slave_config structure definition in dmaengine.h - for a detailed explanation of the struct members. Please note - that the 'direction' member will be going away as it duplicates the - direction given in the prepare call. - -3. Get a descriptor for transaction - - For slave usage the various modes of slave transfers supported by the - DMA-engine are: - - slave_sg - DMA a list of scatter gather buffers from/to a peripheral - dma_cyclic - Perform a cyclic DMA operation from/to a peripheral till the - operation is explicitly stopped. - interleaved_dma - This is common to Slave as well as M2M clients. For slave - address of devices' fifo could be already known to the driver. - Various types of operations could be expressed by setting - appropriate values to the 'dma_interleaved_template' members. - - A non-NULL return of this transfer API represents a "descriptor" for - the given transaction. - - Interface: - struct dma_async_tx_descriptor *dmaengine_prep_slave_sg( - struct dma_chan *chan, struct scatterlist *sgl, - unsigned int sg_len, enum dma_data_direction direction, - unsigned long flags); - - struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic( - struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len, - size_t period_len, enum dma_data_direction direction); - - struct dma_async_tx_descriptor *dmaengine_prep_interleaved_dma( - struct dma_chan *chan, struct dma_interleaved_template *xt, - unsigned long flags); - - The peripheral driver is expected to have mapped the scatterlist for - the DMA operation prior to calling dmaengine_prep_slave_sg(), and must - keep the scatterlist mapped until the DMA operation has completed. - The scatterlist must be mapped using the DMA struct device. - If a mapping needs to be synchronized later, dma_sync_*_for_*() must be - called using the DMA struct device, too. - So, normal setup should look like this: - - nr_sg = dma_map_sg(chan->device->dev, sgl, sg_len); - if (nr_sg == 0) - /* error */ - - desc = dmaengine_prep_slave_sg(chan, sgl, nr_sg, direction, flags); - - Once a descriptor has been obtained, the callback information can be - added and the descriptor must then be submitted. Some DMA engine - drivers may hold a spinlock between a successful preparation and - submission so it is important that these two operations are closely - paired. - - Note: - Although the async_tx API specifies that completion callback - routines cannot submit any new operations, this is not the - case for slave/cyclic DMA. - - For slave DMA, the subsequent transaction may not be available - for submission prior to callback function being invoked, so - slave DMA callbacks are permitted to prepare and submit a new - transaction. - - For cyclic DMA, a callback function may wish to terminate the - DMA via dmaengine_terminate_async(). - - Therefore, it is important that DMA engine drivers drop any - locks before calling the callback function which may cause a - deadlock. - - Note that callbacks will always be invoked from the DMA - engines tasklet, never from interrupt context. - -4. Submit the transaction - - Once the descriptor has been prepared and the callback information - added, it must be placed on the DMA engine drivers pending queue. - - Interface: - dma_cookie_t dmaengine_submit(struct dma_async_tx_descriptor *desc) - - This returns a cookie can be used to check the progress of DMA engine - activity via other DMA engine calls not covered in this document. - - dmaengine_submit() will not start the DMA operation, it merely adds - it to the pending queue. For this, see step 5, dma_async_issue_pending. - -5. Issue pending DMA requests and wait for callback notification - - The transactions in the pending queue can be activated by calling the - issue_pending API. If channel is idle then the first transaction in - queue is started and subsequent ones queued up. - - On completion of each DMA operation, the next in queue is started and - a tasklet triggered. The tasklet will then call the client driver - completion callback routine for notification, if set. - - Interface: - void dma_async_issue_pending(struct dma_chan *chan); - -Further APIs: - -1. int dmaengine_terminate_sync(struct dma_chan *chan) - int dmaengine_terminate_async(struct dma_chan *chan) - int dmaengine_terminate_all(struct dma_chan *chan) /* DEPRECATED */ - - This causes all activity for the DMA channel to be stopped, and may - discard data in the DMA FIFO which hasn't been fully transferred. - No callback functions will be called for any incomplete transfers. - - Two variants of this function are available. - - dmaengine_terminate_async() might not wait until the DMA has been fully - stopped or until any running complete callbacks have finished. But it is - possible to call dmaengine_terminate_async() from atomic context or from - within a complete callback. dmaengine_synchronize() must be called before it - is safe to free the memory accessed by the DMA transfer or free resources - accessed from within the complete callback. - - dmaengine_terminate_sync() will wait for the transfer and any running - complete callbacks to finish before it returns. But the function must not be - called from atomic context or from within a complete callback. - - dmaengine_terminate_all() is deprecated and should not be used in new code. - -2. int dmaengine_pause(struct dma_chan *chan) - - This pauses activity on the DMA channel without data loss. - -3. int dmaengine_resume(struct dma_chan *chan) - - Resume a previously paused DMA channel. It is invalid to resume a - channel which is not currently paused. - -4. enum dma_status dma_async_is_tx_complete(struct dma_chan *chan, - dma_cookie_t cookie, dma_cookie_t *last, dma_cookie_t *used) - - This can be used to check the status of the channel. Please see - the documentation in include/linux/dmaengine.h for a more complete - description of this API. - - This can be used in conjunction with dma_async_is_complete() and - the cookie returned from dmaengine_submit() to check for - completion of a specific DMA transaction. - - Note: - Not all DMA engine drivers can return reliable information for - a running DMA channel. It is recommended that DMA engine users - pause or stop (via dmaengine_terminate_all()) the channel before - using this API. - -5. void dmaengine_synchronize(struct dma_chan *chan) - - Synchronize the termination of the DMA channel to the current context. - - This function should be used after dmaengine_terminate_async() to synchronize - the termination of the DMA channel to the current context. The function will - wait for the transfer and any running complete callbacks to finish before it - returns. - - If dmaengine_terminate_async() is used to stop the DMA channel this function - must be called before it is safe to free memory accessed by previously - submitted descriptors or to free any resources accessed within the complete - callback of previously submitted descriptors. - - The behavior of this function is undefined if dma_async_issue_pending() has - been called between dmaengine_terminate_async() and this function. diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst new file mode 100644 index 000000000000..6245c99af8c1 --- /dev/null +++ b/Documentation/driver-api/dmaengine/client.rst @@ -0,0 +1,275 @@ +==================== +DMA Engine API Guide +==================== + +Vinod Koul + +.. note:: For DMA Engine usage in async_tx please see: + ``Documentation/crypto/async-tx-api.txt`` + + +Below is a guide to device driver writers on how to use the Slave-DMA API of the +DMA Engine. This is applicable only for slave DMA usage only. + +DMA usage +========= + +The slave DMA usage consists of following steps: + +- Allocate a DMA slave channel + +- Set slave and controller specific parameters + +- Get a descriptor for transaction + +- Submit the transaction + +- Issue pending requests and wait for callback notification + +The details of these operations are: + +1. Allocate a DMA slave channel + + Channel allocation is slightly different in the slave DMA context, + client drivers typically need a channel from a particular DMA + controller only and even in some cases a specific channel is desired. + To request a channel dma_request_chan() API is used. + + Interface: + + .. code-block:: c + + struct dma_chan *dma_request_chan(struct device *dev, const char *name); + + Which will find and return the ``name`` DMA channel associated with the 'dev' + device. The association is done via DT, ACPI or board file based + dma_slave_map matching table. + + A channel allocated via this interface is exclusive to the caller, + until dma_release_channel() is called. + +2. Set slave and controller specific parameters + + Next step is always to pass some specific information to the DMA + driver. Most of the generic information which a slave DMA can use + is in struct dma_slave_config. This allows the clients to specify + DMA direction, DMA addresses, bus widths, DMA burst lengths etc + for the peripheral. + + If some DMA controllers have more parameters to be sent then they + should try to embed struct dma_slave_config in their controller + specific structure. That gives flexibility to client to pass more + parameters, if required. + + Interface: + + .. code-block:: c + + int dmaengine_slave_config(struct dma_chan *chan, + struct dma_slave_config *config) + + Please see the dma_slave_config structure definition in dmaengine.h + for a detailed explanation of the struct members. Please note + that the 'direction' member will be going away as it duplicates the + direction given in the prepare call. + +3. Get a descriptor for transaction + + For slave usage the various modes of slave transfers supported by the + DMA-engine are: + + - slave_sg: DMA a list of scatter gather buffers from/to a peripheral + + - dma_cyclic: Perform a cyclic DMA operation from/to a peripheral till the + operation is explicitly stopped. + + - interleaved_dma: This is common to Slave as well as M2M clients. For slave + address of devices' fifo could be already known to the driver. + Various types of operations could be expressed by setting + appropriate values to the 'dma_interleaved_template' members. + + A non-NULL return of this transfer API represents a "descriptor" for + the given transaction. + + Interface: + + .. code-block:: c + + struct dma_async_tx_descriptor *dmaengine_prep_slave_sg( + struct dma_chan *chan, struct scatterlist *sgl, + unsigned int sg_len, enum dma_data_direction direction, + unsigned long flags); + + struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic( + struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len, + size_t period_len, enum dma_data_direction direction); + + struct dma_async_tx_descriptor *dmaengine_prep_interleaved_dma( + struct dma_chan *chan, struct dma_interleaved_template *xt, + unsigned long flags); + + The peripheral driver is expected to have mapped the scatterlist for + the DMA operation prior to calling dmaengine_prep_slave_sg(), and must + keep the scatterlist mapped until the DMA operation has completed. + The scatterlist must be mapped using the DMA struct device. + If a mapping needs to be synchronized later, dma_sync_*_for_*() must be + called using the DMA struct device, too. + So, normal setup should look like this: + + .. code-block:: c + + nr_sg = dma_map_sg(chan->device->dev, sgl, sg_len); + if (nr_sg == 0) + /* error */ + + desc = dmaengine_prep_slave_sg(chan, sgl, nr_sg, direction, flags); + + Once a descriptor has been obtained, the callback information can be + added and the descriptor must then be submitted. Some DMA engine + drivers may hold a spinlock between a successful preparation and + submission so it is important that these two operations are closely + paired. + + .. note:: + + Although the async_tx API specifies that completion callback + routines cannot submit any new operations, this is not the + case for slave/cyclic DMA. + + For slave DMA, the subsequent transaction may not be available + for submission prior to callback function being invoked, so + slave DMA callbacks are permitted to prepare and submit a new + transaction. + + For cyclic DMA, a callback function may wish to terminate the + DMA via dmaengine_terminate_async(). + + Therefore, it is important that DMA engine drivers drop any + locks before calling the callback function which may cause a + deadlock. + + Note that callbacks will always be invoked from the DMA + engines tasklet, never from interrupt context. + +4. Submit the transaction + + Once the descriptor has been prepared and the callback information + added, it must be placed on the DMA engine drivers pending queue. + + Interface: + + .. code-block:: c + + dma_cookie_t dmaengine_submit(struct dma_async_tx_descriptor *desc) + + This returns a cookie can be used to check the progress of DMA engine + activity via other DMA engine calls not covered in this document. + + dmaengine_submit() will not start the DMA operation, it merely adds + it to the pending queue. For this, see step 5, dma_async_issue_pending. + +5. Issue pending DMA requests and wait for callback notification + + The transactions in the pending queue can be activated by calling the + issue_pending API. If channel is idle then the first transaction in + queue is started and subsequent ones queued up. + + On completion of each DMA operation, the next in queue is started and + a tasklet triggered. The tasklet will then call the client driver + completion callback routine for notification, if set. + + Interface: + + .. code-block:: c + + void dma_async_issue_pending(struct dma_chan *chan); + +Further APIs: +------------ + +1. Terminate APIs + + .. code-block:: c + + int dmaengine_terminate_sync(struct dma_chan *chan) + int dmaengine_terminate_async(struct dma_chan *chan) + int dmaengine_terminate_all(struct dma_chan *chan) /* DEPRECATED */ + + This causes all activity for the DMA channel to be stopped, and may + discard data in the DMA FIFO which hasn't been fully transferred. + No callback functions will be called for any incomplete transfers. + + Two variants of this function are available. + + dmaengine_terminate_async() might not wait until the DMA has been fully + stopped or until any running complete callbacks have finished. But it is + possible to call dmaengine_terminate_async() from atomic context or from + within a complete callback. dmaengine_synchronize() must be called before it + is safe to free the memory accessed by the DMA transfer or free resources + accessed from within the complete callback. + + dmaengine_terminate_sync() will wait for the transfer and any running + complete callbacks to finish before it returns. But the function must not be + called from atomic context or from within a complete callback. + + dmaengine_terminate_all() is deprecated and should not be used in new code. + +2. Pause API + + .. code-block:: c + + int dmaengine_pause(struct dma_chan *chan) + + This pauses activity on the DMA channel without data loss. + +3. Resume API + + .. code-block:: c + + int dmaengine_resume(struct dma_chan *chan) + + Resume a previously paused DMA channel. It is invalid to resume a + channel which is not currently paused. + +4. Check Txn complete + + .. code-block:: c + + enum dma_status dma_async_is_tx_complete(struct dma_chan *chan, + dma_cookie_t cookie, dma_cookie_t *last, dma_cookie_t *used) + + This can be used to check the status of the channel. Please see + the documentation in include/linux/dmaengine.h for a more complete + description of this API. + + This can be used in conjunction with dma_async_is_complete() and + the cookie returned from dmaengine_submit() to check for + completion of a specific DMA transaction. + + .. note:: + + Not all DMA engine drivers can return reliable information for + a running DMA channel. It is recommended that DMA engine users + pause or stop (via dmaengine_terminate_all()) the channel before + using this API. + +5. Synchronize termination API + + .. code-block:: c + + void dmaengine_synchronize(struct dma_chan *chan) + + Synchronize the termination of the DMA channel to the current context. + + This function should be used after dmaengine_terminate_async() to synchronize + the termination of the DMA channel to the current context. The function will + wait for the transfer and any running complete callbacks to finish before it + returns. + + If dmaengine_terminate_async() is used to stop the DMA channel this function + must be called before it is safe to free memory accessed by previously + submitted descriptors or to free any resources accessed within the complete + callback of previously submitted descriptors. + + The behavior of this function is undefined if dma_async_issue_pending() has + been called between dmaengine_terminate_async() and this function. diff --git a/Documentation/driver-api/dmaengine/index.rst b/Documentation/driver-api/dmaengine/index.rst index eee0377e0d7b..ffc2b797938c 100644 --- a/Documentation/driver-api/dmaengine/index.rst +++ b/Documentation/driver-api/dmaengine/index.rst @@ -16,6 +16,17 @@ driver writers. provider +DMAEngine client documentation +------------------------------ + +This book is a guide to device driver writers on how to use the Slave-DMA +API of the DMAEngine. This is applicable only for slave DMA usage only. + +.. toctree:: + :maxdepth: 1 + + client + .. only:: subproject Indices -- cgit v1.2.3 From 179a214e9e985ef9b14d7e5d9fff20acddb9315b Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Fri, 3 Nov 2017 10:19:40 +0530 Subject: dmaengine: doc: ReSTize dmatest doc This converts and moves dmatest file with some format changes for RST style Signed-off-by: Vinod Koul Signed-off-by: Jonathan Corbet --- Documentation/dmaengine/dmatest.txt | 92 --------------------- Documentation/driver-api/dmaengine/dmatest.rst | 110 +++++++++++++++++++++++++ Documentation/driver-api/dmaengine/index.rst | 10 +++ 3 files changed, 120 insertions(+), 92 deletions(-) delete mode 100644 Documentation/dmaengine/dmatest.txt create mode 100644 Documentation/driver-api/dmaengine/dmatest.rst (limited to 'Documentation') diff --git a/Documentation/dmaengine/dmatest.txt b/Documentation/dmaengine/dmatest.txt deleted file mode 100644 index fb683c72dea8..000000000000 --- a/Documentation/dmaengine/dmatest.txt +++ /dev/null @@ -1,92 +0,0 @@ - DMA Test Guide - ============== - - Andy Shevchenko - -This small document introduces how to test DMA drivers using dmatest module. - - Part 1 - How to build the test module - -The menuconfig contains an option that could be found by following path: - Device Drivers -> DMA Engine support -> DMA Test client - -In the configuration file the option called CONFIG_DMATEST. The dmatest could -be built as module or inside kernel. Let's consider those cases. - - Part 2 - When dmatest is built as a module... - -Example of usage: - % modprobe dmatest channel=dma0chan0 timeout=2000 iterations=1 run=1 - -...or: - % modprobe dmatest - % echo dma0chan0 > /sys/module/dmatest/parameters/channel - % echo 2000 > /sys/module/dmatest/parameters/timeout - % echo 1 > /sys/module/dmatest/parameters/iterations - % echo 1 > /sys/module/dmatest/parameters/run - -...or on the kernel command line: - - dmatest.channel=dma0chan0 dmatest.timeout=2000 dmatest.iterations=1 dmatest.run=1 - -Hint: available channel list could be extracted by running the following -command: - % ls -1 /sys/class/dma/ - -Once started a message like "dmatest: Started 1 threads using dma0chan0" is -emitted. After that only test failure messages are reported until the test -stops. - -Note that running a new test will not stop any in progress test. - -The following command returns the state of the test. - % cat /sys/module/dmatest/parameters/run - -To wait for test completion userpace can poll 'run' until it is false, or use -the wait parameter. Specifying 'wait=1' when loading the module causes module -initialization to pause until a test run has completed, while reading -/sys/module/dmatest/parameters/wait waits for any running test to complete -before returning. For example, the following scripts wait for 42 tests -to complete before exiting. Note that if 'iterations' is set to 'infinite' then -waiting is disabled. - -Example: - % modprobe dmatest run=1 iterations=42 wait=1 - % modprobe -r dmatest -...or: - % modprobe dmatest run=1 iterations=42 - % cat /sys/module/dmatest/parameters/wait - % modprobe -r dmatest - - Part 3 - When built-in in the kernel... - -The module parameters that is supplied to the kernel command line will be used -for the first performed test. After user gets a control, the test could be -re-run with the same or different parameters. For the details see the above -section "Part 2 - When dmatest is built as a module..." - -In both cases the module parameters are used as the actual values for the test -case. You always could check them at run-time by running - % grep -H . /sys/module/dmatest/parameters/* - - Part 4 - Gathering the test results - -Test results are printed to the kernel log buffer with the format: - -"dmatest: result : : '' with src_off= dst_off= len= ()" - -Example of output: - % dmesg | tail -n 1 - dmatest: result dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0) - -The message format is unified across the different types of errors. A number in -the parens represents additional information, e.g. error code, error counter, -or status. A test thread also emits a summary line at completion listing the -number of tests executed, number that failed, and a result code. - -Example: - % dmesg | tail -n 1 - dmatest: dma0chan0-copy0: summary 1 test, 0 failures 1000 iops 100000 KB/s (0) - -The details of a data miscompare error are also emitted, but do not follow the -above format. diff --git a/Documentation/driver-api/dmaengine/dmatest.rst b/Documentation/driver-api/dmaengine/dmatest.rst new file mode 100644 index 000000000000..3922c0a3f0c0 --- /dev/null +++ b/Documentation/driver-api/dmaengine/dmatest.rst @@ -0,0 +1,110 @@ +============== +DMA Test Guide +============== + +Andy Shevchenko + +This small document introduces how to test DMA drivers using dmatest module. + +Part 1 - How to build the test module +===================================== + +The menuconfig contains an option that could be found by following path: + Device Drivers -> DMA Engine support -> DMA Test client + +In the configuration file the option called CONFIG_DMATEST. The dmatest could +be built as module or inside kernel. Let's consider those cases. + +Part 2 - When dmatest is built as a module +========================================== + +Example of usage: :: + + % modprobe dmatest channel=dma0chan0 timeout=2000 iterations=1 run=1 + +...or: :: + + % modprobe dmatest + % echo dma0chan0 > /sys/module/dmatest/parameters/channel + % echo 2000 > /sys/module/dmatest/parameters/timeout + % echo 1 > /sys/module/dmatest/parameters/iterations + % echo 1 > /sys/module/dmatest/parameters/run + +...or on the kernel command line: :: + + dmatest.channel=dma0chan0 dmatest.timeout=2000 dmatest.iterations=1 dmatest.run=1 + +..hint:: available channel list could be extracted by running the following + command: + +:: + + % ls -1 /sys/class/dma/ + +Once started a message like "dmatest: Started 1 threads using dma0chan0" is +emitted. After that only test failure messages are reported until the test +stops. + +Note that running a new test will not stop any in progress test. + +The following command returns the state of the test. :: + + % cat /sys/module/dmatest/parameters/run + +To wait for test completion userpace can poll 'run' until it is false, or use +the wait parameter. Specifying 'wait=1' when loading the module causes module +initialization to pause until a test run has completed, while reading +/sys/module/dmatest/parameters/wait waits for any running test to complete +before returning. For example, the following scripts wait for 42 tests +to complete before exiting. Note that if 'iterations' is set to 'infinite' then +waiting is disabled. + +Example: :: + + % modprobe dmatest run=1 iterations=42 wait=1 + % modprobe -r dmatest + +...or: :: + + % modprobe dmatest run=1 iterations=42 + % cat /sys/module/dmatest/parameters/wait + % modprobe -r dmatest + +Part 3 - When built-in in the kernel +==================================== + +The module parameters that is supplied to the kernel command line will be used +for the first performed test. After user gets a control, the test could be +re-run with the same or different parameters. For the details see the above +section "Part 2 - When dmatest is built as a module..." + +In both cases the module parameters are used as the actual values for the test +case. You always could check them at run-time by running :: + + % grep -H . /sys/module/dmatest/parameters/* + +Part 4 - Gathering the test results +=================================== + +Test results are printed to the kernel log buffer with the format: :: + + "dmatest: result : : '' with src_off= dst_off= len= ()" + +Example of output: :: + + + % dmesg | tail -n 1 + dmatest: result dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0) + +The message format is unified across the different types of errors. A number in +the parens represents additional information, e.g. error code, error counter, +or status. A test thread also emits a summary line at completion listing the +number of tests executed, number that failed, and a result code. + +Example: :: + + % dmesg | tail -n 1 + dmatest: dma0chan0-copy0: summary 1 test, 0 failures 1000 iops 100000 KB/s (0) + +The details of a data miscompare error are also emitted, but do not follow the +above format. diff --git a/Documentation/driver-api/dmaengine/index.rst b/Documentation/driver-api/dmaengine/index.rst index ffc2b797938c..fae852922a49 100644 --- a/Documentation/driver-api/dmaengine/index.rst +++ b/Documentation/driver-api/dmaengine/index.rst @@ -27,6 +27,16 @@ API of the DMAEngine. This is applicable only for slave DMA usage only. client +DMA Test documentation +---------------------- + +This book introduces how to test DMA drivers using dmatest module. + +.. toctree:: + :maxdepth: 1 + + dmatest + .. only:: subproject Indices -- cgit v1.2.3 From fbbe0bff9d2aa6f7b2d34059fca2ee808c04a651 Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Fri, 3 Nov 2017 10:19:41 +0530 Subject: dmaengine: doc: ReSTize pxa_dma doc This converts and moves pxa_dma file with some format changes for RST style Signed-off-by: Vinod Koul Signed-off-by: Jonathan Corbet --- Documentation/dmaengine/pxa_dma.txt | 153 -------------------- Documentation/driver-api/dmaengine/index.rst | 10 ++ Documentation/driver-api/dmaengine/pxa_dma.rst | 190 +++++++++++++++++++++++++ 3 files changed, 200 insertions(+), 153 deletions(-) delete mode 100644 Documentation/dmaengine/pxa_dma.txt create mode 100644 Documentation/driver-api/dmaengine/pxa_dma.rst (limited to 'Documentation') diff --git a/Documentation/dmaengine/pxa_dma.txt b/Documentation/dmaengine/pxa_dma.txt deleted file mode 100644 index 0736d44b5438..000000000000 --- a/Documentation/dmaengine/pxa_dma.txt +++ /dev/null @@ -1,153 +0,0 @@ -PXA/MMP - DMA Slave controller -============================== - -Constraints ------------ - a) Transfers hot queuing - A driver submitting a transfer and issuing it should be granted the transfer - is queued even on a running DMA channel. - This implies that the queuing doesn't wait for the previous transfer end, - and that the descriptor chaining is not only done in the irq/tasklet code - triggered by the end of the transfer. - A transfer which is submitted and issued on a phy doesn't wait for a phy to - stop and restart, but is submitted on a "running channel". The other - drivers, especially mmp_pdma waited for the phy to stop before relaunching - a new transfer. - - b) All transfers having asked for confirmation should be signaled - Any issued transfer with DMA_PREP_INTERRUPT should trigger a callback call. - This implies that even if an irq/tasklet is triggered by end of tx1, but - at the time of irq/dma tx2 is already finished, tx1->complete() and - tx2->complete() should be called. - - c) Channel running state - A driver should be able to query if a channel is running or not. For the - multimedia case, such as video capture, if a transfer is submitted and then - a check of the DMA channel reports a "stopped channel", the transfer should - not be issued until the next "start of frame interrupt", hence the need to - know if a channel is in running or stopped state. - - d) Bandwidth guarantee - The PXA architecture has 4 levels of DMAs priorities : high, normal, low. - The high priorities get twice as much bandwidth as the normal, which get twice - as much as the low priorities. - A driver should be able to request a priority, especially the real-time - ones such as pxa_camera with (big) throughputs. - -Design ------- - a) Virtual channels - Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual - channel" linked to the requestor line, and the physical DMA channel is - assigned on the fly when the transfer is issued. - - b) Transfer anatomy for a scatter-gather transfer - +------------+-----+---------------+----------------+-----------------+ - | desc-sg[0] | ... | desc-sg[last] | status updater | finisher/linker | - +------------+-----+---------------+----------------+-----------------+ - - This structure is pointed by dma->sg_cpu. - The descriptors are used as follows : - - desc-sg[i]: i-th descriptor, transferring the i-th sg - element to the video buffer scatter gather - - status updater - Transfers a single u32 to a well known dma coherent memory to leave - a trace that this transfer is done. The "well known" is unique per - physical channel, meaning that a read of this value will tell which - is the last finished transfer at that point in time. - - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN - - linker: has ddadr= desc-sg[0] of next transfer, dcmd=0 - - c) Transfers hot-chaining - Suppose the running chain is : - Buffer 1 Buffer 2 - +---------+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+---+ - | | - +----+ - - After a call to dmaengine_submit(b3), the chain will look like : - Buffer 1 Buffer 2 Buffer 3 - +---------+----+---+ +----+----+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ - | | | | - +----+ +----+ - new_link - - If while new_link was created the DMA channel stopped, it is _not_ - restarted. Hot-chaining doesn't break the assumption that - dma_async_issue_pending() is to be used to ensure the transfer is actually started. - - One exception to this rule : - - if Buffer1 and Buffer2 had all their addresses 8 bytes aligned - - and if Buffer3 has at least one address not 4 bytes aligned - - then hot-chaining cannot happen, as the channel must be stopped, the - "align bit" must be set, and the channel restarted As a consequence, - such a transfer tx_submit() will be queued on the submitted queue, and - this specific case if the DMA is already running in aligned mode. - - d) Transfers completion updater - Each time a transfer is completed on a channel, an interrupt might be - generated or not, up to the client's request. But in each case, the last - descriptor of a transfer, the "status updater", will write the latest - transfer being completed into the physical channel's completion mark. - - This will speed up residue calculation, for large transfers such as video - buffers which hold around 6k descriptors or more. This also allows without - any lock to find out what is the latest completed transfer in a running - DMA chain. - - e) Transfers completion, irq and tasklet - When a transfer flagged as "DMA_PREP_INTERRUPT" is finished, the dma irq - is raised. Upon this interrupt, a tasklet is scheduled for the physical - channel. - The tasklet is responsible for : - - reading the physical channel last updater mark - - calling all the transfer callbacks of finished transfers, based on - that mark, and each transfer flags. - If a transfer is completed while this handling is done, a dma irq will - be raised, and the tasklet will be scheduled once again, having a new - updater mark. - - f) Residue - Residue granularity will be descriptor based. The issued but not completed - transfers will be scanned for all of their descriptors against the - currently running descriptor. - - g) Most complicated case of driver's tx queues - The most tricky situation is when : - - there are not "acked" transfers (tx0) - - a driver submitted an aligned tx1, not chained - - a driver submitted an aligned tx2 => tx2 is cold chained to tx1 - - a driver issued tx1+tx2 => channel is running in aligned mode - - a driver submitted an aligned tx3 => tx3 is hot-chained - - a driver submitted an unaligned tx4 => tx4 is put in submitted queue, - not chained - - a driver issued tx4 => tx4 is put in issued queue, not chained - - a driver submitted an aligned tx5 => tx5 is put in submitted queue, not - chained - - a driver submitted an aligned tx6 => tx6 is put in submitted queue, - cold chained to tx5 - - This translates into (after tx4 is issued) : - - issued queue - +-----+ +-----+ +-----+ +-----+ - | tx1 | | tx2 | | tx3 | | tx4 | - +---|-+ ^---|-+ ^-----+ +-----+ - | | | | - +---+ +---+ - - submitted queue - +-----+ +-----+ - | tx5 | | tx6 | - +---|-+ ^-----+ - | | - +---+ - - completed queue : empty - - allocated queue : tx0 - - It should be noted that after tx3 is completed, the channel is stopped, and - restarted in "unaligned mode" to handle tx4. - -Author: Robert Jarzmik diff --git a/Documentation/driver-api/dmaengine/index.rst b/Documentation/driver-api/dmaengine/index.rst index fae852922a49..3026fa975937 100644 --- a/Documentation/driver-api/dmaengine/index.rst +++ b/Documentation/driver-api/dmaengine/index.rst @@ -37,6 +37,16 @@ This book introduces how to test DMA drivers using dmatest module. dmatest +PXA DMA documentation +---------------------- + +This book adds some notes about PXA DMA + +.. toctree:: + :maxdepth: 1 + + pxa_dma + .. only:: subproject Indices diff --git a/Documentation/driver-api/dmaengine/pxa_dma.rst b/Documentation/driver-api/dmaengine/pxa_dma.rst new file mode 100644 index 000000000000..442ee691a190 --- /dev/null +++ b/Documentation/driver-api/dmaengine/pxa_dma.rst @@ -0,0 +1,190 @@ +============================== +PXA/MMP - DMA Slave controller +============================== + +Constraints +=========== + +a) Transfers hot queuing +A driver submitting a transfer and issuing it should be granted the transfer +is queued even on a running DMA channel. +This implies that the queuing doesn't wait for the previous transfer end, +and that the descriptor chaining is not only done in the irq/tasklet code +triggered by the end of the transfer. +A transfer which is submitted and issued on a phy doesn't wait for a phy to +stop and restart, but is submitted on a "running channel". The other +drivers, especially mmp_pdma waited for the phy to stop before relaunching +a new transfer. + +b) All transfers having asked for confirmation should be signaled +Any issued transfer with DMA_PREP_INTERRUPT should trigger a callback call. +This implies that even if an irq/tasklet is triggered by end of tx1, but +at the time of irq/dma tx2 is already finished, tx1->complete() and +tx2->complete() should be called. + +c) Channel running state +A driver should be able to query if a channel is running or not. For the +multimedia case, such as video capture, if a transfer is submitted and then +a check of the DMA channel reports a "stopped channel", the transfer should +not be issued until the next "start of frame interrupt", hence the need to +know if a channel is in running or stopped state. + +d) Bandwidth guarantee +The PXA architecture has 4 levels of DMAs priorities : high, normal, low. +The high priorities get twice as much bandwidth as the normal, which get twice +as much as the low priorities. +A driver should be able to request a priority, especially the real-time +ones such as pxa_camera with (big) throughputs. + +Design +====== +a) Virtual channels +Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual +channel" linked to the requestor line, and the physical DMA channel is +assigned on the fly when the transfer is issued. + +b) Transfer anatomy for a scatter-gather transfer + +:: + + +------------+-----+---------------+----------------+-----------------+ + | desc-sg[0] | ... | desc-sg[last] | status updater | finisher/linker | + +------------+-----+---------------+----------------+-----------------+ + +This structure is pointed by dma->sg_cpu. +The descriptors are used as follows : + + - desc-sg[i]: i-th descriptor, transferring the i-th sg + element to the video buffer scatter gather + + - status updater + Transfers a single u32 to a well known dma coherent memory to leave + a trace that this transfer is done. The "well known" is unique per + physical channel, meaning that a read of this value will tell which + is the last finished transfer at that point in time. + + - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN + + - linker: has ddadr= desc-sg[0] of next transfer, dcmd=0 + +c) Transfers hot-chaining +Suppose the running chain is: + +:: + + Buffer 1 Buffer 2 + +---------+----+---+ +----+----+----+---+ + | d0 | .. | dN | l | | d0 | .. | dN | f | + +---------+----+-|-+ ^----+----+----+---+ + | | + +----+ + +After a call to dmaengine_submit(b3), the chain will look like: + +:: + + Buffer 1 Buffer 2 Buffer 3 + +---------+----+---+ +----+----+----+---+ +----+----+----+---+ + | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | + +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ + | | | | + +----+ +----+ + new_link + +If while new_link was created the DMA channel stopped, it is _not_ +restarted. Hot-chaining doesn't break the assumption that +dma_async_issue_pending() is to be used to ensure the transfer is actually started. + +One exception to this rule : + +- if Buffer1 and Buffer2 had all their addresses 8 bytes aligned + +- and if Buffer3 has at least one address not 4 bytes aligned + +- then hot-chaining cannot happen, as the channel must be stopped, the + "align bit" must be set, and the channel restarted As a consequence, + such a transfer tx_submit() will be queued on the submitted queue, and + this specific case if the DMA is already running in aligned mode. + +d) Transfers completion updater +Each time a transfer is completed on a channel, an interrupt might be +generated or not, up to the client's request. But in each case, the last +descriptor of a transfer, the "status updater", will write the latest +transfer being completed into the physical channel's completion mark. + +This will speed up residue calculation, for large transfers such as video +buffers which hold around 6k descriptors or more. This also allows without +any lock to find out what is the latest completed transfer in a running +DMA chain. + +e) Transfers completion, irq and tasklet +When a transfer flagged as "DMA_PREP_INTERRUPT" is finished, the dma irq +is raised. Upon this interrupt, a tasklet is scheduled for the physical +channel. + +The tasklet is responsible for : + +- reading the physical channel last updater mark + +- calling all the transfer callbacks of finished transfers, based on + that mark, and each transfer flags. + +If a transfer is completed while this handling is done, a dma irq will +be raised, and the tasklet will be scheduled once again, having a new +updater mark. + +f) Residue +Residue granularity will be descriptor based. The issued but not completed +transfers will be scanned for all of their descriptors against the +currently running descriptor. + +g) Most complicated case of driver's tx queues +The most tricky situation is when : + + - there are not "acked" transfers (tx0) + + - a driver submitted an aligned tx1, not chained + + - a driver submitted an aligned tx2 => tx2 is cold chained to tx1 + + - a driver issued tx1+tx2 => channel is running in aligned mode + + - a driver submitted an aligned tx3 => tx3 is hot-chained + + - a driver submitted an unaligned tx4 => tx4 is put in submitted queue, + not chained + + - a driver issued tx4 => tx4 is put in issued queue, not chained + + - a driver submitted an aligned tx5 => tx5 is put in submitted queue, not + chained + + - a driver submitted an aligned tx6 => tx6 is put in submitted queue, + cold chained to tx5 + + This translates into (after tx4 is issued) : + + - issued queue + + :: + + +-----+ +-----+ +-----+ +-----+ + | tx1 | | tx2 | | tx3 | | tx4 | + +---|-+ ^---|-+ ^-----+ +-----+ + | | | | + +---+ +---+ + - submitted queue + +-----+ +-----+ + | tx5 | | tx6 | + +---|-+ ^-----+ + | | + +---+ + +- completed queue : empty + +- allocated queue : tx0 + +It should be noted that after tx3 is completed, the channel is stopped, and +restarted in "unaligned mode" to handle tx4. + +Author: Robert Jarzmik -- cgit v1.2.3 From c02b1a9b41c2e728289f96850580a3651e0a8b5f Mon Sep 17 00:00:00 2001 From: Mateusz Guzik Date: Tue, 3 Oct 2017 12:58:15 +0200 Subject: vfs: grab the lock instead of blocking in __fd_install during resizing Explicit locking in the fallback case provides a safe state of the table. Getting rid of blocking semantics makes __fd_install usable again in non-sleepable contexts, which easies backporting efforts. There is a side effect of slightly nicer assembly for the common case as might_sleep can now be removed. Signed-off-by: Mateusz Guzik Signed-off-by: Al Viro --- Documentation/filesystems/porting | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 93e0a2404532..17bb4dc28fae 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -501,10 +501,6 @@ in your dentry operations instead. is non-NULL. Note that link body isn't available anymore, so if you need it, store it as cookie. -- -[mandatory] - __fd_install() & fd_install() can now sleep. Callers should not - hold a spinlock or other resources that do not allow a schedule. --- [mandatory] any symlink that might use page_follow_link_light/page_put_link() must have inode_nohighmem(inode) called before anything might start playing with -- cgit v1.2.3 From 80d421450187e894af841849d66614a0456912f9 Mon Sep 17 00:00:00 2001 From: Yunlong Song Date: Fri, 27 Oct 2017 20:45:05 +0800 Subject: f2fs: support soft block reservation It supports to extend reserved_blocks sysfs interface to be soft threshold, which allows user configure it exceeding current available user space. This patch also introduces a new sysfs interface called current_reserved_blocks, which shows the current blocks that have already been reserved. Signed-off-by: Yunlong Song Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 11b7f4ebea7c..7562b0d42105 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -138,7 +138,18 @@ What: /sys/fs/f2fs//reserved_blocks Date: June 2017 Contact: "Chao Yu" Description: - Controls current reserved blocks in system. + Controls target reserved blocks in system, the threshold + is soft, it could exceed current available user space. + +What: /sys/fs/f2fs//current_reserved_blocks +Date: October 2017 +Contact: "Yunlong Song" +Contact: "Chao Yu" +Description: + Shows current reserved blocks in system, it may be temporarily + smaller than target_reserved_blocks, but will gradually + increase to target_reserved_blocks when more free blocks are + freed by user later. What: /sys/fs/f2fs//gc_urgent Date: August 2017 -- cgit v1.2.3 From b32d73abc6f0a63503f68a7227b1d46aff1f46af Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Sat, 28 Oct 2017 16:52:29 +0800 Subject: f2fs: add missing sysfs description There are some missing sysfs entries' description in document, add them. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 7562b0d42105..fc1dff659df4 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -51,6 +51,12 @@ Description: Controls the dirty page count condition for the in-place-update policies. +What: /sys/fs/f2fs//min_hot_blocks +Date: March 2017 +Contact: "Jaegeuk Kim" +Description: + Controls the dirty page count condition for redefining hot data. + What: /sys/fs/f2fs//max_small_discards Date: November 2013 Contact: "Jaegeuk Kim" @@ -102,6 +108,12 @@ Contact: "Jaegeuk Kim" Description: Controls the idle timing. +What: /sys/fs/f2fs//iostat_enable +Date: August 2017 +Contact: "Chao Yu" +Description: + Controls to enable/disable IO stat. + What: /sys/fs/f2fs//ra_nid_pages Date: October 2015 Contact: "Chao Yu" @@ -122,6 +134,12 @@ Contact: "Shuoran Liu" Description: Shows total written kbytes issued to disk. +What: /sys/fs/f2fs//feature +Date: July 2017 +Contact: "Jaegeuk Kim" +Description: + Shows all enabled features in current device. + What: /sys/fs/f2fs//inject_rate Date: May 2016 Contact: "Sheng Yong" -- cgit v1.2.3 From a2a12b679f367014fa86d2cf3309e37c59e155c2 Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Sat, 28 Oct 2017 16:52:33 +0800 Subject: f2fs: export SSR allocation threshold This patch exports min_ssr_segments threshold in sysfs to let user control triggering SSR allocation flexibly. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index fc1dff659df4..a7799c2fca28 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -57,6 +57,12 @@ Contact: "Jaegeuk Kim" Description: Controls the dirty page count condition for redefining hot data. +What: /sys/fs/f2fs//min_ssr_sections +Date: October 2017 +Contact: "Chao Yu" +Description: + Controls the fee section threshold to trigger SSR allocation. + What: /sys/fs/f2fs//max_small_discards Date: November 2013 Contact: "Jaegeuk Kim" -- cgit v1.2.3 From 08810a4119aaebf6318f209ec5dd9828e969cba4 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 25 Oct 2017 14:12:29 +0200 Subject: PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags The motivation for this change is to provide a way to work around a problem with the direct-complete mechanism used for avoiding system suspend/resume handling for devices in runtime suspend. The problem is that some middle layer code (the PCI bus type and the ACPI PM domain in particular) returns positive values from its system suspend ->prepare callbacks regardless of whether the driver's ->prepare returns a positive value or 0, which effectively prevents drivers from being able to control the direct-complete feature. Some drivers need that control, however, and the PCI bus type has grown its own flag to deal with this issue, but since it is not limited to PCI, it is better to address it by adding driver flags at the core level. To that end, add a driver_flags field to struct dev_pm_info for flags that can be set by device drivers at the probe time to inform the PM core and/or bus types, PM domains and so on on the capabilities and/or preferences of device drivers. Also add two static inline helpers for setting that field and testing it against a given set of flags and make the driver core clear it automatically on driver remove and probe failures. Define and document two PM driver flags related to the direct- complete feature: NEVER_SKIP and SMART_PREPARE that can be used, respectively, to indicate to the PM core that the direct-complete mechanism should never be used for the device and to inform the middle layer code (bus types, PM domains etc) that it can only request the PM core to use the direct-complete mechanism for the device (by returning a positive value from its ->prepare callback) if it also has been requested by the driver. While at it, make the core check pm_runtime_suspended() when setting power.direct_complete so that it doesn't need to be checked by ->prepare callbacks. Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman Acked-by: Bjorn Helgaas Reviewed-by: Ulf Hansson --- Documentation/driver-api/pm/devices.rst | 14 ++++++++++++++ Documentation/power/pci.txt | 19 +++++++++++++++++++ 2 files changed, 33 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index 4a18ef9997c0..8add5b302a89 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -354,6 +354,20 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``. is because all such devices are initially set to runtime-suspended with runtime PM disabled. + This feature also can be controlled by device drivers by using the + ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power + management flags. [Typically, they are set at the time the driver is + probed against the device in question by passing them to the + :c:func:`dev_pm_set_driver_flags` helper function.] If the first of + these flags is set, the PM core will not apply the direct-complete + procedure described above to the given device and, consequenty, to any + of its ancestors. The second flag, when set, informs the middle layer + code (bus types, device types, PM domains, classes) that it should take + the return value of the ``->prepare`` callback provided by the driver + into account and it may only return a positive value from its own + ``->prepare`` callback if the driver's one also has returned a positive + value. + 2. The ``->suspend`` methods should quiesce the device to stop it from performing I/O. They also may save the device registers and put it into the appropriate low-power state, depending on the bus type the device is diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt index a1b7f7158930..ab4e7d0540c1 100644 --- a/Documentation/power/pci.txt +++ b/Documentation/power/pci.txt @@ -961,6 +961,25 @@ dev_pm_ops to indicate that one suspend routine is to be pointed to by the .suspend(), .freeze(), and .poweroff() members and one resume routine is to be pointed to by the .resume(), .thaw(), and .restore() members. +3.1.19. Driver Flags for Power Management + +The PM core allows device drivers to set flags that influence the handling of +power management for the devices by the core itself and by middle layer code +including the PCI bus type. The flags should be set once at the driver probe +time with the help of the dev_pm_set_driver_flags() function and they should not +be updated directly afterwards. + +The DPM_FLAG_NEVER_SKIP flag prevents the PM core from using the direct-complete +mechanism allowing device suspend/resume callbacks to be skipped if the device +is in runtime suspend when the system suspend starts. That also affects all of +the ancestors of the device, so this flag should only be used if absolutely +necessary. + +The DPM_FLAG_SMART_PREPARE flag instructs the PCI bus type to only return a +positive value from pci_pm_prepare() if the ->prepare callback provided by the +driver of the device returns a positive value. That allows the driver to opt +out from using the direct-complete mechanism dynamically. + 3.2. Device Runtime Power Management ------------------------------------ In addition to providing device power management callbacks PCI device drivers -- cgit v1.2.3 From 0eab11c9ae3b3cc5dd76f20b81d0247647a6e96f Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 26 Oct 2017 12:12:08 +0200 Subject: PM / core: Add SMART_SUSPEND driver flag Define and document a SMART_SUSPEND flag to instruct bus types and PM domains that the system suspend callbacks provided by the driver can cope with runtime-suspended devices, so from the driver's perspective it should be safe to leave devices in runtime suspend during system suspend. Setting that flag may also cause middle-layer code (bus types, PM domains etc.) to skip invocations of the ->suspend_late and ->suspend_noirq callbacks provided by the driver if the device is in runtime suspend at the beginning of the "late" phase of the system-wide suspend transition, in which case the driver's system-wide resume callbacks may be invoked back-to-back with its ->runtime_suspend callback, so the driver has to be able to cope with that too. Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman Reviewed-by: Ulf Hansson --- Documentation/driver-api/pm/devices.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index 8add5b302a89..574dadd06dec 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -766,6 +766,26 @@ the state of devices (possibly except for resuming them from runtime suspend) from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before* invoking device drivers' ``->suspend`` callbacks (or equivalent). +Some bus types and PM domains have a policy to resume all devices from runtime +suspend upfront in their ``->suspend`` callbacks, but that may not be really +necessary if the driver of the device can cope with runtime-suspended devices. +The driver can indicate that by setting ``DPM_FLAG_SMART_SUSPEND`` in +:c:member:`power.driver_flags` at the probe time, by passing it to the +:c:func:`dev_pm_set_driver_flags` helper. That also may cause middle-layer code +(bus types, PM domains etc.) to skip the ``->suspend_late`` and +``->suspend_noirq`` callbacks provided by the driver if the device remains in +runtime suspend at the beginning of the ``suspend_late`` phase of system-wide +suspend (or in the ``poweroff_late`` phase of hibernation), when runtime PM +has been disabled for it, under the assumption that its state should not change +after that point until the system-wide transition is over. If that happens, the +driver's system-wide resume callbacks, if present, may still be invoked during +the subsequent system-wide resume transition and the device's runtime power +management status may be set to "active" before enabling runtime PM for it, +so the driver must be prepared to cope with the invocation of its system-wide +resume callbacks back-to-back with its ``->runtime_suspend`` one (without the +intervening ``->runtime_resume`` and so on) and the final state of the device +must reflect the "active" status for runtime PM in that case. + During system-wide resume from a sleep state it's easiest to put devices into the full-power state, as explained in :file:`Documentation/power/runtime_pm.txt`. Refer to that document for more information regarding this particular issue as -- cgit v1.2.3 From c4b65157aeefad29b2351a00a010e8c40ce7fd0e Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 26 Oct 2017 12:12:22 +0200 Subject: PCI / PM: Take SMART_SUSPEND driver flag into account Make the PCI bus type take DPM_FLAG_SMART_SUSPEND into account in its system-wide PM callbacks and make sure that all code that should not run in parallel with pci_pm_runtime_resume() is executed in the "late" phases of system suspend, freeze and poweroff transitions. [Note that the pm_runtime_suspended() check in pci_dev_keep_suspended() is an optimization, because if is not passed, all of the subsequent checks may be skipped and some of them are much more overhead in general.] Also use the observation that if the device is in runtime suspend at the beginning of the "late" phase of a system-wide suspend-like transition, its state cannot change going forward (runtime PM is disabled for it at that time) until the transition is over and the subsequent system-wide PM callbacks should be skipped for it (as they generally assume the device to not be suspended), so add checks for that in pci_pm_suspend_late/noirq(), pci_pm_freeze_late/noirq() and pci_pm_poweroff_late/noirq(). Moreover, if pci_pm_resume_noirq() or pci_pm_restore_noirq() is called during the subsequent system-wide resume transition and if the device was left in runtime suspend previously, its runtime PM status needs to be changed to "active" as it is going to be put into the full-power state, so add checks for that too to these functions. In turn, if pci_pm_thaw_noirq() runs after the device has been left in runtime suspend, the subsequent "thaw" callbacks need to be skipped for it (as they may not work correctly with a suspended device), so set the power.direct_complete flag for the device then to make the PM core skip those callbacks. In addition to the above add a core helper for checking if DPM_FLAG_SMART_SUSPEND is set and the device runtime PM status is "suspended" at the same time, which is done quite often in the new code (and will be done elsewhere going forward too). Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman Acked-by: Bjorn Helgaas --- Documentation/power/pci.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt index ab4e7d0540c1..304162ea377e 100644 --- a/Documentation/power/pci.txt +++ b/Documentation/power/pci.txt @@ -980,6 +980,20 @@ positive value from pci_pm_prepare() if the ->prepare callback provided by the driver of the device returns a positive value. That allows the driver to opt out from using the direct-complete mechanism dynamically. +The DPM_FLAG_SMART_SUSPEND flag tells the PCI bus type that from the driver's +perspective the device can be safely left in runtime suspend during system +suspend. That causes pci_pm_suspend(), pci_pm_freeze() and pci_pm_poweroff() +to skip resuming the device from runtime suspend unless there are PCI-specific +reasons for doing that. Also, it causes pci_pm_suspend_late/noirq(), +pci_pm_freeze_late/noirq() and pci_pm_poweroff_late/noirq() to return early +if the device remains in runtime suspend in the beginning of the "late" phase +of the system-wide transition under way. Moreover, if the device is in +runtime suspend in pci_pm_resume_noirq() or pci_pm_restore_noirq(), its runtime +power management status will be changed to "active" (as it is going to be put +into D0 going forward), but if it is in runtime suspend in pci_pm_thaw_noirq(), +the function will set the power.direct_complete flag for it (to make the PM core +skip the subsequent "thaw" callbacks for it) and return. + 3.2. Device Runtime Power Management ------------------------------------ In addition to providing device power management callbacks PCI device drivers -- cgit v1.2.3 From ae204f80ca4074b6db07bd28c75faf02718735a0 Mon Sep 17 00:00:00 2001 From: Eric Auger Date: Thu, 26 Oct 2017 17:23:10 +0200 Subject: KVM: arm/arm64: Document KVM_DEV_ARM_ITS_CTRL_RESET At the moment, the in-kernel emulated ITS is not properly reset. On guest restart/reset some registers keep their old values and internal structures like device, ITE, and collection lists are not freed. This may lead to various bugs. Among them, we can have incorrect state backup or failure when saving the ITS state at early guest boot stage. This patch documents a new attribute, KVM_DEV_ARM_ITS_CTRL_RESET in the KVM_DEV_ARM_VGIC_GRP_CTRL group. Upon this action, we can reset registers and especially those pointing to tables previously allocated by the guest and free the internal data structures storing the list of devices, collections and lpis. The usual approach for device reset of having userspace write the reset values of the registers to the kernel via the register read/write APIs doesn't work for the ITS because it has some internal state (caches) which is not exposed as registers, and there is no register interface for "drop cached data without writing it back to RAM". So we need a KVM API which mimics the hardware's reset line, to provide the equivalent behaviour to a "pull the power cord out of the back of the machine" reset. Reviewed-by: Christoffer Dall Reviewed-by: Marc Zyngier Signed-off-by: Eric Auger Reported-by: wanghaibin Signed-off-by: Christoffer Dall --- Documentation/virtual/kvm/devices/arm-vgic-its.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt index eb06beb75960..8d5830eab26a 100644 --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt @@ -33,6 +33,10 @@ Groups: request the initialization of the ITS, no additional parameter in kvm_device_attr.addr. + KVM_DEV_ARM_ITS_CTRL_RESET + reset the ITS, no additional parameter in kvm_device_attr.addr. + See "ITS Reset State" section. + KVM_DEV_ARM_ITS_SAVE_TABLES save the ITS table data into guest RAM, at the location provisioned by the guest in corresponding registers/table entries. @@ -157,3 +161,19 @@ Then vcpus can be started. - pINTID is the physical LPI ID; if zero, it means the entry is not valid and other fields are not meaningful. - ICID is the collection ID + + ITS Reset State: + ---------------- + +RESET returns the ITS to the same state that it was when first created and +initialized. When the RESET command returns, the following things are +guaranteed: + +- The ITS is not enabled and quiescent + GITS_CTLR.Enabled = 0 .Quiescent=1 +- There is no internally cached state +- No collection or device table are used + GITS_BASER.Valid = 0 +- GITS_CBASER = 0, GITS_CREADR = 0, GITS_CWRITER = 0 +- The ABI version is unchanged and remains the one set when the ITS + device was first created. -- cgit v1.2.3 From edd20e95bca4a5434f264d8ab40d729761479825 Mon Sep 17 00:00:00 2001 From: Joel Stanley Date: Wed, 1 Nov 2017 10:53:30 +1030 Subject: i2c: aspeed: Deassert reset in probe In order to use i2c from a cold boot, the i2c peripheral must be taken out of reset. We request a shared reset controller each time a bus driver is loaded, as the reset is shared between the 14 i2c buses. On remove the reset is asserted, which only touches the hardware once the last i2c bus is removed. The reset is required as the I2C buses will not work without releasing the reset. Previously the driver only worked with out of tree hacks that released this reset before the driver was loaded. Update the device tree bindings to reflect this. Signed-off-by: Joel Stanley Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt index bd6480b19535..e7106bfc1f13 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt @@ -7,7 +7,9 @@ Required Properties: - compatible : should be "aspeed,ast2400-i2c-bus" or "aspeed,ast2500-i2c-bus" - clocks : root clock of bus, should reference the APB - clock + clock in the second cell +- resets : phandle to reset controller with the reset number in + the second cell - interrupts : interrupt number - interrupt-parent : interrupt controller for bus, should reference a aspeed,ast2400-i2c-ic or aspeed,ast2500-i2c-ic @@ -40,7 +42,8 @@ i2c { #interrupt-cells = <1>; reg = <0x40 0x40>; compatible = "aspeed,ast2400-i2c-bus"; - clocks = <&clk_apb>; + clocks = <&syscon ASPEED_CLK_APB>; + resets = <&syscon ASPEED_RESET_I2C>; bus-frequency = <100000>; interrupts = <0>; interrupt-parent = <&i2c_ic>; -- cgit v1.2.3 From ded0eb83449e8fcba22fd2736826336e101ffbcb Mon Sep 17 00:00:00 2001 From: Andrew Jeffery Date: Fri, 3 Nov 2017 15:53:01 +1100 Subject: dt-bindings: pmbus: Add Maxim MAX31785 documentation Signed-off-by: Andrew Jeffery Acked-by: Rob Herring Signed-off-by: Guenter Roeck --- .../devicetree/bindings/hwmon/max31785.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/max31785.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwmon/max31785.txt b/Documentation/devicetree/bindings/hwmon/max31785.txt new file mode 100644 index 000000000000..106e08c56aaa --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/max31785.txt @@ -0,0 +1,22 @@ +Bindings for the Maxim MAX31785 Intelligent Fan Controller +========================================================== + +Reference: + +https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf + +The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan +management with temperature and remote voltage sensing. Various fan control +features are provided, including PWM frequency control, temperature hysteresis, +dual tachometer measurements, and fan health monitoring. + +Required properties: +- compatible : One of "maxim,max31785" or "maxim,max31785a" +- reg : I2C address, one of 0x52, 0x53, 0x54, 0x55. + +Example: + + fans@52 { + compatible = "maxim,max31785"; + reg = <0x52>; + }; -- cgit v1.2.3 From 0ea04c7322b0dbbc4e7a862451855b10ef9922d3 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel Date: Mon, 6 Nov 2017 18:34:36 +0000 Subject: dt-bindings: Add description of Socionext EXIU interrupt controller Add a description of the External Interrupt Unit (EXIU) interrupt controller as found on the Socionext SynQuacer SoC. Acked-by: Rob Herring Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier --- .../socionext,synquacer-exiu.txt | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt b/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt new file mode 100644 index 000000000000..8b2faefe29ca --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt @@ -0,0 +1,32 @@ +Socionext SynQuacer External Interrupt Unit (EXIU) + +The Socionext Synquacer SoC has an external interrupt unit (EXIU) +that forwards a block of 32 configurable input lines to 32 adjacent +level-high type GICv3 SPIs. + +Required properties: + +- compatible : Should be "socionext,synquacer-exiu". +- reg : Specifies base physical address and size of the + control registers. +- interrupt-controller : Identifies the node as an interrupt controller. +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The value must be 3. +- interrupt-parent : phandle of the GIC these interrupts are routed to. +- socionext,spi-base : The SPI number of the first SPI of the 32 adjacent + ones the EXIU forwards its interrups to. + +Notes: + +- Only SPIs can use the EXIU as an interrupt parent. + +Example: + + exiu: interrupt-controller@510c0000 { + compatible = "socionext,synquacer-exiu"; + reg = <0x0 0x510c0000 0x0 0x20>; + interrupt-controller; + interrupt-parent = <&gic>; + #interrupt-cells = <3>; + socionext,spi-base = <112>; + }; -- cgit v1.2.3 From ce0b7e39c5a0c65bdce6fc36bba2991ea8f915b7 Mon Sep 17 00:00:00 2001 From: Ludovic Barre Date: Mon, 6 Nov 2017 18:03:33 +0100 Subject: dt-bindings/interrupt-controllers: Add compatible string for stm32h7 This patch updates stm32-exti documentation with stm32h7-exti compatible string. Acked-by: Rob Herring Signed-off-by: Ludovic Barre Signed-off-by: Marc Zyngier --- .../devicetree/bindings/interrupt-controller/st,stm32-exti.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt index 6e7703d4ff5b..edf03f09244b 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt @@ -2,7 +2,9 @@ STM32 External Interrupt Controller Required properties: -- compatible: Should be "st,stm32-exti" +- compatible: Should be: + "st,stm32-exti" + "st,stm32h7-exti" - reg: Specifies base physical address and size of the registers - interrupt-controller: Indentifies the node as an interrupt controller - #interrupt-cells: Specifies the number of cells to encode an interrupt -- cgit v1.2.3 From 167e5b6f98d27901c7a00b566938ce1973af4395 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel Date: Mon, 6 Nov 2017 15:29:22 +0000 Subject: dt-bindings: sdhci-fujitsu: document cmd-dat-delay property Document a new boolean property of the sdhci-fujitsu binding that indicates whether the CMD_DAT_DELAY bit needs to be set in the F_SDH30_ESD_CONTROL register. Acked-by: Rob Herring Signed-off-by: Ard Biesheuvel Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt b/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt index de2c53cff4f1..3ee9263adf73 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt @@ -15,6 +15,8 @@ Required properties: Optional properties: - vqmmc-supply: phandle to the regulator device tree node, mentioned as the VCCQ/VDD_IO supply in the eMMC/SD specs. +- fujitsu,cmd-dat-delay-select: boolean property indicating that this host + requires the CMD_DAT_DELAY control to be enabled. Example: -- cgit v1.2.3 From 33e63acc119d15c2fac3e3775f32d1ce7a01021b Mon Sep 17 00:00:00 2001 From: Brijesh Singh Date: Fri, 20 Oct 2017 09:30:43 -0500 Subject: Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) description Update the AMD memory encryption document describing the Secure Encrypted Virtualization (SEV) feature. Signed-off-by: Brijesh Singh Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Cc: Tom Lendacky Cc: kvm@vger.kernel.org Cc: Jonathan Corbet Cc: Borislav Petkov Link: https://lkml.kernel.org/r/20171020143059.3291-2-brijesh.singh@amd.com --- Documentation/x86/amd-memory-encryption.txt | 30 +++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/amd-memory-encryption.txt b/Documentation/x86/amd-memory-encryption.txt index f512ab718541..afc41f544dab 100644 --- a/Documentation/x86/amd-memory-encryption.txt +++ b/Documentation/x86/amd-memory-encryption.txt @@ -1,4 +1,5 @@ -Secure Memory Encryption (SME) is a feature found on AMD processors. +Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV) are +features found on AMD processors. SME provides the ability to mark individual pages of memory as encrypted using the standard x86 page tables. A page that is marked encrypted will be @@ -6,24 +7,38 @@ automatically decrypted when read from DRAM and encrypted when written to DRAM. SME can therefore be used to protect the contents of DRAM from physical attacks on the system. +SEV enables running encrypted virtual machines (VMs) in which the code and data +of the guest VM are secured so that a decrypted version is available only +within the VM itself. SEV guest VMs have the concept of private and shared +memory. Private memory is encrypted with the guest-specific key, while shared +memory may be encrypted with hypervisor key. When SME is enabled, the hypervisor +key is the same key which is used in SME. + A page is encrypted when a page table entry has the encryption bit set (see below on how to determine its position). The encryption bit can also be specified in the cr3 register, allowing the PGD table to be encrypted. Each successive level of page tables can also be encrypted by setting the encryption bit in the page table entry that points to the next table. This allows the full page table hierarchy to be encrypted. Note, this means that just because the -encryption bit is set in cr3, doesn't imply the full hierarchy is encyrpted. +encryption bit is set in cr3, doesn't imply the full hierarchy is encrypted. Each page table entry in the hierarchy needs to have the encryption bit set to achieve that. So, theoretically, you could have the encryption bit set in cr3 so that the PGD is encrypted, but not set the encryption bit in the PGD entry for a PUD which results in the PUD pointed to by that entry to not be encrypted. -Support for SME can be determined through the CPUID instruction. The CPUID -function 0x8000001f reports information related to SME: +When SEV is enabled, instruction pages and guest page tables are always treated +as private. All the DMA operations inside the guest must be performed on shared +memory. Since the memory encryption bit is controlled by the guest OS when it +is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware +forces the memory encryption bit to 1. + +Support for SME and SEV can be determined through the CPUID instruction. The +CPUID function 0x8000001f reports information related to SME: 0x8000001f[eax]: Bit[0] indicates support for SME + Bit[1] indicates support for SEV 0x8000001f[ebx]: Bits[5:0] pagetable bit number used to activate memory encryption @@ -39,6 +54,13 @@ determine if SME is enabled and/or to enable memory encryption: Bit[23] 0 = memory encryption features are disabled 1 = memory encryption features are enabled +If SEV is supported, MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if +SEV is active: + + 0xc0010131: + Bit[0] 0 = memory encryption is not active + 1 = memory encryption is active + Linux relies on BIOS to set this bit if BIOS has determined that the reduction in the physical address space as a result of enabling memory encryption (see CPUID information above) will not conflict with the address space resource -- cgit v1.2.3 From ec473a9c40416ef1802088e9f9d44d40c16aac6a Mon Sep 17 00:00:00 2001 From: Sebastien Bourdelin Date: Thu, 2 Nov 2017 14:17:12 -0400 Subject: dt-bindings: bus: Add documentation for the Technologic Systems NBUS Add binding documentation for the Technologic Systems NBUS that is used to interface with peripherals in the FPGA of the TS-4600 SoM. Signed-off-by: Sebastien Bourdelin Acked-by: Linus Walleij Acked-by: Rob Herring Signed-off-by: Arnd Bergmann --- Documentation/devicetree/bindings/bus/ts-nbus.txt | 50 +++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/ts-nbus.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/bus/ts-nbus.txt b/Documentation/devicetree/bindings/bus/ts-nbus.txt new file mode 100644 index 000000000000..2a10d065b9fa --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ts-nbus.txt @@ -0,0 +1,50 @@ +Technologic Systems NBUS + +The NBUS is a bus used to interface with peripherals in the Technologic +Systems FPGA on the TS-4600 SoM. + +Required properties : + - compatible : "technologic,ts-nbus" + - #address-cells : must be 1 + - #size-cells : must be 0 + - pwms : The PWM bound to the FPGA + - ts,data-gpios : The 8 GPIO pins connected to the data lines on the FPGA + - ts,csn-gpios : The GPIO pin connected to the csn line on the FPGA + - ts,txrx-gpios : The GPIO pin connected to the txrx line on the FPGA + - ts,strobe-gpios : The GPIO pin connected to the stobe line on the FPGA + - ts,ale-gpios : The GPIO pin connected to the ale line on the FPGA + - ts,rdy-gpios : The GPIO pin connected to the rdy line on the FPGA + +Child nodes: + +The NBUS node can contain zero or more child nodes representing peripherals +on the bus. + +Example: + + nbus { + compatible = "technologic,ts-nbus"; + pinctrl-0 = <&nbus_pins>; + #address-cells = <1>; + #size-cells = <0>; + pwms = <&pwm 2 83>; + ts,data-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH + &gpio0 1 GPIO_ACTIVE_HIGH + &gpio0 2 GPIO_ACTIVE_HIGH + &gpio0 3 GPIO_ACTIVE_HIGH + &gpio0 4 GPIO_ACTIVE_HIGH + &gpio0 5 GPIO_ACTIVE_HIGH + &gpio0 6 GPIO_ACTIVE_HIGH + &gpio0 7 GPIO_ACTIVE_HIGH>; + ts,csn-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; + ts,txrx-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>; + ts,strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>; + ts,ale-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; + ts,rdy-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>; + + watchdog@2a { + compatible = "..."; + + /* ... */ + }; + }; -- cgit v1.2.3 From e8815241173ebba4ccad490d4907b354b795fa5c Mon Sep 17 00:00:00 2001 From: Minwoo Im Date: Tue, 7 Nov 2017 22:23:01 +0900 Subject: null_blk: fix default values in documentation null_blk.c has initial value of (1) nr_devices as 1. (2) completion_nsec as 10,000ns, not 10.000ns. documentation should be updated for fixes above. Signed-off-by: Minwoo Im Signed-off-by: Jens Axboe --- Documentation/block/null_blk.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/null_blk.txt b/Documentation/block/null_blk.txt index b7161c8e70f2..fcf7f8487d8e 100644 --- a/Documentation/block/null_blk.txt +++ b/Documentation/block/null_blk.txt @@ -38,7 +38,7 @@ gb=[Size in GB]: Default: 250GB bs=[Block size (in bytes)]: Default: 512 bytes The block size reported to the system. -nr_devices=[Number of devices]: Default: 2 +nr_devices=[Number of devices]: Default: 1 Number of block devices instantiated. They are instantiated as /dev/nullb0, etc. @@ -52,7 +52,7 @@ irqmode=[0-2]: Default: 1-Soft-irq 2: Timer: Waits a specific period (completion_nsec) for each IO before completion. -completion_nsec=[ns]: Default: 10.000ns +completion_nsec=[ns]: Default: 10,000ns Combined with irqmode=2 (timer). The time each completion event must wait. submit_queues=[1..nr_cpus]: -- cgit v1.2.3 From bf9fc98b736b8a3837040d5ce3a7caf04fa0859c Mon Sep 17 00:00:00 2001 From: Minwoo Im Date: Tue, 7 Nov 2017 09:25:37 -0700 Subject: null_blk: add an usage for shared tags in documentation Add usage explanation for a shared_tags, introduced by commit: 82f402fefa50 ("null_blk: add support for shared tags") Signed-off-by: Minwoo Im Reworded slightly. Signed-off-by: Jens Axboe --- Documentation/block/null_blk.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/block/null_blk.txt b/Documentation/block/null_blk.txt index fcf7f8487d8e..733927a7b501 100644 --- a/Documentation/block/null_blk.txt +++ b/Documentation/block/null_blk.txt @@ -77,3 +77,8 @@ use_lightnvm=[0/1]: Default: 0 no_sched=[0/1]: Default: 0 0: nullb* use default blk-mq io scheduler. 1: nullb* doesn't use io scheduler. + +shared_tags=[0/1]: Default: 0 + 0: Tag set is not shared. + 1: Tag set shared between devices for blk-mq. Only makes sense with + nr_devices > 1, otherwise there's no tag set to share. -- cgit v1.2.3 From fa1e6a8aec47d5623f8361907f57e44f112a8f4f Mon Sep 17 00:00:00 2001 From: Jonas Gorski Date: Wed, 20 Sep 2017 13:14:04 +0200 Subject: tty/bcm63xx_uart: allow naming clock in device tree Codify using a named clock for the refclk of the uart. This makes it easier if we might need to add a gating clock (like present on the BCM6345). Signed-off-by: Jonas Gorski Acked-by: Rob Herring Acked-by: Greg Kroah-Hartman Reviewed-by: Florian Fainelli Cc: Mark Rutland Cc: Kevin Cernekee Cc: Russell King Cc: linux-mips@linux-mips.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-serial@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: bcm-kernel-feedback-list@broadcom.com Patchwork: https://patchwork.linux-mips.org/patch/17328/ Signed-off-by: Ralf Baechle Signed-off-by: James Hogan --- Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt b/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt index 5c52e5eef16d..8b2b0460259a 100644 --- a/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt +++ b/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt @@ -11,6 +11,11 @@ Required properties: - clocks: Clock driving the hardware; used to figure out the baud rate divisor. + +Optional properties: + +- clock-names: Should be "refclk". + Example: uart0: serial@14e00520 { @@ -19,6 +24,7 @@ Example: interrupt-parent = <&periph_intc>; interrupts = <2>; clocks = <&periph_clk>; + clock-names = "refclk"; }; clocks { -- cgit v1.2.3 From 4ad1ceec05e49175d0f967cc87628101e79176f6 Mon Sep 17 00:00:00 2001 From: Troy Kisky Date: Fri, 3 Nov 2017 10:29:59 -0700 Subject: net: fec: Let fec_ptp have its own interrupt routine This is better for code locality and should slightly speed up normal interrupts. This also allows PPS clock output to start working for i.mx7. This is because i.mx7 was already using the limit of 3 interrupts, and needed another. Signed-off-by: Troy Kisky Acked-by: Fugang Duan Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/fsl-fec.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt index 6f55bdd52f8a..f0dc94409107 100644 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt @@ -34,6 +34,19 @@ Optional properties: - fsl,err006687-workaround-present: If present indicates that the system has the hardware workaround for ERR006687 applied and does not need a software workaround. + -interrupt-names: names of the interrupts listed in interrupts property in + the same order. The defaults if not specified are + __Number of interrupts__ __Default__ + 1 "int0" + 2 "int0", "pps" + 3 "int0", "int1", "int2" + 4 "int0", "int1", "int2", "pps" + The order may be changed as long as they correspond to the interrupts + property. Currently, only i.mx7 uses "int1" and "int2". They correspond to + tx/rx queues 1 and 2. "int0" will be used for queue 0 and ENET_MII interrupts. + For imx6sx, "int0" handles all 3 queues and ENET_MII. "pps" is for the pulse + per second interrupt associated with 1588 precision time protocol(PTP). + Optional subnodes: - mdio : specifies the mdio bus in the FEC, used as a container for phy nodes -- cgit v1.2.3 From 7afc19bc217475000e5cd8eb0009665453c8439e Mon Sep 17 00:00:00 2001 From: Tom Herbert Date: Sun, 5 Nov 2017 15:58:26 -0800 Subject: ila: Add ila.txt Add documenation for kernel ILA. This describes ILA, features, configuration gives some examples. Signed-off-by: Tom Herbert Signed-off-by: David S. Miller --- Documentation/networking/ila.txt | 285 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 285 insertions(+) create mode 100644 Documentation/networking/ila.txt (limited to 'Documentation') diff --git a/Documentation/networking/ila.txt b/Documentation/networking/ila.txt new file mode 100644 index 000000000000..78df879abd26 --- /dev/null +++ b/Documentation/networking/ila.txt @@ -0,0 +1,285 @@ +Identifier Locator Addressing (ILA) + + +Introduction +============ + +Identifier-locator addressing (ILA) is a technique used with IPv6 that +differentiates between location and identity of a network node. Part of an +address expresses the immutable identity of the node, and another part +indicates the location of the node which can be dynamic. Identifier-locator +addressing can be used to efficiently implement overlay networks for +network virtualization as well as solutions for use cases in mobility. + +ILA can be thought of as means to implement an overlay network without +encapsulation. This is accomplished by performing network address +translation on destination addresses as a packet traverses a network. To +the network, an ILA translated packet appears to be no different than any +other IPv6 packet. For instance, if the transport protocol is TCP then an +ILA translated packet looks like just another TCP/IPv6 packet. The +advantage of this is that ILA is transparent to the network so that +optimizations in the network, such as ECMP, RSS, GRO, GSO, etc., just work. + +The ILA protocol is described in Internet-Draft draft-herbert-intarea-ila. + + +ILA terminology +=============== + + - Identifier A number that identifies an addressable node in the network + independent of its location. ILA identifiers are sixty-four + bit values. + + - Locator A network prefix that routes to a physical host. Locators + provide the topological location of an addressed node. ILA + locators are sixty-four bit prefixes. + + - ILA mapping + A mapping of an ILA identifier to a locator (or to a + locator and meta data). An ILA domain maintains a database + that contains mappings for all destinations in the domain. + + - SIR address + An IPv6 address composed of a SIR prefix (upper sixty- + four bits) and an identifier (lower sixty-four bits). + SIR addresses are visible to applications and provide a + means for them to address nodes independent of their + location. + + - ILA address + An IPv6 address composed of a locator (upper sixty-four + bits) and an identifier (low order sixty-four bits). ILA + addresses are never visible to an application. + + - ILA host An end host that is capable of performing ILA translations + on transmit or receive. + + - ILA router A network node that performs ILA translation and forwarding + of translated packets. + + - ILA forwarding cache + A type of ILA router that only maintains a working set + cache of mappings. + + - ILA node A network node capable of performing ILA translations. This + can be an ILA router, ILA forwarding cache, or ILA host. + + +Operation +========= + +There are two fundamental operations with ILA: + + - Translate a SIR address to an ILA address. This is performed on ingress + to an ILA overlay. + + - Translate an ILA address to a SIR address. This is performed on egress + from the ILA overlay. + +ILA can be deployed either on end hosts or intermediate devices in the +network; these are provided by "ILA hosts" and "ILA routers" respectively. +Configuration and datapath for these two points of deployment is somewhat +different. + +The diagram below illustrates the flow of packets through ILA as well +as showing ILA hosts and routers. + + +--------+ +--------+ + | Host A +-+ +--->| Host B | + | | | (2) ILA (') | | + +--------+ | ...addressed.... ( ) +--------+ + V +---+--+ . packet . +---+--+ (_) + (1) SIR | | ILA |----->-------->---->| ILA | | (3) SIR + addressed +->|router| . . |router|->-+ addressed + packet +---+--+ . IPv6 . +---+--+ packet + / . Network . + / . . +--+-++--------+ + +--------+ / . . |ILA || Host | + | Host +--+ . .- -|host|| | + | | . . +--+-++--------+ + +--------+ ................ + + +Transport checksum handling +=========================== + +When an address is translated by ILA, an encapsulated transport checksum +that includes the translated address in a pseudo header may be rendered +incorrect on the wire. This is a problem for intermediate devices, +including checksum offload in NICs, that process the checksum. There are +three options to deal with this: + +- no action Allow the checksum to be incorrect on the wire. Before + a receiver verifies a checksum the ILA to SIR address + translation must be done. + +- adjust transport checksum + When ILA translation is performed the packet is parsed + and if a transport layer checksum is found then it is + adjusted to reflect the correct checksum per the + translated address. + +- checksum neutral mapping + When an address is translated the difference can be offset + elsewhere in a part of the packet that is covered by the + the checksum. The low order sixteen bits of the identifier + are used. This method is preferred since it doesn't require + parsing a packet beyond the IP header and in most cases the + adjustment can be precomputed and saved with the mapping. + +Note that the checksum neutral adjustment affects the low order sixteen +bits of the identifier. When ILA to SIR address translation is done on +egress the low order bits are restored to the original value which +restores the identifier as it was originally sent. + + +Identifier types +================ + +ILA defines different types of identifiers for different use cases. + +The defined types are: + + 0: interface identifier + + 1: locally unique identifier + + 2: virtual networking identifier for IPv4 address + + 3: virtual networking identifier for IPv6 unicast address + + 4: virtual networking identifier for IPv6 multicast address + + 5: non-local address identifier + +In the current implementation of kernel ILA only locally unique identifiers +(LUID) are supported. LUID allows for a generic, unformatted 64 bit +identifier. + + +Identifier formats +================== + +Kernel ILA supports two optional fields in an identifier for formatting: +"C-bit" and "identifier type". The presence of these fields is determined +by configuration as demonstrated below. + +If the identifier type is present it occupies the three highest order +bits of an identifier. The possible values are given in the above list. + +If the C-bit is present, this is used as an indication that checksum +neutral mapping has been done. The C-bit can only be set in an +ILA address, never a SIR address. + +In the simplest format the identifier types, C-bit, and checksum +adjustment value are not present so an identifier is considered an +unstructured sixty-four bit value. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +The checksum neutral adjustment may be configured to always be +present using neutral-map-auto. In this case there is no C-bit, but the +checksum adjustment is in the low order 16 bits. The identifier is +still sixty-four bits. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Checksum-neutral adjustment | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +The C-bit may used to explicitly indicate that checksum neutral +mapping has been applied to an ILA address. The format is: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |C| Identifier | + | +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Checksum-neutral adjustment | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +The identifier type field may be present to indicate the identifier +type. If it is not present then the type is inferred based on mapping +configuration. The checksum neutral adjustment may automatically +used with the identifier type as illustrated below. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type| Identifier | + +-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Checksum-neutral adjustment | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +If the identifier type and the C-bit can be present simultaneously so +the identifier format would be: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type|C| Identifier | + +-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Checksum-neutral adjustment | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +Configuration +============= + +There are two methods to configure ILA mappings. One is by using LWT routes +and the other is ila_xlat (called from NFHOOK PREROUTING hook). ila_xlat +is intended to be used in the receive path for ILA hosts . + +An ILA router has also been implemented in XDP. Description of that is +outside the scope of this document. + +The usage of for ILA LWT routes is: + +ip route add DEST/128 encap ila LOC csum-mode MODE ident-type TYPE via ADDR + +Destination (DEST) can either be a SIR address (for an ILA host or ingress +ILA router) or an ILA address (egress ILA router). LOC is the sixty-four +bit locator (with format W:X:Y:Z) that overwrites the upper sixty-four +bits of the destination address. Checksum MODE is one of "no-action", +"adj-transport", "neutral-map", and "neutral-map-auto". If neutral-map is +set then the C-bit will be present. Identifier TYPE one of "luid" or +"use-format." In the case of use-format, the identifier type field is +present and the effective type is taken from that. + +The usage of ila_xlat is: + +ip ila add loc_match MATCH loc LOC csum-mode MODE ident-type TYPE + +MATCH indicates the incoming locator that must be matched to apply +a the translaiton. LOC is the locator that overwrites the upper +sixty-four bits of the destination address. MODE and TYPE have the +same meanings as described above. + + +Some examples +============= + +# Configure an ILA route that uses checksum neutral mapping as well +# as type field. Note that the type field is set in the SIR address +# (the 2000 implies type is 1 which is LUID). +ip route add 3333:0:0:1:2000:0:1:87/128 encap ila 2001:0:87:0 \ + csum-mode neutral-map ident-type use-format + +# Configure an ILA LWT route that uses auto checksum neutral mapping +# (no C-bit) and configure identifier type to be LUID so that the +# identifier type field will not be present. +ip route add 3333:0:0:1:2000:0:2:87/128 encap ila 2001:0:87:1 \ + csum-mode neutral-map-auto ident-type luid + +ila_xlat configuration + +# Configure an ILA to SIR mapping that matches a locator and overwrites +# it with a SIR address (3333:0:0:1 in this example). The C-bit and +# identifier field are used. +ip ila add loc_match 2001:0:119:0 loc 3333:0:0:1 \ + csum-mode neutral-map-auto ident-type use-format + +# Configure an ILA to SIR mapping where checksum neutral is automatically +# set without the C-bit and the identifier type is configured to be LUID +# so that the identifier type field is not present. +ip ila add loc_match 2001:0:119:0 loc 3333:0:0:1 \ + csum-mode neutral-map-auto ident-type use-format -- cgit v1.2.3 From 68d50fa494f6265288b60151a6460b33290593c2 Mon Sep 17 00:00:00 2001 From: Egil Hjelmeland Date: Mon, 6 Nov 2017 12:42:02 +0100 Subject: net: dsa: lan9303: Fix syntax errors in device tree examples Signed-off-by: Egil Hjelmeland Reviewed-by: Vivien Didelot Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/dsa/lan9303.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt index 4448d063ddf6..464d6bf87605 100644 --- a/Documentation/devicetree/bindings/net/dsa/lan9303.txt +++ b/Documentation/devicetree/bindings/net/dsa/lan9303.txt @@ -52,7 +52,7 @@ I2C managed mode: port@1 { /* external port 1 */ reg = <1>; - label = "lan1; + label = "lan1"; }; port@2 { /* external port 2 */ @@ -89,7 +89,7 @@ MDIO managed mode: port@1 { /* external port 1 */ reg = <1>; - label = "lan1; + label = "lan1"; }; port@2 { /* external port 2 */ -- cgit v1.2.3 From a9687aa2764dd2669602bd19dc636cbeef5293d5 Mon Sep 17 00:00:00 2001 From: Eric Nelson Date: Wed, 1 Nov 2017 08:01:20 -0700 Subject: rtc: add support for NXP PCF85363 real-time clock Note that alarms are not currently implemented. 64 bytes of nvmem is supported and exposed in sysfs (# is the instance number, starting with 0): /sys/bus/nvmem/devices/pcf85363-#/nvmem Signed-off-by: Eric Nelson Reviewed-by: Fabio Estevam Tested-by: Alexandre Belloni Acked-by: Rob Herring Signed-off-by: Alexandre Belloni --- Documentation/devicetree/bindings/rtc/pcf85363.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/pcf85363.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/pcf85363.txt b/Documentation/devicetree/bindings/rtc/pcf85363.txt new file mode 100644 index 000000000000..76fdabc59742 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/pcf85363.txt @@ -0,0 +1,17 @@ +NXP PCF85363 Real Time Clock +============================ + +Required properties: +- compatible: Should contain "nxp,pcf85363". +- reg: I2C address for chip. + +Optional properties: +- interrupts: IRQ line for the RTC (not implemented). + +Example: + +pcf85363: pcf85363@51 { + compatible = "nxp,pcf85363"; + reg = <0x51>; +}; + -- cgit v1.2.3 From 47427379ea80f1368ccec6ba20874fc19a9f0cc4 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 7 Nov 2017 10:28:06 -0800 Subject: documentation: fb: update list of available compiled-in fonts Update list of available compiled-in fonts in lib/fonts/: add 6x10 and drop RomanLarge (which was reverted 12 years ago). Also sort the list alphabetically. Signed-off-by: Randy Dunlap Acked-by: Geert Uytterhoeven # v1 Signed-off-by: Jonathan Corbet --- Documentation/fb/fbcon.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/fb/fbcon.txt b/Documentation/fb/fbcon.txt index a38d3aa4d189..79c22d096bbc 100644 --- a/Documentation/fb/fbcon.txt +++ b/Documentation/fb/fbcon.txt @@ -77,8 +77,8 @@ C. Boot options 1. fbcon=font: Select the initial font to use. The value 'name' can be any of the - compiled-in fonts: VGA8x16, 7x14, 10x18, VGA8x8, MINI4x6, RomanLarge, - SUN8x16, SUN12x22, ProFont6x11, Acorn8x8, PEARL8x8. + compiled-in fonts: 10x18, 6x10, 7x14, Acorn8x8, MINI4x6, + PEARL8x8, ProFont6x11, SUN12x22, SUN8x16, VGA8x16, VGA8x8. Note, not all drivers can handle font with widths not divisible by 8, such as vga16fb. -- cgit v1.2.3 From 0759e80b84e34a84e7e46e2b1adb528c83d84a47 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 7 Nov 2017 11:33:49 +0100 Subject: PM / QoS: Fix device resume latency framework The special value of 0 for device resume latency PM QoS means "no restriction", but there are two problems with that. First, device resume latency PM QoS requests with 0 as the value are always put in front of requests with positive values in the priority lists used internally by the PM QoS framework, causing 0 to be chosen as an effective constraint value. However, that 0 is then interpreted as "no restriction" effectively overriding the other requests with specific restrictions which is incorrect. Second, the users of device resume latency PM QoS have no way to specify that *any* resume latency at all should be avoided, which is an artificial limitation in general. To address these issues, modify device resume latency PM QoS to use S32_MAX as the "no constraint" value and 0 as the "no latency at all" one and rework its users (the cpuidle menu governor, the genpd QoS governor and the runtime PM framework) to follow these changes. Also add a special "n/a" value to the corresponding user space I/F to allow user space to indicate that it cannot accept any resume latencies at all for the given device. Fixes: 85dc0b8a4019 (PM / QoS: Make it possible to expose PM QoS latency constraints) Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323 Reported-by: Reinette Chatre Signed-off-by: Rafael J. Wysocki Tested-by: Reinette Chatre Tested-by: Geert Uytterhoeven Tested-by: Tero Kristo Reviewed-by: Ramesh Thomas --- Documentation/ABI/testing/sysfs-devices-power | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index f4b24c327665..80a00f7b6667 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -211,7 +211,9 @@ Description: device, after it has been suspended at run time, from a resume request to the moment the device will be ready to process I/O, in microseconds. If it is equal to 0, however, this means that - the PM QoS resume latency may be arbitrary. + the PM QoS resume latency may be arbitrary and the special value + "n/a" means that user space cannot accept any resume latency at + all for the given device. Not all drivers support this attribute. If it isn't supported, it is not present. -- cgit v1.2.3 From e0e1e39de490a2d9b8a173363ccf2415ddada871 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sat, 28 Oct 2017 15:37:17 +0200 Subject: pinctrl: Add skew-delay pin config and bindings Some pin controllers (such as the Gemini) can control the expected clock skew and output delay on certain pins with a sub-nanosecond granularity. This is typically done by shunting in a number of double inverters in front of or behind the pin. Make it possible to configure this with a generic binding. Cc: devicetree@vger.kernel.org Acked-by: Rob Herring Acked-by: Hans Ulli Kroll Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index 4483cc31e531..ad9bbbba36e9 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -271,6 +271,10 @@ output-high - set the pin to output mode with high level sleep-hardware-state - indicate this is sleep related state which will be programmed into the registers for the sleep state. slew-rate - set the slew rate +skew-delay - this affects the expected clock skew on input pins + and the delay before latching a value to an output + pin. Typically indicates how many double-inverters are + used to delay the signal. For example: -- cgit v1.2.3 From 60ad481f74a6d5ffb38e2c2ea325324e82081e7e Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sat, 28 Oct 2017 15:37:19 +0200 Subject: pinctrl: gemini: Implement clock skew/delay config This enabled pin config on the Gemini driver and implements pin skew/delay so that the ethernet pins clocking can be properly configured. Acked-by: Hans Ulli Kroll Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt index 61466c58faae..d857b67fab72 100644 --- a/Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt @@ -9,8 +9,14 @@ The pin controller node must be a subnode of the system controller node. Required properties: - compatible: "cortina,gemini-pinctrl" -Subnodes of the pin controller contain pin control multiplexing set-up. -Please refer to pinctrl-bindings.txt for generic pin multiplexing nodes. +Subnodes of the pin controller contain pin control multiplexing set-up +and pin configuration of individual pins. + +Please refer to pinctrl-bindings.txt for generic pin multiplexing nodes +and generic pin config nodes. + +Supported configurations: +- skew-delay is supported on the Ethernet pins Example: -- cgit v1.2.3 From 8d6cfb14088e340acd56264f52a60c8f8f735854 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Thu, 2 Nov 2017 14:59:42 +0530 Subject: pinctrl: qcom: spmi-gpio: Add pmi8994 gpio support Update the binding and driver for pmi8994-gpios Signed-off-by: Rajendra Nayak Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index 5b12c57e7f02..5c25fcb29fb5 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -15,6 +15,7 @@ PMIC's from Qualcomm. "qcom,pm8921-gpio" "qcom,pm8941-gpio" "qcom,pm8994-gpio" + "qcom,pmi8994-gpio" "qcom,pma8084-gpio" "qcom,pmi8994-gpio" @@ -85,6 +86,7 @@ to specify in a pin configuration subnode: gpio1-gpio44 for pm8921 gpio1-gpio36 for pm8941 gpio1-gpio22 for pm8994 + gpio1-gpio10 for pmi8994 gpio1-gpio22 for pma8084 gpio1-gpio10 for pmi8994 -- cgit v1.2.3 From f0fbe7bce733561b76a5b55c5f4625888acd3792 Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Tue, 7 Nov 2017 19:15:47 +0100 Subject: gpio: Move irqdomain into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding Acked-by: Grygorii Strashko Signed-off-by: Linus Walleij --- Documentation/gpio/driver.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index fc1d2f83564d..dcf6af1d9e56 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -254,7 +254,7 @@ GPIO irqchips usually fall in one of two categories: static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank) unsigned long wa_lock_flags; raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags); - generic_handle_irq(irq_find_mapping(bank->chip.irqdomain, bit)); + generic_handle_irq(irq_find_mapping(bank->chip.irq.domain, bit)); raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags); * GENERIC CHAINED GPIO irqchips: these are the same as "CHAINED GPIO irqchips", -- cgit v1.2.3 From dc7b0387ee894c115ef5ddcaaf794125d6d9058c Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Tue, 7 Nov 2017 19:15:52 +0100 Subject: gpio: Move irq_valid_mask into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding Acked-by: Grygorii Strashko Signed-off-by: Linus Walleij --- Documentation/gpio/driver.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index dcf6af1d9e56..d8de1c7de85a 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -313,8 +313,8 @@ symbol: mark all the child IRQs as having the other IRQ as parent. If there is a need to exclude certain GPIOs from the IRQ domain, you can -set .irq_need_valid_mask of the gpiochip before gpiochip_add_data() is -called. This allocates an .irq_valid_mask with as many bits set as there +set .irq.need_valid_mask of the gpiochip before gpiochip_add_data() is +called. This allocates an .irq.valid_mask with as many bits set as there are GPIOs in the chip. Drivers can exclude GPIOs by clearing bits from this mask. The mask must be filled in before gpiochip_irqchip_add() or gpiochip_irqchip_add_nested() is called. -- cgit v1.2.3 From 2a96c818f484bcc16f42a09b030a470f2b44df04 Mon Sep 17 00:00:00 2001 From: Keiji Hayashibara Date: Tue, 24 Oct 2017 10:54:25 +0100 Subject: dt-bindings: nvmem: add description for UniPhier eFuse Add uniphier-efuse dt-bindings documentation. Signed-off-by: Keiji Hayashibara Acked-by: Rob Herring Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/nvmem/uniphier-efuse.txt | 49 ++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt new file mode 100644 index 000000000000..eccf490d5a6d --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt @@ -0,0 +1,49 @@ += UniPhier eFuse device tree bindings = + +This UniPhier eFuse must be under soc-glue. + +Required properties: +- compatible: should be "socionext,uniphier-efuse" +- reg: should contain the register location and length + += Data cells = +Are child nodes of efuse, bindings of which as described in +bindings/nvmem/nvmem.txt + +Example: + + soc-glue@5f900000 { + compatible = "socionext,uniphier-ld20-soc-glue-debug", + "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x5f900000 0x2000>; + + efuse@100 { + compatible = "socionext,uniphier-efuse"; + reg = <0x100 0x28>; + }; + + efuse@200 { + compatible = "socionext,uniphier-efuse"; + reg = <0x200 0x68>; + #address-cells = <1>; + #size-cells = <1>; + + /* Data cells */ + usb_mon: usb-mon@54 { + reg = <0x54 0xc>; + }; + }; + }; + += Data consumers = +Are device nodes which consume nvmem data cells. + +Example: + + usb { + ... + nvmem-cells = <&usb_mon>; + nvmem-cell-names = "usb_mon"; + } -- cgit v1.2.3 From b7fe57b802c4f12da20920229acb9fff92300ad4 Mon Sep 17 00:00:00 2001 From: Icenowy Zheng Date: Tue, 24 Oct 2017 10:54:34 +0100 Subject: nvmem: sunxi-sid: add support for A64/H5's SID controller Allwinner A64/H5 SoCs come with a SID controller like the one in H3, but without the silicon bug that makes the initial value at 0x200 wrong, so the value at 0x200 can be directly read. Add support for this kind of SID controller. Signed-off-by: Icenowy Zheng Acked-by: Rob Herring Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt index ef06d061913c..6ea0836939ee 100644 --- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt @@ -5,6 +5,7 @@ Required properties: "allwinner,sun4i-a10-sid" "allwinner,sun7i-a20-sid" "allwinner,sun8i-h3-sid" + "allwinner,sun50i-a64-sid" - reg: Should contain registers location and length -- cgit v1.2.3 From 74ce1896c6c65b2f8cccbf59162d542988835835 Mon Sep 17 00:00:00 2001 From: Masahiro Yamada Date: Thu, 2 Nov 2017 11:51:25 +0900 Subject: kbuild: clean up *.dtb and *.dtb.S patterns from top-level Makefile We need to add "clean-files" in Makfiles to clean up DT blobs, but we often miss to do so. Since there are no source files that end with .dtb or .dtb.S, so we can clean-up those files from the top-level Makefile. Signed-off-by: Masahiro Yamada Acked-by: Arnd Bergmann Signed-off-by: Rob Herring --- Documentation/kbuild/makefiles.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 329e740adea7..411b7282c287 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1153,7 +1153,6 @@ When kbuild executes, the following steps are followed (roughly): Example: targets += $(dtb-y) - clean-files += *.dtb DTC_FLAGS ?= -p 1024 --- 6.8 Custom kbuild commands -- cgit v1.2.3 From f00d79750712511d0a83c108eea0d44b680a915f Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Wed, 11 Oct 2017 12:10:14 -0700 Subject: EVM: Allow userspace to signal an RSA key has been loaded EVM will only perform validation once a key has been loaded. This key may either be a symmetric trusted key (for HMAC validation and creation) or the public half of an asymmetric key (for digital signature validation). The /sys/kernel/security/evm interface allows userland to signal that a symmetric key has been loaded, but does not allow userland to signal that an asymmetric public key has been loaded. This patch extends the interface to permit userspace to pass a bitmask of loaded key types. It also allows userspace to block loading of a symmetric key in order to avoid a compromised system from being able to load an additional key type later. Signed-off-by: Matthew Garrett Signed-off-by: Mimi Zohar --- Documentation/ABI/testing/evm | 47 ++++++++++++++++++++++++++++++------------- 1 file changed, 33 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/evm b/Documentation/ABI/testing/evm index 8374d4557e5d..a0bbccb00736 100644 --- a/Documentation/ABI/testing/evm +++ b/Documentation/ABI/testing/evm @@ -7,17 +7,36 @@ Description: HMAC-sha1 value across the extended attributes, storing the value as the extended attribute 'security.evm'. - EVM depends on the Kernel Key Retention System to provide it - with a trusted/encrypted key for the HMAC-sha1 operation. - The key is loaded onto the root's keyring using keyctl. Until - EVM receives notification that the key has been successfully - loaded onto the keyring (echo 1 > /evm), EVM - can not create or validate the 'security.evm' xattr, but - returns INTEGRITY_UNKNOWN. Loading the key and signaling EVM - should be done as early as possible. Normally this is done - in the initramfs, which has already been measured as part - of the trusted boot. For more information on creating and - loading existing trusted/encrypted keys, refer to: - Documentation/keys-trusted-encrypted.txt. (A sample dracut - patch, which loads the trusted/encrypted key and enables - EVM, is available from http://linux-ima.sourceforge.net/#EVM.) + EVM supports two classes of security.evm. The first is + an HMAC-sha1 generated locally with a + trusted/encrypted key stored in the Kernel Key + Retention System. The second is a digital signature + generated either locally or remotely using an + asymmetric key. These keys are loaded onto root's + keyring using keyctl, and EVM is then enabled by + echoing a value to /evm: + + 1: enable HMAC validation and creation + 2: enable digital signature validation + 3: enable HMAC and digital signature validation and HMAC + creation + + Further writes will be blocked if HMAC support is enabled or + if bit 32 is set: + + echo 0x80000002 >/evm + + will enable digital signature validation and block + further writes to /evm. + + Until this is done, EVM can not create or validate the + 'security.evm' xattr, but returns INTEGRITY_UNKNOWN. + Loading keys and signaling EVM should be done as early + as possible. Normally this is done in the initramfs, + which has already been measured as part of the trusted + boot. For more information on creating and loading + existing trusted/encrypted keys, refer to: + Documentation/keys-trusted-encrypted.txt. Both dracut + (via 97masterkey and 98integrity) and systemd (via + core/ima-setup) have support for loading keys at boot + time. -- cgit v1.2.3 From 8adc430603d67e76a0f8491df21654f691acda62 Mon Sep 17 00:00:00 2001 From: "Andrew F. Davis" Date: Wed, 8 Nov 2017 15:24:59 -0600 Subject: ASoC: cs42l56: Fix reset GPIO name in example DT binding The binding states the reset GPIO property shall be named "cirrus,gpio-nreset" and this is what the driver looks for, but the example uses "gpio-reset". Fix this here. Fixes: 3bb40619aca8 ("ASoC: cs42l56: bindings: sound: Add bindings for CS42L56 CODEC") Signed-off-by: Andrew F. Davis Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/cs42l56.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/cs42l56.txt b/Documentation/devicetree/bindings/sound/cs42l56.txt index 4feb0eb27ea4..4ba520a28ae8 100644 --- a/Documentation/devicetree/bindings/sound/cs42l56.txt +++ b/Documentation/devicetree/bindings/sound/cs42l56.txt @@ -55,7 +55,7 @@ Example: codec: codec@4b { compatible = "cirrus,cs42l56"; reg = <0x4b>; - gpio-reset = <&gpio 10 0>; + cirrus,gpio-nreset = <&gpio 10 0>; cirrus,chgfreq-divisor = <0x05>; cirrus.ain1_ref_cfg; cirrus,micbias-lvl = <5>; -- cgit v1.2.3 From f7bc9b209e27c0b617378400136cc663a6314d0c Mon Sep 17 00:00:00 2001 From: "Gautham R. Shenoy" Date: Tue, 7 Nov 2017 13:39:29 +0530 Subject: cpufreq: stats: Handle the case when trans_table goes beyond PAGE_SIZE On platforms with large number of Pstates, the transition table, which is a NxN matrix, can overflow beyond the PAGE_SIZE boundary. This can be seen on POWER9 which has 100+ Pstates. As a result, each time the trans_table is read for any of the CPUs, we will get the following error. --------------------------------------------------- fill_read_buffer: show+0x0/0xa0 returned bad count --------------------------------------------------- This patch ensures that in case of an overflow, we print a warning once in the dmesg and return FILE TOO LARGE error for this and all subsequent accesses of trans_table. Signed-off-by: Gautham R. Shenoy Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-freq/cpufreq-stats.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/cpufreq-stats.txt b/Documentation/cpu-freq/cpufreq-stats.txt index 2bbe207354ed..a873855c811d 100644 --- a/Documentation/cpu-freq/cpufreq-stats.txt +++ b/Documentation/cpu-freq/cpufreq-stats.txt @@ -90,6 +90,9 @@ Freq_i to Freq_j. Freq_i is in descending order with increasing rows and Freq_j is in descending order with increasing columns. The output here also contains the actual freq values for each row and column for better readability. +If the transition table is bigger than PAGE_SIZE, reading this will +return an -EFBIG error. + -------------------------------------------------------------------------------- :/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table From : To -- cgit v1.2.3 From 4dd6f17eb913d3d23dd6c07950627ac2c3068dca Mon Sep 17 00:00:00 2001 From: Michael Mueller Date: Thu, 6 Jul 2017 14:22:20 +0200 Subject: KVM: s390: clear_io_irq() requests are not expected for adapter interrupts There is a chance to delete not yet delivered I/O interrupts if an exploiter uses the subsystem identification word 0x0000 while processing a KVM_DEV_FLIC_CLEAR_IO_IRQ ioctl. -EINVAL will be returned now instead in that case. Classic interrupts will always have bit 0x10000 set in the schid while adapter interrupts have a zero schid. The clear_io_irq interface is only useful for classic interrupts (as adapter interrupts belong to many devices). Let's make this interface more strict and forbid a schid of 0. Signed-off-by: Michael Mueller Reviewed-by: Halil Pasic Reviewed-by: Christian Borntraeger Reviewed-by: Cornelia Huck Signed-off-by: Christian Borntraeger --- Documentation/virtual/kvm/devices/s390_flic.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/devices/s390_flic.txt b/Documentation/virtual/kvm/devices/s390_flic.txt index 2f1cbf1301d2..27ad53c7149d 100644 --- a/Documentation/virtual/kvm/devices/s390_flic.txt +++ b/Documentation/virtual/kvm/devices/s390_flic.txt @@ -156,3 +156,6 @@ FLIC with an unknown group or attribute gives the error code EINVAL (instead of ENXIO, as specified in the API documentation). It is not possible to conclude that a FLIC operation is unavailable based on the error code resulting from a usage attempt. + +Note: The KVM_DEV_FLIC_CLEAR_IO_IRQ ioctl will return EINVAL in case a zero +schid is specified. -- cgit v1.2.3 From b2596d70351370530d3fce16f3b6e6f1cd4dbdf0 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Wed, 20 Sep 2017 12:51:51 -0300 Subject: dt-bindings: mfd: mc13xxx: Remove obsolete property The 'fsl,spi-num-chipselects' property is obsolete according to Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt, so remove it from the example. Signed-off-by: Fabio Estevam Acked-by: Rob Herring Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/mc13xxx.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt index 39ba4146769d..ac235fe385fc 100644 --- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt +++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt @@ -113,7 +113,6 @@ MC13892 regulators: Examples: ecspi@70010000 { /* ECSPI1 */ - fsl,spi-num-chipselects = <2>; cs-gpios = <&gpio4 24 0>, /* GPIO4_24 */ <&gpio4 25 0>; /* GPIO4_25 */ -- cgit v1.2.3 From 924d4db29f1237f9fe90a7439d2ee81837d282bd Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Thu, 9 Nov 2017 11:39:20 +0100 Subject: gpio: rcar: Add r8a77995 (R-Car D3) support This patch adds binding for r8a77995 (R-Car D3). This SoC can use "renesas,rcar-gen3-gpio" fallback compatibility. So, this patch doesn't modify the gpio-rcar driver. Signed-off-by: Yoshihiro Shimoda Acked-by: Simon Horman Acked-by: Rob Herring Signed-off-by: Geert Uytterhoeven Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt index 41137a1cc099..a7ac460ad657 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt @@ -15,6 +15,7 @@ Required Properties: - "renesas,gpio-r8a7795": for R8A7795 (R-Car H3) compatible GPIO controller. - "renesas,gpio-r8a7796": for R8A7796 (R-Car M3-W) compatible GPIO controller. - "renesas,gpio-r8a77970": for R8A77970 (R-Car V3M) compatible GPIO controller. + - "renesas,gpio-r8a77995": for R8A77995 (R-Car D3) compatible GPIO controller. - "renesas,rcar-gen1-gpio": for a generic R-Car Gen1 GPIO controller. - "renesas,rcar-gen2-gpio": for a generic R-Car Gen2 or RZ/G1 GPIO controller. - "renesas,rcar-gen3-gpio": for a generic R-Car Gen3 GPIO controller. -- cgit v1.2.3 From da9a1446d248f673a8560ce46251ff620214ab7b Mon Sep 17 00:00:00 2001 From: Christian Borntraeger Date: Thu, 9 Nov 2017 10:00:45 +0100 Subject: KVM: s390: provide a capability for AIS state migration The AIS capability was introduced in 4.12, while the interface to migrate the state was added in 4.13. Unfortunately it is not possible for userspace to detect the migration capability without creating a flic kvm device. As in QEMU the cpu model detection runs on the "none" machine this will result in cpu model issues regarding the "ais" capability. To get the "ais" capability properly let's add a new KVM capability that tells userspace that AIS states can be migrated. Signed-off-by: Christian Borntraeger Reviewed-by: Cornelia Huck Reviewed-by: David Hildenbrand Acked-by: Halil Pasic --- Documentation/virtual/kvm/api.txt | 9 +++++++++ Documentation/virtual/kvm/devices/s390_flic.txt | 2 ++ 2 files changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index e63a35fafef0..49540e53c4bd 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -4347,3 +4347,12 @@ This capability indicates that userspace can load HV_X64_MSR_VP_INDEX msr. Its value is used to denote the target vcpu for a SynIC interrupt. For compatibilty, KVM initializes this msr to KVM's internal vcpu index. When this capability is absent, userspace can still query this msr's value. + +8.13 KVM_CAP_S390_AIS_MIGRATION + +Architectures: s390 +Parameters: none + +This capability indicates if the flic device will be able to get/set the +AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows +to discover this without having to create a flic device. diff --git a/Documentation/virtual/kvm/devices/s390_flic.txt b/Documentation/virtual/kvm/devices/s390_flic.txt index 27ad53c7149d..a4e20a090174 100644 --- a/Documentation/virtual/kvm/devices/s390_flic.txt +++ b/Documentation/virtual/kvm/devices/s390_flic.txt @@ -151,6 +151,8 @@ struct kvm_s390_ais_all { to an ISC (MSB0 bit 0 to ISC 0 and so on). The combination of simm bit and nimm bit presents AIS mode for a ISC. + KVM_DEV_FLIC_AISM_ALL is indicated by KVM_CAP_S390_AIS_MIGRATION. + Note: The KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR device ioctls executed on FLIC with an unknown group or attribute gives the error code EINVAL (instead of ENXIO, as specified in the API documentation). It is not possible to conclude -- cgit v1.2.3 From bad12f43d0b164aad2a32b48bdc09d0d9680a213 Mon Sep 17 00:00:00 2001 From: Aleksandar Markovic Date: Thu, 9 Nov 2017 18:09:30 +0100 Subject: Documentation: Add device tree binding for Goldfish FB driver Add documentation for DT binding of Goldfish FB driver. The compatible string used by OS for binding the driver is "google,goldfish-fb". Signed-off-by: Miodrag Dinic Signed-off-by: Goran Ferenc Signed-off-by: Aleksandar Markovic Acked-by: Rob Herring Cc: David Airlie Cc: Douglas Leung Cc: James Hogan Cc: Mark Rutland Cc: Paul Burton Cc: Petar Jovanovic Cc: Raghu Gandham Signed-off-by: Bartlomiej Zolnierkiewicz --- .../devicetree/bindings/display/google,goldfish-fb.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/google,goldfish-fb.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/google,goldfish-fb.txt b/Documentation/devicetree/bindings/display/google,goldfish-fb.txt new file mode 100644 index 000000000000..751fa9f51e5d --- /dev/null +++ b/Documentation/devicetree/bindings/display/google,goldfish-fb.txt @@ -0,0 +1,17 @@ +Android Goldfish framebuffer + +Android Goldfish framebuffer device used by Android emulator. + +Required properties: + +- compatible : should contain "google,goldfish-fb" +- reg : +- interrupts : + +Example: + + display-controller@1f008000 { + compatible = "google,goldfish-fb"; + interrupts = <0x10>; + reg = <0x1f008000 0x100>; + }; -- cgit v1.2.3 From 48c926cd3414c7e628909f6f831394184816da87 Mon Sep 17 00:00:00 2001 From: Marco Franchi Date: Wed, 8 Nov 2017 14:27:48 -0200 Subject: dt-bindings: Remove leading zeros from bindings notation Improve the binding example by removing all the leading zeros to fix the following dtc warnings: Warning (unit_address_format): Node /XXX unit name should not have leading 0s Converted using the following command: perl -p -i -e 's/\@0+([0-9a-f])/\@$1/g' `find ./Documentation/devicetree/bindings "*.txt"` Some unnecessary changes were manually fixed. Signed-off-by: Marco Franchi Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/samsung/pmu.txt | 2 +- .../devicetree/bindings/arm/samsung/samsung-boards.txt | 2 +- Documentation/devicetree/bindings/arm/sp810.txt | 2 +- .../devicetree/bindings/arm/vexpress-sysreg.txt | 2 +- Documentation/devicetree/bindings/ata/ahci-platform.txt | 2 +- Documentation/devicetree/bindings/ata/imx-sata.txt | 2 +- Documentation/devicetree/bindings/bus/imx-weim.txt | 2 +- Documentation/devicetree/bindings/bus/sunxi-rsb.txt | 2 +- .../devicetree/bindings/clock/arm-syscon-icst.txt | 2 +- .../devicetree/bindings/clock/clk-exynos-audss.txt | 2 +- .../devicetree/bindings/clock/clk-s5pv210-audss.txt | 2 +- .../devicetree/bindings/clock/dove-divider-clock.txt | 2 +- Documentation/devicetree/bindings/clock/imx1-clock.txt | 4 ++-- Documentation/devicetree/bindings/clock/imx6q-clock.txt | 4 ++-- .../devicetree/bindings/clock/maxim,max77686.txt | 4 ++-- Documentation/devicetree/bindings/clock/st/st,clkgen.txt | 2 +- Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 4 ++-- Documentation/devicetree/bindings/clock/sunxi.txt | 16 ++++++++-------- Documentation/devicetree/bindings/clock/ti,cdce706.txt | 2 +- Documentation/devicetree/bindings/crypto/sun4i-ss.txt | 2 +- .../devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 2 +- Documentation/devicetree/bindings/display/imx/hdmi.txt | 4 ++-- .../devicetree/bindings/display/simple-framebuffer.txt | 2 +- .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 ++-- Documentation/devicetree/bindings/dma/sun4i-dma.txt | 4 ++-- Documentation/devicetree/bindings/dma/sun6i-dma.txt | 2 +- Documentation/devicetree/bindings/dma/ti-edma.txt | 6 +++--- Documentation/devicetree/bindings/dma/zxdma.txt | 2 +- .../bindings/firmware/nvidia,tegra186-bpmp.txt | 2 +- .../devicetree/bindings/gpio/gpio-dsp-keystone.txt | 2 +- .../devicetree/bindings/gpio/gpio-tz1090-pdc.txt | 2 +- Documentation/devicetree/bindings/gpio/gpio-tz1090.txt | 2 +- Documentation/devicetree/bindings/i2c/i2c-axxia.txt | 2 +- Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt | 2 +- .../devicetree/bindings/iio/magnetometer/ak8974.txt | 2 +- .../devicetree/bindings/iio/magnetometer/ak8975.txt | 2 +- .../devicetree/bindings/input/sun4i-lradc-keys.txt | 2 +- .../devicetree/bindings/input/touchscreen/egalax-ts.txt | 2 +- .../devicetree/bindings/input/touchscreen/imx6ul_tsc.txt | 2 +- .../interrupt-controller/allwinner,sunxi-nmi.txt | 2 +- .../bindings/interrupt-controller/ti,keystone-irq.txt | 2 +- Documentation/devicetree/bindings/iommu/qcom,iommu.txt | 2 +- .../devicetree/bindings/leds/register-bit-led.txt | 16 ++++++++-------- .../devicetree/bindings/mailbox/ti,message-manager.txt | 2 +- Documentation/devicetree/bindings/marvell.txt | 4 ++-- Documentation/devicetree/bindings/media/i2c/tc358743.txt | 2 +- Documentation/devicetree/bindings/media/img-ir-rev1.txt | 2 +- Documentation/devicetree/bindings/media/stih-cec.txt | 2 +- .../devicetree/bindings/media/stih407-c8sectpfe.txt | 2 +- Documentation/devicetree/bindings/media/sunxi-ir.txt | 2 +- Documentation/devicetree/bindings/mfd/max77686.txt | 2 +- Documentation/devicetree/bindings/mfd/max77802.txt | 2 +- Documentation/devicetree/bindings/mfd/mfd.txt | 2 +- Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt | 4 ++-- Documentation/devicetree/bindings/mfd/sun6i-prcm.txt | 2 +- Documentation/devicetree/bindings/mfd/syscon.txt | 2 +- Documentation/devicetree/bindings/mmc/mmc.txt | 2 +- Documentation/devicetree/bindings/mmc/sdhci-st.txt | 4 ++-- Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 4 ++-- Documentation/devicetree/bindings/mtd/sunxi-nand.txt | 2 +- .../devicetree/bindings/net/allwinner,sun4i-emac.txt | 2 +- .../devicetree/bindings/net/allwinner,sun4i-mdio.txt | 4 ++-- .../devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt | 2 +- Documentation/devicetree/bindings/net/brcm,bcmgenet.txt | 2 +- Documentation/devicetree/bindings/net/can/m_can.txt | 2 +- Documentation/devicetree/bindings/net/can/sun4i_can.txt | 4 ++-- .../bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +- .../devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 4 ++-- Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt | 2 +- Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 2 +- Documentation/devicetree/bindings/nvmem/nvmem.txt | 2 +- Documentation/devicetree/bindings/nvmem/qfprom.txt | 2 +- .../devicetree/bindings/pci/nvidia,tegra20-pcie.txt | 12 ++++++------ .../devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt | 2 +- Documentation/devicetree/bindings/phy/mxs-usb-phy.txt | 2 +- Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt | 2 +- .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 2 +- .../devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt | 4 ++-- .../bindings/pinctrl/img,tz1090-pdc-pinctrl.txt | 4 ++-- .../devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt | 4 ++-- .../bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt | 2 +- .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt | 2 +- Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt | 2 +- .../devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt | 2 +- Documentation/devicetree/bindings/power/fsl,imx-gpc.txt | 4 ++-- .../bindings/power/reset/imx-snvs-poweroff.txt | 2 +- .../devicetree/bindings/power/reset/keystone-reset.txt | 4 ++-- .../devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt | 2 +- Documentation/devicetree/bindings/pwm/pwm-sun4i.txt | 2 +- Documentation/devicetree/bindings/regulator/max77686.txt | 2 +- Documentation/devicetree/bindings/regulator/max77802.txt | 2 +- .../bindings/reset/allwinner,sunxi-clock-reset.txt | 2 +- Documentation/devicetree/bindings/reset/fsl,imx-src.txt | 6 +++--- .../devicetree/bindings/reset/ti-syscon-reset.txt | 2 +- Documentation/devicetree/bindings/rtc/sun6i-rtc.txt | 2 +- Documentation/devicetree/bindings/rtc/sunxi-rtc.txt | 2 +- .../devicetree/bindings/soc/fsl/cpm_qe/qe/par_io.txt | 2 +- .../devicetree/bindings/soc/fsl/cpm_qe/qe/pincfg.txt | 2 +- .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 2 +- .../devicetree/bindings/sound/cdns,xtfpga-i2s.txt | 2 +- Documentation/devicetree/bindings/sound/fsl,asrc.txt | 2 +- Documentation/devicetree/bindings/sound/fsl,esai.txt | 2 +- Documentation/devicetree/bindings/sound/fsl,spdif.txt | 2 +- Documentation/devicetree/bindings/sound/imx-audmux.txt | 2 +- Documentation/devicetree/bindings/sound/samsung-i2s.txt | 2 +- Documentation/devicetree/bindings/sound/sun4i-codec.txt | 4 ++-- Documentation/devicetree/bindings/sound/sun4i-i2s.txt | 2 +- .../devicetree/bindings/sound/sun8i-a33-codec.txt | 2 +- .../devicetree/bindings/sound/sun8i-codec-analog.txt | 2 +- .../devicetree/bindings/sound/sunxi,sun4i-spdif.txt | 2 +- Documentation/devicetree/bindings/sound/zte,zx-spdif.txt | 2 +- Documentation/devicetree/bindings/spi/spi-sun4i.txt | 2 +- Documentation/devicetree/bindings/spi/spi-sun6i.txt | 4 ++-- Documentation/devicetree/bindings/sram/samsung-sram.txt | 2 +- Documentation/devicetree/bindings/sram/sunxi-sram.txt | 4 ++-- .../bindings/timer/allwinner,sun5i-a13-hstimer.txt | 2 +- .../devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt | 2 +- Documentation/devicetree/bindings/usb/am33xx-usb.txt | 2 +- Documentation/devicetree/bindings/usb/atmel-usb.txt | 4 ++-- Documentation/devicetree/bindings/usb/ohci-da8xx.txt | 2 +- Documentation/devicetree/bindings/usb/usb-ehci.txt | 2 +- Documentation/devicetree/bindings/usb/usb-ohci.txt | 2 +- Documentation/devicetree/bindings/usb/usb3503.txt | 2 +- Documentation/devicetree/bindings/usb/usbmisc-imx.txt | 2 +- Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 2 +- Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt | 2 +- 126 files changed, 172 insertions(+), 172 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt index bf5fc59a6938..088584a98cf4 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -62,7 +62,7 @@ pmu_system_controller: system-controller@10040000 { Example of clock consumer : -usb3503: usb3503@08 { +usb3503: usb3503@8 { /* ... */ clock-names = "refclk"; clocks = <&pmu_system_controller 0>; diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt index 3c551894f621..fa674818e7e8 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt @@ -71,7 +71,7 @@ Optional nodes: - compatible: only "samsung,secure-firmware" is currently supported - reg: address of non-secure SYSRAM used for communication with firmware - firmware@0203F000 { + firmware@203F000 { compatible = "samsung,secure-firmware"; reg = <0x0203F000 0x1000>; }; diff --git a/Documentation/devicetree/bindings/arm/sp810.txt b/Documentation/devicetree/bindings/arm/sp810.txt index 6808fb5dee40..1b2ab1ff5587 100644 --- a/Documentation/devicetree/bindings/arm/sp810.txt +++ b/Documentation/devicetree/bindings/arm/sp810.txt @@ -33,7 +33,7 @@ Required properties: property with the highest frequency Example: - v2m_sysctl: sysctl@020000 { + v2m_sysctl: sysctl@20000 { compatible = "arm,sp810", "arm,primecell"; reg = <0x020000 0x1000>; clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>; diff --git a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt index 00318d083c9e..50095802fb4a 100644 --- a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt +++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt @@ -37,7 +37,7 @@ Example: compatible = "arm,vexpress-sysreg"; reg = <0x10000000 0x1000>; - v2m_led_gpios: sys_led@08 { + v2m_led_gpios: sys_led@8 { compatible = "arm,vexpress-sysreg,sys_led"; gpio-controller; #gpio-cells = <2>; diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index fedc213b5f1a..c760ecb81381 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -56,7 +56,7 @@ Examples: interrupts = <115>; }; - ahci: sata@01c18000 { + ahci: sata@1c18000 { compatible = "allwinner,sun4i-a10-ahci"; reg = <0x01c18000 0x1000>; interrupts = <56>; diff --git a/Documentation/devicetree/bindings/ata/imx-sata.txt b/Documentation/devicetree/bindings/ata/imx-sata.txt index fa511db18408..a3d14719e478 100644 --- a/Documentation/devicetree/bindings/ata/imx-sata.txt +++ b/Documentation/devicetree/bindings/ata/imx-sata.txt @@ -25,7 +25,7 @@ Optional properties: Examples: -sata@02200000 { +sata@2200000 { compatible = "fsl,imx6q-ahci"; reg = <0x02200000 0x4000>; interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>; diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt index 6630d842c7a3..683eaf3aed79 100644 --- a/Documentation/devicetree/bindings/bus/imx-weim.txt +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt @@ -61,7 +61,7 @@ Timing property for child nodes. It is mandatory, not optional. Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM: - weim: weim@021b8000 { + weim: weim@21b8000 { compatible = "fsl,imx6q-weim"; reg = <0x021b8000 0x4000>; clocks = <&clks 196>; diff --git a/Documentation/devicetree/bindings/bus/sunxi-rsb.txt b/Documentation/devicetree/bindings/bus/sunxi-rsb.txt index 3dd28343b6ce..eb3ed628c6f1 100644 --- a/Documentation/devicetree/bindings/bus/sunxi-rsb.txt +++ b/Documentation/devicetree/bindings/bus/sunxi-rsb.txt @@ -28,7 +28,7 @@ which can normally be found in the datasheet. Example: - rsb@01f03400 { + rsb@1f03400 { compatible = "allwinner,sun8i-a23-rsb"; reg = <0x01f03400 0x400>; interrupts = <0 39 4>; diff --git a/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt b/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt index 27468119fd94..4cd81742038f 100644 --- a/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt +++ b/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt @@ -59,7 +59,7 @@ syscon: syscon@10000000 { compatible = "syscon"; reg = <0x10000000 0x1000>; - oscclk0: osc0@0c { + oscclk0: osc0@c { compatible = "arm,syscon-icst307"; #clock-cells = <0>; lock-offset = <0x20>; diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt index 0c3d6015868d..2cba012f5af0 100644 --- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt +++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt @@ -80,7 +80,7 @@ Example 3: I2S controller node that consumes the clock generated by the clock controller. Refer to the standard clock bindings for information about 'clocks' and 'clock-names' property. -i2s0: i2s@03830000 { +i2s0: i2s@3830000 { compatible = "samsung,i2s-v5"; reg = <0x03830000 0x100>; dmas = <&pdma0 10 diff --git a/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt b/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt index 4fc869b69d4a..f6272dcd96f4 100644 --- a/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt +++ b/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt @@ -43,7 +43,7 @@ Example: I2S controller node that consumes the clock generated by the clock controller. Refer to the standard clock bindings for information about 'clocks' and 'clock-names' property. - i2s0: i2s@03830000 { + i2s0: i2s@3830000 { /* ... */ clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; diff --git a/Documentation/devicetree/bindings/clock/dove-divider-clock.txt b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt index e3eb0f657c5e..217871f483c0 100644 --- a/Documentation/devicetree/bindings/clock/dove-divider-clock.txt +++ b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt @@ -21,7 +21,7 @@ Required properties: a size of 8. - #clock-cells : from common clock binding; shall be set to 1 -divider_clk: core-clock@0064 { +divider_clk: core-clock@64 { compatible = "marvell,dove-divider-clock"; reg = <0x0064 0x8>; #clock-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/imx1-clock.txt b/Documentation/devicetree/bindings/clock/imx1-clock.txt index b7adf4e3ea98..9823baf7acb6 100644 --- a/Documentation/devicetree/bindings/clock/imx1-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx1-clock.txt @@ -10,13 +10,13 @@ ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx1-clock.h for the full list of i.MX1 clock IDs. Examples: - clks: ccm@0021b000 { + clks: ccm@21b000 { #clock-cells = <1>; compatible = "fsl,imx1-ccm"; reg = <0x0021b000 0x1000>; }; - pwm: pwm@00208000 { + pwm: pwm@208000 { #pwm-cells = <2>; compatible = "fsl,imx1-pwm"; reg = <0x00208000 0x1000>; diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index aa0a4d423ef5..a45ca67a9d5f 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -14,14 +14,14 @@ Examples: #include -clks: ccm@020c4000 { +clks: ccm@20c4000 { compatible = "fsl,imx6q-ccm"; reg = <0x020c4000 0x4000>; interrupts = <0 87 0x04 0 88 0x04>; #clock-cells = <1>; }; -uart1: serial@02020000 { +uart1: serial@2020000 { compatible = "fsl,imx6q-uart", "fsl,imx21-uart"; reg = <0x02020000 0x4000>; interrupts = <0 26 0x04>; diff --git a/Documentation/devicetree/bindings/clock/maxim,max77686.txt b/Documentation/devicetree/bindings/clock/maxim,max77686.txt index 8398a3a5e106..3472b461ca93 100644 --- a/Documentation/devicetree/bindings/clock/maxim,max77686.txt +++ b/Documentation/devicetree/bindings/clock/maxim,max77686.txt @@ -46,7 +46,7 @@ Example: /* ... */ Node of the MFD chip - max77686: max77686@09 { + max77686: max77686@9 { compatible = "maxim,max77686"; interrupt-parent = <&wakeup_eint>; interrupts = <26 0>; @@ -71,7 +71,7 @@ Example: /* ... */ Node of the MFD chip - max77802: max77802@09 { + max77802: max77802@9 { compatible = "maxim,max77802"; interrupt-parent = <&wakeup_eint>; interrupts = <26 0>; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt index c35390f60545..7364953d0d0b 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt @@ -42,7 +42,7 @@ Required properties: Example: - clockgen-a@090ff000 { + clockgen-a@90ff000 { compatible = "st,clkgen-c32"; reg = <0x90ff000 0x1000>; diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt index 7eda08eb8a1e..4ca21c3a6fc9 100644 --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt @@ -36,7 +36,7 @@ For the PRCM CCUs on A83T/H3/A64, two more clocks are needed: - "iosc": the SoC's internal frequency oscillator Example for generic CCU: -ccu: clock@01c20000 { +ccu: clock@1c20000 { compatible = "allwinner,sun8i-h3-ccu"; reg = <0x01c20000 0x400>; clocks = <&osc24M>, <&osc32k>; @@ -46,7 +46,7 @@ ccu: clock@01c20000 { }; Example for PRCM CCU: -r_ccu: clock@01f01400 { +r_ccu: clock@1f01400 { compatible = "allwinner,sun50i-a64-r-ccu"; reg = <0x01f01400 0x100>; clocks = <&osc24M>, <&osc32k>, <&iosc>, <&ccu CLK_PLL_PERIPH0>; diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index 8f7619d8c8d8..1a042e20b115 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -137,7 +137,7 @@ the address block, which is related to the overall mmc block. For example: -osc24M: clk@01c20050 { +osc24M: clk@1c20050 { #clock-cells = <0>; compatible = "allwinner,sun4i-a10-osc-clk"; reg = <0x01c20050 0x4>; @@ -145,7 +145,7 @@ osc24M: clk@01c20050 { clock-output-names = "osc24M"; }; -pll1: clk@01c20000 { +pll1: clk@1c20000 { #clock-cells = <0>; compatible = "allwinner,sun4i-a10-pll1-clk"; reg = <0x01c20000 0x4>; @@ -153,7 +153,7 @@ pll1: clk@01c20000 { clock-output-names = "pll1"; }; -pll5: clk@01c20020 { +pll5: clk@1c20020 { #clock-cells = <1>; compatible = "allwinner,sun4i-pll5-clk"; reg = <0x01c20020 0x4>; @@ -161,7 +161,7 @@ pll5: clk@01c20020 { clock-output-names = "pll5_ddr", "pll5_other"; }; -pll6: clk@01c20028 { +pll6: clk@1c20028 { #clock-cells = <1>; compatible = "allwinner,sun6i-a31-pll6-clk"; reg = <0x01c20028 0x4>; @@ -169,7 +169,7 @@ pll6: clk@01c20028 { clock-output-names = "pll6", "pll6x2"; }; -cpu: cpu@01c20054 { +cpu: cpu@1c20054 { #clock-cells = <0>; compatible = "allwinner,sun4i-a10-cpu-clk"; reg = <0x01c20054 0x4>; @@ -177,7 +177,7 @@ cpu: cpu@01c20054 { clock-output-names = "cpu"; }; -mmc0_clk: clk@01c20088 { +mmc0_clk: clk@1c20088 { #clock-cells = <1>; compatible = "allwinner,sun4i-a10-mmc-clk"; reg = <0x01c20088 0x4>; @@ -199,7 +199,7 @@ gmac_int_tx_clk: clk@3 { clock-output-names = "gmac_int_tx"; }; -gmac_clk: clk@01c20164 { +gmac_clk: clk@1c20164 { #clock-cells = <0>; compatible = "allwinner,sun7i-a20-gmac-clk"; reg = <0x01c20164 0x4>; @@ -211,7 +211,7 @@ gmac_clk: clk@01c20164 { clock-output-names = "gmac"; }; -mmc_config_clk: clk@01c13000 { +mmc_config_clk: clk@1c13000 { compatible = "allwinner,sun9i-a80-mmc-config-clk"; reg = <0x01c13000 0x10>; clocks = <&ahb0_gates 8>; diff --git a/Documentation/devicetree/bindings/clock/ti,cdce706.txt b/Documentation/devicetree/bindings/clock/ti,cdce706.txt index 616836e7e1e2..959d96632f5d 100644 --- a/Documentation/devicetree/bindings/clock/ti,cdce706.txt +++ b/Documentation/devicetree/bindings/clock/ti,cdce706.txt @@ -25,7 +25,7 @@ Example: }; }; ... - i2c0: i2c-master@0d090000 { + i2c0: i2c-master@d090000 { ... cdce706: clock-synth@69 { compatible = "ti,cdce706"; diff --git a/Documentation/devicetree/bindings/crypto/sun4i-ss.txt b/Documentation/devicetree/bindings/crypto/sun4i-ss.txt index 5d38e9b7033f..f2dc3d9bca92 100644 --- a/Documentation/devicetree/bindings/crypto/sun4i-ss.txt +++ b/Documentation/devicetree/bindings/crypto/sun4i-ss.txt @@ -14,7 +14,7 @@ Optional properties: - reset-names : must contain "ahb" Example: - crypto: crypto-engine@01c15000 { + crypto: crypto-engine@1c15000 { compatible = "allwinner,sun4i-a10-crypto"; reg = <0x01c15000 0x1000>; interrupts = ; diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt index ed5e0a7894ad..05176f1ae108 100644 --- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt @@ -42,7 +42,7 @@ Optional properties: example: -gpu_3d: gpu@00130000 { +gpu_3d: gpu@130000 { compatible = "vivante,gc"; reg = <0x00130000 0x4000>; interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>; diff --git a/Documentation/devicetree/bindings/display/imx/hdmi.txt b/Documentation/devicetree/bindings/display/imx/hdmi.txt index 66a8f86e5d12..6d021e71c9cf 100644 --- a/Documentation/devicetree/bindings/display/imx/hdmi.txt +++ b/Documentation/devicetree/bindings/display/imx/hdmi.txt @@ -32,11 +32,11 @@ Optional properties Example: - gpr: iomuxc-gpr@020e0000 { + gpr: iomuxc-gpr@20e0000 { /* ... */ }; - hdmi: hdmi@0120000 { + hdmi: hdmi@120000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,imx6q-hdmi"; diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.txt b/Documentation/devicetree/bindings/display/simple-framebuffer.txt index 8c9e9f515c87..5a9ce511be88 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.txt +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.txt @@ -78,7 +78,7 @@ chosen { stdout-path = "display0"; }; -soc@01c00000 { +soc@1c00000 { lcdc0: lcdc@1c0c000 { compatible = "allwinner,sun4i-a10-lcdc"; ... diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 92441086caba..b7faa6f6a326 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -266,7 +266,7 @@ connector { }; }; -hdmi: hdmi@01c16000 { +hdmi: hdmi@1c16000 { compatible = "allwinner,sun5i-a10s-hdmi"; reg = <0x01c16000 0x1000>; interrupts = <58>; @@ -305,7 +305,7 @@ hdmi: hdmi@01c16000 { }; }; -tve0: tv-encoder@01c0a000 { +tve0: tv-encoder@1c0a000 { compatible = "allwinner,sun4i-a10-tv-encoder"; reg = <0x01c0a000 0x1000>; clocks = <&ahb_gates 34>; diff --git a/Documentation/devicetree/bindings/dma/sun4i-dma.txt b/Documentation/devicetree/bindings/dma/sun4i-dma.txt index 3b484380c56a..8ad556aca70b 100644 --- a/Documentation/devicetree/bindings/dma/sun4i-dma.txt +++ b/Documentation/devicetree/bindings/dma/sun4i-dma.txt @@ -12,7 +12,7 @@ Required properties: second cell holding the request line number. Example: - dma: dma-controller@01c02000 { + dma: dma-controller@1c02000 { compatible = "allwinner,sun4i-a10-dma"; reg = <0x01c02000 0x1000>; interrupts = <27>; @@ -32,7 +32,7 @@ The three cells in order are: 3. The port ID as specified in the datasheet Example: - spi2: spi@01c17000 { + spi2: spi@1c17000 { compatible = "allwinner,sun4i-a10-spi"; reg = <0x01c17000 0x1000>; interrupts = <0 12 4>; diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt b/Documentation/devicetree/bindings/dma/sun6i-dma.txt index 98fbe1a5c6dd..717851407fac 100644 --- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt +++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt @@ -38,7 +38,7 @@ The two cells in order are: 2. The port ID as specified in the datasheet Example: -spi2: spi@01c6a000 { +spi2: spi@1c6a000 { compatible = "allwinner,sun6i-a31-spi"; reg = <0x01c6a000 0x1000>; interrupts = <0 67 4>; diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 41f0c1a07c56..66026dcf53e1 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -142,7 +142,7 @@ mcasp0: mcasp@48038000 { }; 2. -edma1: edma@02728000 { +edma1: edma@2728000 { compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc"; reg = <0x02728000 0x8000>; reg-names = "edma3_cc"; @@ -165,13 +165,13 @@ edma1: edma@02728000 { power-domains = <&k2g_pds 0x4f>; }; -edma1_tptc0: tptc@027b0000 { +edma1_tptc0: tptc@27b0000 { compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; reg = <0x027b0000 0x400>; power-domains = <&k2g_pds 0x4f>; }; -edma1_tptc1: tptc@027b8000 { +edma1_tptc1: tptc@27b8000 { compatible = "ti, k2g-edma3-tptc", "ti,edma3-tptc"; reg = <0x027b8000 0x400>; power-domains = <&k2g_pds 0x4f>; diff --git a/Documentation/devicetree/bindings/dma/zxdma.txt b/Documentation/devicetree/bindings/dma/zxdma.txt index 3207ceb04d0b..abec59f35fde 100644 --- a/Documentation/devicetree/bindings/dma/zxdma.txt +++ b/Documentation/devicetree/bindings/dma/zxdma.txt @@ -26,7 +26,7 @@ Controller: Client: Use specific request line passing from dmax For example, spdif0 tx channel request line is 4 - spdif0: spdif0@0b004000 { + spdif0: spdif0@b004000 { #sound-dai-cells = <0>; compatible = "zte,zx296702-spdif"; reg = <0x0b004000 0x1000>; diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt index e821e16ad65b..0c10802c8327 100644 --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt @@ -66,7 +66,7 @@ See ".../sram/sram.txt" for the bindings. Example: -hsp_top0: hsp@03c00000 { +hsp_top0: hsp@3c00000 { ... #mbox-cells = <2>; }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt b/Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt index 6c7e6c7302f5..0423699d74c7 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt @@ -25,7 +25,7 @@ Please refer to gpio.txt in this directory for details of the common GPIO bindings used by client devices. Example: - dspgpio0: keystone_dsp_gpio@02620240 { + dspgpio0: keystone_dsp_gpio@2620240 { compatible = "ti,keystone-dsp-gpio"; ti,syscon-dev = <&devctrl 0x240>; gpio-controller; diff --git a/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt b/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt index 1fd98ffa8cb7..528f5ef5a893 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt @@ -30,7 +30,7 @@ Optional properties: Example: - pdc_gpios: gpio-controller@02006500 { + pdc_gpios: gpio-controller@2006500 { gpio-controller; #gpio-cells = <2>; diff --git a/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt b/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt index 174cdf309170..b05a90e0ab29 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt @@ -59,7 +59,7 @@ Required properties: Example: - gpios: gpio-controller@02005800 { + gpios: gpio-controller@2005800 { #address-cells = <1>; #size-cells = <0>; compatible = "img,tz1090-gpio"; diff --git a/Documentation/devicetree/bindings/i2c/i2c-axxia.txt b/Documentation/devicetree/bindings/i2c/i2c-axxia.txt index 2296d782b4c2..7d53a2b79553 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-axxia.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-axxia.txt @@ -17,7 +17,7 @@ Optional properties : Example : -i2c@02010084000 { +i2c@2010084000 { compatible = "lsi,api2c"; device_type = "i2c"; #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt b/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt index 6b765485af7d..49df0053347a 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt @@ -24,7 +24,7 @@ Slave device properties: Example: - p2wi@01f03400 { + p2wi@1f03400 { compatible = "allwinner,sun6i-a31-p2wi"; reg = <0x01f03400 0x400>; interrupts = <0 39 4>; diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt index 77d5aba1bd8c..baecc4a85197 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt @@ -19,7 +19,7 @@ Optional properties: Example: -ak8974@0f { +ak8974@f { compatible = "asahi-kasei,ak8974"; reg = <0x0f>; avdd-supply = <&foo_reg>; diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt index e1e7dd3259f6..aa67ceb0d4e0 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt @@ -13,7 +13,7 @@ Optional properties: Example: -ak8975@0c { +ak8975@c { compatible = "asahi-kasei,ak8975"; reg = <0x0c>; gpios = <&gpj0 7 0>; diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt index 4357e498ef04..1458c3179a63 100644 --- a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt +++ b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt @@ -19,7 +19,7 @@ Example: #include - lradc: lradc@01c22800 { + lradc: lradc@1c22800 { compatible = "allwinner,sun4i-a10-lradc-keys"; reg = <0x01c22800 0x100>; interrupts = <31>; diff --git a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt index 49fa14ed155c..298e3442f143 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt @@ -10,7 +10,7 @@ Required properties: Example: - egalax_ts@04 { + touchscreen@4 { compatible = "eeti,egalax_ts"; reg = <0x04>; interrupt-parent = <&gpio1>; diff --git a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt index e67e58b61706..164915004424 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt @@ -21,7 +21,7 @@ Optional properties: each read. Valid values are 1, 4, 8, 16 and 32. Example: - tsc: tsc@02040000 { + tsc: tsc@2040000 { compatible = "fsl,imx6ul-tsc"; reg = <0x02040000 0x4000>, <0x0219c000 0x4000>; interrupts = , diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt index 4ae553eb333d..4903fb72d883 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt @@ -20,7 +20,7 @@ Required properties: Example: -sc-nmi-intc@01c00030 { +sc-nmi-intc@1c00030 { compatible = "allwinner,sun7i-a20-sc-nmi"; interrupt-controller; #interrupt-cells = <2>; diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt index d9bb106bdd16..5f94d7739d8d 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt @@ -20,7 +20,7 @@ Please refer to interrupts.txt in this directory for details of the common Interrupt Controllers bindings used by client devices. Example: - kirq0: keystone_irq0@026202a0 { + kirq0: keystone_irq0@26202a0 { compatible = "ti,keystone-irq"; ti,syscon-dev = <&devctrl 0x2a0>; interrupts = ; diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt index b2641ceb2b40..059139abce35 100644 --- a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt @@ -115,7 +115,7 @@ to non-secure vs secure interrupt line. iommus = <&apps_iommu 4>; }; - gpu@01c00000 { + gpu@1c00000 { ... iommus = <&gpu_iommu 1>, <&gpu_iommu 2>; }; diff --git a/Documentation/devicetree/bindings/leds/register-bit-led.txt b/Documentation/devicetree/bindings/leds/register-bit-led.txt index 59b56365f648..cf1ea403ba7a 100644 --- a/Documentation/devicetree/bindings/leds/register-bit-led.txt +++ b/Documentation/devicetree/bindings/leds/register-bit-led.txt @@ -32,7 +32,7 @@ syscon: syscon@10000000 { compatible = "arm,realview-pb1176-syscon", "syscon"; reg = <0x10000000 0x1000>; - led@08.0 { + led@8.0 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x01>; @@ -40,7 +40,7 @@ syscon: syscon@10000000 { linux,default-trigger = "heartbeat"; default-state = "on"; }; - led@08.1 { + led@8.1 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x02>; @@ -48,7 +48,7 @@ syscon: syscon@10000000 { linux,default-trigger = "mmc0"; default-state = "off"; }; - led@08.2 { + led@8.2 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x04>; @@ -56,35 +56,35 @@ syscon: syscon@10000000 { linux,default-trigger = "cpu0"; default-state = "off"; }; - led@08.3 { + led@8.3 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x08>; label = "versatile:3"; default-state = "off"; }; - led@08.4 { + led@8.4 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x10>; label = "versatile:4"; default-state = "off"; }; - led@08.5 { + led@8.5 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x20>; label = "versatile:5"; default-state = "off"; }; - led@08.6 { + led@8.6 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x40>; label = "versatile:6"; default-state = "off"; }; - led@08.7 { + led@8.7 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x80>; diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt index b449d025049f..c3b55b3ede8a 100644 --- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt @@ -29,7 +29,7 @@ Required properties: Example(K2G): ------------ - msgmgr: msgmgr@02a00000 { + msgmgr: msgmgr@2a00000 { compatible = "ti,k2g-message-manager"; #mbox-cells = <2>; reg-names = "queue_proxy_region", "queue_state_debug_region"; diff --git a/Documentation/devicetree/bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt index ea2b16ced49b..7f722316458a 100644 --- a/Documentation/devicetree/bindings/marvell.txt +++ b/Documentation/devicetree/bindings/marvell.txt @@ -446,7 +446,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. that services interrupts for this device. Example Discovery CPU Error node: - cpu-error@0070 { + cpu-error@70 { compatible = "marvell,mv64360-cpu-error"; reg = <0x70 0x10 0x128 0x28>; interrupts = <3>; @@ -466,7 +466,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. that services interrupts for this device. Example Discovery SRAM Controller node: - sram-ctrl@0380 { + sram-ctrl@380 { compatible = "marvell,mv64360-sram-ctrl"; reg = <0x380 0x80>; interrupts = <13>; diff --git a/Documentation/devicetree/bindings/media/i2c/tc358743.txt b/Documentation/devicetree/bindings/media/i2c/tc358743.txt index 5218921629ed..49f8bcc2ea4d 100644 --- a/Documentation/devicetree/bindings/media/i2c/tc358743.txt +++ b/Documentation/devicetree/bindings/media/i2c/tc358743.txt @@ -27,7 +27,7 @@ Documentation/devicetree/bindings/media/video-interfaces.txt. Example: - tc358743@0f { + tc358743@f { compatible = "toshiba,tc358743"; reg = <0x0f>; clocks = <&hdmi_osc>; diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt b/Documentation/devicetree/bindings/media/img-ir-rev1.txt index 5434ce61b925..ed9ec52b77e0 100644 --- a/Documentation/devicetree/bindings/media/img-ir-rev1.txt +++ b/Documentation/devicetree/bindings/media/img-ir-rev1.txt @@ -25,7 +25,7 @@ Optional properties: Example: - ir@02006200 { + ir@2006200 { compatible = "img,ir-rev1"; reg = <0x02006200 0x100>; interrupts = <29 4>; diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt b/Documentation/devicetree/bindings/media/stih-cec.txt index 8be2a040c6c6..ece0832fdeaf 100644 --- a/Documentation/devicetree/bindings/media/stih-cec.txt +++ b/Documentation/devicetree/bindings/media/stih-cec.txt @@ -13,7 +13,7 @@ Required properties: Example for STIH407: -sti-cec@094a087c { +sti-cec@94a087c { compatible = "st,stih-cec"; reg = <0x94a087c 0x64>; clocks = <&clk_sysin>; diff --git a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt index 6af3fc210ecc..c7888d6f6408 100644 --- a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt +++ b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt @@ -50,7 +50,7 @@ Example: /* stih410 SoC b2120 + b2004a + stv0367-pll(NIMB) + stv0367-tda18212 (NIMA) DT example) */ - c8sectpfe@08a20000 { + c8sectpfe@8a20000 { compatible = "st,stih407-c8sectpfe"; reg = <0x08a20000 0x10000>, <0x08a00000 0x4000>; reg-names = "stfe", "stfe-ram"; diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt index 302a0b183cb8..91648c569b1e 100644 --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt @@ -14,7 +14,7 @@ Optional properties: Example: -ir0: ir@01c21800 { +ir0: ir@1c21800 { compatible = "allwinner,sun4i-a10-ir"; clocks = <&apb0_gates 6>, <&ir0_clk>; clock-names = "apb", "ir"; diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt b/Documentation/devicetree/bindings/mfd/max77686.txt index 741e76688cf2..0f2587fa42cb 100644 --- a/Documentation/devicetree/bindings/mfd/max77686.txt +++ b/Documentation/devicetree/bindings/mfd/max77686.txt @@ -19,7 +19,7 @@ Required properties: Example: - max77686: pmic@09 { + max77686: pmic@9 { compatible = "maxim,max77686"; interrupt-parent = <&wakeup_eint>; interrupts = <26 0>; diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt b/Documentation/devicetree/bindings/mfd/max77802.txt index 51fc1a60caa5..f2f3fe75901c 100644 --- a/Documentation/devicetree/bindings/mfd/max77802.txt +++ b/Documentation/devicetree/bindings/mfd/max77802.txt @@ -18,7 +18,7 @@ Required properties: Example: - max77802: pmic@09 { + max77802: pmic@9 { compatible = "maxim,max77802"; interrupt-parent = <&intc>; interrupts = <26 IRQ_TYPE_NONE>; diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt index bcb6abb9d413..336c0495c8a3 100644 --- a/Documentation/devicetree/bindings/mfd/mfd.txt +++ b/Documentation/devicetree/bindings/mfd/mfd.txt @@ -41,7 +41,7 @@ foo@1000 { compatible = "syscon", "simple-mfd"; reg = <0x01000 0x1000>; - led@08.0 { + led@8.0 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x01>; diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt index badff3611a98..86dd8191b04c 100644 --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt @@ -10,7 +10,7 @@ Required properties: - #io-channel-cells: shall be 0, Example: - ths: ths@01c25000 { + ths: ths@1c25000 { compatible = "allwinner,sun8i-a33-ths"; reg = <0x01c25000 0x100>; #thermal-sensor-cells = <0>; @@ -47,7 +47,7 @@ Optional properties: Example: - rtp: rtp@01c25000 { + rtp: rtp@1c25000 { compatible = "allwinner,sun4i-a10-ts"; reg = <0x01c25000 0x100>; interrupts = <29>; diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt index 03c5a551da55..dd2c06540485 100644 --- a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt +++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt @@ -15,7 +15,7 @@ The prcm node may contain several subdevices definitions: Example: - prcm: prcm@01f01400 { + prcm: prcm@1f01400 { compatible = "allwinner,sun6i-a31-prcm"; reg = <0x01f01400 0x200>; diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt b/Documentation/devicetree/bindings/mfd/syscon.txt index 408f768686f1..8b92d4576c42 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.txt +++ b/Documentation/devicetree/bindings/mfd/syscon.txt @@ -18,7 +18,7 @@ Optional property: performed on the device. Examples: -gpr: iomuxc-gpr@020e0000 { +gpr: iomuxc-gpr@20e0000 { compatible = "fsl,imx6q-iomuxc-gpr", "syscon"; reg = <0x020e0000 0x38>; }; diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index b32ade645ad9..5934157cf2cd 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -143,7 +143,7 @@ sdhci@ab000000 { Example with sdio function subnode: -mmc3: mmc@01c12000 { +mmc3: mmc@1c12000 { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt b/Documentation/devicetree/bindings/mmc/sdhci-st.txt index e35645598315..6b3d40ca395e 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-st.txt @@ -74,7 +74,7 @@ mmc0: sdhci@fe81e000 { /* Example SD stih407 family configuration */ -mmc1: sdhci@09080000 { +mmc1: sdhci@9080000 { compatible = "st,sdhci-stih407", "st,sdhci"; reg = <0x09080000 0x7ff>; reg-names = "mmc"; @@ -90,7 +90,7 @@ mmc1: sdhci@09080000 { /* Example eMMC stih407 family configuration */ -mmc0: sdhci@09060000 { +mmc0: sdhci@9060000 { compatible = "st,sdhci-stih407", "st,sdhci"; reg = <0x09060000 0x7ff>, <0x9061008 0x20>; reg-names = "mmc", "top-mmc-delay"; diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt index 63b57e2a10fb..132e0007d7d6 100644 --- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt @@ -29,7 +29,7 @@ Optional properties: Examples: - Within .dtsi: - mmc0: mmc@01c0f000 { + mmc0: mmc@1c0f000 { compatible = "allwinner,sun5i-a13-mmc"; reg = <0x01c0f000 0x1000>; clocks = <&ahb_gates 8>, <&mmc0_clk>, <&mmc0_output_clk>, <&mmc0_sample_clk>; @@ -39,7 +39,7 @@ Examples: }; - Within dts: - mmc0: mmc@01c0f000 { + mmc0: mmc@1c0f000 { pinctrl-names = "default", "default"; pinctrl-0 = <&mmc0_pins_a>; pinctrl-1 = <&mmc0_cd_pin_reference_design>; diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt index a37c67bcb43b..5e13a5cdff03 100644 --- a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt +++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt @@ -31,7 +31,7 @@ see Documentation/devicetree/bindings/mtd/nand.txt for generic bindings. Examples: -nfc: nand@01c03000 { +nfc: nand@1c03000 { compatible = "allwinner,sun4i-a10-nand"; reg = <0x01c03000 0x1000>; interrupts = <0 37 1>; diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt index 10640b17c866..e98118aef5f6 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt @@ -10,7 +10,7 @@ Required properties: Example: -emac: ethernet@01c0b000 { +emac: ethernet@1c0b000 { compatible = "allwinner,sun4i-a10-emac"; reg = <0x01c0b000 0x1000>; interrupts = <55>; diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt index 4ec56413779d..ab5b8613b0ef 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt @@ -9,7 +9,7 @@ Optional properties: - phy-supply: phandle to a regulator if the PHY needs one Example at the SoC level: -mdio@01c0b080 { +mdio@1c0b080 { compatible = "allwinner,sun4i-a10-mdio"; reg = <0x01c0b080 0x14>; #address-cells = <1>; @@ -18,7 +18,7 @@ mdio@01c0b080 { And at the board level: -mdio@01c0b080 { +mdio@1c0b080 { phy-supply = <®_emac_3v3>; phy0: ethernet-phy@0 { diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt index ea4d752389a2..8b3f953656e3 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt +++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt @@ -15,7 +15,7 @@ Optional properties: Examples: - gmac: ethernet@01c50000 { + gmac: ethernet@1c50000 { compatible = "allwinner,sun7i-a20-gmac"; reg = <0x01c50000 0x10000>, <0x01c20164 0x4>; diff --git a/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt b/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt index 26c77d985faf..3956af1d30f3 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt +++ b/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt @@ -109,7 +109,7 @@ ethernet@f0ba0000 { reg = <0xf0ba0000 0xfc4c>; interrupts = <0x0 0x18 0x0>, <0x0 0x19 0x0>; - mdio@0e14 { + mdio@e14 { compatible = "brcm,genet-mdio-v4"; #address-cells = <0x1>; #size-cells = <0x0>; diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt b/Documentation/devicetree/bindings/net/can/m_can.txt index 78138333ff7a..63e90421d029 100644 --- a/Documentation/devicetree/bindings/net/can/m_can.txt +++ b/Documentation/devicetree/bindings/net/can/m_can.txt @@ -45,7 +45,7 @@ Required properties: Example: SoC dtsi: -m_can1: can@020e8000 { +m_can1: can@20e8000 { compatible = "bosch,m_can"; reg = <0x020e8000 0x4000>, <0x02298000 0x4000>; reg-names = "m_can", "message_ram"; diff --git a/Documentation/devicetree/bindings/net/can/sun4i_can.txt b/Documentation/devicetree/bindings/net/can/sun4i_can.txt index 84ed1909df76..f69845e6feaf 100644 --- a/Documentation/devicetree/bindings/net/can/sun4i_can.txt +++ b/Documentation/devicetree/bindings/net/can/sun4i_can.txt @@ -19,7 +19,7 @@ SoC common .dtsi file: allwinner,pull = <0>; }; ... - can0: can@01c2bc00 { + can0: can@1c2bc00 { compatible = "allwinner,sun4i-a10-can"; reg = <0x01c2bc00 0x400>; interrupts = <0 26 4>; @@ -29,7 +29,7 @@ SoC common .dtsi file: Board specific .dts file: - can0: can@01c2bc00 { + can0: can@1c2bc00 { pinctrl-names = "default"; pinctrl-0 = <&can0_pins_a>; status = "okay"; diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt index b2bd4704f859..86602f264dce 100644 --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt @@ -20,7 +20,7 @@ Optional properties: Example: -mmc3: mmc@01c12000 { +mmc3: mmc@1c12000 { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt index ef06d061913c..081c49c0dac0 100644 --- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt @@ -13,13 +13,13 @@ Are child nodes of qfprom, bindings of which as described in bindings/nvmem/nvmem.txt Example for sun4i: - sid@01c23800 { + sid@1c23800 { compatible = "allwinner,sun4i-a10-sid"; reg = <0x01c23800 0x10> }; Example for sun7i: - sid@01c23800 { + sid@1c23800 { compatible = "allwinner,sun7i-a20-sid"; reg = <0x01c23800 0x200> }; diff --git a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt index 6462e12d8de6..0415265c215a 100644 --- a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt +++ b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt @@ -10,7 +10,7 @@ Required Properties: Example: -otp: otp@0301c800 { +otp: otp@301c800 { compatible = "brcm,ocotp"; reg = <0x0301c800 0x2c>; brcm,ocotp-size = <2048>; diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt index 70d791b03ea1..f162c72b4e36 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt @@ -19,7 +19,7 @@ Optional properties: Example: - ocotp: ocotp@021bc000 { + ocotp: ocotp@21bc000 { compatible = "fsl,imx6q-ocotp", "syscon"; reg = <0x021bc000 0x4000>; clocks = <&clks IMX6QDL_CLK_IIM>; diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt b/Documentation/devicetree/bindings/nvmem/nvmem.txt index b52bc11e9597..fd06c09b822b 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.txt +++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt @@ -33,7 +33,7 @@ bits: Is pair of bit location and number of bits, which specifies offset For example: /* Provider */ - qfprom: qfprom@00700000 { + qfprom: qfprom@700000 { ... /* Data cells */ diff --git a/Documentation/devicetree/bindings/nvmem/qfprom.txt b/Documentation/devicetree/bindings/nvmem/qfprom.txt index 4ad68b7f5c18..26fe878d5c86 100644 --- a/Documentation/devicetree/bindings/nvmem/qfprom.txt +++ b/Documentation/devicetree/bindings/nvmem/qfprom.txt @@ -12,7 +12,7 @@ bindings/nvmem/nvmem.txt Example: - qfprom: qfprom@00700000 { + qfprom: qfprom@700000 { compatible = "qcom,qfprom"; reg = <0x00700000 0x8000>; ... diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index 982a74ea6df9..1b4d2803dad1 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -255,7 +255,7 @@ Tegra30: SoC DTSI: - pcie-controller@00003000 { + pcie-controller@3000 { compatible = "nvidia,tegra30-pcie"; device_type = "pci"; reg = <0x00003000 0x00000800 /* PADS registers */ @@ -334,7 +334,7 @@ SoC DTSI: Board DTS: - pcie-controller@00003000 { + pcie-controller@3000 { status = "okay"; avdd-pexa-supply = <&ldo1_reg>; @@ -360,7 +360,7 @@ Tegra124: SoC DTSI: - pcie-controller@01003000 { + pcie-controller@1003000 { compatible = "nvidia,tegra124-pcie"; device_type = "pci"; reg = <0x0 0x01003000 0x0 0x00000800 /* PADS registers */ @@ -425,7 +425,7 @@ SoC DTSI: Board DTS: - pcie-controller@01003000 { + pcie-controller@1003000 { status = "okay"; avddio-pex-supply = <&vdd_1v05_run>; @@ -456,7 +456,7 @@ Tegra210: SoC DTSI: - pcie-controller@01003000 { + pcie-controller@1003000 { compatible = "nvidia,tegra210-pcie"; device_type = "pci"; reg = <0x0 0x01003000 0x0 0x00000800 /* PADS registers */ @@ -521,7 +521,7 @@ SoC DTSI: Board DTS: - pcie-controller@01003000 { + pcie-controller@1003000 { status = "okay"; avdd-pll-uerefe-supply = <&avdd_1v05_pll>; diff --git a/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt b/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt index 761c4bc24a9b..10efff28b52b 100644 --- a/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt +++ b/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt @@ -15,7 +15,7 @@ Required properties For the child node: - #phy-cells: must be 0 Example: - pcie_phy: phy@0301d0a0 { + pcie_phy: phy@301d0a0 { compatible = "brcm,cygnus-pcie-phy"; reg = <0x0301d0a0 0x14>; diff --git a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt index 1d25b04cd05e..6ac98b3b5f57 100644 --- a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt +++ b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt @@ -23,7 +23,7 @@ Optional properties: the 17.78mA TX reference current. Default: 100 Example: -usbphy1: usbphy@020c9000 { +usbphy1: usbphy@20c9000 { compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy"; reg = <0x020c9000 0x1000>; interrupts = <0 44 0x04>; diff --git a/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt index f9853156e311..64f7109aea1f 100644 --- a/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt +++ b/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt @@ -25,7 +25,7 @@ It is recommended to list all clocks and resets available. The driver will only use those matching the phy_type. Example: - usbphy1: phy@00a01800 { + usbphy1: phy@a01800 { compatible = "allwinner,sun9i-a80-usb-phy"; reg = <0x00a01800 0x4>; clocks = <&usb_phy_clk 2>, <&usb_phy_clk 10>, diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt index 6f2ec9af0de2..09789fdfa749 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt @@ -89,7 +89,7 @@ Optional subnode-properties: Examples: -pio: pinctrl@01c20800 { +pio: pinctrl@1c20800 { compatible = "allwinner,sun5i-a13-pinctrl"; reg = <0x01c20800 0x400>; #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt index 42d74f8a1bcc..a1050b5982ec 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt @@ -58,14 +58,14 @@ Some requirements for using fsl,imx-pinctrl binding: configurations by referring to the phandle of that pin configuration node. Examples: -usdhc@0219c000 { /* uSDHC4 */ +usdhc@219c000 { /* uSDHC4 */ non-removable; vmmc-supply = <®_3p3v>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usdhc4_1>; }; -iomuxc@020e0000 { +iomuxc@20e0000 { compatible = "fsl,imx6q-iomuxc"; reg = <0x020e0000 0x4000>; diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt index 51b943cc9770..cf9ccdff4455 100644 --- a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt @@ -89,7 +89,7 @@ Valid values for pin and group names are: Example: - pinctrl_pdc: pinctrl@02006500 { + pinctrl_pdc: pinctrl@2006500 { #gpio-range-cells = <3>; compatible = "img,tz1090-pdc-pinctrl"; reg = <0x02006500 0x100>; @@ -121,7 +121,7 @@ Example board file extracts: }; }; - ir: ir@02006200 { + ir: ir@2006200 { pinctrl-names = "default"; pinctrl-0 = <&irmod_default>; }; diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt index 509faa87ad0e..2dfd9a3fc1e4 100644 --- a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt @@ -197,7 +197,7 @@ Valid values for pin and group names are: Example: - pinctrl: pinctrl@02005800 { + pinctrl: pinctrl@2005800 { #gpio-range-cells = <3>; compatible = "img,tz1090-pinctrl"; reg = <0x02005800 0xe4>; @@ -221,7 +221,7 @@ Example board file extract: }; }; - uart@02004b00 { + uart@2004b00 { pinctrl-names = "default"; pinctrl-0 = <&uart0_default>; }; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt index 4048f43a9d29..02e971c39d81 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt @@ -97,7 +97,7 @@ SoC file extract: Board file extract: ------------------- - pcie-controller@01003000 { + pcie-controller@1003000 { ... phys = <&padctl 0>; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt index 37d744750579..231fa1db7c5e 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt @@ -86,7 +86,7 @@ Examples: reg = <0 0x1020C020 0 0x1000>; }; - pinctrl@01c20800 { + pinctrl@1c20800 { compatible = "mediatek,mt8135-pinctrl"; reg = <0 0x1000B000 0 0x1000>; mediatek,pctl-regmap = <&syscfg_pctl_a &syscfg_pctl_b>; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt index 013c675b5b64..48b9be48af18 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt @@ -89,7 +89,7 @@ Example: interrupt-names = "irqmux"; ranges = <0 0x09610000 0x6000>; - pio0: gpio@09610000 { + pio0: gpio@9610000 { gpio-controller; #gpio-cells = <2>; interrupt-controller; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt index e312a71b2f94..aaf01e929eea 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt @@ -175,7 +175,7 @@ to specify in a pin configuration subnode: Example: - tlmm: pinctrl@01010000 { + tlmm: pinctrl@1010000 { compatible = "qcom,msm8996-pinctrl"; reg = <0x01010000 0x300000>; interrupts = <0 208 0>; diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt index 6c1498958d48..e371b262d709 100644 --- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt @@ -40,7 +40,7 @@ Optional properties: Example: - gpc: gpc@020dc000 { + gpc: gpc@20dc000 { compatible = "fsl,imx6q-gpc"; reg = <0x020dc000 0x4000>; interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>, @@ -80,7 +80,7 @@ that is a phandle pointing to the power domain the device belongs to. Example of a device that is part of the PU power domain: - vpu: vpu@02040000 { + vpu: vpu@2040000 { reg = <0x02040000 0x3c000>; /* ... */ power-domains = <&pd_pu>; diff --git a/Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt b/Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt index dc7c9bad63ea..1b81fcd9fb72 100644 --- a/Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt +++ b/Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt @@ -10,7 +10,7 @@ Required Properties: -reg: Specifies the physical address of the SNVS_LPCR register Example: - snvs@020cc000 { + snvs@20cc000 { compatible = "fsl,sec-v4.0-mon", "simple-bus"; #address-cells = <1>; #size-cells = <1>; diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt index c82f12e2d85c..c5c03789ed1e 100644 --- a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt +++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt @@ -37,12 +37,12 @@ Example 1: Setup keystone reset so that in case software reset or WDT0 is triggered it issues hard reset for SoC. -pllctrl: pll-controller@02310000 { +pllctrl: pll-controller@2310000 { compatible = "ti,keystone-pllctrl", "syscon"; reg = <0x02310000 0x200>; }; -devctrl: device-state-control@02620000 { +devctrl: device-state-control@2620000 { compatible = "ti,keystone-devctrl", "syscon"; reg = <0x02620000 0x1000>; }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt b/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt index 0f766333b6eb..37f91fa57654 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt @@ -8,7 +8,7 @@ Required properties: Example: -mcu@0a { +mcu@a { #gpio-cells = <2>; compatible = "fsl,mc9s08qg8-mpc8349emitx", "fsl,mcu-mpc8349emitx"; diff --git a/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt b/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt index c5171660eaf9..51ff54c8b8ef 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt @@ -14,7 +14,7 @@ Required properties: Example: - pwm: pwm@01c20e00 { + pwm: pwm@1c20e00 { compatible = "allwinner,sun7i-a20-pwm"; reg = <0x01c20e00 0xc>; clocks = <&osc24M>; diff --git a/Documentation/devicetree/bindings/regulator/max77686.txt b/Documentation/devicetree/bindings/regulator/max77686.txt index 0dded64d89d3..e9f7578ca09a 100644 --- a/Documentation/devicetree/bindings/regulator/max77686.txt +++ b/Documentation/devicetree/bindings/regulator/max77686.txt @@ -40,7 +40,7 @@ to get matched with their hardware counterparts as follow: Example: - max77686: pmic@09 { + max77686: pmic@9 { compatible = "maxim,max77686"; interrupt-parent = <&wakeup_eint>; interrupts = <26 IRQ_TYPE_NONE>; diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt b/Documentation/devicetree/bindings/regulator/max77802.txt index 879e98d3b9aa..b82943d83677 100644 --- a/Documentation/devicetree/bindings/regulator/max77802.txt +++ b/Documentation/devicetree/bindings/regulator/max77802.txt @@ -71,7 +71,7 @@ has not been disabled for that state using "regulator-off-in-suspend". Example: - max77802@09 { + max77802@9 { compatible = "maxim,max77802"; interrupt-parent = <&wakeup_eint>; interrupts = <26 0>; diff --git a/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt b/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt index c8f775714887..4ca66c96fe97 100644 --- a/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt +++ b/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt @@ -14,7 +14,7 @@ Required properties: example: -ahb1_rst: reset@01c202c0 { +ahb1_rst: reset@1c202c0 { #reset-cells = <1>; compatible = "allwinner,sun6i-a31-ahb1-reset"; reg = <0x01c202c0 0xc>; diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt index 13301777e11c..6ed79e60248a 100644 --- a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt +++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt @@ -14,7 +14,7 @@ Required properties: example: -src: src@020d8000 { +src: src@20d8000 { compatible = "fsl,imx6q-src"; reg = <0x020d8000 0x4000>; interrupts = <0 91 0x04 0 96 0x04>; @@ -33,10 +33,10 @@ reset.txt example: - ipu1: ipu@02400000 { + ipu1: ipu@2400000 { resets = <&src 2>; }; - ipu2: ipu@02800000 { + ipu2: ipu@2800000 { resets = <&src 4>; }; diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt index c516d24959f2..86945502ccb5 100644 --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt @@ -67,7 +67,7 @@ using the syscon node, and a consumer (a DSP device) on the TI Keystone 2 / { soc { - psc: power-sleep-controller@02350000 { + psc: power-sleep-controller@2350000 { compatible = "syscon", "simple-mfd"; reg = <0x02350000 0x1000>; diff --git a/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt b/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt index d5e26d313f62..12c083c1140a 100644 --- a/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt +++ b/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt @@ -17,7 +17,7 @@ Required properties for new device trees Example: -rtc: rtc@01f00000 { +rtc: rtc@1f00000 { compatible = "allwinner,sun6i-a31-rtc"; reg = <0x01f00000 0x54>; interrupts = <0 40 4>, <0 41 4>; diff --git a/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt index 6983aad376c3..4a8d79c1cf08 100644 --- a/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt +++ b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt @@ -10,7 +10,7 @@ Required properties: Example: -rtc: rtc@01c20d00 { +rtc: rtc@1c20d00 { compatible = "allwinner,sun4i-a10-rtc"; reg = <0x01c20d00 0x20>; interrupts = <24>; diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/par_io.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/par_io.txt index 60984260207b..09b1b05fa677 100644 --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/par_io.txt +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/par_io.txt @@ -18,7 +18,7 @@ par_io@1400 { #size-cells = <0>; device_type = "par_io"; num-ports = <7>; - ucc_pin@01 { + ucc_pin@1 { ...... }; diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/pincfg.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/pincfg.txt index ec6ee2e864a2..5bde8b98a8c9 100644 --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/pincfg.txt +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/pincfg.txt @@ -26,7 +26,7 @@ Required properties: interrupts. Example: - ucc_pin@01 { + ucc_pin@1 { pio-map = < /* port pin dir open_drain assignment has_irq */ 0 3 1 0 1 0 /* TxD0 */ diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt index 66e6265fb0aa..f7b00a7c0f68 100644 --- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt @@ -51,7 +51,7 @@ of valid identifiers for k2g. Example (K2G): -------------------- - uart0: serial@02530c00 { + uart0: serial@2530c00 { compatible = "ns16550a"; ... power-domains = <&k2g_pds 0x002c>; diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt index befd125d18bb..860fc0da39c0 100644 --- a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt +++ b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt @@ -9,7 +9,7 @@ Required properties: Examples: - i2s0: xtfpga-i2s@0d080000 { + i2s0: xtfpga-i2s@d080000 { #sound-dai-cells = <0>; compatible = "cdns,xtfpga-i2s"; reg = <0x0d080000 0x40>; diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt index 65979b205893..f5a14115b459 100644 --- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt +++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt @@ -41,7 +41,7 @@ Required properties: Example: -asrc: asrc@02034000 { +asrc: asrc@2034000 { compatible = "fsl,imx53-asrc"; reg = <0x02034000 0x4000>; interrupts = <0 50 IRQ_TYPE_LEVEL_HIGH>; diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt index 21c401e2ccda..cacd18bb9ba6 100644 --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt +++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt @@ -48,7 +48,7 @@ Required properties: Example: -esai: esai@02024000 { +esai: esai@2024000 { compatible = "fsl,imx35-esai"; reg = <0x02024000 0x4000>; interrupts = <0 51 0x04>; diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt b/Documentation/devicetree/bindings/sound/fsl,spdif.txt index 0f97e54c3d43..38cfa7573441 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.txt +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt @@ -39,7 +39,7 @@ Required properties: Example: -spdif: spdif@02004000 { +spdif: spdif@2004000 { compatible = "fsl,imx35-spdif"; reg = <0x02004000 0x4000>; interrupts = <0 52 0x04>; diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.txt b/Documentation/devicetree/bindings/sound/imx-audmux.txt index b30a737e209e..2db4dcbee1b9 100644 --- a/Documentation/devicetree/bindings/sound/imx-audmux.txt +++ b/Documentation/devicetree/bindings/sound/imx-audmux.txt @@ -22,7 +22,7 @@ Required properties of optional child nodes: Example: -audmux@021d8000 { +audmux@21d8000 { compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; reg = <0x021d8000 0x4000>; }; diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt index 09e0e18591ae..bf100cd0d0f7 100644 --- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt @@ -63,7 +63,7 @@ Optional SoC Specific Properties: Example: -i2s0: i2s@03830000 { +i2s0: i2s@3830000 { compatible = "samsung,s5pv210-i2s"; reg = <0x03830000 0x100>; dmas = <&pdma0 10 diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt index 2d4e10deb6f4..66579bbd3294 100644 --- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt +++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt @@ -62,7 +62,7 @@ Required properties for the following compatibles: block in the PRCM. Example: -codec: codec@01c22c00 { +codec: codec@1c22c00 { #sound-dai-cells = <0>; compatible = "allwinner,sun7i-a20-codec"; reg = <0x01c22c00 0x40>; @@ -73,7 +73,7 @@ codec: codec@01c22c00 { dma-names = "rx", "tx"; }; -codec: codec@01c22c00 { +codec: codec@1c22c00 { #sound-dai-cells = <0>; compatible = "allwinner,sun6i-a31-codec"; reg = <0x01c22c00 0x98>; diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt index fc5da6080759..05d7135a8d2f 100644 --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt @@ -28,7 +28,7 @@ Required properties for the following compatibles: Example: -i2s0: i2s@01c22400 { +i2s0: i2s@1c22400 { #sound-dai-cells = <0>; compatible = "allwinner,sun4i-a10-i2s"; reg = <0x01c22400 0x400>; diff --git a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt index 399b1b4bae22..2ca3d138528e 100644 --- a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt +++ b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt @@ -48,7 +48,7 @@ are similar to A33 using simple-card: sound-dai = <&codec>; }; - soc@01c00000 { + soc@1c00000 { [...] audio-codec@1c22e00 { diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt index 1b6e7c4e50ab..07356758bd91 100644 --- a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt +++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt @@ -10,7 +10,7 @@ Required properties if not a sub-node of the PRCM node: - reg: must contain the registers location and length Example: -prcm: prcm@01f01400 { +prcm: prcm@1f01400 { codec_analog: codec-analog { compatible = "allwinner,sun8i-a23-codec-analog"; }; diff --git a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt index 70ee177901d3..0c64a209c2e9 100644 --- a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt +++ b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt @@ -31,7 +31,7 @@ Required properties: Example: -spdif: spdif@01c21000 { +spdif: spdif@1c21000 { compatible = "allwinner,sun4i-a10-spdif"; reg = <0x01c21000 0x40>; interrupts = <13>; diff --git a/Documentation/devicetree/bindings/sound/zte,zx-spdif.txt b/Documentation/devicetree/bindings/sound/zte,zx-spdif.txt index b5a5ca4502f9..09231d7586b2 100644 --- a/Documentation/devicetree/bindings/sound/zte,zx-spdif.txt +++ b/Documentation/devicetree/bindings/sound/zte,zx-spdif.txt @@ -16,7 +16,7 @@ please check: * dma/dma.txt Example: - spdif0: spdif0@0b004000 { + spdif0: spdif0@b004000 { compatible = "zte,zx296702-spdif"; reg = <0x0b004000 0x1000>; clocks = <&lsp0clk ZX296702_SPDIF0_DIV>; diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt b/Documentation/devicetree/bindings/spi/spi-sun4i.txt index 484bbff5337e..c75d604a8290 100644 --- a/Documentation/devicetree/bindings/spi/spi-sun4i.txt +++ b/Documentation/devicetree/bindings/spi/spi-sun4i.txt @@ -12,7 +12,7 @@ Required properties: Example: -spi1: spi@01c06000 { +spi1: spi@1c06000 { compatible = "allwinner,sun4i-a10-spi"; reg = <0x01c06000 0x1000>; interrupts = <11>; diff --git a/Documentation/devicetree/bindings/spi/spi-sun6i.txt b/Documentation/devicetree/bindings/spi/spi-sun6i.txt index ab1811354cce..435a8e0731ac 100644 --- a/Documentation/devicetree/bindings/spi/spi-sun6i.txt +++ b/Documentation/devicetree/bindings/spi/spi-sun6i.txt @@ -19,7 +19,7 @@ Optional properties: Example: -spi1: spi@01c69000 { +spi1: spi@1c69000 { compatible = "allwinner,sun6i-a31-spi"; reg = <0x01c69000 0x1000>; interrupts = <0 66 4>; @@ -28,7 +28,7 @@ spi1: spi@01c69000 { resets = <&ahb1_rst 21>; }; -spi0: spi@01c68000 { +spi0: spi@1c68000 { compatible = "allwinner,sun8i-h3-spi"; reg = <0x01c68000 0x1000>; interrupts = ; diff --git a/Documentation/devicetree/bindings/sram/samsung-sram.txt b/Documentation/devicetree/bindings/sram/samsung-sram.txt index 6bc474b2b885..61a9bbed303d 100644 --- a/Documentation/devicetree/bindings/sram/samsung-sram.txt +++ b/Documentation/devicetree/bindings/sram/samsung-sram.txt @@ -19,7 +19,7 @@ found in Documentation/devicetree/bindings/sram/sram.txt Example: - sysram@02020000 { + sysram@2020000 { compatible = "mmio-sram"; reg = <0x02020000 0x54000>; #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt index 6bb92a1df753..d087f04a4d7f 100644 --- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt +++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt @@ -47,7 +47,7 @@ This valid values for this argument are: Example ------- -sram-controller@01c00000 { +sram-controller@1c00000 { compatible = "allwinner,sun4i-a10-sram-controller"; reg = <0x01c00000 0x30>; #address-cells = <1>; @@ -68,7 +68,7 @@ sram-controller@01c00000 { }; }; -emac: ethernet@01c0b000 { +emac: ethernet@1c0b000 { compatible = "allwinner,sun4i-a10-emac"; ... diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt index 8d6e4fd2468e..2c5c1be78360 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt @@ -14,7 +14,7 @@ Optional properties: Example: -timer@01c60000 { +timer@1c60000 { compatible = "allwinner,sun7i-a20-hstimer"; reg = <0x01c60000 0x1000>; interrupts = <0 51 1>, diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt index cb2bd83fa89a..50abb20fe319 100644 --- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt +++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt @@ -16,7 +16,7 @@ Required properties: Example: - usb_otg: usb@01c13000 { + usb_otg: usb@1c13000 { compatible = "allwinner,sun4i-a10-musb"; reg = <0x01c13000 0x0400>; clocks = <&ahb_gates 0>; diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index 16920d78e1b8..7a33f22c815a 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -181,7 +181,7 @@ usb: usb@47400000 { "tx14", "tx15"; }; - cppi41dma: dma-controller@07402000 { + cppi41dma: dma-controller@7402000 { compatible = "ti,am3359-cppi41"; reg = <0x47400000 0x1000 0x47402000 0x1000 diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index ad8ea56a9ed3..44e80153b148 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt @@ -18,7 +18,7 @@ Required properties: - atmel,oc-gpio: If present, specifies a gpio that needs to be activated for the overcurrent detection. -usb0: ohci@00500000 { +usb0: ohci@500000 { compatible = "atmel,at91rm9200-ohci", "usb-ohci"; reg = <0x00500000 0x100000>; clocks = <&uhphs_clk>, <&uhphs_clk>, <&uhpck>; @@ -39,7 +39,7 @@ Required properties: "ehci_clk" for the peripheral clock "usb_clk" for the UTMI clock -usb1: ehci@00800000 { +usb1: ehci@800000 { compatible = "atmel,at91sam9g45-ehci", "usb-ehci"; reg = <0x00800000 0x100000>; interrupts = <22 4>; diff --git a/Documentation/devicetree/bindings/usb/ohci-da8xx.txt b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt index 2dc8f67eda39..24a826d5015e 100644 --- a/Documentation/devicetree/bindings/usb/ohci-da8xx.txt +++ b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt @@ -13,7 +13,7 @@ Optional properties: Example: -ohci: usb@0225000 { +ohci: usb@225000 { compatible = "ti,da830-ohci"; reg = <0x225000 0x1000>; interrupts = <59>; diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index a12d6012a40f..3efde12b5d68 100644 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt @@ -30,7 +30,7 @@ Example (Sequoia 440EPx): }; Example (Allwinner sun4i A10 SoC): - ehci0: usb@01c14000 { + ehci0: usb@1c14000 { compatible = "allwinner,sun4i-a10-ehci", "generic-ehci"; reg = <0x01c14000 0x100>; interrupts = <39>; diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt index e8766b08c93b..09e70c875bc6 100644 --- a/Documentation/devicetree/bindings/usb/usb-ohci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt @@ -19,7 +19,7 @@ Optional properties: Example: - ohci0: usb@01c14400 { + ohci0: usb@1c14400 { compatible = "allwinner,sun4i-a10-ohci", "generic-ohci"; reg = <0x01c14400 0x100>; interrupts = <64>; diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt index c1a0a9191d26..057dd384d473 100644 --- a/Documentation/devicetree/bindings/usb/usb3503.txt +++ b/Documentation/devicetree/bindings/usb/usb3503.txt @@ -26,7 +26,7 @@ Optional properties: clock frequencies table is used) Examples: - usb3503@08 { + usb3503@8 { compatible = "smsc,usb3503"; reg = <0x08>; connect-gpios = <&gpx3 0 1>; diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt index f1e27faf528e..a85a631ec434 100644 --- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt +++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt @@ -10,7 +10,7 @@ Required properties: - reg: Should contain registers location and length Examples: -usbmisc@02184800 { +usbmisc@2184800 { #index-cells = <1>; compatible = "fsl,imx6q-usbmisc"; reg = <0x02184800 0x200>; diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 235de0683bb6..5b38a30e608c 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -13,7 +13,7 @@ Required properties: Example: -wdt: watchdog@010000000 { +wdt: watchdog@10000000 { compatible = "mediatek,mt6589-wdt"; reg = <0x10000000 0x18>; }; diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt index b8f75c51453a..62dd5baad70e 100644 --- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt @@ -8,7 +8,7 @@ Required properties: Example: -wdt: watchdog@01c20c90 { +wdt: watchdog@1c20c90 { compatible = "allwinner,sun4i-a10-wdt"; reg = <0x01c20c90 0x10>; }; -- cgit v1.2.3 From bd94e7aea40387524b1d6c76b09785f5c3319116 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Fri, 27 Oct 2017 15:28:52 +0100 Subject: KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved The GICv4 architecture doesn't make it easy for save/restore to work, as it doesn't give any guarantee that the pending state is written into the pending table. So let's not take any chance, and let's return an error if we encounter any LPI that has the HW bit set. In order for userspace to distinguish this error from other failure modes, use -EACCES as an error code. Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall --- Documentation/virtual/kvm/devices/arm-vgic-its.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt index 8d5830eab26a..4f0c9fc40365 100644 --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt @@ -64,6 +64,8 @@ Groups: -EINVAL: Inconsistent restored data -EFAULT: Invalid guest ram access -EBUSY: One or more VCPUS are running + -EACCES: The virtual ITS is backed by a physical GICv4 ITS, and the + state is not available KVM_DEV_ARM_VGIC_GRP_ITS_REGS Attributes: -- cgit v1.2.3 From a75460547e13c99762c2f9dbfcdd13ad416f91c5 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Fri, 27 Oct 2017 15:28:54 +0100 Subject: KVM: arm/arm64: GICv4: Enable VLPI support All it takes is the has_v4 flag to be set in gic_kvm_info as well as "kvm-arm.vgic_v4_enable=1" being passed on the command line for GICv4 to be enabled in KVM. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall --- Documentation/admin-guide/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3daa0a590236..6f897a4c8281 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1881,6 +1881,10 @@ [KVM,ARM] Trap guest accesses to GICv3 common system registers + kvm-arm.vgic_v4_enable= + [KVM,ARM] Allow use of GICv4 for direct injection of + LPIs. + kvm-intel.ept= [KVM,Intel] Disable extended page tables (virtualized MMU) support on capable Intel chips. Default is 1 (enabled) -- cgit v1.2.3 From 8ddef132a36f4081b7cc7a34bce6a666e78083e3 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Wed, 1 Nov 2017 16:20:05 -0700 Subject: dt-bindings: rng: Document BCM7278 RNG200 compatible BCM7278 includes a RGN200 hardware random number generator, document the compatible string for that version of the IP. Signed-off-by: Florian Fainelli Acked-by: Rob Herring Signed-off-by: Herbert Xu --- Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt index e25a456664b9..0014da9145af 100644 --- a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt +++ b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt @@ -1,7 +1,9 @@ HWRNG support for the iproc-rng200 driver Required properties: -- compatible : "brcm,iproc-rng200" +- compatible : Must be one of: + "brcm,bcm7278-rng200" + "brcm,iproc-rng200" - reg : base address and size of control register block Example: -- cgit v1.2.3 From 842ff286166e8512450573f6b6eb5e04e626a07f Mon Sep 17 00:00:00 2001 From: Anthony Kim Date: Wed, 25 Oct 2017 14:57:04 -0700 Subject: Input: add support for HiDeep touchscreen The HiDeep touchscreen device is a capacitive multi-touch controller mainly for multi-touch supported devices use. It use I2C interface for communication to IC and provide axis X, Y, Z locations for ten finger touch through input event interface to userspace. It support the Crimson and the Lime two type IC. They are different the number of channel supported and FW size. But the working protocol is same. Signed-off-by: Anthony Kim Acked-by: Rob Herring Signed-off-by: Dmitry Torokhov --- .../bindings/input/touchscreen/hideep.txt | 42 ++++++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/hideep.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt new file mode 100644 index 000000000000..121d9b7c79a2 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt @@ -0,0 +1,42 @@ +* HiDeep Finger and Stylus touchscreen controller + +Required properties: +- compatible : must be "hideep,hideep-ts" +- reg : I2C slave address, (e.g. 0x6C). +- interrupt-parent : Interrupt controller to which the chip is connected. +- interrupts : Interrupt to which the chip is connected. + +Optional properties: +- vdd-supply : It is the controller supply for controlling + main voltage(3.3V) through the regulator. +- vid-supply : It is the controller supply for controlling + IO voltage(1.8V) through the regulator. +- reset-gpios : Define for reset gpio pin. + It is to use for reset IC. +- touchscreen-size-x : X axis size of touchscreen +- touchscreen-size-y : Y axis size of touchscreen +- linux,keycodes : Specifies an array of numeric keycode values to + be used for reporting button presses. The array can + contain up to 3 entries. + +Example: + +#include "dt-bindings/input/input.h" + +i2c@00000000 { + + /* ... */ + + touchscreen@6c { + compatible = "hideep,hideep-ts"; + reg = <0x6c>; + interrupt-parent = <&gpx1>; + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&ldo15_reg>"; + vid-supply = <&ldo18_reg>; + reset-gpios = <&gpx1 5 0>; + touchscreen-size-x = <1080>; + touchscreen-size-y = <1920>; + linux,keycodes = , , ; + }; +}; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1afd298eddd7..138895e99508 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -137,6 +137,7 @@ 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. -- cgit v1.2.3 From 0145a7141e597e14c60f7561add76bea874768b2 Mon Sep 17 00:00:00 2001 From: Andi Shyti Date: Thu, 9 Nov 2017 23:10:06 -0800 Subject: Input: add support for the Samsung S6SY761 touchscreen The S6SY761 touchscreen is a capicitive multi-touch controller for mobile use. It's connected with i2c at the address 0x48. This commit provides a basic version of the driver which can handle only initialization, touch events and power states. The controller is controlled by a firmware which, in the version I currently have, doesn't provide all the possible functionalities mentioned in the datasheet. Signed-off-by: Andi Shyti Acked-by: Rob Herring Signed-off-by: Dmitry Torokhov --- .../bindings/input/touchscreen/samsung,s6sy761.txt | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt b/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt new file mode 100644 index 000000000000..d9b7c2ff611e --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt @@ -0,0 +1,34 @@ +* Samsung S6SY761 touchscreen controller + +Required properties: +- compatible : must be "samsung,s6sy761" +- reg : I2C slave address, (e.g. 0x48) +- interrupt-parent : the phandle to the interrupt controller which provides + the interrupt +- interrupts : interrupt specification +- avdd-supply : analogic power supply +- vdd-supply : power supply + +Optional properties: +- touchscreen-size-x : see touchscreen.txt. This property is embedded in the + device. If defined it forces a different x resolution. +- touchscreen-size-y : see touchscreen.txt. This property is embedded in the + device. If defined it forces a different y resolution. + +Example: + +i2c@00000000 { + + /* ... */ + + touchscreen@48 { + compatible = "samsung,s6sy761"; + reg = <0x48>; + interrupt-parent = <&gpa1>; + interrupts = <1 IRQ_TYPE_NONE>; + avdd-supply = <&ldo30_reg>; + vdd-supply = <&ldo31_reg>; + touchscreen-size-x = <4096>; + touchscreen-size-y = <4096>; + }; +}; -- cgit v1.2.3 From b8b0d10c3a9b6ee94d56d0c3b162d05c177fb101 Mon Sep 17 00:00:00 2001 From: Olivier Moysan Date: Thu, 9 Nov 2017 15:07:57 +0100 Subject: ASoC: add mclk-fs to audio graph card binding Add mclk-fs support to audio graph card as initially supported in simple card. Signed-off-by: Olivier Moysan Acked-by: Kuninori Morimoto Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/audio-graph-card.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card.txt b/Documentation/devicetree/bindings/sound/audio-graph-card.txt index 6e6720aa33f1..d04ea3b1a1dd 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-card.txt +++ b/Documentation/devicetree/bindings/sound/audio-graph-card.txt @@ -17,6 +17,7 @@ Below are same as Simple-Card. - bitclock-master - bitclock-inversion - frame-inversion +- mclk-fs - dai-tdm-slot-num - dai-tdm-slot-width - clocks / system-clock-frequency -- cgit v1.2.3 From 83f5f7ed72f316eda4c4c3833beebfe6578926f4 Mon Sep 17 00:00:00 2001 From: Jens Axboe Date: Wed, 8 Nov 2017 11:15:37 -0700 Subject: block: kill bio_kmap/kunmap_irq() There are no users of it anymore. Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe --- Documentation/block/biodoc.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 9490f2845f06..01c0a03407cc 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -216,7 +216,7 @@ may need to abort DMA operations and revert to PIO for the transfer, in which case a virtual mapping of the page is required. For SCSI it is also done in some scenarios where the low level driver cannot be trusted to handle a single sg entry correctly. The driver is expected to perform the -kmaps as needed on such occasions using the __bio_kmap_atomic and bio_kmap_irq +kmaps as needed on such occasions using the bio_kmap_irq and friends routines as appropriate. A driver could also use the blk_queue_bounce() routine on its own to bounce highmem i/o to low memory for specific requests if so desired. @@ -1137,7 +1137,7 @@ use dma_map_sg for scatter gather) to be able to ship it to the driver. For PIO drivers (or drivers that need to revert to PIO transfer once in a while (IDE for example)), where the CPU is doing the actual data transfer a virtual mapping is needed. If the driver supports highmem I/O, -(Sec 1.1, (ii) ) it needs to use __bio_kmap_atomic and bio_kmap_irq to +(Sec 1.1, (ii) ) it needs to use __bio_kmap_atomic or similar to temporarily map a bio into the virtual address space. -- cgit v1.2.3 From d004a5e7d4dd6335ce6e2044af42f5e0fbebb51d Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Wed, 8 Nov 2017 19:13:48 +0100 Subject: block: remove __bio_kmap_atomic This helper doesn't buy us much over calling kmap_atomic directly. In fact in the only caller it does a bit of useless work as the caller already has the bvec at hand, and said caller would even buggy for a multi-segment bio due to the use of this helper. So just remove it. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe --- Documentation/block/biodoc.txt | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 01c0a03407cc..86927029a52d 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -216,10 +216,9 @@ may need to abort DMA operations and revert to PIO for the transfer, in which case a virtual mapping of the page is required. For SCSI it is also done in some scenarios where the low level driver cannot be trusted to handle a single sg entry correctly. The driver is expected to perform the -kmaps as needed on such occasions using the bio_kmap_irq and friends -routines as appropriate. A driver could also use the blk_queue_bounce() -routine on its own to bounce highmem i/o to low memory for specific requests -if so desired. +kmaps as needed on such occasions as appropriate. A driver could also use +the blk_queue_bounce() routine on its own to bounce highmem i/o to low +memory for specific requests if so desired. iii. The i/o scheduler algorithm itself can be replaced/set as appropriate @@ -1137,8 +1136,8 @@ use dma_map_sg for scatter gather) to be able to ship it to the driver. For PIO drivers (or drivers that need to revert to PIO transfer once in a while (IDE for example)), where the CPU is doing the actual data transfer a virtual mapping is needed. If the driver supports highmem I/O, -(Sec 1.1, (ii) ) it needs to use __bio_kmap_atomic or similar to -temporarily map a bio into the virtual address space. +(Sec 1.1, (ii) ) it needs to use kmap_atomic or similar to temporarily map +a bio into the virtual address space. 8. Prior/Related/Impacted patches -- cgit v1.2.3 From 2210d6b2f287d738eddf6b75f432126ce05450f8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maciej=20=C5=BBenczykowski?= Date: Tue, 7 Nov 2017 21:52:09 -0800 Subject: net: ipv6: sysctl to specify IPv6 ND traffic class MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a per-device sysctl to specify the default traffic class to use for kernel originated IPv6 Neighbour Discovery packets. Currently this includes: - Router Solicitation (ICMPv6 type 133) ndisc_send_rs() -> ndisc_send_skb() -> ip6_nd_hdr() - Neighbour Solicitation (ICMPv6 type 135) ndisc_send_ns() -> ndisc_send_skb() -> ip6_nd_hdr() - Neighbour Advertisement (ICMPv6 type 136) ndisc_send_na() -> ndisc_send_skb() -> ip6_nd_hdr() - Redirect (ICMPv6 type 137) ndisc_send_redirect() -> ndisc_send_skb() -> ip6_nd_hdr() and if the kernel ever gets around to generating RA's, it would presumably also include: - Router Advertisement (ICMPv6 type 134) (radvd daemon could pick up on the kernel setting and use it) Interface drivers may examine the Traffic Class value and translate the DiffServ Code Point into a link-layer appropriate traffic prioritization scheme. An example of mapping IETF DSCP values to IEEE 802.11 User Priority values can be found here: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11 The expected primary use case is to properly prioritize ND over wifi. Testing: jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass 0 jzem22:~# echo -1 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass -bash: echo: write error: Invalid argument jzem22:~# echo 256 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass -bash: echo: write error: Invalid argument jzem22:~# echo 0 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass jzem22:~# echo 255 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass 255 jzem22:~# echo 34 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass 34 jzem22:~# echo $[0xDC] > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass jzem22:~# tcpdump -v -i eth0 icmp6 and src host jzem22.pgc and dst host fe80::1 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes IP6 (class 0xdc, hlim 255, next-header ICMPv6 (58) payload length: 24) jzem22.pgc > fe80::1: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is jzem22.pgc, Flags [solicited] (based on original change written by Erik Kline, with minor changes) v2: fix 'suspicious rcu_dereference_check() usage' by explicitly grabbing the rcu_read_lock. Cc: Lorenzo Colitti Signed-off-by: Erik Kline Signed-off-by: Maciej Żenczykowski Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 54410a1d4065..d8676dda7fa6 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -1732,6 +1732,15 @@ ndisc_notify - BOOLEAN 1 - Generate unsolicited neighbour advertisements when device is brought up or hardware address changes. +ndisc_tclass - INTEGER + The IPv6 Traffic Class to use by default when sending IPv6 Neighbor + Discovery (Router Solicitation, Router Advertisement, Neighbor + Solicitation, Neighbor Advertisement, Redirect) messages. + These 8 bits can be interpreted as 6 high order bits holding the DSCP + value and 2 low order bits representing ECN (which you probably want + to leave cleared). + 0 - (default) + mldv1_unsolicited_report_interval - INTEGER The interval in milliseconds in which the next unsolicited MLDv1 report retransmit will take place. -- cgit v1.2.3 From 713bafea92920103cd3d361657406cf04d0e22dd Mon Sep 17 00:00:00 2001 From: Yuchung Cheng Date: Wed, 8 Nov 2017 13:01:26 -0800 Subject: tcp: retire FACK loss detection FACK loss detection has been disabled by default and the successor RACK subsumed FACK and can handle reordering better. This patch removes FACK to simplify TCP loss recovery. Signed-off-by: Yuchung Cheng Reviewed-by: Eric Dumazet Reviewed-by: Neal Cardwell Reviewed-by: Soheil Hassas Yeganeh Reviewed-by: Priyaranjan Jha Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index d8676dda7fa6..46c7e1085efc 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -289,8 +289,7 @@ tcp_ecn_fallback - BOOLEAN Default: 1 (fallback enabled) tcp_fack - BOOLEAN - Enable FACK congestion avoidance and fast retransmission. - The value is not used, if tcp_sack is not enabled. + This is a legacy option, it has no effect anymore. tcp_fin_timeout - INTEGER The length of time an orphaned (no longer referenced by any -- cgit v1.2.3 From 3ec26c7944a405e9dbd21b31ff46a3b4e6095adb Mon Sep 17 00:00:00 2001 From: Niklas Cassel Date: Thu, 9 Nov 2017 18:09:26 +0100 Subject: bindings: net: stmmac: correctify note about LPI interrupt There are two different combined signal for various interrupt events: In EQOS-CORE and EQOS-MTL configurations, mci_intr_o is the interrupt signal. In EQOS-DMA, EQOS-AHB and EQOS-AXI configurations, these interrupt events are combined with the events in the DMA on the sbd_intr_o signal. Depending on configuration, the device tree irq "macirq" will refer to either mci_intr_o or sbd_intr_o. The databook states: "The MAC generates the LPI interrupt when the Tx or Rx side enters or exits the LPI state. The interrupt mci_intr_o (sbd_intr_o in certain configurations) is asserted when the LPI interrupt status is set. When the MAC exits the Rx LPI state, then in addition to the mci_intr_o (sbd_intr_o in certain configurations), the sideband signal lpi_intr_o is asserted. If you do not want to gate-off the application clock during the Rx LPI state, you can leave the lpi_intr_o signal unconnected and use the mci_intr_o (sbd_intr_o in certain configurations) signal to detect Rx LPI exit." Since the "macirq" is always raised when Tx or Rx enters/exits the LPI state, "eth_lpi" must therefore refer to lpi_intr_o, which is only raised when Rx exits the LPI state. Update the DT binding description to reflect reality. Signed-off-by: Niklas Cassel Acked-by: Alexandre TORGUE Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/stmmac.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index c3a7be6615c5..3a28a5d8857d 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -12,7 +12,7 @@ Required properties: Valid interrupt names are: - "macirq" (combined signal for various interrupt events) - "eth_wake_irq" (the interrupt to manage the remote wake-up packet detection) - - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI state) + - "eth_lpi" (the interrupt that occurs when Rx exits the LPI state) - phy-mode: See ethernet.txt file in the same directory. - snps,reset-gpio gpio number for phy reset. - snps,reset-active-low boolean flag to indicate if phy reset is active low. -- cgit v1.2.3 From 4b33709d894f2f058566ac06d9769dbc5617268d Mon Sep 17 00:00:00 2001 From: Egil Hjelmeland Date: Wed, 8 Nov 2017 11:55:14 +0100 Subject: net: dsa: lan9303: Documentation: Add missing word "Mbps" Signed-off-by: Egil Hjelmeland Signed-off-by: David S. Miller --- Documentation/networking/dsa/lan9303.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/dsa/lan9303.txt b/Documentation/networking/dsa/lan9303.txt index ec28683d107d..144b02b95207 100644 --- a/Documentation/networking/dsa/lan9303.txt +++ b/Documentation/networking/dsa/lan9303.txt @@ -1,9 +1,9 @@ LAN9303 Ethernet switch driver ============================== -The LAN9303 is a three port 10/100 ethernet switch with integrated phys for the -two external ethernet ports. The third port is an RMII/MII interface to a host -master network interface (e.g. fixed link). +The LAN9303 is a three port 10/100 Mbps ethernet switch with integrated phys for +the two external ethernet ports. The third port is an RMII/MII interface to a +host master network interface (e.g. fixed link). Driver details -- cgit v1.2.3 From f4c09f87adfe31587aa4b2aea2cb2dbde2150f54 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner Date: Mon, 13 Nov 2017 09:39:01 +0100 Subject: cpu/hotplug: Get rid of CPU hotplug notifier leftovers The CPU hotplug notifiers are history. Remove the last reminders. Reported-by: Ingo Molnar Signed-off-by: Thomas Gleixner --- .../fault-injection/notifier-error-inject.txt | 30 ---------------------- Documentation/power/suspend-and-cpuhotplug.txt | 9 +++---- 2 files changed, 4 insertions(+), 35 deletions(-) (limited to 'Documentation') diff --git a/Documentation/fault-injection/notifier-error-inject.txt b/Documentation/fault-injection/notifier-error-inject.txt index 83d3f4e43e91..e861d761de24 100644 --- a/Documentation/fault-injection/notifier-error-inject.txt +++ b/Documentation/fault-injection/notifier-error-inject.txt @@ -6,41 +6,11 @@ specified notifier chain callbacks. It is useful to test the error handling of notifier call chain failures which is rarely executed. There are kernel modules that can be used to test the following notifiers. - * CPU notifier * PM notifier * Memory hotplug notifier * powerpc pSeries reconfig notifier * Netdevice notifier -CPU notifier error injection module ------------------------------------ -This feature can be used to test the error handling of the CPU notifiers by -injecting artificial errors to CPU notifier chain callbacks. - -If the notifier call chain should be failed with some events notified, write -the error code to debugfs interface -/sys/kernel/debug/notifier-error-inject/cpu/actions//error - -Possible CPU notifier events to be failed are: - - * CPU_UP_PREPARE - * CPU_UP_PREPARE_FROZEN - * CPU_DOWN_PREPARE - * CPU_DOWN_PREPARE_FROZEN - -Example1: Inject CPU offline error (-1 == -EPERM) - - # cd /sys/kernel/debug/notifier-error-inject/cpu - # echo -1 > actions/CPU_DOWN_PREPARE/error - # echo 0 > /sys/devices/system/cpu/cpu1/online - bash: echo: write error: Operation not permitted - -Example2: inject CPU online error (-2 == -ENOENT) - - # echo -2 > actions/CPU_UP_PREPARE/error - # echo 1 > /sys/devices/system/cpu/cpu1/online - bash: echo: write error: No such file or directory - PM notifier error injection module ---------------------------------- This feature is controlled through debugfs interface diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.txt index 2fc909502db5..31abd04b9572 100644 --- a/Documentation/power/suspend-and-cpuhotplug.txt +++ b/Documentation/power/suspend-and-cpuhotplug.txt @@ -232,7 +232,7 @@ d. Handling microcode update during suspend/hibernate: hibernate/restore cycle.] In the current design of the kernel however, during a CPU offline operation - as part of the suspend/hibernate cycle (the CPU_DEAD_FROZEN notification), + as part of the suspend/hibernate cycle (cpuhp_tasks_frozen is set), the existing copy of microcode image in the kernel is not freed up. And during the CPU online operations (during resume/restore), since the kernel finds that it already has copies of the microcode images for all the @@ -252,10 +252,9 @@ Yes, they are listed below: the _cpu_down() and _cpu_up() functions is *always* 0. This might not reflect the true current state of the system, since the tasks could have been frozen by an out-of-band event such as a suspend - operation in progress. Hence, it will lead to wrong notifications being - sent during the cpu online/offline events (eg, CPU_ONLINE notification - instead of CPU_ONLINE_FROZEN) which in turn will lead to execution of - inappropriate code by the callbacks registered for such CPU hotplug events. + operation in progress. Hence, the cpuhp_tasks_frozen variable will not + reflect the frozen state and the CPU hotplug callbacks which evaluate + that variable might execute the wrong code path. 2. If a regular CPU hotplug stress test happens to race with the freezer due to a suspend operation in progress at the same time, then we could hit the -- cgit v1.2.3 From becfcc7e576eed03b93f412769573c93de550527 Mon Sep 17 00:00:00 2001 From: David Howells Date: Thu, 2 Nov 2017 15:27:51 +0000 Subject: afs: Fix documentation on # vs % prefix in mount source specification The documentation that describes the #-prefix and the %-prefix used when specifying the source to mount is has the descriptions the wrong way round. Switch them over. Reported-by: Marc Dionne Signed-off-by: David Howells --- Documentation/filesystems/afs.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/afs.txt b/Documentation/filesystems/afs.txt index 060da408923b..ba99b5ac4fd8 100644 --- a/Documentation/filesystems/afs.txt +++ b/Documentation/filesystems/afs.txt @@ -91,8 +91,8 @@ Filesystems can be mounted anywhere by commands similar to the following: mount -t afs "#root.cell." /afs/cambridge Where the initial character is either a hash or a percent symbol depending on -whether you definitely want a R/W volume (hash) or whether you'd prefer a R/O -volume, but are willing to use a R/W volume instead (percent). +whether you definitely want a R/W volume (percent) or whether you'd prefer a +R/O volume, but are willing to use a R/W volume instead (hash). The name of the volume can be suffixes with ".backup" or ".readonly" to specify connection to only volumes of those types. -- cgit v1.2.3 From 7087cb8fad5e19113d82f47f351fc6b338948d5f Mon Sep 17 00:00:00 2001 From: Chris Gorman Date: Mon, 13 Nov 2017 12:41:23 -0500 Subject: Documentation: sound: hd-audio: notes.rst Fixed reference to file HD-Audio-Models.rst which has been moved to hd-audio/models.rst Signed-off-by: Chris Gorman Signed-off-by: Takashi Iwai --- Documentation/sound/hd-audio/notes.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/hd-audio/notes.rst b/Documentation/sound/hd-audio/notes.rst index f59c3cdbfaf4..9f7347830ba4 100644 --- a/Documentation/sound/hd-audio/notes.rst +++ b/Documentation/sound/hd-audio/notes.rst @@ -192,7 +192,7 @@ preset model instead of PCI (and codec-) SSID look-up. What ``model`` option values are available depends on the codec chip. Check your codec chip from the codec proc file (see "Codec Proc-File" section below). It will show the vendor/product name of your codec -chip. Then, see Documentation/sound/HD-Audio-Models.rst file, +chip. Then, see Documentation/sound/hd-audio/models.rst file, the section of HD-audio driver. You can find a list of codecs and ``model`` options belonging to each codec. For example, for Realtek ALC262 codec chip, pass ``model=ultra`` for devices that are compatible -- cgit v1.2.3 From aa25e446ce76c37bfd75ac06598c316af94e9a26 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 9 Nov 2017 16:00:55 -0600 Subject: dt-bindings: usb: add #phy-cells to usb-nop-xceiv Consumers of usb-nop-xceiv use the phy binding, but #phy-cells is missing from the binding. This is probably because this binding predates the common phy binding. So add #phy-cells as a required property. This should not break any users as missing should be treated as 0 cells. Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt index 5be01c859b7a..4dc6a8ee3071 100644 --- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt @@ -2,6 +2,7 @@ USB NOP PHY Required properties: - compatible: should be usb-nop-xceiv +- #phy-cells: Must be 0 Optional properties: - clocks: phandle to the PHY clock. Use as per Documentation/devicetree @@ -33,6 +34,7 @@ Example: reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; vbus-detect-gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>; vbus-regulator = <&vbus_regulator>; + #phy-cells = <0>; }; hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator -- cgit v1.2.3 From 3ba88c477bac891a53ba5a0efb351285297a5e5b Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Mon, 13 Nov 2017 07:18:45 +0900 Subject: net: Extend Kernel GTP-U tunneling documentation * clarify specification references for v0/v1 * add section "APN vs. Network device" * add section "Local GTP-U entity and tunnel identification" Signed-off-by: Andreas Schultz Signed-off-by: Harald Welte Signed-off-by: David S. Miller --- Documentation/networking/gtp.txt | 103 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 99 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/gtp.txt b/Documentation/networking/gtp.txt index 93e96750f103..0d9c18f05ec6 100644 --- a/Documentation/networking/gtp.txt +++ b/Documentation/networking/gtp.txt @@ -1,6 +1,7 @@ The Linux kernel GTP tunneling module ====================================================================== -Documentation by Harald Welte +Documentation by Harald Welte and + Andreas Schultz In 'drivers/net/gtp.c' you are finding a kernel-level implementation of a GTP tunnel endpoint. @@ -91,9 +92,13 @@ http://git.osmocom.org/libgtpnl/ == Protocol Versions == -There are two different versions of GTP-U: v0 and v1. Both are -implemented in the Kernel GTP module. Version 0 is a legacy version, -and deprecated from recent 3GPP specifications. +There are two different versions of GTP-U: v0 [GSM TS 09.60] and v1 +[3GPP TS 29.281]. Both are implemented in the Kernel GTP module. +Version 0 is a legacy version, and deprecated from recent 3GPP +specifications. + +GTP-U uses UDP for transporting PDUs. The receiving UDP port is 2151 +for GTPv1-U and 3386 for GTPv0-U. There are three versions of GTP-C: v0, v1, and v2. As the kernel doesn't implement GTP-C, we don't have to worry about this. It's the @@ -133,3 +138,93 @@ doe to a lack of user interest, it never got merged. In 2015, Andreas Schultz came to the rescue and fixed lots more bugs, extended it with new features and finally pushed all of us to get it mainline, where it was merged in 4.7.0. + +== Architectural Details == + +=== Local GTP-U entity and tunnel identification === + +GTP-U uses UDP for transporting PDU's. The receiving UDP port is 2152 +for GTPv1-U and 3386 for GTPv0-U. + +There is only one GTP-U entity (and therefor SGSN/GGSN/S-GW/PDN-GW +instance) per IP address. Tunnel Endpoint Identifier (TEID) are unique +per GTP-U entity. + +A specific tunnel is only defined by the destination entity. Since the +destination port is constant, only the destination IP and TEID define +a tunnel. The source IP and Port have no meaning for the tunnel. + +Therefore: + + * when sending, the remote entity is defined by the remote IP and + the tunnel endpoint id. The source IP and port have no meaning and + can be changed at any time. + + * when receiving the local entity is defined by the local + destination IP and the tunnel endpoint id. The source IP and port + have no meaning and can change at any time. + +[3GPP TS 29.281] Section 4.3.0 defines this so: + +> The TEID in the GTP-U header is used to de-multiplex traffic +> incoming from remote tunnel endpoints so that it is delivered to the +> User plane entities in a way that allows multiplexing of different +> users, different packet protocols and different QoS levels. +> Therefore no two remote GTP-U endpoints shall send traffic to a +> GTP-U protocol entity using the same TEID value except +> for data forwarding as part of mobility procedures. + +The definition above only defines that two remote GTP-U endpoints +*should not* send to the same TEID, it *does not* forbid or exclude +such a scenario. In fact, the mentioned mobility procedures make it +necessary that the GTP-U entity accepts traffic for TEIDs from +multiple or unknown peers. + +Therefore, the receiving side identifies tunnels exclusively based on +TEIDs, not based on the source IP! + +== APN vs. Network Device == + +The GTP-U driver creates a Linux network device for each Gi/SGi +interface. + +[3GPP TS 29.281] calls the Gi/SGi reference point an interface. This +may lead to the impression that the GGSN/P-GW can have only one such +interface. + +Correct is that the Gi/SGi reference point defines the interworking +between +the 3GPP packet domain (PDN) based on GTP-U tunnel and IP +based networks. + +There is no provision in any of the 3GPP documents that limits the +number of Gi/SGi interfaces implemented by a GGSN/P-GW. + +[3GPP TS 29.061] Section 11.3 makes it clear that the selection of a +specific Gi/SGi interfaces is made through the Access Point Name +(APN): + +> 2. each private network manages its own addressing. In general this +> will result in different private networks having overlapping +> address ranges. A logically separate connection (e.g. an IP in IP +> tunnel or layer 2 virtual circuit) is used between the GGSN/P-GW +> and each private network. +> +> In this case the IP address alone is not necessarily unique. The +> pair of values, Access Point Name (APN) and IPv4 address and/or +> IPv6 prefixes, is unique. + +In order to support the overlapping address range use case, each APN +is mapped to a separate Gi/SGi interface (network device). + +NOTE: The Access Point Name is purely a control plane (GTP-C) concept. +At the GTP-U level, only Tunnel Endpoint Identifiers are present in +GTP-U packets and network devices are known + +Therefore for a given UE the mapping in IP to PDN network is: + * network device + MS IP -> Peer IP + Peer TEID, + +and from PDN to IP network: + * local GTP-U IP + TEID -> network device + +Furthermore, before a received T-PDU is injected into the network +device the MS IP is checked against the IP recorded in PDP context. -- cgit v1.2.3 From 8983487f5e4e377cfc873160f4b557907debd286 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Mon, 13 Nov 2017 07:21:34 +0900 Subject: net: Mention net-next status web page in netdev-FAQ.txt According to https://www.mail-archive.com/netdev@vger.kernel.org/msg177411.html there is a status page available at http://vger.kernel.org/~davem/net-next.html to obtain the current status of the net-next tree. Let's add this information to the netdev FAQ. Signed-off-by: Harald Welte Signed-off-by: David S. Miller --- Documentation/networking/netdev-FAQ.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt index cfc66ea72329..2a3278d5cf35 100644 --- a/Documentation/networking/netdev-FAQ.txt +++ b/Documentation/networking/netdev-FAQ.txt @@ -64,7 +64,10 @@ A: To understand this, you need to know a bit of background information If you aren't subscribed to netdev and/or are simply unsure if net-next has re-opened yet, simply check the net-next git repository link above for - any new networking-related commits. + any new networking-related commits. You may also check the following + website for the current status: + + http://vger.kernel.org/~davem/net-next.html The "net" tree continues to collect fixes for the vX.Y content, and is fed back to Linus at regular (~weekly) intervals. Meaning that the -- cgit v1.2.3 From 68017e5d87a2477d40476f1a0a06f202ee79316b Mon Sep 17 00:00:00 2001 From: Paolo Valente Date: Mon, 13 Nov 2017 07:34:07 +0100 Subject: doc, block, bfq: update max IOPS sustainable with BFQ We have investigated more deeply the performance of BFQ, in terms of number of IOPS that can be processed by the CPU when BFQ is used as I/O scheduler. In more detail, using the script [1], we have measured the number of IOPS reached on top of a null block device configured with zero latency, as a function of the workload (sequential read, sequential write, random read, random write) and of the system (we considered desktops, laptops and embedded systems). Basing on the resulting figures, with this commit we update the current, conservative IOPS range reported in BFQ documentation. In particular, the documentation now reports, for each of three different systems, the lowest number of IOPS obtained for that system with the above test (namely, the value obtained with the workload leading to the lowest IOPS). [1] https://github.com/Algodev-github/IOSpeed Reviewed-by: Lee Tibbert Signed-off-by: Paolo Valente Signed-off-by: Luca Miccio Signed-off-by: Jens Axboe --- Documentation/block/bfq-iosched.txt | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/bfq-iosched.txt b/Documentation/block/bfq-iosched.txt index 3d6951d63489..7a9361508157 100644 --- a/Documentation/block/bfq-iosched.txt +++ b/Documentation/block/bfq-iosched.txt @@ -20,12 +20,17 @@ for that device, by setting low_latency to 0. See Section 3 for details on how to configure BFQ for the desired tradeoff between latency and throughput, or on how to maximize throughput. -On average CPUs, the current version of BFQ can handle devices -performing at most ~30K IOPS; at most ~50 KIOPS on faster CPUs. As a -reference, 30-50 KIOPS correspond to very high bandwidths with -sequential I/O (e.g., 8-12 GB/s if I/O requests are 256 KB large), and -to 120-200 MB/s with 4KB random I/O. BFQ is currently being tested on -multi-queue devices too. +BFQ has a non-null overhead, which limits the maximum IOPS that the +CPU can process for a device scheduled with BFQ. To give an idea of +the limits on slow or average CPUs, here are BFQ limits for three +different CPUs, on, respectively, an average laptop, an old desktop, +and a cheap embedded system, in case full hierarchical support is +enabled (i.e., CONFIG_BFQ_GROUP_IOSCHED is set): +- Intel i7-4850HQ: 250 KIOPS +- AMD A8-3850: 170 KIOPS +- ARM CortexTM-A53 Octa-core: 45 KIOPS + +BFQ works for multi-queue devices too. The table of contents follow. Impatients can just jump to Section 3. -- cgit v1.2.3 From 24bfd19bb7890255693ee5cb6dc100d8d215d00b Mon Sep 17 00:00:00 2001 From: Paolo Valente Date: Mon, 13 Nov 2017 07:34:09 +0100 Subject: block, bfq: update blkio stats outside the scheduler lock bfq invokes various blkg_*stats_* functions to update the statistics contained in the special files blkio.bfq.* in the blkio controller groups, i.e., the I/O accounting related to the proportional-share policy provided by bfq. The execution of these functions takes a considerable percentage, about 40%, of the total per-request execution time of bfq (i.e., of the sum of the execution time of all the bfq functions that have to be executed to process an I/O request from its creation to its destruction). This reduces the request-processing rate sustainable by bfq noticeably, even on a multicore CPU. In fact, the bfq functions that invoke blkg_*stats_* functions cannot be executed in parallel with the rest of the code of bfq, because both are executed under the same same per-device scheduler lock. To reduce this slowdown, this commit moves, wherever possible, the invocation of these functions (more precisely, of the bfq functions that invoke blkg_*stats_* functions) outside the critical sections protected by the scheduler lock. With this change, and with all blkio.bfq.* statistics enabled, the throughput grows, e.g., from 250 to 310 KIOPS (+25%) on an Intel i7-4850HQ, in case of 8 threads doing random I/O in parallel on null_blk, with the latter configured with 0 latency. We obtained the same or higher throughput boosts, up to +30%, with other processors (some figures are reported in the documentation). For our tests, we used the script [1], with which our results can be easily reproduced. NOTE. This commit still protects the invocation of blkg_*stats_* functions with the request_queue lock, because the group these functions are invoked on may otherwise disappear before or while these functions are executed. Fortunately, tests without even this lock show, by difference, that the serialization caused by this lock has a little impact (at most ~5% of throughput reduction). [1] https://github.com/Algodev-github/IOSpeed Tested-by: Lee Tibbert Tested-by: Oleksandr Natalenko Signed-off-by: Paolo Valente Signed-off-by: Luca Miccio Signed-off-by: Jens Axboe --- Documentation/block/bfq-iosched.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/bfq-iosched.txt b/Documentation/block/bfq-iosched.txt index 7a9361508157..7fad6c061470 100644 --- a/Documentation/block/bfq-iosched.txt +++ b/Documentation/block/bfq-iosched.txt @@ -26,9 +26,9 @@ the limits on slow or average CPUs, here are BFQ limits for three different CPUs, on, respectively, an average laptop, an old desktop, and a cheap embedded system, in case full hierarchical support is enabled (i.e., CONFIG_BFQ_GROUP_IOSCHED is set): -- Intel i7-4850HQ: 250 KIOPS -- AMD A8-3850: 170 KIOPS -- ARM CortexTM-A53 Octa-core: 45 KIOPS +- Intel i7-4850HQ: 310 KIOPS +- AMD A8-3850: 200 KIOPS +- ARM CortexTM-A53 Octa-core: 56 KIOPS BFQ works for multi-queue devices too. -- cgit v1.2.3 From a33801e8b4735b8d473f963e5854172f9cde3e8b Mon Sep 17 00:00:00 2001 From: Luca Miccio Date: Mon, 13 Nov 2017 07:34:10 +0100 Subject: block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP BFQ currently creates, and updates, its own instance of the whole set of blkio statistics that cfq creates. Yet, from the comments of Tejun Heo in [1], it turned out that most of these statistics are meant/useful only for debugging. This commit makes BFQ create the latter, debugging statistics only if the option CONFIG_DEBUG_BLK_CGROUP is set. By doing so, this commit also enables BFQ to enjoy a high perfomance boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then BFQ has to update far fewer statistics, and, in particular, not the heaviest to update. To give an idea of the benefits, if CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and with 8 threads doing random I/O in parallel on null_blk (configured with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS (+30%). We have measured similar or even much higher boosts with other CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have been obtained and can be reproduced very easily with the script in [1]. [1] https://www.spinics.net/lists/linux-block/msg18943.html Suggested-by: Tejun Heo Suggested-by: Ulf Hansson Tested-by: Lee Tibbert Tested-by: Oleksandr Natalenko Signed-off-by: Luca Miccio Signed-off-by: Paolo Valente Signed-off-by: Jens Axboe --- Documentation/block/bfq-iosched.txt | 38 +++++++++++++++++++++++++++++++------ 1 file changed, 32 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/bfq-iosched.txt b/Documentation/block/bfq-iosched.txt index 7fad6c061470..8d8d8f06cab2 100644 --- a/Documentation/block/bfq-iosched.txt +++ b/Documentation/block/bfq-iosched.txt @@ -20,12 +20,22 @@ for that device, by setting low_latency to 0. See Section 3 for details on how to configure BFQ for the desired tradeoff between latency and throughput, or on how to maximize throughput. -BFQ has a non-null overhead, which limits the maximum IOPS that the -CPU can process for a device scheduled with BFQ. To give an idea of -the limits on slow or average CPUs, here are BFQ limits for three -different CPUs, on, respectively, an average laptop, an old desktop, -and a cheap embedded system, in case full hierarchical support is -enabled (i.e., CONFIG_BFQ_GROUP_IOSCHED is set): +BFQ has a non-null overhead, which limits the maximum IOPS that a CPU +can process for a device scheduled with BFQ. To give an idea of the +limits on slow or average CPUs, here are, first, the limits of BFQ for +three different CPUs, on, respectively, an average laptop, an old +desktop, and a cheap embedded system, in case full hierarchical +support is enabled (i.e., CONFIG_BFQ_GROUP_IOSCHED is set), but +CONFIG_DEBUG_BLK_CGROUP is not set (Section 4-2): +- Intel i7-4850HQ: 400 KIOPS +- AMD A8-3850: 250 KIOPS +- ARM CortexTM-A53 Octa-core: 80 KIOPS + +If CONFIG_DEBUG_BLK_CGROUP is set (and of course full hierarchical +support is enabled), then the sustainable throughput with BFQ +decreases, because all blkio.bfq* statistics are created and updated +(Section 4-2). For BFQ, this leads to the following maximum +sustainable throughputs, on the same systems as above: - Intel i7-4850HQ: 310 KIOPS - AMD A8-3850: 200 KIOPS - ARM CortexTM-A53 Octa-core: 56 KIOPS @@ -505,6 +515,22 @@ BFQ-specific files is "blkio.bfq." or "io.bfq." For example, the group parameter to set the weight of a group with BFQ is blkio.bfq.weight or io.bfq.weight. +As for cgroups-v1 (blkio controller), the exact set of stat files +created, and kept up-to-date by bfq, depends on whether +CONFIG_DEBUG_BLK_CGROUP is set. If it is set, then bfq creates all +the stat files documented in +Documentation/cgroup-v1/blkio-controller.txt. If, instead, +CONFIG_DEBUG_BLK_CGROUP is not set, then bfq creates only the files +blkio.bfq.io_service_bytes +blkio.bfq.io_service_bytes_recursive +blkio.bfq.io_serviced +blkio.bfq.io_serviced_recursive + +The value of CONFIG_DEBUG_BLK_CGROUP greatly influences the maximum +throughput sustainable with bfq, because updating the blkio.bfq.* +stats is rather costly, especially for some of the stats enabled by +CONFIG_DEBUG_BLK_CGROUP. + Parameters to set ----------------- -- cgit v1.2.3 From ccb4e74aebb6fbd56fc6783f4d5c6ded48bc2f5d Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Wed, 4 Oct 2017 19:10:38 +0900 Subject: dt-bindings: pwm: Add R-Car D3 device tree bindings Add device tree bindings for the PWM controller found on R-Car D3 SoCs. Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt index 7e94b802395d..74c118015980 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt @@ -9,6 +9,7 @@ Required Properties: - "renesas,pwm-r8a7794": for R-Car E2 - "renesas,pwm-r8a7795": for R-Car H3 - "renesas,pwm-r8a7796": for R-Car M3-W + - "renesas,pwm-r8a77995": for R-Car D3 - reg: base address and length of the registers block for the PWM. - #pwm-cells: should be 2. See pwm.txt in this directory for a description of the cells format. -- cgit v1.2.3 From 8f6596f4c94a155b93a809989314e5e8c01d0618 Mon Sep 17 00:00:00 2001 From: Baolin Wang Date: Thu, 9 Nov 2017 11:34:16 +0800 Subject: dt-bindings: rtc: Add Spreadtrum SC27xx RTC documentation This patch adds the binding documentation for Spreadtrum SC27xx series RTC device. Signed-off-by: Baolin Wang Acked-by: Rob Herring Signed-off-by: Alexandre Belloni --- .../devicetree/bindings/rtc/sprd,sc27xx-rtc.txt | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt b/Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt new file mode 100644 index 000000000000..7c170da0d4b7 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt @@ -0,0 +1,27 @@ +Spreadtrum SC27xx Real Time Clock + +Required properties: +- compatible: should be "sprd,sc2731-rtc". +- reg: address offset of rtc register. +- interrupt-parent: phandle for the interrupt controller. +- interrupts: rtc alarm interrupt. + +Example: + + sc2731_pmic: pmic@0 { + compatible = "sprd,sc2731"; + reg = <0>; + spi-max-frequency = <26000000>; + interrupts = ; + interrupt-controller; + #interrupt-cells = <2>; + #address-cells = <1>; + #size-cells = <0>; + + rtc@280 { + compatible = "sprd,sc2731-rtc"; + reg = <0x280>; + interrupt-parent = <&sc2731_pmic>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; + }; + }; -- cgit v1.2.3 From be543dd626c0a23829e9cc1a28e1e3af4cd9ced6 Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Wed, 15 Nov 2017 16:38:44 +0000 Subject: KEYS: fix in-kernel documentation for keyctl_read() When keyctl_read() is passed a buffer that is too small, the behavior is inconsistent. Some key types will fill as much of the buffer as possible, while others won't copy anything. Moreover, the in-kernel documentation contradicted the man page on this point. Update the in-kernel documentation to say that this point is unspecified. Signed-off-by: Eric Biggers Signed-off-by: David Howells --- Documentation/security/keys/core.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst index 1266eeae45f6..9ce7256c6edb 100644 --- a/Documentation/security/keys/core.rst +++ b/Documentation/security/keys/core.rst @@ -628,12 +628,12 @@ The keyctl syscall functions are: defined key type will return its data as is. If a key type does not implement this function, error EOPNOTSUPP will result. - As much of the data as can be fitted into the buffer will be copied to - userspace if the buffer pointer is not NULL. - - On a successful return, the function will always return the amount of data - available rather than the amount copied. + If the specified buffer is too small, then the size of the buffer required + will be returned. Note that in this case, the contents of the buffer may + have been overwritten in some undefined way. + Otherwise, on success, the function will return the amount of data copied + into the buffer. * Instantiate a partially constructed key:: -- cgit v1.2.3 From e9e716ff2d4d8618aefac55691a4c4483abecc37 Mon Sep 17 00:00:00 2001 From: Julia Lawall Date: Mon, 13 Nov 2017 17:50:42 +0100 Subject: docs: dev-tools: coccinelle: delete out of date wiki reference The wiki is no longer available. Signed-off-by: Julia Lawall Signed-off-by: Masahiro Yamada --- Documentation/dev-tools/coccinelle.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index 4a64b4c69d3f..38f3b32203e9 100644 --- a/Documentation/dev-tools/coccinelle.rst +++ b/Documentation/dev-tools/coccinelle.rst @@ -33,9 +33,6 @@ of many distributions, e.g. : You can get the latest version released from the Coccinelle homepage at http://coccinelle.lip6.fr/ -Information and tips about Coccinelle are also provided on the wiki -pages at http://cocci.ekstranet.diku.dk/wiki/doku.php - Once you have it, run the following command:: ./configure -- cgit v1.2.3 From 0f6d24f878568fac579a1962d0bf7cb9f01e0ceb Mon Sep 17 00:00:00 2001 From: Yafang Shao Date: Wed, 15 Nov 2017 17:33:45 -0800 Subject: mm/page-writeback.c: print a warning if the vm dirtiness settings are illogical The vm direct limit setting must be set greater than vm background limit setting. Otherwise print a warning to help the operator to figure out that the vm dirtiness settings is in illogical state. Link: http://lkml.kernel.org/r/1506592464-30962-1-git-send-email-laoar.shao@gmail.com Signed-off-by: Yafang Shao Cc: Jan Kara Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 9baf66a9ef4e..30fd16b14196 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -157,6 +157,10 @@ Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any value lower than this limit will be ignored and the old configuration will be retained. +Note: the value of dirty_bytes also must be set greater than +dirty_background_bytes or the amount of memory corresponding to +dirty_background_ratio. + ============================================================== dirty_expire_centisecs @@ -176,6 +180,9 @@ generating disk writes will itself start writing out dirty data. The total available memory is not equal to total system memory. +Note: dirty_ratio must be set greater than dirty_background_ratio or +ratio corresponding to dirty_background_bytes. + ============================================================== dirty_writeback_centisecs -- cgit v1.2.3 From 0f10851ea475e08896ee5d9a2036d1bb46a8f3a4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= Date: Wed, 15 Nov 2017 17:34:07 -0800 Subject: mm/mmu_notifier: avoid double notification when it is useless MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch only affects users of mmu_notifier->invalidate_range callback which are device drivers related to ATS/PASID, CAPI, IOMMUv2, SVM ... and it is an optimization for those users. Everyone else is unaffected by it. When clearing a pte/pmd we are given a choice to notify the event under the page table lock (notify version of *_clear_flush helpers do call the mmu_notifier_invalidate_range). But that notification is not necessary in all cases. This patch removes almost all cases where it is useless to have a call to mmu_notifier_invalidate_range before mmu_notifier_invalidate_range_end. It also adds documentation in all those cases explaining why. Below is a more in depth analysis of why this is fine to do this: For secondary TLB (non CPU TLB) like IOMMU TLB or device TLB (when device use thing like ATS/PASID to get the IOMMU to walk the CPU page table to access a process virtual address space). There is only 2 cases when you need to notify those secondary TLB while holding page table lock when clearing a pte/pmd: A) page backing address is free before mmu_notifier_invalidate_range_end B) a page table entry is updated to point to a new page (COW, write fault on zero page, __replace_page(), ...) Case A is obvious you do not want to take the risk for the device to write to a page that might now be used by something completely different. Case B is more subtle. For correctness it requires the following sequence to happen: - take page table lock - clear page table entry and notify (pmd/pte_huge_clear_flush_notify()) - set page table entry to point to new page If clearing the page table entry is not followed by a notify before setting the new pte/pmd value then you can break memory model like C11 or C++11 for the device. Consider the following scenario (device use a feature similar to ATS/ PASID): Two address addrA and addrB such that |addrA - addrB| >= PAGE_SIZE we assume they are write protected for COW (other case of B apply too). [Time N] ----------------------------------------------------------------- CPU-thread-0 {try to write to addrA} CPU-thread-1 {try to write to addrB} CPU-thread-2 {} CPU-thread-3 {} DEV-thread-0 {read addrA and populate device TLB} DEV-thread-2 {read addrB and populate device TLB} [Time N+1] --------------------------------------------------------------- CPU-thread-0 {COW_step0: {mmu_notifier_invalidate_range_start(addrA)}} CPU-thread-1 {COW_step0: {mmu_notifier_invalidate_range_start(addrB)}} CPU-thread-2 {} CPU-thread-3 {} DEV-thread-0 {} DEV-thread-2 {} [Time N+2] --------------------------------------------------------------- CPU-thread-0 {COW_step1: {update page table point to new page for addrA}} CPU-thread-1 {COW_step1: {update page table point to new page for addrB}} CPU-thread-2 {} CPU-thread-3 {} DEV-thread-0 {} DEV-thread-2 {} [Time N+3] --------------------------------------------------------------- CPU-thread-0 {preempted} CPU-thread-1 {preempted} CPU-thread-2 {write to addrA which is a write to new page} CPU-thread-3 {} DEV-thread-0 {} DEV-thread-2 {} [Time N+3] --------------------------------------------------------------- CPU-thread-0 {preempted} CPU-thread-1 {preempted} CPU-thread-2 {} CPU-thread-3 {write to addrB which is a write to new page} DEV-thread-0 {} DEV-thread-2 {} [Time N+4] --------------------------------------------------------------- CPU-thread-0 {preempted} CPU-thread-1 {COW_step3: {mmu_notifier_invalidate_range_end(addrB)}} CPU-thread-2 {} CPU-thread-3 {} DEV-thread-0 {} DEV-thread-2 {} [Time N+5] --------------------------------------------------------------- CPU-thread-0 {preempted} CPU-thread-1 {} CPU-thread-2 {} CPU-thread-3 {} DEV-thread-0 {read addrA from old page} DEV-thread-2 {read addrB from new page} So here because at time N+2 the clear page table entry was not pair with a notification to invalidate the secondary TLB, the device see the new value for addrB before seing the new value for addrA. This break total memory ordering for the device. When changing a pte to write protect or to point to a new write protected page with same content (KSM) it is ok to delay invalidate_range callback to mmu_notifier_invalidate_range_end() outside the page table lock. This is true even if the thread doing page table update is preempted right after releasing page table lock before calling mmu_notifier_invalidate_range_end Thanks to Andrea for thinking of a problematic scenario for COW. [jglisse@redhat.com: v2] Link: http://lkml.kernel.org/r/20171017031003.7481-2-jglisse@redhat.com Link: http://lkml.kernel.org/r/20170901173011.10745-1-jglisse@redhat.com Signed-off-by: Jérôme Glisse Cc: Andrea Arcangeli Cc: Nadav Amit Cc: Joerg Roedel Cc: Suravee Suthikulpanit Cc: David Woodhouse Cc: Alistair Popple Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Stephen Rothwell Cc: Andrew Donnellan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/mmu_notifier.txt | 93 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 Documentation/vm/mmu_notifier.txt (limited to 'Documentation') diff --git a/Documentation/vm/mmu_notifier.txt b/Documentation/vm/mmu_notifier.txt new file mode 100644 index 000000000000..23b462566bb7 --- /dev/null +++ b/Documentation/vm/mmu_notifier.txt @@ -0,0 +1,93 @@ +When do you need to notify inside page table lock ? + +When clearing a pte/pmd we are given a choice to notify the event through +(notify version of *_clear_flush call mmu_notifier_invalidate_range) under +the page table lock. But that notification is not necessary in all cases. + +For secondary TLB (non CPU TLB) like IOMMU TLB or device TLB (when device use +thing like ATS/PASID to get the IOMMU to walk the CPU page table to access a +process virtual address space). There is only 2 cases when you need to notify +those secondary TLB while holding page table lock when clearing a pte/pmd: + + A) page backing address is free before mmu_notifier_invalidate_range_end() + B) a page table entry is updated to point to a new page (COW, write fault + on zero page, __replace_page(), ...) + +Case A is obvious you do not want to take the risk for the device to write to +a page that might now be used by some completely different task. + +Case B is more subtle. For correctness it requires the following sequence to +happen: + - take page table lock + - clear page table entry and notify ([pmd/pte]p_huge_clear_flush_notify()) + - set page table entry to point to new page + +If clearing the page table entry is not followed by a notify before setting +the new pte/pmd value then you can break memory model like C11 or C++11 for +the device. + +Consider the following scenario (device use a feature similar to ATS/PASID): + +Two address addrA and addrB such that |addrA - addrB| >= PAGE_SIZE we assume +they are write protected for COW (other case of B apply too). + +[Time N] -------------------------------------------------------------------- +CPU-thread-0 {try to write to addrA} +CPU-thread-1 {try to write to addrB} +CPU-thread-2 {} +CPU-thread-3 {} +DEV-thread-0 {read addrA and populate device TLB} +DEV-thread-2 {read addrB and populate device TLB} +[Time N+1] ------------------------------------------------------------------ +CPU-thread-0 {COW_step0: {mmu_notifier_invalidate_range_start(addrA)}} +CPU-thread-1 {COW_step0: {mmu_notifier_invalidate_range_start(addrB)}} +CPU-thread-2 {} +CPU-thread-3 {} +DEV-thread-0 {} +DEV-thread-2 {} +[Time N+2] ------------------------------------------------------------------ +CPU-thread-0 {COW_step1: {update page table to point to new page for addrA}} +CPU-thread-1 {COW_step1: {update page table to point to new page for addrB}} +CPU-thread-2 {} +CPU-thread-3 {} +DEV-thread-0 {} +DEV-thread-2 {} +[Time N+3] ------------------------------------------------------------------ +CPU-thread-0 {preempted} +CPU-thread-1 {preempted} +CPU-thread-2 {write to addrA which is a write to new page} +CPU-thread-3 {} +DEV-thread-0 {} +DEV-thread-2 {} +[Time N+3] ------------------------------------------------------------------ +CPU-thread-0 {preempted} +CPU-thread-1 {preempted} +CPU-thread-2 {} +CPU-thread-3 {write to addrB which is a write to new page} +DEV-thread-0 {} +DEV-thread-2 {} +[Time N+4] ------------------------------------------------------------------ +CPU-thread-0 {preempted} +CPU-thread-1 {COW_step3: {mmu_notifier_invalidate_range_end(addrB)}} +CPU-thread-2 {} +CPU-thread-3 {} +DEV-thread-0 {} +DEV-thread-2 {} +[Time N+5] ------------------------------------------------------------------ +CPU-thread-0 {preempted} +CPU-thread-1 {} +CPU-thread-2 {} +CPU-thread-3 {} +DEV-thread-0 {read addrA from old page} +DEV-thread-2 {read addrB from new page} + +So here because at time N+2 the clear page table entry was not pair with a +notification to invalidate the secondary TLB, the device see the new value for +addrB before seing the new value for addrA. This break total memory ordering +for the device. + +When changing a pte to write protect or to point to a new write protected page +with same content (KSM) it is fine to delay the mmu_notifier_invalidate_range +call to mmu_notifier_invalidate_range_end() outside the page table lock. This +is true even if the thread doing the page table update is preempted right after +releasing page table lock but before call mmu_notifier_invalidate_range_end(). -- cgit v1.2.3 From b4e98d9ac775907cc53fb08fcb6776deb7694e30 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Wed, 15 Nov 2017 17:35:33 -0800 Subject: mm: account pud page tables On a machine with 5-level paging support a process can allocate significant amount of memory and stay unnoticed by oom-killer and memory cgroup. The trick is to allocate a lot of PUD page tables. We don't account PUD page tables, only PMD and PTE. We already addressed the same issue for PMD page tables, see commit dc6c9a35b66b ("mm: account pmd page tables to the process"). Introduction of 5-level paging brings the same issue for PUD page tables. The patch expands accounting to PUD level. [kirill.shutemov@linux.intel.com: s/pmd_t/pud_t/] Link: http://lkml.kernel.org/r/20171004074305.x35eh5u7ybbt5kar@black.fi.intel.com [heiko.carstens@de.ibm.com: s390/mm: fix pud table accounting] Link: http://lkml.kernel.org/r/20171103090551.18231-1-heiko.carstens@de.ibm.com Link: http://lkml.kernel.org/r/20171002080427.3320-1-kirill.shutemov@linux.intel.com Signed-off-by: Kirill A. Shutemov Signed-off-by: Heiko Carstens Acked-by: Rik van Riel Acked-by: Michal Hocko Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 30fd16b14196..2729e8db9492 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -629,10 +629,10 @@ oom_dump_tasks Enables a system-wide task dump (excluding kernel threads) to be produced when the kernel performs an OOM-killing and includes such information as -pid, uid, tgid, vm size, rss, nr_ptes, nr_pmds, swapents, oom_score_adj -score, and name. This is helpful to determine why the OOM killer was -invoked, to identify the rogue task that caused it, and to determine why -the OOM killer chose the task it did to kill. +pid, uid, tgid, vm size, rss, nr_ptes, nr_pmds, nr_puds, swapents, +oom_score_adj score, and name. This is helpful to determine why the OOM +killer was invoked, to identify the rogue task that caused it, and to +determine why the OOM killer chose the task it did to kill. If this is set to zero, this information is suppressed. On very large systems with thousands of tasks it may not be feasible to dump -- cgit v1.2.3 From af5b0f6a09e42c9f4fa87735f2a366748767b686 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Wed, 15 Nov 2017 17:35:40 -0800 Subject: mm: consolidate page table accounting Currently, we account page tables separately for each page table level, but that's redundant -- we only make use of total memory allocated to page tables for oom_badness calculation. We also provide the information to userspace, but it has dubious value there too. This patch switches page table accounting to single counter. mm->pgtables_bytes is now used to account all page table levels. We use bytes, because page table size for different levels of page table tree may be different. The change has user-visible effect: we don't have VmPMD and VmPUD reported in /proc/[pid]/status. Not sure if anybody uses them. (As alternative, we can always report 0 kB for them.) OOM-killer report is also slightly changed: we now report pgtables_bytes instead of nr_ptes, nr_pmd, nr_puds. Apart from reducing number of counters per-mm, the benefit is that we now calculate oom_badness() more correctly for machines which have different size of page tables depending on level or where page tables are less than a page in size. The only downside can be debuggability because we do not know which page table level could leak. But I do not remember many bugs that would be caught by separate counters so I wouldn't lose sleep over this. [akpm@linux-foundation.org: fix mm/huge_memory.c] Link: http://lkml.kernel.org/r/20171006100651.44742-2-kirill.shutemov@linux.intel.com Signed-off-by: Kirill A. Shutemov Acked-by: Michal Hocko [kirill.shutemov@linux.intel.com: fix build] Link: http://lkml.kernel.org/r/20171016150113.ikfxy3e7zzfvsr4w@black.fi.intel.com Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 1 - Documentation/sysctl/vm.txt | 8 ++++---- 2 files changed, 4 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index adba21b5ada7..ec571b9bb18a 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -250,7 +250,6 @@ Table 1-2: Contents of the status files (as of 4.8) VmExe size of text segment VmLib size of shared library code VmPTE size of page table entries - VmPMD size of second level page tables VmSwap amount of swap used by anonymous private data (shmem swap usage is not included) HugetlbPages size of hugetlb memory portions diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 2729e8db9492..3e579740b49f 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -629,10 +629,10 @@ oom_dump_tasks Enables a system-wide task dump (excluding kernel threads) to be produced when the kernel performs an OOM-killing and includes such information as -pid, uid, tgid, vm size, rss, nr_ptes, nr_pmds, nr_puds, swapents, -oom_score_adj score, and name. This is helpful to determine why the OOM -killer was invoked, to identify the rogue task that caused it, and to -determine why the OOM killer chose the task it did to kill. +pid, uid, tgid, vm size, rss, pgtables_bytes, swapents, oom_score_adj +score, and name. This is helpful to determine why the OOM killer was +invoked, to identify the rogue task that caused it, and to determine why +the OOM killer chose the task it did to kill. If this is set to zero, this information is suppressed. On very large systems with thousands of tasks it may not be feasible to dump -- cgit v1.2.3 From 4675ff05de2d76d167336b368bd07f3fef6ed5a6 Mon Sep 17 00:00:00 2001 From: "Levin, Alexander (Sasha Levin)" Date: Wed, 15 Nov 2017 17:36:02 -0800 Subject: kmemcheck: rip it out Fix up makefiles, remove references, and git rm kmemcheck. Link: http://lkml.kernel.org/r/20171007030159.22241-4-alexander.levin@verizon.com Signed-off-by: Sasha Levin Cc: Steven Rostedt Cc: Vegard Nossum Cc: Pekka Enberg Cc: Michal Hocko Cc: Eric W. Biederman Cc: Alexander Potapenko Cc: Tim Hansen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/kernel-parameters.txt | 7 - Documentation/dev-tools/index.rst | 1 - Documentation/dev-tools/kmemcheck.rst | 733 ------------------------ 3 files changed, 741 deletions(-) delete mode 100644 Documentation/dev-tools/kmemcheck.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index b74e13312fdc..00bb04972612 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1864,13 +1864,6 @@ Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y, the default is off. - kmemcheck= [X86] Boot-time kmemcheck enable/disable/one-shot mode - Valid arguments: 0, 1, 2 - kmemcheck=0 (disabled) - kmemcheck=1 (enabled) - kmemcheck=2 (one-shot mode) - Default: 2 (one-shot mode) - kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs. Default is 0 (don't ignore, but inject #GP) diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst index a81787cd47d7..e313925fb0fa 100644 --- a/Documentation/dev-tools/index.rst +++ b/Documentation/dev-tools/index.rst @@ -21,7 +21,6 @@ whole; patches welcome! kasan ubsan kmemleak - kmemcheck gdb-kernel-debugging kgdb kselftest diff --git a/Documentation/dev-tools/kmemcheck.rst b/Documentation/dev-tools/kmemcheck.rst deleted file mode 100644 index 7f3d1985de74..000000000000 --- a/Documentation/dev-tools/kmemcheck.rst +++ /dev/null @@ -1,733 +0,0 @@ -Getting started with kmemcheck -============================== - -Vegard Nossum - - -Introduction ------------- - -kmemcheck is a debugging feature for the Linux Kernel. More specifically, it -is a dynamic checker that detects and warns about some uses of uninitialized -memory. - -Userspace programmers might be familiar with Valgrind's memcheck. The main -difference between memcheck and kmemcheck is that memcheck works for userspace -programs only, and kmemcheck works for the kernel only. The implementations -are of course vastly different. Because of this, kmemcheck is not as accurate -as memcheck, but it turns out to be good enough in practice to discover real -programmer errors that the compiler is not able to find through static -analysis. - -Enabling kmemcheck on a kernel will probably slow it down to the extent that -the machine will not be usable for normal workloads such as e.g. an -interactive desktop. kmemcheck will also cause the kernel to use about twice -as much memory as normal. For this reason, kmemcheck is strictly a debugging -feature. - - -Downloading ------------ - -As of version 2.6.31-rc1, kmemcheck is included in the mainline kernel. - - -Configuring and compiling -------------------------- - -kmemcheck only works for the x86 (both 32- and 64-bit) platform. A number of -configuration variables must have specific settings in order for the kmemcheck -menu to even appear in "menuconfig". These are: - -- ``CONFIG_CC_OPTIMIZE_FOR_SIZE=n`` - This option is located under "General setup" / "Optimize for size". - - Without this, gcc will use certain optimizations that usually lead to - false positive warnings from kmemcheck. An example of this is a 16-bit - field in a struct, where gcc may load 32 bits, then discard the upper - 16 bits. kmemcheck sees only the 32-bit load, and may trigger a - warning for the upper 16 bits (if they're uninitialized). - -- ``CONFIG_SLAB=y`` or ``CONFIG_SLUB=y`` - This option is located under "General setup" / "Choose SLAB - allocator". - -- ``CONFIG_FUNCTION_TRACER=n`` - This option is located under "Kernel hacking" / "Tracers" / "Kernel - Function Tracer" - - When function tracing is compiled in, gcc emits a call to another - function at the beginning of every function. This means that when the - page fault handler is called, the ftrace framework will be called - before kmemcheck has had a chance to handle the fault. If ftrace then - modifies memory that was tracked by kmemcheck, the result is an - endless recursive page fault. - -- ``CONFIG_DEBUG_PAGEALLOC=n`` - This option is located under "Kernel hacking" / "Memory Debugging" - / "Debug page memory allocations". - -In addition, I highly recommend turning on ``CONFIG_DEBUG_INFO=y``. This is also -located under "Kernel hacking". With this, you will be able to get line number -information from the kmemcheck warnings, which is extremely valuable in -debugging a problem. This option is not mandatory, however, because it slows -down the compilation process and produces a much bigger kernel image. - -Now the kmemcheck menu should be visible (under "Kernel hacking" / "Memory -Debugging" / "kmemcheck: trap use of uninitialized memory"). Here follows -a description of the kmemcheck configuration variables: - -- ``CONFIG_KMEMCHECK`` - This must be enabled in order to use kmemcheck at all... - -- ``CONFIG_KMEMCHECK_``[``DISABLED`` | ``ENABLED`` | ``ONESHOT``]``_BY_DEFAULT`` - This option controls the status of kmemcheck at boot-time. "Enabled" - will enable kmemcheck right from the start, "disabled" will boot the - kernel as normal (but with the kmemcheck code compiled in, so it can - be enabled at run-time after the kernel has booted), and "one-shot" is - a special mode which will turn kmemcheck off automatically after - detecting the first use of uninitialized memory. - - If you are using kmemcheck to actively debug a problem, then you - probably want to choose "enabled" here. - - The one-shot mode is mostly useful in automated test setups because it - can prevent floods of warnings and increase the chances of the machine - surviving in case something is really wrong. In other cases, the one- - shot mode could actually be counter-productive because it would turn - itself off at the very first error -- in the case of a false positive - too -- and this would come in the way of debugging the specific - problem you were interested in. - - If you would like to use your kernel as normal, but with a chance to - enable kmemcheck in case of some problem, it might be a good idea to - choose "disabled" here. When kmemcheck is disabled, most of the run- - time overhead is not incurred, and the kernel will be almost as fast - as normal. - -- ``CONFIG_KMEMCHECK_QUEUE_SIZE`` - Select the maximum number of error reports to store in an internal - (fixed-size) buffer. Since errors can occur virtually anywhere and in - any context, we need a temporary storage area which is guaranteed not - to generate any other page faults when accessed. The queue will be - emptied as soon as a tasklet may be scheduled. If the queue is full, - new error reports will be lost. - - The default value of 64 is probably fine. If some code produces more - than 64 errors within an irqs-off section, then the code is likely to - produce many, many more, too, and these additional reports seldom give - any more information (the first report is usually the most valuable - anyway). - - This number might have to be adjusted if you are not using serial - console or similar to capture the kernel log. If you are using the - "dmesg" command to save the log, then getting a lot of kmemcheck - warnings might overflow the kernel log itself, and the earlier reports - will get lost in that way instead. Try setting this to 10 or so on - such a setup. - -- ``CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT`` - Select the number of shadow bytes to save along with each entry of the - error-report queue. These bytes indicate what parts of an allocation - are initialized, uninitialized, etc. and will be displayed when an - error is detected to help the debugging of a particular problem. - - The number entered here is actually the logarithm of the number of - bytes that will be saved. So if you pick for example 5 here, kmemcheck - will save 2^5 = 32 bytes. - - The default value should be fine for debugging most problems. It also - fits nicely within 80 columns. - -- ``CONFIG_KMEMCHECK_PARTIAL_OK`` - This option (when enabled) works around certain GCC optimizations that - produce 32-bit reads from 16-bit variables where the upper 16 bits are - thrown away afterwards. - - The default value (enabled) is recommended. This may of course hide - some real errors, but disabling it would probably produce a lot of - false positives. - -- ``CONFIG_KMEMCHECK_BITOPS_OK`` - This option silences warnings that would be generated for bit-field - accesses where not all the bits are initialized at the same time. This - may also hide some real bugs. - - This option is probably obsolete, or it should be replaced with - the kmemcheck-/bitfield-annotations for the code in question. The - default value is therefore fine. - -Now compile the kernel as usual. - - -How to use ----------- - -Booting -~~~~~~~ - -First some information about the command-line options. There is only one -option specific to kmemcheck, and this is called "kmemcheck". It can be used -to override the default mode as chosen by the ``CONFIG_KMEMCHECK_*_BY_DEFAULT`` -option. Its possible settings are: - -- ``kmemcheck=0`` (disabled) -- ``kmemcheck=1`` (enabled) -- ``kmemcheck=2`` (one-shot mode) - -If SLUB debugging has been enabled in the kernel, it may take precedence over -kmemcheck in such a way that the slab caches which are under SLUB debugging -will not be tracked by kmemcheck. In order to ensure that this doesn't happen -(even though it shouldn't by default), use SLUB's boot option ``slub_debug``, -like this: ``slub_debug=-`` - -In fact, this option may also be used for fine-grained control over SLUB vs. -kmemcheck. For example, if the command line includes -``kmemcheck=1 slub_debug=,dentry``, then SLUB debugging will be used only -for the "dentry" slab cache, and with kmemcheck tracking all the other -caches. This is advanced usage, however, and is not generally recommended. - - -Run-time enable/disable -~~~~~~~~~~~~~~~~~~~~~~~ - -When the kernel has booted, it is possible to enable or disable kmemcheck at -run-time. WARNING: This feature is still experimental and may cause false -positive warnings to appear. Therefore, try not to use this. If you find that -it doesn't work properly (e.g. you see an unreasonable amount of warnings), I -will be happy to take bug reports. - -Use the file ``/proc/sys/kernel/kmemcheck`` for this purpose, e.g.:: - - $ echo 0 > /proc/sys/kernel/kmemcheck # disables kmemcheck - -The numbers are the same as for the ``kmemcheck=`` command-line option. - - -Debugging -~~~~~~~~~ - -A typical report will look something like this:: - - WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88003e4a2024) - 80000000000000000000000000000000000000000088ffff0000000000000000 - i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u - ^ - - Pid: 1856, comm: ntpdate Not tainted 2.6.29-rc5 #264 945P-A - RIP: 0010:[] [] __dequeue_signal+0xc8/0x190 - RSP: 0018:ffff88003cdf7d98 EFLAGS: 00210002 - RAX: 0000000000000030 RBX: ffff88003d4ea968 RCX: 0000000000000009 - RDX: ffff88003e5d6018 RSI: ffff88003e5d6024 RDI: ffff88003cdf7e84 - RBP: ffff88003cdf7db8 R08: ffff88003e5d6000 R09: 0000000000000000 - R10: 0000000000000080 R11: 0000000000000000 R12: 000000000000000e - R13: ffff88003cdf7e78 R14: ffff88003d530710 R15: ffff88003d5a98c8 - FS: 0000000000000000(0000) GS:ffff880001982000(0063) knlGS:00000 - CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 - CR2: ffff88003f806ea0 CR3: 000000003c036000 CR4: 00000000000006a0 - DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 - DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 - [] dequeue_signal+0x8e/0x170 - [] get_signal_to_deliver+0x98/0x390 - [] do_notify_resume+0xad/0x7d0 - [] int_signal+0x12/0x17 - [] 0xffffffffffffffff - -The single most valuable information in this report is the RIP (or EIP on 32- -bit) value. This will help us pinpoint exactly which instruction that caused -the warning. - -If your kernel was compiled with ``CONFIG_DEBUG_INFO=y``, then all we have to do -is give this address to the addr2line program, like this:: - - $ addr2line -e vmlinux -i ffffffff8104ede8 - arch/x86/include/asm/string_64.h:12 - include/asm-generic/siginfo.h:287 - kernel/signal.c:380 - kernel/signal.c:410 - -The "``-e vmlinux``" tells addr2line which file to look in. **IMPORTANT:** -This must be the vmlinux of the kernel that produced the warning in the -first place! If not, the line number information will almost certainly be -wrong. - -The "``-i``" tells addr2line to also print the line numbers of inlined -functions. In this case, the flag was very important, because otherwise, -it would only have printed the first line, which is just a call to -``memcpy()``, which could be called from a thousand places in the kernel, and -is therefore not very useful. These inlined functions would not show up in -the stack trace above, simply because the kernel doesn't load the extra -debugging information. This technique can of course be used with ordinary -kernel oopses as well. - -In this case, it's the caller of ``memcpy()`` that is interesting, and it can be -found in ``include/asm-generic/siginfo.h``, line 287:: - - 281 static inline void copy_siginfo(struct siginfo *to, struct siginfo *from) - 282 { - 283 if (from->si_code < 0) - 284 memcpy(to, from, sizeof(*to)); - 285 else - 286 /* _sigchld is currently the largest know union member */ - 287 memcpy(to, from, __ARCH_SI_PREAMBLE_SIZE + sizeof(from->_sifields._sigchld)); - 288 } - -Since this was a read (kmemcheck usually warns about reads only, though it can -warn about writes to unallocated or freed memory as well), it was probably the -"from" argument which contained some uninitialized bytes. Following the chain -of calls, we move upwards to see where "from" was allocated or initialized, -``kernel/signal.c``, line 380:: - - 359 static void collect_signal(int sig, struct sigpending *list, siginfo_t *info) - 360 { - ... - 367 list_for_each_entry(q, &list->list, list) { - 368 if (q->info.si_signo == sig) { - 369 if (first) - 370 goto still_pending; - 371 first = q; - ... - 377 if (first) { - 378 still_pending: - 379 list_del_init(&first->list); - 380 copy_siginfo(info, &first->info); - 381 __sigqueue_free(first); - ... - 392 } - 393 } - -Here, it is ``&first->info`` that is being passed on to ``copy_siginfo()``. The -variable ``first`` was found on a list -- passed in as the second argument to -``collect_signal()``. We continue our journey through the stack, to figure out -where the item on "list" was allocated or initialized. We move to line 410:: - - 395 static int __dequeue_signal(struct sigpending *pending, sigset_t *mask, - 396 siginfo_t *info) - 397 { - ... - 410 collect_signal(sig, pending, info); - ... - 414 } - -Now we need to follow the ``pending`` pointer, since that is being passed on to -``collect_signal()`` as ``list``. At this point, we've run out of lines from the -"addr2line" output. Not to worry, we just paste the next addresses from the -kmemcheck stack dump, i.e.:: - - [] dequeue_signal+0x8e/0x170 - [] get_signal_to_deliver+0x98/0x390 - [] do_notify_resume+0xad/0x7d0 - [] int_signal+0x12/0x17 - - $ addr2line -e vmlinux -i ffffffff8104f04e ffffffff81050bd8 \ - ffffffff8100b87d ffffffff8100c7b5 - kernel/signal.c:446 - kernel/signal.c:1806 - arch/x86/kernel/signal.c:805 - arch/x86/kernel/signal.c:871 - arch/x86/kernel/entry_64.S:694 - -Remember that since these addresses were found on the stack and not as the -RIP value, they actually point to the _next_ instruction (they are return -addresses). This becomes obvious when we look at the code for line 446:: - - 422 int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info) - 423 { - ... - 431 signr = __dequeue_signal(&tsk->signal->shared_pending, - 432 mask, info); - 433 /* - 434 * itimer signal ? - 435 * - 436 * itimers are process shared and we restart periodic - 437 * itimers in the signal delivery path to prevent DoS - 438 * attacks in the high resolution timer case. This is - 439 * compliant with the old way of self restarting - 440 * itimers, as the SIGALRM is a legacy signal and only - 441 * queued once. Changing the restart behaviour to - 442 * restart the timer in the signal dequeue path is - 443 * reducing the timer noise on heavy loaded !highres - 444 * systems too. - 445 */ - 446 if (unlikely(signr == SIGALRM)) { - ... - 489 } - -So instead of looking at 446, we should be looking at 431, which is the line -that executes just before 446. Here we see that what we are looking for is -``&tsk->signal->shared_pending``. - -Our next task is now to figure out which function that puts items on this -``shared_pending`` list. A crude, but efficient tool, is ``git grep``:: - - $ git grep -n 'shared_pending' kernel/ - ... - kernel/signal.c:828: pending = group ? &t->signal->shared_pending : &t->pending; - kernel/signal.c:1339: pending = group ? &t->signal->shared_pending : &t->pending; - ... - -There were more results, but none of them were related to list operations, -and these were the only assignments. We inspect the line numbers more closely -and find that this is indeed where items are being added to the list:: - - 816 static int send_signal(int sig, struct siginfo *info, struct task_struct *t, - 817 int group) - 818 { - ... - 828 pending = group ? &t->signal->shared_pending : &t->pending; - ... - 851 q = __sigqueue_alloc(t, GFP_ATOMIC, (sig < SIGRTMIN && - 852 (is_si_special(info) || - 853 info->si_code >= 0))); - 854 if (q) { - 855 list_add_tail(&q->list, &pending->list); - ... - 890 } - -and:: - - 1309 int send_sigqueue(struct sigqueue *q, struct task_struct *t, int group) - 1310 { - .... - 1339 pending = group ? &t->signal->shared_pending : &t->pending; - 1340 list_add_tail(&q->list, &pending->list); - .... - 1347 } - -In the first case, the list element we are looking for, ``q``, is being -returned from the function ``__sigqueue_alloc()``, which looks like an -allocation function. Let's take a look at it:: - - 187 static struct sigqueue *__sigqueue_alloc(struct task_struct *t, gfp_t flags, - 188 int override_rlimit) - 189 { - 190 struct sigqueue *q = NULL; - 191 struct user_struct *user; - 192 - 193 /* - 194 * We won't get problems with the target's UID changing under us - 195 * because changing it requires RCU be used, and if t != current, the - 196 * caller must be holding the RCU readlock (by way of a spinlock) and - 197 * we use RCU protection here - 198 */ - 199 user = get_uid(__task_cred(t)->user); - 200 atomic_inc(&user->sigpending); - 201 if (override_rlimit || - 202 atomic_read(&user->sigpending) <= - 203 t->signal->rlim[RLIMIT_SIGPENDING].rlim_cur) - 204 q = kmem_cache_alloc(sigqueue_cachep, flags); - 205 if (unlikely(q == NULL)) { - 206 atomic_dec(&user->sigpending); - 207 free_uid(user); - 208 } else { - 209 INIT_LIST_HEAD(&q->list); - 210 q->flags = 0; - 211 q->user = user; - 212 } - 213 - 214 return q; - 215 } - -We see that this function initializes ``q->list``, ``q->flags``, and -``q->user``. It seems that now is the time to look at the definition of -``struct sigqueue``, e.g.:: - - 14 struct sigqueue { - 15 struct list_head list; - 16 int flags; - 17 siginfo_t info; - 18 struct user_struct *user; - 19 }; - -And, you might remember, it was a ``memcpy()`` on ``&first->info`` that -caused the warning, so this makes perfect sense. It also seems reasonable -to assume that it is the caller of ``__sigqueue_alloc()`` that has the -responsibility of filling out (initializing) this member. - -But just which fields of the struct were uninitialized? Let's look at -kmemcheck's report again:: - - WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88003e4a2024) - 80000000000000000000000000000000000000000088ffff0000000000000000 - i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u - ^ - -These first two lines are the memory dump of the memory object itself, and -the shadow bytemap, respectively. The memory object itself is in this case -``&first->info``. Just beware that the start of this dump is NOT the start -of the object itself! The position of the caret (^) corresponds with the -address of the read (ffff88003e4a2024). - -The shadow bytemap dump legend is as follows: - -- i: initialized -- u: uninitialized -- a: unallocated (memory has been allocated by the slab layer, but has not - yet been handed off to anybody) -- f: freed (memory has been allocated by the slab layer, but has been freed - by the previous owner) - -In order to figure out where (relative to the start of the object) the -uninitialized memory was located, we have to look at the disassembly. For -that, we'll need the RIP address again:: - - RIP: 0010:[] [] __dequeue_signal+0xc8/0x190 - - $ objdump -d --no-show-raw-insn vmlinux | grep -C 8 ffffffff8104ede8: - ffffffff8104edc8: mov %r8,0x8(%r8) - ffffffff8104edcc: test %r10d,%r10d - ffffffff8104edcf: js ffffffff8104ee88 <__dequeue_signal+0x168> - ffffffff8104edd5: mov %rax,%rdx - ffffffff8104edd8: mov $0xc,%ecx - ffffffff8104eddd: mov %r13,%rdi - ffffffff8104ede0: mov $0x30,%eax - ffffffff8104ede5: mov %rdx,%rsi - ffffffff8104ede8: rep movsl %ds:(%rsi),%es:(%rdi) - ffffffff8104edea: test $0x2,%al - ffffffff8104edec: je ffffffff8104edf0 <__dequeue_signal+0xd0> - ffffffff8104edee: movsw %ds:(%rsi),%es:(%rdi) - ffffffff8104edf0: test $0x1,%al - ffffffff8104edf2: je ffffffff8104edf5 <__dequeue_signal+0xd5> - ffffffff8104edf4: movsb %ds:(%rsi),%es:(%rdi) - ffffffff8104edf5: mov %r8,%rdi - ffffffff8104edf8: callq ffffffff8104de60 <__sigqueue_free> - -As expected, it's the "``rep movsl``" instruction from the ``memcpy()`` -that causes the warning. We know about ``REP MOVSL`` that it uses the register -``RCX`` to count the number of remaining iterations. By taking a look at the -register dump again (from the kmemcheck report), we can figure out how many -bytes were left to copy:: - - RAX: 0000000000000030 RBX: ffff88003d4ea968 RCX: 0000000000000009 - -By looking at the disassembly, we also see that ``%ecx`` is being loaded -with the value ``$0xc`` just before (ffffffff8104edd8), so we are very -lucky. Keep in mind that this is the number of iterations, not bytes. And -since this is a "long" operation, we need to multiply by 4 to get the -number of bytes. So this means that the uninitialized value was encountered -at 4 * (0xc - 0x9) = 12 bytes from the start of the object. - -We can now try to figure out which field of the "``struct siginfo``" that -was not initialized. This is the beginning of the struct:: - - 40 typedef struct siginfo { - 41 int si_signo; - 42 int si_errno; - 43 int si_code; - 44 - 45 union { - .. - 92 } _sifields; - 93 } siginfo_t; - -On 64-bit, the int is 4 bytes long, so it must the union member that has -not been initialized. We can verify this using gdb:: - - $ gdb vmlinux - ... - (gdb) p &((struct siginfo *) 0)->_sifields - $1 = (union {...} *) 0x10 - -Actually, it seems that the union member is located at offset 0x10 -- which -means that gcc has inserted 4 bytes of padding between the members ``si_code`` -and ``_sifields``. We can now get a fuller picture of the memory dump:: - - _----------------------------=> si_code - / _--------------------=> (padding) - | / _------------=> _sifields(._kill._pid) - | | / _----=> _sifields(._kill._uid) - | | | / - -------|-------|-------|-------| - 80000000000000000000000000000000000000000088ffff0000000000000000 - i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u - -This allows us to realize another important fact: ``si_code`` contains the -value 0x80. Remember that x86 is little endian, so the first 4 bytes -"80000000" are really the number 0x00000080. With a bit of research, we -find that this is actually the constant ``SI_KERNEL`` defined in -``include/asm-generic/siginfo.h``:: - - 144 #define SI_KERNEL 0x80 /* sent by the kernel from somewhere */ - -This macro is used in exactly one place in the x86 kernel: In ``send_signal()`` -in ``kernel/signal.c``:: - - 816 static int send_signal(int sig, struct siginfo *info, struct task_struct *t, - 817 int group) - 818 { - ... - 828 pending = group ? &t->signal->shared_pending : &t->pending; - ... - 851 q = __sigqueue_alloc(t, GFP_ATOMIC, (sig < SIGRTMIN && - 852 (is_si_special(info) || - 853 info->si_code >= 0))); - 854 if (q) { - 855 list_add_tail(&q->list, &pending->list); - 856 switch ((unsigned long) info) { - ... - 865 case (unsigned long) SEND_SIG_PRIV: - 866 q->info.si_signo = sig; - 867 q->info.si_errno = 0; - 868 q->info.si_code = SI_KERNEL; - 869 q->info.si_pid = 0; - 870 q->info.si_uid = 0; - 871 break; - ... - 890 } - -Not only does this match with the ``.si_code`` member, it also matches the place -we found earlier when looking for where siginfo_t objects are enqueued on the -``shared_pending`` list. - -So to sum up: It seems that it is the padding introduced by the compiler -between two struct fields that is uninitialized, and this gets reported when -we do a ``memcpy()`` on the struct. This means that we have identified a false -positive warning. - -Normally, kmemcheck will not report uninitialized accesses in ``memcpy()`` calls -when both the source and destination addresses are tracked. (Instead, we copy -the shadow bytemap as well). In this case, the destination address clearly -was not tracked. We can dig a little deeper into the stack trace from above:: - - arch/x86/kernel/signal.c:805 - arch/x86/kernel/signal.c:871 - arch/x86/kernel/entry_64.S:694 - -And we clearly see that the destination siginfo object is located on the -stack:: - - 782 static void do_signal(struct pt_regs *regs) - 783 { - 784 struct k_sigaction ka; - 785 siginfo_t info; - ... - 804 signr = get_signal_to_deliver(&info, &ka, regs, NULL); - ... - 854 } - -And this ``&info`` is what eventually gets passed to ``copy_siginfo()`` as the -destination argument. - -Now, even though we didn't find an actual error here, the example is still a -good one, because it shows how one would go about to find out what the report -was all about. - - -Annotating false positives -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are a few different ways to make annotations in the source code that -will keep kmemcheck from checking and reporting certain allocations. Here -they are: - -- ``__GFP_NOTRACK_FALSE_POSITIVE`` - This flag can be passed to ``kmalloc()`` or ``kmem_cache_alloc()`` - (therefore also to other functions that end up calling one of - these) to indicate that the allocation should not be tracked - because it would lead to a false positive report. This is a "big - hammer" way of silencing kmemcheck; after all, even if the false - positive pertains to particular field in a struct, for example, we - will now lose the ability to find (real) errors in other parts of - the same struct. - - Example:: - - /* No warnings will ever trigger on accessing any part of x */ - x = kmalloc(sizeof *x, GFP_KERNEL | __GFP_NOTRACK_FALSE_POSITIVE); - -- ``kmemcheck_bitfield_begin(name)``/``kmemcheck_bitfield_end(name)`` and - ``kmemcheck_annotate_bitfield(ptr, name)`` - The first two of these three macros can be used inside struct - definitions to signal, respectively, the beginning and end of a - bitfield. Additionally, this will assign the bitfield a name, which - is given as an argument to the macros. - - Having used these markers, one can later use - kmemcheck_annotate_bitfield() at the point of allocation, to indicate - which parts of the allocation is part of a bitfield. - - Example:: - - struct foo { - int x; - - kmemcheck_bitfield_begin(flags); - int flag_a:1; - int flag_b:1; - kmemcheck_bitfield_end(flags); - - int y; - }; - - struct foo *x = kmalloc(sizeof *x); - - /* No warnings will trigger on accessing the bitfield of x */ - kmemcheck_annotate_bitfield(x, flags); - - Note that ``kmemcheck_annotate_bitfield()`` can be used even before the - return value of ``kmalloc()`` is checked -- in other words, passing NULL - as the first argument is legal (and will do nothing). - - -Reporting errors ----------------- - -As we have seen, kmemcheck will produce false positive reports. Therefore, it -is not very wise to blindly post kmemcheck warnings to mailing lists and -maintainers. Instead, I encourage maintainers and developers to find errors -in their own code. If you get a warning, you can try to work around it, try -to figure out if it's a real error or not, or simply ignore it. Most -developers know their own code and will quickly and efficiently determine the -root cause of a kmemcheck report. This is therefore also the most efficient -way to work with kmemcheck. - -That said, we (the kmemcheck maintainers) will always be on the lookout for -false positives that we can annotate and silence. So whatever you find, -please drop us a note privately! Kernel configs and steps to reproduce (if -available) are of course a great help too. - -Happy hacking! - - -Technical description ---------------------- - -kmemcheck works by marking memory pages non-present. This means that whenever -somebody attempts to access the page, a page fault is generated. The page -fault handler notices that the page was in fact only hidden, and so it calls -on the kmemcheck code to make further investigations. - -When the investigations are completed, kmemcheck "shows" the page by marking -it present (as it would be under normal circumstances). This way, the -interrupted code can continue as usual. - -But after the instruction has been executed, we should hide the page again, so -that we can catch the next access too! Now kmemcheck makes use of a debugging -feature of the processor, namely single-stepping. When the processor has -finished the one instruction that generated the memory access, a debug -exception is raised. From here, we simply hide the page again and continue -execution, this time with the single-stepping feature turned off. - -kmemcheck requires some assistance from the memory allocator in order to work. -The memory allocator needs to - - 1. Tell kmemcheck about newly allocated pages and pages that are about to - be freed. This allows kmemcheck to set up and tear down the shadow memory - for the pages in question. The shadow memory stores the status of each - byte in the allocation proper, e.g. whether it is initialized or - uninitialized. - - 2. Tell kmemcheck which parts of memory should be marked uninitialized. - There are actually a few more states, such as "not yet allocated" and - "recently freed". - -If a slab cache is set up using the SLAB_NOTRACK flag, it will never return -memory that can take page faults because of kmemcheck. - -If a slab cache is NOT set up using the SLAB_NOTRACK flag, callers can still -request memory with the __GFP_NOTRACK or __GFP_NOTRACK_FALSE_POSITIVE flags. -This does not prevent the page faults from occurring, however, but marks the -object in question as being initialized so that no warnings will ever be -produced for this object. - -Currently, the SLAB and SLUB allocators are supported by kmemcheck. -- cgit v1.2.3 From 4518085e127dff97e74f74a8780d7564e273bec8 Mon Sep 17 00:00:00 2001 From: Kemi Wang Date: Wed, 15 Nov 2017 17:38:22 -0800 Subject: mm, sysctl: make NUMA stats configurable This is the second step which introduces a tunable interface that allow numa stats configurable for optimizing zone_statistics(), as suggested by Dave Hansen and Ying Huang. ========================================================================= When page allocation performance becomes a bottleneck and you can tolerate some possible tool breakage and decreased numa counter precision, you can do: echo 0 > /proc/sys/vm/numa_stat In this case, numa counter update is ignored. We can see about *4.8%*(185->176) drop of cpu cycles per single page allocation and reclaim on Jesper's page_bench01 (single thread) and *8.1%*(343->315) drop of cpu cycles per single page allocation and reclaim on Jesper's page_bench03 (88 threads) running on a 2-Socket Broadwell-based server (88 threads, 126G memory). Benchmark link provided by Jesper D Brouer (increase loop times to 10000000): https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm/bench ========================================================================= When page allocation performance is not a bottleneck and you want all tooling to work, you can do: echo 1 > /proc/sys/vm/numa_stat This is system default setting. Many thanks to Michal Hocko, Dave Hansen, Ying Huang and Vlastimil Babka for comments to help improve the original patch. [keescook@chromium.org: make sure mutex is a global static] Link: http://lkml.kernel.org/r/20171107213809.GA4314@beast Link: http://lkml.kernel.org/r/1508290927-8518-1-git-send-email-kemi.wang@intel.com Signed-off-by: Kemi Wang Signed-off-by: Kees Cook Reported-by: Jesper Dangaard Brouer Suggested-by: Dave Hansen Suggested-by: Ying Huang Acked-by: Vlastimil Babka Acked-by: Michal Hocko Cc: "Luis R . Rodriguez" Cc: Kees Cook Cc: Jonathan Corbet Cc: Mel Gorman Cc: Johannes Weiner Cc: Christopher Lameter Cc: Sebastian Andrzej Siewior Cc: Andrey Ryabinin Cc: Tim Chen Cc: Andi Kleen Cc: Aaron Lu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 3e579740b49f..055c8b3e1018 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -58,6 +58,7 @@ Currently, these files are in /proc/sys/vm: - percpu_pagelist_fraction - stat_interval - stat_refresh +- numa_stat - swappiness - user_reserve_kbytes - vfs_cache_pressure @@ -799,6 +800,21 @@ with no ill effects: errors and warnings on these stats are suppressed.) ============================================================== +numa_stat + +This interface allows runtime configuration of numa statistics. + +When page allocation performance becomes a bottleneck and you can tolerate +some possible tool breakage and decreased numa counter precision, you can +do: + echo 0 > /proc/sys/vm/numa_stat + +When page allocation performance is not a bottleneck and you want all +tooling to work, you can do: + echo 1 > /proc/sys/vm/numa_stat + +============================================================== + swappiness This control is used to define how aggressive the kernel will swap -- cgit v1.2.3 From 5c0342ca7ef17220d8dd2da68d0d349c26ab19df Mon Sep 17 00:00:00 2001 From: Claudio Scordino Date: Tue, 14 Nov 2017 12:19:26 +0100 Subject: sched/deadline: Fix the description of runtime accounting in the documentation Signed-off-by: Claudio Scordino Signed-off-by: Luca Abeni Acked-by: Daniel Bristot de Oliveira Acked-by: Peter Zijlstra Cc: Jonathan Corbet Cc: Linus Torvalds Cc: Mathieu Poirier Cc: Thomas Gleixner Cc: Tommaso Cucinotta Cc: linux-doc@vger.kernel.org Link: http://lkml.kernel.org/r/1510658366-28995-1-git-send-email-claudio@evidence.eu.com Signed-off-by: Ingo Molnar --- Documentation/scheduler/sched-deadline.txt | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt index e89e36ec15a5..8ce78f82ae23 100644 --- a/Documentation/scheduler/sched-deadline.txt +++ b/Documentation/scheduler/sched-deadline.txt @@ -204,10 +204,17 @@ CONTENTS It does so by decrementing the runtime of the executing task Ti at a pace equal to - dq = -max{ Ui, (1 - Uinact) } dt + dq = -max{ Ui / Umax, (1 - Uinact - Uextra) } dt - where Uinact is the inactive utilization, computed as (this_bq - running_bw), - and Ui is the bandwidth of task Ti. + where: + + - Ui is the bandwidth of task Ti; + - Umax is the maximum reclaimable utilization (subjected to RT throttling + limits); + - Uinact is the (per runqueue) inactive utilization, computed as + (this_bq - running_bw); + - Uextra is the (per runqueue) extra reclaimable utilization + (subjected to RT throttling limits). Let's now see a trivial example of two deadline tasks with runtime equal -- cgit v1.2.3 From 1759f27027c88adfd94b436fda219eb80531bf6d Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Thu, 9 Nov 2017 18:07:16 +0100 Subject: dt-bindings: usb: fix example hub node name According to the OF Recommended Practice for USB, hub nodes shall be named "hub", but the example had mixed up the label and node names. Fix the node name and drop the redundant label. While at it, remove a newline and add a missing semicolon to the example source. Signed-off-by: Johan Hovold Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-device.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt index ce02cebac26a..4df7e22e0084 100644 --- a/Documentation/devicetree/bindings/usb/usb-device.txt +++ b/Documentation/devicetree/bindings/usb/usb-device.txt @@ -16,12 +16,11 @@ Required properties: Example: &usb1 { - #address-cells = <1>; #size-cells = <0>; - hub: genesys@1 { + hub@1 { compatible = "usb5e3,608"; reg = <1>; }; -} +}; -- cgit v1.2.3 From f42ae7b0540937e00fe005812997f126aaac4bc2 Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Thu, 9 Nov 2017 18:07:17 +0100 Subject: dt-bindings: usb: fix reg-property port-number range The USB hub port-number range for USB 2.0 is 1-255 and not 1-31 which reflects an arbitrary limit set by the current Linux implementation. Note that for USB 3.1 hubs the valid range is 1-15. Increase the documented valid range in the binding to 255, which is the maximum allowed by the specifications. Signed-off-by: Johan Hovold Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-device.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt index 4df7e22e0084..b749fb9f2674 100644 --- a/Documentation/devicetree/bindings/usb/usb-device.txt +++ b/Documentation/devicetree/bindings/usb/usb-device.txt @@ -11,7 +11,7 @@ Required properties: be used, but a device adhering to this binding may leave out all except for usbVID,PID. - reg: the port number which this device is connecting to, the range - is 1-31. + is 1-255. Example: -- cgit v1.2.3 From bfebcf54608a749800a171ffd01f7d5b450e9a55 Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Thu, 9 Nov 2017 18:07:18 +0100 Subject: dt-bindings: usb: clean up compatible property Add quotation marks around the compatible string to avoid ambiguity due to following punctuation, and define the VID and PID components. Signed-off-by: Johan Hovold Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-device.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt index b749fb9f2674..e0b562e35a0c 100644 --- a/Documentation/devicetree/bindings/usb/usb-device.txt +++ b/Documentation/devicetree/bindings/usb/usb-device.txt @@ -5,11 +5,11 @@ The reference binding doc is from: http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps Required properties: -- compatible: usbVID,PID. The textual representation of VID, PID shall - be in lower case hexadecimal with leading zeroes suppressed. The - other compatible strings from the above standard binding could also - be used, but a device adhering to this binding may leave out all except - for usbVID,PID. +- compatible: "usbVID,PID", where VID is the vendor id and PID the product id. + The textual representation of VID and PID shall be in lower case hexadecimal + with leading zeroes suppressed. The other compatible strings from the above + standard binding could also be used, but a device adhering to this binding + may leave out all except for "usbVID,PID". - reg: the port number which this device is connecting to, the range is 1-255. -- cgit v1.2.3 From f877918cdd793373fb7a960c72ba3639786e8e8f Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Thu, 9 Nov 2017 18:07:19 +0100 Subject: dt-bindings: usb: document hub and host-controller properties Hub nodes and host-controller nodes with child nodes must specify values for #address-cells (1) and #size-cells (0). Also make the definition of the related reg property a bit more stringent, and add comments to the example source. Signed-off-by: Johan Hovold Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-device.txt | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt index e0b562e35a0c..1b27cebb47f4 100644 --- a/Documentation/devicetree/bindings/usb/usb-device.txt +++ b/Documentation/devicetree/bindings/usb/usb-device.txt @@ -4,22 +4,34 @@ Usually, we only use device tree for hard wired USB device. The reference binding doc is from: http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps + Required properties: - compatible: "usbVID,PID", where VID is the vendor id and PID the product id. The textual representation of VID and PID shall be in lower case hexadecimal with leading zeroes suppressed. The other compatible strings from the above standard binding could also be used, but a device adhering to this binding may leave out all except for "usbVID,PID". -- reg: the port number which this device is connecting to, the range - is 1-255. +- reg: the number of the USB hub port or the USB host-controller port to which + this device is attached. The range is 1-255. + + +Required properties for hub nodes with device nodes: +- #address-cells: shall be 1 +- #size-cells: shall be 0 + + +Required properties for host-controller nodes with device nodes: +- #address-cells: shall be 1 +- #size-cells: shall be 0 + Example: -&usb1 { +&usb1 { /* host controller */ #address-cells = <1>; #size-cells = <0>; - hub@1 { + hub@1 { /* hub connected to port 1 */ compatible = "usb5e3,608"; reg = <1>; }; -- cgit v1.2.3 From f8817f61e8215b0ff1b73a0d33fa04ef9e6bce8b Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 16 Nov 2017 22:51:22 +0100 Subject: PM / runtime: Drop children check from __pm_runtime_set_status() The check for "active" children in __pm_runtime_set_status(), when trying to set the parent device status to "suspended", doesn't really make sense, because in fact it is not invalid to set the status of a device with runtime PM disabled to "suspended" in any case. It is invalid to enable runtime PM for a device with its status set to "suspended" while its child_count reference counter is nonzero, but the check in __pm_runtime_set_status() doesn't really cover that situation. For this reason, drop the children check from __pm_runtime_set_status() and add a check against child_count reference counters of "suspended" devices to pm_runtime_enable(). Fixes: a8636c89648a (PM / Runtime: Don't allow to suspend a device with an active child) Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Reviewed-by: Johan Hovold --- Documentation/power/runtime_pm.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 57af2f7963ee..937e33c46211 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -435,8 +435,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: PM status to 'suspended' and update its parent's counter of 'active' children as appropriate (it is only valid to use this function if 'power.runtime_error' is set or 'power.disable_depth' is greater than - zero); it will fail and return an error code if the device has a child - which is active and the 'power.ignore_children' flag is unset + zero) bool pm_runtime_active(struct device *dev); - return true if the device's runtime PM status is 'active' or its -- cgit v1.2.3 From c643401218be0f4ab3522e0c0a63016596d6e9ca Mon Sep 17 00:00:00 2001 From: Roman Gushchin Date: Fri, 17 Nov 2017 15:26:45 -0800 Subject: proc, coredump: add CoreDumping flag to /proc/pid/status Right now there is no convenient way to check if a process is being coredumped at the moment. It might be necessary to recognize such state to prevent killing the process and getting a broken coredump. Writing a large core might take significant time, and the process is unresponsive during it, so it might be killed by timeout, if another process is monitoring and killing/restarting hanging tasks. We're getting a significant number of corrupted coredump files on machines in our fleet, just because processes are being killed by timeout in the middle of the core writing process. We do have a process health check, and some agent is responsible for restarting processes which are not responding for health check requests. Writing a large coredump to the disk can easily exceed the reasonable timeout (especially on an overloaded machine). This flag will allow the agent to distinguish processes which are being coredumped, extend the timeout for them, and let them produce a full coredump file. To provide an ability to detect if a process is in the state of being coredumped, we can expose a boolean CoreDumping flag in /proc/pid/status. Example: $ cat core.sh #!/bin/sh echo "|/usr/bin/sleep 10" > /proc/sys/kernel/core_pattern sleep 1000 & PID=$! cat /proc/$PID/status | grep CoreDumping kill -ABRT $PID sleep 1 cat /proc/$PID/status | grep CoreDumping $ ./core.sh CoreDumping: 0 CoreDumping: 1 [guro@fb.com: document CoreDumping flag in /proc//status] Link: http://lkml.kernel.org/r/20170928135357.GA8470@castle.DHCP.thefacebook.com Link: http://lkml.kernel.org/r/20170920230634.31572-1-guro@fb.com Signed-off-by: Roman Gushchin Cc: Alexander Viro Cc: Ingo Molnar Cc: Konstantin Khlebnikov Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index ec571b9bb18a..2a84bb334894 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -181,6 +181,7 @@ read the file /proc/PID/status: VmPTE: 20 kb VmSwap: 0 kB HugetlbPages: 0 kB + CoreDumping: 0 Threads: 1 SigQ: 0/28578 SigPnd: 0000000000000000 @@ -253,6 +254,8 @@ Table 1-2: Contents of the status files (as of 4.8) VmSwap amount of swap used by anonymous private data (shmem swap usage is not included) HugetlbPages size of hugetlb memory portions + CoreDumping process's memory is currently being dumped + (killing the process may lead to a corrupted core) Threads number of threads SigQ number of signals queued/max. number for queue SigPnd bitmap of pending signals for the thread -- cgit v1.2.3 From b1fca27d384e8418aac84b39f6f5179aecc1b64f Mon Sep 17 00:00:00 2001 From: Andi Kleen Date: Fri, 17 Nov 2017 15:27:03 -0800 Subject: kernel debug: support resetting WARN*_ONCE I like _ONCE warnings because it's guaranteed that they don't flood the log. During testing I find it useful to reset the state of the once warnings, so that I can rerun tests and see if they trigger again, or can guarantee that a test run always hits the same warnings. This patch adds a debugfs interface to reset all the _ONCE warnings so that they appear again: echo 1 > /sys/kernel/debug/clear_warn_once This is implemented by putting all the warning booleans into a special section, and clearing it. [akpm@linux-foundation.org: coding-style fixes] Link: http://lkml.kernel.org/r/20171017221455.6740-1-andi@firstfloor.org Signed-off-by: Andi Kleen Tested-by: Michael Ellerman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/clearing-warn-once.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/clearing-warn-once.txt (limited to 'Documentation') diff --git a/Documentation/clearing-warn-once.txt b/Documentation/clearing-warn-once.txt new file mode 100644 index 000000000000..5b1f5d547be1 --- /dev/null +++ b/Documentation/clearing-warn-once.txt @@ -0,0 +1,7 @@ + +WARN_ONCE / WARN_ON_ONCE only print a warning once. + +echo 1 > /sys/kernel/debug/clear_warn_once + +clears the state and allows the warnings to print once again. +This can be useful after test suite runs to reproduce problems. -- cgit v1.2.3 From 8c188759fb5788579b5975d5a8c9f529e25c2171 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Fri, 17 Nov 2017 15:27:39 -0800 Subject: dynamic_debug documentation: minor fixes Fix minor typo. Fix missing words in explaining parsing of last line number. Link: http://lkml.kernel.org/r/ebb7ff42-4945-103f-d5b4-f07a6f3343a7@infradead.org Signed-off-by: Randy Dunlap Cc: Jason Baron Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/dynamic-debug-howto.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 12278a926370..fdf72429f801 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -18,7 +18,7 @@ shortcut for ``print_hex_dump(KERN_DEBUG)``. For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is its ``prefix_str`` argument, if it is constant string; or ``hexdump`` -in case ``prefix_str`` is build dynamically. +in case ``prefix_str`` is built dynamically. Dynamic debug has even more useful features: @@ -197,8 +197,8 @@ line line number matches the callsite line number exactly. A range of line numbers matches any callsite between the first and last line number inclusive. An empty first number means - the first line in the file, an empty line number means the - last number in the file. Examples:: + the first line in the file, an empty last line number means the + last line number in the file. Examples:: line 1603 // exactly line 1603 line 1600-1605 // the six lines from line 1600 to line 1605 -- cgit v1.2.3 From 2743232c0c4c82311718bb4ec1fb659ed64ecf7a Mon Sep 17 00:00:00 2001 From: Kangmin Park Date: Fri, 17 Nov 2017 15:30:23 -0800 Subject: Documentation/sysctl/vm.txt: fix typo Link: http://lkml.kernel.org/r/CAKW4uUyCi=PnKf3epgFVz8z=1tMtHSOHNm+fdNxrNw3-THvRCA@mail.gmail.com Signed-off-by: Kangmin Park Cc: Jiri Kosina Cc: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 055c8b3e1018..b920423f88cb 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -818,7 +818,7 @@ tooling to work, you can do: swappiness This control is used to define how aggressive the kernel will swap -memory pages. Higher values will increase agressiveness, lower values +memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone. -- cgit v1.2.3 From c512ac01d8a841033da8ec538a83f80fb0b4d1fe Mon Sep 17 00:00:00 2001 From: Victor Chibotaru Date: Fri, 17 Nov 2017 15:30:53 -0800 Subject: kcov: update documentation The updated documentation describes new KCOV mode for collecting comparison operands. Link: http://lkml.kernel.org/r/20171011095459.70721-3-glider@google.com Signed-off-by: Victor Chibotaru Signed-off-by: Alexander Potapenko Cc: Dmitry Vyukov Cc: Andrey Konovalov Cc: Mark Rutland Cc: Alexander Popov Cc: Andrey Ryabinin Cc: Kees Cook Cc: Vegard Nossum Cc: Quentin Casasnovas Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dev-tools/kcov.rst | 99 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 95 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst index 44886c91e112..c2f6452e38ed 100644 --- a/Documentation/dev-tools/kcov.rst +++ b/Documentation/dev-tools/kcov.rst @@ -12,19 +12,30 @@ To achieve this goal it does not collect coverage in soft/hard interrupts and instrumentation of some inherently non-deterministic parts of kernel is disabled (e.g. scheduler, locking). -Usage ------ +kcov is also able to collect comparison operands from the instrumented code +(this feature currently requires that the kernel is compiled with clang). + +Prerequisites +------------- Configure the kernel with:: CONFIG_KCOV=y CONFIG_KCOV requires gcc built on revision 231296 or later. + +If the comparison operands need to be collected, set:: + + CONFIG_KCOV_ENABLE_COMPARISONS=y + Profiling data will only become accessible once debugfs has been mounted:: mount -t debugfs none /sys/kernel/debug -The following program demonstrates kcov usage from within a test program: +Coverage collection +------------------- +The following program demonstrates coverage collection from within a test +program using kcov: .. code-block:: c @@ -44,6 +55,9 @@ The following program demonstrates kcov usage from within a test program: #define KCOV_DISABLE _IO('c', 101) #define COVER_SIZE (64<<10) + #define KCOV_TRACE_PC 0 + #define KCOV_TRACE_CMP 1 + int main(int argc, char **argv) { int fd; @@ -64,7 +78,7 @@ The following program demonstrates kcov usage from within a test program: if ((void*)cover == MAP_FAILED) perror("mmap"), exit(1); /* Enable coverage collection on the current thread. */ - if (ioctl(fd, KCOV_ENABLE, 0)) + if (ioctl(fd, KCOV_ENABLE, KCOV_TRACE_PC)) perror("ioctl"), exit(1); /* Reset coverage from the tail of the ioctl() call. */ __atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED); @@ -111,3 +125,80 @@ The interface is fine-grained to allow efficient forking of test processes. That is, a parent process opens /sys/kernel/debug/kcov, enables trace mode, mmaps coverage buffer and then forks child processes in a loop. Child processes only need to enable coverage (disable happens automatically on thread end). + +Comparison operands collection +------------------------------ +Comparison operands collection is similar to coverage collection: + +.. code-block:: c + + /* Same includes and defines as above. */ + + /* Number of 64-bit words per record. */ + #define KCOV_WORDS_PER_CMP 4 + + /* + * The format for the types of collected comparisons. + * + * Bit 0 shows whether one of the arguments is a compile-time constant. + * Bits 1 & 2 contain log2 of the argument size, up to 8 bytes. + */ + + #define KCOV_CMP_CONST (1 << 0) + #define KCOV_CMP_SIZE(n) ((n) << 1) + #define KCOV_CMP_MASK KCOV_CMP_SIZE(3) + + int main(int argc, char **argv) + { + int fd; + uint64_t *cover, type, arg1, arg2, is_const, size; + unsigned long n, i; + + fd = open("/sys/kernel/debug/kcov", O_RDWR); + if (fd == -1) + perror("open"), exit(1); + if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE)) + perror("ioctl"), exit(1); + /* + * Note that the buffer pointer is of type uint64_t*, because all + * the comparison operands are promoted to uint64_t. + */ + cover = (uint64_t *)mmap(NULL, COVER_SIZE * sizeof(unsigned long), + PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); + if ((void*)cover == MAP_FAILED) + perror("mmap"), exit(1); + /* Note KCOV_TRACE_CMP instead of KCOV_TRACE_PC. */ + if (ioctl(fd, KCOV_ENABLE, KCOV_TRACE_CMP)) + perror("ioctl"), exit(1); + __atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED); + read(-1, NULL, 0); + /* Read number of comparisons collected. */ + n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED); + for (i = 0; i < n; i++) { + type = cover[i * KCOV_WORDS_PER_CMP + 1]; + /* arg1 and arg2 - operands of the comparison. */ + arg1 = cover[i * KCOV_WORDS_PER_CMP + 2]; + arg2 = cover[i * KCOV_WORDS_PER_CMP + 3]; + /* ip - caller address. */ + ip = cover[i * KCOV_WORDS_PER_CMP + 4]; + /* size of the operands. */ + size = 1 << ((type & KCOV_CMP_MASK) >> 1); + /* is_const - true if either operand is a compile-time constant.*/ + is_const = type & KCOV_CMP_CONST; + printf("ip: 0x%lx type: 0x%lx, arg1: 0x%lx, arg2: 0x%lx, " + "size: %lu, %s\n", + ip, type, arg1, arg2, size, + is_const ? "const" : "non-const"); + } + if (ioctl(fd, KCOV_DISABLE, 0)) + perror("ioctl"), exit(1); + /* Free resources. */ + if (munmap(cover, COVER_SIZE * sizeof(unsigned long))) + perror("munmap"), exit(1); + if (close(fd)) + perror("close"), exit(1); + return 0; + } + +Note that the kcov modes (coverage collection or comparison operands) are +mutually exclusive. -- cgit v1.2.3 From 16f8259ca77d04f95e5ca90be1b1894ed45816c0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B8rn=20Forsman?= Date: Sun, 5 Nov 2017 10:44:16 +0100 Subject: kbuild: /bin/pwd -> pwd MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Most places use pwd and rely on $PATH lookup. Moving the remaining absolute path /bin/pwd users over for consistency. Also, a reason for doing /bin/pwd -> pwd instead of the other way around is because I believe build systems should make little assumptions on host filesystem layout. Case in point, we do this kind of patching already in NixOS. Ref. commit 028568d84da3cfca49f5f846eeeef01441d70451 ("kbuild: revert $(realpath ...) to $(shell cd ... && /bin/pwd)"). Signed-off-by: Bjørn Forsman Signed-off-by: Masahiro Yamada --- Documentation/ia64/xen.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ia64/xen.txt b/Documentation/ia64/xen.txt index c61a99f7c8bb..a12c74ce2773 100644 --- a/Documentation/ia64/xen.txt +++ b/Documentation/ia64/xen.txt @@ -41,7 +41,7 @@ Getting and Building Xen and Dom0 5. make initrd for Dom0/DomU # make -C linux-2.6.18-xen.hg ARCH=ia64 modules_install \ - O=$(/bin/pwd)/build-linux-2.6.18-xen_ia64 + O=$(pwd)/build-linux-2.6.18-xen_ia64 # mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.18.8-xen.img \ 2.6.18.8-xen --builtin mptspi --builtin mptbase \ --builtin mptscsih --builtin uhci-hcd --builtin ohci-hcd \ -- cgit v1.2.3 From d0450244a4920187eebf844a1610744059b59ee6 Mon Sep 17 00:00:00 2001 From: Logan Gunthorpe Date: Thu, 3 Aug 2017 12:19:54 -0600 Subject: NTB: switchtec_ntb: Update switchtec documentation with notes for NTB The switchtec_ntb driver has a couple requirements on the switchec's hardware configuration so we add these notes to the documentation. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt Schwemmer Acked-by: Allen Hubbe Signed-off-by: Jon Mason --- Documentation/switchtec.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt index a0a9c7b3d4d5..f788264921ff 100644 --- a/Documentation/switchtec.txt +++ b/Documentation/switchtec.txt @@ -78,3 +78,15 @@ The following IOCTLs are also supported by the device: between PCI Function Framework number (used by the event system) and Switchtec Logic Port ID and Partition number (which is more user friendly). + + +Non-Transparent Bridge (NTB) Driver +=================================== + +An NTB driver is provided for the switchtec hardware in switchtec_ntb. +Currently, it only supports switches configured with exactly 2 +partitions. It also requires the following configuration settings: + +* Both partitions must be able to access each other's GAS spaces. + Thus, the bits in the GAS Access Vector under Management Settings + must be set to support this. -- cgit v1.2.3 From 8ee25f6fcfa967da26c5dfa43c731a61f84f7404 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Thu, 16 Nov 2017 14:23:09 +0100 Subject: Documentation/process: add Co-Developed-by: tag for patches with multiple authors Sometimes a single patch is the result of multiple authors. As git only can have one "author" of a patch, it is still good to properly give credit to the other developers of a commit. To address this, document the "Co-Developed-by:" tag which can be used to show other authors of the patch. Note, these other authors must also provide a Signed-off-by: tag as it is their work that is being submitted here. Reported-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman Reviewed-by: Thomas Gleixner Acked-by: Borislav Petkov Signed-off-by: Jonathan Corbet --- Documentation/process/5.Posting.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index 1b7728b19ea7..645fa9c7388a 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -213,6 +213,11 @@ The tags in common use are: which can be found in Documentation/process/submitting-patches.rst. Code without a proper signoff cannot be merged into the mainline. + - Co-Developed-by: states that the patch was also created by another developer + along with the original author. This is useful at times when multiple + people work on a single patch. Note, this person also needs to have a + Signed-off-by: line in the patch as well. + - Acked-by: indicates an agreement by another developer (often a maintainer of the relevant code) that the patch is appropriate for inclusion into the kernel. -- cgit v1.2.3 From 578152da87c7e9d350a5164beb16214e5bef1420 Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Sat, 18 Nov 2017 11:52:23 +0900 Subject: kokr/memory-barriers/txt: Replace uses of "transitive" This commit applies two upstream change, commit f1ab25a30ce8 ("memory-barriers: Replace uses of "transitive"") and commit 0902b1f44a72 ("memory-barriers: Rework multicopy-atomicity section") to the Korean translation. Those two changes are applied with this signle commit because the second change is improvement of the first one. Signed-off-by: SeongJae Park Signed-off-by: Jonathan Corbet --- .../translations/ko_KR/memory-barriers.txt | 176 ++++++++++----------- 1 file changed, 88 insertions(+), 88 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index a7a813258013..7433ad60fabc 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -82,7 +82,7 @@ Documentation/memory-barriers.txt - SMP 배리어 짝맞추기. - 메모리 배리어 시퀀스의 예. - 읽기 메모리 배리어 vs 로드 예측. - - 이행성 + - Multicopy 원자성. (*) 명시적 커널 배리어. @@ -656,6 +656,11 @@ Documentation/RCU/rcu_dereference.txt 파일을 주의 깊게 읽어 주시기 해줍니다. +데이터 의존성에 의해 제공되는 이 순서규칙은 이를 포함하고 있는 CPU 에 +지역적임을 알아두시기 바랍니다. 더 많은 정보를 위해선 "Multicopy 원자성" +섹션을 참고하세요. + + 데이터 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다. include/linux/rcupdate.h 의 rcu_assign_pointer() 와 rcu_dereference() 를 참고하세요. 여기서 데이터 의존성 배리어는 RCU 로 관리되는 포인터의 타겟을 현재 @@ -864,38 +869,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레 주어진 if 문의 then 절과 else 절에게만 (그리고 이 두 절 내에서 호출되는 함수들에게까지) 적용되지, 이 if 문을 뒤따르는 코드에는 적용되지 않습니다. -마지막으로, 컨트롤 의존성은 이행성 (transitivity) 을 제공하지 -않습니다-. 이건 -'x' 와 'y' 가 둘 다 0 이라는 초기값을 가졌다는 가정 하의 두개의 예제로 -보이겠습니다: - - CPU 0 CPU 1 - ======================= ======================= - r1 = READ_ONCE(x); r2 = READ_ONCE(y); - if (r1 > 0) if (r2 > 0) - WRITE_ONCE(y, 1); WRITE_ONCE(x, 1); - - assert(!(r1 == 1 && r2 == 1)); - -이 두 CPU 예제에서 assert() 의 조건은 항상 참일 것입니다. 그리고, 만약 컨트롤 -의존성이 이행성을 (실제로는 그러지 않지만) 보장한다면, 다음의 CPU 가 추가되어도 -아래의 assert() 조건은 참이 될것입니다: - CPU 2 - ===================== - WRITE_ONCE(x, 2); +컨트롤 의존성에 의해 제공되는 이 순서규칙은 이를 포함하고 있는 CPU 에 +지역적입니다. 더 많은 정보를 위해선 "Multicopy 원자성" 섹션을 참고하세요. - assert(!(r1 == 2 && r2 == 1 && x == 2)); /* FAILS!!! */ - -하지만 컨트롤 의존성은 이행성을 제공하지 -않기- 때문에, 세개의 CPU 예제가 실행 -완료된 후에 위의 assert() 의 조건은 거짓으로 평가될 수 있습니다. 세개의 CPU -예제가 순서를 지키길 원한다면, CPU 0 와 CPU 1 코드의 로드와 스토어 사이, "if" -문 바로 다음에 smp_mb()를 넣어야 합니다. 더 나아가서, 최초의 두 CPU 예제는 -매우 위험하므로 사용되지 않아야 합니다. - -이 두개의 예제는 다음 논문: -http://www.cl.cam.ac.uk/users/pes20/ppc-supplemental/test6.pdf 와 -이 사이트: https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html 에 나온 LB 와 WWC -리트머스 테스트입니다. 요약하자면: @@ -930,8 +907,8 @@ http://www.cl.cam.ac.uk/users/pes20/ppc-supplemental/test6.pdf 와 (*) 컨트롤 의존성은 보통 다른 타입의 배리어들과 짝을 맞춰 사용됩니다. - (*) 컨트롤 의존성은 이행성을 제공하지 -않습니다-. 이행성이 필요하다면, - smp_mb() 를 사용하세요. + (*) 컨트롤 의존성은 multicopy 원자성을 제공하지 -않습니다-. 모든 CPU 들이 + 특정 스토어를 동시에 보길 원한다면, smp_mb() 를 사용하세요. (*) 컴파일러는 컨트롤 의존성을 이해하고 있지 않습니다. 따라서 컴파일러가 여러분의 코드를 망가뜨리지 않도록 하는건 여러분이 해야 하는 일입니다. @@ -943,13 +920,14 @@ SMP 배리어 짝맞추기 CPU 간 상호작용을 다룰 때에 일부 타입의 메모리 배리어는 항상 짝을 맞춰 사용되어야 합니다. 적절하게 짝을 맞추지 않은 코드는 사실상 에러에 가깝습니다. -범용 배리어들은 범용 배리어끼리도 짝을 맞추지만 이행성이 없는 대부분의 다른 -타입의 배리어들과도 짝을 맞춥니다. ACQUIRE 배리어는 RELEASE 배리어와 짝을 -맞춥니다만, 둘 다 범용 배리어를 포함해 다른 배리어들과도 짝을 맞출 수 있습니다. -쓰기 배리어는 데이터 의존성 배리어나 컨트롤 의존성, ACQUIRE 배리어, RELEASE -배리어, 읽기 배리어, 또는 범용 배리어와 짝을 맞춥니다. 비슷하게 읽기 배리어나 -컨트롤 의존성, 또는 데이터 의존성 배리어는 쓰기 배리어나 ACQUIRE 배리어, -RELEASE 배리어, 또는 범용 배리어와 짝을 맞추는데, 다음과 같습니다: +범용 배리어들은 범용 배리어끼리도 짝을 맞추지만 multicopy 원자성이 없는 +대부분의 다른 타입의 배리어들과도 짝을 맞춥니다. ACQUIRE 배리어는 RELEASE +배리어와 짝을 맞춥니다만, 둘 다 범용 배리어를 포함해 다른 배리어들과도 짝을 +맞출 수 있습니다. 쓰기 배리어는 데이터 의존성 배리어나 컨트롤 의존성, ACQUIRE +배리어, RELEASE 배리어, 읽기 배리어, 또는 범용 배리어와 짝을 맞춥니다. +비슷하게 읽기 배리어나 컨트롤 의존성, 또는 데이터 의존성 배리어는 쓰기 배리어나 +ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추는데, 다음과 +같습니다: CPU 1 CPU 2 =============== =============== @@ -1361,57 +1339,74 @@ A 의 로드 두개가 모두 B 의 로드 뒤에 있지만, 서로 다른 값 : : +-------+ -이행성 ------- +MULTICOPY 원자성 +---------------- -이행성(transitivity)은 실제의 컴퓨터 시스템에서 항상 제공되지는 않는, 순서 -맞추기에 대한 상당히 직관적인 개념입니다. 다음의 예가 이행성을 보여줍니다: +Multicopy 원자성은 실제의 컴퓨터 시스템에서 항상 제공되지는 않는, 순서 맞추기에 +대한 상당히 직관적인 개념으로, 특정 스토어가 모든 CPU 들에게 동시에 보여지게 +됨을, 달리 말하자면 모든 CPU 들이 모든 스토어들이 보여지는 순서를 동의하게 되는 +것입니다. 하지만, 완전한 multicopy 원자성의 사용은 가치있는 하드웨어 +최적화들을 무능하게 만들어버릴 수 있어서, 보다 완화된 형태의 ``다른 multicopy +원자성'' 라는 이름의, 특정 스토어가 모든 -다른- CPU 들에게는 동시에 보여지게 +하는 보장을 대신 제공합니다. 이 문서의 뒷부분들은 이 완화된 형태에 대해 논하게 +됩니다만, 단순히 ``multicopy 원자성'' 이라고 부르겠습니다. + +다음의 예가 multicopy 원자성을 보입니다: CPU 1 CPU 2 CPU 3 ======================= ======================= ======================= { X = 0, Y = 0 } - STORE X=1 LOAD X STORE Y=1 - <범용 배리어> <범용 배리어> - LOAD Y LOAD X - -CPU 2 의 X 로드가 1을 리턴했고 Y 로드가 0을 리턴했다고 해봅시다. 이는 CPU 2 의 -X 로드가 CPU 1 의 X 스토어 뒤에 이루어졌고 CPU 2 의 Y 로드는 CPU 3 의 Y 스토어 -전에 이루어졌음을 의미합니다. 그럼 "CPU 3 의 X 로드는 0을 리턴할 수 있나요?" - -CPU 2 의 X 로드는 CPU 1 의 스토어 후에 이루어졌으니, CPU 3 의 X 로드는 1을 -리턴하는게 자연스럽습니다. 이런 생각이 이행성의 한 예입니다: CPU A 에서 실행된 -로드가 CPU B 에서의 같은 변수에 대한 로드를 뒤따른다면, CPU A 의 로드는 CPU B -의 로드가 내놓은 값과 같거나 그 후의 값을 내놓아야 합니다. - -리눅스 커널에서 범용 배리어의 사용은 이행성을 보장합니다. 따라서, 앞의 예에서 -CPU 2 의 X 로드가 1을, Y 로드는 0을 리턴했다면, CPU 3 의 X 로드는 반드시 1을 -리턴합니다. - -하지만, 읽기나 쓰기 배리어에 대해서는 이행성이 보장되지 -않습니다-. 예를 들어, -앞의 예에서 CPU 2 의 범용 배리어가 아래처럼 읽기 배리어로 바뀐 경우를 생각해 -봅시다: + STORE X=1 r1=LOAD X (reads 1) LOAD Y (reads 1) + <범용 배리어> <읽기 배리어> + STORE Y=r1 LOAD X + +CPU 2 의 Y 로의 스토어에 사용되는 X 로드의 결과가 1 이었고 CPU 3 의 Y 로드가 +1을 리턴했다고 해봅시다. 이는 CPU 1 의 X 로의 스토어가 CPU 2 의 X 로부터의 +로드를 앞서고 CPU 2 의 Y 로의 스토어가 CPU 3 의 Y 로부터의 로드를 앞섬을 +의미합니다. 또한, 여기서의 메모리 배리어들은 CPU 2 가 자신의 로드를 자신의 +스토어 전에 수행하고, CPU 3 가 Y 로부터의 로드를 X 로부터의 로드 전에 수행함을 +보장합니다. 그럼 "CPU 3 의 X 로부터의 로드는 0 을 리턴할 수 있을까요?" + +CPU 3 의 X 로드가 CPU 2 의 로드보다 뒤에 이루어졌으므로, CPU 3 의 X 로부터의 +로드는 1 을 리턴한다고 예상하는게 당연합니다. 이런 예상은 multicopy +원자성으로부터 나옵니다: CPU B 에서 수행된 로드가 CPU A 의 같은 변수로부터의 +로드를 뒤따른다면 (그리고 CPU A 가 자신이 읽은 값으로 먼저 해당 변수에 스토어 +하지 않았다면) multicopy 원자성을 제공하는 시스템에서는, CPU B 의 로드가 CPU A +의 로드와 같은 값 또는 그 나중 값을 리턴해야만 합니다. 하지만, 리눅스 커널은 +시스템들이 multicopy 원자성을 제공할 것을 요구하지 않습니다. + +앞의 범용 메모리 배리어의 사용은 모든 multicopy 원자성의 부족을 보상해줍니다. +앞의 예에서, CPU 2 의 X 로부터의 로드가 1 을 리턴했고 CPU 3 의 Y 로부터의 +로드가 1 을 리턴했다면, CPU 3 의 X 로부터의 로드는 1을 리턴해야만 합니다. + +하지만, 의존성, 읽기 배리어, 쓰기 배리어는 항상 non-multicopy 원자성을 보상해 +주지는 않습니다. 예를 들어, CPU 2 의 범용 배리어가 앞의 예에서 사라져서 +아래처럼 데이터 의존성만 남게 되었다고 해봅시다: CPU 1 CPU 2 CPU 3 ======================= ======================= ======================= { X = 0, Y = 0 } - STORE X=1 LOAD X STORE Y=1 - <읽기 배리어> <범용 배리어> - LOAD Y LOAD X - -이 코드는 이행성을 갖지 않습니다: 이 예에서는, CPU 2 의 X 로드가 1을 -리턴하고, Y 로드는 0을 리턴하지만 CPU 3 의 X 로드가 0을 리턴하는 것도 완전히 -합법적입니다. - -CPU 2 의 읽기 배리어가 자신의 읽기는 순서를 맞춰줘도, CPU 1 의 스토어와의 -순서를 맞춰준다고는 보장할 수 없다는게 핵심입니다. 따라서, CPU 1 과 CPU 2 가 -버퍼나 캐시를 공유하는 시스템에서 이 예제 코드가 실행된다면, CPU 2 는 CPU 1 이 -쓴 값에 좀 빨리 접근할 수 있을 것입니다. 따라서 CPU 1 과 CPU 2 의 접근으로 -조합된 순서를 모든 CPU 가 동의할 수 있도록 하기 위해 범용 배리어가 필요합니다. - -범용 배리어는 "글로벌 이행성"을 제공해서, 모든 CPU 들이 오퍼레이션들의 순서에 -동의하게 할 것입니다. 반면, release-acquire 조합은 "로컬 이행성" 만을 -제공해서, 해당 조합이 사용된 CPU 들만이 해당 액세스들의 조합된 순서에 동의함이 -보장됩니다. 예를 들어, 존경스런 Herman Hollerith 의 C 코드로 보면: + STORE X=1 r1=LOAD X (reads 1) LOAD Y (reads 1) + <데이터 의존성> <읽기 배리어> + STORE Y=r1 LOAD X (reads 0) + +이 변화는 non-multicopy 원자성이 만연하게 합니다: 이 예에서, CPU 2 의 X +로부터의 로드가 1을 리턴하고, CPU 3 의 Y 로부터의 로드가 1 을 리턴하는데, CPU 3 +의 X 로부터의 로드가 0 을 리턴하는게 완전히 합법적입니다. + +핵심은, CPU 2 의 데이터 의존성이 자신의 로드와 스토어를 순서짓지만, CPU 1 의 +스토어에 대한 순서는 보장하지 않는다는 것입니다. 따라서, 이 예제가 CPU 1 과 +CPU 2 가 스토어 버퍼나 한 수준의 캐시를 공유하는, multicopy 원자성을 제공하지 +않는 시스템에서 수행된다면 CPU 2 는 CPU 1 의 쓰기에 이른 접근을 할 수도 +있습니다. 따라서, 모든 CPU 들이 여러 접근들의 조합된 순서에 대해서 동의하게 +하기 위해서는 범용 배리어가 필요합니다. + +범용 배리어는 non-multicopy 원자성만 보상할 수 있는게 아니라, -모든- CPU 들이 +-모든- 오퍼레이션들의 순서를 동일하게 인식하게 하는 추가적인 순서 보장을 +만들어냅니다. 반대로, release-acquire 짝의 연결은 이런 추가적인 순서는 +제공하지 않는데, 해당 연결에 들어있는 CPU 들만이 메모리 접근의 조합된 순서에 +대해 동의할 것으로 보장됨을 의미합니다. 예를 들어, 존경스런 Herman Hollerith +의 코드를 C 코드로 변환하면: int u, v, x, y, z; @@ -1444,8 +1439,7 @@ CPU 2 의 읽기 배리어가 자신의 읽기는 순서를 맞춰줘도, CPU 1 } cpu0(), cpu1(), 그리고 cpu2() 는 smp_store_release()/smp_load_acquire() 쌍의 -연결을 통한 로컬 이행성에 동참하고 있으므로, 다음과 같은 결과는 나오지 않을 -겁니다: +연결에 참여되어 있으므로, 다음과 같은 결과는 나오지 않을 겁니다: r0 == 1 && r1 == 1 && r2 == 1 @@ -1454,8 +1448,9 @@ cpu0() 의 쓰기를 봐야만 하므로, 다음과 같은 결과도 없을 겁 r1 == 1 && r5 == 0 -하지만, release-acquire 타동성은 동참한 CPU 들에만 적용되므로 cpu3() 에는 -적용되지 않습니다. 따라서, 다음과 같은 결과가 가능합니다: +하지만, release-acquire 에 의해 제공되는 순서는 해당 연결에 동참한 CPU 들에만 +적용되므로 cpu3() 에, 적어도 스토어들 외에는 적용되지 않습니다. 따라서, 다음과 +같은 결과가 가능합니다: r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 @@ -1482,8 +1477,8 @@ u 로의 스토어를 cpu1() 의 v 로부터의 로드 뒤에 일어난 것으 이런 결과는 어떤 것도 재배치 되지 않는, 순차적 일관성을 가진 가상의 시스템에서도 일어날 수 있음을 기억해 두시기 바랍니다. -다시 말하지만, 당신의 코드가 글로벌 이행성을 필요로 한다면, 범용 배리어를 -사용하십시오. +다시 말하지만, 당신의 코드가 모든 오퍼레이션들의 완전한 순서를 필요로 한다면, +범용 배리어를 사용하십시오. ================== @@ -3058,6 +3053,9 @@ AMD64 Architecture Programmer's Manual Volume 2: System Programming Chapter 7.1: Memory-Access Ordering Chapter 7.4: Buffering and Combining Memory Writes +ARM Architecture Reference Manual (ARMv8, for ARMv8-A architecture profile) + Chapter B2: The AArch64 Application Level Memory Model + IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide Chapter 7.1: Locked Atomic Operations @@ -3069,6 +3067,8 @@ The SPARC Architecture Manual, Version 9 Appendix D: Formal Specification of the Memory Models Appendix J: Programming with the Memory Models +Storage in the PowerPC (Stone and Fitzgerald) + UltraSPARC Programmer Reference Manual Chapter 5: Memory Accesses and Cacheability Chapter 15: Sparc-V9 Memory Models -- cgit v1.2.3 From 80416fb43e14e443dd18bc395167f73dba271748 Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Sat, 18 Nov 2017 11:52:24 +0900 Subject: kokr/memory-barriers.txt: Fix typo in paring example This commit applies an upstream change, commit d92f842bb30f ("memory-barriers.txt: Fix typo in pairing example") to the Korean translation. Signed-off-by: SeongJae Park Signed-off-by: Jonathan Corbet --- Documentation/translations/ko_KR/memory-barriers.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 7433ad60fabc..1f99331aeb39 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -953,7 +953,7 @@ ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추 =============== =============================== r1 = READ_ONCE(y); <범용 배리어> - WRITE_ONCE(y, 1); if (r2 = READ_ONCE(x)) { + WRITE_ONCE(x, 1); if (r2 = READ_ONCE(x)) { <묵시적 컨트롤 의존성> WRITE_ONCE(y, 1); } -- cgit v1.2.3 From 0cf9bb67f518f1064ec482b790d51a6e02406cba Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 19 Nov 2017 10:02:20 -0800 Subject: documentation/svga.txt: update outdated file Drop CONFIG_VIDEO_400_HACK info completely. Drop CONFIG_VIDEO_RETAIN and CONFIG_VIDEO_LOCAL completely. Drop CONFIG_VIDEO_COMPACT and CONFIG_VIDEO_VESA info completely. Drop CONFIG_VIDEO_SVGA info since it has been removed. Drop chapter number & section number references since they are wrong. Drop (bad) ftp URL for 800x600 Thinkpad XF86Config. Rename CONFIG_VIDEO_GFX_HACK to VIDEO_GFX_HACK since it is not a Kconfig symbol. And to match the source code. Build options are controlled by the kernel kconfig utility. Signed-off-by: Randy Dunlap Acked-By: Martin Mares Cc: "H. Peter Anvin" Signed-off-by: Jonathan Corbet --- Documentation/svga.txt | 59 ++++++++------------------------------------------ 1 file changed, 9 insertions(+), 50 deletions(-) (limited to 'Documentation') diff --git a/Documentation/svga.txt b/Documentation/svga.txt index 119f1515b1ac..b6c2f9acca92 100644 --- a/Documentation/svga.txt +++ b/Documentation/svga.txt @@ -67,8 +67,7 @@ The menu looks like:: tells what video adapter did Linux detect -- it's either a generic adapter name (MDA, CGA, HGC, EGA, VGA, VESA VGA [a VGA with VESA-compliant BIOS]) or a chipset name (e.g., Trident). Direct detection -of chipsets is turned off by default (see CONFIG_VIDEO_SVGA in chapter 4 to see -how to enable it if you really want) as it's inherently unreliable due to +of chipsets is turned off by default as it's inherently unreliable due to absolutely insane PC design. "0 0F00 80x25" means that the first menu item (the menu items are numbered @@ -138,7 +137,7 @@ The ID numbers can be divided to those regions:: 0x0f05 VGA 80x30 (480 scans, 16-point font) 0x0f06 VGA 80x34 (480 scans, 14-point font) 0x0f07 VGA 80x60 (480 scans, 8-point font) - 0x0f08 Graphics hack (see the CONFIG_VIDEO_HACK paragraph below) + 0x0f08 Graphics hack (see the VIDEO_GFX_HACK paragraph below) 0x1000 to 0x7fff - modes specified by resolution. The code has a "0xRRCC" form where RR is a number of rows and CC is a number of columns. @@ -160,58 +159,22 @@ end of the display. Options ~~~~~~~ -Some options can be set in the source text (in arch/i386/boot/video.S). -All of them are simple #define's -- change them to #undef's when you want to -switch them off. Currently supported: - -CONFIG_VIDEO_SVGA - enables autodetection of SVGA cards. This is switched -off by default as it's a bit unreliable due to terribly bad PC design. If you -really want to have the adapter autodetected (maybe in case the ``scan`` feature -doesn't work on your machine), switch this on and don't cry if the results -are not completely sane. In case you really need this feature, please drop me -a mail as I think of removing it some day. - -CONFIG_VIDEO_VESA - enables autodetection of VESA modes. If it doesn't work -on your machine (or displays a "Error: Scanning of VESA modes failed" message), -you can switch it off and report as a bug. - -CONFIG_VIDEO_COMPACT - enables compacting of the video mode list. If there -are more modes with the same screen size, only the first one is kept (see above -for more info on mode ordering). However, in very strange cases it's possible -that the first "version" of the mode doesn't work although some of the others -do -- in this case turn this switch off to see the rest. - -CONFIG_VIDEO_RETAIN - enables retaining of screen contents when switching -video modes. Works only with some boot loaders which leave enough room for the -buffer. (If you have old LILO, you can adjust heap_end_ptr and loadflags -in setup.S, but it's better to upgrade the boot loader...) - -CONFIG_VIDEO_LOCAL - enables inclusion of "local modes" in the list. The -local modes are added automatically to the beginning of the list not depending -on hardware configuration. The local modes are listed in the source text after -the "local_mode_table:" line. The comment before this line describes the format -of the table (which also includes a video card name to be displayed on the -top of the menu). - -CONFIG_VIDEO_400_HACK - force setting of 400 scan lines for standard VGA -modes. This option is intended to be used on certain buggy BIOSes which draw -some useless logo using font download and then fail to reset the correct mode. -Don't use unless needed as it forces resetting the video card. - -CONFIG_VIDEO_GFX_HACK - includes special hack for setting of graphics modes -to be used later by special drivers (e.g., 800x600 on IBM ThinkPad -- see -ftp://ftp.phys.keio.ac.jp/pub/XFree86/800x600/XF86Configs/XF86Config.IBM_TP560). +Build options for arch/x86/boot/* are selected by the kernel kconfig +utility and the kernel .config file. + +VIDEO_GFX_HACK - includes special hack for setting of graphics modes +to be used later by special drivers. Allows to set _any_ BIOS mode including graphic ones and forcing specific text screen resolution instead of peeking it from BIOS variables. Don't use unless you think you know what you're doing. To activate this setup, use -mode number 0x0f08 (see section 3). +mode number 0x0f08 (see the Mode IDs section above). Still doesn't work? ~~~~~~~~~~~~~~~~~~~ When the mode detection doesn't work (e.g., the mode list is incorrect or the machine hangs instead of displaying the menu), try to switch off some of -the configuration options listed in section 4. If it fails, you can still use +the configuration options listed under "Options". If it fails, you can still use your kernel with the video mode set directly via the kernel parameter. In either case, please send me a bug report containing what _exactly_ @@ -228,10 +191,6 @@ contains the most common video BIOS bug called "incorrect vertical display end setting". Adding 0x8000 to the mode ID might fix the problem. Unfortunately, this must be done manually -- no autodetection mechanisms are available. -If you have a VGA card and your display still looks as on EGA, your BIOS -is probably broken and you need to set the CONFIG_VIDEO_400_HACK switch to -force setting of the correct mode. - History ~~~~~~~ -- cgit v1.2.3 From e7e61fc0ba7b92153e17f1f707d2b7b3d52c0588 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 19 Nov 2017 21:08:11 -0800 Subject: Documentation: fix profile= options in kernel-parameters.txt Correctly the formatting of several additions to the profile= option that have been added by using and listing the choices for it. Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 97a76eea7389..a0532127807f 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3223,13 +3223,15 @@ instead using the legacy FADT method profile= [KNL] Enable kernel profiling via /proc/profile - Format: [schedule,] + Format: [,] + Param: : "schedule", "sleep", or "kvm" + [defaults to kernel profiling] Param: "schedule" - profile schedule points. - Param: - step/bucket size as a power of 2 for - statistical time based profiling. Param: "sleep" - profile D-state sleeping (millisecs). Requires CONFIG_SCHEDSTATS Param: "kvm" - profile VM exits. + Param: - step/bucket size as a power of 2 for + statistical time based profiling. prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk before loading. -- cgit v1.2.3 From def4db33e69609a43b28b399d569b6a0d3ba272a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonathan=20Neusch=C3=A4fer?= Date: Sat, 18 Nov 2017 03:22:32 +0100 Subject: dt-bindings: trivial-devices: Remove fsl,mc13892 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This device's bindings are not trivial: Additional properties are documented in in Documentation/devicetree/bindings/mfd/mc13xxx.txt. Signed-off-by: Jonathan Neuschäfer Reviewed-by: Fabio Estevam Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/trivial-devices.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt index 4b169caab0eb..21e2d96295fe 100644 --- a/Documentation/devicetree/bindings/trivial-devices.txt +++ b/Documentation/devicetree/bindings/trivial-devices.txt @@ -55,7 +55,6 @@ epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE emmicro,em3027 EM Microelectronic EM3027 Real-time Clock fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer -fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51 fsl,mma7660 MMA7660FC: 3-Axis Orientation/Motion Detection Sensor fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer fsl,mpl3115 MPL3115: Absolute Digital Pressure Sensor -- cgit v1.2.3 From 87c9fd81825363237ac5560822e2261535800597 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Wed, 15 Nov 2017 10:59:53 -0200 Subject: dt-bindings: rtc: imxdi: Improve the bindings text Improve the bindings text by doing the following changes: - Remove the i.MX53 reference, as the RTC on i.MX53 is a different hardware - Add 'clocks' to the list of required properties - Explain that the optional security violation irq is the second entry - Use the real unit address and irq numbers for i.MX25 Signed-off-by: Fabio Estevam Acked-by: Juergen Borleis Acked-by: Rob Herring Signed-off-by: Alexandre Belloni --- Documentation/devicetree/bindings/rtc/imxdi-rtc.txt | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt index 323cf26374cb..c797bc9d77d2 100644 --- a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt +++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt @@ -1,20 +1,20 @@ * i.MX25 Real Time Clock controller -This binding supports the following chips: i.MX25, i.MX53 - Required properties: - compatible: should be: "fsl,imx25-rtc" - reg: physical base address of the controller and length of memory mapped region. +- clocks: should contain the phandle for the rtc clock - interrupts: rtc alarm interrupt Optional properties: -- interrupts: dryice security violation interrupt +- interrupts: dryice security violation interrupt (second entry) Example: -rtc@80056000 { - compatible = "fsl,imx53-rtc", "fsl,imx25-rtc"; - reg = <0x80056000 2000>; - interrupts = <29 56>; +rtc@53ffc000 { + compatible = "fsl,imx25-rtc"; + reg = <0x53ffc000 0x4000>; + clocks = <&clks 81>; + interrupts = <25 56>; }; -- cgit v1.2.3 From c51ff2c7fc45da8b18b28c4f15eca5a9975dfb59 Mon Sep 17 00:00:00 2001 From: Dave Hansen Date: Fri, 10 Nov 2017 16:12:28 -0800 Subject: x86/pkeys: Update documentation about availability Now that CPUs that implement Memory Protection Keys are publicly available we can be a bit less oblique about where it is available. Signed-off-by: Dave Hansen Acked-by: Thomas Gleixner Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20171111001228.DC748A10@viggo.jf.intel.com Signed-off-by: Ingo Molnar --- Documentation/x86/protection-keys.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/protection-keys.txt b/Documentation/x86/protection-keys.txt index fa46dcb347bc..ecb0d2dadfb7 100644 --- a/Documentation/x86/protection-keys.txt +++ b/Documentation/x86/protection-keys.txt @@ -1,5 +1,10 @@ -Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature -which will be found on future Intel CPUs. +Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature +which is found on Intel's Skylake "Scalable Processor" Server CPUs. +It will be avalable in future non-server parts. + +For anyone wishing to test or use this feature, it is available in +Amazon's EC2 C5 instances and is known to work there using an Ubuntu +17.04 image. Memory Protection Keys provides a mechanism for enforcing page-based protections, but without requiring modification of the page tables -- cgit v1.2.3 From 7eeb6b893bd28c68b6d664de1d3120e49b855cdb Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Wed, 11 Oct 2017 23:13:49 -0700 Subject: timer: Remove init_timer() interface All users of init_timer() have been updated. Remove the ancient interface. Cc: Thomas Gleixner Cc: Jonathan Corbet Signed-off-by: Kees Cook --- Documentation/core-api/local_ops.rst | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/local_ops.rst b/Documentation/core-api/local_ops.rst index 1062ddba62c7..2ac3f9f29845 100644 --- a/Documentation/core-api/local_ops.rst +++ b/Documentation/core-api/local_ops.rst @@ -177,18 +177,14 @@ Here is a sample module which implements a basic per cpu counter using printk("Read : CPU %d, count %ld\n", cpu, local_read(&per_cpu(counters, cpu))); } - del_timer(&test_timer); - test_timer.expires = jiffies + 1000; - add_timer(&test_timer); + mod_timer(&test_timer, jiffies + 1000); } static int __init test_init(void) { /* initialize the timer that will increment the counter */ - init_timer(&test_timer); - test_timer.function = do_test_timer; - test_timer.expires = jiffies + 1; - add_timer(&test_timer); + timer_setup(&test_timer, do_test_timer, 0); + mod_timer(&test_timer, jiffies + 1); return 0; } -- cgit v1.2.3